3458A Worklog

[CurtisSeizert]

To put some numbers to my last post, I compared aperture jitter calculated from the sample times taken in the code to aperture jitter calculated from phase noise of a 9 Hz carrier using a DS345 function generator.

The aperture jitter calculated in the code was 384 usRMS, and it was 26 usRMS as calculated from phase noise. This very close to what I got with an Analog Discovery Pro, so the measurement is probably limited by the DS345.

[CurtisSeizert]

I began getting some trigger too fast errors with the code I was using, and the problem was somewhat sporadic at 50 SPS - worse at some times, better at others. At 40 SPS, I got no errors, at 60 SPS, I always got them. From doing a little bit of experimentation, I found that running captures while transferring one data point per GPIB transaction could not do better than about 19 ms with my GPIB to USB bridge. This was with all the settings necessary for fast mode and "OFORMAT SINT". That is not much faster than transferring not in fast mode with "OFORMAT ASCII", just about 1 ms for me.

To solve this problem, I just transferred all the data in one transaction. It is not much more work to go from the float values to integers, and you can get a lot better throughput with integers, probably because this output format puts the meter in fast mode. However, it is difficult to avoid trigger too fast errors for long captures at fast sample rates, even if you can further increase the sample rate and get no errors with short captures. For example, with 10kSPS and 10k samples I get an error, and with 50kSPS and 131 samples I get no error. I consistently get an error at 132 samples with 50kSPS. With 10kSPS, 1k samples is fine (I haven't checked the exact limit), and with 5kSPS, 10k samples is fine. Changing the aperture time as a fraction of the sampling interval has minimal effect up to maybe 90% unless you are on the line. The code I used for this is below - I just used this for testing, and there is the possibility it will hang forever if something goes awry.

Code: [Select]

from pyvisa import ResourceManager
import time
import pandas as pd
import numpy as np
#import matplotlib.pyplot as plt


DCVrange = 0.1

numsamp = 10000
sfreq = 5000
sleeptime = 1

stime = 1/sfreq
aper = 80*stime/100
logfile = 'test.csv'


df = pd.DataFrame(columns = ("V","freq"), dtype = float)


rm = ResourceManager()
dmm = rm.open_resource('GPIB1::22::INSTR')


dmm.timeout = None

# Setup commands and clear errors
dmm.write("END ALWAYS")
dmm.write("BEEP OFF")
dmm.write("TARM HOLD")
dmm.write("TRIG HOLD")
dmm.write("ERR?")

dmm.write("OFORMAT ASCII")

print("")
print("Voltage meter: ", dmm.query("ID?"))

print("")
print("Waiting %d seconds" % sleeptime)
time.sleep(sleeptime)

# For high-speed mode
dmm.write("ARANGE OFF")
dmm.write("MATH OFF")
dmm.write("OFORMAT DINT")
dmm.write("DISP OFF")

# Measurement parameters
dmm.write("DCV %f" % DCVrange)
dmm.write("APER %f" % aper)
dmm.write("TIMER %f" % stime)
dmm.write("NRDGS %d, TIMER" % numsamp)
dmm.write("AZERO OFF")
dmm.write("MEM OFF")
dmm.write("INBUF ON")
dmm.write("RATIO OFF")

dmm.write("TARM AUTO")

V = np.empty([numsamp], dtype=np.int32)
t0 = time.time()

V = dmm.query_binary_values("TRIG SGL", datatype='i', delay=0, container=np.ndarray, data_points=numsamp, is_big_endian=True, header_fmt='empty')

scale_factor = dmm.query_ascii_values("ISCALE?")[0]
t_tot = time.time() - t0
avg_time = t_tot/(numsamp-1)

print("Average sample time: ", avg_time)

dmm.write("DISP ON")
dmm.write("BEEP ONCE")
dmm.write("OFORMAT ASCII")

df["V"] = V*scale_factor

df["freq"][0] = sfreq
df.to_csv(path_or_buf= logfile)

err_code = dmm.query("ERRSTR?")

if(int(err_code[0]) == 0):
    print("Valid data: no errors")
else:
    print("Invalid data: ", err_code)

I don't know offhand why I get the trigger too fast error under specific conditions with this code. It would seem that if the GPIB transfers can keep up with a handful of readings, there should be idle time between the transfers of individual samples. If there is idle time, there should not be enough fluctuation between times of individual transfers that 50kSPS could work for 100 or so readings and 10kSPS could give errors at some point. This code has no way of giving the intervals between individual samples, so it is not clear how many times in, for example, a 1M sample capture at 10kSPS the error is being thrown. In such an experiment with aperture time at 90% of the sampling interval, the average sample time was 100.14us, and this was consistent. In any event, I have run multiple captures using this code (with OFORMAT DREAL) at 4M samples and 200 SPS with no trigger errors, and I used 90% aperture for those. It would be nice to use this method to take arbitrarily large captures at the GPIB bandwidth limit of about 50kSPS for DINT and 100kSPS for SINT, but I haven't been able to pull that off yet.

[Dr. Frank]

GPIB usually is able to transfer @ 1MByte/sec, therefore there is no problem for Digitizing with SINT @ 100kHz (16bit, 1.4µS APER) and DINT @ 50kHz (>= 18Bit, 10µs).
You have several possibilities for making fast data acquisitions , with very low jitter.
At first, you either need to use the TIMER function for arming / triggering, or you might use external triggering at the required sample rate.
Latter gives +/- 50ns latency / jitter, or you might go one step further and synchronize with the internal 10MHz timebase, as NIST / PTB do for their AC digitization standards.
Then you have two possibilities for the data transfer, or data storage.
You might first sample into the internal memory of up to 148kB, and afterwards read it from there.
If you want to sample directly into the PC, you need to use low level GPIB commands for array transfer. My GPIB card features:
procedure rarray (var d; count : word; var len : word; var status : integer)

where you can transfer a pre determined amount of data, up to 64kB with one trigger   
That avoids any GPIB READ or TRIG commands for each data point, which would slow down the transfer., and gives a high trigger uncertainty / jitter.   
I also used low level GPIB commands like MLA 0 TALK 22, so that trigger and data transfer is completely managed by the basic GPIB functions of the interface card and the hp3458A.

You might find examples for such precisely timed, fast transfers also inside the source code (vb) of the Swerlein algorithm.
Frank

[leighcorrigall]

Does anyone know what the two-position fan connector is called? I would like to order a replacement to swap fans in quickly.

Thank you.

[leighcorrigall]

Does anyone know what the two-position fan connector is called? I would like to order a replacement to swap fans in quickly.

Thank you.

I was told by a community member that they used the following as replacement parts:

TE Connectivity 104257-1 with 1-104480-6

I am also going to try out the following:

Molex 0015474023 and 0705410036

EDIT: The Molex part numbers seem to be original. I would suggest these, although the TE Connectivity parts seem to be interchangeable.

Some additional comments:

I would also like to point out that MiDi's fan selection is excellent. It seems to have slightly lower noise and cooling capabilities. The internal (34 Celsius) and external (23.5 Celsius) temperature difference (delta) is about 10.5 Celsius when the fan filter is installed.

The only disappointment was that the mounting hole diameters were slightly larger than the original. This consequence means that a fastener assembly needs to be applied to secure the fan. The author of this post does point this out, but it should be made more obvious.

Clearing the fan filter significantly improved the temperature. This easy process will prolong the service life of this instrument by reducing the internal temperature by a degree or so.

[Arhigos]

Does anyone know how I can remove SCAL FREQ REQUIER message from the meter? I checked AC and Frequency and its all good. I just want to get rid of that message 

[Dr. Frank]

Does anyone know how I can remove SCAL FREQ REQUIER message from the meter? I checked AC and Frequency and its all good. I just want to get rid of that message 

Probably you just have to do a frequency calibration. See service manual, how to.
Frank

[MiDi]

To characterize noise of unit, measurements for different ranges, NPLCs, short/FS and AZ on/off were taken.
It gives the base for major project on improving noise of unit by exchange of A9 for low noise ADR1000 and changing several op amps e.g. for reference scaling (+12V/-12V/+5V) - inspired by talk from Chuck Beuning at MM24.
More on that in future posts, currently FW mod and A9 ADR1000 is installed w/o issues.
FW mod only changes the minimum cal values, so that lower voltage ADR1000 can be used w/o additional gain stage.


Comparison for input short of different NPLCs for 10V with AZ:

   

As expected NSDs for 10 to 100 NPLC are similar, as the 3458A just does multiple 10 NPLC readings for higher NPLCs and takes the mean.
Overlapping Allan Deviation (OADev) gives a bit different picture for averaging times >1h, seems there is an advantage for longer integration times - the cause is unclear, it may be just a fluke.
Unexpected is the significantly increasing NSD and additionally the increasing 1/f and "HF" part to higher NPLCs.
OADev tells 2 NPLC has lowest noise at ~3h averaging, but may be just a fluke.


Same comparison on 0.1V range:

   

Difference of NSD 1/f part is nearly same for all NPLCs compared to 10V, which implies origin from AFE and not Ref/ADC, the "HF" part does not increase, instead bump between 0.1..1Hz rises.
OADev show no significant difference between NPLCs around 5min averaging, for higher averaging times environment and other factors may be the main contributor as there is no clear picture of what is going on.


Comparison of short/FS on 10V range (FS with 2 different 3x18650):

   

NSD shows prominent 1/f noise at FS compared to input short.
OADev reveals some more details that are barely visible in NSD: 10.6V shows lower noise for higher averaging times in comparison to 11.8V.
My guess is this is the transition of 1/f noise from FS to short, which could be verified by measuring different input levels.
Lowest noise for 10.8V between 10..20s averaging is around 120-150nV, which is in compliance what PTB showed at MM24, but lower noise around 90nV (10NPLC, 5V input?).
As for the short the NSD is significantly increasing to higher NPLCs and OADev confirms lower noise for 1NPLC.
That implies to capture in 1NPLC and do averaging later in software for lowest noise.

Comparison with other 3458A meters on 10V range (AZ off):

   

With AZ off there is no significant difference in noise between 1 and 10 NPLC in comparsion to AZ on.
My unit shows a bump between 1..10Hz, which is not present in the other units and not visible with AZ at 10V and indicates that something is off.


Same on 0.1V range (AZ off):

   

Same on 0.1V, with AZ off there is no significant difference in noise between 1 and 10 NPLC as was with AZ.
Bump now between 0.1..1Hz (same as with AZ on), what could change this bump in frequency for range change?


References:
Captured data
Captured data from reps
Python script to capture the data
Python script to analyze and plot the data (combined plots for NSD, ADev, OADev, MDev included)
Python script to combine different data in one plot # currently not available online, will be updated

[Kleinstein]

The Allan deviation at the very long times is effected by thermal drift and similar. Different runs may not experience the same degree of thermal drift. This could explain the difference between the 10 PLC / 50 PLC and 100 PLC curves, that suould normally look similar.
It quite normal that about the last decade of data for the Allan deviation is not that repeatable. Also a new run with the same setting can look different there.

[aronake]

To characterize noise of unit, measurements for different ranges, NPLCs, short/FS and AZ on/off were taken.
It gives the base for major project on improving noise of unit by exchange of A9 for low noise ADR1000 and changing several op amps e.g. for reference scaling (+12V/-12V/+5V) - inspired by talk from Chuck Beuning at MM24.
More on that in future posts, currently FW mod and A9 ADR1000 is installed w/o issues.
FW mod only changes the minimum cal values, so that lower voltage ADR1000 can be used w/o additional gain stage.

Nice work and detailed measurements! Do you have any before and after comparison for the ADR1000 mod? Or anyone else seen some data on this?

[MiDi]

A9 ADR1000 sneak peek.
Keep in mind that there is a scaling factor of 1.06 from ADR1000 to LTZ1000.

   

[Kleinstein]

Why does the reference make so much difference also with a shorted input ?  There is a small contribution expected, but it should not be that much, unless the A9 reference is rather noisy in the higher frequency range.

[MiDi]

Why does the reference make so much difference also with a shorted input ?  There is a small contribution expected, but it should not be that much, unless the A9 reference is rather noisy in the higher frequency range.

No clue, scaling factor should not effect 0V noise.
The A9 ADR1000 has some additional EMI-filtering (10nF), but that should not have any significant effect (schematic see attachment).
The attached zoomed view of the NSD for short shows 10-15nV / 8-10% lower noise.

How does ref noise at higher frequency reflect back into noise at lower frequency for shorted input?

[Dr. Frank]

Hello MiDi,
thank you for sharing the information.
Have you already replaced the noisy OpAmps for the +/- 12V and +5V references at U180, like Chuck Beuning did, or wanted to do?
Others already claimed, that w/o replacement, the lesser noise of the ADR1000 would not become effective.

Have you observed what happens with your specific ADR1000, when it's switched off for several days, or weeks?

I have observed that its reference voltage needs 1..2 weeks to recover to its old, powered-on state.
When sitting idle, my specimen showed a temporary shift of up to +5ppm after re-powering.

Frank

[Kleinstein]

The capacitor C3 shown in the ADR1000 ref. circuit can make quite some difference for the noise in the 100 kHz range.

The higher frequency (e.g. half the run-up modulation frequency or some 160 kHz) reference noise can modulate down to near zero. The run-up alternates between using the positive and negative reference to get a zero. The switching effectively acts like an RF mixer, muliplying the ref. noise with the modulation pattern (as +-1).  There is some gain from the 50K/40 K resistor ratio. At least the 7 V to +-12 V gain is largely filtered, otherwise the ref. noise could be even worse.  In my estimate for the noise contributions the mixed down ref. noise is about on par with the integrator noise (mainyl the LT1001). There is quite some uncertainty here as the 100 kHz range noise for the LTZ1000 is not in the datasheet and details of the ref. circuit can have an effect from filtering to an added noise peak.

Filtering out the part about some 50 kHz does not take much. I think this is a part that is missed in the design, not just for the 3458. It is a bit tricky part that is easy to miss. It's also a slightly odd part that gets less when the voltage gets higher. As a complication the frequencies involved would also change.

[MiDi]

Have you already replaced the noisy OpAmps for the +/- 12V and +5V references at U180, like Chuck Beuning did, or wanted to do?
Others already claimed, that w/p replacement, the lesser noise of the ADR1000 would not become effective.

Have you observed what happens with your specific ADR1000, when it's switched off for several days, or weeks?

I have observed that its reference voltage needs 1..2 weeks to recover to its old, powered-on state.
When sitting idle, my specimen showed a temporary shift of up to +5ppm after re-powering.

Replacement of ref gain op amps are next steps, first want to get data with A9 replacement only.
The ADR1000 is only a week on until now, will do further tests after it has settled (TC, on/off hysteresis, ...) - so in 3-4 years maybe  .

The capacitor C3 shown in the ADR1000 ref. circuit can make quite some difference for the noise in the 100 kHz range.

The higher frequency (e.g. half the run-up modulation frequency or some 160 kHz) reference noise can modulate down to near zero. The run-up alternates between using the positive and negative reference to get a zero. The switching effectively acts like an RF mixer, muliplying the ref. noise with the modulation pattern (as +-1).  There is some gain from the 50K/40 K resistor ratio. At least the 7 V to +-12 V gain is largely filtered, otherwise the ref. noise could be even worse.  In my estimate for the noise contributions the mixed down ref. noise is about on par with the integrator noise (mainyl the LT1001). There is quite some uncertainty here as the 100 kHz range noise for the LTZ1000 is not in the datasheet and details of the ref. circuit can have an effect from filtering to an added noise peak.

Filtering out the part about some 50 kHz does not take much. I think this is a part that is missed in the design, not just for the 3458. It is a bit tricky part that is easy to miss. It's also a slightly odd part that gets less when the voltage gets higher. As a complication the frequencies involved would also change.

Indeed, C3 adds additional LPF.
Thought about replacing op amps in the integrator/slope amp to decrease noise, any suggestions?
At least LT1001 in integrator could benefit from lower (current & voltage) noise upgrade.
Additional LPF of +-12/5V ref voltages could be another thing to try.

[Kleinstein]

For the amplifiers I would consider the OPA205.
U110 should be effective with a noise gain of 2.25. Here the current noise is also relative important.
U165 should be effective with a noise gain of 1.25.
U160 should be effective like the reference.
U151 (for the +5 V ref. level) should be non critical and hardly worth a change.
In the integrator (U110) one may want to increase R112 because of the higher bandwidth.

The slope amplifier is a bit noisy, but still good enough. The quantization noise should still be a little higher. It would mainly effect the short integration times, like < 1 ms and hardly noticable at 1 PLC.
A logical position for a low pass filter is at the input of U160.

[MiDi]

The KiCad project files and documentation for A9 ADR1000 are released: https://github.com/EleDes/3458A_A9_REF_PCB_KICAD




Specs of realized A9 (trimmed R415/R2 for low unheated TC for oven setpoint):

Tset	59
Iz	10.51E-3
Vz	6.693419
R415/R2	12600
VQ2be	0.5147
VR414	0.5256
Enpp 0.1-10Hz	330E-9	STD 28E-9 (DIY LFLNA-80 1054Z 20MHz BWL, 2MSPS, 24Mpts, mean of 13 Samples)
Enpp 0.1-10Hz	258E-9	STD 23E-9 (DIY LFLNA-80 1054Z 20MHz BWL, 1kSPS, 12kpts, mean of 14 Samples)
En 1Hz	17E-9	(DIY LFLNA-80 3458A 1V, 1NPLC, AZ off, fast)

For comparison: typical LTZ1000A noise @3.6mA is ~840nVpp and ~60nV @1Hz (from DS)

         


Big thanks to xdevs, reps discord, the metrology meetings and the other voltnuts that shared their experience, published their designs and contributed to development.

[MiDi]

3458A ADR1000 vs LTZ#3 drift, two short off times had very little effect on ADR1000 (March 2nd and 3rd):



The TC of A9 ADR1000 inside 3458A is around -80ppb/K vs. interpolated CAL175 (from hourly ACAL):

[MiDi]

Evaluation of drift after ACAL ALL:

[Kleinstein]

That is quite some drift after ACAL. It also seem to be 2 separate parts for the offset and gain.
For the offset I can somewhat understand some drift from thermal EMF from heat in the front end, especially the reed realy at the input and maybe resistors near by.
The gain part (larger effect with external voltage) it is a bit unclear, where this could come from. My guess would be thermal effects at the ADC. Another possibility could be some disturbance of the reference during the ACAL measurment of the reference.
A related test could be checking what happens after just a pause (e.g. switch to current measurement with zero current) for some 10 minutes. There I would expect a similat thermal effect, but of cause no loading of the reference.

[MiDi]

Good point, need to verify if external voltage reference is effected by ACAL (AFE switching).
Thermal effects in ADC leading to gain error of around 0.07ppm (10V) would be more than stated INL of 0.05ppm.

The network used in the HP 3458A's ADC shows no measurable self-heating nonlinearities. - p.13 HP Journal 1989-04

[Dr. Frank]

Good point, need to verify if external voltage reference is effected by ACAL (AFE switching).
Thermal effects in ADC leading to gain error of around 0.07ppm (10V) would be more than stated INL of 0.05ppm.

The network used in the HP 3458A's ADC shows no measurable self-heating nonlinearities. - p.13 HP Journal 1989-04

Hello MiDi,
I was wondering, why you made an ACAL ALL, when you obviously wanted to check the ACAL DCV - 10V range only?

Within 20 min, if I interpret your graph correctly, this probable heating effect decays from about +0.04 ppm to zero.. that's a very small effect, and quite good, I guess.
I made similar stability measurements on my pimped 34465A, after ACAL you see several ppm of drift, and you can't distinguish, whether this is an effect of the A/D, the input amplifier circuit, or the LTZ1000 reference, which is in doubt to be influenced by an ACAL.

Therefore, another such stability measurement after a simple ACAL DCV would be helpful.

Thank you
Frank

[MiDi]

It was just a by-product of the ongoing evaluation of A9 ADR1000 & subsequent mods, my standard logging simply does hourly ACAL ALL.
Good point, A9 ADR1000 could be influenced by ACAL, but no clue how to check that - at least could compare to stock A9.

[MiDi]

Investigation of the mysterious ADC Zero Glitch Jump Circuit: summarized it forces input currents to the integrator to <-4µA & >4µA (±200mV offset) and switches between the currents at around 0V (if circuit enabled).

At the input of rusn1 (U180 28) R185 3.01Meg connected to -12ref gives -4µA offset current, corresponding to -200mV.
ZJUMP switches between 0V and 5V, 5V on R184 619k gives 8µA current into rusn1, in sum with R185 current gives 4µA (200mV).
ZGJC is enabled & latched by XLEN (U181 6) and controlled by U212A (D-Flip-Flop bottom left on IN-GRD CTL) with the main input PC at 1D.
PC is controlled by µC 8051 U220 and additionally connects as PC_F to Sentry Input Signal Conditioning U11D 11 (top right) - wondering what magic it is doing there.

At least for DCV 1NPLC AZ the ZGJC is active all the time - XLEN switches always between AZ and input cycle transition.
But it is only effecting 10V and 1000V range, for 100mV ZJUMP is always high, for 1V & 100V always low  .
To correct the offset, the state of ZJUMP needs to be evaluated and ±200mV subtracted from measurement.

How the state of ZJUMP is determined is still a mystery, as there is no connection to anything else.
It would have been easy to feed ZJUMP or comparator output (U181 7) into µC or GAL as there are a couple unused inputs, so there might have been reasons not doing that.
Likely it is evaluated indirectly by a measurement at some point, e.g. first runup slope direction.

The transition of DCBUF from AZ to input looks somehow weird, especially for the 100mV, 1V & 100V ranges.
Something going on in Input Signal Conditioning, PC_F signal?


10V 0V (Cyan is XLEN):


Setup:


Additional screenshots of the other ranges attached