What should a new variant support?

[xyphro]

Hi!

As you might have noticed, I am busy with a new HW and SW variant. So far I made a development PCB with it (quite huge, but will be scaled down) and already got the basics of USBTMC running. Some pictures are here: #31 (comment)

That new adapter should address:

• Support Ethernet on top of USB
• Support High speed USB (480Mbps). Not because it is really needed, but for latency reduction.
• Get on par in transfer speeds with commercial Adapters -> 1.8MBit/s for read/write transfers. Current gen has 240..320KByte/s.

However, I have so many ideas and would like to get your feedback of what you would like to see in terms of functionality on SW, but also on the HW design itself.

For now I plan to make a HW which is similar to the REV2 of the adapter. One side will get an Ethernet Jack, the other side a USB jack.

Below a list of items... Would value feedback or an extension with your ideas, such that I can consider them early. We have a green field to start sth. new :-)

Best regards,

Kai

Ethernet:

• 10 MBit/s - 100MBit/s might come at a later stage when adding an external Ethernet PHY
• VXI11 protocol. Any other preference here?
• Device discovery matching the ones of commercial devices (to be investigated on how they do it)
• DHCP support default wise. Via USB port it can be configured to get a static IP address setting among other LAN specific settings also.
• Power supply for Ethernet is coming from the USB port. The USB port could be connected to a wall wart or an instruments USB port. I do not intend so far to support POE. POE requires also POE infrastructure to be present like a POE Switch and adds to size and costs of the final solution. In worst case I can consider a retrofit solution like on Raspberry pi. But how do you see this?
• simple HTTP server for easy GPIB control, e.g. read/writes - read status bytes, ...

USB

• The MCU used has 2 USB ports and allows SW wise to emulate a USB HUB. This means one port connects to PC and the other Port can be used to connect another USB device. This other device can then also be another GPIB Adapter again, so you can daisy chain them. However, there are limits due to IR related voltage drop. For now I think it might be possible to link up to 3 devices on a single chain.
  The host port on the adapter would run in full speed (12MBps) mode only. Is the effort worth to do this?
• It might be feasible to allow multiple GPIB devices to connect and expose as seperate devices on the PC side. This means one GPIB adpater and for each GPIB device connected another USBTMC device would appear on the PC.

Priority on USB vs. Ethernet

• Ethernet has priority: When Ethernet is connected, the USB side will disappear thus not enumerate on PC. USB is used as power source only. Why not support both at the same time? When using an USB port of your instrument it would be strange if it enumerates there as USBTMC device controlling itself. Or do you see value in supporting both at the same time? This can result in quite difficult to solve race conditions impacting stability... So for now I would not intend to support this mode

GPIB side

• For now I plan to support normal GPIB mode only - but with 1.8MByte/s spec. GPIB has also HS modes ~8MBytes/s... Never saw them beeing used. Any opinions on this?
• Device mode: Build in a plotter emulator for easy screenshots using older instruments. This will require an application to be run on PC which receives the data. Such an application can directly visualize the (mostly HPGL) data and copy it to clipboard.
• Device mode: Do you see other usecases for device mode? Some other adapters support emulation of a GPIB device, but what else is this typically used for?

overkill?!

• In very long term it MIGHT be possible to allow your instrument to emulate a remote frontpanel control like modern instruments do. This would mean that an easy method to create such instrument specific interfaces would be required first.
  E.g. when you have a digital multimeter a web interface could show the current value and have a button like interface to switch modes, ... During covid times such interfaces were great to remotely control your lab setup remotely and only modern instruments had it. But: This requires support from instrument owners for creation of the "web control plugins". Not sure if this would fire at the end, but it would be super cool.
  In easiest case it would already also be a great help to just get a "download screenshot" button.

Any feedback is highly appreciated :-)

[mankangustafsson]

First, thanks for this project. I've been following this for a long time, impressive work with the latest speedups. Currently waiting on parts for building some adapters of the rev2 HW. I've built seven rev1 HW.

Ethernet:
No comments

USB
I do not see a value in daisy-chaining. I rather see one adapter being able to drive multiple instruments but that might be out of scope for this project.

USB/Ethernet priority
I agree, only one interface at the time.

GPIB
Never seen HS mode used either.
Device mode: Support for the 7470 KE5FX plotter would be awesome.
Also being able to be used as a HPIB disk could be useful, see http://dalton.ax/hpdisk/ and https://www.hp9845.net/9845/projects/hpdrive/

Overkill
Just keep the SW open so others can do their own mods.

Connector placement:
Not convinced that side mount for both USB and Ethernet is the best compared to back mount. Side mount can cause cables blocking other connectors on the instruments. However back mount makes the cable protrude longer but not maybe more than two GPIB connectors that would be the alternative.

