Mercurial > whatever / changeset

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/content/hp34970a_3.rst	Sun Jun 26 01:32:13 2016 +0200
@@ -0,0 +1,90 @@
+==========================================
+ HP 34970A Data Acquisition Unit - part 3
+==========================================
+
+:Author: David Douard
+:Category: Electronics
+:Tags: HP, 34970A, DMM, repair, test equipment
+:series: HP 34970A repair
+:series_index: 3
+
+
+As explained in `the previous post in this series <{filename}/hp34970a_2.rst>`_, I've started to sniff the serial
+protocol between the main board and the display panel so I can replace
+the failed VFD by an OLED or TFT display managed by an arduino or
+similar.
+
+Protocol
+========
+
+The serial communication takes place at a rather unusual speed: 187.5
+kbits/s, otherwise, a standard 8N1 scheme.
+
+The protocol consist in a transmission frame with a start of
+transmission handcheck, some commands with arguments, and an end of
+transmission packet.
+
+Each transmitted character is acknowledged by the receiver, either by
+a ``<0x99>`` (for the initial handcheck) or by a ``<0x00>`` for the
+other ones..
+
+I've only probed the CPU->DP communications. I don't really care the
+other way fr now since I plan to keep the original 80C51 so it manages
+this protocol and handle the keyboard.
+
+In the direction CPU->DP, we can find:
+
+- ``<0x66>``: start of transmission, must be acknowledged by a
+  ``<0x99>`` by the receiver; this start of transmission is then followed by a "command":
+
+- ``<CMD> <NCHAR> <CHAR1> ... <CHARN>``: the command byte is followed
+  by the numer of characters sent as argument, then the characters
+  themselves.
+
+- ``<0x55>``: end of transmission.
+
+
+I've only identified 2 commands for now, but these are the most
+important ones:
+
+- ``0x00``: send the chars to the main display
+- ``0x0C``: send the chars to the secondary channel display
+
+  
+Quick prototype
+===============
+
+With this very incomplete reverse ingeeniring of the communication, I
+have enough meat to try a quick prototype.
+
+I've used an Arduino Uno and a cheap 3.2" TFT color display. As I
+wanted to have my serial protocol to debug the code for the beginning,
+I've used the SoftwareSerial_ library for this prototype.
+
+The result is this beautiful clean setup:
+
+.. image:: {filename}/images/hp34970a/poc_display.jpg
+   :alt: A very quick proof of concept of an arduino based display replacement for the HP34970A.
+
+
+As you can see, it works: I have the main content od the VFD display
+on my TFT module!
+
+.. image:: {filename}/images/hp34970a/poc_display_mux_off.jpg
+   :alt: The FTF display showing the main area and the current channel area.
+	 
+.. image:: {filename}/images/hp34970a/poc_display_vdc.jpg
+   :alt: The same with the channel 209 configured as VDC, 6.5digits.
+
+
+The job is far from finished however: I still have to figure out how
+the "annotation" flags are encoded and display them, and most
+importantly, I have it make it work with the hardwre USART of the
+mega328. This seems to mbe necessary because I have glitches
+sometimes. But I'm very happy it worked almost at my first try. I was
+quite surprised since the baudrate is above the maximum officially
+supported one (115200).
+
+I'll release the code of the prototype any time soon. 
+	 
+.. _SoftwareSerial: https://www.arduino.cc/en/Reference/SoftwareSerial

Binary file content/images/hp34970a/poc_display.jpg has changed

Binary file content/images/hp34970a/poc_display_mux_off.jpg has changed

Binary file content/images/hp34970a/poc_display_vdc.jpg has changed