Replace LCD on HP/Agilent 664XA PSUs

[Gandalf_Sr]

I have a couple of PSUs 6642A 6643A that have the old non-backlit displays that have the caption markers under them.  I saw that someone had done an OLED display like this (check out the youtube video) but I don't want to use a $21 OLED; I do like the way that the captions are presented as text on the second line.

This would be a pretty straightforward project, the idea would be to create a small PCB that matches the connector on the end of the HP ribbon cable and have a 50 cent micro-controller translate the HP signals to the new LCD signals. Finally, I'll design a plastic part that mounts the 16x2 or 20x2 character display into the existing HP slot.

Things I'd need to make this work:

1. Info on the connector that's at the end of the ribbon cable.
2. Info on the signal format coming from the power supply end.
3. A PCB - I can design and have made
4. Micro-controller code - I can write, I already have LCD driver code written
5. Physical adapter design - I can design and print on 3D printer

I've bought displays like these from buydisplay.com before and they are very nice and cheap.

Help me get this working and I'll share the design files here.

So for 1 above - the connector. Please see the picture below.  I have pulled at it but it's not clear how or if it comes apart. I had assumed it was a 0.1" header plug but now I'm concerned that it's some sort of IDC connector that's soldered to the PCB - can anyone shed any light on this?

And for 2 above - the format of the signals.  I found the service manual for this series of PSUs and, on p150 (left side) it shows connect J2 going to the LCD; the right side of that has various supplies that are needed for the LCD including 5V and 3.3V so power should be no issue. But what about the data? it's clear that there's a 4-bit data bus with H0..3 and there's 2 other lines so I assume it's like the 4-bit parallel HD44780 style data with Enable, R/W, and RS pins. It might be possible to ID the display and find a data sheet for it and the really good bit would be if eb4eqa would share his code for translating the data coming from the PSU.

Any ideas or suggestion for improvements or approach?

[coromonadalix]

what is the big chip markings ?

its an Optrex  what number  ?, your finger hide a number i think

Seems to work in 4 bit as you guessed with an 8096 cpu, it should not be hard to decode the data ?

Maybe the 1.1 2.2 3.3 volts are for contrast and brightness modes adjustment, since you have rt1 on the 3.3vdc line ??

[coromonadalix]

Old ebay sale at 50$ usd  ??

Seems to be that part number
HP/Agilent/Keysight 06624-60002 LCD

Original pn:  5061-1190

[tsman]

I doubt you'll find a direct datasheet as this will be a custom HP part. Optrex did have some LCDs with an interface similar to HD44780 and also one with far more control lines which wouldn't work with this. I can't find any display that has the same pinout though.

I suspect it'll be similar to the HD44780 as you mention. 4 data + E + RS and the R/W line is just forced to W always. The other 4 data lines are just not connected since its operating in 4 bit mode.

Best bet is just to wire up a logic analyser and see what is going on. Doubt it is very complicated. You can probably ignore most of the initialisation writes as well since your display is specifically designed for this PSU.

[Gandalf_Sr]

OK, unless eb4eqa (or someone else who has crossed this bridge before) comes up with the format info, I will have to logic-analyze the data but first I need to get that IDC connector off the LCD PCB - any ideas about that?

Here's a couple of pictures of the info that was hidden by my thumb + the part marking.

[coromonadalix]

https://www.nxp.com/docs/en/data-sheet/PCF8578.pdf

its an i2c interface display

the 4 data lines can be:  sck, data or miso mosi  etc ...

Hum  i think its an idc conntector snapped in the thru holes like the hp3478 meter lcd ?


--------------------------------------------------------------------------------------------------------------

EDIT:  ask qu1ck  member here  he's done a great job reverse the hp34401a  old vfd board display protocols

here is github infos : https://github.com/openscopeproject/HP34401a-OLED-FW

[tsman]

Odd it has 4 data lines connected to the HSO peripheral in the 8096 + 2 extra unknown lines for an I2C display. The HSO lines look to be output only on a 8096 but I'm not familiar with this particular uC. If they are output only then the 2 extra lines (9 + 11) are probably I2C with pullups on the display itself. I've no idea what those 4 HSO lines are.

