USA calibration club

[orin]

If it could come to the Bay Area, I would love to get my hands on it for a couple of weeks. I have some local friends with well-characterized 732As that would give us some interesting numbers.

Sounds great!  I'll tack you onto the end of the route.  Can you shoot me a PM with your address?

If it's of any interest, I could compare against my very good SVR-T and/or 731B.

https://www.eevblog.com/forum/testgear/geller-labs-svr-and-svr-t/msg282582/#msg282582

The 731B is currently within 1ppm of 10V on the 34461A at a temperature of 25C.  Realistically, that measurement setup reflects the 34461A'a tempco.  A SVR-T vs. 731B setup as in the above post is far more interesting.

Orin.

[cellularmitosis]

If it's of any interest, I could compare against my very good SVR-T and/or 731B.

Definitely!  Can you send me a PM with your address?

[CalMachine]

@CalMachine reply #228

Is the blue line the SVR-T? If so it seems to vary from 2-7ppm above 10V. Earlier you had closer and less variation. Is the environment the same. In the lab you work? I find this very intersting as it shows how difficult it is to be sure of a result.
As I understand you use a calibrated HP3458 as Dr. Diesel also did (calibrated at your work?). His result was very close to spot  on within 2ppm if I remember correct. Both for the DUT and DMMs. How was the calibration of your 3458?

Lars

Correct, the blue line is the SVR-T.  The environmental conditions were fairly constant.  My 2 first logs were of only a few hours each, while the last log was close to 60 hours.  I also didn't have a line transient suppressor available for use with the power supply for the reference... so whatever noise from the grid/nearby SMPS wasn't being filtered.

You hit the nail on the head!  It is very difficult to measure in the PPM world, accurately.   Sure, you're meter might be stable and measuring a reference/source with little noise and deviation between measurements.. but, that doesn't give you any kind of indication of system biases that might be present, skewing your result.

His meters performed pretty flawlessly!!  It was my first time having the pleasure of calibrating a modified oven'd 3458A.  I believe the 3458A I used was last calibrated in March.

[orin]

If it's of any interest, I could compare against my very good SVR-T and/or 731B.

Definitely!  Can you send me a PM with your address?

Will do.

[CatalinaWOW]

I now have measurements enough to keep me thinking for a long time now.

It will be on the way to you kj7e in this afternoons post.

I added a thumb drive to store data and to hold the drivers for the temp and humidity sensor I threw in.

Just for giggles I measured the precisely measured capacitor that is in the box with my $20 LCR meter (https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/).  Just a bit over 1 part in 1000 error in the reading.  Very nice work madires and others who have contributed to this.

[bitseeker]

Oh, good idea to check the $20 tester. I'll have to remember to do that as well.

[kj7e]

I now have measurements enough to keep me thinking for a long time now.

It will be on the way to you kj7e in this afternoons post.

I added a thumb drive to store data and to hold the drivers for the temp and humidity sensor I threw in.

Just for giggles I measured the precisely measured capacitor that is in the box with my $20 LCR meter (https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/).  Just a bit over 1 part in 1000 error in the reading.  Very nice work madires and others who have contributed to this.

Perfect timing, these showed up today. 

[cellularmitosis]

 

[CatalinaWOW]

Brief summary of what I found just before I sent the SVR-T on down the line.

Line regulation ~ 4.9 microvolts/Volt , compares very favorably with specification of < 100 microvolts/volt

Max temp slope over lab temp range is about .6 ppm/deg.  Compares well to specification of <5 ppm/deg although spec is over a significantly larger range.

[bitseeker]

As a volt-noob whose turn with the roving transfer standard is coming up soon, I have a few questions to start preparing.

1. What's the minimum input impedance that's acceptable for the included voltage standard? The defaults for my 6.5-digit bench meters in multi-megaohm, but if I run three or four of them in parallel, will that load down the standard too much? If I, instead, switch them to gigaohm range, will that be too noisy?

2. Since banana plugs were indicated to be suboptimal for connecting to the standard, how many leads are in the package? How do they connect to DMMs that don't have binding posts, just banana jacks?

3. CatalinaWOW's line regulation figures look like I won't have to worry too much about the power supply for the voltage standard. However, I do have a Power Designs 2010 and an HP 6114A to run it.

4. @cellularmitosis: Were you able to get your K196 logging via GPIB?

