USA calibration club

[cellularmitosis]

Congrats on the meter!  Fantastic! 

That $29 GPIB adapter sounds like a great deal, definitely the cheapest I've seen so far!  I'm tempted to order one just to see if it solves my problem (I have the Galvant Industries open source GPIB board, which works with my HP 3478A, but not with my Keithley 196).

I just got the board design finished and ordered from dirtypcbs.  Should be here in about 3 weeks.

I decided to throw in a button with the idea that you can use it to log a generic "event".

[Muxr]

Muxr

I saw a decent deal on a pretty beat up 3458A so I decided to bite the bullet.

From now on, it's only going downhill, trust me

There are worse hobbies I suppose 

You can get brand new front panel plastic from the Keysight, MPN: 03458-40212. It's relatively cheap (100$) + 30$ for the display window (which says Key-sigh on it .
Binding posts block is $230 however. 

Thanks TiN! Will give them a call about the face panel!

Congrats on the meter!  Fantastic! 

That $29 GPIB adapter sounds like a great deal, definitely the cheapest I've seen so far!  I'm tempted to order one just to see if it solves my problem (I have the Galvant Industries open source GPIB board, which works with my HP 3478A, but not with my Keithley 196).

I just got the board design finished and ordered from dirtypcbs.  Should be here in about 3 weeks.

Thanks CM! I ordered one today, will definitely keep you guys posted if I have any luck with it once I get it.

[VintageNut]

Here are the results of the Gellar Labs reference being monitored via DMM7510

First the graph of the voltage vs time. You can see the popcorn noise. One of the individual popcorn events is rather large.

Next, the statistics view. The average is almost exactly 10V. So, the deviation from 10V, is just about exacly the deviation from 10V of the DMM7510. That deviation is just a couple of PPM. I will dig out the calibration report of the DMM7510.

The standard deviation is 77.16 uV. This standard deviation is an order of magnitude larger than the standard deviation of my Fluse 731Bs. My conclusion is that the Gellar reference is noisier than the 731B.

[technogeeky]

Here are the results of the Gellar Labs reference being monitored via DMM7510
...

1) Glad it got to you safely.
2) Wow, what an instrument that is!

[VintageNut]

The stats were not posted properly. Here they are

[CatalinaWOW]

Great find on the meter MUXR.  Just to make us really sick do mind sharing how good a deal you got?

[Muxr]

Great find on the meter MUXR.  Just to make us really sick do mind sharing how good a deal you got?

Don't think it will make you feel sick. I think it was priced fairly. Largely as is, and pretty beat up, I talked the seller down to $2800, he accepted. It's still a lot for largely a gamble on an abused piece of gear. But at the end of the day it's a great instrument, and I really wanted to be able to evaluate drift on the references I am working on with an 8 1/2 digit meter.

Not going to lie either, it's the most expensive used item I bought on Ebay. The heart did skip a beat when I placed the order. 

[Muxr]

The stats were not posted properly. Here they are

Thanks VintageNut! Did you happen to take note of the temperature and humidity during the run? Also this was as is, with the temp. compensation jumper on?

[TiN]

If you have good A3 (seems only me get very lucky with bad/dead A3 every meter I got ), than it's very well worth the money.
Looking forward for your data plots.

Btw, any schedule you guys have for rotating standards?
Little bird tells me that I might have a voltage reference and a resistor to participate in USA club rover  .

I might also be on short trip to Oregon next month...

[bitseeker]

There isn't a fixed schedule that I'm aware of. We're in a loop and each person, when they're done, just ships everything to the next one in order. CM posted a neat little map last month.

I haven't counted the posts in this thread thus far to figure out how far around it is right now (I'd guess New York or thereabouts). However, I do see what appears to be an upcoming stop in Oregon. So, I guess you could jump into the loop there by coordinating with CM or whomever is at that stop. If that timing doesn't work out, you could just send your additions from Oregon to whichever is the upcoming stop at that point in time.

[Muxr]

If you have good A3 (seems only me get very lucky with bad/dead A3 every meter I got ), than it's very well worth the money.
Looking forward for your data plots.

