Fluke 5440A repair

[Andreas]

Hello branadic,

on measurement devices (K2000 or my ADCs) it is software compensation.
(measuring the raw value and the temperature inside the instrument e.g. by additional NTC and then doing a linear or 3rd order T.C. compensation on the computer).

On references it is hardware compensation (400K resistor or copper resistor on LTZ1000 or ADR1000 or NTC in the feedback loop of a AD587).

with best regards

Andreas

[Rax]

The 1.5ppm delta remains unchanged after overnight running of both units.

Obviously, I need to have my other units confirm this, and the next best instruments I have are 6.5 digit, so this would be barely noticeable on their last count, which is why I'll call it inconclusive... The best other meter I have here is a Fluke 8846 which seems to register a slight +1 slide up on the last count.

Any ideas?... Anything to look into? I feel the issue seems to track to the F5440A, and I wonder if something became off in the INT CAL routine. Maybe I should consider reimaging all four EPROMs and see if that fixes this.

[Rax]

[...]
It's very uncommon, that the SZA 263s inside the 5440A just make just a jump out of thin air.
I also doubt that you would find a real damage inside your instrument.
[...]
Frank

I can only work with actual causes for observed events. If there's no damage, no jump, no tempco... 
I love sci-fi, but not at the bench.

[Rax]

And BTW, all this talk of jumping references - I only brought it up (or even considered it) because it was pointed out here. I can't say I've seen it, or experienced it in any way before, and frankly, it's extremely bad news it's even a possibility. Worst freaking thing that could ever happen in a world of exactitude, isn't it?... 

But I'm counting on the far greater experience and incredible knowledge in this "think tank" to possibly suggest paths to understand this occurrence.

[Rax]

A fair point to make is that 1.5ppm is still well within even the 1 year spec of 3.5ppm. And I have no history on the instrument. So there's all that.

But even so, particularly given all the input here, a jump like this is not easily explainable. I'd be remiss to not investigate it and work to determine a cause.

[branadic]

I think whether or not it was a sudden jump (like popcorn noise with a very large time constant) or a (random) walk is just guesswork/speculation as you are not constantly observing your setup due to the lag of a GPIB adapter. I can only advert what Frank already suggested, go get a GPIB adapter and set up some logging. And while you are at it, add ambient sensors too.
As you already pointed out multiple times you are a physicist, so please act like one and prepare an experiment/setup, that leaves no question.

-branadic-

[Rax]

I think whether or not it was a sudden jump (like popcorn noise with a very large time constant) or a (random) walk is just guesswork/speculation as you are not constantly observing your setup due to the lag of a GPIB adapter. I can only advert what Frank already suggested, go get a GPIB adapter and set up some logging. And while you are at it, add ambient sensors too.

-branadic-

Well, I I sir. Understood!!

...though I never said I'm a programmer, so this won't be quick, nor painless... Oh boy!

[Rax]

I think whether or not it was a sudden jump (like popcorn noise with a very large time constant) or a (random) walk is just guesswork/speculation as you are not constantly observing your setup due to the lag of a GPIB adapter.
-branadic-

I'll put the work in this getting this done - in fact, I've been working on this for quite a while, just not very successfully... - but I don't think that's going to be telling us much on this past "walk" event. Or maybe I'm missing something?...

[branadic]

Get a Raspberry Pi, a GPIB adapter and use one of the two instructions below to set up everything.

https://github.com/PhilippCo/meas_rpi

https://www.eevblog.com/forum/metrology/raspberry-pi23-logging-platform-for-voltnuts/msg2008349/#msg2008349

-branadic-

[Rax]

I'll definitely try the RPI path, but will take a while to put all that together.

But in the meantime, I have two built, and one unbuilt USBGPIB adapters (I think xypros?...), based upon the ATMEL MEGA32U4 (?...). But have never been able to get those set up. I just placed an order for an AVR ISP adapter which I should get tomorrow.

But I got on this path before and every single time got lost in the weeds of lack of clear direction, documentation, etc. If anyone has a clear step by step idea of how those get set up and running, I'd be very grateful for that guidance.

[Rax]

As you already pointed out multiple times you are a physicist, so please act like one and prepare an experiment/setup, that leaves no question.
-branadic-

