HP 3456A 7th digit

[cellularmitosis]

In kj7e's 3456A thread, AG7CK mentioned that the manual appears to indicate that in 10 PLC mode, the ADC is producing a 7th digit during the last part of the multi-slope run-down, but the meter rounds this off and only displays 6 digits.  https://www.eevblog.com/forum/testgear/fluke-8505a-vs-hp-3456a/msg1479347/#msg1479347

(Rather than replying to his thread in the testgear section, I thought I'd post in the metrology section for better volt-nut visibility).

It turns out you can pull this 7th digit out, and you don't even need a soldering iron to do it!   

This meter is split into an "inguard" and "outguard" (simply put, the ADC and the controlling processor), and the two halves communicate using a serial binary protocol over two isolation transformers (one for each communication direction).

All you have to do is wrap a turn of wire around the T2 transformer and you can spy on the ADC's output, and bingo -- 7th digit!

In fact, if you wanted to make a custom controller / interface / display for this meter, it should be as simple as disconnecting the outguard and coming up with your own little controller board with two signal transformers (disclaimer: I haven't tried this yet).  Might be a fun project to make a jumbo display, implement your own math functions, add a serial port, or add an SD card slot which logs to a CSV file!

(Now I'm curious if the same hack can be applied to the 3455A...  )

Details to follow...

Edit: fixing photo rotation 

[cellularmitosis]

Setup:

Take a clip-lead, cut and strip it at about 3/4 of its length.  Find the T2 transformer and make one complete turn around it.  Twist the severed part back together, and clip the lead to your oscilloscope probe.

One turn will produce about +/- 1V output.

[cellularmitosis]

Messages are 5 bytes.  Byte 2 starts 1.36ms after start of byte 1.  Bytes 2 - 5 are more closely spaces, starting on 75us intervals.

Each "byte" is actually 9 bits.  The manual states that the leading bit is always a 1.  However, I found the numbers easier to interpret if I swaped the leads the other way around, so that the leading bit was always a 0.

Settings: DCV, rear input, 6 stored in N DIG DISP, range fixed at 10v

It appears that the byte layout is as follows:

Code: [Select]

Byte 1 of 5
Indicates sign

0 1111 1111 = negative
0 0110 0110 = positive

Using an MV106 (yes I've been going a bit crazy on ebay lately  ), I was able to work out the rest of the bytes.  Here are some measurements and the resulting bit pattern:

Code: [Select]

Byte 2 of 5
First nibble is 10v
Second nibble is 1V
0: 0 0110 0110
1: 0 0110 0111
2: 0 0110 1000
3: 0 0110 1001
4: 0 0110 1010
...
9: 0 0110 1111
10: 0 0111 0110
-0: 0 1111 1111
-1: 0 1111 1110
-2: 0 1111 1101
...
-8: 0 1111 0111
-9: 0 1111 0110
-10: 0 1110 1111

Byte 3 of 5
First nibble is 100mv
second nibble is 10mv
10.00: 0 0110 0110
10.01: 0 0110 0111
10.11: 0 0111 0111
10.22: 0 1000 1000
-10.00: 0 1111 1111
-10.11: 0 1110 1110

Byte 4 of 5
First nibble is 1mv
Second nibble is 100uv

Byte 5 of 5
First nibble is 10uV
Second nibble is 1uV


[kj7e]

When did you pick up a 3456A?  Nice work by the way!

[cellularmitosis]

It just came in on friday.  At $94 shipped I just couldn't resist 

[e61_phil]

Great job!

With this extra digit it would be really interesting to compare the linearity of the 3456A against a 34401A.

[MisterDiodes]

This concept is not at all new, but certainly fun to play with.  3456a have been hacked "extended" for an extra digit for decades, and it's fun.  What tends to happen is the 7th digit isn't always very accurate when you're comparing against a 3458a - a lot of noise there (and HP used to warn about that).  It -might- be useful depending on how you're using the meter, but usually it's sort of a novelty.  That being said - if your 3456a is very well stabilized and quiet, a lot of times the extra digit is really a bit more meaningful than what the 3457a produces on its GPIB bus.  For best results you'll need the Vref to have settled way down from when it was new (lots of ON time), or maybe modified with an LTZ.

[AG7CK]

 

Very clever work. Thanks alot.

[AG7CK]

This concept is not at all new, but certainly fun to play with.  3456a have been hacked "extended" for an extra digit for decades,  ...

 
Yeah ...? Why didn't you tell us before? Show us one single mention on the web of any HP 3456A machine producing 7 digits, if you can ...
 

[MisterDiodes]

A) Believe it or not, there actually was a time before the WWW....

B) As I said, the 3456a / 3457a are really 6.5 digit meters, and use 6.5 digit capable Vrefs.  Even though the 7th digit is there it's not exactly always useful (just helps with averaging / round off error mostly...sometimes)...and that's why you will always have a 6.5 digit meter, not a 7.5 digit meter.  Run the meters side by side with a 3458a (or any 8 digit meter) and you'll see the difference.

But plenty of guys in the lab were always tinkering with the idea on the '56a, HP noticed, and HP included that extended digit feature on the 57a - with warning from HP that you still have a true 6.5 digit meter, but the 7th digit is there mostly to aid in math averaging ops, but they did call it "Hi Res" mode on the '57a.  It was never intended to be built or sold as a true, direct reading 7.5 digit instrument - except in math "Hi Res" mode which is usually pretty noisy compared to everything else on the market, even at 100 NPLC. Never really caught on like the 3456a / 3458a.

If you're going for 7th digit, the only time i ever saw better results on a 3456a was when an upgraded Vref used, and keep it on the 10V range.  You still won't really have a true 7 digit meter accuracy (but pretty close), still fun to play with.  Some techniques involved monitoring ADC signals, other techniques used socketed ROM's and rebuilding the machine code / modified PCB's...etc.  That was back in the 80's / 90s.  Once the 3458a came out that's what everybody wanted.

[TiN]

B) As I said, the 3456a / 3457a are really 6.5 digit meters, and use 6.5 digit capable Vrefs. 
...
If you're going for 7th digit, the only time i ever saw better results on a 3456a was when an upgraded Vref used, and keep it on the 10V range.

It is relatively low cost for one to tinker and bodge a better reference (with LM399 ref it is still a possiblity to go LTZ, unlike the 8.5d meters delivering 9th random noise digit ) and pimp a circuitry a little with modern parts. TEKTRON did exactly that for both on HP 3457A and HP 3456A.

[MisterDiodes]

...Yes, upgrading the Vref can get you upgraded 6.5 digit performance mostly on the meter's native input range.  No Vref upgrade by itself is going to magically upgrade the input front end attenuator / amp's system noise floor though, so there are limits. 

 I have seen attempts at those front-end modifications too (back in the 80's, before WWW) - but after the 3458a came out the '56a mods fell out of style.  The '58a was such a big upgrade for only around 50%~60% more than the '56a, and for a commercial application it was a lot cheaper to just use a 3458a where needed, and use the 3456a and lesser meters where they were still adequate.  Like we do today.  The '55a, '56a and '57a were certainly lead ups to the '58a. The '57a was more like a lesson for HP on some things NOT to do - but it filled the gap in their catalog until the 3458a was ready a few years later.  When it first came out the '57a was actually a little cheaper than the '56a, usually at the expense of more noise / less stability - so the '56a has always been popular model to upgrade if you were after better accuracy.

Accuracy is not resolution - and usually instrument accuracy (and low drift) is more important at the end of the day.

[e61_phil]

Accuracy is not resolution - and usually instrument accuracy (and low drift) is more important at the end of the day.

I would think it depends on what you wan't to do. If you'r aiming for transfer measurements an extra digit could be really nice, even with a LM399 reference.

[MisterDiodes]

I would think it depends on what you wan't to do. If you'r aiming for transfer measurements an extra digit could be really nice, even with a LM399 reference.

Sometimes that's exactly when you don't want extra noise digits.  You always have to pay attention to your measure confidence and uncertainty on your transfers, because you can't ever do that with zero error.  So if you had a more accurate 6.5 digits with low uncertainty and high confidence vs. 7.5 digits with (much) higher uncertainty and (much) lower confidence...which one is the better result?  You can compute the real numbers after verifying the true accuracy of the instrument against higher class instruments, but usually you find the more accurate / less uncertain result is more valuable.  Depends on what you're doing of course, and does the measure have to be a real traceable absolute value - in which case the basic accuracy class of the meter is generally used (before modifications).  The higher resolution is meaningless without the accuracy and lower uncertainty of measure to go along with it.

In other words:  a noisy 7.5 digit measure isn't necessarily better than a stable 6.5 digit measure, and that was one of the problems with the '57a - depending on what you were doing.

[e61_phil]

I'm very new to consider uncertainties in my measurements according to the GUM. And I don't disagree with your points, but as I understood so far it is possible to use an instrument better than it's specifactions. In the Fluke Calibration Books (Rev. 2) they mentioned to use the floor specifactions for transfers (equal value). Another described way is to make some measurements to characterize the instrument.

For example: I made 1000 measurements (10 NPLC everything above is just an average from the meter) with my 34401A (also 7,5 digits) on a 10k VHP101. This measurement results in a std. deviation (of sample) of 0.3 ppm. The standard error is even much lower after you apply statistics.

I would expect it is a traceable measurement if you make measurements at least over the duration of such a transfer. This should reflect short-term zero-drift, gain-drift and noise. Noise can always be reduced by averaging. But this will not reduce the drift. Therefore, one should be careful with the amount of averaging.

Another point is the linearity. But this error is very small due to the fact of the similiar values.

Edit:

I would calculate the uncertainty this way:

- AD linearity: 2ppm of value + 1ppm of range  (Dr. Frank and others (inlcuding myself) already showed, that the INL of the 34401 is much better)
- To be very pessimistic apply the standard deviation of the whole measurement instead of the standard error and multiply by 2 for 95% confidence level
- Rs = 95% uncertainty of the standard

uncertainty = sqrt( 3ppm² + 0.6ppm² + 0.6ppm² + Rs²)

If we assume an uncertainty of 1ppm for the Standard we end up with 3.3ppm. The uncertainty will be dominated by the INL.

Did I miss a big thing?

Edit2:

So if you had a more accurate 6.5 digits with low uncertainty and high confidence vs. 7.5 digits with (much) higher uncertainty and (much) lower confidence...which one is the better result?

I think that isn't the question here. To enable an extra digit on the instrument will not harm the 6.5 digit specifications.

[borghese]

Very interesting; I had already planned to replace LM399 with LTZ, but someone has the scheme on how to implement the upgrade maybe without uProcessor?
Thanks in advance

[TWMIV]

I have two of these on my bench, I may have to snake a wire in there to see what is coming out.

[e61_phil]

You should keep in mind, that the reference isn't the only noise source in a DMM.
I attached a side by side measurement from a Keysight 34470A (LTZ1000 ref) and an Agilent 34401A (LM399). Both DMMs are set to 100NPLC. The 10V source was a Fluke 5440B.

[Conrad Hoffman]

So will it work with a 3455A?

[cellularmitosis]

Hmm, looks like the 3455A uses optos to talk between inguard and the main processor.  Definitely worth probing!

[Kleinstein]

You should keep in mind, that the reference isn't the only noise source in a DMM.
I attached a side by side measurement from a Keysight 34470A (LTZ1000 ref) and an Agilent 34401A (LM399). Both DMMs are set to 100NPLC. The 10V source was a Fluke 5440B.

That comparison looks really odd: usually the 34401 is also relatively noisy (maybe not as bad as the 3457, but some of the ADC part is similar odd: the 3457 has 3 V range with 10 V native ADC, while the 34401 divides the 10 V input by 3 so the ADC effectively is only working over a +-4 V range - so maybe they should have mixed parts a bit different).  This looks like there something odd with the 34470 - like interference or ripply from the 5440.

Reference noise is not everything, but it gets important at higher resolution.  Near zero there is little influence of reference noise, if used right.
There still is a chance to get some of the higher frequency reference noise back through the ADC - though not that much an avoidable.
So at least for the low readings near zero more resolution could help despite a noisy reference.

A reference upgrade for the 3456 could be a dual / tripple LM399. TiN's links showed such an example. I would still add an extra cap to filter higher frequency noise of the LM399 and maybe use slightly lower value resistors for voltage averaging. Absolutely no need for a µC, but a new calibration due to a changes voltage and maybe changed jumpers.  Using a LTZ1000 might need a little extra modification, as the voltage adjustment range may not be sufficient.

Form the design there is one big change from the 3456 to 3457: the 3456 still uses adjustment with trimmers, while the 3457 does digital calibration / adjustment for most parts.  AFAIK the (later) 3456 and 3457 even use the same reference module.

[e61_phil]

That comparison looks really odd: usually the 34401 is also relatively noisy (maybe not as bad as the 3457, but some of the ADC part is similar odd: the 3457 has 3 V range with 10 V native ADC, while the 34401 divides the 10 V input by 3 so the ADC effectively is only working over a +-4 V range - so maybe they should have mixed parts a bit different).  This looks like there something odd with the 34470 - like interference or ripply from the 5440.

Interesting! I will redo this measurement with a LTZ1000 as voltage source.

Edit:
@Kleinstein: What level of noise do you expect from the 34401A?

I attached a comparision of a 10k measurement with my (old) Agilent 34401A (another one as used for the comparison with the 34470A) and my 3456A. The measurements were taken with 10NPLC and the plots using a moving average of 10 (equal to 100NPLC).

The noise is comparable to the 10V measurement of the other 34401A. And during 10k measurement it is only around 1V FS.

[borghese]

I have already replaced LM399 with LTZ, but how to add the 7th digit?

Thanks in advance

[floobydust]

The 34401A has a few noisy devices on quiet +5VB, such as 12MHz oscillator U405, FF U404 so I believe that rail is not ideal.
Also check the 34401A revision history- C402, R430, R403 etc. changes to the A/D depending on serial number. I think R403 from 8k25 to 12k1 affects linearity.

[MisterDiodes]

Cellular:
Be aware that a lot of DMM's will have that "extra digit" floating around by the ADC system.  In the case of the 3456a the 7th digit will not exactly be like having another 0.1ppm across the entire range - you may see a true accuracy of more like .3~.4ppm or worse on that extra digit - it will depend on where you are on the range, temp. etc.  That extra digit is already being used to help the stability of your 6.5 digit data, and sometimes that extra digit accuracy doesn't need to be any better than .5ppm - its function is to help round up your 6th digit data or not.  Sometimes you'll get better accuracy on that 7th digit, especially if you upgrade your Vref. (Which has been going on since about an hour after the first 3456a was delivered in 1981 ).

In other words:  It's not like the designers forgot about an extra digit or were trying to hide it from you; it's already used to tighten the uncertainty of your instrument accuracy at 6.5 digits.  Extracting that extra digit out again may or may not help whole lot.  You just have to play with it, and verify what it can and can't deliver for lowering measurement uncertainty.

It's still fun to learn about it and investigate how the measurement system works.  As you verify your souped-up 3456a system you'll find out where the true limits are!  Of course that means more sources to test it against ...

Another suggestion:  If that new 3456a passes all self tests, I'd suggest re-capping it and give it a good spruce-up cleaning. Run it on your best Vref for at least a few weeks and make sure it's stable.  If it's nice and quiet I'd suggest you get it calibrated at your local lab - it's usually very reasonable.  Around here it runs around $125~150.  That will give you at least one low-cost anchor point for absolute voltage value.  56a's (modified or not) usually run well and are a nice tool to have when you're playing with Vrefs.  At this age they can have can have really good 1yr drift rates too.

Have fun!
 

[orin]

Hmm, looks like the 3455A uses optos to talk between inguard and the main processor.  Definitely worth probing!

Easy enough to probe - I used a Digilent Analog Discovery to probe mine.  You get raw counts - and you need the calibration constants to make sense of them.  You could do it in Auto-Cal mode though as it cycles through all the calibration constants.

I'll look up my notes at home and post the kind of counts you get.

[cellularmitosis]

Thanks for the advice and historical perspective here, MrDiodes.  My hope is that taking 10 readings at 10 NPLC will produce one 100 NPLC reading which is closer to a "real" 7.5-digit measurement.  I'll have to play around with it a bit and see if anything useful comes out of it.

[orin]

Here are some 3455A counts.  The 201BBD/201BBE entries are the input which was 10V.  The others are the calibration constants.  This is with the stock integration capacitor replaced with a Russian teflon capacitor.  There was a +/- 2 to 3 count jitter on the input reading with the original capacitor (depending on which calibration constant was converted immediately preceding the input reading).

So, with a count of 201BBE for a 10V input, i.e. 2104254 decimal, there isn't another digit hiding behind the scenes on the 3455A.

201BBE
201BB8	10V Gain
201BBE
AEB	Ohms Offset
201BBE
8001E4	Ohms Offset
201BBE
8002BF	100V Offset 2
201BBE
8002C2	1000V Offset
201BBE
9F93AB	100V Gain
201BBE
474	100V Offset 1
201BBE
4491	0.1V Offset
201BBE
4B2	1V Offset 1
201BBE
469	1V Offset 2
201BBD
1FDDE1	1V Gain
201BBE
800002	AtoD Offset
201BBE
801079	AtoD Gain
201BBE
8002B9	10V Offset

[e61_phil]

That comparison looks really odd: usually the 34401 is also relatively noisy (maybe not as bad as the 3457, but some of the ADC part is similar odd: the 3457 has 3 V range with 10 V native ADC, while the 34401 divides the 10 V input by 3 so the ADC effectively is only working over a +-4 V range - so maybe they should have mixed parts a bit different).  This looks like there something odd with the 34470 - like interference or ripply from the 5440.

Interesting! I will redo this measurement with a LTZ1000 as voltage source.

I did a new measurement with a battery powered LTZ1000 as source. Kleinstein was right, the other measurement looks odd compared to the new one. Nevertheless, the 34470A isn't superior in this measurement.

[Kleinstein]

At 100 PLC the noise of the ADC in the 34401 is not that relevant anymore compared to the reference. It's at 1 PLC were ADC noise is relatively high.

For the 7 V reading one should mainly see the noise of the reference and the data shown for the 34401 already look better than what is expected from an average LM399 - so HP might have done quite a bit of selecting good LM399/LM199s, or it was just luck / maybe better LM399 back than.

At least in the plans I found there where 2 versions of reference  for the 3456: one with an LM399 (A25) and one (A24) with a different reference with a separate temperature control, but slightly higher zener current and thus possibly slightly lower noise.

The noise data shown so far for the 3456 show little fluctuations with sometimes essentially stuck to one value. This is nice for manual reading, but it is bad for doing averaging. So here it would help to have that extra digit, even it it is rather noisy.

[cellularmitosis]

Might be interesting to create a 2DW232 ref board for the 3456a to find the noise floor of the ADC

[zhtoor]

Might be interesting to create a 2DW232 ref board for the 3456a to find the noise floor of the ADC

just use a set of batteries (NiCd or Lead Acid) in series for this noise floor measurement.
(you might have to correct for voltage droop)

or

charge a supercap to the required voltage and buffer using a *very* lownoise opamp
and use as a ref.

best regards.

-zia

[cellularmitosis]

A bit of progress:

If you breadboard up the circuit from the schematic (just the transistors and resistors, haven't added the flip-flops and gates and shift register and such), these are the two signals you get as output.

This is with 9 turns around the transformer, and using 2N3904's in place of the CA3046 (U23).

The "byte" (9 bits) which you are looking at is 1 1001 0111

The yellow trace appears to be a clock signal, while the blue appears to be the data.  However, they don't quite align perfectly.  Perhaps that's what the rest of the circuitry handles.

[AG7CK]

In the document https://literature.cdn.keysight.com/litweb/pdf/03456-90006.pdf?id=722597 I find information that confirms your oscilloscope findings (both for clock and data) in paragraph 8-262, document p. 8-49 (pdf-page 251 of 385). The first bit (of the 9) seems however to be always 1, and is used for "data available" indication and clock / timing.

On pdf-pages 312-13 there are also photographs of oscilloscope CRT's resembling your findings.

So imo there is no doubt that one can read and clean up the data. But I can find no information on the format of the serial readings and whether they do contain 24 or more bits / 7 digits resolution numbers.

Could you please give a link to the manual you are using (your schematic seems different from Figure 8.73 on pdf-page 293 in my link), and indicate whether you know the format of the data or not.

To be very brief: Does anyone =know= that the 7th ADC-digit ever is sent to the Isolation Logic transformer T2 (A3T2) that you are reading data from?

[cellularmitosis]

I'm using the same manual which TiN has on his website: https://xdevs.com/fix/hp3456a/

However, I purchased a copy from Artek manuals which had a bit higher-resolution schematic scan (I needed to confirm if one of the connections had a "dot" junction or not).

I'm 90% confident about the 7th digit, as I was able to verify each of the first few digits using an MV106, then counted the remaining nibbles (half bytes), and the last one would be #7, and it bobbles around a bit, as expected.

My plan is to decode the bytes, then measure a battery, and log the data.  Through the noise, we should be able to see the battery very slowly lowering in voltage, which should confirm the 7th digit.

[kj7e]

I have the original book, if you need a high-res photo of a schematic let me know.

[cellularmitosis]

Could you please give a link to the manual you are using (your schematic seems different from Figure 8.73 on pdf-page 293 in my link), and indicate whether you know the format of the data or not.

Oh, whoops, I was using the inguard's receiver in figure 8-69.  I should be using the outguard's receiver (figure 8-73)

[MisterDiodes]

Another suggestion:  You've got access to the 3456a firmware images (Boat Anchor Manual Archive), you've got schematics, you've got machine code disassemblers for MC 6800, 6802, '6809 and 8048 CPUs...  (Very very common for that era)

Just remove the original CPU, plug in an ICE (In Circuit Emulator) and you can just run and examine the code anywhere while the meter is running.

Even build your own ICE (This is just an example I picked at random); this is typical of how you do it if you're a serious Meter Modder:

https://www.ebay.com/itm/MC6809-In-Circuit-Emulator-PlansTo-Build-ICE-and-Sofware-Break-at-ROM-Address/332620709949

HINT: If you use an ICE on a 3456a you want one that has accurate I/O pin updates down to every clock cycle edge.  This can be done with the 1.5 Mhz CPU's.  It's also handy if the ICE can run the ROM image code right from it's own memory, that way you can test firmware mods without touching the ROM's on the meter.

You might even run an ICE from a 40MHz PIC chip or ARM.

Probably illegal on a public forum like EEVblog since the code was never released into the public domain, but somewhere floating around is the full documented firmware sources for these meters.  Then you can just look at the sources to see how the math is done internally.

Again it's a lot of work for potentially not a very big payoff, but it's neat to trace through the meter's functions step by step. 

You can also see what's possible with a faster CPU - if you can keep the noise out.  You also might find out why you still probably want to keep the NPLC at 100 if you're interested in accurate data (and why that's tied to the ADC design), but that's up to you.

[kj7e]

See here for a hack by TimInCanada to mod the exponent to display the extra digit;

https://www.eevblog.com/forum/testgear/adventures-in-retrocomputing-hacking-a-7-5-digit-hp-3456a/