I’ve got an Arduino Nano connected to the internals of a Canon Pixma MX340 multi-function inkjet, specifically the quadrature encoder reporting on rotational motion of the paper feed motor gear assembly. After capturing the power-up sequence, I pressed the button again to capture the power-down standby sequence.

This standby sequence took twice as long as the power-up sequence, 18 seconds versus 9. Almost 11 seconds were spent rolling backwards relative to printing feed direction, traversing about 248,000 encoder counts. Eight times more than the backwards roll during power-up, which traversed ~31,000 encoder counts. That long rearward roll was followed by a forward roll for ~25,000 encoder counts.

During this roll, there were no paper motion and the print carriage sits in the parked position. What effect could this roll have? At the moment, my only guess is something preparing the ink cartridges to sit for a while. It would make sense for the power-up sequence to prepare the ink cartridges for use, and then for the standby sequence to prepare them for storage. Trying to figure out the details of this preparatory work is on the to-do list for later this teardown.

Besides that very long motion, there are several small movements back and forth. Looking at the data, I can see the times and duration differ between them, but each of those smaller movements traversed 1800 encoder counts. Reviewing the startup sequence, most of those small movements were also 1800 encoder counts. This is interesting. I will have to determine how many degrees of rotation corresponds to 1800 encoder counts, then look for a mechanism that corresponds to such a rotation during later disassembly. This little detail should be easier to understand than the actual printing process.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Captured CSV and Excel worksheets are included in the companion GitHub repository.

Whenever I turn on my Canon Pixma MX340 multi-function inkjet, I immediately hear motors whirring and I had always been curious: I haven’t even tried to print anything yet. What is it doing? Now that I’ve retired the machine and slowly taking it apart, I want to get some information hopefully leading to some answers. I have attached an Arduino Nano to two photo interrupter sensors and the quadrature encoder reporting position of the paper feed motor gearbox assembly. The Nano watches those sensors and report on their status every 10 milliseconds to a serial port as a list of comma-separated values. Thanks to the “everything is a file” nature of Linux, I could run “cat /dev/ttyUSB0 > capture.csv” and I had a file I could import into Excel.

Here is the startup sequence that has long intrigued me, in the form of an Excel scatter chart. Horizontal axis is the time stamp. This graph covered about 9 seconds with a data point every 10ms, resulting in dots densely packed into a line. Vertical axis is the encoder counter value, with the encoder as a gray line maxing out at almost 32000 counts. (Getting a number for count per rotation is on the to-do list.)

The two photo interrupter sensors did not change state throughout startup.

Due to the way I wired up the quadrature decoder, positive values on on this counter correspond to rotating the paper feed backwards. I usually think of printing as advancing forwards on the Y-axis, so this is reversed from that I would have chosen if I had known. But now that it is connected, I don’t care enough to fix this minor issue. If it starts causing problems I can flip the two wires and reverse their direction.

The fact this plot appears to be a series of straight lines tells me the motor does not vary its speed (significantly) once it is in motion.

Zooming on the initial set of movements, I see an acceleration curve before it reaches that speed, and there’s a deceleration curve at the end of each movement. My eyes did not perceive acceleration and deceleration, so this exercise is already telling me things I couldn’t pick up with my own eyes. I can also see the first two movements here are both backwards, but the second movement has a gentler slope reflecting a slower speed. Another difference I could not see with eyeballs.

Zooming in on a different part of the graph, this is the point of maximum backwards travel. On the big graph I saw a small bump on either side of the peak, now I see the motor decelerated to a stop before immediately accelerating back up in the same direction, only to decelerate to a stop again before going in the opposite direction. It then slowed down again to a stop before resuming in the same direction at a different speed. Both of these pauses are extremely short, only a few milliseconds if that.

What did that motion accomplish? In fact, what did any of these motions accomplish? I don’t have answers yet, but I’m excited I’m peeling back at least the first layer of this onion. Next: power down standby sequence.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Captured CSV and Excel worksheets are included in the companion GitHub repository.

I’m slowly taking apart my retired Canon Pixma MX340 multi-function inkjet, and I’ve wrapped up my second pass examination of control panel electronics. Now I will switch attention to its paper feed motor assembly. First of all, calling it the paper feed motor is an understatement, I just don’t have a better name. Looking at gears and shafts on my first pass, I knew it is linked to several other mechanisms beyond feeding paper. I got a close look at how it can open the paper tray door at the front of the machine, but everything else is still buried out of sight at the moment.

They are still buried because I paused physical disassembly in order to ensure the machine remain in a running state. This was very useful as I probed electronic control and communication signals while it was running live. I gained far more insight this way than I could have if I couldn’t run the machine. I learned a lot about the document feeder, the scanner, and how the main board communicates with the control panel. After all that, though, I’m close to exhausting everything within my current skill level to understand. But I think there’s one or two more things I can do before I pick up the screwdriver again.

I want to record paper feed motor mechanism’s behavior. I can see with my eyes it turn forward and backwards multiple times at different speeds. There’s a sequence that runs upon power up, another one when it goes into standby, and naturally there is much more when the machine prepares to actually put ink on paper. I want to quantify that motion more precisely than what I can see with my own eyes. This way, in the likely event the machine stops running as a result of future disassembly, I have something to reference. Correlating them with mechanisms that probably won’t run by the time I disassemble the machine far enough to get to them. I need to quantify exactly what I want to record, then go look for tools that can help me do it.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I’ve been poking around the control panel assembly of a Canon Pixma MX340 multi-function inkjet. An examination of data sent to its LCD module was the final piece of information I had expected to extract when I started “Control Panel Round 2. This post will summarize what I found, with links to specific posts for more detailed reference.

Electrical

The control panel is connected to the main board with a long flat cable with twelve wires. Five of those wires are related to power supply: One 5.5V DC feed a single LED, a 3.3V DC supply for everything else, and three ground wires. Four wires enable direct main board control of four control panel elements: two buttons [Power] and [Stop], and two LEDs [Power] and [Alarm]. That leaves three wires for communication with the NEC K13988 chip on the control panel. See connector pinout post.

The NEC K13988 chip controls the remaining 2 LEDs on the control panel, has a matrix of wires to scan through the remaining 27 buttons, and passes display data onward to the LCD screen. Details at NEC K13988 chip pinout post and LCD connector pinout post.

Communication

Three wires for communication between main board and NEC K13988 chip consists of a single wire for [Chip Enable] and two wires for bidirectional communication. The protocol is 250000-8-E-1 asynchronous serial for both wires.

• Main board commands are always two-byte sequences, each command acknowledged by the NEC K13988 with a single byte 0x20.
• Main board bulk data transfers are announced with 0x06 for first byte of the two-byte command and the second byte indicates length of data transfer in number of bytes. This has only been observed for updating LCD screen bitmap, with five transfers of 196 (0xC4) bytes. After 0x06 0xC4 is acknowledged by a 0x20, 196 bytes are sent and another 0x20 acknowledgement at its conclusion. This post decoded a single frame using Excel.
• Main board commands with 0x04 as the first byte are LCD module commands. NEC K13988 will forward the second byte to the LCD.
• Main board commands where 0x0E is the first byte are LED commands. NEC K13988 will update illumination of [In Use/Memory] and [WiFi] LEDs based on two of the bits in the second byte.

In addition to 0x20 acknowledgements, the NEC K13988 sends a single byte reporting button matrix status every ~9.2ms. 0x80 means no buttons are pressed. Any value other than 0x20 or 0x80 will be one of the button matrix status reporting scan code listed in this post.

Commands

Lacking any reference material on these components, I don’t know the full meaning of most of the commands decoded and recorded by my Saleae Logic 8 analyzer. Some were correlated with observable behavior and listed above, but the rest remain opaque unknowns.

List of posts that go into more detail on commands associated with each machine state, along with some notes on timing pauses seen in logic analyzer captures:

• Brief activity upon plugging in power cable.
• Powering up from standby.
• LCD screen update.
• LCD sleep and wake.
• Going into standby.

Future

Sometime after this MX340 is completely torn down, I may try to repurpose this control panel assembly for a future project. I will start by playing back all of the commands recorded above and see if the control panel responds as observed. If it doesn’t, then I have to go back to my Saleae Logic captures and try to replicate the pause timing between commands. If that still doesn’t work, I have failed to capture something important.

