Using a Thermal Printer Mechanism

 Using a Thermal Printer Mechanism

The Casio CP-10 is a neat calculator that has a thermal printer attached. The calculator also has a built-in clock and can do useful tasks such as printing this month's calendar. The date range is also useful as it ends in 2099. The printer is a small mechanism that take standard 38mm thermal paper. I found out that the mechanism is the same one that the FP-12 printer uses. This is a small printer that is designed to attach to a variety of calculators and pocket computers.

I bought a CP-10 to see if I could re-use the printer mechanism instead of the receipt printers that I have bought off ebay in the past. They are relatively expensive (over £20) whereas the CP-10 can be had for half the price, if the CP-10 is listed as non-working. Unfortunately the CP-10 has a NiCd battery pack, as the printer mechanism take a fair current when running and the pack is used to supply that. This means that a lot of CP-10s have suffered battery leakage and failed. This is what had happened to my example. After a brief attempt to revive it I cut off the printer mechanism and attached a blue pill and some extra circuitry.

There's seven transistors, one for each thermal element, and one transistor that drives the motor. There's an input for the home position switch as well. The mechanism has a tachometer output that gives a series of pulses as a magnet rotates near a coil. The magnet is attached to the motor, so this arrangement gives a reading of the motor speed. The pulse may also be used for dot timing. Unfortunately my mechanism seems to have a broken tachometer output. The coil reads 25M resistance, which is a bit high for a coil of wire. (I have since bought a second CP-10, this one shows signs of life and its coil reads 82R, so is much healthier). After trying my own tacho circuit, then copying the CP-10 circuit, then building a higher gain circuit with an op-amp I decided that the tacho output wasn't reliable enough to use. This may not be too much of a problem if the motor is run off a stable supply as the speed of the motor should be fixed. I should be able to time the motor moving from home position back to home position and scale the dot timings appropriately if need be.

The output from my working CP-10 is like this:

That's the calendar printout from the CP-10. The FP-12 has a print width of 20 characters, the CP-10 also seems to have a print width of 20 characters.

My first attempt at printing was a little more basic than a calculator. I turned the motor on and fired one element of the print head repeatedly:

This is a start, at least I'm getting dots. The motor drive also performs line feeds and the dots show that. The horizontal dots are the feed across the paper. the sloping dots are where the head is returning and the paper is being fed. After some work with the code, including adding a font table and using the input from the home switch, this is the output:

This is a test printout that is printing the parameters of the code that printed that section. I am also using 20 characters as the width here, simply because the mechanism is set up for it. There's a row at the top of the characters that is faint, I think this is to do with the ground wiring I have used.

There is also an interesting effect which is best shown in the lines of asterisks. They are darker on the right hand side of the line. I'm pretty sure this is down to the heating of the printhead as elements are turned on. Every time a dot is printed, the printhead warms up a bit. This means that to get an equivalent dot, you don't need to turn the element on quite as long the next time. In the printout above, I have a parameter called 'DEC_PERIOD' which controls part of my correction for this thermal heating effect. You can see that the second from bottom section has a DEC_PERIOD of 1 and the asterisks are darker to the right hand side of the line. The section above it has a DEC_PERIOD of 2 and the asterisks are printed more evenly.  The correction code counts the number of elements that have fired, accumulates those counts and uses them to create a 'temperature' for the printhead.  The DEC_PERIOD value controls the cooling of the printhead. This does lead to a working correction as can be seen above.

I think the CP-10 code must also be doing something similar, as the calendar printouts above show an even darkness across all the lines.

The CP-10 must also be correcting for supply voltage variations. It runs off four NiCd cells which will present a range of voltages to the motor and hence different speeds of printing. I have attached my working CP-10 to a power supply and varied the voltage. The time to print a line definitely changes, but the characters printed remain in the correct positions. The printout is fainter when the voltage is lower. The code could be using the tachometer signals from the mechanism. I can't do this but I could measure the time taken to print a blank line and use that to adjust the dot timings. Interestingly it appears that the CP-10 does print one blank line after it is powered on. I wonder if that is a timing line and the CP-10 is doing what I will probably have to do if I want to correct for voltage?

