Any chance of an Ethernet variant?

[m1geo]

I'd be really keen on an Ethernet variant of this for automated setup. My ATE experience is that Ethernet works better, long term, than USB, and doesn't require any host-side drivers. Perhaps the 32u4 part isn't quite up to it, but a separate IC for Ethernet (or an STM32) may work?

[xyphro]

I'd then make an combined version with ethernet and USB. Main reason is that you'd need for an ethernet version a power supply which would be best exposed as USB-C connector. Routing the usb lines to an MCU does then not cost a lot. The hw will get more expensive a bit, levelshifting will likely be required e.g. an spi or i2c based gpio expander IC and voltage regulators - harder for others to build it.

What I do not like about ethernet is that you expose the user to IP configurations (not all networks have DHCP) and to my knowledge there is no easy way to discover instruments in a network. Here I might be wrong, please correct me :-)

[xyphro]

Accidentally pressed close - reopened it.

[m1geo]

An easy option to making the device discoverableis to send broadcast packets (sending UDP packets to 255.255.255.255) which contain the actual IP address. Anything in the same subnet will see the broadcast packet.

I agree the IP address option isn't ideal, but DHCP would be a great start. A USB tool could set up the network options if needed. I agree there are complications, but TCPIP would be a nice option!

Thanks for a great project.

[dazz100]

Hi If an ethernet adapter is given a host name, then you don't need to know the ip address when allocated by DHCP. Each device on a network would need a unique host name so that requires programming.

Ethernet would make Wifi or Bluetooth viable, but in certain scenarios/labs, Wifi would not be acceptable (eg. EMC testing). You would still need wired Ethernet and USB for configuration.

So ethernet would be a great option, but a lot of work.

The major issue with USB is the need for USB port for each adapter. Not a problem with 1-5 items of test equipment, but many labs have more than that.

Even with just USB, it is still a great project.

[larrye11ison]

Just my 2 cents, but I'd love to be able to control these devices using TCP/IP over ethernet. All the potential drawbacks being discussed above simply aren't a problem for me. I can find new devices on my network easily. It would be nice if there was an easy way to customise the hostname on each device, but even if that wasn't available, I can do it at the network level.

[dazz100]

This is a very niche product so to be successful, it needs to satisfy the requirements of the niche. That includes being user friendly. So if ethernet is added, then is should be fully featured, with Wifi/Bluetooth. If it can be better than commercial equivalents, that could only be a good thing. Writing the code for that is not something I can do.

[xyphro]

Let me think about it. Btw: my very first version of this was wifi based :-) and yes I had concerns about EMI, but nowadays you run anyway with your mobile arround close to measurement equipment. I dropped it bwcause wifi is not a reliable connection method. I prefer cables :-)

Edit: There should be standarized discovery methods. I remembered that NIMAX had an option to discover tcpip instruments. Unfortuntely on vacation. I'll check once home.

[dazz100]

I would be really interested in a Ethernet version. The following is my wish list of features:

RF emissions

For many, wifi/BT would be a great feature, but anyone doing EMC testing, sensitive measurements, or concerned about data security, Wifi/BT would not be usable. For this reason, the adapter should be able to work with/without Wifi/BT and with USB/wired Ethernet.

Power

Given that there is no power available over the GPIB, Power options should be:

• USB - C 5V wall-wart adapter or host device
• PoE - to avoid the need to supply power separately to a wired Ethernet cable.
• Battery 15V to 5V (possibly through the USB-C connector). Easy to include a voltage regulator that can handle 15V to 5V input.

Configuration

Configuration needed to configure ip's and Wifi/BT etc.

• Needs to be via USB or/and
• basic web-server via Ethernet.

Multiple Devices

The current usb version is cheap enough that a limit of one adapter per instrument is OK. I anticipate an Ethernet version will be expensive enough to want one adapter for multiple instruments. GPIB cables are available on Aliexpress.

Driver Compatibility Whatever the design/features the driver should be compatible with everything.

Fit-for-but-not-with (FFBNW) Options

Not everyone will want or need POE, Wifi/BT, or even Ethernet, so there should be options not to fit components for unwanted features. The firmware should be able to figure out what options are/are not fitted and still work OK.

Hand Assembly

The cost of a PCB and 3D printed enclosure are not big cost drivers. Components should be selected to allow hand assembly by a competent person. SMD yes, but not the smallest components.

EMC Compliant

It would be highly desirable if the adapter was compliant with EMC standards. This would be good engineering and also broaden the appeal of the adapter.

This project would be a lot easier if the work is shared. I have programmed in a number of languages, but never C. I could provide some assistance with hardware.

[m1geo]

I agree with all of the comments here.

But my gut feeling is even the crappiest DHCP/Static IP configuration is workable. I have a decent few things that I'd like to use with these, and most of the newer gear uses Ethernet (LXI) etc., so adding the older kit in would be awesome.

Manufacturing wise, I'd target one of the cheap, low volume Chinese assembly places (JLCPCB, PCBWay, ALLPCB). But keep hand assembly open as an option. Just dump all the files into github and let others decide.

Thanks for the consideration! 👌

[xyphro]

I started (with low prio for now) to look into if we can do something with a combination of ESP8684and level shifting GPIO expander to bridge to 5V GPIB levels (and reusing the baseline GPIB code from this project as common ground). Why ESP8684? It has a great level of integration and I'd like to play arround with Risc V.

