There was a discussion a couple months ago in the Metrology section about the 3456A actually measures 7.5 digits but only outputs 6.5. So how can you get that extra digit? Not knowing any better, I thought "How hard can it be?"
Here's the result. The exponent digit has been hijacked to display the extra digit:
And, on startup:
Just to let you know you don't just have an ordinary 3456A...
The
attached zip file has the details. It contains:
- HP3456A_Firmware_Notes.docx, with details of the relevant code changes and resources
- u7.bin, the original firmware image
- u7.sym, the symbol file for the disassembler
- u7disassembled.asm, the original firmware disassembled
- u7commented.asm, the firmware with comments added and a lot of unnecessary jumps and branches removed
- u7modded.asm, above with modifications for 7.5 digit output
- u7modded.bin, assembled version of the above
The Outguard microprocessor does most of the work and is a Motorola 68A00, a 1.5 MHz version of the 6800. The firmware is about 22KB of code and 2KB of data. The code certainly appears to be the output of a compiler, and in the day HP had the 64000 Logic Development System that had available Pascal and C compilers for the 6800. I took out right about 1000 bytes of unnecessary jumps and branches in an attempt to untangle the code and make it more readable. I broke something in the Auto Range that causes the display to freeze under certain conditions. Not much other testing has been done, so there could be other problems.
The Inguard and Outguard processors communicate through two, one-way serial links. Here's a breakdown:
The Outgard sets the measurement mode by sending four bytes to the Inguard. It looks like these bytes provide low-level details to the Inguard such as FET switch settings and such, but I haven't decoded those commands.
To replace the firmware I used a SST39SF010A 128Kx8 flash ROM. It's four times the needed capacity, but the smallest 5V DIP that Digikey stocks. I did an adaptor board that's a little different than solutions I've seen elsewhere:
Most of the signals are taken directly from the unstuffed U2 position. A12,13,14 are taken from jumper positions 6,4,8, respectively. The ROM Select signal is taken from pin4 of U6. On this adapter, A15 and A16 are tied to ground, but I realized later that a switch could be added to +5V, both original and modified firmware could be put in the ROM, selectable by the switch position. When trying code modifications there was often the question of whether the meter was acting normally. Flipping a switch would have saved time over switching ROMs.
Here's the results from letting it run overnight measuring a lithium coin cell. Readings were taken at about 10 second intervals. Temperature came from a LM35 placed on the bench under the 3456A, read by another meter.
I have no idea what happened in the middle of the night. Air Conditioning was off, there are no other fans running, nothing else was powered. My best guess is something suddenly caused the 3456A to emit less heat. It's a unit I bought non-functioning, so it very well could have other problems to sort out.
Anyway, here's the middle data on an expanded scale:
Set to 10 PLC integration, here are the results from 1000 consecutive readings:
This particular meter is moving around quite a bit, so it will take some more work to figure out if this extra digit provides any additional information. This scatter does look promising, though.
I've got a bunch of other things on the To Do list that need to be done before I can descend into volt-nuttery, so though I'd put this out in case anyone else needs some "fun".
One idea I'm wondering about is if the 3458A's multislope ADC algorithm is different than the 3456A's. There will be differences in the analog circuitry, but we now have the potential to change the operation of the digital control.
Tim