Next step? probably a PCB. But do I use a blue pill or STM32 chip? Given the size of the mechanism, a blue pill is a bit on the big side, so I think a chip would be better. The only problem is that there is quite a shortage of STM32s at the moment. I've got a few so that is probably OK.

There's a video here of the prototype:

 

 

Sony MZ-R37 LCD Reverse Engineering

Sony MZ-R37 LCD Reverse Engineering

I'd had a Sony MZ-R37 in the workshop for quite a while. I can't remember where I got it, I think it came in a job lot of something. It had battery leakage so I left it for later clean up. Unfortunately when I recently came to look at it again I found that the batteries had leaked out of the device and onto my shelf. It had turned from a possible recovery situation to a tear down and parts salvage. There's a video of the strip down here:

During that process I found that the display was an interesting little PCB with what looked like a serial interface. What made it particularly interesting was that it has a six character dot matrix display as part of the layout. This means that it could maybe display arbitrary character on it and make it a useful part to repurpose.

A very nice discovery was the service manual for the MZ-R37. This is very complete and had the pinout for the LCD controller flexi cable. It is indeed a serial interface. The interesting signals are:

DATA

CLOCK

STB

A0

DATA and CLOCK are serial data and clock respectively. STB is a strobe or chip select signal. The A0 line is a command/data selection signal. With this information it was easy to scope the signals up and see how the dot matrix data is transmitted. There's a block of 30 bytes clocked out with a preceding command byte of 0x0A. The bytes are columns of each 5x7 character, in sequence from left to right. The row order is not logical and has to be reordered from a standard top to bottom order. Only seven of the 8 bits in each byte is a dot matrix segment, the remaining bit (bit 0) controls an icon in the top right of the display.

I grabbed a trace of the matrix data for the Vr1.20 display, it is:

0x0a,                                           // Command code (A0 low)
0xe2, 0x14, 0x08, 0x18, 0xe2,                   // First matrix character data
0x7c, 0x20, 0x40, 0x40, 0x40,                   // Second matrix character data
0x00, 0x80, 0x80, 0xfe, 0x00,
0x00, 0x08, 0x00, 0x00, 0x00,
0x8c, 0x1a, 0x2a, 0x2a, 0xc8,
0xf4, 0x1a, 0x2a, 0x4a, 0xf4

As the data is jumbled it was difficult to decode this. I wasn't even sure that the matrix data was segment data, but 30 bytes was a bit too much for 6 characters of text if it was ASCII data. Counting the number of 1 bits in the data gave the same number as the number of segments in Vr1.20: 66 bits.

So it was definitely segment data. It took a lot of fiddling and test programs to work out the jumbling, but I did manage to work out the row order. 

I attached a Wemos D1 to the LCD PCB and replayed the 30 byte packet I captured earlier and the Vr1.20 appeared in the dot matrix area. I used voltage dividers on the GPIO lines and supply to drop the 3V3 to 3V0, just in case the display can't handle 3V3.

Once that was working I wrote a small test program that sent the 30 byte packet using a 5x7 font and jiggled row data. This allows arbitrary data to be displayed in the matrix characters. I also sent a second burst of data which is segment data for the left hand side of the display. The icons on the top right of the display are sent in bit 0 of each byte of the 30 character burst as mentioned above.

The switches are wired up with two signals that use voltage dividers to give different voltages for each key press. There's also a signal (WP) which pulses low when a key is pressed. Another signal (HOLD) is pulsed by the controller, but at the moment I'm not sure why. There's only one analog channel on the WEMOS D1 so I can't read both signals. At the moment the keys don't return different voltages when attached to the WEMOS, but do when attached to the MZ-R37 processor. I'm not sure why at the moment, but I'm not too worried about the switches, it was the display I was after.