Fluke8840A IEEE-488 redesign (Ethernet replacement for GPIB Option -05)

[Burner_357]

Hello Forum,

long story short: the Zilog Z8 Out-Guard controller of one of my Fluke8840A GPIB-cards died.
short story long: why replacing the controller when you can replace the whole GPIB-thingy with something useful, like ethernet.

So I startet digging around in my second (and working) unit and found out, the Out-Guard Z8 (U901) translates the GPIB-data into UART to communicate with the In-Guard controller (U202) with 62,5kBaud, 8 data-bits, no parity-bit.
Unfortunately the protocol for the UART communication is not straight forward. 


What I found out by now:

1. As some sort of error detection mechanism the listening controller repeats the recieved message on the UART back to the talker.

2. "get requests" are transmitted as 2 bytes (for example "G3" seems to be 0x46 and 0x40 as in attached image "G3_GPIB_UART")

3. when transmitting the user defined message (requested with "G3") from the IG-controller to the OG-controller the ASCII-characters are split in their high and low nibbles and sent in two seperate UART-frames. In my example (see images "G3_GPIB_UART" and "G3_GPIB_UART_2") the text "HELLO123" is the user defined message. The IG-controller begins the transmission with 0xEA, maybe some satus-info or "frame-start-byte".
Then the first 4 Bytes of the 16-byte message-data follows:
0xA4 0xA8 => combine the low nibbles to 0x48 and you get the ASCII-code for "H"
0xA4 0x25 => combine the low nibbles to 0x45 and you get the ASCII-code for "E"
0xA4 0x2C => combine the low nibbles to 0x4C and you get the ASCII-code for "L"
0xA4 0x2C => combine the low nibbles to 0x4C and you get the ASCII-code for "L"
Then the 0xE0 ends the frame and 0xEA starts the next one:
0xA4 0x2F => combine the low nibbles to 0x4F and you get the ASCII-code for "O"
0x23 0xA1 => combine the low nibbles to 0x31 and you get the ASCII-code for "1"
0x23 0xA2 => combine the low nibbles to 0x32 and you get the ASCII-code for "2"
0x23 0xA3 => combine the low nibbles to 0x33 and you get the ASCII-code for "3"
Then the 0xE0 ends the frame again.
The next two Frames are filled with:
0xA2 0x20 => combine the low nibbles to 0x20 and you get the ASCII-code for " " (space)
to fill up the unused bytes of the 16 byte user defined message.

4. the measured values are transmitted cyclicly (depending on the sample rate)
the transmission seems to start with 0x61, 0xE0 and then 0x67.
Then the value is transmitted (similarly to the user definded message) as the low-nibble of the frame. But the numbers are send directly, not as ASCII-code.
This can be seen in the "9V" and "11V" images, where the meter measures 9V and 11V respectively. When the GPIB-Output (the "9V_2" and "11V_2" images) is compared to the UART-frames it is clear, where the numbers are transmitted, but I couldn't figure out where the sign, the position of the decimal point and the exponent are transmitted.


What I couldn't find out by now:

1. is there a correlation between the get- and set-commands (G0-G8, F1-F6, R0-R7......etc.) and the 2-byte UART-data sent to the IG-controller?
2. how are the sign, the position of the decimal point and the exponent transmitted in the data?
3. what do the start-bytes and stop-bytes correlate to?
4. why are the high-nibbles of the transmitted user defined message and the measured values kind of randomly change from "A" to "2"?
5. all the other stuff I didn't see by now, or haven't tried yet...


Another approach of reverse engineering the protocol was looking at the code of the Out-Guard controller U901:
I found a ROM-binary of the controller online and was able to disassemble it. But this path quickly lead to a dead end because of my lack of assembly language skills in general and my lack of Zilog Z8 assembly knowledge in particular.

I was able to figure out the configurations of the special function registers and understood that "sub_575" (see the attached assembly code of the OG-controller) is a delay-loop.
But when it comes to "ld @R0, R0" and stack-pointer manipulations like "inc spl" and "inc sph" I have no idea what's happening there. 


At this point, I think I need the cumulated powers of the EEVBlog-forum. Maybe I can find someone in here who has:
(in order from "kinda guessing what the OG-controller does" to "exactly knowing what the OG-controller does")

1. brilliant ideas on the used protocol (by looking at more grabbed data while throwing commands at the meter)
2. reading the disassembled ROM binary like a book
3. having worked (or still working) at Fluke and having access to the specifications of the OG-controller and the UART protocol.


I hope I can find enough support to massively upvalue these old, but reliable meters, by adding the capability to use a modern communication interface (USB, Ethernet, whatever).
Once the specifications of the protocol are clear, everything is possible


Burner_357

[lordium]

just had a quick look, and I think it is 1 start, 7 bit, and parity.

0xA4 0 0010010 1   0x24
0xA8 0 0001010 1   0x28
0x25 0 1010010 0   0x25
0x2C 0 0011010 0   0x2C
0xEA 0 0101011 1   0x6A
0xE0 0 0000011 1   0x60
0x46 0 0110001 0   0x46
0x40 0 0000001 0   0x40

the higher nibble is destination maybe? (0x2 to gpib for example) and lower the data, this seems to fit you data.
if you keep throwing data at it with known functions it should be more clear on where it goes and what it means.
to find which means + or - for example input positive and negative same value (switch leads) and look for the difference in data.

