content/hp34970a_3.rst

changeset 63
64a7d3e2b2a8
child 64
dcb6f3fcbd1e
equal deleted inserted replaced
60:3f87af862c60 63:64a7d3e2b2a8
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

mercurial