|
1 ========================================== |
|
2 HP 34970A Data Acquisition Unit - part 3 |
|
3 ========================================== |
|
4 |
|
5 :Author: David Douard |
|
6 :Category: Electronics |
|
7 :Tags: HP, 34970A, DMM, repair, test equipment |
|
8 :series: HP 34970A repair |
|
9 :series_index: 3 |
|
10 |
|
11 |
|
12 As explained in `the previous post in this series <{filename}/hp34970a_2.rst>`_, I've started to sniff the serial |
|
13 protocol between the main board and the display panel so I can replace |
|
14 the failed VFD by an OLED or TFT display managed by an arduino or |
|
15 similar. |
|
16 |
|
17 Protocol |
|
18 ======== |
|
19 |
|
20 The serial communication takes place at a rather unusual speed: 187.5 |
|
21 kbits/s, otherwise, a standard 8N1 scheme. |
|
22 |
|
23 The protocol consist in a transmission frame with a start of |
|
24 transmission handcheck, some commands with arguments, and an end of |
|
25 transmission packet. |
|
26 |
|
27 Each transmitted character is acknowledged by the receiver, either by |
|
28 a ``<0x99>`` (for the initial handcheck) or by a ``<0x00>`` for the |
|
29 other ones.. |
|
30 |
|
31 I've only probed the CPU->DP communications. I don't really care the |
|
32 other way fr now since I plan to keep the original 80C51 so it manages |
|
33 this protocol and handle the keyboard. |
|
34 |
|
35 In the direction CPU->DP, we can find: |
|
36 |
|
37 - ``<0x66>``: start of transmission, must be acknowledged by a |
|
38 ``<0x99>`` by the receiver; this start of transmission is then followed by a "command": |
|
39 |
|
40 - ``<CMD> <NCHAR> <CHAR1> ... <CHARN>``: the command byte is followed |
|
41 by the numer of characters sent as argument, then the characters |
|
42 themselves. |
|
43 |
|
44 - ``<0x55>``: end of transmission. |
|
45 |
|
46 |
|
47 I've only identified 2 commands for now, but these are the most |
|
48 important ones: |
|
49 |
|
50 - ``0x00``: send the chars to the main display |
|
51 - ``0x0C``: send the chars to the secondary channel display |
|
52 |
|
53 |
|
54 Quick prototype |
|
55 =============== |
|
56 |
|
57 With this very incomplete reverse ingeeniring of the communication, I |
|
58 have enough meat to try a quick prototype. |
|
59 |
|
60 I've used an Arduino Uno and a cheap 3.2" TFT color display. As I |
|
61 wanted to have my serial protocol to debug the code for the beginning, |
|
62 I've used the SoftwareSerial_ library for this prototype. |
|
63 |
|
64 The result is this beautiful clean setup: |
|
65 |
|
66 .. image:: {filename}/images/hp34970a/poc_display.jpg |
|
67 :alt: A very quick proof of concept of an arduino based display replacement for the HP34970A. |
|
68 |
|
69 |
|
70 As you can see, it works: I have the main content od the VFD display |
|
71 on my TFT module! |
|
72 |
|
73 .. image:: {filename}/images/hp34970a/poc_display_mux_off.jpg |
|
74 :alt: The FTF display showing the main area and the current channel area. |
|
75 |
|
76 .. image:: {filename}/images/hp34970a/poc_display_vdc.jpg |
|
77 :alt: The same with the channel 209 configured as VDC, 6.5digits. |
|
78 |
|
79 |
|
80 The job is far from finished however: I still have to figure out how |
|
81 the "annotation" flags are encoded and display them, and most |
|
82 importantly, I have it make it work with the hardwre USART of the |
|
83 mega328. This seems to mbe necessary because I have glitches |
|
84 sometimes. But I'm very happy it worked almost at my first try. I was |
|
85 quite surprised since the baudrate is above the maximum officially |
|
86 supported one (115200). |
|
87 |
|
88 I'll release the code of the prototype any time soon. |
|
89 |
|
90 .. _SoftwareSerial: https://www.arduino.cc/en/Reference/SoftwareSerial |