[Gandalf_Sr]

tsman is right, the PCF8578 is an LCD driver IC that takes an I2C input.

What I need to do is figure out how to disconnect the display connector and then intercept the I2C signals and see how they correspond to what I see on the display.  It does look like this will be very similar though as it even explains that the caption bars are just bits in 2 bytes that update whenever a caption bar changes.

[EDIT] I might be moving faster on this if water hadn't started to drip in my basement! Bugger!

[coromonadalix]

you ca emulate i2c  on any cpu if you put the right code / fw     if you have the right timings, the lcd refresh can be fast enough to not see any artefacts ...

[tsman]

tsman I think coromonadalix is right, the PCF8578 is an LCD driver IC that takes a SPI input and, if the info on the HP 34401a meter here is relevant, then the protocol.md file may have 80% of what I need.

PCF8578T is I2C not SPI. It looks to be just using a single PCF8578T in its basic 32x8 multiplexing mode as that should just cover all the segments on your LCD. The HP34401A display protocol isn't the same as what the PCF8578T is expecting. You'll need to work out what bit turns on what segment.

[coromonadalix]

oh  forgot that       yeah  spi is not i2c  loll  vice versa

Surely on the web   must be some code snipets

maybe with translation : https://www.roboternetz.de/community/threads/15812-Hilfe%21Fur-LCD-display-mit-PCF8578T

you have lots of i2c arduinos lcd projects,  maybe could wire some i2c decoder   you have the serial port to help debugging ??


Adresses

Hex 50 - 5E
Hex 60 - 6E
Hex 70 - 7E

PCF8576   PCF8576   PCF8577   PCF8577A  PCF8578   PCF8578   PCF8566   PCF8566
SAA1064   SAA1064   SAA1064   SAA1064   PCF8579   PCF8579
PCF8574A  PCF8574A  PCF8574A  PCF8574A  PCF8574A  PCF8574A  PCF8574A  PCF8574A


And some infos : http://micro.et-inf.fho-emden.de/data/i2c/i2c_faq.txt

[tsman]

This may be useful. xi made a replacement HP 3457A display. The pin arrangement matches up with what your HP 6642A service manual shows.

Not sure how this works with that PCF8578T I2C LCD driver though. Are there any other hidden chips on that display? Maybe it isn't actually I2C and there is another processor somewhere? I think you'll need to put a logic analyser on this to really work out what is going on.

They managed to get that connector off as well somehow.

Code: [Select]

       1  2 3.3V
HO(2)  3  4 2.2V
HO(3)  5  6 1.1V
       7  8 GND
P1.6   9 10 C2 capacitor
P1.7  11 12
HO(1) 13 14
HO(0) 15 16 5V

Code: [Select]

                                               (NC) 17|18 (V3V: power supply for the LCD)
                            (instruction line: ISA) 19|20 (V2V: power supply for the LCD)
(1 = read data on ISA / 0 = read data on INA: SYNC) 21|22 (V1V: power supply for the LCD)
                                               (NC) 23|24 (GND)
                                   (data line: INA) 25|26 (OS1: for internal oscillator of the LCD display ; connected to a 470pF capacitor on the motherboard)
  (second clock, same as O1 with a small delay: 02) 27|28 (NC)
                                        (clock: 01) 29|30 (NC)
                          (global chip select: PWO) 31|32 (VCC: +5V with a serial resistor of 1k on the motherboard)


[coromonadalix]

got me on that one TSMAN   i was searching for it loll   

Can you see something between the lcd and the pcb if the gray connector is soldered or just snapped in the thru holes ?

[Gandalf_Sr]

OK, you're right tsman, I2C, not SPI. So the github stuff is no good   I'll change previous post

I have a bucket under the drip and most stuff that could be damaged picked up!

[Gandalf_Sr]

