Automated comparison of several meters

[BradC]

G'day all,

I now have a pair of 3478a to compliment a 3457a. I knew one of the 3478a was off compared to the other two meters, so I knocked up a bit of a hack with a homebrew GPIB controller to present some data to watch.

As you would assume, with a 3457a in 100NPLC, I get 10 readings of the 3478a(s) at 10NPLC for every 3457a reading, so I store all 10 readings from both 5.5 digit meters and then average them.

- The first 3 values are the 3 meters (3478a 3478a 3457a) last raw reading. The reading from the 3457a uses the HIRES register also.
- The next two are the averaged readings from the 3478a(s) over the last 3457a reading period (I just re-trigger them after each read until the 3457a asserts SRQ).

I then just do a simple subtraction between both 3478a and the 3457a and break that out in voltage and PPM of the actual reading (so Meter 3 - Meter 1 and then Meter 3 - Meter 2). As usual, there's way more digits there than there is accuracy, but it's interesting to watch the readings track with different voltages.

Code: [Select]

27.8513  : 27.8498  : 27.84987 :  --- 27.8513  : 27.84976 ---  -1.429 mV :    -51.3 ppm :   108.7 uV :    3.904 ppm : 10,0
27.8513  : 27.8497  : 27.84984 :  --- 27.85129 : 27.84973 ---  -1.455 mV :   -52.26 ppm :   104.9 uV :    3.767 ppm : 11,0
27.8512  : 27.8497  : 27.8498  :  --- 27.85124 : 27.8497  ---  -1.436 mV :   -51.57 ppm :   104.9 uV :    3.767 ppm : 12,0
27.8513  : 27.8497  : 27.84978 :  --- 27.85128 : 27.84969 ---  -1.507 mV :    -54.1 ppm :   85.83 uV :    3.082 ppm : 13,0
27.8513  : 27.8497  : 27.84979 :  --- 27.85127 : 27.8497  ---  -1.482 mV :   -53.21 ppm :   89.65 uV :    3.219 ppm : 14,0
27.8513  : 27.8497  : 27.84984 :  --- 27.8513  : 27.84974 ---  -1.457 mV :   -52.32 ppm :   101.1 uV :     3.63 ppm : 15,0
27.8513  : 27.8497  : 27.84984 :  --- 27.8513  : 27.84971 ---  -1.463 mV :   -52.53 ppm :   125.9 uV :     4.52 ppm : 16,0
27.8513  : 27.8497  : 27.84983 :  --- 27.8513  : 27.8497  ---  -1.467 mV :   -52.67 ppm :   135.4 uV :    4.863 ppm : 17,0
27.8512  : 27.8497  : 27.8498  :  --- 27.85127 : 27.84969 ---  -1.474 mV :   -52.94 ppm :   104.9 uV :    3.767 ppm : 18,0
27.8513  : 27.8497  : 27.8498  :  --- 27.85127 : 27.8497  ---  -1.474 mV :   -52.94 ppm :   97.27 uV :    3.493 ppm : 19,0
27.8513  : 27.8497  : 27.84982 :  --- 27.8513  : 27.84971 ---  -1.482 mV :   -53.21 ppm :   106.8 uV :    3.835 ppm : 20,0
27.8513  : 27.8497  : 27.84982 :  --- 27.8513  : 27.84973 ---  -1.480 mV :   -53.15 ppm :   87.74 uV :     3.15 ppm : 21,0
27.8513  : 27.8498  : 27.84982 :  --- 27.8513  : 27.84972 ---  -1.476 mV :   -53.01 ppm :   103.0 uV :    3.698 ppm : 22,0
27.8513  : 27.8497  : 27.84984 :  --- 27.8513  : 27.8497  ---  -1.457 mV :   -52.32 ppm :   145.0 uV :    5.205 ppm : 23,0

All the math is 32 bit floating point.

Now I might be able to use the information in the 3478a Cal RAM thread to tweak the cal values live and watch what they do relative to both the other 3478a and the 3457a.

I'd forgotten how much you can actually get done with GPIB when you get into it.

[cellularmitosis]

Would love to see the details of you DIY GPIB setup!

[sokoloff]

