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?).


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