content/hp34970a_3.rst

Sun, 26 Jun 2016 01:32:13 +0200

author
David Douard <david.douard@logilab.fr>
date
Sun, 26 Jun 2016 01:32:13 +0200
changeset 63
64a7d3e2b2a8
child 64
dcb6f3fcbd1e
permissions
-rw-r--r--

[hp34970a] poc of an arduino display

==========================================
 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

mercurial