Interesting. Why not use 64-bit doubles? (Floats are near the edge of the minimum changes you're adjusting for, and doubles are certainly "cheap enough" for the pace of computation required here.)

Ditto on wanting to know more about the homebrew GPIB as well.

[BradC]

Interesting. Why not use 64-bit doubles? (Floats are near the edge of the minimum changes you're adjusting for, and doubles are certainly "cheap enough" for the pace of computation required here.)

I'm doing all the processing on a Parallax Propeller and there's no double float library (and I can't be arsed writing one). There is a C compiler for it, but that's kinda like trying to decode i2c on my 20MHz analogue scope. Sure you can do it, but it's just not designed with that in mind. C on this chip is just a terribly ugly hack, and this is giving me what I need at the moment.

Ditto on wanting to know more about the homebrew GPIB as well.

I built it back in 2010 to grab screenshots from my Tek2440 scope when I was still fairly heavily into the Propeller. It did the job at the time, but was always a nasty hack and I never had the reason to work on it. It's a Propeller 'proto-board' with an IDC connector and a handful of resistors. Not ideal, but has no issue driving 4 devices as fast as it can drive one. More detail here : https://forums.parallax.com/discussion/113404/propeller-speaks-gpib although terribly old and out of date. The hardware hasn't changed at all.

Since I got some new meters I decided it was time to pull it out, dust it off and write a better GPIB stack for it. With my original code I was getting about 5Kb/s with 4 devices on the bus. I now get ~70Kb/s, which is fast enough to take a set of samples from the scope as fast as it can push them out. I can get just over half that through the UART into the PC if I try hard enough, but with 32k of ram to play with and 2Kb samples I can buffer fairly well.

I'm not really communicating with the PC as such. I'm just pumping formatted data out the serial port to a terminal. When I get some time I might write a Prologix compatible parser for it, but being able to do most of the legwork on the chip and not worry about the PC interface has some definite advantages.

[sokoloff]

Interesting. Why not use 64-bit doubles? (Floats are near the edge of the minimum changes you're adjusting for, and doubles are certainly "cheap enough" for the pace of computation required here.)

I'm doing all the processing on a Parallax Propeller and there's no double float library (and I can't be arsed writing one). There is a C compiler for it, but that's kinda like trying to decode i2c on my 20MHz analogue scope. Sure you can do it, but it's just not designed with that in mind. C on this chip is just a terribly ugly hack, and this is giving me what I need at the moment.

Interesting. Hadn't considered that angle and in light of constraints, makes total sense.

Another option you might consider is to use fixed point integer math. (Use an int32 to represent the 10^-7 volts and do all your averaging in integer math, so 27.8513 becomes 278,513,000.)

[guenthert]

Uh, not sure I follow.  If there's a PC involved, why does the Propeller do any data processing?  Can't it act just as a GPIB interface/driver chip while the PC is doing any (non real time) processing? 

[BradC]

Uh, not sure I follow.  If there's a PC involved, why does the Propeller do any data processing?  Can't it act just as a GPIB interface/driver chip while the PC is doing any (non real time) processing?

I could make the Propeller a dumb interface, but since I'm not bumping into any limitations on the chip there's no advantage to doing that currently and doing it this way has significant timing/speed advantages. Additionally this opens up the possibility to do stand alone loging to an SD card.

Also, because I can.

[sokoloff]

Also, because I can.

Best reason of all sometimes. 

[rhb]

Would you be willing to collect some data with PLC=0 for a few days?  I need such data for my attempt to separate 1/f and thermal noise using a sparse L1 pursuit.

[BradC]

Would you be willing to collect some data with PLC=0 for a few days?  I need such data for my attempt to separate 1/f and thermal noise using a sparse L1 pursuit.

I'm certainly willing to look at it. What are you after?

[rhb]

What I need is several days of readings in ASCII format at the fastest rate possible without the power line cycle integration.  Environmental data would be useful, but not needed at this stage.

The basic idea is to assume that the measurement noise consists of 1/f, thermal and mains noise.  What I want to do is test how well a sparse L1 pursuit will separate those three noise terms.  Each noise term should be a constant times a function of frequency.  Because the shapes of the noise amplitude as a function of frequency are different, I should be able to separate them from the true value fo the voltage reference.

The proof of why this might be possible is very painful, but doing it is easy.  You set up Ax=y with an A matrix which includes all the possible functions of frequency you want to consider.  In this case, some function of frequency that is approximately 1/f, another that is constant up ~1/4th the sample rate and a component which is almost a spike at the mains frequency.

Traditionally such problems were solved using an L2, least squares, norm.  In 2004 David Donoho showed that an L1 (absolute value) norm was  identical to the L0 (optimal) norm *if and only if* you can solve the L1 problem..  The L0 requires trying every possible answer which is computationally impossible for practical problems.  But the L1 is easy.

I'm accumulating the stuff to do this myself, but it takes time to collect and setup the stuff.

[BradC]

I may well not have time to get to this until after the 30th of April, but it gives me something to think about in the background.

What resolution are you after? Reading the manual for the 3457a :
NPLC 0-.0005 == 3.5 digits
NPLC .005 == 4.5 digits
NPLC 0.1 == 5.5 digits

The meter defaults to NPLC=10 on power up. "At the fastest rate possible" is 3.5 digits. With Auto-Zero on that's 300 readings per second, and 1350 with it off.

Have a look at page 1-12 of the HP3457a manual to see what it is capable of.

There are potential speed issues or bottlenecks with the serial link back to the PC, but I could work around that by getting the meter to spit out single precision floats (4 bytes) vs its default ASCII interpretation (16 bytes), or even one of its binary integer representations.

Also, I'm not measuring a voltage standard. I am measuring the output of a Tektronix PG506 in DC calibrator mode (50V), divided with resistors to give me as close to the top of the 30V range as is practical without actually having to think. So there will be thermal drift of the measured voltage *and* the meter, although it's not fast.

I do have a 10V reference around somewhere, but it's not great. Probably more stable than the Tek calibrator over temperature though, but then only uses 1/3 of the meters available dynamic range.

(further edit after some testing).
I did some cursory performance tests and the limit of the meter seems to be about 750 readings/sec using a signed 16bit int format. That applies for either 3.5 digits *or* 4.5 digits.
SINT - 750/s
DINT - 420/s
SREAL - 175/s

Given the DINT and SREAL put the same data over the bus, the meter is obviously taking a lot longer to do the conversion internally.

So the optimum would be 4.5 digits, using a 16 bit signed integer That nets roughly 750 conversions/second with AZ off, or ~250 with AZ on.

I assume then that the figures in the manual refer to the maximum sample speed when streaming straight to memory. When belting each sample out the GPIB as fast as the meter can manage we get about half what the meter is capable of, which makes sense in some perverse fashion. So yeah, the best I can do continuously is 750 samples/sec at 4.5 digits.

This is sampling a roughly 3V input at 4.5 digits as fast as I can get data out of the meter. Each line is a 15 second milestone (so roughly 11325 samples)

Code: [Select]

Value is 2860 Got 755 samples / sec
Value is 2905 Got 755 samples / sec
Value is 2988 Got 755 samples / sec
Value is 2843 Got 755 samples / sec
Value is 2892 Got 755 samples / sec


[rhb]

Let's both ponder this between now and May.   I clearly need to read the 3478A and 3457A manuals among other things.  That will also give me time to code up a numerical simulation and read up on the various models for noise from voltage references.  I spent a couple of hours yesterday downloading IEEE papers at the university library.  I've got 42 papers to read.

[BradC]

No worries. It's an interesting experiment anyway to see what the maximum performance is I can squeeze out of my GPIB stack.

I tweaked the meter a bit and found an extra 100 conversions/sec using a 32bit signed int. So ~850 conversions/sec. Strange that using exactly the same config a 16 bit int is slower.

Curiouser and curiouser.
(Nope, I was wrong. I forgot to update the progress calculation for the extra word size. That was 425 conversions/sec at 32 bit, so same as previous).

Til May then.

[BradC]

So I've now got some time and have done a bit more work with the GPIB interface.

My interface used 10K pullups to 5V and 100 Ohm in series with each uC pin on a 3.3V chip. That was pretty reliable with 3 meters (2x3478 & 1x3457a), but things went to poop when I switched on my Tek 2400 and it enabled its GPIB termination. So, cue a new build.

This time I've used a setup that is closer to the GPIB recommendation. 4.7K pull up to 5V, 10K pull down to Gnd and no resistor in series with the uC (I had those resistors arrays on the shelf, and the ratio is close enough to the 3K/6.2K recommendation). The propeller can drive 40mA per pin, and the on-die clamp doesn't start to conduct until VCC+0.3V (so 3.6V in this case). That works with all devices on the bus, and some occasional errors I was seeing every 8 hours or so are now gone. So win. Of course if I plugged a duff device in that forced more than 3.6V on the bus then the uC would probably pop, but everything I have here seems to be pretty well behaved.

Next iteration I'll buy a set of 7516x drivers and do it properly.

I also did some experimentation with the T1 delay, as the minimum is recommended at 350ns and I was only giving 144ns. That seems to have helped also.

I'm still only getting ~750 conversions/sec out of the 3457a at 4.5 digits, and I'm starting to think that is the max it is going to do in a continuous streaming setup. I can get the rated max if I record to RAM, but then I'm limited to ~1000 readings in a burst.