Power supply over USB with a buck converter (cause LDOS are incredibly slow for reliable Wifi operation)- either plug in into an instruments usb port or use a USB charger (not happy about this: A wireless solution which needs a wire).

Design in Kicad with LCSC part numbers.

I like the idea of a Wifi based solution (as said, I worked on this a while ago). In medium to big sized company environments wifi will be a no go though, but for usage at home it is cool.

This might be a seperate project though, but I will keep this thread open to update on more progress.

[m1geo]

The ESP is a nice idea, but I figure the WiFi will be less reliable than USB so not sure it serves a real purpose beyond being cool. Still a nice idea and I would be interested in a WiFi unit, but wired Ethernet is where it's at. :)

[xyphro]

Do I hear you saying I should go with something like ch32v208? :-) It has integrated 10MBit PHY, usb and matches my wish to work with risc V.

What about: Above mcu in qfn28 housing, support usbtmc and 10MBit ethernet. Ethernet magnetics/connector can be optionally mounted. Single button to reset with long keypresy to a default eth config. Defaultwose it will do dhcp only. I think a display would be useful: a small oled to show address info. After a button was shortly pressed. Display is optional and does not have to be placed.

Embedded usb bootloader for easy updates (in worst case usbhid based).

Costs: 1.5 for mcu 1.5 for level shifting gpio expander (5v vs. 3.3v) 0.5 for an ldo 0.5 for xtal (might not be required, docs are not precise enough) 2 for gpib connector 2 for pcb 2 for unforeseen stuff and passives -- ~10 usd for more functionality. Cheaper and more versatile. Of course with lots of SW effort :-)

Ps: i should drop the display idea I think.

[m1geo]

I think that is an excellent idea, display or otherwise. I would also advocate broadcast packets (sending to 255.255.255.255) which include the GPIB instrument name and the IP address, sent every 5 seconds. It would be trivial to find the devices on the network with a simple client program (just listening for broadcast packets).

[xyphro]

Mcus are ordered, studies on vxi-11 protocol started!

[xyphro]

I think that is an excellent idea, display or otherwise. I would also advocate broadcast packets (sending to 255.255.255.255) which include the GPIB instrument name and the IP address, sent every 5 seconds. It would be trivial to find the devices on the network with a simple client program (just listening for broadcast packets).

Can do that, but would make that an option which can be turned off, for home network it is no issue, but in a company network or lab-sub-network you might get into trouble with an IT guy (especially if they enabled routing of BC packets) :-)

Started on PC side with ONC/RPC stack programming required for VXI-11 while waiting for the MCUs...

This does not mean, that I don't intend to support raw tcpip, but I think a VXI-11 wrapper makes sense to avoid a strange protocol layers that users have to take care of like applied for uart based gpib converters (+++ messages) to allow things like status byte reading.

[m1geo]

BC packets are usually just kept local on our corporate network - they don't propagate upwards.

But, having looked into this a bit more, I would suggest mDNS as the way to do this. It's an industry standard protocol.

[xyphro]

Mdns might be an option. Not all routers support those (I had some troubles also with recent equipment). Fow now I am not that much concerned about discovery. I see that Visa tools (NI MAX / R&S Visa) also have scan methods implemented - will try and see what mechanism is used there.

I decided now finally to use CH32V307. This MCU has an internal 10MBit/s Ethernet PHY. Furthermore it has HIGH SPEED USB, which will give a great latency improvement compared to the current full speed USB (1ms vs. 1/8ms).

It has several 5V tolerant GPIOs too. So no level shifters required.

The MCU also has a 2nd USB port - full speed only. Maybe useful to see if this could be used to daisy chain the boards when USB is used?

It also comes with a USB bootloader, which is great for rebuilds. You can program it without requiring a programming adapter. But I intend to add a second stage bootloader, for FW upgrade via Ethernet and USB.

Should have used that MCU already earlier, instead of the old school expensive AtMega32U4.

This is certainly not the final Hardware, but will get a development board for first experiments until I design a final board. I will shrink it HEAVILY down. For first steps it is however nice to have a big board with easy access everywhere.

On FW side I have a ONC/RPC layer running, which is the basis for the VXI-11 protocol.

[DavidLutton]

On a separate LAN for instruments, I use pyvisa-py to do VXI-11 discovery with VXI-11 list_resources

from pyvisa_py.tcpip import TCPIPInstrVxi11 as TCPVXI11
TCPVXI11.list_resources()

Add that list to discovery & driver mapping as used by Labtoolkit with any IO / VISA. So far used NI, PyVISA-py, pySerial and Linux GPIB

[xyphro]

Will keep that in my mind, thanks for sharing! Still quite a trip to get there :-)

[m1geo]

This is awesome progress! Thanks for the update and yes, it seems like a very suitable CPU/SoC.

[xyphro]

Have ordered it now. In a week i can mount components and get started. Will continue to post here until I open a new repository for it.

[xyphro]

+++update+++ The development board is mounted and tomorrow will be the great day of testing if the xtal begins to oscillate and the debugger connection works :-)

The rj45 connector with integrated transformer is not mounted yet on purpose.

[xyphro]

...all set: Debugger connection works like charm. Now there is "just a little bit of SW to make and test" :-D

[dazz100]

I like it. Good progress.

[m1geo]

This is excellent progress! :dancers: