Canon Pixma MX340 Control Panel LCD Screen Update First Look
Listening in to serial communication between circuit boards of a Canon Pixma MX340 multi-function inkjet, I think I have a handle on how the control panel reports button presses to the main board. Some of these button presses trigger updates to information shown on the control panel LCD screen, which gave me a first look at what that involved.
Pressing right/+ button at the home screen incremented a number on screen representing number of copies to be made. Pressing left/- afterwards triggered another update as the number was decremented. For each of the two screen updates, I observed similar behavior. It starts with four two-byte sequences from the mainboard, each followed by a single byte 0x20 from the control panel which is probably an "OK" acknowledgement.
After that, a large number of bytes were sent from the mainboard. I didn't find a way to ask Saleae Logic to count the number of bytes for me. (I hope I don't end up counting manually) But at least it was easy to measure the time interval for this transmission: 14ms. At 250000 baud 8E1, that can't be more than (0.014 seconds * 250000 symbols per second / 11 symbols per byte) = 318 bytes. Plus I saw a few pauses in between this data transmission, so it wasn't transmitting at full speed. Looking at powers of two numbers, I think 256 bytes is a good candidate. At the end of this burst of bytes, there was another 0x20 acknowledgement from the control panel.
[UPDATE: I've figured out the burst is 196 bytes long, shorter than the 256 I guessed. 196 decimal is 0xC4 hexadecimal, which explains the fourth two-byte transmission. 0x06 0xC4 must mean "I am about to send you 196 bytes"]
This pattern (four two-byte sequences, followed by a large number of bytes) was repeated five times.
Transmission from main board | Acknowledgement by control panel |
---|---|
0x04 0x4D | 0x20 |
0x04 0xC8 | 0x20 |
0x04 0x30 | 0x20 |
0x06 0xC4 | 0x20 |
[... 196 bytes ...] | 0x20 |
0x04 0xCD | 0x20 |
0x04 0xC8 | 0x20 |
0x04 0x30 | 0x20 |
0x06 0xC4 | 0x20 |
[... 196 bytes ...] | 0x20 |
0x04 0x2D | 0x20 |
0x04 0xC8 | 0x20 |
0x04 0x30 | 0x20 |
0x06 0xC4 | 0x20 |
[... 196 bytes ...] | 0x20 |
0x04 0xAD | 0x20 |
0x04 0xC8 | 0x20 |
0x04 0x30 | 0x20 |
0x06 0xC4 | 0x20 |
[... 196 bytes ...] | 0x20 |
0x04 0x6D | 0x20 |
0x04 0xC8 | 0x20 |
0x04 0x30 | 0x20 |
0x06 0xC4 | 0x20 |
[... 196 bytes ...] | 0x20 |
Looking at the four two-byte sequences, they differed only in the second byte of the first pair. I've highlighted this byte in the table above. Perhaps this is an address of some sort, and if so I find it interesting the values are not consecutive from one iteration to the next.
I haven't figured out how I'll analyze the burst of data. A few hundred bytes is too unwieldy to examine in a linear capture timeline, I'll have to think about what other tools I could bring in. [UPDATE: Microsoft Excel to the rescue.] Despite that open question, this established a baseline pattern for comparison against other machine states.
This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.