Replace LCD on HP/Agilent 664XA PSUs - Page 1
Forum section: electronics / repair

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 20, 2019, 02:44:10 pm
content: 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 displaylike 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 made4. Micro-controller code - I can write, I already have LCD driver code written5. Physical adapter design - I can design and print on 3D printerI've bought displayslike thesefrom 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 theservice manualfor 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?

author: coromonadalix
author_rank: Super Contributor
timestamp: January 20, 2019, 03:50:42 pm
content: what is the big chip markings ?its an Optrex what number ?, your finger hide a number i thinkSeems 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 ??

author: coromonadalix
author_rank: Super Contributor
timestamp: January 20, 2019, 04:06:24 pm
content: Old ebay sale at 50$ usd ??Seems to be that part numberHP/Agilent/Keysight 06624-60002 LCDOriginal pn: 5061-1190

author: tsman
author_rank: Frequent Contributor
timestamp: January 20, 2019, 04:20:25 pm
content: 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.

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 20, 2019, 04:27:31 pm
content: OK, unlesseb4eqa(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.

author: coromonadalix
author_rank: Super Contributor
timestamp: January 20, 2019, 04:28:53 pm
content: https://www.nxp.com/docs/en/data-sheet/PCF8578.pdfits an i2c interface displaythe 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 protocolshere is github infos :https://github.com/openscopeproject/HP34401a-OLED-FW

author: tsman
author_rank: Frequent Contributor
timestamp: January 20, 2019, 05:14:20 pm
content: 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.

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 20, 2019, 05:21:47 pm
content: tsmanis 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. I might be moving faster on this if water hadn't started to drip in my basement! Bugger!

author: coromonadalix
author_rank: Super Contributor
timestamp: January 20, 2019, 05:25:19 pm
content: 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 ...

author: tsman
author_rank: Frequent Contributor
timestamp: January 20, 2019, 05:32:08 pm
content: Quote from: Gandalf_Sr on January 20, 2019, 05:21:47 pmPCF8578T 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.

author: coromonadalix
author_rank: Super Contributor
timestamp: January 20, 2019, 05:38:35 pm
content: oh forgot thatyeah spi is not i2c loll vice versaSurely on the web must be some code snipetsmaybe with translation :https://www.roboternetz.de/community/threads/15812-Hilfe%21Fur-LCD-display-mit-PCF8578Tyou have lots of i2c arduinos lcd projects, maybe could wire some i2c decoderyou have the serial port to help debugging ??AdressesHex 50 - 5EHex 60 - 6EHex 70 - 7EPCF8576 PCF8576 PCF8577 PCF8577A PCF8578 PCF8578 PCF8566 PCF8566SAA1064 SAA1064 SAA1064 SAA1064 PCF8579 PCF8579PCF8574A PCF8574A PCF8574A PCF8574A PCF8574A PCF8574A PCF8574A PCF8574AAnd some infos :http://micro.et-inf.fho-emden.de/data/i2c/i2c_faq.txt

author: tsman
author_rank: Frequent Contributor
timestamp: January 20, 2019, 05:57:06 pm
content: 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:1 2 3.3VHO(2) 3 4 2.2VHO(3) 5 6 1.1V7 8 GNDP1.6 9 10 C2 capacitorP1.7 11 12HO(1) 13 14HO(0) 15 16 5VCode:(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)

author: coromonadalix
author_rank: Super Contributor
timestamp: January 20, 2019, 05:59:36 pm
content: got me on that one TSMAN i was searching for it lollCan you see something between the lcd and the pcb if the gray connector is soldered or just snapped in the thru holes ?

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 20, 2019, 06:01:15 pm
content: OK, you're righttsman, I2C, not SPI. So the github stuff is no goodI'll change previous postI have a bucket under the drip and most stuff that could be damaged picked up!

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 21, 2019, 11:18:13 am
content: 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

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 21, 2019, 11:27:53 am
content: 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 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 = 4000000Config Sda = Portd.4Config Scl = Portd.5I2cinitConst Disp = $ 78 'PCF8578 Adr'----------------- Display Initialization ----------------------------- ----------I2cstart 'StartI2cwbyte Disp' send slave address PCF8578I2cwbyte $ d9 'Write Set Mode: Mixed Mode, all segments on, 1: 8MuxI2cstop' StopWait 1 '1 second waitI2cstart' StartI2cwbyte Disp 'send slave address PCF8578I2cwbyte $ d5' Write Set Mode: Mixed Mode, normal, 1: 8MuxI2cwbyte $ e0 'Device Select Addr 0000 only if multiple PCF8578I2cwbyte $ 88' X Address = 8I2cwbyte $ 70 'Ram Access: Character, Ram Bank 0I2cstop' Init done'--------------------------------- ----------------------------------------------'This Must Turn on All Segments on the Display for 1s' look Datasheet73 DE ArthurLooks 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

author: Le_Bassiste
author_rank: Frequent Contributor
timestamp: January 21, 2019, 02:27:31 pm
content: 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)

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 21, 2019, 02:29:40 pm
content: 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 inthis post here.

author: Le_Bassiste
author_rank: Frequent Contributor
timestamp: January 21, 2019, 02:33:41 pm
content: 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.

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 21, 2019, 02:34:43 pm
content: 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 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 1and7 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 everywhereBWAHAHAHAHAHAHAHA!!!

