I2C Monitor
The I2C Monitor shows every write to and read from the devices on the I2C bus of your EZBs, timestamped, by device address, in a hex editor style view. Use it when an I2C device (an IMU, a display, a temperature sensor, a servo driver board) does not answer, reads nonsense, or behaves unexpectedly. You can see exactly what was written, which register was read, what came back and how long it took, then save the traffic to a file to review later or post on the forum.
Where to find it: Side menu → Views → I2C Monitor. It is also under Views when you right-click a workspace.
What is captured
- Writes to a device: the bytes ARCx sent to its address.
- Reads from a device: the bytes that came back, and how long the read took.
- The bus clock, when a robot skill or script sets the I2C clock speed.
- Failed calls, such as a write with no data, with the reason.
- Markers you add yourself.
Traffic from robot skills and from scripts is captured alike. Each entry says who made the call: the robot skill's name, or JavaScript or Python for a script.
Addresses are always shown in the 7 bit form, such as 0x68. A robot skill that gives an 8 bit address (0xD0) is shown at the same 7 bit address.
Registers
Most I2C devices are a set of numbered registers. The monitor reads the usual pattern and says what each transfer is doing in the Length · from column:
| Transfer | Shown as |
|---|---|
| A write of one byte | register pointer 0x3B: the next read starts at register 0x3B. |
| A write of two bytes | register 0x6B = 0x00: register 0x6B is set to 0x00. |
| A longer write | registers from 0x10, 4 bytes: several registers set in a row. |
| A read soon after a one byte write | from register 0x3B, or from register 0x3B on when it reads several. |
This is a hint, not a decode. Some devices take commands instead of registers (a sensor's "start measurement" command looks like a two byte register write), and text written to a display shows as a register write too.
Capturing
Tick Capture I2C traffic to start. Capturing is off when ARCx starts. While it is off, the I2C calls do no extra work, so leaving the feature unused costs nothing.
Capturing carries on when you leave the page, so you can tick the box, go to the robot skill that talks to the device, reproduce the problem, and come back. A red REC badge shows while it is on. Untick the box to stop; what was captured is kept.
The newest 50,000 entries (up to 16 MB of data) are kept in memory. When the buffer is full, the oldest entries are discarded and the status line says how many. The capture is not saved with the project and is gone when ARCx closes. Save it to a file to keep it.
The status bar
| Item | What it does |
|---|---|
| Capture I2C traffic | Starts and stops capturing for the whole of ARCx. |
| Status | How long has been captured, the number of entries, how full the buffer is, and how many entries the filters are showing. |
| Marker | Adds a numbered marker to the capture at this moment, such as just before you move the robot. Markers make a moment easy to find later. |
| Save | Text file for Notepad (.txt) saves a hex dump that opens in any text editor. Spreadsheet (.csv) saves one entry per line for Excel or similar. Copy for a forum post copies the text version to the clipboard inside a code block, ready to paste into a post. All three save what the view is showing, with the filters applied, and the file says which filters were used. |
| Clear | Deletes everything captured and the device totals, after asking. Capturing carries on if it is on. |
The device cards
Each device address that has been talked to gets a card.
- Under the address is what the device could be, from the chips that commonly use that address, such as MPU-6050 / MPU-9250 / DS3231 / DS1307 for 0x68. Several chips share most addresses, so check it against what is wired to the robot.
- The Write (orange) and Read (teal) lights blink when the device is written to or read from.
- The sparkline shows the bytes per second written and read over the last minute.
- The totals show the bytes written and read, and a red count of failed calls when there are any.
The Bus card shows the clock speed when one has been set since ARCx started. Until then the EZB uses its default and the card does not appear.
Click a card to hide that device's traffic from the view. Click it again to show it.
Filtering and display
| Control | What it does |
|---|---|
| Write / Read / Events | Show or hide writes, reads, and the other entries (the clock, errors and markers). |
| Search | Shows only the transfers that contain what you type, and highlights the match. Hex such as 3B or 6B 00 searches for those bytes. Anything else, or text in quotes such as "OK", searches for that text, ignoring letter case. Searching also finds the words of the register notes, so 0x3B finds every transfer about register 0x3B. |
| Bytes per row | 8, 16 or 32 bytes on each line. |
| Merge | Joins reads (or writes) of the same device that are less than 30 ms apart into one packet, for robot skills that read a block of registers a few bytes at a time. |
| Colours | Colours each byte by kind: zero, printable text, control characters, high bytes (0x80 and up), and FF. The key is at the bottom of the inspector. |
| Follow | Keeps the newest traffic in view. Scrolling up stops following so you can read; scroll back to the bottom or click Follow to start again. |
Reading the view
| Column | What it shows |
|---|---|
| Time | The computer's clock when the entry was recorded, to the millisecond. |
| Δ prev | The time since the entry above. |
| Device | The EZB and device address, such as 0·0x68 for address 0x68 on EZB 0. Each device has its own colour. |
| Dir | ▶ WR is a write to the device. ◀ RD is a read from it. INIT, ERR and MARK are the other entries. |
| Off | The offset of the first byte on the line within the transfer, in hex. |
| Hex | The bytes. |
| ASCII | The same bytes as text. Bytes that are not printable show as a dot. |
| Length · from | The size, how long a read took, the robot skill or script that made the call, and the register note. |
Move the mouse over a byte and the same byte lights up in both the hex and the ASCII column.
The inspector
Click a byte to see what it means in the inspector on the right:
- The transfer it belongs to: direction, device, time, size, how long it took and who made it.
- The byte as binary, unsigned and signed, and as a character.
- The bytes starting there read as 16 and 32 bit numbers, little endian (LE) and big endian (BE), and as a float. Most I2C sensors send their readings big endian: an MPU-6050's accelerometer X is the Int16 BE of the first two bytes read from register 0x3B.
Shift + click another byte of the same transfer to select a range. The inspector then also shows the range's checksums. When the byte (or two bytes) right after the selection hold the same value, that checksum is marked ✓ next. Sensirion sensors (SHT3x, SHT4x, SCD30, SCD4x) send a CRC-8 Sensirion after every two data bytes: select a pair to check it.
Click beside the bytes of a row to select the whole transfer. Hex and C array copy the selected bytes to the clipboard, and Clear clears the selection.
Things to look for
- Reads of all FF usually mean nothing answered at that address: the wrong address, the device is not powered, or the wiring is loose.
- An address twice or half what the datasheet says is an 8 bit address given where a 7 bit one is expected, or the reverse.
- A register note that does not match the datasheet is a robot skill or script reading the wrong register.
- ERR entries say why a call failed.
Saved files
The text file is plain ASCII, so it looks the same in Notepad, an e-mail or a forum post. It starts with when and what was captured, the filters used, and each device's totals and what it could be, followed by every entry:
12:55:09.945 +1.23 ms EZB 0 0x68 WRITE 1 byte register pointer 0x75 (JavaScript)
0000 75 |u|
12:55:09.947 +1.56 ms EZB 0 0x68 READ 1 byte [0.20 ms] from register 0x75 (JavaScript)
0000 68 |h|
The time in square brackets is how long the read took. The CSV file has one entry per line with its sequence number, date, time, milliseconds since the capture started and since the line above, how long it took, EZB, address, direction, length, the bytes as hex and as text, the clock speed, who made the call, and the register note.
AI assistants
An AI assistant connected to ARCx over MCP can use the same capture to help find a problem with an I2C device. It can start and stop capturing, read the traffic and add markers. It sees exactly what this page shows.
Notes
- Only the I2C bus of EZBs is captured.
- A write does not wait for the device to answer, so only reads show how long they took. The time includes the network time to the EZB.
- Several pages, browsers and an AI can look at the capture at once. Clearing it clears it for all of them.
- UART traffic has a monitor of its own that works the same way: Side menu → Views → UART Monitor.