Not all physicists are experimental physicists, BTW. I don't think I really said my background is in physics more than once (though I candidly appreciate your spirit of observation) - I may just exhibit the mindset pretty consistently (and repeatedly in writing), as that's how I think (nothing ostentatious meant with it at all).

Setting our terms/definitions and framework is prerequisite to communication.

[Rax]

I think whether or not it was a sudden jump (like popcorn noise with a very large time constant) or a (random) walk
[...]
-branadic-

Thank you very much for thinking on this with me ("levelling") and actually presenting some possible causes for the observed occurrence. Much appreciated.

[Rax]

In the meantime, things have gone down again to sub-ppm agreement. Not sure what all this is about. I had the F5440A off for a day, then I turned it on to find it about .25-.5ppm high. It'd be interesting for me to see if it goes back down to an order of magnitude closer agreement (by which I mean being at 9.9999999V - 10.0000000V for any significant stretch of time), and try to discern any patterns.

I am working on the automated logging of readings.

[Rax]

It'd be interesting for me to see if it goes back down to an order of magnitude closer agreement (by which I mean being at 9.9999999V - 10.0000000V for any significant stretch of time.

Yes, we are. I'm not sure what all this "wild" "excursion" was about  . I'll keep on watching it, and maybe all this is relatively normal in my "non-metrology-grade" environment  (though tempco is not the cause), with many variables and little capacity to thoroughly diagnose on basis of a solid set of time-coordinated data with multiple streams (V, C, t, etc.). One keeps on learning! If so lucky. 

[Rax]

by which I mean being at 9.9999999V - 10.0000000V for any significant stretch of time

"any significant stretch of time" for me means multiple (>1) 20s integrations on the P6048.

[alligatorblues]

Now that I have a functional 5440A (it feels good to say that) I realize I never really looked for an Operating Manual. Does anyone know a source?

I can find 5440Bs, and I assume it's probably almost the same, though I'd still prefer a 5440A specific version. Looked at Artek, and even they don't have it.

If all else fails to locate a service manual, I look on https://elektrotanya.com/keres

[Dr. Frank]

It'd be interesting for me to see if it goes back down to an order of magnitude closer agreement (by which I mean being at 9.9999999V - 10.0000000V for any significant stretch of time.

Yes, we are. I'm not sure what all this "wild" "excursion" was about  . I'll keep on watching it, and maybe all this is relatively normal in my "non-metrology-grade" environment  (though tempco is not the cause), with many variables and little capacity to thoroughly diagnose on basis of a solid set of time-coordinated data with multiple streams (V, C, t, etc.). One keeps on learning! If so lucky.

Good evening Rax,

Maybe that's simply the usual hickups of very old instruments.
I copy the monthly comparisons of the 5442A and another LTZ reference, latter is continuously running.
They were measured and compared in relation to the mean of my whole reference group of 11.
The LTZ #1 tracking is relatively smooth, especially after I used shielded PTFE cables similar to Adrians, 10 samples with statistics with reversal (GPIB monitoring required), and always holding the breath and my hands still during the sampling time.

You also see, that the 5442A sometimes has hickups up to 1 ppm., which will vanish the next time, but can only be identified by using such regular comparisons.
Another INT CAL on that same measurement-day did never remove the hickup.

Recently, I changed my averaging method. I have found out, that during reversal of each measurement, I got a mostly constant -300nV offset between + and - values. This I simply had to assign to the constant non-linearity, or reversal error of my 3458A, which would be -0.03ppm, i.e. its nominal INL error, instead of any random e.m.f.
So I also doubt, that any e.m.f. error will have big influence (~0.02ppm typically), like Dieter assumed recently: https://www.eevblog.com/forum/metrology/fluke-5440a-calibration-procedure/msg5147310/#msg5147310

When you're using proper PTFE with copper or gold plated lugs, those e.m.f. errors will stay nearly below the detection limit.

My new algorithm:
3458A @ 8 digits, NPLC 100
- screw lugs to the DUT, wait 1 min for thermal equilibrium
- take 16 measurements for ~ 1 min
- read statistics: average value = result (9 digits), StD will be 70 .. 300nV or 0.01 .. 0.04ppm
- if measurement shows more noise, repeat reading

Maybe it would be better in your case to use 7 digit, 2sec long measurements and use statistics of your 6048.
This will give you as well stable results to 8 digits , but also an idea / hint how stable your measurement, i.e. DUT vs. DMM is.
You might also identify external noise sources, like SMPS.

Frank

Btw.: Obviously, we have found the root cause of the deviation during the last external comparison.
When i get the corrected results, I hope that my baseline is confirmed within 0.3ppm.
 

[Rax]

If all else fails to locate a service manual, I look on https://elektrotanya.com/keres

I was able to track it down, very serendipitously, as essentially one of those free operating manuals and/or datasheets on the instrument page of a major retailer of used equipment... (with their watermark, of course). But nowhere else! Go figure.

[Rax]

Btw.: Obviously, we have found the root cause of the deviation during the last external comparison.
When i get the corrected results, I hope that my baseline is confirmed within 0.3ppm.

Well, I'm very glad, and thank you for following up on that. I (start) understanding how nerve wracking that can be. I'm happy it sounds like it's out of the way!

[Dr. Frank]

Btw.: Obviously, we have found the root cause of the deviation during the last external comparison.
When i get the corrected results, I hope that my baseline is confirmed within 0.3ppm.

Well, I'm very glad, and thank you for following up on that. I (start) understanding how nerve wracking that can be. I'm happy it sounds like it's out of the way!

Well, it's very interesting, indeed, as this demonstrates how careful you have to be when making ring comparisons, i.e. what kind of error sources you have, in the cabling, instruments, but also in the way how to calculate the measured values.
That's also the reason, why I find your 5440A / 6048 comparison so useful.

Anyhow, that brought back my trust into my references.

Frank

[Rax]

That's also the reason, why I find your 5440A / 6048 comparison so useful.
Frank

Thank you very much for your words of encouragement. "Gives heart" to one embarked on some pretty unsettling and unfamiliar territory that's at the threshold of observable phenomena.

[Rax]

Here's a graph over about 3hrs of automated readings via the P6048 (one reading every 20s as per 20s integration, in total about 550 readings for this graph). Fluctuations within about .2ppm, as mentioned before. They're a bit high (this is ppm on the high side of 10V, so "0.0ppm" = 10.0000000V), but no INT CAL or nulling of the instruments was done prior to running this log (the most recent have been days ago). In the previous weeks, doing both of the above would restore/shift the readings to a pretty sharp 10V. Given I've seen this recent >1pmm "wander," I don't exactly know what to expect in the future... We'll see.

Environmental conditions were pretty hostile during this hot afternoon in SoCal (according to my bench thermometer, about between 27C to 28.5C at the bench during these logs, ramping up along the measurements - there's a hint of the readings going ever so slightly higher with time in the graph tilt, I think?...).

Fall is about to kick in, so hopefully temperatures will fluctuate less, at least during the day. I still have to figure out how to also record temperatures during these logs.

[Rax]

731B [...] you can for sure simply present your T.C. and stability measurements on it
Frank   

Enclosed below. As this was late evening, there were more hectic temperature differentials - though I tried to keep things as reasonable as I could by "throttling open" the garage door - and the tempco is about where I saw it before (nowhere near 1ppm/C).

I'm running a Python script logging this overnight, and will seek to update this report tomorrow morning, though I won't have hands-on temperature readings throughout the night. But, as I said before, the likeliest highest temperature differential will occur about the time I wake up, as the early bird that I am (4:30-5AM).

[Rax]

Longer 731B readings (overnight). I don't think the temperature variations were any higher than specifically during the evening (I found the bench at 26.4C at 5AM), which is reflected in the graph. One can see my activity at the beginning of the graph (though, still, very reasonably small effects).

[Rax]

I was going to submit more data accrued this morning (see below, only about 150 readings this time), when, right after collecting this, I zeroed the P6048 to see if I can remove the .25ppm delta (aiming for the sky here, and I hope everyone sees the deprecating humor in there), and instead I got the... 1.5ppm offset by the F5440A back! This is maddening.

I tried INT CAL, RESET, etc., but nothing works (like, I think, Frank also testified). I should probably let this run an endless log and see if at any point it jumps back down to convergence with the P6048.

Obviously, comparing again with my F731B, I don't see this jump reflected in the P6048, so I assume this is the F5440A again "jaywalking."