GPIB cloud logging "stick" project

[niner_007]

I find it really painful to keep a computer around for 3458s long term logging, right now I don't have a PC dedicated to it, so I use my laptop, so you can imagine it's very annoying. It is my fault and while I can dedicate a NUC or build a tiny SFF PC with a PCI-E GPIB adapter to do all this work, why not take it one step forward?

I was thinking it would be cool to build onto one of the open source GPIB projects, redesign the PCB layout from scratch and add a ESP32 to connect it to the local wireless network, all in a super compact form factor, as a "stick" as much as possible. The next step, which is key for this project, is to have the "stick" self-contained, you can connect to it and tell it to do things, but general idea is to have it ran a script or set of scripts in a trivial easy to do way, that does not involve logging into a computer and updating or running scripts. The next key thing is to log the data directly in the cloud, on Azure or AWS, and provide easy to access log pages from anywhere in the world, and from any device. Also best would be one stick - one device, to avoid annoying cables as much as possible.

[essele]

Hi niner_007.

I am just about to post details of a project I’ve been working on which is “yet another usb GPIB interface” (yaugi), which is a PSoC based adapter. This works well as it has an integrated USB controller so can provide either a uart based interface or potentially also a TMC usb interface. It also has the option of using the configurable hardware to accelerate the handshake and speed up transfers. And it can do open drain gpios!

I’ve built a small pcb (jlcpcb), and it uses less than £10 in components - I’m just working through implementing the Prologix command set, but functionally it all works well as a uart based device. I still need to look at the hardware acceleration and the USBTMC side of things.

My next effort was going to be trying to build it into the shield of one of those metal shielded connectors, but I had also thought about adding a serial memory and creating a stand-alone logger. I did also think about the WiFi/cloud side of things, but haven’t got to that yet.

I’m travelling with work at the moment, so I can’t post all the details until the weekend, but it might serve as a good low cost basis for what you are looking for.

[Macbeth]

Isn't the real problem with this IEEE-488 WiFi Dongle the simple fact that it can't be powered from the instrument itself, like a USB device can?

It's all well and good not having a network of data cables, but if you then have to have a network of PSU wallwarts or phone charger power cables then its pretty shit really.

I have a couple of Keithley 2000's and recently obtained a HP 34401A. I have been happy using a Raspberry Pi with python and using typical CH340 or PL2303 USB-RS232 devices with the Keithleys but have found the 34401A has a very tiny buffer and without the full protocol including RTS/CTS pins it's not so good over RS232 without a low baud rate and lots of artificial delays in my code.

But now we have https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/

Others are happy to have dedicated AR488 USB cables per device, but I can't see any reason not to just use cheap ribbon cable and a few Centronics 24 IDC plugs with a single USB AR488. This leaves my Raspberry Pi with 3 free USB's for my other USBTMC instruments and no need for another USB hub. The Pi 3 has wifi which I use to connect and transfer files, but I leave it logging to its local SD card as wifi is quite congested in my neighbourhood and often drops out. I wouldn't rely on it for logging directly.

[niner_007]

I don't have a good answer for the power source, a power daisy chain might be the best solution :/

[Andreas]

Hello,

have you checked wether the WIFI frequencies influence the readings of your DMMs?
(changes in value or standard deviation?)

I for my part ban all WIFI, mobiles and LED lamps out of my lab.
At least I see some influence of the lap top WIFI on my noise measurements of voltage references on the scope.
Even when the x1000 or x10000 amplfier and the DUT are within a metal can cookies box.

With best regards

Andreas

[Macbeth]

I don't have a good answer for the power source, a power daisy chain might be the best solution :/

Best solution could possibly be using a parasitic method of tapping every signal pin with a diode going to a supercap or even rechargeable cell and using a low power low volt micro with BLE for serial data.   

[niner_007]

Hello,

have you checked wether the WIFI frequencies influence the readings of your DMMs?
(changes in value or standard deviation?)

I for my part ban all WIFI, mobiles and LED lamps out of my lab.
At least I see some influence of the lap top WIFI on my noise measurements of voltage references on the scope.
Even when the x1000 or x10000 amplfier and the DUT are within a metal can cookies box.

With best regards

Andreas

good point, is the 3458A known to be affected by Wi-Fi signals?

[Andreas]

Hello,

I have no clue.
But my measurement setup between a LTZ1000 and K2000 gets influenced when a signal generator is operated "nearby".
So I would try to find it out.

https://www.eevblog.com/forum/metrology/emi-measurements-of-a-volt-nut/msg2729888/#msg2729888

with best regards

Andreas

[niner_007]

I refined my requirements, my goals are now:

• USB support/communication, exposed as Virtual COM
• Ethernet support/communication
• Wi-Fi and Bluetooth/communication, which can be turned off if needed
• Completely standalone operation support, without any PC or active external communication
• Web management interface for configuration
• C, C++ and C# APIs for control and configuration, but this of course won't be needed unless programmatic access is needed
• MicroSD slot and logging, which can be accessed either in standalone operation or when controlling externally
• Power in and out for daisy chaining from just one power supply

Any or all of the communication interfaces ca be used at any time, and including at the same time. I checked the code involved to support GPIB, and I won't be cloning any of the existing code except for inspiration and help, which will of course be attributed. I won't be using any existing PCB layout of any of the existing open source GPIB projects.

[niner_007]

here's a little bit of progress on this, USB/Ethernet and power jacks all fit, the design for the enclosure will follow those of VGA/DVI port, where the screw doesn't go all the way to the back, to leave space for the ports and not waste unnecessary space; the sdcard slot will be on the side, while the wireless adapter will be on a daughter board; there should be plenty of space for all of these things