I got some data to look at.  You guys were right that the connector on the end of the cable is simply plugged into a set of gold-plated through holes on the LCD PCB (see picture) I was able to carefully prize it off using a very fine flat screwdriver.  I tapped out the signals going to the first 9 pins of the PCF8578T and found that only 2 of the 4 data signals go anywhere. So it looks like all there is 5V, Gnd, SCL, and SDA.  I hooked up wires to an unpopulated SMT footprint that's to the left of the connector and connected the Saleae Logic 8 on to grab the data (see attached .xls file) after a quick refresher lesson for myself on how to use the Saleae.

These data represent a 10 Sec capture during startup where the display briefly shows...

ADDRESS      4
----------------

and then...

 0.00V  -0.00A
-      -

The bucket has maybe 3 inches in it over the last 19 hours

[Gandalf_Sr]

There's something wrong with my decode setup as the PCF8578T specifically says that it generates an ACK after every byte but all the decodes say that there's a missing ACK, I'll try another capture and post up a screen shot.

-6 degree F this morning in Michigan - brrrrrrrrrr

[EDIT] Did another capture, all looks OK signals-wise with the exception that there are no ACKs but the master seems to not care.  Maybe the decoded data in the .xls file is good.  I found this from the german language translated link...

$ regfile = "2313def.dat"
$ crystal = 4000000

Config Sda = Portd.4
Config Scl = Portd.5

I2cinit


Const Disp = $ 78 'PCF8578 Adr

'----------------- Display Initialization ----------------------------- ----------

I2cstart 'Start
I2cwbyte Disp' send slave address PCF8578
I2cwbyte $ d9 'Write Set Mode: Mixed Mode, all segments on, 1: 8Mux
I2cstop' Stop
Wait 1 '1 second wait
I2cstart' Start
I2cwbyte Disp 'send slave address PCF8578
I2cwbyte $ d5' Write Set Mode: Mixed Mode, normal, 1: 8Mux
I2cwbyte $ e0 'Device Select Addr 0000 only if multiple PCF8578
I2cwbyte $ 88' X Address = 8
I2cwbyte $ 70 'Ram Access: Character, Ram Bank 0
I2cstop
' Init done
'--------------------------------- ----------------------------------------------
'This Must Turn on All Segments on the Display for 1s
' look Datasheet

73 DE Arthur

Looks similar to my early early code because I briefly have all the segments of the display come on, then the ADDRESS 4, then the 0.00V -0.00A display

[Le_Bassiste]

on my HP6626, the ribbon cable plug isn't soldered onto the display. it can be pulled off easily with pliers.
as for the display protocol, would this help? (i gave up on a similar project some time ago- maybe you can use my findings)

[Gandalf_Sr]

Working through the commands and translating what they mean from the PCF8578 data sheet - updated spreadsheet attached.

I'm hoping that I'll begin to recognize something that relates to the character block in this post here.

[Le_Bassiste]

probably not, because there are at least two different display types out there, one being I2C (TWI) , the other one being ISA (similar to HP-41C) interface type.

edit:
oops, not so much HP-41C, but HP3468A multimeter display type, which has PHI, ISA, INA and SYNC line.

[Gandalf_Sr]

Thanks, when you say you gave up on it, did you actually figure out how the characters were formed?  I have a secret decoder chart but I'm not sure it's the right one 

[EDIT] I'm think I'm getting somewhere thanks to Le_Bassiste!
The sequence of numbers (written as Hex) that follows the preamble of D5 FC E0 F0 08 is sequences of 3 bytes that, as a set of 3, contain characters for positions 1 and 7 in the 12 character display; you have to break each byte into 2 nybbles and then group the high ones together and the low ones together (maybe Le_Bassiste already figured this out?).