If it works, I can try to gain more insight into those opaque commands. I can omit a command and look for changes in system behavior, then repeat for each opaque command. Or I may decide such investigation is not worth the trouble, and just play back those commands as-is while I focus on other aspects of the project. We’ll see what the future holds.

Up Next

This concludes “Control Panel Round 2” and I’m ready to move on. My next target is the paper feed motor assembly.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I am examining communication between NEC K13988 chip and LCD embedded controller on board the control panel of a Canon Pixma MX340 multi-function inkjet. There are five wires between them, and I have candidate roles for all five after running the printer and looking at their behavior with a Saleae Logic 8 analyzer. Armed with this information, I can configure the Saleae Logic SPI decoder module.

Selecting channel numbers for data, clock, and enable was straightforward. I had to go back and look at the waveform some more to determine the next few options: enable is low when active and there are 8 bits per transfer. Clock is also low when active, and data is valid on clock trailing edge. (With active low clock, trailing edge is the low-to-high transition.)

That left one unknown: does this system transfer most significant bit first, or least significant bit first? Saleae SPI decoder says most significant bit (MSB) first is standard, so I tried that first. I compared decoded data against what I saw before and saw no resemblance. I then flipped the decoder over to treat least significant bits (LSB) first, and jackpot! Decoded data matches byte-for-byte.

Looking at scenarios for system power-up, LCD screen update, and LCD sleep/wake, the pattern is clear. Every time the main board sent a two-byte command to the K13988 where the first byte is 0x04, the K13988 passes the second byte on to the LCD as a command. For LCD update bulk transfers, where the first byte is 0x06 and second byte is length of transfer, the command itself is not passed along but all bytes transferred afterwards are passed on to the LCD as data.

The question this raises is: do I have the correct setting? Perhaps the asynchronous serial communication between main board and K13988 was supposed to be decoded as MSB first, and the match here is merely a “two wrongs made a right” situation. I thought about it and decided the octal number pattern visible in button matrix scan code report wouldn’t exist if decoded as MSB first, so LSB first must be the correct setting.

LCD Pin	K13988 Pin	Role	Notes
1	28	SPI Chip Select	Active Low
2	26	Chip Enable	Active High
3	27	Command/Data	Low = command High = data Valid on first clock trailing edge (low-to-high transition)
4	9	SPI Clock	Active Low 8 bits per transfer
5	10	SPI MOSI Data	Least significant bit first Valid on every clock trailing edge (low-to-high transition)

It’s great when observations from different parts of the system align! It gives me confidence my notes here aren’t entirely gibberish. As a practical matter I don’t expect to put this knowledge to use, since I don’t plan to extract this LCD screen from its control panel assembly. I can only imagine one scenario where it might make sense to do so: if I want to update this LCD at a higher frame rate, I can decouple it from the K13988 and hook it up to something else with higher SPI clock speed. I doubt that will happen. I’m more likely to use another display, especially if I have its datasheet to know how much higher I can run the SPI clock. I lack such technical information for this screen. I only have information on what I can characterize based on change in measurable behavior, and it’s time to wrap it up with a summary.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Tracing through the control panel circuit board of a Canon Pixma MX340 multi-function inkjet, I found five communication wires between its control chip and LCD screen. While I was soldering wires to tap into that data bus, I hypothesized what they might be. My best guess was four wires for SPI plus an analog voltage wire to control display contrast. For my initial captures, I set Saleae Logic to analog mode and ran through scenarios similar to what I used to capture data between main board and control panel. The analog voltage hypothesis was quickly disproved: these are all digital signals of either 3.3V DC or ground.

Setting my capture settings back to digital, I started over from the beginning. At the moment I plugged in its power cable, four out of five wires went high.

When I pressed the power button, the first detected activity was the fifth wire going high. This pin stayed high until I pressed the power button to drop the system into standby mode. From this I inferred LCD pin 2 (red wire, logic analyzer channel 2) is passing through the “Chip Enable” signal. One mystery down, four to go.

