USA calibration club

[dr.diesel]

Do you have your 3458As on top of each other?

Yup.  Every 100 samples I take the internal 3458A temps, just too much for the graph.  On average the higher reading 3458A #1 is 1.06C lower in temp.

I need to quantify/test this, but I thought I noticed after a couple of the power outages the deviation between the two being much (after a 4 hour warm up) less before the first ACAL.  This wasn't captured by the logging as an ACAL is initiated at first run.

[IconicPCB]

Dr.Diesel,

Try Gnumeric spreadsheet.
Much faster than libre or what have you.
I too was using libre and it was such a tedious task.

[vindoline]

Beautiful data dr.diesel! I don't think we'll get better measurement confidence than this - 2 freshly call'd 3458As. Looks like the SVR-T is within 0.5 ppm of 10.00000 volts!

[cellularmitosis]

Beautiful data dr.diesel! I don't think we'll get better measurement confidence than this - 2 freshly call'd 3458As. Looks like the SVR-T is within 0.5 ppm of 10.00000 volts!

Indeed!  Bravo!

[dr.diesel]

Headed your way @CalMachine.   

[CalMachine]

 

[vindoline]

The "goodie bag" keeps growing in size!

[bitseeker]

Indeed. Seems the cal pack will need an inventory checklist.

[TiN]

I have L&N 4030-10KOhm to throw in  .

[cellularmitosis]

TiN, you have contributed so much to the volt nut community.     I would be honored to add you as an honorary member of the USA Cal Club.

I'll PM you to get your address, and look into international shipping options 

[TiN]

Well, resistor is in USA now, so you guys go in the planned routing, and I'll jump in for the round two.
Hopefully we will have few voltage references too. I heard some modules are cooking  .

[cellularmitosis]

Sounds good 

[TiN]

I'd really love to see Raspberry Pi included in round two with data storage.
Maybe somebody could even donate Agilent/knockoff GPIB dongle, so we can have automated datalogging for common meters.

Seeing calibration clubs without data attached to each measurement + environmentals + used gear details defeats whole purpose for me, to be honest. 
It's bit too much, asking for people who use/own meters like 3458/8508/2002 spending their time on so-so reusability and history access.

I wanted to make a dedicated website for this very purpose, of storing/accessing data with history,... but well, need moar time. 

[cellularmitosis]

Yeah, I agree with you on a lot of those points, and I've been enjoying working on some solutions to these problems, but the going is slow.

I have a first-draft of a temperature / humidity logger which works over USB.  I plan on including this in round two, or maybe even just distributing the boards to forum members so that we all have environment logging ready at hand.  https://github.com/pepaslabs/lab-logger

My current mission in life is to bring a cheap and open GPIB solution to this community.  We have a wonderful gift of all of this cheap used test & measurement gear on ebay, yet most hobbyists are ham-strung by lack of a solid PC connection.  And if you can't log data, it is pretty difficult to be a volt-nut.

(My latest weapon in this crusade has just arrived from OSHPark -- I made a "spy" board which allows me to insert logic analyzers into a GPIB connection).

I'm still working on a plotting solution.  Muxr's python-based script is a great start -- I just need to figure out how to make Pandas process two independent CSV files at once.

My hope is that in a couple of months (by the time round 1 is finished?), this little club will be in a much better spot with regard to solutions to all of these challenges.

(A perhaps more distant pipe-dream is to start a youtube channel and make some videos about metrology and volt-nutting.  Perhaps I could start by making a video guide to the LTZ1000 thread.  That should keep me busy for a while...  )

[Muxr]

I'd really love to see Raspberry Pi included in round two with data storage.
Maybe somebody could even donate Agilent/knockoff GPIB dongle, so we can have automated datalogging for common meters.

Seeing calibration clubs without data attached to each measurement + environmentals + used gear details defeats whole purpose for me, to be honest. 
It's bit too much, asking for people who use/own meters like 3458/8508/2002 spending their time on so-so reusability and history access.

I wanted to make a dedicated website for this very purpose, of storing/accessing data with history,... but well, need moar time. 

That's a great idea.

I have come up with a solution for logging for my own needs and tried to share my findings but not everyone has the same background and time to get it going. Plus for my needs I use REST micro services on my distributed network in the lab, in order to keep instruments in different locations connected.

But I can try working on a traveling rig we can use. I wasn't aware of the 82357B USB/GPIB clones to be honest, so I don't mind donating it and the rPi to the club.

I have some ideas on how to make it fairly easy for anyone to get it working. I could build a simple self hosted web interface on the Pi to simplify the process. I do have a full time job and other side projects, so it won't be any time soon though.

I'm still working on a plotting solution.  Muxr's python-based script is a great start -- I just need to figure out how to make Pandas process two independent CSV files at once.

I purposely wanted to keep the python example simple so that it's easier to extend. But take a look at the version I've been developing: https://gist.github.com/sirmo/4126a9450a769a3cc9d011beb6a7eded

