I've been looking at the control panel circuit board from a Canon Pixma MX340 multi-function inkjet. I have found the pins used for communication between the main board and control panel, and connected them to my oscilloscope. The first discovery was the line used by the control board to report button status back to the main board.

Here is a sample of communication activity on that line, reporting the user has pressed the "OK" button. (Rightmost of four buttons below the LCD screen.)

When I press a button that is not valid for the current menu, I hear an error beep. In this error case, information on the LCD does not change and nothing happens on pin 1 (yellow line). But if I press a valid button causing a change on screen, I see a digital serial communication wave form on the oscilloscope screen. A lot more of it.

I had to zoom out to get an idea of how much more. Whatever it is, it takes around 72ms to complete. Notably, it takes the same amount of time no matter what changed on screen. It doesn't matter if I change only a single digit or navigate to an entirely different menu. If there's any change, there will be ~72ms of activity on pin 1. This puts an upper limit on screen refresh rate of (1000/72) = 13.89 frames per second. Too slow for video games (no Doom for this screen) but perfectly fine for an inkjet control panel.

Transmission time of ~72ms would cover multiple cycles of pin 2 keyboard update data. This means keyboard status could change in the middle of a screen update, though again this lack of responsiveness is not a concern for an inkjet control panel.

To try to get some context as to the magnitude of data involved here, I went back to looking at data on pin 2. It looks like each bit takes roughly 4us to transmit. A millisecond would allow 1000/4=250 bits to be transmitted. 250 bits * 72 milliseconds = 18,000 bits. I look at the LCD and it looks like each character is represented by 8x16 pixels and there's room for two lines of 28 characters each. 8*16*2*28 = 7168 which is less than half of that wild guess.

That was only a rough estimate. Screen update data isn't necessarily transmitted at the same rate as keyboard data. Some of that data will be transmission overhead, so on and so forth. But getting the rough magnitude is informative for some broad strokes. If refreshing the entire screen took very little data, I could infer the mainboard is probably sending ASCII character values. But the quantity involved here meant the main board is probably not doing that. There's more than enough to be transmitting the entire LCD screen frame buffer as a raw bitmap. It also meant manually decoding this data on my oscilloscope is a hopeless task. Thankfully, I now have tools to help tackle such things. Before I do, though, there's still one more wire to examine under the oscilloscope.

This teardown ran far longer than I originally thought it would. Click here for the starting point.