Well, yesterday I nipped down to Maplins and bought myself a Brother PT-1010 label printer, as an upgrade for the PT-1000 I’ve been using for the past few months. This was mainly down to the fact that the ‘1000 was nearly useless for labelling component boxes — mine would never print the micro (mu) symbol, or the ohm symbol. That and the PT-1010 has a 12-character display and shows actual error messages, vs. the 8-character display and single “ERROR” message on the PT-1000 (you have to spend ages working through the flowcharts to find out what’s wrong with it!) Also, I wanted an excuse to rip the PT-1000 apart and figure out how it works (or worked?)
So I checked that the ‘1010 worked, moved the label cartridge from the 1000 (they both use the “TZ” tapes), and swapped the batteries over. Then I ripped the 1000 open and started investigating…
The P-touch system seems to be based on thermal transfer technology. There are actually three tapes in the cartridge, not one:
* The plastic carrier tape — the ink is transferred to the back of this tape, which also forms the front of the label.
* A thermal-transfer ink tape — this carries a thermal ink which is transferred to the carrier tape using a thermal print head. The unused sections of this are discarded.
* The adhesive backing and base — adhesive coated on both sides, one side covered with a protective sheet. This forms the back of the label.
So the idea is, the first two tapes pass in front of the thermal head, then the ink dots that make up the character are transferred from the ink tape to the carrier. The used ink tape is fed onto a takeup spool inside the cartridge, while the carrier tape (with ink dots transferred) is attached to the adhesive backing. Nice and easy, and it works pretty well — the labels will tend to put up with quite a bit of abuse, and the plastic carrier stops anything reaching the ink.
But what about the printer — how does it work?
Well, the PT-1000 uses a Panasonic MN101C77 microcontroller to control the print head. This chip is a mask-ROM device that appears to have either 32K or 48K of ROM, and either 1.5K or 3K of onboard RAM. So obviously there isn’t much space there for character definitions, etc., which explains the slightly ropey print quality.
The LCD seems to be controlled by a glob-top LSI, as seems to be the case with a lot of Chinese-made kit.
Lastly, there’s a ROHM BA6220 motor speed controller, which seems to exist solely to keep the speed of the DC motor (which I’ll get to in a minute) constant under varying load conditions.
So now we move onto the printer mechanism. We can split this into three parts:
* Printing — the thermal head, basically.
* Label feed — the motor, gearing and drive system
* Sensing and detection — the cutter actuation switch, and the three pinswitches that are used for cartridge presence and type detection.
The printing head itself appears to be a 64-dot 12mm thermal print head, manufacturer unknown (possibly Kyocera). There are ten contacts on the flat-cable connector, which is obviously not enough to drive the printing elements individually. So that means there’s a shift register in there. Two pins are used for +9V (actually 7V to 9V according to the legend on the power connector), two for +3.3V, and four for control — strobe, clock, data and latch-pulse.
There are also three pin switches in the cartridge bay. These are used to detect the state (hole/no hole) of the cartridge type points on the bottom of the P-touch cartridges. One of these is used to detect that a cartridge is inserted, while the other two seem to identify the tape size. I only have the 12mm tapes, so I can’t say for certain which pins control what without doing some further tests.
So now we move onto how the head actually works. To start with, I powered up the printer and used a multimeter to find all the ground and power pins. This was fairly easy — the PCB has labelled ground and +3.3V test points. I scanned across all ten pins on the connector, and measured the voltage on each pin. By tracing the tracks on the board, I found a few pairs of pins that were connected to the same points. It turns out there are two battery supply (more likely heater supply, about 7V to 9V) points, two +3.3V supply points, and two grounds. That’s six power pins, which leaves four actual signal lines.
One of my fairly recent acquisitions is a Tektronix TDS2024B digital storage oscilloscope. This nondescript white box can acquire at a sample rate of 2Gsps (two gigasamples per second), across four signal channels. This makes it ideal for reverse engineering digital circuitry, where lots of signals often depend on each other. It’s an absolute godsend for debugging SPI serial buses (which involve four lines — chip select, master-out-slave-in, master-in-slave-out and clock). You can watch an entire bus transaction take place, capture it, zoom in and out, and figure out in a few minutes why that particular transaction failed.
But enough about the scope. Seeing as we only have four actual signal lines (once we eliminate the power feeds), we can put each signal on its own input channel and see everything that’s being sent to the print head at a given point in time.
But to do this, I had to attach about half a dozen wires to the fine-pitch flat-cable connector… less said about that the better. The connector appears to be about 1mm pitch…
So now I’ve got the head wired up to the scope, I powered up the ‘1000 again, filled the print buffer with capital “X” symbols (these are easy to spot in data traces, as you’ll see in a minute) and hit print. The scope was set to trigger on the first clock cycle, and I ended up with this:
OK, that gives you an idea what the P-touch is sending to the head — the scope is triggering off the falling edge of channel 1 (Note the “CH1 (fall) 2.40V” in the bottom right corner of the screen dump). From the trace, it’s pretty obvious that Ch3 (magenta/pink) is some form of clock signal, and Ch4 (green) is data, which leaves Ch1 and Ch2. We can also see that the print data is sent in eight bursts, though we can’t see how many clock cycles there are in a burst. So let’s zoom in a bit:
Hmm. Eight cycles in each burst. That makes sense, seeing as eight bits is a byte. Let’s take a closer look at that trace, turn the cursors on and see how fast data is being clocked into the head…
That’s 1.6us per clock cycle, or about 625kHz. Let’s zoom back out again, and see how much time there is between each burst:
Once again the scope did the hard work — there’s a delay of 10us between data bursts. It looks like the print head is being controlled by some form of onboard serial port (shift register?) on the Panasonic chip.
Now I’m going to turn the cursors off, and set the scope to view 1 again. Note that this is a short video clip of about 6Mbytes in XviD/AVI format, not a static image:
This is the first view again, but shown in real time. You can see the high area of the data bytes move into the centre, then back out again. Think about what an “X” looks like. Two arrowheads next to each other, with symmetry around the centre point. Data is sent line-by-line, and the P-touch prints horizontally. What you just saw was a bunch of “X”es being clocked into the print head as bitmap data.
So now we need a few more measurements:
* The low time and high time for the Ch1 waveform. They aren’t the same, there may be some meaning in that.
* The low time and period for Ch2, and how long it takes from the rising edge of Ch2 to the falling edge of Ch1
Let’s go back to view 1 again, zoom out and move the trace along a bit:
Note that I’ve turned the cursors on, and used them to measure the low time of the Ch1 signal (first image). I’ve also measured the high time (second image). We’re looking at a low time of around 4ms and a high time of around 10ms. That’s a total of 14ms.
Last but not least, we need Ch2’s low time (pulse period) and the Ch2-to-Ch1 delay. This time I’m going to set the scope to trigger off Ch2’s rising edge, in Single Sweep mode:
Reading off the cursor values gives us a low time of 1.4us (first image) and a delay of 11.2us from Ch2 going high to Ch1 going low (second image).
So now we need to do some research. What are these signals? What do they do? What do they mean? Well, it turns out Kyocera have produced a really nice application note on how their thermal print heads work… and the waveforms match the P-touch ones almost exactly. So open up the [application note](http://global.kyocera.com/prdct/ios/tph/tech_cont_e.html) and read through it. Pay close attention to the “Driver IC equivalent logic circuit” and “Sequence of printhead operations” sections.
Let’s take a look at the first image again (the overall view) and #7 (the zoomed-out view):
Compare these with the timing diagram in the Kyocera appnote. See the similarity?
It seems Ch1 (yellow) is our Strobe, Ch2 (cyan/light blue) is our /Latch (not-latch) signal, Ch3 (magenta/pink) is the clock (which we knew before), and Ch4 (green) is the data line (which we guessed from the video trace). From the video, we can also infer that when a high bit is clocked into the register, that heating element will be energised on the next firing cycle (latch pulse followed by low pulse on Strobe).
So if we merge the pinouts we’ve deduced with the scope with the power pins that we found earlier, we get:
1. Vheater. +9V supply from battery pack.
2. Data. Serial data into shift register.
3. Clock. Serial shift clock. Apparently clocks on a high-to-low edge.
4. Latch pulse. Negative-going latch pulse, ~1.6us wide.
5. +3.3V logic supply.
8. Strobe. Negative-active strobe pulse used to fire the print heads. Timing critical.
9. +3.3V logic supply.
10. Vheater. +9V supply from battery pack.
You’ll notice that I’ve described the strobe as “timing critical.” The strobe must be low for no longer than the P-touch holds it low (in this case, 4 milliseconds). If it is held low for too long, the print head will burn out. The high time is irrelevant, as in this state the head elements (heaters) are not energised.
It’s also worth paying attention to the time from latch to strobe (there is a time delay from latching the data to it appearing on the thermal printing elements) and the clock rates.
Now I just need to figure out how that blasted motor speed controller works… The motor is wired in reverse, and the drive voltage seems to be around 2.685V according to my DMM. The BA6220 datasheet is pretty sparse though…
And as a final bonus, here’s a picture of my rather scruffy, cramped workbench: