Fluke 5440A repair

[Rax]

Hi all,
I've been weirdly unable to find a datasheet for this DC Calibrator. Does anyone have one? All of the manuals I have are missing that "attachment."

Also, would appreciate some thoughts on it. What's the level of this really? Up to par for 6.5, or maybe 7.5 digit meters calibration?

It's a huge and heavy box for just DCV, for a while I thought I must be imagining things and it must include more functionality than just that.

[Swainster]

Do you mean the schematic? The datasheet should be easy to find. That said, I don't recall that the schematic was hard to find either...

Anyway, the 5440B is indeed a large heavy box, just for DCV... and it does it really well. To my mind, it's the best DCV reference that you can get in the kilobuck price range, and i seem to recall that it's in the 7.5 digit class. I mainly use it to transfer DCV from my in-cal 7.5 digit meter to 6.5 digits and below.

The down side is that you will still need a rack full of other instruments to give you ACV, current, resistance etc.

[alm]

It's a huge and heavy box for just DCV, for a while I thought I must be imagining things and it must include more functionality than just that.

The 5440 series is the most linear and stable DCV calibrator next to the Datron 4000/4708/4808 or Fluke 5700/5720 series. The latter can contain more functionality in the box (in the case of Datron depending on options), but certainly aren't any much smaller or lighter. The 5440 has the advantage over the Datron calibrators that the 11V range and higher ranges can be calibrated using artifact calibration using a single external 10V standard. Something the 5700/5720 can also do, but not many other calibrators (none of the Datron units). I have a paper 5440A manual but unfortunately it's also missing the specifications section. So it's not just scanned manuals that are missing it...

Apparently the 5440A is described in the 1985 (and probably 1984 and possibly 1983) catalogs, so if you could find a (digital) copy of one of these catalogs, they would probably give you some abbreviated specifications. You could message Bill158 to see if they still have access and would be able to scan those pages. Please share them if you find them.

I would expect them to be very close to the 5440B/5442A. It should be sufficient to calibrate 7.5 digit meters, and should be good enough for 8.5 digit meters in the presence of other standards (e.g. a more stable 10V DC standard).

[Rax]

The datasheet should be easy to find.

I have the component-level SM from Fluke (which is pretty spectacular face-value, but not unusual for the time), but no trace of the specifications anywhere. At least where I looked.

[Rax]

Converting this thread into a repair thread.

I essentially have a unit here which upon receipt had completely nonsensical display annunciations (8000000 on the left and a bunch of squares and a "?" on the right) and no output at LO/HI. Given these drastic symptoms I suspected power supply issues, and I did find that TP7 to TP8 and TP9 were completely off. Other voltages on the Inside and Outside Guard Regulators (A10 and A17) seem to be reasonably close (didn't try any adjustments at this point).

Replacing C17 through C20 resolved this issue (including CR21 turning off). Definitely not out of the woods yet, I still have roughly the same weird stuff displayed (and, BTW, one red LED is lit on A1, Keyboard Assembly), and no output from the unit.

I do see diagnostic LEDs lighting on different boards (just like CR21 was lit before fixing A10, and as I mention just above). I can't find anything on the SM on these... Can anyone point me to where this stuff is, please?

Any repair path forward recommendations are welcome. Thank you!

[bdunham7]

These guys say their manual has specs, I'd just ask them if they really have them and ask for your money back if they aren't in there.

https://www.ebay.com/itm/370513925603

Repair is probably going to be a challenge.  But that's what you're after, right?

Here's an advertising blurb.  I'd say these have a good enough TUR for any 6.5-digit meter and probably with guardbanding good enough for 7.5-digit.

[Swainster]

Apologies to Rax, I missed that he was looking for info on the 'A' version.

Looking forward to the repair - I have a 'B and the only issue that I've had so far is a couple of blown PCB fuses, which depowered the in-guard processor. Never found any reason for the blown fuse and its been fine since being replaced, so may have been due to aging.

These guys say their manual has specs, I'd just ask them if they really have them and ask for your money back if they aren't in there.

https://www.ebay.com/itm/370513925603

Satisfied Artek customer here (I've bought 2 or 3 manuals from them so far). I have found that Dave at Artek has always been really friendly and helpful, and their manuals to be their own scans. Should be no problem asking them for more info before purchasing.

[Andreas]

Hello,

the specs can be found here:
https://www.amplifier.cd/Test_Equipment/other/Fluke5442A.html

with best regards

Andreas

[Dr. Frank]

Hello,
it's not useful to ask about 6.5, 7.5 or 8.5 digit DMM calibration.
You only need to compare the possible uncertainty of the 544x A/B vs. the uncertainty of your intended DMM.
In principle, as the 10V output of the calibrator is extremely stable over time, much better than specified, and maybe better than usual 10V standards, it's also possible to calibrate DCV of a 3458A.

I append the specification table from a Fluke / Philips catalogue.

I have the 5440B_AF operation and service manuals, and both contain the specifications, of course. There are only small differences between 5440A / B, and 5442A as well. These might be available at xdevs.com.

Frank

[alm]

These guys say their manual has specs, I'd just ask them if they really have them and ask for your money back if they aren't in there.

https://www.ebay.com/itm/370513925603

Satisfied Artek customer here (I've bought 2 or 3 manuals from them so far). I have found that Dave at Artek has always been really friendly and helpful, and their manuals to be their own scans. Should be no problem asking them for more info before purchasing.

I 100% agree with the positive comments, but note that Dave has passed away recently, and while his wife is taking over the business, expect slower service. Also, I have that manual, and while section 1 is in the table of contents, the section is empty. Just like in my paper copy. I guess the leaflet was easily lost.

[MegaVolt]

Does anyone have one? All of the manuals I have are missing that "attachment."

You can use the documentation from the 5440B. The schemes coincide completely except for the control scheme of the front display.

[Rax]

the only issue that I've had so far is a couple of blown PCB fuses

This is a very good point, I need to evaluate all PCB fuses.

Satisfied Artek customer here (I've bought 2 or 3 manuals from them so far). I have found that Dave at Artek has always been really friendly and helpful, and their manuals to be their own scans. Should be no problem asking them for more info before purchasing.

Unfortunately, Dave has recently passed. Manuals are still available and the business is still attended to, but with some delays and a backlog. I think the eBay orders are being well catered for, but the ones through the website are not processed as well.

[Kosmic]

I 100% agree with the positive comments, but note that Dave has passed away recently, and while his wife is taking over the business, expect slower service. Also, I have that manual, and while section 1 is in the table of contents, the section is empty. Just like in my paper copy. I guess the leaflet was easily lost.

About Artek, I ordered a manual yesterday on ebay and it was shipped on the same day. So look like it's business as usual.

[Rax]

So look like it's business as usual.

See my post above, AFAIK only on eBay currently. I don't think the website is up yet. 

[Kosmic]

So look like it's business as usual.

See my post above, AFAIK only on eBay currently. I don't think the website is up yet.

I mean, for the ebay store. The web site is up but apparently (from the discussion on groups.io) they can't process orders from there. Probably better to avoid the website for the time being.

[Rax]

The web site is up but apparently

You're misreading what I meant by the "site being up."

[Rax]

Further work on this.

• pulled most boards and cleaned their header contacts with pure IPA
• also, checked their fuses
• ...and replaced a couple of electrolytics where I think they placed 85C ones far too close to toasty heatsinks... If the PCB is dark, that cap can't be doing well. Put 105C ones instead and tilted them a bit for heat clearance

No smoking gun yet. Again, if anyone has any information on the PCB LEDs error codes, I'd appreciate some direction. I can't find those anywhere. There are flickering LEDs on some of the boards.

[Rax]

Here are the fault codes I am getting from the LEDs on the boards:

• A16, Controller: CPU blinks very rarely; MEM, INT blink about 2x more often; FPC is continuously lit
• on the keyboard assembly, the FAULT LED is also continuously on

It looks like I am on the 2-13 2-41 pages on the SM, which I'm still "close reading..."

[Swainster]

Regarding the fuses which I changed, I recall that they looked just like an axial leaded resistor i.e. not a cartridge type. I dont think your issue is related to a fuse though, as they caused a whole section to go dead.

So far, my personal experience with old Flukes is that tantalum beads are often the culprit. That anecdotal evidence is based on a very limited sample size - I have hopes of increasing that sample size, however my lottery numbers have yet to come up.

[MegaVolt]

Again, if anyone has any information on the PCB LEDs error codes, I'd appreciate some direction. I can't find those anywhere. There are flickering LEDs on some of the boards.

[MegaVolt]

I gave initial setup tips in the topic:

https://www.eevblog.com/forum/metrology/another-fluke-5440baf-repair/

You can remove most of the boards and start by setting up the digital part.

[Rax]

I gave initial setup tips in the topic:

https://www.eevblog.com/forum/metrology/another-fluke-5440baf-repair/

You can remove most of the boards and start by setting up the digital part.

Thank you for this. I read your saga, but I'm not sure how much of it is applicable here. I think you had a bad IC on A16 (or A14? It's not clear which, and neither is which IC was bad). Also, you had a PS issue - which I also had (the +-30V rails), but fixed. I've also checked all fuses in sight and nothing seems open. Like I mentioned, I started selectively replacing stressed electrolytics, but may just go ahead and replace all dipped tantalums I see (probably with Nichicon HEs, unless anyone tells me they're not the right pick for the job in some of those tantalums duty).

On the logic/digital side of things, I am a bit raw. Different put, I am not sure how to read comms and bits and such. It sounds to me like you're suggesting taking all boards out (probably except all the supply boards) and see how that changes the codes?

If yes, given the codes (they seem pretty much exactly like yours in your thread), which would be your sequencing of swapping out and in?

[MegaVolt]

It sounds to me like you're suggesting taking all boards out (probably except all the supply boards) and see how that changes the codes?

List of removed boards.
https://www.eevblog.com/forum/metrology/another-fluke-5440baf-repair/msg3722311/#msg3722311

[Rax]

List of removed boards.
https://www.eevblog.com/forum/metrology/another-fluke-5440baf-repair/msg3722311/#msg3722311

Oh! One more thread to read!... Didn't realize there's that one also. Thank you.

I think you're saying - remove all boards from inside the guard cage and also A14 and watch for just the comms error with A14 to pop up? If yes, what error code would this be? Please have in mind I see nothing legible displayed on the right panel, and the left displays 800000H or something like this, where the last # changes occasionally depending on what I do to the unit (for instance, clean the edge connector on a board, etc.).

[MegaVolt]

Oh! One more thread to read!... Didn't realize there's that one also. Thank you.

)))))))

I think you're saying - remove all boards from inside the guard cage and also A14 and watch for just the comms error with A14 to pop up? If yes, what error code would this be? Please have in mind I see nothing legible displayed on the right panel, and the left displays 800000H or something like this, where the last # changes occasionally depending on what I do to the unit (for instance, clean the edge connector on a board, etc.).

This is problem ((

Then you have to watch the LEDs.

If you had a logic analyzer, you could stand on the display board and track the writing on the letter bus to the display.

[Rax]

If you had a logic analyzer, you could stand on the display board and track the writing on the letter bus to the display.

Funny you should mention that, I do... Sort of. I have an 8 CH Saleae (I think?...) 24MHz USB logic analyzer. Not sure how many channels I need, or if this is anywhere near up to par. But I'm definitely willing to find out.
___________________________________________________________
Well, the POS doesn't work. I got it a couple of years ago and I don't think I ever used it.

Just picked up a Hantek 6022BL which I should receive tomorrow. Would this fit the bill?

[MegaVolt]

Funny you should mention that, I do... Sort of. I have an 8 CH Saleae (I think?...) 24MHz USB logic analyzer. Not sure how many channels I need, or if this is anywhere near up to par. But I'm definitely willing to find out.

You need 7 channels.
1. Letter writing signal. There is a small circle in the picture. Unfortunately I don't have a schematic for this board and you'll have to do a bit of research to find it. Address for accessing the display A15...A11 = 11111. When setting this address and the WR signal, you should see a signal at the output.
Display_2_WR  =  [A15...A11 = 11111]   +   [nMREQ_Z80=0]   +   [nFRSH_Z80=0] + [nWR_Z80=0]

2. Data bus D0...D5.

If 0x20 is added to the data, then the letter codes will correspond to ASCII codes.

[Rax]

Repair is probably going to be a challenge.  But that's what you're after, right?

yes, and you well know it

[Rax]

Does anyone have any info on the extender cards needed for this? I can't find anything in the SM, but maybe I'm missing it. I'm not even sure if there's one type for servicing the entire unit.
I think I'll have to raise the controller to pursue some troubleshooting steps from the SM (4-28 @ p. 4-31).
Thank you.

[bdunham7]

You might try asking ebay seller Sparko0679.

https://www.ebay.com/sch/i.html?_ssn=sparko6079&store_name=sparko6079&_oac=1&_trksid=p2047675.m3561.l2562

[Tony_G]

I have several of his extenders - They work very well and he'll work with you to create a new one (He did his 8340 & 5200 extenders because we asked).

Also did some extenders for 8350 plug-ins from PCBWay and they were great too - If the extender is just a passthrough, then don't let the lack of original pieces stop you - If they have additional bits on them (I think the 8902A micro board extender has things like this) then you might just have to go with a passthrough and a logic analyzer.

TonyG

[Rax]

You might try asking ebay seller Sparko0679.

The interactions I had with him make me not want to touch his business with a ten foot pole, frankly. Besides, these are machined, or routed PCBs, so not precise and rely on a good hand when made, etc. Due to the fabrication process, the reviews I heard from other people have been at best mixed - there's inherent tolerances I'd rather... not. One puts their equipment at risk when using them, in my opinion.

I am hoping to find a genuine extender or just fabricated better.

[Rax]

Still looking for any info on these extenders. I haven't been able to even find part numbers, or pictures, or really anything.

If anyone has any information, I'd appreciate sharing it. Thank you.

[Tony_G]

The connectors are just standard (for the time) Cinch connectors - You can buy modern equivalents from Newark (and probably others).

Grab KiCAD and create a simple board that passes from an edge connector to whatever you get from Newark. That is what I did for the 8350 plugins. Cost me US$5 for the boards - Would be more for the 5440 as it seems to double up those connectors.

Regarding the actual part numbers, according to the publicly available service manual, the complete extender kit seems to have the part number Y5021 - The extender board has the part number 608281 - The filter extender has the part number 608117.

TonyG

[Rax]

Regarding the actual part numbers, according to the publicly available service manual
TonyG

Thank you very much, Tony! I really appreciate it. I couldn't find it in there if my life depended on it.

[Rax]

Grab KiCAD and create a simple board that passes from an edge connector to whatever you get from Newark. That is what I did for the 8350 plugins. Cost me US$5 for the boards - Would be more for the 5440 as it seems to double up those connectors.

That's not a bad idea at all. I can't imagine finding the time with all projects, but it'd be a very useful contribution if no one else has done it already.

[Rax]

You need 7 channels.
1. Letter writing signal. There is a small circle in the picture. Unfortunately I don't have a schematic for this board and you'll have to do a bit of research to find it. Address for accessing the display A15...A11 = 11111. When setting this address and the WR signal, you should see a signal at the output.
Display_2_WR  =  [A15...A11 = 11111]   +   [nMREQ_Z80=0]   +   [nFRSH_Z80=0] + [nWR_Z80=0]

2. Data bus D0...D5.

If 0x20 is added to the data, then the letter codes will correspond to ASCII codes.

Thank you for that, Megavolt. I'll likely try to read these data lines over the weekend, if I'm very lucky (timewise). I'm not sure I can probe all that without extenders, but I'll look into it. This is "path A."

That said, I'm trying to take a bit of a step back and figure out what exactly is my best next step here. You've previously mentioned pulling a bunch of cards and then - if I understand your approach correctly - putting them back in one by one? While watching how the trouble LEDs on the controller card act? (in other words, see which card triggers error codes) Is this what you had in mind with that? This is path "B."

So I have the following steps forward, in no particular order (as, to be honest, I'm not sure at all what to do next):

• step C - follow the procedure in the SM (p.4-31). This should, in theory, allow me to isolate the issue(s?) to the controller vs. the front panel.
• step A
• step B

Thanks in advance for any "birdseye view" guiding thoughts.

[MegaVolt]

You've previously mentioned pulling a bunch of cards and then - if I understand your approach correctly - putting them back in one by one? While watching how the trouble LEDs on the controller card act? (in other words, see which card triggers error codes) Is this what you had in mind with that? This is path "B."

Unfortunately, this is part of path A - the launch of the digital part of the device. Further tuning uses a rich set of self-test tools for the instrument itself. And for this you need to be able to read messages from the display. You do not have to make an insert board, you can solder the wires to the desired points and bring them up.

Connectors with a pitch of 3.81mm, I could not find. Be careful the internet is full of 3.96mm ones that don't fit.

[MegaVolt]

P.S. To access the above contacts, you do not need a debug board. They are located on the A2 board, which is accessible by removing the front panel.

[MegaVolt]

You can buy modern equivalents from Newark (and probably others).

Do you know the name?

[Rax]

You can buy modern equivalents from Newark (and probably others).

Do you know the name?

I'd also appreciate more specific information - part number, possibly link to one... Thanks much in advance.

[Rax]

The connectors are just standard (for the time) Cinch connectors - You can buy modern equivalents from Newark (and probably others).

I don't see any card edge connectors at Newark in the US with 3.81mm pitch, only 3.96mm. I am looking at other suppliers, but if I recall correctly, I ran into the same problem when trying to build extenders for some HP equipment.

[MegaVolt]

The part that is in the device itself has the TE Connectivity number 2-583407-0. Perhaps you can buy them.

I looked at the pci connector, they have a 1.27mm pitch. Those three pins per pin of the original connector. If you leave two out of three, you get a pretty good connector. Like this: 00_00_00_00_

[Rax]

P.S. To access the above contacts, you do not need a debug board. They are located on the A2 board, which is accessible by removing the front panel.

Here's how I set this up last night. This should allow access to the boards (at least for pulling) and the front panel too.

[MegaVolt]

Here's how I set this up last night. This should allow access to the boards (at least for pulling) and the front panel too.

You can disable the keyboard. This will add space.

[Tony_G]

I don't see any card edge connectors at Newark in the US with 3.81mm pitch, only 3.96mm. I am looking at other suppliers, but if I recall correctly, I ran into the same problem when trying to build extenders for some HP equipment.

Just looked at the part and yes you're right - While they are Cinch connectors, the specific part is a 0.150/3.81mm spacing - For all of the HP gear I have, I used 0.100/2.54 spacing connectors which I have bought from Newark.

No idea where you would get these ones - You might want to try reaching out to Fluke and asking - They might have a current part number for the connectors.

TonyG

[Rax]

You can disable the keyboard. This will add space.

As I'm further taking this apart, I am concerned about this ribbon cable in a sleeve which seems stressed the way I have this setup currently (see pic). Do I need to sit this to work on differently? Am I putting that cable under too much duress?

Edit: the way the forum mangles pictures in what seem like a capricious, random manner, no one'd be able to tell what they're looking at. The pic is upside down. So the ribbon in the black sleeve, even if the unit stands on the side railings on this bench I have it on, is a bit pressed under the unit.

[MegaVolt]

The black cable is the connection between the front panel and the A16.  It's just a flat cable.  Black insulation is protection against breakdown of high voltage that is in the device.  It shouldn't be damaged.

[Rax]

I've taken a bit of a step back and looked at the other threads on this unit and sim. It seems I also am looking at some trouble on A19, though different than essele. I see higher than expected voltages on the unregulated rails on there:

• TP1: +39V
• TP3: -40.5V
• TP4: +9.4V
• TP5: +9.9V

I'll take the board off and look for trouble, probably recap it and get some ballsy diodes in there to allow for lower/easier dissipation, but I'm a bit unsure how unregulated supplies can be this much off. For reference, I'm measuring this with my Fluke 189.

Any recommendations on what type of diodes to use? I should have some either Schottky or soft recovery all the way to TO220.
________________________________________________________________________________________________________

Later: The hole size seems to exclude my "non-TO220" options. So, from the TO220s I have at hand, I'd probably go with either VT5202 (5A/200V), or STPSC110065D (10A/650V) or MBRF10200 (10A/200V), all Schottkys.
________________________________________________________________________________________________________

Even later: In case anyone's wondering, I didn't check for ripple to explain the values above. It's all apart now, so I'm just going to proceed with the recap and... "rediod?..."  and rebuild this board. Should probably also see if any of the resistors has drifted.

[Rax]

Well, a CR1 bridge, C1, C3, C4, CR2, and CR3 "later," I still have high DC on at least TP1 (vs. TP2 taken as ground). I also have high ripple - about 1VAC - on the same test point... Given all rectifiers (except CR5/6) and all electrolytics are new, I just can't explain the ripple and high DC reading. Any pointers are welcome.

As a next step, I can think of verifying all resistors on the board, but I can't really imagine how they'd cause these symptoms. The other thought I have is some MB-level leak, which would be pretty bad news troubleshooting-wise.

I should also probably do the cards pull - and I guess my question from those having done it with this particular unit is if it the order and combinations of boards populated matters (can I break anything with al ill combination of populated boards?) - and see if that changes anything on the voltages I see, and therefore potentially localize trouble on one of the cards.

[Rax]

I decided to stop obsessing about unregulated supplies as long as the regulated side is in the ballpark. To that end, I enclose measurements from a couple of weeks ago, and then another set from this morning. In between, I've not only fixed the +-30V rails on A10, but also recapped and used 10A TO220 Schottkys on the high draw rail of A19.

In any case, a couple of questions to those that have similar units (and obviously, everyone else wanting to pitch in):

• Most voltages are close enough, though I will go ahead and adjust, as some seem to need to be dead on. For instance, could anyone confirm the TP1/TP2 measurement on A17 is supposed to be +5.15V +-0.00V? As the adjustment page (enclosed) calls it. This is a bit awkward, as the voltage there is labeled as "+5V" everywhere - on the schematic, PCB, etc. This seems pretty important to clarify before I dial that supply to 5.15V which is not a minor variation from 5.00V
• On board A5 I have a burnout spot around R102/R5/VR1. I pulled their legs and measured and the resistors seem fine. Also, VR1 drops 12V over itself. This seems to be confirmed by the SM part number, but not the description - the latter seems to indicate a "20.0V" zener. Can anyone confirm which one it is?

Thank you.

[Rax]

Unfortunately, this is part of path A - the launch of the digital part of the device. Further tuning uses a rich set of self-test tools for the instrument itself. And for this you need to be able to read messages from the display.

Working towards this goal. I don't feel I have clarity on what to do with the pulling of the cards process, but I'm taking it one step at a time and working towards hooking up my logic analyzer to the data lines.

Now, the interesting thing is I see no resemblance between my A2 PCB and the PCA in the wide circulation Service Manual. The Artek-sourced one has exactly what my board has (see attachments below). Megavolt - please let me know how you think that changes where I need to connect my logic analyzer to read those characters. For instance, I see D0 through D5 on U31 pins 9 through 4 - so that's six channels. Where does the seventh connect?

[Rax]

Due to size limitations, separate post with pics of my own A2 board.

[Rax]

BTW - unfortunately, the Artek Media SM doesn't have the 5440A specifications either.

[MegaVolt]

Thank you so much for these schematics!!! I didn't have them.

The point you need is on the u4 chip pin 4.

I have attached a small specification for the 5440a. But considering that all the circuitry completely coincides with the 5440b, I think you can safely take the specification from there.

The only difference is in the maximum output current.

[Rax]

Thank you so much for these schematics!!! I didn't have them.

Thank you for all the thinking on this with me!

The point you need is on the u4 chip pin 4.

You're a person of few words... I think you're saying this is the revised "letter writing signal" from your prior post (U4/pin4). Can you confirm? This would be one channel for the logic analyzer.

Can you also confirm the data lines are where I assumed them to be? (U31/pin9-pin4). Six more channels.

I also think there is a "0x20" to be read to better legibility - are we able to tell where to collect this data? One more channel to read here.
 
This would make eight channels to look at. If all of the above get confirmed, I should be able to read these shortly. I'd really be out of my mind happy to start registering some actual progress.

[MegaVolt]

I write through google translator, so I try to write briefly so that there are no mistakes ))

1. U4 pin 4 - write signal. The logic analyzer needs to be told that this is a rising edge clock signal.

2. Before starting work, you can check with an oscilloscope the presence of a signal on the U4 pin 4 line. This will indicate that the processor is trying to transmit data to the screen.

3. Data can be taken anywhere. It is possible on U31 pin 4-9. But better at the output of U31 pin11-16. It is also possible on any chip where there is D or D'. D is data from the processor. D' data after buffering. It is better to take the data after the buffer.

4. You will see data less by 0x20 i.e. the analizer will show 0x00 and this will mean 0x00+0x20 = 0x20 (Space ASCII).

4. I did not understand about the eighth channel. Seven should be enough.

[Rax]

I write through google translator, so I try to write briefly so that there are no mistakes ))

Thank you! All good and clarifying that is appreciated

[Rax]

2. Before starting work, you can check with an oscilloscope the presence of a signal on the U4 pin 4 line. This will indicate that the processor is trying to transmit data to the screen.

I tried this and I see some sort of pulses - one every couple of seconds o so. May be a good sign, but maybe it's trying to start up and shuts down on a fault condition. I did this just as a general measurement with a 10x probe relative to the 5V GND, but I can apply a different protocol to looking at these - ECL or TTL on my 54522A scope.

[Rax]

Here's some data I just collected. This is with all cards present. I have no idea if my collection protocol produces legible data. Again, I'm new to this, so please feel free to comment, etc.

I am not sure whether I should see anything on Channel 0 (which goes to pin 4 of U4). Channel 1 through 6 goes to pins 11-16 of U31. With the Hantek, you can make Channel 0 the "source" of the vertical cursor, so that's what I did. I assume this makes it the trigger channel. I can't see much else in the software (rising edge etc. be darned).

[MegaVolt]

Synchronization doesn't seem to work I haven't used this logic analyzer and can't tell you how to set it up.

But something can be done.

1. Is the GND pin of the logic analyzer connected?
2. Can you increase the capture rate to 4M for example
3. Since we are writing all the data, we need to increase the recording time to 2-3s from switching on. Those. sample rate*3.
4. Does recording start when power is applied? Or is it data captured at a random moment in time?
5. How are the thresholds configured on the logic analyzer?

In the data that is, I do not see anything meaningful. There is one place where the zero channel drops to zero. But he is in it for a very long time and I do not see meaningful data there. It is possible that any of the above will correct the situation.

[Rax]

Synchronization doesn't seem to work I haven't used this logic analyzer and can't tell you how to set it up.

But something can be done.

1. Is the GND pin of the logic analyzer connected?
2. Can you increase the capture rate to 4M for example
3. Since we are writing all the data, we need to increase the recording time to 2-3s from switching on. Those. sample rate*3.
4. Does recording start when power is applied? Or is it data captured at a random moment in time?
5. How are the thresholds configured on the logic analyzer?

In the data that is, I do not see anything meaningful. There is one place where the zero channel drops to zero. But he is in it for a very long time and I do not see meaningful data there. It is possible that any of the above will correct the situation.

• I connected it to TP1 (5V GND).
• I enclose a couple of readings at 16M.
• I think this is covered by the above?... The only other thing I can change is the sample length, and I kept it at the maximum possible value of 1M.
• I can press on this "play" button and it collects at that time. Strangely, I seem to see it changing occasionally (?), so maybe it keeps collecting? I wonder if the readings changing at no prompt has to do with the cursor being triggered by Channel 0. But I never see any "1"s on Channel zero - always completely black.
• I don't seem to have any control over them. I assume it's in the software - some sort of auto-detect of the protocol - but overall, a very disappointing experience with this Hantek.

[Rax]

I am less and less convinced U4 passes anything - I see these faint pulses at random intervals (I really need to watch very closely and I may still miss it, and it may just be the triggering system on the scope trying to grab something that's not quite there), while I do see some noisy DC at the inputs of that U4 gate (in the order of about 100mV). I am not sure how regular/compliant conditions should look like, but I can persist with a bit of direction, including scope and/or logic analyzer setup.

[Rax]

• Most voltages are close enough, though I will go ahead and adjust, as some seem to need to be dead on. For instance, could anyone confirm the TP1/TP2 measurement on A17 is supposed to be +5.15V +-0.00V? As the adjustment page (enclosed) calls it. This is a bit awkward, as the voltage there is labeled as "+5V" everywhere - on the schematic, PCB, etc. This seems pretty important to clarify before I dial that supply to 5.15V which is not a minor variation from 5.00V
• On board A5 I have a burnout spot around R102/R5/VR1. I pulled their legs and measured and the resistors seem fine. Also, VR1 drops 12V over itself. This seems to be confirmed by the SM part number, but not the description - the latter seems to indicate a "20.0V" zener. Can anyone confirm which one it is?

Thank you.

Anyone having more info on this? (MegaVolt? essele?). Should the +5 rail be adjusted to 5.15V? Is that zener 12V or 20V? Not sure if either of you has adjusted the rails and/or may have easy access to measure that zener drop in a unit working optimally.

While scratching my head over figuring out what's going on with the A2 board, I am also trying to make sure there's no weird behavior simply triggered by out-of-adjustment rails (which so often result in the most puzzling symptoms and behavior, isn't it?).

[MegaVolt]

1. Data must be taken immediately after power on. The instrument updates the screen only when parameters are changed. If this is an error message, it can only be one. And no repeats.

2. There was a failure with the logic analyzer.

3. 5.15V supply is within +/-10%. I don't think this is a problem. But you can probably adjust it more precisely.

4. You can try using an oscilloscope. By putting one channel on u4 pin 4 and see if there is a correct signal after turning on the power. You should observe a logic 1 most of the time and short pulses of a logic 0. (a few µs). If you find them, you can look at the rest of the oscilloscope channels on the data line, taking data one by one This is not convenient. But I don’t see other ways.

It may be possible to find information on using the logic analyzer on the net or on this forum. And it will turn out to get the desired mode of operation from it.

[Rax]

Thank you, MegaVolt, you've been very helpful through this saga and I really appreciate it.

There's obviously a "1" state on U4/pin4, and I've been trying to snapshot the state change to it when the unit it turned on. Somehow, the measly "half-a-buck" logic analyzer started to work, and I enclose a couple of readings at different settings. I am reviewing and trying to interpret this data myself, but if anyone is proficient at reading this and there's something useful in there, please do share.

[Rax]

One more data dump, this time with what I think is proper triggering ("high level" on U4/pin4), and with the channels named appropriately. I haven't used "sigrok session files" before, but I assume they embed all info picked during the data collection session. I did 5Ms @ 2MHz, so 3s collection.

Hopefully this is legible. I am doing this with PulseView, and I think it has some built in protocol decoders. What protocol is appropriate for this data? I assume a properly configured decoder would be able to interpret for me what exactly are the annunciations sent to the display.

[MegaVolt]

This data is still short.

I tried to display the correct data in the figure.

You can see it there.
1. Turn-on moment (all lines go from zero to 1)
2. RESET time.
3. Beginning of the processor. This is good.
4. Further, 1.7s after the start of the processor, the screen is accessed. I drew it.

Try to take them off like this.

The decoder can be set in parallel.

[Rax]

This data is still short.

Here's a 10 seconds read at 1M. What decoder is suitable for interpreting this? I've tried a few yesterday but only got gibberish out.

[Rax]

With the "7-segment display" decoder I see a repeating "bKH98" from a point on. Not sure if this is anything or as nonsensical as it seems.

[MegaVolt]

The data looks weird.  In the data that was before, the data was filled evenly.  In this data, one bit has large gaps.  This is weird.  Perhaps the sampling rate of 1M is not enough.  Or the processor has started badly

[Rax]

The data looks weird.  In the data that was before, the data was filled evenly.  In this data, one bit has large gaps.

Here's a couple other readings. Maybe let's assume worst case scenario - maybe the processor is bad. Are these unobtainium?

[Rax]

Attachment(s) were too large for a single post.

[Rax]

Are these unobtainium?

Both U5 and U16 seem pretty easily obtainable in the US, from some vendors I've used through the years and trust. I don't think I need to be swapping parts yet, not having narrowed down yet the issue(s), but just for reference.

[MegaVolt]

Maybe let's assume worst case scenario - maybe the processor is bad. Are these unobtainium?

1. The processor is the most common Z80, it is very common and it is not difficult to get it.

You can also swap chips between A2 and A16 boards. There is exactly the same processor. But from the data that I see the processor is working. It may have bad contact or wrong program.

2. You can check the data in the memory chips. If you have a programmer you can get them and check the data.

3. About the data.
I talk about how the data should look so that you can check it yourself. This will greatly speed up the check.

Below are two pictures. On one of them, as the data should look like. On the second there are places without data. It should not be. Files where there are gaps in the data are meaningless and of no interest. There is no point in posting them.

If there is no signal on u4.4, you can try to stand on u28.15 or u28.14.

[MegaVolt]

Another sign that the A2 board processor is working will be the FAULT error LED lighting up some time after switching on.

[Rax]

Another sign that the A2 board processor is working will be the FAULT error LED lighting up some time after switching on.

If a delay from actuating the power knob to the moment of the FAULT LED coming on is the critical aspect here - I can confirm there's no delay at all. The FAULT LED on A2 is turning on at the exact time the instrument is turned on. At least to my eyes.

[MegaVolt]

I checked the diagram. This is the correct behaviour.
Immediately after the reset, the LED lights up. If all is well, it should turn off.

But for this, both boards, A2 and A16, and the connection between them must work. For that reason, I wouldn't count on it.

[Rax]

Thank you, MegaVolt.
This far, given enough run time, it seems those interruptions are inevitable. I probably should investigate if there's any sign of trouble on that specific data path, hardware-wise, that may corrupt it.
But from the data accrued, for the healthy segments, were you able to decipher anything useful?...

[MegaVolt]

But from the data accrued, for the healthy segments, were you able to decipher anything useful?...

I'm sorry ... From the data collected, there is little that can be said.

I see that sometimes it turns out to collect good data. Sometimes not. I don't really understand what this is about. Possibly bad contact? Or the influence of probes.

The device shows signs of life. But something gets in the way.

[Rax]

I will seek to collect the data at different points in the chain, maybe at some particular step it gets corrupted (in the hardware, I'm thinking).

[Rax]

Taking a closer look at this I observe what I didn't notice before - U20 seems to be missing on my A2 PCB. Is this normal?
_________________________________________________________________________________________________

Later: U20 is noted as a "SPARE" on p7-9. So maybe it missing from my board is not out of order?

[MegaVolt]

Taking a closer look at this I observe what I didn't notice before - U20 seems to be missing on my A2 PCB. Is this normal?
_________________________________________________________________________________________________

Later: U20 is noted as a "SPARE" on p7-9. So maybe it missing from my board is not out of order?

This chip is not installed. At least for my device, its absence does not prevent it from working.

[Kleinstein]

From the footprint is looks like U20 would be another RAM chip. It could be place just in case the SW may need more memory than expected or alternatively use samller size RAM chips and more of these (e.g. 3 x 1 K instead of 2 x 2 K).

[Rax]

From the footprint is looks like U20 would be another RAM chip. It could be place just in case the SW may need more memory than expected or alternatively use smaller size RAM chips and more of these (e.g. 3 x 1 K instead of 2 x 2 K).

The SM makes this a bit confusing - while the schematic calls it "RAM" (p.7-9), the parts list calls it a CD4514BE on p.5-12 (actually, a "CO4514BE," but I don't think that part exists), which would obviously be a CMOS Latch/Decoder. All things considered, I think it's a memory chip that's not being used, like you point out.

[Rax]

Grab KiCAD and create a simple board that passes from an edge connector to whatever you get from Newark.
TonyG

TonyG - just wondering if you're aware of footprints in KiCAD for card edge connectors with 3.81mm/.0150" pitch. I have not found any and maybe they exist somewhere. I'll seek to create them, but I'm not entirely sure how involved that'd be.

[Tony_G]

I couldn't find any - I had to create my own for use in some 8350B plugins.

https://www.eevblog.com/forum/kicad/kicad-0-1-card-edge-connector-definition/msg4192591/

TonyG

[Rax]

Proto extender boards just about ready to be tested. EDAC makes these in pretty low order runs, but it takes a couple of months or so, so here we are.

I need to fix a couple of things - one of which (DUH!!) being that I only provided corresponding notches for one of the positions (and, expectedly, they are all placed at a different locations for each given module position) - and that I need to figure which version (I have a "short" and a "long" one - the latter being the same size as the existing boards, the former being a bot shorter, such that boards plugged into it would partially insert in the vertical guides for a bit more rugged operation).

I will make these available, one way or another, once tested and vetted.

[Rax]

Just a pic or two as to why I made a "short" version (as opposed to the "long," which is as long as the actual modules). It seems to be working pretty well.

I need to fix the boards (a couple more bugs as I look at it closer), and will make a more permanent version soon.

This would at last allow me to troubleshoot a bit more easily (and apply SM procedures).

[Rax]

While still waiting for revised boards, I thought I'd give a run to my new rework setup - a Pace SX90 w/ an MBT PS (which I'm just in love with, BTW... Highly recommended).

Recapping is the obvious use for this rig, and so I started looking at the boards a little closer, and noticed that C6 on A5 (Output/HV Control) was leaked and corroded a bunch of resistors in its proximity (see pic). I haven't noticed this before - my bad. Damage was so bad, R9 essentially seem to have had one leg almost severed (not not glaringly obvious, at least until I tried to remove it, and one leg just came off). I went ahead and replaced C6, R9, R10, and - why not? - recapped the entire board. The SX90 IS that much fun.

Upon putting it back, I see the same warning lights and all, and think - darn, no progress... - but as I'm thinking this, C18 literally blew up. Brand new cap, correctly polarized, voltage rating exceeding original... What gives? I feel this may be hitting at the core of at least one issue with this unit, though what that is exactly, I am still processing.

For instance, why is C18 (and C17, for that matter) only rated for 35V? (see enclosed pic) They seem to (potentially?) be exposed to 175V... Is there a floating ground aspect here I need to factor in (reducing exactly how much those caps are "seeing?").
__________________________________________________________________________________________

I ran the unit with A5 pulled and it seems to exhibit the same behavior as before (same blinking LEDs on the controller board, no PS errors LEDs on, same "8000000" on the left screen and "squares...1/squares...0...." on the right screen). Back to the drawing board.

[Rax]

[...] C18 (and C17, for that matter) only rated for 35V [...]

I just ran the unit with C18 out, and it's seeing about 17V... Looks good to me. Except that - unless my eyes deceive me - it's reversed polarized?... I'll need to double check this later, I am unsure this would be possible (other than that the "float" doesn't elevate enough and the -175V ends up "below" the "S"/"P COM"?...).

Let's keep in mind that, though they don't seem damaged, R102 and VR1 are very "toasty" (see charred PCB in pic).

Sorry for my undigested thoughts, but I'm hoping someone else with knowledge of this unit could think with me on this and help clarify what's going on here.

[Rax]

Well, mystery solved (??).

I'm pretty certain I've experienced a... triple whammy! The schematic, the type of pad on the board (where square equals positive leg), and even the actual capacitor placement for C18 was reversed... No wonder it failed, though it failed far less spectacularly than the cap I used as a replacement. The original seems to just have dried down and leaked very inconspicuously in its misery.

But spending a minute with the schematic makes it obvious C18 and C17 cannot be placed back-to-back like that (assuming that "S" is a module ground and voltages coming in are polarized as per schematic). But measuring over C17 and the C18 (unpopulated currently) shows that indeed these two caps are standing "atop" each other and so the placement as done by factory is incorrect. Oh, and BTW - what I thought is +-175V needs a dot after the first two digits... I am also pretty sure that's supposed to be 17.5V. I got tricked by the HV word in the module name, and, in my defense, I get bits and pieces of time for this currently so it's more like trickle progress.

Not the first PCB and manufacturing error, but still pretty surprising. Can anyone possibly confirm my conclusion above? I don't think I've seen this mentioned anywhere. Maybe I have an early production board and this was addressed later.

[bdunham7]

Not the first PCB and manufacturing error, but still pretty surprising. Can anyone possibly confirm my conclusion above? I don't think I've seen this mentioned anywhere. Maybe I have an early production board and this was addressed later.

Can you verify the actual voltage and polarity across the capacitor under power with an operational circuit?  There have been examples of PCB layouts being wrong before.  And are you sure of how the original (?) capacitor was installed?

Edit: After looking at the schematic, yeah that has to be wrong...

[Rax]

Can you verify the actual voltage and polarity across the capacitor under power with an operational circuit?  There have been examples of PCB layouts being wrong before.  And are you sure of how the original (?) capacitor was installed?

That was my "sanity check" - turn this on with C18 out (it just decouples the rail...) and measure polarity and voltage across C17 and (C18). It checks out.
I am just about positive the cap that was there (and leaked) was original - no reason to suspect it's been replaced.
Also, I always take good pictures prior to taking parts off, for this kind of thing happening. The picture clearly shows how they were back-to-back against that ground.

Edit: After looking at the schematic, yeah that has to be wrong...

I've occasionally ran into various degrees of messup like this (HP, Tektronix), but this one beats my prior encounters by being a "triple whammy!"

[Rax]

And are you sure of how the original (?) capacitor was installed?

Pic enclosed.
I also got confused between the leaked C6 - having nothing to do with this - and C18, which seems to have been able to withstand reverse polarization with no aggravation for a long time. Maybe also died an early, quiet death?... I'm not sure I can still tell which one's which in the small pile of removed caps to check its health on my meter.

[Rax]

Continuing my work on this while still waiting for the extender PBCs.

I found quite a few leaked capacitors across different boards last night. For instance, on A14: C28, C29 (I also replaced the affected resistors). I used 1% resistors, but I don't think any of those is of critical value (affecting calibration, I mean by that).

MegaVolt - my unit, overall, exhibits similar symptoms to yours (having watched your video, pretty much except the front panel board light being continuously on, and no lights on the PS boards, as I fixed those). Can you please elaborate how you investigated U22 on A14 to realize it's faulty? I wonder if mine could be at fault also. Oftentimes, the same parts fail in the same units due to a variety of conducive conditions (marginal design vs. specs, etc.).

[Rax]

Here are videos of my issues - troubleshooting lights and front panel displays.

https://youtu.be/IORA5uATvQo

https://youtube.com/shorts/DxgEM9nHz4A?feature=share

[Rax]

I finally went ahead and did what you asked a while back, MegaVolt - I pulled all boards within the INSIDE/GUARD cage (A4 through A10) + A14 from outside of it. I am getting the exact same error lights from A16 and A2.

I guess this confirms what we knew all this time - that the issue resides in one (or both) of these modules. But it seems to eliminate the possibility that any of the other boards is at fault. Which also means it'd make no sense to try putting them back in a sequence (as obviously there's nothing to observe with that). I feel this is essentially the first major step forward with my unit throughout this saga this far.

I am considering doing the following next:

• go through the fault module isolation steps at 4-28
• depending on what I find the above (though maybe not in this order) try swapping the spare microprocessors I have in A2 and A16
• possibly try replacing the UART IC that you, MegaVolt, found defective
• try reading the memory chips (though I'm apprehensive about deleting them as I try that, so this is a last resort step)
• .......?

[MegaVolt]

Can you please elaborate how you investigated U22 on A14 to realize it's faulty?

My block worked a little and gave out a "communication error" between the boards. There is a communication cable between the boards. Communication protocol TTL_RS232.

I observed the exchange but one of the bits was stuck and did not change. At the input of the microcircuit, the data was correct. So it's a chip failure.

And my topic has examples of the exchange protocol. You can check it against what you see.

Regarding other errors:

1. Judging by the video, the A16 board starts working and successfully checks the bootloader, memory and interrupts and stops on the exchange with the front panel.

2. The front panel seems to be starting to start, but for some reason it does not have time ...

I would do the following:

I would also extract the A16 board and deal only with the A2 board. It should start up on power up and give an exchange error.

You can check the reset circuits, the capacitors in these circuits.

[Rax]

Tried one other thing - replaced the A2 microprocessor (U16), to no avail. It was worth a shot.

[Rax]

Alright, we have good working extender cards. Yeah!

Now, as I'm going ahead with the SM steps, a couple of confusing points I would appreciate some thinking along with me:

• What should be the default state of the troubleshooting switches? I am referring specifically to those on A2 and A16. Mine were all in the OFF position (which seems to be tagged as "1" by the troubleshooting switches schedules notes, which is quite counterintuitive). See pic for how I found them.
• At p.4-31, section 4-28, step 3 calls for S1 to be switched to "0." I assume this to be the Controller S1 (A16). This though has four different sections. Does this mean it needs to be closed circuit ("0") on all four sections?...
• Step 5 is clearer, where I guess all sections need to be in the way they spec - first, second and fourth closed circuit, third open.

Am I reading the above correctly?

[Rax]

My working hypothesis is all four sections of the switches need to close.

If I do this on the Controller/A16, and then dial S1 to 0010 (after the unit fully starts), the Guard Crossing/A14 LED starts flashing - like there's data being transmitted to it every second or so (which seems to match Table 4-4). All four LEDs on A16 stay lit.

But I've been unable this far to find any consistent logic pulses on P80:24/25 and 2/22, as per 4-28 steps 6 and 7.

No progress whatsoever. I'll try to pull A2 tomorrow and see if there's anything visible that needs addressing.

A question for Megavolt - given the interruptions in data we've seen prior, what sort of failure you'd think could trigger that? Maybe I should try to work back on the signal path and see where it gets corrupted - though I frankly do not understand the circuitry enough to think this through.

BTW - does anyone have any good tips on removing and reinserting large DIP ICs? Such as 40 pin. I have a Radioshack inserter that is pretty good, and recently purchased one of those Jonard EX-2s for pulling, which is a complete POS. A well thought through puller would have large jaws locking on the IC body (not the typical, 1/8" or whatever all these crappy tools have), and rails that would mechanically push against the socket as one engages some lever or whatever. Anything else puts the PCB at risk. I still have to see a toold that's designed this way. Maybe I should model and 3D print it...

[alm]

BTW - does anyone have any good tips on removing and reinserting large DIP ICs? Such as 40 pin. I have a Radioshack inserter that is pretty good, and recently purchased one of those Jonard EX-2s, which is a complete POS. A well thought through puller would have large jaws locking on the IC body (not the typical, 1/8" or whatever all these crappy tools have), and rails that would mechanically push against the socket as one engages some lever or whatever. Anything else puts the PCB at risk. I still have to see a toold that's designed this way. Maybe I should model and 3D print it...

I find that using a large ish screwdriver as a lever between socket and chip works better since it's more controlled and puts stress on the socket instead of on the board like with the cheap and nasty IC puller. I think I might have seen a tool like you describe in a catalog back when DIP was more common. Just make sure you work gradually and from both sides to prevent bending the pins on one side/corner.

[Tony_G]

I bought the previous version of this and it does a good job - You have to be careful to ensure that you keep moving it under the IC otherwise you'll bend pins at the other end from the lifter.

https://www.digikey.com/en/products/detail/wiha/27922/11585736

TonyG

[Rax]

I bought the previous version of this and it does a good job - You have to be careful to ensure that you keep moving it under the IC otherwise you'll bend pins at the other end from the lifter.

https://www.digikey.com/en/products/detail/wiha/27922/11585736

TonyG

That's very interesting... I actually have a similar tool, from a larger set for desoldering. I had no idea it's (also?...) intended for extracting ICs. Good to know!

[MegaVolt]

Let's go in order.

Read my previous answer and recommendation to start with the A2 board. board A16, judging by the LEDs, is more or less working, which means that the switch for testing A16 was in the correct state 1111 this is the position for work.
This means that all switches must be open (high resistance). You can check with a multimeter.

Here are two tables. Several lines are of interest.
For A2
1. display test
2. Exchange test with A16 board. The same byte is continuously transmitted. Can be observed with an oscilloscope or analyzer.

For A16
1. Exchange test with A2 board. The same byte is continuously transmitted. Can be observed with an oscilloscope or analyzer.

Accordingly, I propose to get A16 and put it aside. And only work with A2. The monitor test should show some changes on the screen. The exchange test will show the health of the communication channel.

Until this is passed, there is no point in touching the A16.

[Rax]

On a relatively different track, if anyone in this thread is interested in a pair of extenders (short version at this time), please PM me.

[Rax]

For A2
1. display test
2. Exchange test with A16 board. The same byte is continuously transmitted. Can be observed with an oscilloscope or analyzer.

[...]

The monitor test should show some changes on the screen. The exchange test will show the health of the communication channel.

Until this is passed, there is no point in touching the A16.

If I'm starting the unit with A2 S1 switch all closed/on (0000) - A16 S1 switch stay 1111 - I see some minimal changes to the screens (see image below). Unless anyone can read something relevant on this screen state, I remain of the mind that this is essentially random. BTW, it may change next time I do this. But some changes seem to occur when doing this, though they may just be random changes between consecutive unit startups which would happen anyway.

Under the switch state above, RINT (which I measure with a Fluke 8840A on pin 7 of A2/U1) is low (around 150mV). If then I switch S1-2 to 1 (open/off), RINT stays low. I assume RINT needs to switch to high (5V?) for the "0100" switch mode troubleshooting mode to be active. BTW - I'm not sure how to check the presence of the "ASCII character, ACK, [being] continuously sent to the front panel interface circuit."

[MegaVolt]

I advise you to remove the A16 board from the device.  It may interfere with the operation of A2.  Communication between the boards is described in the link.  with waveforms.

https://www.eevblog.com/forum/metrology/fluke-5440a-repair/msg3616353/#msg3616353

[Rax]

I advise you to remove the A16 board from the device.  It may interfere with the operation of A2.

 

Sorry, but I am not following... If I remove A16, how would they communicate? I think I need to be assessing their capability to exchange data and I'm not sure how that'd occur if one of them is removed.

Communication between the boards is described in the link.  with waveforms.
https://www.eevblog.com/forum/metrology/fluke-5440a-repair/msg3616353/#msg3616353

Thank you, MegaVolt, but your quoted post makes no mention of where and how you measure those waveforms. Where did you connect your scope/LA (by far the biggest question here), and what were the measurement settings? Trigger (y/n, if y on which channel?), ground, etc. I can't tell what I'm looking at without that context.

So I went back to the SM and spent some additional time with 4-28 and 4-29 from p. 4-31 and 4-32. I am not sure how this is possible, but I am not seeing any "pulses" or "logic activity" on P80-2, 20, 24 and 25, regardless of the troubleshooting switches (or instrument collecting data) settings.  .

I tried my 54522A scope (including on the two logic modes available, ECL and TTL), and the "toss a coin to know if it'll work this time" KeeYees (WTF?...) logic analyzer. I collected ground from the A16/Controller TP1 (GND). 

The universe has just decided this project will stay stuck on me regardless of how much work I put in it.

 

[Rax]

One thing I just realized, is that jumpering E6 to E5 instead (on A16) - which means flipping the A16 jumper to the other possible position - disables the watchdog reset, which in turn stops the restart loop my unit's been since day one. This I think is intended to allow for further troubleshooting of A2.

I'm not sure if very useful, but I'll be trying to see if this allows me to collect more information on A2.

[MegaVolt]

Sorry, but I am not following... If I remove A16, how would they communicate? I think I need to be assessing their capability to exchange data and I'm not sure how that'd occur if one of them is removed.

Checking the exchange is the next step. First you need to check that everyone is trying to say something to the other. The fact that there is no other is not a problem.

The A16 board works for you and stops on the exchange with A2.
So the problem is A2. She needs to be dealt with. A16 can be put aside. You can leave )))

Thank you, MegaVolt, but your quoted post makes no mention of where and how you measure those waveforms. Where did you connect your scope/LA (by far the biggest question here), and what were the measurement settings? Trigger (y/n, if y on which channel?), ground, etc. I can't tell what I'm looking at without that context.

So I went back to the SM and spent some additional time with 4-28 and 4-29 from p. 4-31 and 4-32. I am not sure how this is possible, but I am not seeing any "pulses" or "logic activity" on P80-2, 20, 24 and 25, regardless of the troubleshooting switches (or instrument collecting data) settings.  .

You are interested in pin 25 of the UART chip (A2 U5). This is the data output to the A16 board.

Data can be transferred once when the power is turned on. You need to put one probe of the analyzer on a 5V supply and set it to trigger once when this signal appears. And put the second on 25 pin. And connect the ground. then, when the power is turned on, the analyzer will write data among which it will be possible to find one byte that was transmitted.

If it is not there, something is possible with the A2 board. You need to be busy troubleshooting on it.
1. Check the reset.
2. Check clock.
3. View other signals on the processor - WR, RD, MREQ, IOREQ, M1, A0...A15, D0...D7
4. Check the content of the memory chips
5. And then look for a microcircuit that does not do what it is supposed to.

You can record signals with the analyzer in different places of the circuit, and I will say if they are similar to what they should be. The recording conditions are the same as above for UART. 7 signals can be recorded at one time.

This can be a long-term activity. Perhaps it makes sense to open a separate topic for this. I think there are a lot of people here who can customize the Z80

[MegaVolt]

Here is the waveform.
The first data transfer starts about 1.5 s after power is applied. This means that the analyzer must record more than 2 seconds from the start of power up to see the data.

[Rax]

Thank you very much, MegaVolt. This provides very welcome clarity.

[Rax]

MegaVolt - thanks again, I will hop on that route you point out relatively shortly.

In the meantime, I probed some more some of the data lines at A16 (those pertaining to troubleshooting steps 4-28 and 4-29). Posting this data here for analysis and hoping it may provide some clues.

I collected this with the watchdog suspended by switching the jumper on A16 from E6 to E5. In this situation, the restart/reset loop is being broken and the unit stops on the state where the FPC and the CR4/FAULT on A2 stay lit.

1. All troubleshooting switches in "operational," default state (1)

• P80-2: there's a bunch of states' changes (high/low switching visible on scope), until the circuit stabilizes high (about 3.2V)
• P80-22: same, around 3.5V. The circuit stabilizes low.
• P80-24: nothing going on past maybe 220mV of fluctuations. This one's dead.
• P80-25: this one has some high/low events, until it seems to stabilize high at around 3.5V

2. Troubleshooting switches per 4-28. Note I'm keeping A2 switches on operational, open/1 state for this step. A16 is 0010.

• P80-2: steady high state (3.5V)
• P80-22: about 500mV of flatlining
• P80-24: about 200mV of flatlining
• P80-25: comes high at 3.5V immediately

3. Troubleshooting switches per 4-29. Note I'm keeping A16 switches on operational, open/1 state for this step. A2 is 0100.

• P80-2: goes high immediately (3.5V), then low (about 500mV) a second or so later.
• P80-22: initially low (about 500mV of flatlining), then goes high at 3.5V and stays there. I think this sequencing/timeline mirrors the state of the fault indicator LEDs.
• P80-24: about 200mV of flatlining
• P80-25: comes high at 3.5V immediately

[MegaVolt]

MegaVolt - thanks again, I will hop on that route you point out relatively shortly.

In the meantime, I probed some more some of the data lines at A16 (those pertaining to troubleshooting steps 4-28 and 4-29). Posting this data here for analysis and hoping it may provide some clues.

I collected this with the watchdog suspended by switching the jumper on A16 from E6 to E5. In this situation, the restart/reset loop is being broken and the unit stops on the state where the FPC and the CR4/FAULT on A2 stay lit.

The FPC error is a communication error with the front panel. Those. this error will always be there until A2 answers.

By signals. It is very difficult to say something in words. It is better to watch them all at the same time with an analyzer.

On the P80, many signals are differential. Those. two wires. One is set to 1 and the other to 0 and vice versa.

[Rax]

By signals. It is very difficult to say something in words. It is better to watch them all at the same time with an analyzer.

I'd like to, but my "logic analyzer" works about a third of the time. It's so frustrating it makes it very hard to collect any data.

On the P80, many signals are differential. Those. two wires. One is set to 1 and the other to 0 and vice versa.

One thing that's been pointed out to me is that 24/25 are complementary, while 24 stays dead. I wonder if I should suspect U28 having at least one dead driver.

[MegaVolt]

One thing that's been pointed out to me is that 24/25 are complementary, while 24 stays dead. I wonder if I should suspect U28 having at least one dead driver.

I would disconnect the cable from A2 and check again. A2 can make corrections. If one signal changes value and the second does not change at the same time, this may mean that U28 needs to be changed.

[Rax]

I would disconnect the cable from A2 and check again.

Great point. A2 could clamp that line to ground. Will give this a shot.

[Rax]

A very quick, rushed check with the ribbon cable pulled from A2 (mostly looking at 24) seems to return similar results. Maybe U28 is the culprit.

One thing I don't feel I quite digested is where signals originate, which I think is important in this case. For instance

• 4-28, A16 being on 0010, the main MP "continuously updates the watchdog circuit." Now, I currently have the watchdog disabled, so maybe I need to retry with it enabled. It shouldn't change the weirdness I'm seeing with U28, 24 and 25 should just be complementary, period.
• 4-29 has A2 sending ACK "to the FP interface circuit" (is that out of A2 and to A16 via the ribbon cable?).

Anyway, a bit of thinking out loud here.

[MegaVolt]

A very quick, rushed check with the ribbon cable pulled from A2 (mostly looking at 24) seems to return similar results. Maybe U28 is the culprit.

Yes. It doesn't work according to your description.

One thing I don't feel I quite digested is where signals originate, which I think is important in this case. For instance

• 4-28, A16 being on 0010, the main MP "continuously updates the watchdog circuit." Now, I currently have the watchdog disabled, so maybe I need to retry with it enabled. It shouldn't change the weirdness I'm seeing with U28, 24 and 25 should just be complementary, period.
• 4-29 has A2 sending ACK "to the FP interface circuit" (is that out of A2 and to A16 via the ribbon cable?).

1. The exchange goes on a flexible cable.
2. In normal mode, the boards communicate for real.
3. In test mode, the boards simply transmit data and do NOT listen to data from the other side. This is done for ease of debugging. Data is sent periodically and can be conveniently checked with an oscilloscope.
4. The watchdog timer is turned off only when the block is fully operational. Those. passed all checks.

[Rax]

4. The watchdog timer is turned off only when the block is fully operational. Those. passed all checks.

With the "watchdog disabled," I meant A16 is jumpered to E5 instead of E6. I think this effectively disables the watchdog circuit (p.2-22 of the 5440A SM). Are we on the same page on this?

[MegaVolt]

With the "watchdog disabled," I meant A16 is jumpered to E5 instead of E6. I think this effectively disables the watchdog circuit (p.2-22 of the 5440A SM). Are we on the same page on this?

Yes I understand. Hardware disable watchdog timer. I described normal operation.

[Rax]

Yes I understand. Hardware disable watchdog timer. I described normal operation.

Great! Just making sure, for our consistency and clarity.

Also, there are some relatively minor differences between the SMs for the "5440 series" vs "5440A," but honestly a bit larger than I initially imagined. I don't think anywhere nearly as radical as concerning A2, but still, same things are on different pages, etc. I didn't quite get a chance earlier today to find the E5/E6 operation in the "5440 series" SM and wasn't quite sure what to make of that until just now.

[Rax]

Well, MegaVolt and the entire chunk of the whole internet interested in Fluke instruments and maybe just calibration stuff generally speaking... I think we have a living Fluke 5440A!!!

After many other investigations offline and the sweat and work associated with that, it seems the U23/704114 EPROM was corrupt. Once I got that reimaged (and a giant bunch of thanks to MegaVolt for making that available!!), the whole thing is back online. I am looking at a 9.9999997V right now on my Prema 6048 after a shorter than required warmup.

Happy camper doesn't describe it.

[bdunham7]

Wow, dedication pays off!  Just in time for your next project to arrive...

[Rax]

One may think seeing one of these may belong in a "Lord of the Rings" production, but when you see it repeatedly, sometimes during three consecutive 20s integrations, maybe it's objectively true?...
Nothing like enjoying the completion of one tough project, y'all.

[Rax]

when you see it repeatedly, sometimes during three consecutive 20s integrations, maybe it's objectively true?...

One more testimony added to Dr Frank's dedication to this unit. I'm not sure what others think, but IMHO, this may be in the 732A standard category (@ 10V)? I'd love to hear thoughts.

[MegaVolt]

Congratulations
It's a pity that we didn't think to check this earlier

Now you can update it to version 5440B as recommended here:
https://www.eevblog.com/forum/repair/fluke-5440b-psu-fault-check-gaurded-power/msg3071346/#msg3071346

[Rax]

Congratulations
It's a pity that we didn't think to check this earlier

Now you can update it to version 5440B as recommended here:
https://www.eevblog.com/forum/repair/fluke-5440b-psu-fault-check-gaurded-power/msg3071346/#msg3071346

Interesting, I was not aware of this. It seems to require an upgrade to the firmware, isn't that a fact?
I think my original firmware is 1.0, I wonder what others have seen on their 5440As. Maybe I need to flash all the EPROMs... I only did U23/704114 to make this work.

[MegaVolt]

It seems to require an upgrade to the firmware, isn't that a fact?

Yes.

I think my original firmware is 1.0, I wonder what others have seen on their 5440As. Maybe I need to flash all the EPROMs... I only did U23/704114 to make this work.

I find it difficult to say what exactly needs to be flashed to get version 2.1 (5440B). Boards A15 and A16 should survive flashing without problems. And perhaps they will be able to work with the old A2.

But I'm not sure if A2 can be updated. Unfortunately this will be an experiment. Which may end in failure.

[Rax]

But I'm not sure if A2 can be updated. Unfortunately this will be an experiment. Which may end in failure.

I'll seek to apply as much as possible the healthy principle of "if not broken, don't fix it," though that's a particularly challenging goal for people with our mindset... 
First step on that path is - research the subject until you feel you have a reasonable handle on it! 

[Dr. Frank]

when you see it repeatedly, sometimes during three consecutive 20s integrations, maybe it's objectively true?...

One more testimony added to Dr Frank's dedication to this unit. I'm not sure what others think, but IMHO, this may be in the 732A standard category (@ 10V)? I'd love to hear thoughts.

Well, I own my 5442A since about 2009, and often compared its +10V output to other volt-nuts standards.
From those data, I estimate its stability to +/- 0.2ppm/y, although it's only powered on, when to be used.
The ratio coefficients for the higher ranges (22V, 250V, 1kV) seem to be very stable as well, <1.5ppm over many years
I think I published these results as well.

Frank

[Rax]

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.

[Rax]

From those data, I estimate its stability to +/- 0.2ppm/y
Frank

What I'm seeing right now is pretty amazing. It's largely staying within the last count on the 20V scale of the Prema 6048, and oftentimes, as I posted above, it may register up to three (to my observations this far) 20 seconds integrations at 10.0000000V. This is with low-emf cables, in a relatively warm garage (temperature cycling is inevitable, but doesn't typically exceed 5C). I had 27C last night, today we were at 25C in the morning and I see 26C now.

This is with a modest warmup, no selfcal or really anything done to the unit. Another thing I should mention is the two halfs of the case are not installed, the unit just has the internal shields on. A little confusingly, it stays closer to 10.0000000V if I don't try to put something on top of the area where the fan is. I'd want to that so airflow is properly occurring inside the unit. But if I do, the unit adds quite a bit of error from the perfect 10V (at least by my Prema's opinion) - a few ppms or more.

Is this something that the internal calibration is addressing? I'm a little apprehensive about doing it, as the unit seems to be so dead on as is (but without the case on....). 

[Dr. Frank]

Last time I forgot to do the Int Cal. Difference was about 0.3ppm
The higher ranges may show more deviation w/o Cal.

[Rax]

Last time I forgot to do the Int Cal. Difference was about 0.3ppm
The higher ranges may show more deviation w/o Cal.

I'll try to first understand better exactly what the Int Cal is doing (there isn't anything useful in the Operations - unless I missed it - and will dive into the SM next to get a handle on that).

But I imagine it's exactly the first thing to do after closing up the case, to mitigate and adjust for slight differences due to internal air movement, parasitic external air/temp gradients, etc. Should I expect the output to be brought about as close to what my Prema says is 10V as I see it currently (while running it open and with a leaky path for the forced air for cooling)?

[Rax]

On further progress report, I've executed both the Digital and the Analog Self-Test Procedures. The unit passed both with no issues.

The manuals are not very clear on what the Analog above contains, but is the Internal Calibration part of it?

[Dr. Frank]

Last time I forgot to do the Int Cal. Difference was about 0.3ppm
The higher ranges may show more deviation w/o Cal.

I'll try to first understand better exactly what the Int Cal is doing (there isn't anything useful in the Operations - unless I missed it - and will dive into the SM next to get a handle on that).

But I imagine it's exactly the first thing to do after closing up the case, to mitigate and adjust for slight differences due to internal air movement, parasitic external air/temp gradients, etc. Should I expect the output to be brought about as close to what my Prema says is 10V as I see it currently (while running it open and with a leaky path for the forced air for cooling)?

The IntCal basically re-measures the resistor ratios of the different ranges, and corrects the gains versus the stored ratios.
 As the reference is very stable, as well -probably-  the DAC , this function corrects for drifts in the gain resistors.
This method is similar to the HP3458A and the Fluke 5720, but it can not fully calibrate its ranges like these, only correct for small differences.

You find a description at the end of the Service Manual, appendix A called: Recent Innovations in Direct Volts Calibrator Design.
Frank

[Rax]

I guess we've also passed the HV self test.

[Rax]

I've done an Int Cal, and I've also re-zeroed the Prema yesterday, and as I feared, I'm no longer seeing the spectacular 10.0000000V measurements. I'm a few ppms off now. What gives?

Were they a fortunate coincidence? Has the Int Cal misfired?

I'm not terribly upset by this, my interpretation is #1 above (coincidence). Though, what are the odds?...

I've launched an inquiry with Fluke for a calibration quote. I think if I'd drive this to their main lab, it'd be a very long, but not unmanageable trip. But this definitely deserves that treatment.

[Dr. Frank]

I've done an Int Cal, and I've also re-zeroed the Prema yesterday, and as I feared, I'm no longer seeing the spectacular 10.0000000V measurements. I'm a few ppms off now. What gives?

Were they a fortunate coincidence? Has the Int Cal misfired?

I'm not terribly upset by this, my interpretation is #1 above (coincidence). Though, what are the odds?...

I've launched an inquiry with Fluke for a calibration quote. I think if I'd drive this to their main lab, it'd be a very long, but not unmanageable trip. But this definitely deserves that treatment.

It is usually necessary only to calibrate the basic 10V range, the other ones are so stable (the range coefficients), that those might not need a special calibration by a 752A. See calibration procedure, in which cases you can abbreviate the external cal.
200mV and 2V ranges need to be calibrated more frequently, anyhow, best with a 3458A.
The 3458A can be used for 10V range calibration of the 5440, anyhow. (Better don't use it for calibration of the higher ranges, esp. 1kV is very bad)

Didn't you have access to a 3458A, or another calibrated precision DMM, or an external 10V reference?

That'll be much better than shipping this beast to a cal lab.

Frank

[Rax]

Didn't you have access to a 3458A, or another calibrated precision DMM, or an external 10V reference?

That'll be much better than shipping this beast to a cal lab.

Frank

I have my own characterized 731B. I could readjust it to match my Prema (once the 5440A is all buttoned up, which is not yet). Then I'd do the 10V cal, like you point out.

For the lower ranges, I could then use my KVD and extract them from the 10V (and still can use the Prema to characterize those).

I have a bunch of other standards (including a null detector), but I think the above is what applies best to this.

[Rax]

In the direction of "buttoning it up," a few possible action items:

• finish the recap (just a few caps left on a board or two)
• EPROMs... Shall I try to replace them all with my NOS ICs after reimaging? I imagine the rest of the EPROM ICs have a likely failure in the short/medium term.
• Also, is it possible to reuse the EPROM that lost its bits? (pun intended). I got some cheap UV erasers, I could use that to blank it and then rewrite.
• MAYBE: perform the output current upgrade mod. How useful is this, really?

[Rax]

Coming back to this topic, as my F5440A is going back to a repair stage - at least I feel I need to assess if that's the case.

This is because it just experienced an apparent jump up of about 1.5ppm at 10V. I probably should check if all ranges have experienced the same, etc. (go in troubleshooting mode), though unfortunately I don't have as much solid data on the other ranges (<2V, including DIV, and 100V, 1000V, etc.). But all my meters this far (though still collecting data) - some of which are calibrated by different labs - seem to indicate the same jump.

The only other thing I can attach to this is that it happened during an unusually warm environment at the bench (over 28C). But it's permanent. Lower current temperatures have not restored the prior output value.

It's completely possible that the internal reference has just jumped by this much. From what I understand, this is rare, but not completely unexpected behavior. Crappy, for sure.

I'd appreciate input on this - what to look for, whether I need to look for anything, or it's all normal behavior, etc. Thank you very much in advance.

[Dr. Frank]

Hello Rax,
to answer your question in the mail: No I have not experienced a jump like that on my 5442A.
I always switch off my 5442A, when not in use, as well my working DMM, the 3458A.
All the references are running continuously, maybe I send one or two cold to another volt-nuts.
In case of low temperatures during transport, i.e. below 15°C, I might have a permanent upward jump of the LTZ1000 based reference on the order of +0.2 .. +1.5ppm, latter for temperatures around 0°C.

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.

I compare all my references once a month. The repeatability of the continuously powered references are around 0.2ppm or better.
The 5442A and the 3458A, after ACAL / INT CAL are on the same order, but tend to show bigger deviations up to 0.5ppm sometimes.
I assume that's due to the ACAL process, which sometimes get a hickup in the external circuitry.
This might be cured by repeating the ACAL process at a later time, but sometimes you have to wait for another day (with power / temperature cycling).

In the annual trend, you can then clearly see this single excursion of the instrument, so that you are able to distinguish between simple hickups and permanent reference shifts.
In your situation with greatly varying room temperature in your garage, it's very difficult to clearly exclude T.C. influences from your measurements.

Your 731B has 1ppm/°C, and very mediocre stability figures on the order of 10ppm/year, 2..5 ppm transfer stability (4h). Therefore, it's no proper voltage reference, but can only be used for transfer measurements when properly characterized for stability.
You definitely need a third stable reference to judge over the other two.

All my references are either specified, or validated to have around 0.02 .. 0.04 ppm/°C.
The 3458A, as already said, has around 0.25ppm/°C for its LTZ1000A reference, and 0.2ppm/°C for the ADC assembly, latter can be ACAL'ed.
 
In summary, your setup / environmental conditions is not good for sub ppm metrology, as I can tell you from experience, when my whole stuff was sitting in my office upstairs, with greatly varying R.T.
Only after I moved everything downstairs to the basement, where R.T. varies no more than +/- 1°C over the whole year, the transfer / comparison measurements were also stable, and such small deviations of 0.1ppm could be identified.

Andreas has a lot of experience with his very hot and unstable lab under the roof .. and he's got a lot of references as well, all have low T.C.
Maybe he can tell, how he deals with this problem. He's as well able to make smooth longterm stability measurements.

Frank

[Rax]

Hello Rax,
to answer your question in the mail: No I have not experienced a jump like that on my 5442A.

I must have misunderstood your recent point by email where you've identified - but not yet determined the cause of, last we talked - a 5.3ppm, then 3ppm, then 2.5ppm discrepancy with one of your other reference environments. Or maybe you've determined there was no jump and the cause was something else but didn't get a chance to share that with me.

Also, I think alm was making a similar point, I thought:

every time you switch a reference off and on there's a small chance it will jump in value.

Though I think the possibility of even apparently spontaneous changes in the reference voltage are not likely, but possible.

But I am pretty sure what I'm seeing is not tempco. It it were, I assume seeing some correlation between the reading and the ambient temperature would be expected. There's no relationship I can discern. It just switched to a higher reading on the Prema, period. The only temperature-related correlation I can think of is the higher than usual temperature at the time of the event, which, because it's such a distinct event and apparently not reversible, I assume could be caused by a part failure of sorts.

I also doubt that you would find a real damage inside your instrument.

If not that, and not tempco, then what is it?... I'm all ears!!

Your 731B has 1ppm/°C, and very mediocre stability figures on the order of 10ppm/year, 2..5 ppm transfer stability (4h).

I have no doubt you didn't mean to literally state that above, as we both know that's not a correct statement. My 731B doesn't have a 1ppm/C tempco. In fact, probably no 731B "has that." That is a guaranteed minimum specification. My 731B may far exceed that - within some reasonable limitations of design, construction, and just... physics - and we actually well know all Fluke instruments tend to far exceed their spec. My sample is an exceptionally well performing one, particularly with regards to tempco, as confirmed by other voltnuts that have examined it and have far more experience than I do. Between mine and other samples seen in this group I'm talking about, there's been a wide variability in the observed performance of some 731B samples, and mine is a standout.

I'm not saying this 731 is a 732 in disguise - not ovenized, right?... - just that the baseline specification shouldn't be looked at as its actual performance, which it is not. For a delta T of just about 3C, the output of an unusually stable 731B may not vary as much as one would imagine just based on specs. This particular 731B was recently adjusted by another voltnut friend by transfer with a Keysight-calibrated meter at 23.3C, so not so far from my conditions, and with a respectable pedigree; I'm considering this datapoint when I'm evaluating some of the things I'm seeing. I do strongly trust it within the limitations I just described.

You definitely need a third stable reference to judge over the other two.

Absolutely I do - though my better half may go through with moving me with all my stuff, permanently, in the garage - and I am picking up a, supposedly working, 332D literally this Sunday. Not a 732, but another opinion of my volt at my bench. As it goes for a lot of us here, this is a hobby, so to just grab a 732C because I want my 5440A or 6048 characterized, is absolutely not a feasible scenario. I do the best I can with what I have at hand in a garage (still, just about +-1.5C!...), and I've also just started on this path, so have that in mind when reading on my work and challenges. I can't change a lot of my determinations.

That said, I do have two calibrated meters at my bench right now (one by Fluke), and will have a calibrated (by Keysight) 3458A/002 on loan soon. I'm presenting all this data I can humbly accrue (=0, apparently) based upon a pretty respectable number of instruments, some of which are "prime house" calibrated! 

Andreas has a lot of experience with his very hot and unstable lab under the roof .. and he's got a lot of references as well, all have low T.C.
Maybe he can tell, how he deals with this problem. He's as well able to make smooth longterm stability measurements.

Frank

Great point, thank you for sharing this. I'll seek to look over his posts, maybe, and the specific challenges he faced and how he sorted them out.

Maybe there's a chance for this aspiring metrologist!

[Dr. Frank]

Hello Rax,
if you just THINK, that your 731B is much more stable than specified, you can for sure simply present your T.C. and stability measurements on it, like most of the volt-nuts did on their "Super LTZ1000 references" in this said thread.
Ah, I forgot that you don't have GPIB and data acquisition yet .. that's the most urgent topic for you to solve.

The deviation problem I described to you was a completely different case.. I had sent two of my working references to another volt-nut.
He observed deviations with greatly varying results, also relative to recent comparisons he made before, and we both could not explain that effect. Other recent  ring transfers were successful to < 0.5ppm, instead.

This case is completely unrelated to comparisons of my 5442A, 3458A, or all my references, which are all still stable and consistent within 0.2ppm when compared in my lab.

Frank   

[Andreas]

Great point, thank you for sharing this. I'll seek to look over his posts, maybe, and the specific challenges he faced and how he sorted them out.

Hello,

I simply try to characterize and improve my measurement devices (e.g. by evaluation and compensation of T.C. and other effects).

https://www.eevblog.com/forum/metrology/project-pimp-a-keithley-2000/msg1106829/#msg1106829

Most of my measurements are only relative (not absolute) so they need only a (characterized) linearity.

For critical absolute measurements I make the measurements with more than one measurement device.
E.g. the K2000 the HP34401A + ADC13, ADC15, ADC16, ADC17 all in parallel and additional my most stable LTZ1000 references as comparison/adjustment.
Against noise I usually average the measurements over 1-5 minutes.

And of course all EMI related stuff like LED lamps, mobiles etc. are banned from my lab.

Most critical for me is a large temperature gradient. So I try to do critical measurements in summer in the morning when the temperature is still stable.

with best regards

Andreas

[branadic]

(e.g. by evaluation and compensation of T.C. and other effects)

Just to be crystal clear on that point, that is software compensation of measured data or hardware compensation, so that the reference exhibits almost no t.c.?

-branadic-

[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."

[Rax]

Here it is, to the best of my capacity to depict it. The only action I executed myself that could explain this is a nulling of the Prema, but that's not explaining anything, as it's not reflected in any 731B relative jumps (which stayed solid as a rock going by the Prema reported readings).

This is over about 10hrs readings through today.

[dietert1]

If your P6048 doesn't have the low input voltage nonlinearity fix this will result in a minor ambiguity when nulling the instrument. The details are in the P6048 thread.
For the time being you could perform nulling when the instrument is warm using the calibration switch to store it as power-on default - and then rely on that instead of nulling the instrument during a log.
I remember a similar comment of TIN concerning random HP 3458A ACAL operations during sub-ppm logs. It can cause small steps.

Regards, Dieter

[Rax]

If your P6048 doesn't have the low input voltage nonlinearity fix this will result in a minor ambiguity when nulling the instrument. The details are in the P6048 thread.
Regards, Dieter

Thank you for this Dieter - definitely a good path to take and seek to further assess and/or cure the issue. I am aware of the conversations over the P6048 INL issues.

I think I could try replacing U9 (I think that's the major linearity fix) and see if this continues occurring. By itself, I think that should be a reversible modification - if no cure, I would insert the old U9 back (OP77) and I think the instrument should then go right back on cal and all prior constants and adjustments restored.

Point being, if I permanently change U9 for an OPA140, I think that's going to waste the accuracy of the instrument. But if I just try the more adequate op amp in that position, this would at least tell me more, as a troubleshooting step.

What have others that performed the P6048 mods did in terms of the instrument's calibration? Use it as relative reference from this point on? Simply recalibrated it with fitting standards at hand?

[Kosmic]

If your P6048 doesn't have the low input voltage nonlinearity fix this will result in a minor ambiguity when nulling the instrument. The details are in the P6048 thread.
For the time being you could perform nulling when the instrument is warm using the calibration switch to store it as power-on default - and then rely on that instead of nulling the instrument during a log.
I remember a similar comment of TIN concerning random HP 3458A ACAL operations during sub-ppm logs. It can cause small steps.

Regards, Dieter

The Solartron 7081 has a similar problem (offset after nulling). Was eventually diagnose and fixed in the firmware by Mickle.

[Kosmic]

If your P6048 doesn't have the low input voltage nonlinearity fix this will result in a minor ambiguity when nulling the instrument. The details are in the P6048 thread.
Regards, Dieter

Thank you for this Dieter - definitely a good path to take and seek to further assess and/or cure the issue. I am aware of the conversations over the P6048 INL issues.

I think I could try replacing U9 (I think that's the major linearity fix) and see if this continues occurring. By itself, I think that should be a reversible modification - if no cure, I would insert the old U9 back (OP77) and I think the instrument should then go right back on cal and all prior constants and adjustments restored.

Point being, if I permanently change U9 for an OPA140, I think that's going to waste the accuracy of the instrument. But if I just try the more adequate op amp in that position, this would at least tell me more, as a troubleshooting step.

What have others that performed the P6048 mods did in terms of the instrument's calibration? Use it as relative reference from this point on? Simply recalibrated it with fitting standards at hand?

You should try to validate this theory (offset due to nulling). Disable auto zero and start logging. If the big offset disappear then you know where it's coming from and it's not much of a problem.

[dietert1]

The Prema 6048 doesn't have autozero mode. Instead it uses a 0 V to 20 V ADC together with an automatic input polarity switch. Unless the built-in scanner is present, for nulling one needs to detach the input cables and insert a short instead.
The method works well except it can introduce a slight inaccuracy while nulling the instrument. The problem was discovered years ago and meanwhile a fix was proposed, please see Prema 6048 thread.
Since the Prema has IC sockets, the measure can be reversible.
If two old, out of calibration instruments agree to 1 ppm, it's nice but not significant. With three of them (P6048, F5440 and F732) in good agreement, there may be a little more truth in it. I can understand the idea of buying a calibration at ebay incorporated in old high end instruments but it's not completely valid as some of those boat-anchors have been without calibration already for 15 or 20 years. The method may serve for checking more simple instruments, but not for sub-ppm. +/- 10 ppm should be possible.

Regards, Dieter

[Kosmic]

The Prema 6048 doesn't have autozero mode. Instead it uses a 0 V to 20 V ADC together with an automatic input polarity switch. Unless the built-in scanner is present, for nulling one needs to detach the input cables and insert a short instead.
The method works well except it can introduce a slight inaccuracy while nulling the instrument. The problem was discovered years ago and meanwhile a fix was proposed, please see Prema 6048 thread.
Since the Prema has IC sockets, the measure can be reversible.

Ho ok can't be easily disabled. Thats too bad 

[Rax]

I can understand the idea of buying a calibration at ebay incorporated in old high end instruments but it's not completely valid as some of those boat-anchors have been without calibration already for 15 or 20 years. The method may serve for checking more simple instruments, but not for sub-ppm. +/- 10 ppm should be possible.

Regards, Dieter

Most of my instruments - except, notably, the Prema - are not sourced off of eBay. Rather, local "mini dealers" that are direct intermediaries (one hand) to major local California labs. Keep in mind that Keysight's primary lab is in my state, and Fluke's own is on the same coast, just at the other end of it (WA). Essentially, all local to me by global, or even US standards. Other instruments I have here are either adjusted by other voltnut friends  traceable to either Keysight or Fluke, or just directly traceable to either.

But I do get your point, which I think is meant to be hopeful - don't obsess over your last ppm with what you have at your bench. I'm doing my best, not very successfully.

That said, although I can't square why the F731B is rock-solid on value on the P6048 (no hiccup I can recall, ever), the INL issue is the best explanation I have for this 1.5ppm "walk." This and the occasional and temporary F5440/5442 ~1ppm shifts per Dr Frank.

A lesser standard such as the 731B agreeing so closely to an 8 1/2 meter (never, ever, even one disagreement event, meaning >1ppm - and I hope my automated data logs agreeing with my statements give me some cred here) against a high end standard such as the 5440A is... inexplicable to me. Particularly as the 5440A has been in agreement for weeks of observations on end. Something must have happened and I can't figure out what it is.

This responds to the laws of physics and electronics, so a repeatable and consistent change in data output as we are seeing must have an explanation. What could it be? As much as I'd love that to be an INL linearity (or lack thereof), I can't buy that, due to the agreement with the 731B.

It may be useful to subtract any claims of traceability from this troubleshooting pursuit. If all we're looking for is agreement with a JJ array - everything else being irrelevant - we'll not perform any diligent analysis on why this 1.5ppm has consistently added itself to the readings. I still look at this as a repair pursuit.

[dietert1]

If you have access to the previous owners of the equipment and to its history, you may be better off than with ebay.
Disagreements in metrology happen always and you learn at which level you are operating. As long as you don't know the physical origin, an observed disagreement is noise and subject to statistical procedures.

Regards, Dieter

[Rax]

Disagreements in metrology happen always and you learn at which level you are operating.

True, and I guess the fact that I have a clear window to observe a 1.5ppm shift is a statement of that level. I see it as a positive thing (I think you meant is as a negative, though not in any ill manner), as much as it's frustrating and puzzling. Both a statement of how far down near the level of noise I can see, and also that I am honest with my data and observations.

As long as you don't know the physical origin, an observed disagreement is noise and subject to statistical procedures.

That's what I mean about my "repair" attitude with this - I am hopeful I'll determine a physical origin for it. I should get some OPA140s and some DIP adapters by the weekend. I think that will help eliminate (or indicate) a possible cause, and a big thanks again for pointing that out. I am aware of the P6048 conversations, but I haven't quite seen it pertinent to this context.

[Rax]

The method may serve for checking more simple instruments, but not for sub-ppm. +/- 10 ppm should be possible.
Regards, Dieter

OK, so let's step back a bit here. Maybe I misunderstand your point, but I didn't think my expectations were unreasonable. Such a loose F5440A doesn't seem at all to be Frank's experience (and others here) - anyone, please feel free to correct me if that's not correct. I'm absolutely willing to accept the 5440A is a crap instrument good for 4.5 digit meters that jumps a few ppms every now and then, but that just doesn't seem at all like a popular opinion. Frank's observations are with a lesser instrument (F5442A), which I also assume he didn't buy new. I didn't find mine in a back alley, or even eBay, and I'm not sure where that assumption came from.

So shall I just cool my horses and accept that all a fully serviced, fully working F5440A can do is +-10ppm? If we're instead talking about some cumulative effect of the P6048's INL non-linearity and a couple of involved instruments' tempcos under wild temperature variations, that seems more feasible to me.

But a +-10ppm F5440A would not even meet spec, and my understanding was this is an exceptional unit that should well exceeds it.

[dietert1]

I think 10 ppm was a reasonable guess for accuracy when using instruments out of calibration (last calibration older than 1 or 2 years, if known at all). A repair often means a new calibration is required. Certainly your calibrator will meet specs after calibration.
Stability may be easier. But really 1 ppm is so little. Imagine two 300 m vessels coming close to 1 cm. That's 30 ppm.

Regards, Dieter

[iMo]

..
..So shall I just cool my horses and accept that all a fully serviced, fully working F5440A can do is +-10ppm?

You have to create a method to double check your instrument is still +- something. Nobody can tell whether your 5440A is working properly within a +- X ppm based on yesterday's data. There is only a certain probability that your fully serviced rig still works within some spec. Only a continuous never ending measurements based on many devices and comparisons can somehow "increase the probability" the stuff is within a +- X ppm.

[dietert1]

An example: Imagine you have two 10 V voltage references with built-in overcurrent protection, let's say 20 mA. You wire them to measure the difference with a nanovoltmeter. Lets say it indicates 1 mV = 100 ppm difference. Now in order to check your setup you add a short over the nanovoltmeter inputs with a 0.1 Ohm lab cable. Will you see 0 V?
Another example with one voltage reference: Wire the plus to the two nanovoltmeter inputs with two cables pretending you had two voltage references of exactly the same output voltage. Will you see 0 V?

Regards, Dieter

[Rax]

I think 10 ppm was a reasonable guess for accuracy when using instruments out of calibration (last calibration older than 1 or 2 years, if known at all).
Regards, Dieter

I recommended we stop considering accuracy while this is under repair a few posts back:

It may be useful to subtract any claims of traceability from this troubleshooting pursuit. If all we're looking for is agreement with a JJ array - everything else being irrelevant - we'll not perform any diligent analysis on why this 1.5ppm has consistently added itself to the readings. I still look at this as a repair pursuit.

The reason I think it's still under repair is the fluctuations (= stability) of well over 1ppm (which I've seen nothing anywhere close to during 8 weeks of literal continuous running and observations, with units moved around a few times over, wiring connected and disconnected dozens of times, so from my direct experience with the unit, I think it's reasonable to provisionally conclude the unit is experiencing some sort of undue episode due to the sudden and radical change).

But if the experienced here tell me that's completely normal behavior, I'll duly take that to the bank. I absolutely understand 1ppm is for all intents and purposes infinitesimally small, and therefore excruciatingly difficult to reliably, and repeatedly, observe (though I didn't have that sense for 8 continuous weeks...  ...), but in terms of what to expect, I rely on you all here to advise on what's reasonable.

[Rax]

You have to create a method to double check your instrument is still +- something. Nobody can tell whether your 5440A is working properly within a +- X ppm based on yesterday's data. There is only a certain probability that your fully serviced rig still works within some spec. Only a continuous never ending measurements based on many devices and comparisons can somehow "increase the probability" the stuff is within a +- X ppm.

After I conclude this is still in serviceable state, I will have access to a calibrated 3458A/002 on loan for a few days to add some objective data to this. I've also been looking for other voltnuts in my proximity, and though I found some (heyyah!), they don't have the kind of standards this requires for a proper assessment. But I'm still working on that.

[Rax]

Should connecting GPIB on the P6048 scramble its brains in any way, due to whatever messy ground that may carry, or ground loops, or garbage from the computer, etc? Is GPIB perfectly inoculated against disturbing the instrument at that "ppm level?"

The other thing that happened at the time of this episode is connecting the P6048 to my bench computer.

[Rax]

It's also completely possible the onset of fall here triggers different, maybe more radical gradients on air temperatures, and air movements and drafts and whatnot at bench (though I'm not at all seeing that in the bench thermometer). The F5440A is an ovenized instrument, obviously, so there's that going against this consideration.

[alm]

Should connecting GPIB on the P6048 scramble its brains in any way, due to whatever messy ground that may carry, or ground loops, or garbage from the computer, etc? Is GPIB perfectly inoculated against disturbing the instrument at that "ppm level?"

Not in any permanent way. Ground loops are possible if the computer is on a different circuit, but that should be easy to check by disconnecting the GPIB cable and seeing if this reverts the jump you observed.

[Dr. Frank]

Should connecting GPIB on the P6048 scramble its brains in any way, due to whatever messy ground that may carry, or ground loops, or garbage from the computer, etc? Is GPIB perfectly inoculated against disturbing the instrument at that "ppm level?"

The other thing that happened at the time of this episode is connecting the P6048 to my bench computer.

I'm not experienced on the 6048, but generally, there must be a galvanic separation between Analog and Digital / GPIB.
Om some instruments you can connect both grounds by a switch.

The 3458A, 5440 and other "ppm-capable" instruments are isolated, and you can of course do sub-ppm metrology w/o disturbances by GPIB.

At one time, I had an interference  problem (shift or instability of several ppm) with my GPIB PC.. and I first thought it would intrigue my high precision instruments via the GPIB interface.. Instead the snubber capacitors inside the ATX-SMPSU of the PC were defect, so that it created a massive EMC disturbance, which in the end influenced my sources, as well the input circuit of my 3458A.

Frank

[alm]

At one time, I had an interference  problem (shift or instability of several ppm) with my GPIB PC.. and I first thought it would intrigue my high precision instruments via the GPIB interface.. Instead the snubber capacitors inside the ATX-SMPSU of the PC were defect, so that it created a massive EMC disturbance, which in the end influenced my sources, as well the input circuit of my 3458A.

I vaguely remember that at the Metrology Meet 2021 in Stuttgart, there was a problem with an USB-GPIB interface connected to a Raspberry Pi (I don't know how the Pi was powered) causing a small offset on a 3458A when measuring DCV. This was worked around it by unplugging the GPIB interface. Note that this was a very temporary setup built up for just one day.

But pretty much anyone serious about metrology will have equipment connected to GPIB (unless they are so rich that they own the very newest equipment with LXI). So these problems are the exception, rather than the rule, and as I wrote trivial to check for.

[Rax]

trivial to check for.

Thank you for the example of it occurring that one time.

I did a quick check yesterday for this as I was trying to determine possible causes, not positively conclusive. I'd just need a bit more time to determine if a/the cause, but I wanted to collect more thoughts on this before I focus too much on it.

[Rax]

At one time, I had an interference  problem (shift or instability of several ppm) with my GPIB PC.. and I first thought it would intrigue my high precision instruments via the GPIB interface.. Instead the snubber capacitors inside the ATX-SMPSU of the PC were defect, so that it created a massive EMC disturbance, which in the end influenced my sources, as well the input circuit of my 3458A.

Frank

Very interesting... If this persists, I may want to open the computer and see if all checks out. It's a pretty old computer at this point, though very well performing and a powerhouse at its time.

Thanks for the pointer, Frank!

[dietert1]

The Prema 6048 is isolated, but not to the same degree as HP meters. It does not use optical fibers but integrated optocouplers and as it does not have a MCU in its isolated front-end there are nine of them to control ADC and relays.
Some people run their GPIB resp. USB cables through toroid cores to improve EMI suppression (common mode choke). One can do the same at the meter input.

Regards, Dieter

[Rax]

Some people run their GPIB resp. USB cables through toroid cores to improve EMI suppression (common mode choke). One can do the same at the meter input.

Regards, Dieter

Great idea! I have a whole set of different sizes for needs such as this.

[Rax]

Here's a 12hrs log (overnight) of the F5440A as read by the P6048. There's a garage door open in there somewhere (possibly where readings climb) - but very mild weather here, so I don't think that created wild temp differentials (also, electric car, so none of the heat a gas car would bring into a garage) - and a ferrite core clip-on the USB cable (possibly where the readings go down). I saw an effect of about .1-.15ppm descent as soon as I connected it, so there may be some truth to contamination over GPIB, but not positively conclusive (in no small part because I didn't really run that as a disciplined experiment, so that's on me).

Now, all that said, the stability doesn't look all that impressive to me. There's a differential of over half a ppm over half a day - is that reasonable/expected? I'm used to seeing about half that from this unit, though via "analog" observations, so obviously less reliable than this. I have not logged temperatures during the below readings, but again, I don't think they could have exceeded 1.5C, maybe 2C in the worst imaginable scenario.

[Rax]

Here's a roughly 36hrs log. A few notes:

• As I said before, the instrument hovers above 10.0000000V most of the time. It doesn't seem to be confused at all about where 10V is (Prema's, of course!... wink to the hardcore). It'd hover over that exact value for hours at a time - and by that I mean less than .1ppm off it (with occasional and typically brief excursions of about .15-.2ppm).
• There are a few hiccups. The first "peak" is .75ppm high... what could trigger such a jump? Anyone's guess, though certainly experience wins the big prize here. I have not seen these so distinctly before setting up automation... this was rather unexpected. The magic of 20/20 hindsight due to automation and logging.
• A couple other hiccups are at +.50ppm (just about the middle of it) and another one at about -.25ppm (at the very end). None of which I think are outrageous - my lab conditions are not "metrology grade..." And yet, the F5440A soldiers through those hostile conditions quite successfully, I'd say.

There's about 2.4C delta over these two days.

[alm]

Nice, so now you're getting actual data. It would be interesting how this looks over the longer term. It looks like there might be a slight negative trend in this data, but the period is too short to tell. This might be a temperature effect, which we'll know once you start logging temperature.

[Rax]

Here's continued readings - about 7k data points on this particular one, a little less than 72hrs 40hrs.

Keep in mind I haven't done an INT CAL (or a nulling for that matter) in a long time. Technically, the F5440A should undergo an INT CAL daily, though in case it's continuously powered, I think the advice of people having used this in cal labs was at least every two weeks I seem to remember.

[Rax]

Though most of the readings are below 10V, there's a constantly recurring crossing into the >10V side. The last 24 hrs are almost "dead on" (by which I mean eyeballing an averaging point hits 10.0000000V as precisely as one can tell). I'll try to average these to see what I get.

[Rax]

Averaging the ppm values, I get an overall .0135ppm, which include the peaks mentioned earlier (which I don't think are guaranteed to occur). In fact, the actual average without those is probably slightly negative, but smaller in absolute value.

[alm]

It would make the graph a lot easier to interpret if you include time on the X axis. It can be relaltive time, which could just be somehting like sample number * 20 seconds / (3600 seconds / hour) to have a scale in hours from t=0. Though tracking calendar time is useful if you want to relate it to other events like temperature measurements or daylight / night.

I don't think averaging over such a long time scale is useful. My reasoning is that on such a long time scale, the result will be a combination of tempco, time drift, etc. So either you calculate the average over a period of let's say a couple of hours max to estimate the value at a single point in time (though likely averaging a couple of dozen samples will give you pretty much the same information), or you do some sort of regression analysis to measure the influences of external factors like time and temperature. This will be difficult on such a short time scale since time and temperature differences will be very small, but the longer you track the easier it will be to see particularly drift over time. What could help spot trends is applying a rolling average filter to filter out some of the noise.

If you report averages, then I think it's also useful to report standard deviation and number of samples in addition to the average.

[Rax]

Nice, so now you're getting actual data.

Thank you, alm! It's been a steep couple of weeks-ish, but with the help of good, knowledgeable, and generous people here I got that running. I still can't really believe it (that's how much I enjoy it).

[Rax]

For shits and giggles, here's the flattest (and closest to Prema's 10V) ~22hrs (about 4k data points) stretch from those 72hrs. Yes, it absolutely is cherry picked data, but I think it's both satisfying and still useful information to ponder over.

Not sure if temperature, noise/EMI/other environmental garbage, or other conditions determine the peaks and valleys on the overall run, but I see this clean stretch as a statement of the fine quality of the F5440A.

_______________________________________________________________
Added time in hours on X axis for clarity and legibility.

[Rax]

If you report averages, then I think it's also useful to report standard deviation and number of samples in addition to the average.

I calculated the basic average using excel tools (AVERAGE, outputting .0135ppm), then standard deviation based upon the same (STDEV.P) comes up with .135ppm (assuming I used correctly the excel calculator, which I merely dabble in). The number of samples is in the original post (about 7000).

If I calculate the same on the 22hrs sample included above (about 4000 entries), I come up with -.0694ppm vs. .0719ppm, respectively.

I just kept on logging, currently. I'm interested in seeing how often these jolts tend to happen, and if there's any pattern or rule to it.

[Rax]

Continued monitoring this past the 60hrs milestone. I suspect there's some "real time" gaps on this, possibly related to saving into the txt file over the network (?). So even if we're at  72hrs into this, there's 11,040 entries into the enclosed graph, which amounts to a bit over 60hrs. I don't think that truncates the data very much (though it may account for some of the "jolts").

For this:

• The number of samples = 11,040
• Averaging = -.0038ppm
• Standard Deviation = .1239ppm

I'll stop posting here at some point, but I thought a bit longer term data would be interesting to present.

[Rax]

What could help spot trends is applying a rolling average filter to filter out some of the noise.

I don't know what you mean with this. Is this a data handling tool, something I can possibly do with my spreadsheet program?

[Rax]

Continued monitoring this past the 60hrs milestone.

BTW, goes without saying, some of those jolts could as well me "thermic shocks" by opening the garage door, etc. This should be at least twice a day, so it looks like most of the time it had virtually no impact on the measurements whatsoever (I regard anything under, say, a .2ppm fluctuation as essentially noise).

[alm]

I don't know what you mean with this. Is this a data handling tool, something I can possibly do with my spreadsheet program?

Yes, a rolling average or moving average is effectively a low-pass filter for data. It averages the last N points (where N determines the degree of filtering) with the goal of uncovering patterns that were previously obscured due to not so relevant high frequency. It should be trivial to find a tutorial how to do that in a spreadsheet, MATLAB/Octave, Python or whatever data analysis tool you use. I would use it as a plot in addition to the raw data plot.

[Rax]

Still learning my instruments. And probably fundamentals on all of this.

After the perfect agreement (which didn't seem to go away for about six days now of continuous running, while leaving the instruments alone, and I kept tracking logs to document it past what I already posted here), I decided to experiment some more, and leaving the P6048 on (and not touching it), run a fresh INT CAL on the F5440A. The result is essentially the same 1.5ppm lift-up of the reading on the P6048. The symmetry of this is, probably, relevant - for reference, I refer here to the identical event where a nulling of the P6048, while leaving the F5440A alone, had apparently the exact same effect - and, surely, has a certain beauty in the spirit of ancient Greek esthetics. Which, for the record, I'm not a big fan of (symmetry as beauty).

I am reviewing several prior pages to this thread to see if anything in the feedback gives me a basis to work with to explain this (other than that anything around 1ppm and lower is subject to fairly random laws, which I regard as legitimate). Being symmetrical, I'm thinking:

• EMF potential over my cables (low-emf AB sourced). Though I think dietert1's input was emf shouldn't account for this much.
  
• Some sort of consistent tempco (can't imagine how).

From the possible hypotheses presented this far, nothing stands out to me as a compelling explanation. I know we've circled this issue quite a few times already, but after performing the parts asked to perform I think these jumps still remain unsolved. Or at least to me, but if I am missing it I'll appreciate a pointer. Possibly missing the forest because of the trees.

It looks like any of the long term logs I am recommended to do rely on explaining this persistent realignment (or else I risk random, but persistent 1.5ppm offsets). I am trying to recall how this went away the last time, but I think it may just be nothing other than time passing. By which I mean given enough time the two instruments seem to fall back into agreement regardless what operations (nulling, INT CAL, etc.) have been  performed in the meantime.

[Rax]

I should also add that my prior observations of INT CAL (F5440A) + nulling (P6048) would have typically generated convergence, not divergence. Hence, as I'm observing this new (?) consistency of the divergence (and of course, these few observations don't amount to a statistically relevant body of work), I am trying to decrypt the patterns.

If I'm overthinking this, please call me on it.

[Rax]

(after doing some homework, I edited my prior two posts - hopefully that doesn't make this confusing)

[Rax]

As I'm currently having that 3458A/002 I mentioned here and elsewhere before, here are the SM performance tests done with it. This is a unit calibrated about two years ago at KS' Rosemont facility.

I include a snip of the allowed ranges for compliance.

• 1.10uV
• 99.99616mV
• .99999535V
• -2.70uV
• 1.00000220V
• 5.0000036V
• 20.000001V
• -19.999998
• 99.999184V

I didn't do the 1000V, as I'm a little antsy with that with with SELV cables and wnatnot.

This looks good to me.

[RandallMcRee]

As I'm currently having that 3458A/002 I mentioned here and elsewhere before, here are the SM performance tests done with it. This is a unit calibrated about two years ago at KS' Rosemont facility.

I include a snip of the allowed ranges for compliance.

• 1.10uV
• 99.99616mV
• .99999535V
• -2.70uV
• 1.00000220V
• 5.0000036V
• 20.000001V
• -19.999998
• 99.999184V

I didn't do the 1000V, as I'm a little antsy with that with with SELV cables and wnatnot.

This looks good to me.

What I expected: comparison of 3458A with cardinal points of 5440. E.g. for 5.0V entered on 5440 3458A reads 5.xxxx volts....for 10-20 such points.
What I see: a table from somewhere or other having nothing to do with this?!

Am I being dense? Sorry if so!

[dietert1]

I 'd guess the first table are the test measurements and the second table are the specs. It's not so obvious whether the 20 V and -20 V results are for polarity reversal of the calibrator setting or for the meter input cables. At least i understand that the measured deviations at 20 V are below 1 % of specs and much below 1 ppm, a very satisfactory agreement. A christmas present if you want so.

Regards,

[Rax]

I 'd guess the first table are the test measurements and the second table are the specs.

That's right. I was closely following the performance verification procedure from the SM.

It's not so obvious whether the 20 V and -20 V results are for polarity reversal of the calibrator setting or for the meter input cables.

The procedure doesn't clarify that, but I used the polarity reversal control on the 5440A.

[bdunham7]

What I expected: comparison of 3458A with cardinal points of 5440. E.g. for 5.0V entered on 5440 3458A reads 5.xxxx volts....for 10-20 such points.
What I see: a table from somewhere or other having nothing to do with this?!

Am I being dense? Sorry if so!

Back when these were new it was not easy to read those voltages to that precision, so they set up the performance test and calibration procedures to use the least number of tests that could verify proper operation provided the instrument didn't have some large or weird malfunction.  Given that there is a 3458A present, I think doing a many-point linearity check would be the way to go.

Also, I think the apparent 40ppm tolerance for the 1V setting is a typo.

[Rax]

The procedure was performed at 24.9C, in case anyone was wondering. The 5440A got a fresh INT CAL and the 3458A had an ACAL the same day.

[Rax]

Also, I think the apparent 40ppm tolerance for the 1V setting is a typo.

In the manual, you mean? That doesn't make a whole lot of sense to me either.

[Kleinstein]

I 'd guess the first table are the test measurements and the second table are the specs.

That's right. I was closely following the performance verification procedure from the SM.

It's not so obvious whether the 20 V and -20 V results are for polarity reversal of the calibrator setting or for the meter input cables.

The procedure doesn't clarify that, but I used the polarity reversal control on the 5440A.

As the specs / test is for the calibrator, it should be the polarity reversal in the meter. For better accuray of the measurement one could consider also swapping the meter leads, so that the meter reads the same sign in both cases.  20 V is not so much a sweet spot for the 3458 and the meters turn over error (e.g. offset in the 100 V range) may be about that large.
With the 3458 I would add a +-10 V test to see if the turn over works Ok. I would not expect much difference as this is only a polarity relay - so mainly a little offset from thermal EMF.

[MadTux]

Better approach would be to compare like 3x 5440B with 3x good DVM as null meter in 1-2, 2-3, 3-1 configuration.
Or replace 2x 5440B with good stable 10V reference, like Fluke 732.

Fluke reference inside 5440B should be at least equal or most likely better than the reference inside most good DVMs.
So you basically compare accuracy of DVM and 5440B and 5440B is most likely the winner, here.

[Rax]

Better approach would be to compare like 3x 5440B with 3x good DVM as null meter in 1-2, 2-3, 3-1 configuration.
Or replace 2x 5440B with good stable 10V reference, like Fluke 732.

Fluke reference inside 5440B should be at least equal or most likely better than the reference inside most good DVMs.
So you basically compare accuracy of DVM and 5440B and 5440B is most likely the winner, here.

I think the reference in both the "A" and the "B" 5440 is two stacked SZA263s. The 3458A I'm using is a well aged, but completely rehauled unit (some modules were replaced, but not the critical boards), and then calibrated by Keysight. So there's a well aged LTZ1000A in there.

I find it very challenging to accurately determine where is the tempco I may be observing at a given time (and particularly tricky, why there's "no tempco" for a certain stretch of temperature gradient...  ), but I have a sense my 5440A is not terribly stable across delta T. I'd like to think my sample can reliably calibrate 8.5 digit DMVs, but I'm not quite convinced. This may sound sacrilegious, but I'd trust my 731B (with a deliberate temperature observation) than my 5440A at 10V. This working hypothesis is currently being confirmed by the 3458A.

[Rax]

BTW, as much as those points recommended by the SM look great, at 10V out my 5440A isn't all that great. I am seeing it consistently over 1ppm high. INT CAL doesn't change that much. All this is at 24-25C, which is where my bench is sitting around right now.

[Kleinstein]

It is normal that the internal calibration should not change much with the 10 V. The 11 V range is kind of the base range, where the other ranges are based on with the INT CAL. For the 11 V range the INT cal should only corect the offset, but not change the scale factor - as there is nothing else internal to compare too.
So if the 10 V are consistantly off by 1 ppm, that this a calibration thing of either the DMM or 5440A. The 22 V range should be a little less stable, as it includes a gain stage and an exra scale factor from INT CAL. So if the 10 V values is different and the 20 V not this would be some error of either the meter of calibrator, e.g. ACAL at the 3458, the ADC or INT cal at the calibrator (e.g. DAC linearity).

[Rax]

So if the 10 V are consistently off by 1 ppm, that this a calibration thing of either the DMM or 5440A. [...] ACAL at the 3458, the ADC or INT cal at the calibrator (e.g. DAC linearity).

I think it's probably a combination of ACAL (fresh or due?), INT CAL (fresh or due?) and environmental temperature.

For instance, here's the result of a linearity read of outputs from 1V to 10V after a fresh ACAL on the 3458A. This was collected at conditions encroaching on the high end of the reasonable bench temps (26.9C).

• 1V: .99999954V
• 2V: 2.0000004V
• 3V: 3.0000006V
• 4V: 4.0000014V
• 5V: 5.0000012V
• 6V: 6.0000014V
• 7V: 7.0000014V
• 8V: 8.0000014V
• 9V: 9.0000012V
• 10V: 10.0000008V

I think this would be fine for both linearity (wrong on this?) and accuracy at specifically 10V.

[Kleinstein]

The linearity looks OK (though not perfect) for the combination of the DAC and ADC.

It looks like there is a bit offset on the order of -1 µV or a little less,  likely at the calibrator.


INT CAL should not make much difference for the 10 V range, mainly for the offset.

[Rax]

Further linearity measurements. I'm learning that ACAL on the 3458A is essential. I don't think anyone should do any measurements they want to consider reliable without an ACAL prior to it within less than an hour. I've seen the 3458A stray by over 2ppm within a few hours of bench time (from the last ACAL ALL, or just an ACAL DCV - say these were performed in the morning, and the 2ppm was observed in the mid afternoon).

• 1V: 1.0000010V
• 2V: 2.0000017V
• 3V: 3.0000023V
• 4V: 4.0000028V
• 5V: 5.0000027V
• 6V: 6.0000028V
• 7V: 7.0000028V
• 8V: 8.0000023V
• 9V: 9.0000028V
• 10V: 10.0000021V
• 11V: 11.0000016V

Over 11V, the 3458A switches to the 100V range and I don't think the readings are still useful.

[Kleinstein]

Noamally the 3458 should not be that bad with need for ACAL. There is however a failure mode of the ADC developing a tendency to drift. So maybe the unit start to devolopement that fault (faulty U180 and thus an expensive repair). For testing the drift of the constant CAL72 should be observed over some time (see HP Servis note 18).   Another possibility may be the drift of units that where not used for an extendet time - that can cause additional drift for the first few weeks.

[Rax]

Another possibility may be the drift of units that where not used for an extended time - that can cause additional drift for the first few weeks.

This is probably it - I don't think the lab owning this is giving it much use at all. I expect it's been sitting pretty much since it came back from Keysight.

That said, I'm not sure if this expected drift after storage effects the reference, the additional precision parts (resistors, etc.), or both? I'm thinking in terms of INT CAL on the 5440A, which I think doesn't have much to do with the reference, but associated parts and compensates for their drift.

The reason I'm thinking that it's possible ACAL similarly involves other parts than the internal reference is that the 3458A is in perfect agreement with the US Cal Club traveling FX reference, also a freshly Fluke-calibrated 8846A and other lesser instruments.

[bdunham7]

Noamally the 3458 should not be that bad with need for ACAL. There is however a failure mode of the ADC developing a tendency to drift. So maybe the unit start to devolopement that fault (faulty U180 and thus an expensive repair). For testing the drift of the constant CAL72 should be observed over some time (see HP Servis note 18).   Another possibility may be the drift of units that where not used for an extendet time - that can cause additional drift for the first few weeks.

The reason I'm thinking that it's possible ACAL similarly involves other parts than the internal reference is that the 3458A is in perfect agreement with the US Cal Club traveling FX reference, also a freshly Fluke-calibrated 8846A and other lesser instruments.

I'm not sure how long the 3458A had been running continuously in Rax's garage lab prior to the previous ACAL, but I saw it change ~2ppm over a 4 hour period at a reasonably constant temperature.  But after each ACAL it seems to agree with the FX, the 5440A and other stuff within the limits of reasonability.  That amount of drift seemed a bit surprising.

Just for a frame of reference on the aforementioned 8846A, here's the last overnight log I did with it and the FX reference.  Temperature was 22+/-1C, I went off to bed about at about 1 hour in, got up at about 9 hours and then bumped the HVAC a few degrees, opened some doors, etc.

[Dr. Frank]

Concerning the T. C. of the 3458A, w/ and w/o ACAL, I wrote a comprehensive article here: https://www.eevblog.com/forum/metrology/ultra-precision-reference-ltz1000/msg5230803/#msg5230803

The 3458A will practically not drift, if not powered, therefore, it might still read very accurate.

The 10V cardinal point checks the 11V range of the 5440A most accurately, as this value is used for its basic calibration as well.

As said, the other ranges, 22V, 250V and 1000V, are calibrated once in the factory, and practically never need a new external calibration any more. The internal calibration will always reproduce the original gain factors.
Therefore, to check these 3 ranges of the 5440A, you need to measure 13 and 20V in the 100V range of the 3458A, 100 and 250V in its 1kV range, and about 276V and maybe 1kV for the highest range.
I wrote a longer article about the Fluke 752A precision divider where I also analyzed the different pitfalls of the 3458A, in conjunction with the 5442A:
https://www.eevblog.com/forum/metrology/influence-of-switch-resistance-in-hamon-dividers/msg4221751/#msg4221751

E.g. those 13, 20 and 100V measurements are quite delicate, as ANY DMM has problems with E. M. F. voltages in this 100V range, due to the usual 100:1 divider. You need to make one careful null reading of the 3458A, 100V range, and subtract that value afterwards. Always use appropriate statistics on the 3458A, as described elsewhere.
Similarily, you need this procedure for precise calibration of 200mV and 2V range.
These about 276V will set 5440A to its 1kV range, but can be measured by the 3458A w/o it's mediocre heating /power effect at 1kV, which might be up to 12ppm additional shift.

I recommend again, to not do any external calibration on the 5440A, as it seems to be spot on within 1ppm
Frank

[Rax]

Looping back on this, I think, indeed, the 5440A is well within spec, and quite a bit more. Everything I've seen from the 3458A says 5440a is within 1ppm during two weeks of checks. I'm happy the 3458A was available to decide the argument. To those watching the saga, the Prema 6048 seems to be about 4ppm high before its op amp mods, and its op amp mods seem to have added about 2ppm on top of that, amounting to something like 6.64ppm high.

I feel I can deem the Prema off and the F5440A dead on. Maybe I'll use the latter to calibrate the former. Of course, the factory cal constants of the Prema are restorable by procedure, but given the op amp upgrades, useless in that configuration.

[Rax]

BTW, as much as those points recommended by the SM look great, at 10V out my 5440A isn't all that great. I am seeing it consistently over 1ppm high. INT CAL doesn't change that much. All this is at 24-25C, which is where my bench is sitting around right now.

Just to clarify - this was before I figured how critical fresh ACALs are for the 3458A. Once that became clear and part of my methodology, the 5440A measured well within 1ppm of 10V.

[Rax]

Therefore, to check these 3 ranges of the 5440A, you need to measure 13 and 20V in the 100V range of the 3458A, 100 and 250V in its 1kV range, and about 276V and maybe 1kV for the highest range.
Frank

I realized I forgot to post the results of the checks I did at Frank's recommendation. Please take with a grain of salt, I just did one measurement after another, not undertaking the careful measures he recommended. Partly, by then the time with the 3458A became limited, and unfortunately my time with the 3458A coincided with holidays and guests visiting for the entire period and so on.

Anyway, please see below. The 10V reading was the most recent during that morning, but may have been a couple of hours before the HV checks batch.

• 10V: 9.9999973V
• 13V (100V range): 12.999992V
• 20V (100V): 19.999976V
• 100V (1kV): 99.99872V
• 250V (1kV): 249.99657V
• 276V (1kV): 275.99650V
• 1000V (1kV): 999.98753V

The 10, 13, and 20V readings were with a 1000 NPLC on the 3458A, the rest with 100. In retrospect, I should probably have done the exact opposite, so I'd leave enough time to the 3458A to reach thermal equilibrium.