5. Has anyone in the loop used https://www.eevblog.com/forum/metrology/raspberry-pi23-logging-platform-for-voltnuts for logging? I don't know if I'll be able to try it out prior to the package arriving. If not, I'll just log with my laptop.

Any recommendations or links to information on how best to perform the first run is also much appreciated.

[CatalinaWOW]

I created an inventory of what is in the box, and then cleverly put my only copy in the box.  Maybe kj7e can post it. 

By memory there are four banana plugs with screw caps.  Two of these are connected to a twisted pair of solid copper wire with mini grabbers on the end.  Two more are loose.  There are two twisted pairs of copper wire with bare leads on the end.  Twisted pair with banana plugs and mini-grabbers for attaching the supplied voltage regulator.  The regulator has a twisted pair and the appropriate plug to power the SVR-T.

I also am a noob, but don't think that hooking multiple meters up should be a problem.  The output is directly from the AD587 which specs load regulation as 100 microvolts/mA.   The meters will be drawing microamps so errors from hooking the voltmeters up should be small fractions of a microvolt.

While stability of the power supply will not be important in terms of controlling line regulation, isolation from line transients will be useful.  I spent a little time looking at the SVR-T output through a spectrum analyzer.  Most of the time the noise was quite white down to just a couple of Hz, but occasionally a burst of 120 Hz showed up.  I didn't try to track down the source - I figured that more good would be done by sending the thing down the line.  Another thing that was showing up when I zeroed in on the very low frequency material was a very low level set of peaks (about 85  dB down) about 8 Hz apart.  I will spend some time tracking these down as time goes by.

I did further reduce my data a pretty up a plot.  I can't explain why, but the recommended 15 volt input does seem to be in a sweet spot with extra low response to source voltage.

[bitseeker]

Thanks for the rundown. It sounds like I can hook up two DMMs with the parts in the kit and perhaps some alligator-to-banana adapters. I'll take a look at the twisted pairs when I get the package to see if I can replicate them for hooking up other meters.

Nice graph. It is quite a flat response around 15V. That's likely the reason it was chosen as the recommended supply voltage. I shall power the standard accordingly.

[CalMachine]

5. Has anyone in the loop used https://www.eevblog.com/forum/metrology/raspberry-pi23-logging-platform-for-voltnuts for logging? I don't know if I'll be able to try it out prior to the package arriving. If not, I'll just log with my laptop.

Any recommendations or links to information on how best to perform the first run is also much appreciated.

I use the LogNut image on an RPi3 here at the shop.  It's what I used for the 3458A logging of the reference.

[bitseeker]

Excellent. Which GPIB interface do you use with it, CalMachine?

[CalMachine]

I am using the NI-USB-GPIB-HS dongle with it

[bitseeker]

Cool. I've got an 82357B (a real one from what I can discern from its internals), which seems to have been a bit of a pain for the LogNut project recently. Hopefully, it'll work OK. I'd also like to try to get the interface working with the BeagleBone Black as I have a 7" LCD cape for it, which would look great with a live graph. Ah, too many projects.

[cellularmitosis]

4. @cellularmitosis: Were you able to get your K196 logging via GPIB?

Not yet.  I am currently working on getting multiple 8-channel logic analyzers to work in unison with Pulseview (the open-source logic analyzer GUI).  The Sigrok developers were kind enough to supply me with a patch, and I'm currently working on muxing the output of two analyzers into a single dump file so that it can be viewed in their GUI.  Once I get that working, then I can start to figure out all of the idiosyncrasies of my GPIB attempts (e.g., why can the UGSimple write to the K196, but not read from it? etc).

I'll keep you posted!

[bitseeker]

Wow, that sounds like quite a project in itself. Cheers!

[vindoline]

Hi bitseeker,

Recently I've had some success logging my Keithley 196 via GPIB. I built up the Arduino based GPIB adapter described here: http://egirland.blogspot.cz/2014/03/arduino-uno-as-usb-to-gpib-controller.html
I think the only changes I made to the Arduino code is to make sure the GPIB ID matches my K196, that the USB port matches my Mac, and to set the "++auto" mode to true.

On my Mac, I'm using muxr's logging and plotting scripts described here: https://www.eevblog.com/forum/metrology/mplot-logging-and-plotting-script-for-long-term-measurements/
It took me quite some time to figure out how to to install and configure these, but it was the first time I did anything with Python. I had to make a few small changes to the code, but I don't remember what off the top of my head.

