reverse ingeeniring hp 34xxx display panel serial protocol

[douardda]

Hi,

having a mostly dead display on my hp 34970a data acquisition unit (which I talk about here https://www.eevblog.com/forum/repair/agilent-34970a-battery-replacement-and-repair/msg953988/#msg953988 and on my blog https://whatever.sdfa3.org/hp-34970a-data-acquisition-unit.html), I've decided (unless I find some simpler solution) to replace the original VFD display by some OLED display controlled by a microcontroller.

My first idea was to read the data from the port 1 of the 80C51 on the display panel board. This port is used to control  the VFD drivers, which are simple 32 bits shift registers. But  the microcontroller seems to have suffered and some of the ouputs of this port 1 look dead (P1.0 aka SEGEN_N and P1.3 aka SEGDATA). I could have lived without SEGGEN_N, but SEGDATA is a bit more problematic.

So now I'm considering to make my arduino probe the serial communication between the display panel and the main board. For now, I want to try to keep the original 80C51 since it still handle the keyboard properly, and most importantly the communication with the main board.

So I wonder if anyone already have done the required reverse engineering on this bus.  It does not look very complicated, but hey. 

In the service manual it's briefly described as a 187500 b/s serial communication with 1 stop bit. It's also described as a 9 data bits but from my tests it looks like a normal 8 bits payload (plus 1 start bit and 1 stop bit).

So if anyone already has done this job on a similar unit (I guess all HP test gears from this generation use the same protocol), I'm very interested.

Otherwise, I'll publish my experiments (on my blog and here).


David

[douardda]

Just a quick note on a few elements of the protocol I've gathered so far:

- a communication starts with a 0x66 and is acknowledged by a 0x99
- a communication ends with a (unacknowledged) 0x55
- every sent character is aknowledged by a 0x00
- after the "start of communication" handcheck, a command byte is sent
- the command 0x00 is used by the main board to send text to display. It's followed by the number of chars to display, then the characters
- the command 0x0C is used to send characters in the channel digits area (the process to write text on the main display (number of chars then the character).

David

[bingo600]

Interesting

Someone did it for a 6632B , told about it , but kept it Closed Source 
https://www.eevblog.com/forum/buysellwanted/hp-6632b-power-supply-replacement-oled-screen-(done)/

Thanx for not doing that.

/Bingo

[douardda]

Interesting

Someone did it for a 6632B , told about it , but kept it Closed Source 
https://www.eevblog.com/forum/buysellwanted/hp-6632b-power-supply-replacement-oled-screen-(done)/

Thanx for not doing that.

/Bingo

Not a chance, I'm a FOSS nut, I only use FOSS software, I only write FOSS software, be it for my personal or professional use  :-)

I've used sigrok to probe and decode the serial packets, and I'm trying to write a backend for hp34970a for it (but my C is very rusty so I'm dawn slow on this side project).   

About this VFD replacement project, I was thinking that, if I'm going all the way through, some guys might be interested if I make a small PCB. If there are some interest here, I might bother to design and order such a board. If I'm the only one interested, I'll probably be content with a breadboard prototype.

But I need to show a working minimal viable product, as we say in our jargon :-)

I think with the portion of the protocol I've already decoded, I have enough meat to make such a proto with an arduino (not sure whether its UART supports 187500bauds, need to check that).


David

[Kleinstein]

For the odd 187500 Baud rate the arduino might need a suitable crystal (e.g. a multiple of 3 MHz) otherwise the UART inside an AVR is fast enough. At the higher rates the divider is just limited to a few values, so that one might need a suitable clock.

[douardda]

First victory tonight:


I have a working prototype of an arduino sniffing the serial bus between the CPU and the DP, and displaying the data on a small TFT module.




I still need to understand how the indicators are handled, but I'm pretty happy so far. For now, my proto uses the SoftwareSerial lib (I wanted my hw serial connection for debugging purpose), but I'll try using the USART next time. I did not have to change the chrystal. However, with the SoftwareSerial, I have a few glitches.

We'll see how it behaves with the hw USART of the mega328.

David

[ManateeMafia]

Great job !

[mrjoda]

excellent work.  Dont give up, it could help lot of people.

[bitseeker]

Great start, David! Excited to see this come together. Thanks for diving in and for sharing.

I wonder how similar it'll be between your 34970A and devices such as the 34401A, 34410A, 33120A, E363xA, E364xA, etc. Although the 34401A has replacement displays available from China, other devices aren't as fortunate.

[mikeselectricstuff]

For the odd 187500 Baud rate the arduino might need a suitable crystal (e.g. a multiple of 3 MHz) otherwise the UART inside an AVR is fast enough. At the higher rates the divider is just limited to a few values, so that one might need a suitable clock.

187500x16=3MHz, so 6 or 12MHz would be ideal, the latter probably  more common value

[douardda]

Not a surprise then that the 87C51 runs at 12Mhz .

With my Arduino Uno running at 16MHz, I can make it work (either with the SoftwareSerial or the hardware serial), but there are always glitches and decoding errors.

I've tried to tune "by hand" the timings using a modified version of the SoftwareSerial library, but it's not  easy since at this communication speed, every "debug" statement added (eg. pulse a pin) changes substentially the timings.

I've ordered a NUCLEO F031K6 to see if I get better results (since it runs at 48MHz, ie. 256x187500, the baud rate).

I've updated a bit my blog post on the reverse engineering of the protocol since I have identified a few indicator flags, like VIEW, MON, 4W.

David

[mikeselectricstuff]

Not a surprise then that the 87C51 runs at 12Mhz .

With my Arduino Uno running at 16MHz, I can make it work (either with the SoftwareSerial or the hardware serial), but there are always glitches and decoding errors.

Or just change the crystal on the Arduino

[douardda]

Or just change the crystal on the Arduino

Sure, but:

- I want to play with Nucleo boards (which I don't know yet),
- I need a small form factor board so I have change to fit it in the the front -panel assembly
  (I only have a pair of Uno R3), so I had to buy a new "tiny" board what so ever for my prototype,
- I was a bit worried that changing the crystal might have side effect when using the arduino soft stack.

David

[Kleinstein]

Changing the clock will change all the timings, unless you let the software know the actual clock. The other hardware / software should have no problem with a lower clock, though there is a slight chance to get rounding errors with some timings.
Soft UART can be more flexible with the baud rate, but 187500 baud is already quite fast for a software UART, so it can get tricky if much other things have to be done and it is often also more sensitive to noise on the lines.

The nucleo board might be a good option if your program get rather long. The ARM's often have fractional  dividers for the UART, so they usually don't need an special clock matching the baud rate. So no real need for a multiple of 3 MHz. The multiples of 12 MHz are preferred for USB.

[douardda]

Hi,

I've made some progress recently (after a long pause). I'm now using a Nucleo F446RE board, and I've bought a 3.2" blue OLED display.



Here is a blog entry on my latest work:

    https://whatever.sdfa3.org/hp-34970a-data-acquisition-unit-part-4.html

I have also written a dedicated page on the communication protocol between the CPU and the DP:

   https://whatever.sdfa3.org/hp-34970a-data-acquisition-unit-communication-protocol.html

I'm beginning to have something. The display is not responsive enough for now  (as I explain in my blog, I send the whole display content each time something changes), and I still have bugs and flag values I have not identified yet, but, it begins to looks quite fine IMHO, and I don't miss bytes from the serial line any more: I've reimplemented the serial "sniffing" code using asynchronous (interrupt based) code, and I now listen both the Rx and the Tx wires, otherwise I cannot be sure of what I read on the serial Rx line. Also, thanks to the RTOS that comes with the mbed platform, I've put the routine that send the "framebuffer" content to the OLED module in a dedicated thread.   


I hope to be able to publish my code soon.



David

 

[bitseeker]

Excellent progress, David. Glad to see your project is proving to be a viable solution.

[douardda]

quick note here. At last I gave this repair project a bit of attention lately, and designed the replacement front panel:



The PCB fits just right in the front panel enclosure:



And after a bit of fight (and despite a few mistakes I made in this design), it begins to work:



https://peertube.social/videos/watch/172bf449-eba7-4429-8840-ab9b2d5398f8

See my latest blog post for a more detailed description of the process:

  https://whatever.sdfa3.org/hp-34970a-data-acquisition-unit-part-5.html

For those interested, I think I have the communication protocol mostly complete now:

  https://whatever.sdfa3.org/hp-34970a-data-acquisition-unit-communication-protocol.html

Cheers,
David

[bitseeker]

I missed this update earlier. Nicely done, douardda!