I just need to clean it up a bit and make it smart so that the old single column format still works with it (and then I'll merge it).

It doesn't load multiple CSV files but it feeds off multiple columns in the CSV. Value from the DMM, Temp, Humidity, Pressure (see attachment)

Not sure if that's what you're looking for.

[cellularmitosis]

Muxr, that's fantastic!

I just realized that I made a github mistake -- I made pull requests against my own fork of your repo, so they never made it your way!

These two PR's allow the columns to be arbitrarily named:

https://github.com/cellularmitosis/muxrplot/pull/2

https://github.com/cellularmitosis/muxrplot/pull/3

[Muxr]

Muxr, that's fantastic!

I just realized that I made a github mistake -- I made pull requests against my own fork of your repo, so they never made it your way!

These two PR's allow the columns to be arbitrarily named:

https://github.com/cellularmitosis/muxrplot/pull/2

https://github.com/cellularmitosis/muxrplot/pull/3

Sweet! will merge them tomorrow, thanks!

[CalMachine]

I set up a little area for the reference to sit in the lab and I brought a 3458A over to log!  I do not have any ambient temperature logging device hooked up, currently.... but I did plot the internal oven temp along with the voltage reference, so that will give you a somewhat idea of what ambient was doing.

My graphing skills are still very lacking, so...  without spending too much time making it look all pretty, here are the overnight logging results.  Each 1000 measurements was ~ 140 minutes.  The right-hand axis is ºC

[cellularmitosis]

Wow, just a few microvolts shy from "bang on!" 

[CalMachine]

Quickly threw a BME280 sensor on the RPi3 and logged a few hours this morning.  Definitely somethin funky going on with the BME280.

[Muxr]

Quickly threw a BME280 sensor on the RPi3 and logged a few hours this morning.  Definitely somethin funky going on with the BME280.

I see what you mean. Those dips. Rpi3 likes to use some power when the CPU spins up.. I would maybe try a different power supply for the Rpi3. Maybe the voltage droop is causing the BME280's readings to dip. Shot in the dark.

[bitseeker]

Another way to check if there may be a power issue with the RPi3 is to plug a monitor into the HDMI port. A lightning bolt icon will flash in the corner of the screen anytime the power supply is insufficient for the Pi's needs.

https://raspberrypi.stackexchange.com/questions/57963/what-does-the-lightning-bolt-mean

(I don't know if this is linux distribution-dependent.)

[lukier]

My current mission in life is to bring a cheap and open GPIB solution to this community.  We have a wonderful gift of all of this cheap used test & measurement gear on ebay, yet most hobbyists are ham-strung by lack of a solid PC connection.  And if you can't log data, it is pretty difficult to be a volt-nut.

The clones from eBay are nice, but OSHW solution would be great. I have this somewhere on my long TODO list.

The idea is to replicate the Keysight E5810B. If you look at the firmware it is based on the AM335x CPUs (i.e. Beagle Bone Black). This neat SoC has a real time peripheral-microcontroller called PRU, can bitbang a pin at 100 MHz rate AFAIR. This is for example used in LinuxCNC/MachineKit for accurate step/dir signals for the stepper drivers.

If I understand E5810B correctly (I never saw any teardown) it uses PRU to bitbang the GPIB transceivers (SN75160B and SN75162B) directly - very neat, no CPLD or obsolete NI chips needed. It could potentially enable high speed GPIB (like GPIB-USB-HS, with DMA) and of course, as it is a decent SoC, an Ethernet gateway (VXI11) and attaching extra I2C or SPI sensors is easy. The whole thing is fully open-source (Linux, linux-gpib, GCC compiler, TI provides the PRU tools).

The GPIB cape wouldn't be very expensive, just the 2 layer PCB, GPIB connector, pin headers, transceivers and some misc components. I guess $20 + the cost of BeagleBoneBlack ($45). The difficulty lies in the low level understanding of both GPIB and VXI11 (for the Ethernet bridge) to implement everything.

[bitseeker]

From what I read some time ago, the PRU isn't all that easy to deal with. Hopefully, the tools support for it is good now. I've got a BBB ready to put on a GPIB cape. It'd be pretty cool.

[CalMachine]

Quickly threw a BME280 sensor on the RPi3 and logged a few hours this morning.  Definitely somethin funky going on with the BME280.

I see what you mean. Those dips. Rpi3 likes to use some power when the CPU spins up.. I would maybe try a different power supply for the Rpi3. Maybe the voltage droop is causing the BME280's readings to dip. Shot in the dark.

I'm using a 2.5A wall wort that are generally sold with the RPi3s.  I've got a little monitor hooked up to it and I'm monitoring the script through the command prompt.  There are not any power draw issues coming from the RPi3, that I've observed.  I was getting some pretty funky readings, so I had to put the reference in a Faraday cage.  I'm supplying the provided voltage regulator with 23 V and I'm using the copper twisted pair wires that Dr. Diesel sent along with the package.

Here is a 3 hour run from this afternoon.  Still observing odd spikes on the BME280, but I'm not really that worried about it, though. It's only happening for 1 measurement.