Now I'm trying to get the RPi solution working, but I'm totally lost with it.
Good luck and have fun!

[alm]

To read from the 196 with a Prologix-compatible GPIB interface, you would probably need something like:

Code: [Select]

++addr 16
++auto 1
F0R0X
16 should be the GPIB address as set on the 196 through the front panel. This should output a continuous stream of readings. See the Keithley 196 manual for more details.

If you want to trigger a single reading at a time, you could send T5X, and it will only perform a single reading on receiving the X command.

[vindoline]

Thank yo alm. My setup is "working" at the moment, but for all the wrong reasons! My Mac (via Python) is reading the responses from the K196 fine. I'm having trouble getting the Mac to talk to the K196 though. I'm not certain if the issue is with Python on the Mac or in the Arduino code. However, with the Arduino GPIB in auto mode, any characters sent to it (including gibberish) result in the current meter reading being returned.

The odd part is that if I use the serial terminal built into the Arduino IDE, everything seems to work fine. My best guess at this point is that it's some kind of line ending mismatch.

[alm]

So sending something like R1X does not effect a range change? Note that the meter will do nothing until you send the eXecute command. Do you see any errors on the 196 display when you send a command, like IddC?

I would start by power cycling the meter and resetting the DMM to factory defaults through the front panel (program 37). This will also reset the GPIB address to 7. You could try if changing the line termination to only LF (Y3X) via the Arduino IDE makes a difference. Not sure what the Arduino IDE does as far as line terminations are concerned. Maybe try sending something like "R1X\r\n" from Python?

[vindoline]

Hi alm, the meter has been power cycled, but I've never reset it to defaults. I can send "R1X" etc. from the Arduino terminal and it works. When I try and have python send the same message, it's not working. So I'm assuming something is getting mangled between the python and arduino. I can check this evening about the error codes. I know I've seen them, but I don't recall under what circumstances.

[Ash]

Thank yo alm. My setup is "working" at the moment, but for all the wrong reasons! My Mac (via Python) is reading the responses from the K196 fine. I'm having trouble getting the Mac to talk to the K196 though. I'm not certain if the issue is with Python on the Mac or in the Arduino code. However, with the Arduino GPIB in auto mode, any characters sent to it (including gibberish) result in the current meter reading being returned.

The odd part is that if I use the serial terminal built into the Arduino IDE, everything seems to work fine. My best guess at this point is that it's some kind of line ending mismatch.

I'm using a Prologix Ethernet based interface with python and I have my K196 working fine. This is my initialisation sequence that I send to the device each time.

Code: [Select]

# Configure the Keithley 196
gpib.select(K196_A_ADDR)
gpib.write("K0X") # enable EOI and bus hold off
gpib.write('F0X') # DC Volts
gpib.write('R3X') # 30V range
gpib.write('Z0X') # Zero disabled
gpib.write('S3X') # 6.5d rate
gpib.write('B0X') # reading from ADC
gpib.write('G1X') # data format without prefixes
gpib.write('P0X') # Digital running average filter disabled
gpib.write('N1X') # Internal Filter for high sensitivity measurements enabled
gpib.write('A1X') # enable Auto/Cal Multiplex
gpib.write('T0X') # continous on talk

When I do a read, I'm using the prologix "++read eoi" command to wait for end of input to be asserted. The "K" command is something to look at.   

I understand you are building your own GPIB interface, that's cool. I believe the older instruments are a bit picky sometimes with the signalling. Also ensure that you have sufficient line drive capability from the Arduino as I've heard that some older instruments load the bus more than they should. 

If it helps, my code (very hacky scripts at the moment as I'm trying to get stuff going before cleaning it up) is here: https://github.com/AshleyRoll/GBIPLogger There is also some plotting code I'm working on there for my Australian Voltnut stuff.

Good luck!

Ash.

[alm]

Do you mean some devices load the bus more than allowed by IEEE 488.1, or that they load it more than a wimpy micro that does not conform to IEEE 488 can drive? GPIB drivers are supposed to be pretty beefy and able to drive up to 20m of cable and up to fifteen devices at the same time.

By the way, you could skip X on all but the last command, or even write it as a single string (K0F0R3Z0...X).