author: Le_Bassiste
author_rank: Frequent Contributor
timestamp: January 21, 2019, 04:47:25 pm
content: (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...)

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 21, 2019, 08:31:19 pm
content: 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 show14 segment display driver fontsbut 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.

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 21, 2019, 10:09:36 pm
content: 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.

author: tsman
author_rank: Frequent Contributor
timestamp: January 21, 2019, 11:45:46 pm
content: Quote from: Gandalf_Sr on January 21, 2019, 10:09:36 pmEB4EQA'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.Quote from: eb4eqa on September 01, 2015, 07:48:38 amQuote from: Gandalf_Sr on January 21, 2019, 10:09:36 pmI'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.

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 22, 2019, 01:16:42 am
content: 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.

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 24, 2019, 02:54:57 pm
content: I'm still struggling to understand how the captions and decimal points are driven. If you look at the attached extract of a 3-line spreadsheet based off my own bus sniffing, you will see stuff like _0.00V__-0.00A( those underscores are spaces), I recorded this while pressing a supply select button on my 6623A power supply which only changes the following..From line 1 to 2, only the caption changes from position 1 to 2 (5 is on in both cases)From line 2 to3 the caption changes from position 2 to 3 (5 is on in both cases) plus the second set of numbers gains a digit - there's one less space in the middle - and the decimal point moves from position 9 to 8.The blue/white background area explains all the digits and I've highlighted in red the numbers that changed with respect to the line immediately aboveSo the challenge is, how are the decimal points and the captions reflected in the data? I have a few ideas:1. There's a binary representation that corresponds bit-for-LCD segment but this doesn't appear to work at all amd I've given up on this idea2. Just like a sequence of nybbles turns on a specific set of LCD segments (from a set of 12) for a specific character, the system might treat the 12 segments of captions and 12 decimal points as two more characters and a sequence of 3 nybbles may control what captions and what decimal places are on - this is my current theory that I haven't proved yet

author: tsman
author_rank: Frequent Contributor
timestamp: January 24, 2019, 08:36:22 pm
content: Quote from: Gandalf_Sr on January 24, 2019, 02:54:57 pmIf you're directly talking to a PCF8578 then it should be this. Each bit in its internal memory is mapped to a LCD segment. You don't need to send the entire RAM contents each time though so you can jump to specific sections of RAM and skip parts that haven't changed. Your dump has everything merged into one long sequence so it is difficult to determine what are commands and what is data.First 5 bytes are a valid initialisation sequence for the PCF8578. Columns 0 to 7 are mentioned in the datasheet as being scratchpad RAM so setting it to 8 would be correct.D5 = Set-mode - Mixed mode, normal, 1:8 mux (8 rows)FC = Set-start-bank - Bank 0E0 = Device-select - Hardware subaddress 0F0 = RAM-access - Character mode, row 008 = Load-X-address - Column 8

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 24, 2019, 09:30:32 pm
content: Thanks, I've updated my spreadsheet slightly (see attached file) to include the binary representation to the right with bits that have changed from the row above highlighted in red.If you're right that each bit goes to a segment then the bits I've highlighted in red may well match 1-1 with captions and DPs, I'll do some more experimentation.

author: tsman
author_rank: Frequent Contributor
timestamp: January 24, 2019, 10:06:43 pm
content: I tried determining what the bits are for the annunciators but it doesn't make much sense. I think you need more dumps and to save where the transactions start/stop so you can determine where the commands and data are. Those EE 7x 22 sequences would be it switching into half graphic mode, selecting two different rows and then writing 0x22 to that location if they're interpreted as commands.

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 25, 2019, 02:52:35 pm
content: Quote from: tsman on January 24, 2019, 10:06:43 pmThe data in positions 0-4 is some kind of setup as you've said; the data in positions 5-22 is already decoded....00 40 00 77 22 EE 77 22 EE 77 22 EE 76 22 E0 70 40 60 represents the display ' 0.00V-0.000A' with captions in display character 3 & 5 on (which I've shown here using underline)Each set of 3 bytes contains data for 2 characters so 00 40 00 represents chars in display character positions 1 and 7 (note I don't count DPs as taking a display character position of their own although they have to in these posts), the low nybbles of 0x000 (from 0x004000) represents a space character and the high nybbles of 0x040 (from 0x004000) are a '-' character. You can see in the pattern that 0x72E is a '0' characterSo the only data that could represent the captions and decimal points (they must be handled separately) is the data in positions 23 - 34

author: tsman
author_rank: Frequent Contributor
timestamp: January 25, 2019, 03:06:00 pm
content: Ahh okay. Hmm. If they're just one long single I2C transaction then it is rewriting the whole of the internal RAM each time. Puzzling then how the annunciators work. Only 1 bit moves between example 1 and 2 which would imply those positions are annunciator 1 + 2 but example 3 still has what is presumably annunciator 2 still set.Can you do some more dumps?

author: Gandalf_Sr
author_rank: Super Contributor
timestamp: January 25, 2019, 03:43:25 pm
content: Quote from: tsman on January 25, 2019, 03:06:00 pmI can do more dumps but not immediately - what if it were inverse logic? Would that allow the bit-per-LCD segment rule to work? I have a bit more data that I've added here but I'm a bit confused as to why I get 2 lines of data for what appears to be the same display with slight differences between the 2 - so treat these extra lines as less reliable. Also 'PON' is not what was on the display, it means 'power on' and all the segments were lit up as it went through that. I actually have a video that covers this sequence. I'll try re-recording the data and see if I get the same.