Replace LCD on HP/Agilent 664XA PSUs

[Gandalf_Sr]

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 above

So the challenge is, how are the decimal points and the captions reflected in the data?

[EDIT] 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 idea
2. 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

[tsman]

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 idea

If 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 0
E0 = Device-select - Hardware subaddress 0
F0 = RAM-access - Character mode, row 0
08 = Load-X-address - Column 8

[Gandalf_Sr]

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.

[tsman]

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.

[Gandalf_Sr]

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.

The 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' character

So the only data that could represent the captions and decimal points (they must be handled separately) is the data in positions 23 - 34

[tsman]

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?

[Gandalf_Sr]

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?

I 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.