HP 3478a Display Interface - Page 1
Forum section: electronics / repair

author: metacollin
author_rank: Contributor
timestamp: November 22, 2014, 08:17:19 pm
content: I have a working, still accurate, good ol' HP 3478a that runs/ran like a champ...until it's LCD display kicked the bucket. One or both of the epoxy blob ICs are definitely fried...they can't even properly generate the AC bias to refresh the LCD, so you see one half of the screen briefly come on, fade to nothing from being DC biased too long, then another flicker of life in a second or 2. But, even what is displayed is gibberish.I found in thisthreadthat the HP 3488a is a good, cheap source of a replacement display, but where's the fun in that? What if I want to hook up a hot and power hungry VFD? Or a giant 1 foot by 16 foot LED wall display of death? Or just pipe it into a character or graphic OLED screen? What if I want the display to be....nicer!Well, that requires decoding the gibberish the CPU is using to control this unknown display controller. Unfortunately, I am not very strong when it comes to digital protocols, and don't really know what to make of this. Does anyone have any hints, ideas, possibilities, in regards to this digital capture?I've captured several seconds and display refreshes worth of bit nuggets (or whatever) using a Saleae logic analyzer. I know this kind of amounts to me asking someone to do my work for me, but I really have no clue. At least a little guidance would be helpful =). But I've attached a screen shot as well as the actual capture in both per-sample 8-bit binary and .logicdata format. I can export other formats if needed. Be warned, the .bin unzips to something like a 180MB file.I've tried using the built in analyzers to little effect. The 1 and 2 lines also have exactly the same data at all times, though 2 is delayed ever so slightly from 1. They seem to be going around 39KHz, which makes me wonder if they're 38400 Asychronous serial lines. But why 2 lines of the same information?Really, all I want is to figure out what digits/letters/segments the HP 3478a is wanting to be light up, and with that knowledge + any basic µC, a wonderland of display hacks is opened up (I mean some straight Aladdin and Jasmine 'Whole New World' magic carpet shit).if anyone recognizes or otherwise notices anything useful, I would be very much appreciative for a reply. And I'm sure this will be a helpful resource to anyone with an hp3478a =).

author: metacollin
author_rank: Contributor
timestamp: November 22, 2014, 08:21:12 pm
content: ....Unless I'm an idiot and 1 and 2 are two lines of one differential serial pair....I don't know. One starts high, the other starts low...strange.

author: MarkL
author_rank: Unknown
timestamp: November 22, 2014, 09:38:09 pm
content: You should read the Theory of Operation section on the display, section 7-F-66. It's short but describes the control signals.The display command/control protocol does not appear to be documented. If you don't have a working display you're going to find it difficult to correlate the serial stream changes to changes on the display.Another approach would be to read the displayed values via the GPIB port and use that information recreate the display, although you're not going to be able to mimic everything that's on the real display.Do you know that the problem is isolated to only the display and everything else is working perfectly? There's a lot of bias voltages being generated for the display, for example. If you haven't, I would verify every pin going to the display with what you'd expect from the schematic. And I would do it with a scope to verify the signal integrity.

author: metacollin
author_rank: Contributor
timestamp: November 22, 2014, 10:31:58 pm
content: Holy crap MarkL, that was _exaxtly_ the information I needed. I thought I had looked through the service manual sufficiently and did not find it, but obviously that was not the case. The description of the control signals is very helpful, and was the main barrier to proceeding further.Also, I am certain the problem is the display only. The bias voltages are correctly generated, I followed the service and repair procedure to diagnose a display problem.I was hoping to figure out what the control lines even were, since all I was going on were the cryptic labels in the schematic. Now I can proceed by displaying specific text over GPIB (which is working fine).I do not think reverse engineering the commands will be all that difficult. The display is refreshed at regular intervals, making a complete "clear, send data, and display" command cycle identifiable. After that, there are really only a couple of possibilities. The control chips are either little more than glorified shift registers and the state of each segment is shifted in (I've already more or less ruled that out though) or it is a driver chip with some undocumented command system that displays things via a font rom. I don't care about perfect emulation, if I can only figure out the font rom table and how it writes that to the display (my guess is it is done with a write command followed by a sequence of every digit, including blank ones, as the refresh data length seems fixed in size).The control lines or the flip flop for the display are not blown, and GPIB works, so I see little chance of the control signals being invalid or dysfunctional.

author: gadgetjunkie
author_rank: Newbie
timestamp: June 09, 2015, 11:44:42 pm
content: Did you get any further with reverse engineering the display protocol? I've been toying with the idea of writing my own code to drive the meter and display as a potential project. The display is probably the hardest nut to crack.

author: free_electron
author_rank: Super Contributor
timestamp: June 10, 2015, 12:12:03 am
content: using the gpib port you can actually display custom text on the display.sou you could make a program the shows a single 0 , then a single * and then shift that one position.that should show you where the bits for the individual segments are.these are starburst dispays with 14 segments and a semicolon separating them.most likely (my gut feeling) they transmit 16 bits per character (14 segments plus the semicolon split in comma and dot)probably a simple serial protocol.the bit layout will become clear by doing the display check using the gpib port