Thanks TiN, your articles were instrumental in learning about this piece of equipment. I read about your ordeals with A3 in particular. Hopefully I get lucky. It will take me awhile to determine how drifty this unit is. I need to build some more references including a few KX LTZ1000 (which will take some time to age as well). I am also building some 1027 based ones.

Btw, any schedule you guys have for rotating standards?

There is no set schedule, so far Cellularmitosis has been kind enough to send out his SVR-T reference together with all prepaid labels for the entire loop of the trip to people who have expressed interest. I think this is a test run to see how well this works.

Maybe we should start a GoogleDocs Spreadsheet to keep track of each reference so that we can have multiple in flight.

Little bird tells me that I might have a voltage reference and a resistor to participate in USA club rover  .

I might also be on short trip to Oregon next month...

I am in FL.. too far but would love to participate in measuring and plotting of one of your references. I can cover the shipping costs.

[Muxr]

Ok, my UGSimple arrived moments ago. With shipping it was $36 (certainly one of the cheaper GPIB solutions). It was trivial to get it working on my Raspberry Pi. http://www.ebay.com/itm/171631337518?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

- I hooked it up to my HP 3458A

- cloned the python repo from here: https://github.com/haata/ugsimple-usb-gpib

I just needed to install pyusb python module "sudo pip install pyusb" (if you don't have pip you can either use easy_install or just install pip first "sudo apt-get install python-pip")

There is an example script as part of the project I just modified it to use HP 3458A commands (which I must say are weird, they are different than your usual scpi gpib commands I've seen on other DMMs.)

Here is the script:

Code: [Select]

from ugsimple.GPIB import UGSimpleGPIB

if __name__ == '__main__':
    # Initialize the UGSimpleGPIB USB adapter
    # Requires root permissions (or add the udev rule)
    mygpib = UGSimpleGPIB()
    #mygpib = UGSimpleGPIB(debug_mode=True)

    # Firmware / Device Information
    print ( mygpib.firmware_version() )
    print ( mygpib.manufacturer_id() )
    print ( mygpib.series_number() )

    # List Connected Devices
    print( mygpib.query_devices() )

    # GPIB address of the device
    addy = 22

    # sending the command to 3458A
    mygpib.write(addy, "TARM SGL,1")

    # reading from device
    data = mygpib.read(addy)

    print data
    print ('%.08f' % float(data))
And this is what it looks like in action (I use the "watch" command here which executes the script periodically") "watch sudo python example2.py":




edit: I should add, I ran into a few syntax errors (on the device) while running this occasionally, so maybe this little module has some issues with synchronization. So high frequency polling is likely out of the question. But for my once a second or once every 2 seconds polling it looks like it will be sufficient enough.

[TiN]

That is awkward way to say at least
Why not just add loop in python app like:

Code: [Select]

for cnt in range (0, 100000):
    # make 100k samples
    # sending the command to 3458A
    mygpib.write(addy, "TARM SGL,1")

    # reading from device
    data = mygpib.read(addy)

    print data
    print ('[%d] %.08f' % (cnt, float(data)) )

I like HP 3458 protocol, it's much easier to remember DCV 100 than SCPI stuff like :SENS:VOLT:DC:RANG 100 etc . But SCPI has it's power, when you take existing tested app and just run on another SCPI-compatible meter, with just few minor tweaks.

[Muxr]

That is awkward way to say at least
Why not just add loop in python app like:

It's just for a quick demo, keeping it short. Adding it to my plotting/logging script with a loop and error handling now.

As far as HP3458A commands go, they are just not familiar. I see your point, they do seem easy to code.

[TiN]

Well , here is my spaghetti python which I use to log meters together.
This specific one reads BME280 I2C sensor locally from Pi, have classes for Keithley 2510 (unused), Keithley 2001/2002 SCPI, Keithley 182 (proprietary protocol), HP 3245A and HP 3458A.
It also logs temperature of 3458A  every 100th sample and runs ACAL if temp changes more than 0.5c either direction.

Surely, python experts will puke from the code, but hey, it works for me so far .
Output CSV is processed by D3js on my site, to make chart like this one.

[Muxr]

Well , here is my spaghetti python which I use to log meters together.
This specific one reads BME280 I2C sensor locally from Pi, have classes for Keithley 2510 (unused), Keithley 2001/2002 SCPI, Keithley 182 (proprietary protocol), HP 3245A and HP 3458A.
It also logs temperature of 3458A  every 100th sample and runs ACAL if temp changes more than 0.5c either direction.

Surely, python experts will puke from the code, but hey, it works for me so far .
Output CSV is processed by D3js on my site, to make chart like this one.

I write Python (Golang and Lua) for a living and work on some fairly large projects, which enforce some pretty strict rules in terms of code style etc (cloud applications, stuff like OpenStack).. but all the rules can get pretty annoying.. especially if you have people on the team who like to nitpick on pull requests (which we do), for personal stuff quick hacks are more fun is how I feel about it. Spaghetti code is sometimes easier to follow, compared to highly abstracted and encapsulated code, which is easier to maintain but you have to understand it first.

Your graphs look really nice I must say.    Thanks for sharing.

[alm]

Ok, my UGSimple arrived moments ago. With shipping it was $36 (certainly one of the cheaper GPIB solutions).

If it works well, that is a nice price. The syntax error worries me, since I want GPIB equipment to be able to log days without intervention. I am actually moving away from using my current NI-GPIB-USB with linux-gpib because of the occasional glitch. Guess you have to build some sort of error recovery mechanism (including resetting the instruments to a known state) with this. Might also that adding some delays can help if the hardware is not well designed. Obviously does not help if it is a signal integrity issue.

The software setup certainly sounds more convenient than messing with linux-gpib. Their claim about Labview setup is the usual nonsense from the small manufacturers. Yes, you can interface with it from Labview, but you can not use it through VISA, and all those instrument (e.g. IVI) drivers that are the main reason for putting up with Labview will not work either. Not that I am recommending any hobbyist with a decent programming knowledge to use Labview.

According to the listing the current version does not support binary transfers. No big deal for DMMs, but would be a limitation for some other instruments like scopes. I also expect that they are just driving the outputs with standard logic gates, not true GPIB drivers. So I expect problems at larger number of instruments and cable length: I believe proper GPIB supports up to 15 instruments and up to 20 meter of cable. This unit might become (more) unreliable with even a couple of instruments.

[Muxr]

Ok, my UGSimple arrived moments ago. With shipping it was $36 (certainly one of the cheaper GPIB solutions).

If it works well, that is a nice price. The syntax error worries me, since I want GPIB equipment to be able to log days without intervention. I am actually moving away from using my current NI-GPIB-USB with linux-gpib because of the occasional glitch. Guess you have to build some sort of error recovery mechanism (including resetting the instruments to a known state) with this. Might also that adding some delays can help if the hardware is not well designed. Obviously does not help if it is a signal integrity issue.

The software setup certainly sounds more convenient than messing with linux-gpib. Their claim about Labview setup is the usual nonsense from the small manufacturers. Yes, you can interface with it from Labview, but you can not use it through VISA, and all those instrument (e.g. IVI) drivers that are the main reason for putting up with Labview will not work either. Not that I am recommending any hobbyist with a decent programming knowledge to use Labview.

According to the listing the current version does not support binary transfers. No big deal for DMMs, but would be a limitation for some other instruments like scopes. I also expect that they are just driving the outputs with standard logic gates, not true GPIB drivers. So I expect problems at larger number of instruments and cable length: I believe proper GPIB supports up to 15 instruments and up to 20 meter of cable. This unit might become (more) unreliable with even a couple of instruments.

You make great points. I have run into a few syntax errors but it seems to only happen when the instrument is fresh (just reset). The driver itself which is written in python as well appears to be pretty experimental, so I might be able to fix some of these problems or at least add some error recovery/retry and perhaps push a PR to the master for the author to merge.

The biggest appeal of this unit as you said is the low price and how lightweight the software stack is.

[alm]

Only happens when the instrument is just reset. That does not sound like signal integrity to me, but more like something like insufficient time between asserting the address signal and sending the data. Hence my idea that a strategically placed delay, despite being a band-aid, makes things more stable. Unfortunately my knowledge of GPIB is not deep enough to go into more detail. I know the Prologix people spent quite a lot of time tweaking their products to work with every instrument.

Does it exhibit the same problem with instruments other than the 3458A (assuming you have those)?

The problem with retrying is that you do not know what state the instrument is in. Did it process part of the commands? Do you need to clear an error? Did it stop sampling? Hence my idea of just resetting an instrument and starting from scratch. Obviously this is something you would do in the application layer, not in the driver.

[Muxr]

Ok I lied when I said it only happened after a fresh reset. It happens intermittently. Now that I have it plugged into my logger/plotter I am able to tell exactly how often it occurs. The issue is much less frequent if I set the polling interval to 2 seconds. Will keep it running and tweak some settings. I have an unrelated work project to finish with a deadline next week, so won't be able to dig into this further until that's done.

For now I am just gracefully handling the errors. The good readings themselves at least aren't being impacted, from what I can tell. And I am able to get at least somewhat useful captures. But I feel like I am going to have to modify the (python) driver itself. Some cursory research also points to a potential bug in the usb.core python library that may have been resolved with a newer version. Will look into this deeper next week.



edit: not a single error in the last 3 hours..

[guenthert]

The driver itself which is written in python as well appears to be pretty experimental

I'd say that's quite an understatement.  I couldn't get it to work for any but the most primitive use cases.  The "programmer" of the Linux code doesn't have much or any documentation (he certainly didn't share any) and apparently lost interest after he dumped the code.  I gave up on it and got me a pre-enjoyed PCI based GPIB adaptor which is supported by the Linux GPIB library. 

The UGSimple hardware isn't all that great either.  It doesn't follow the IEEE488 standard (doesn't use driver chips and won't be able to supply sufficient current); might work with a single modern instrument, but don't expect much more.  There's cheap, as in exploiting the laborers in low wage countries, using cheap components, reducing the margin and utilizing the economy of scale and then there is cheap as in cutting corners ...

[bitseeker]

Speaking of Linux GPIB and (earlier) Raspberry Pi, it appears that there's been discussion of using them along with an 82357 (genuine HPAK and Beiming clone). One of the recent posts, from last year, indicate it may not be too stable with NI's USB adapter.

https://www.eevblog.com/forum/reviews/using-a-raspberry-pi-with-linux-gpib-and-a-beiming-or-agilent-usb-gpib-adapter/

That'd be a neat setup for logging.

[ManateeMafia]

I use a few RPi and NI GPIB-USB-HS adapters. They work quite well together logging data over long periods of time. The biggest issue I have is wearing out the SD card and I eventually have to replace it 2-3 times a year. I used to have an Agilent clone and gave up on it not properly loading firmware.

I recommend spending the extra money on the NI model. Get the HS model and not the B.

[nikonoid]

I have an UGSimple adapter and it seems to work ok with hp 34401a using their windows utility. However on Keithlies it is working sporadically at best.

Anybody had a luck using UGSimple on Keithley 2000 or 2002, perhaps using RPi3?


Sent from my iPhone using Tapatalk

[alm]

Too bad the UGSimple adapter does (currently) not appear to be sufficient even for fairly simple logging.

I had problems with the NI GPIB-USB-B hanging somewhat frequently with linux-gpib on amd64. It would require unplugging the USB cable to reset the adapter to get it to work again. Kind of sucks when it happens during an overnight logging run. Found at least one similar report on the linux-gpib mailing list: the conclusion was that it was probably some particular sequence of events that upset the GPIB-USB-B, but that it was hard to reproduce. NI seem to have given up on supporting USB devices on Linux.

So I am planning to switch to VXI-11 (ethernet) compatible interfaces (got the hardware, have to change my software). It does not need any drivers and hence should be more stable, apart from the one with corrupt EEPROM that I still have to fix . The old devices can only do 10 Mbit/s ethernet and will be slower, especially compared to the USB-HS, but I imagine that few people on this forum ever max out the transfer rate of GPIB. The HP E2050a can be found fairly cheap (I think I paid around $50+shipping). Other options are the Agilent E5810A and Tektronix AD007. Software support is pure python, so should be easy to maintain.

There are also the NI GPIB-ENET(/100), but it does not support VXI-11, so software support will be more complicated. You would either need whatever NI-VISA version still supports that hardware or some unmaintained Python code. Not something I would rely on, but I have not tried it.