[wizard69]

Sorry I don't have one of these meters so I can't help much.   However I was surprised to find Zilog is still in business as I've heard nothing from them in years.

As for protocols the only thing I can suggest here is to look up a manual for the meter and digest as much info as they have for what the unit was capable of with the 488 option.   Putting the 488 interface into talk only mode might be revealing also.   I can't imagine that stuff is significantly different than what the old Fluke Basic code would be sending the 488 interface.   That is there might be some light translation going on but that I'd expect most commands to make it across the interface unmolested.

As for your thoughts on an Ethernet interface, yeah that could be a great product to have, putting these old meter back to work.   Such a board likely would not be a big money maker but it might make buying one of these old Flukes worthwhile to some of us.

[wizard69]

By the way I looked at this data for several minutes and couldn't come up with anything that made sense!    At first I thought ASCII data but that didn't seem to add up.   I couldn't get BCD to fit either.   This has me wondering if the scope is displaying the data correctly.   Is it making the right assumptions on parity and so forth?

One thing worth trying is to send it a well defined command.    If I remember correctly G8 should query for the devices model number and should return 8840A.   I would hope that it comes back as ASCII data and thus helps with verification of what you are seeing on the scope.

[softfoot]

Has there been any progress on this topic - I'm looking for a replacement for my 8840A
Dave

[Burner_357]

Has this project made progress...good question.
Let's say: yes and no 

I've built a replacement board for the original GPIB-board, that fits the original outline and uses the GPIB-cutout at the rear of the instrument for the ethernet connector.
It uses a W5500 board to handle the ethernet stuff.
In the schematic, I tried to stay as close to the original schematic as possible, while making use of the components I had at hand.
That led to some weird component selections. So no comments needed on that aspect, I'm aware of the mess 

I also started reverse engineering the internal protocol between the main controller and the controller of the GPIB-card.
So far, I'm pretty confident that the following parts of the protocol (getting info from the device) are correctly decoded:
- displayed measurement value (sign, value, range, function)
- readout some settings (sample-rate, off-set, auto-range, F/R-input, ext-trigger)
- internal trigger event

I also have decoded some of the "set parameters of the device" part of the protocol.
But they are not tested yet.
- set the "Listen", "Talk", "Remote" LEDs in the front-panel
- request the current configuration (data for "G0" and "G5" requests)
- set the current configuration (F, R, S, T, D, B)

I haven't poked around with the calibration procedure. I don't want to lose/brick the cal-data.
And there are still many gaps in the understanding of some parts of the protocol. Especially error handling and error-code transmission.

In general, I was only listening to the original "conversation" in a working unit and used my replacement board as a sniffer to decode the protocol.
I haven't tried to "talk" actively to replace the original board.

I've attached some details of the project below:
- Schematic and PCB overview
- Pictures of the actual board
- info to the W5500 ethernet module
- the parts of the protocol I've decoded by now (yellow highlighted parts contain open questions and unverified info)


greetings, Alex

[xerbo]

I've been following this topic for a while, haven't been able to get a hold of an actual GPIB board so nice to see good progress has been made.

Although looking at the the schematic the use of isolation to the W5500 seems slightly unnecessary since ethernet is already an isolated interface (apart from shield, but the connector breaks out chassis ground so that's not a problem).

[xerbo]

The past couple of days I've been working on my own version of this, it uses an ESP32 (currently connected over WiFi). Got it to the point where I have a basic display only interface (readings are sent over websockets).

[xerbo]

Here it is speaking SCPI (emulating a 34405A) with Sigrok/SmuView. Code should be up on GitHub in a few days.

EDIT: as promised https://github.com/Xerbo/8840a_io_card, keep in mind this is still very very very WIP.

[coromonadalix]

hi   will the model / equipment like  34405 meter  in a definition file / config text file   ??

Have a basis to control other meters, i have an L4411A  coming soon and want to have some kind of an interface to control it from some distance

You don't need the i/o librairies or other drivers  do you ??



thks for your good work   

[xerbo]

The meter definitions are in https://github.com/sigrokproject/libsigrok/blob/master/src/hardware/scpi-dmm/api.c, changing/adding definitions will involve a (re)compiling libsigrok. Weather or not drivers are needed depends on the interface used, the L4411A has ethernet and can talk over TCP, which doesn't require drivers.

[softfoot]

Alex, that's pretty impressive :-) can't wait to get my hands on one.
Dave

[softfoot]

Hi,
Just checking ... has any version been finalized (499, ethernet, wifi, etc).
I need to start logging data from a DVM for a project and I'd preferto do it on my 8840A
rather than buying another meter.
I'm still looking for an original 488 card but they are unobtainium :-(
Dave

[alm]

I have an original Fluke 8840A IEEE-488 module I'm willing to sell. DM me if you're interested.

[softfoot]

Is this still available ??   If so how much ??
and where are you ??  I'm in the UK so shipping will be a deterrent from the US.
Dave

[alm]

Is this still available ??   If so how much ??
and where are you ??  I'm in the UK so shipping will be a deterrent from the US.

Yes, it's still available. Like I wrote, send me a DM if you're interested and I can send you some pictures, shipping quotes, etc. That's off topic for this thread.