So on the big pdf that Le_Bassiste provided, the display showing ADDRESS...8 (which corresponds to the sequence I recorded that's already in my spreadsheet) shows 37 44 C6 as the first 3 bytes, this is giving first digit 'A' from the low nybbles (7,4,6) and seventh digit 'S' from the high nybbles (3,4,C).

Look at other sequences in the big pdf that Le_Bassiste posted and you'll see that this translation works everywhere   

BWAHAHAHAHAHAHAHA!!!

[Le_Bassiste]

(spoiler alert)
...aaand here's what i found out concerning the segments coding of the display. maybe not correct in places, but you get the picture.
on the ascii char table the column heading "LCR" reads "left, center, right". the orange pictogram has the according segments.
so, for the letter "A", the coding reads L7, C4,R6. now, going into the pictogram, find all segments that are named L7,C4,R6. note also that "R6" lights up the two right-hand vertical bars, while "RE" lights up those _plus_ the the bottom bar. thus, letter J comes out at L4, C0, RE, where C0 means "no center segments lit".

hth, and keep us posted in case you dig up some errors in the table.
(edit: still some chars missing, though...)

[Gandalf_Sr]

Le_Bassiste, It seems like you're trying to find some perfect algorithm to decode the LRC numbers but that's not strictly necessary.  There are tables available that show 14 segment display driver fonts but I think the simplest (but not slickest) approach is to create a lookup table in C code that simply translates any combination of LCR to an ASCII character.  There will need to be some way to strip off the decimal point but that should be fairly simple as it's only 1 segment.

[Gandalf_Sr]

I just got a pm from eb4eqa on how he implemented his replacement OLED for the 6632B PSU but it seems way more straightforward than what I'm attempting as the characters coming from the PSU are just a stream of ASCII where one byte represents one character on the display (from what he sent me).

We're trying to decode the 14 segment display bits that have been sliced, diced, and blended together!  It may well be that the bits in the 3 nybbles correspond to specific segments lit up on the old Omron display (e.g. there's only 1 bit difference between 8 and 9) so the decimal point and captions must be separately encoded.  Anyone got any idea how they are encoded?  It looks like they are in the stuff to the right of 18 x 12-character bytes.

I'll keep looking at it as it may be possible to decode what each char looks like from the segments it lights up and that would allow me to figure out how to decode 12 segments to ASCII but a lookup table is the logical way to implement the electronics, either way there are 4096 possible permutations of 12 bits so you feed the 12 bits into an array and it spits out the ASCII character to display.

[tsman]

I just got a pm from eb4eqa on how he implemented his replacement OLED for the 6632B PSU but it seems way more straightforward than what I'm attempting as the characters coming from the PSU are just a stream of ASCII where one byte represents one character on the display (from what he sent me).

EB4EQA's implementation won't be the same. He's tapping a serial line that goes from the main board to the 8096 uC on the front panel board. You're replacing something after the 8096.

taemun: The original plan was to tap the data going into the VFD controller, but it turns out it uses two VFD drivers (Allegro ICs, I can't check the part number now). The display segments are divided in four groups and each group is on and refreshed one at a time (by the way, the ICs do that again for each segment in each group, even faster). I could not find a way for the PIC to keep up at that speed. Then I found the controller on the main logic board and the controller on the front panel board talk to each other using a serial protocol. The PIC decodes that and drives the OLED.

Anyone got any idea how they are encoded?  It looks like they are in the stuff to the right of 18 x 12-character bytes.

I'd suggest approaching this from the other direction. You know it is I2C and you know what the PCF8578T expects. Get a cheap 5V microcontroller like an AVR or even Arduino board and send it handcrafted data. Flip bits and see what turns on. Once you've worked out how they've mapped between bits and segments then you can decide on how to best implement this.

[Gandalf_Sr]

Thanks for all the input.  I messed around trying to map the bits in the 3 nybbles to the segments of the 14 segment characters tonight and most characters work out as expected but a few don't.  But now I have the basic 12 characters worked out, you're right, I can build a simple driver PCB and test the old display but, if I could figure out how the DPs and caption segments work, I can simply work on the characters coming from the system, parallel my system with the old display and make comparisons.

I had assumed that all of these old HP systems with the 12 segment 12-character + 12 caption displays were all using the same system but it appears that they're not.  I'll see if I can come up with a prototype system without actually designing a PCB.

Got to stop and do real work tomorrow.