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