[xyphro]

The disk emulation is really a good one, will look into it. Maybe I should support mounting an spi flash (those are cheap) and use that for disk emulation.

Towards PC it could be made visible like a flash drive (usb mass storage) with on the fly filesystem emulation - likely the disk drives don't use fat? Or are they not block based at all? I will investigate!!

Same could be used to store plotter outputs and not require a dedicated pc application. Just download from the "flash drive".

About multi gpib device support: I think I will implement it. I heard so far nobody complaining as GPIB cables are expensive, but some ppl already had a bunch of those "garden hose" cables.

[xyphro]

Valid comment on the side mount. I can leave the ussb connector where it is located now on REV2, which results in good compatibility as notmal gpib cables are routed in the same location.
For ethernet I can consider to use a 180degree type connector, so routing "from the instrument away".

[dazz100]

Hi
My input:
Ethernet
For many users, needing POusb (Power Over usb) will negate much of the benefit of POE. One option is to design a pcb that allows for both options. Just fit the components needed for the chosen option. PCB space is so cheap that having not fitted components is the cheapest option. I do not consider having the smallest possible form factor is not a high priority. If the pcb is 10mm larger than it could be, there is no significant cost or operational downside.

usb daisy chaining
I don't see any significant benefit in daisy chaining usb. That is better done with ethernet.

Overkill
No such thing :), but keeping the software open and modular for others to tinker with is a good feature. Especially dealing with outlier use-cases and equipment.

Small point. Rename TestandMeasurement to avoid confusion with original unmodded code.

Connector Placement
Include both sideways and rearward options. This again is where the pcb can be designed for a connector to be placed sideways OR rearward, but not both. The foot prints could overlap to prevent two connectors. Cuttable/solderable links can be included in the tracks for impedance matching. By default, all real gpib connectors that I have seen are side entry. All equipment I have seen does not block side entry.

Flash Drive
I can't think of a use case that doesn't have a workaround, or better option. What would this feature be used for??

[xyphro]

Thanks Dazz100,

Flash drive option is under consideration for use as plotter emulator and disk drive emulation. This is stuff which is not needed often, but still quite handy if you need it.

But first I finalize USB side and gpib. Have a usb stack programmed [*] and it is slowly but surely getting stable, gpib side is operational but not fully tested. Transfer speeds are extremly promissing and motivating me.

Once USB 2 gpib is stable I shift to ethernet part. Parts of vxi11 is running (compiled to run on pc right now).

The rest of the features will come later.

[*] available usb stacks don't give me the options to tweak everything I need for multi GPIB support.

[dazz100]

OK
My EMC receiver has a serial port for connection to a basic pen plotter, but not for a gpib pen plotter.
I had a rummage around the Internet and found this:
https://github.com/rhalkyard/plotadapter
and this:
http://www.qsl.net/ke5fx/misc/7470.zip

that might help as a starting point.

[dazz100]

Just thinking aloud here.
Would there be any benefit in a hardware version that does a smart serial to usb connection. By that I mean doing something like: serial > gpib > usb or ethernet > gpib > serial.

For example, I have a Philips PM3070 oscilloscope which has a serial port, but not gpib. It does not have a adc to digitize analog signals. The control instruction set looks like gpib instructions. If the adapter converted serial to gpib, then visa could be used to control the PM3070 as if it was gpib. Same for serial pen recorders.

All that I might propose is a hardware version that allowed individuals to modify the adapter software themselves to do the conversion in the adapter. I am not proposing that you write the software because the number of people, like me, who have equipment controlled with a serial port would likely be small.

My thoughts are that the usb-gpib adapter should remain agnostic to the connected PC or test equipment.

[xyphro]

I had that uart support also shortly in mind but dumped that idea again. Many configuration options would need to be exposed. I can foresee in hw design to make uart with hw handshake and supply on pins available for potential extensions.

[xyphro]

Hi again!

I wanted to share some updates on the project:

• Developed new hardware.
• Ported and tested GPIB functions to a new MCU, achieving excellent speeds.
• Built an embedded VXI-11 stack entirely from scratch.

That said, I’ve decided to pause work on a new variant of this adapter for now.

Investing significant time into development, testing, bug-fixing, supporting users, explaining how to control the device with VISA, and more has been rewarding but also demanding. And a new "state of the art" version will double this effort.
Balancing this alongside other interests, projects, hobbies, and family life - especially for something that doesn’t any cover daily expenses and is a "free service" - has become increasingly challenging.

While I hope to revisit this new project when I have more bandwidth, for now, I’ve decided it’s best to put it on hold.

Maintenance for the current USBGpib REV 1 and REV 2 will, of course, continue as is.
I’ve also developed a new GUI tool to simplify updating non-volatile settings—check it out!

Best regards,
Kai