Here’s a single-byte command sent to the LCD telling it to go to sleep. LCD pin 4 (green wire, logic analyzer channel 5) looks like an active-low clock signal, pulsing eight times to send a single byte. LCD pin 1 (yellow wire, logic analyzer channel 4) was dropped low just before the clock started pulsing, and stayed low until after it was done. This behavior is consistent with SPI “Select” wire, notifying LCD to pay attention to incoming synchronous clock and data signals. Speaking of data, that would be LCD pin 5 (black wire, logic analyzer channel 0) that held each data bit at the clock signal’s low-to-high transition.

Where does that leave the LCD pin 3? (blue wire, logic analyzer channel 6) It almost behaves like a SPI Select, except it drops low at the same time as the first leading edge of the clock. Too late to serve as notification for LCD to get ready, so it must mean something else.

This is the capture timeline for a LCD update, and it showed a behavior difference between blue and yellow lines. The blue pulses divide this transfer into five sections, matching the number of bulk transfers sent by the main board. For each section, several bytes were transferred with blue held low, followed by many bytes with the blue held high. This means the blue line indicates whether the data being transferred is to be treated as a command (low) or as data (high).

With candidate roles for all five wires, I could use them to configure Saleae Logic’s SPI decoder and look over the bytes transferred.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I’m taking apart my old Canon Pixma MX340 multi-function inkjet and the next step in this adventure is to tap into communication between the main chip (marked NEC K13988) and LCD screen (no markings found) of its control panel.

Earlier exploration of the circuit board indicated 5 of 24 pins on 1mm pitch LCD connector are wired to the K13988 indirectly via resistors and capacitors. I want to solder wires to connect those signals to my logic analyzer, and the easiest to solder features are five 330 ohm resistors much larger than other surrounding features. Out of habit I soldered the wire colors to match my oscilloscope channel colors, forgetting that I skipped the oscilloscope probing step and thus there would be no color mismatch concern here. Oops.

LCD Pin	Wire color	Saleae channel	K13988 pin
1	Yellow	4	28
2	Red	2	26
3	Blue	6	27
4	Green	5	9
5	Black	0	10

I have some idea of the kind of data that flows between that K13988 chip and system main board. Since this K13988 to LCD link sits downstream, I expect to see some subset of that data passed through. For me, the most interesting unknown is… why five wires? I’ve already traced out 3.3V power and ground to other pins on the connector, so they’re not involved in this set of five.

Something like asynchronous serial or I2C would need only two wires. SPI would need four wires, but that would still leave one explained wire. My best guess is the last wire controls LCD screen contrast, possibly via an analog voltage level. I recall seeing such a control scheme, designed so it’s trivial to implement a contrast adjustment knob by connecting a potentiometer to that wire. Those resistors and capacitors I see between K13988 and LCD are consistent with this idea, possibly implementing a filter to help turn a digital PWM signal into an analog voltage level.

The possibility of an analog signal was why I started my Saleae Logic session in analog mode.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Using a Python script I wrote to match known patterns, I am now confident I have a good record of communication between main board and control panel of a Canon Pixma MX340 multi-function inkjet. My next focus is communication between control panel’s NEC K13988 chip and LCD screen.

I’ve established the LCD is a pixel-addressable display with a resolution of 196-ish pixels wide and 34 pixels tall. With just five wires between K13988 and LCD, that’s far too few to control all pixels directly, so those five wires must lead to an embedded controller on board the LCD itself. Something with a frame buffer who will scan through all the segment/common lines of the pixel array to refresh them.

Given the delicate mounting mechanism and fine-pitched surface mount connector, I don’t expect to extract this LCD from the control panel assembly. Any potential future repurpose project will use the entire control panel assembly and not just the LCD itself. If I have a project that wants a small LCD, I’m more likely to use something else. So my objective here is just for learning’s sake. See if I can gain any further insight into the recorded (but not fully understood) communication between main board and control panel by looking at the LCD which lies downstream.

When I started examining communication between main board and control panel, my first step was wiring things up to an oscilloscope. One of the reasons was because I didn’t know the voltage going over those wires and my oscilloscope can handle a far wider voltage range than the logic analyzer. Now that I know this board runs on 3.3V DC (with the lone exception of a LED powered by 5.5V DC) I’m more comfortable skipping the oscilloscope step and go straight to wiring up the board for my Saleae Logic 8.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.