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.

Dehydrator MK 2

After success with Dehydrator MK 1, I decided that the cardboard box would probably give out after a while, but before that happened the supply of 100W light bulbs would run out. Several bulbs failed and they are now difficult to buy, so I decided to build a more solid solution.

I'd need a heat source, a fan, and something to control it all. In the end I added a temperature sensor and a humidity sensor, and attached an LCD panel that I had hanging around. An Arduino Uno controls everything.

The power for all the circuitry comes from a slightly modified power supply PCB from an old video recorder. I modified a couple of supplies to get 12V and 5V and added voltage control from one of the Arduino PWM ports so that I could control the fan speed using firmware.

Video recorder PSU PCB

The electronics is in a separate area to the drying chamber, with a hinged front panel to allow access.

The arduino and the display are on one panel:

The fan and power supply and the power resistor controller are on a second panel:

The heat source I settled on was a 200W wire wound resistor that was connected across the mains supply using a triac with an opto isolated trigger from one of the Arduino GPIO lines. The algorithm works on a 30s cycle, altering the duty cycle of the power drive between 0% and 100%, in order to get different power outputs from the power resistor.

I also added an I2C temperature and relative humidity sensor so that I can attempt some form of automation in the future. All the power settings and readouts from sensors fits on the LCD display:

The trays fit in from the top (something I may change in a dehydrator MK 3, as it's a bit fiddly but it does make the air flow easier) and are wooden frames with plastic mesh on them.

I've dried apple, tomatoes and mango in the drier so far and the results are pretty good, I can't tell dried mango from the dehydrator from shop bought dried mango.