Yaugi 4: GPIB Ethernet PoE Adapter

[psynautic]

How's it been going?

[essele]

How's it been going?

Hmmm … well there have been a few things going on. I decided to look at FreeRTOS to make some of the threading aspects easier, and then actually built a lightweight version of an RTOS which works surprisingly  well. Then I looked at the PSoC 6 as it’s still a reasonable price but has quite a bit more capability (and memory.)

I even managed to get the BGA soldered at home with hot air!

Then I got thoroughly annoyed with Cypress because the PSoC 6 doesn’t behave as it should in some situations and they seem not to care about the programmable logic side of things any more.

Then I had a break because I got CoVID and suffered with some effects for a long time afterwards. Thankfully that’s mostly over!

Now I’ve decided that a Lattice FPGA (ECP5) is a brilliant option that allows a Linux capable solution on a RISC-V core, plus all sorts of other potential capabilities.

I’m just working through a new PoE implementation (waiting for third iteration to be delivered) with the various rails for the FPGA and building the GPIB solution in parallel on a dev board.

It’s obviously a lot more complicated but the Linux capability means that the device will be able to do much more itself and I won’t have to keep writing network stack components and dealing with severe memory limitations. I still think it can be built for a very reasonable cost.

[essele]

Ok, so I've had a bit of a rethink about this and I think I'd lost my way a bit, hopefully now back on track .. I'll walk through my thought process quickly which will hopefully explain my intermediate madness.

- So I was following the FPGA idea, had a few variations of RISC-V core built, and was starting to design a Lattice ECP5 based board. For the cost of the ECP5 you actually didn't get a lot of performance out of the RISC-V core and you had to also include ethernet MAC and various other things which eat into your LUT budget.

- So then I started to look at perhaps pairing a smaller FPGA with a more capable ARM core (SAMD5 type). SAMD5's come in SOP modules including SDRAM which meant not having to lay out DDR (which I was enjoying though!) and also they have an external bus which would give high speed comms to the FPGA ... sort of a poor man's Zynq. I had a board mostly designed, although having never done this before, it probably would have needed a few iterations.

- Then I started thinking ... actually with that power I could have several end-points controlled by the main board, and have three of four GPIB devices connected. So I started thinking about the best form of linkage between the devices and end-points, thought about high speed serial, then ...

- What am I doing? I've kind of gone full circle ... I could actually just connect a load of simple devices over USB (or Ethernet) to a pi (or similar), so I don't need to build all the smarts into the end device, the Pi can handle anything clever ... and there's no way I could build something as capable (and get it to work) for anywhere close to the cost.

So ... my approach is now this:

1. Go back to a simple USB end device, without a lot of clever capabilities - Can just do serial emulation or USBTMC (switch on the side) and with my new method of attaching the connector which allows the entire device to be pretty small but still easy to build. I've got a first cut arriving in a few days, and already have a second more optimised board mostly designed (3d image attached) ... the unpopulated FRAM slot is just me experimenting with EEPROM vs FRAM. The former is much lower cost and can be JLCPCB assembled as a basic part, so will probably be the path I take.

I have added an I2C external connector to this, the intention is to use this for an optional high accuracy temperature sensor ... I'm intending to embed these into the various meters I'm using so I can get an internal temperature alongside the actual measurement.

2. Produce a PoE version of the above ... won't be quite as small, but I've found a much smaller transformer and have reworked my PoE converted a few times now, so should be manageable. (Haven't started this yet, but I have all the building blocks from previous versions.)

3. Use a Raspberry Pi Compute Module 4 as the base of a hub device that can be used as a more capable collector for up to 7 USB devices. I've added an M.2 PCIe slot so you can add fast storage to use this as the central recording and reporting hub, and make use of the various graphing tools etc.

This is PoE based as well, although I still need to see how this performs from a power perspective .. I can run my latest PoE build at 5V 2.1A without anything getting too hot, but over that I think the magnetics don't cope. This will limit available power for the USB ports, but this is meant for USB Yaugi's not anything too heavy. (3d image attached, although this isn't finished yet.)

So the actual GPIB modules then become generic again, I've done most of the work for these, and they could be used with or without the hub, and are back to being very low cost.

The hub is optional ... you could use a normal Pi (with less connectivity), or a Pi with a hub etc. Or anything else for that matter.

I feel like this is the best approach ... and a hell of a lot less complicated than my ARM+FPGA madness. The biggest issue for now is that a few of the parts aren't available ... luckily I think I've got enough spares for the USB and PoE modules so they should be fine. Unfortunately you don't seem to be able to get a CM4 module so I'll do as much testing as I can with a Pi4 (should be able to test the USB hub and PoE, but won't be able to test the PCIe capability) but then I can get back to getting the software in the right place.

Hopefully that all makes sense ... interested in anyone's thoughts?

Quick Question -- I've included two different USB connectors on the module, a USB-C and a Micro-B (and it's not switched, so breaks all sorts of requirements, but the distances are tiny, and it's relatively low speed, so not expecting issues) ... I did this because I want to make more use of USBC, but I still have more of the older cables around, so the flexibility seemed useful. What does everyone else think?

[ve7xen]

Glad to see you've embraced KISS!

Personally my interest remains mostly in the simple PoE modules, and I think this is the most compelling and 'unique' feature of your design.

Are you planning to release design files? GitHub repo or something for your work thus far? I'd really like to see the PoE PD implementation you ended up with, if nothing else, but it sounds like there's plenty else here of interest too . If not, still watching with interest!

[essele]

Hi ve7xen,

Yes I will release all the files and code once it's in a reasonable place.

I'm still largely using the same PoE design (attached) although I have changed the FET's to ones that can cope with a bit more power, most of the tweaks have been in the layout, making best use of heat sinking on the board and reducing loop sizes. I'm very pleased with how it performs, I can draw 2A without things getting too hot, which I don't think is bad considering my low level of expertise. Above about 2.1A it drops the output voltage significantly .. I think this is hitting the current limit (choice of resistors), but could also be limitations of the transformer (which is only rated to 1.4A according to the datasheet!) I will use a larger transformer for the hub .. I also need to look at 802.3at.

I have tried a few other options whilst pursuing lower cost... I built boards with the KTA1136 and the MP8007, both are primary side regulated so you can lose the opto-coupler and reference, and they are also integrated FET ... but I couldn't get either of them to work properly. It could well be a mismatch with the transformer, whereas the FAN 7601 just seems to work with any transformer I try! I should probably look again as I know they can work well as one of them (can't remember which) is used in the Pi PoE hat.

I'm now also starting to look at some other options, but this time more in pursuit of reduced board space ... I'm just designing a board with a LNK346, an OB2269, and an OB2512 (all LCSC/JLC low cost devices) ... they each have pros/cons, so stage one is just seeing if I can get them to work, and if successful then I'll try with the tiny Pulse transformers ... if that all works then it will be a good approach for the PoE module.

If I struggle then I'm also considering using a 2-board option for the PoE modules ... I'd prefer to avoid it, but it might be the best way to get a highly compact end result.

[essele]

Quick update on the PoE ... my test boards came back, and some mixed results...

The LNK346 version ... which is vastly simpler than my current approach, but keeps the opto-coupler ... worked well. Spot on 5V with the Hanrun transformer, but I could only get to 150mA. I tried a SPOE3-0508 Bel transformer and that worked well, 300mA with no issues other than a bit of audible noise. I've ordered a few PH9585.002NLT as they are tiny, if they work as well and don't have the noise then this will be perfect.

The two OBxxxx devices were a complete flop ... no output at all. The first one looks like I used too large a resistor on the VDD side, which meant it wasn't getting up past it's UVLO point. A quick experiment changing things resulted in the magic smoke ... so more to look at on this one. The second one looks fine from a voltage standpoint, so I'm going to need to get my scope out to see what's going on.

Unfortunately my scope is tied up at the moment on directly interfacing a 10/100 PHY to an RP2040 microcontroller ... and it's working really rather well, and the GPIB side works also ... I think this is going to be the basis for the next gen devices ... much more powerful and much lower cost. But I'll post more about that once I've got it a bit tidier.

[essele]

Great progress on the RP2040 based boards ... the first USB version is being made as we speak. Should be back in just over a week ... although it will need at least one revision, I made a stupid mistake on the crystal caps.

For the PoE version -- I've pretty much completed my interface to the PHY and this works nicely in testing, even with long jumper wires to a LAN8720 breakout board, so I'm quite confident this will work well on a custom board, I've attached a 3d view of my current thinking .. not quite finished yet, and with a completely new way of attaching the GPIB connector that should save a lot of space. I am going to use a daughter-board for the PoE adapter, but that should slot nicely alongside the RJ45 connector.

On PoE... well, it turns out that my cheap DC electronic load has been hiccupping rather than my test circuits being wrong. It's rather annoying as I've tried and eliminated quite a few options based on that bloody thing. The symptoms were voltage dropping to 0V every 1.5s or so and then recovering ... I had assumed it was the driver chips giving up, but it really doesn't look like it (reproduced with a signal generator and a mosfet instead of a PWM driver!) So I've ordered a proper DC load, so I'll go round the loop again once that arrives.

Oh ... and the Pulse PH9585's are absolutely gorgeous and tiny ... they work nicely, so it will save loads of space, and they're not bad value either!

[essele]

The first RP2040 boards are back and (once I'd fixed my stupid crystal cap mistake) they work nicely.

USB working, Flash programming working, SWD working, and GPIB working!

I do seem to have an issue with the flash "unique id" being the same on both of the first two boards, which makes me worry about the quality/genuine-ness of the flash chip, but other than that it seem to be working well. (I haven't checked the other three yet.)

The fact that these worked right out of the box gives me confidence to send off the ethernet ones ... they have the different connector attachment mechanism which will shrink the overall size quite significantly. I'm still waiting on a DC load, so can't make much progress with the PoE daughter board yet.

The software is coming on nicely as well, on the USB version I'm probably going to support a number of "compatibility modes", I'll also probably ditch the slide switch and do everything through config. I already have a nice user friendly serial command line, supports editing and history ... perfect for experimenting and configuring the device, and am now working on a prologix like interface as per many of the other devices out there. USBTMC to follow shortly.

[essele]

Some good progress ...

The network boards came back and worked perfectly, some minor tweaks to the timing on the ethernet interface as the lack of a myriad of 8" jumper leads seemed to make a positive difference. I can push the interface as hard as I can and don't get any checksum issues or dropped packets, so this seems like a pretty resilient solution.

The I2C interface works well and I've built support for the GXHTC3 temperature and humidity sensor, but it should be easy to add support for any 3.3v capable I2C sensor. I just picked the GXHTC3 as JLC could assemble them and they were relatively low cost for good accuracy.

My DC Load finally arrived and I've had another go at a load of new PoE designs ... I really don't know what I'm doing wrong, but the only solution I can find that consistently works and provides a good output current with low ripple/noise is the FAN7601B design that I started with ... thank god I found that at the beginning, otherwise I would have given up by now.

I've designed a daughterboard for the next iteration which is the PoE power supply, this should fit above the main part of the board ... the PH9585 is low profile so I don't think it will negatively impact the size, and current seems to be only ~150mA when connected to a 100fd link, so hopefully nothing will get too warm.

I've decided the best approach is actually a single design that has both ethernet and USB, but they could be populated differently if needed: i.e. for a USB only device there's no need for the PHY, RJ45 connector, PoE daughterboard etc. But this means that everything else is consistent and this should simplify the software side by not having to run two different builds.

I've attached a photo of the first network board, this was attached to a 34401 to test that the new GPIB connector attachment was working ok ... all good ... it's a bit of a faff to assemble, but seems nice and strong.

All of that working meant I could send off the next (hopefully nearing final) board and the PoE board ... I've attached a 3d image of the main board, so you can see ethernet and USB, reverted to 10pin 1.27mm header for programming ... this is so that I can use a cable for when it's in a device (the pogo thing comes off too easily) but still use a pogo thing for rapid programming if needed.

[Gribo]

I would avoid an SMT MicroUSB connector - they are flimsy and easily broken. There are connectors that use mix technology, both TH and SMT, and seem slightly more reliable.
Edit: You forgot fiducial marks.

[essele]

Thanks Gribo ... it is actually a mixed technology one as you suggest (SMT with 4 through hole anchors) ... it's just not that clear from the image ... I've also been caught out by the pure SMT ones, I'd never use them in anything where you might actually need to plug a cable into it!

The JSH-SH connector is only SMT, but you shouldn't really be plugging/unplugging that frequently.

[essele]

Edit: You forgot fiducial marks.

Why do I need fiducial marks? This is all handled by JLCPCB ... I assume they actually do it on the panel rather than individual boards, I've had quite a lot assembled by them now and I've never added anything and they've never added anything (other than their part number.)

Is there any benefit in me doing it? (Other than presumably if I wanted someone else to assemble it?)

[pigrew]

This looks like a very nice implementation and I'm looking forward to looking at the design details.

When thinking about a GPIB adapter, I keep being torn between between supporting one device vs a whole bus of devices. With the price of this board, I think it makes having a single device per bus the answer. This seems to be cheaper than a GPIB cable. Having an adapter per bus also allows use of the most common protocols (USBTMC or VXI-11.1 or HiSLIP). For a whole bus, one would need to use VXI-11.2. One downside is that group triggers wouldn't be synchronized between the multiple adapters (but I don't think group triggers are an often used feature... I've only used them once.)

Were you able to use the RP2040's PIO to handle the GPIB interface? RP2040 seems like a great choice. The only downside I see is that it doesn't support high-speed USB (meaning that latencies are >1ms and transfer speeds are <12 Mbps), though both of these are overcome with the ethernet interface. I really wish that the RP2040 supported ULPI for high-speed USB.

Is there any issue with applying the GPIB bus termination voltage (~3V) on the RP2040 I/O pins while the adapter is not powered? Is the bus power sufficient to power the RP2040 through the ESD diodes?

There are about 16 I/O lines. The total RPi sink current seems in spec with a single GPIB device connected. Each connected device sources about 2 mA when the RPi is at logic 0. (16 I/O * 2 mA <= 50 mA limit) Two connected devices would be beyond the MCU's rating. (though I think only 9 lines can be held low simultaneously?)

I'm tempted to wire a RPi Pico board directly to a GPIB port.... For the USB implementation, I don't think there's any components required that not already on the pico board (assuming that bus termination is ignored...).

There are a few peculiarities of USBTMC that need some thought, like how it should identify to the bus (use the adapter's model/serial number or the connected devices) or configuration (maybe use USB control transfers).

For the debug connector, tag-connect pogo pins work well and latch in place, but real connectors are certainly reliable.

(Huh, looks like I made similar comments a few years ago... I reply to threads too quickly....)

[essele]

Were you able to use the RP2040's PIO to handle the GPIB interface? RP2040 seems like a great choice. The only downside I see is that it doesn't support high-speed USB (meaning that latencies are >1ms and transfer speeds are <12 Mbps), though both of these are overcome with the ethernet interface. I really wish that the RP2040 supported ULPI for high-speed USB.

Yes, PIO is brilliant. I'm using it for the PHY interface (where it's the only way this could be done given the speed) and also for GPIB. At the moment I'm only doing single character handshakes in PIO .. so you put a byte in the FIFO (to signal input or output) and it lets you know when it's complete, with a slightly different approach to sending and receiving.

I did have a solution that would send or receive whole strings, i.e. less processing on the cpu side, but I don't think it really speeds things up much in real-world situations, so I've gone for simplicity for the moment.

I'm not sure the USB speed is particularly an issue for the vast majority of use cases .. it's pretty close to GPIB limits (not the fast mode, of course) ... and I think most people don't do mass high speed transfers ... and for those that do, as you say ethernet is an option.

I would be interested to know if there's a low cost device I could get that would be a good device to test speed/throughput. At the moment I only have a bunch of multimeters, and a DSA (which I'm going to use to hopefully support screen dumps/printing.)

Is there any issue with applying the GPIB bus termination voltage (~3V) on the RP2040 I/O pins while the adapter is not powered? Is the bus power sufficient to power the RP2040 through the ESD diodes?

I'm not seeing the device powered once power is removed from the board so I don't think this is an issue ... I did see it on the PSoC and had to implement voltage monitoring. Also not seeing any issues driving the GPIB ... although I have only tested with a couple of devices so far, but I think from a spec standpoint everything is ok.

And yes, I think you're right about the 9 lines ... 8 data lines and DAV when you are a talker.

I'm tempted to wire a RPi Pico board directly to a GPIB port.... For the USB implementation, I don't think there's any components required that not already on the pico board (assuming that bus termination is ignored...).

That's exactly what I did to start with ... I rigged up one of my previous GPIB connector adapter boards and crimped up a load of Dupont connectors onto the end of a ribbon cable. It all works perfectly.

There are a few peculiarities of USBTMC that need some thought, like how it should identify to the bus (use the adapter's model/serial number or the connected devices) or configuration (maybe use USB control transfers).

Yes, I went through all of this when I implemented it before ... it looks like it will be a bit easier this time as the TMC framework is part of tinyusb, so I can hopefully concentrate on the real details rather than having to get into the usb weeds as well.

(Huh, looks like I made similar comments a few years ago... I reply to threads too quickly....)

Yes, deja-vu for me as well ... but going round the loop again with different (but more capable, and lower cost!) hardware this time!

[alm]

I would be interested to know if there's a low cost device I could get that would be a good device to test speed/throughput. At the moment I only have a bunch of multimeters, and a DSA (which I'm going to use to hopefully support screen dumps/printing.)

If you have a commercial GPIB controller (e. g. NI, Agilent etc) that can act as device, you could use it to measure speed. This is pretty common, because for some equipment it's common that for example the spectrum analyzer is the controller, and your computer is emulating a plotter. Maybe you could even connect two of your own devices back to back?

[essele]

What a good idea … why didn’t I think about the back to back approach 

I haven’t written any code for client support yet, so that will need a bit of work but shouldn’t be too difficult, and I should be able to rig up a back-to-back connector.

Great idea - thanks!

[alm]

A standard GPIB cable with stackable connectors can serve as an easy way to connect two connectors of the same gender.

[pigrew]

I'm not sure the USB speed is particularly an issue for the vast majority of use cases .. it's pretty close to GPIB limits (not the fast mode, of course) ... and I think most people don't do mass high speed transfers ... and for those that do, as you say ethernet is an option.

I would be interested to know if there's a low cost device I could get that would be a good device to test speed/throughput. At the moment I only have a bunch of multimeters, and a DSA (which I'm going to use to hopefully support screen dumps/printing.)

Agreed. In my experience, I'm generally more concerned with latency than transfer rate. I good test for latency might issuing "*OPC" and waiting for the SRQ, or "*OPC?" and reading the result back. I often synchronize a few different devices together, so have to wait for operations to complete quite a lot. As others have mentioned, having one YAUGI talk to another YAUGI (if it supports slave mode) sounds like a good solution.

In terms of raw transfer, I don't have any devices in mind. Downloading a screenshot, or a datalog (like from the 34410A) seems reasonable. NI did introduce their HS488 protocol, but I'm not sure if any devices use it (and it isn't in the IEEE spec, anyway).

Yes, I went through all of this when I implemented it before ... it looks like it will be a bit easier this time as the TMC framework is part of tinyusb, so I can hopefully concentrate on the real details rather than having to get into the usb weeds as well.

I wrote the USBTMC code for TinyUSB, but only used it for two projects a while ago. Its interface I made is pretty rudimentary, and TinyUSB was still working out concurrency issues at the time... let me know if you have API suggestions or need any help with it.

(ADDENDUM: I started looking at the IEEE 488.1-2003 standard, and am finding it virtually unreadable due to all the acronyms it uses.... When in C function, default to CIDS until you get a TCT message or the SAIS is active, and then transition to CADS.)

[dietert1]

When i implemented a USB-GPIB adapter 10 years ago i used a manual bus analyzer HP 59401A.
Later i found i had enough bandwidth to implement a trace option that logs all byte transfers and control signal transitions on the bus and sends them to the host. I am using that till today.
NI Measurement Studio implements the same for some of their interfaces.

Regards, Dieter

[essele]

Later i found i had enough bandwidth to implement a trace option that logs all byte transfers and control signal transitions on the bus and sends them to the host.

Another fantastic idea … I have a couple of spare PIO state machines, so I think I should be able to setup one to monitor all 16 lines and just signal changes, I also have a spare CPU core which could process that data and send a stream of timestamps and values over usb or Ethernet, and then a small program on the host side could easily turn that into VCD files for use with gtkwave or similar.

That could then be used as part of the active device for debugging, but also could be used entirely passively in a different system to trace all GPIB activity.

Thinking about the PIO instructions needed to track deltas I think it could monitor at 50MHz, but then it would take another three cycles to push the changes, so could handle changing signals at 25MHz (subject to being able to process it quickly enough if there’s a long stream.)

I will experiment later today … will be really useful for debugging.

Lee.

[MegaVolt]

Does the network connector block access to the left GPIB screw?

[essele]

Does the network connector block access to the left GPIB screw?

Yes it does ... and the programming header and I2C connector is in the way on the other side. I had intended not including screws, I couldn't find any sensible (cost wise) source for the long ones that run through the enclosure and the device is small enough that it doesn't pull itself out under it's own weight.

On my previous versions I had actually used the screws as a method of mechanically fixing the case (see photo) and I've had no issues with all of the kit I have here. I did worry they would stop the connector going in properly, but everything I have has a good clearance.

Do you think not having screw access would be a problem? If so then I'd have to make it narrower and longer, I'm guessing that will add about 15 - 20mm to the length?

[essele]

Quick update...

The main boards and the PoE boards all came back and are working nicely.

The PoE board worked fine, but there was some audible noise from the transformer ... a few (many many) hours of experimenting with component swapping and I've got to a great place with no audible noise, low ripple, and easily supplying 300mA (I only need about 150mA.).  There were a couple of main issues ... the current sense resistors were too small as the FAN7601B uses a comparative approach to detecting low power usage and then switches into an audible range. Increasing the current sense resistors (given the low power needs) solved this problem and also reduced the ripple significantly.

Also, the VDD capacitor was too small and, whilst everything worked, it wouldn't startup properly if a full load was attached, I don't think this would have been an issue in practice, but was a simple fix.

(So the dodgy soldering it the result of me switching stuff and soldering in pots, not JLC's assembly ;-))

Temperature looks good, the only thing that seems to get warm is the transformer, and this didn't go above 65 degrees at 300mA, so I think plenty of headroom.

No issues yet with the main board other than poor placement of the debug connector, it gets in the way of the PoE connections and is easily moved slightly on the next revision.

The assembly is a bit of a pain ... having to solder boards at right angles, and trim pins etc. (There is a 1.27mm 20pin right angled header under the board.) So any ideas about different (but space efficient) ways of doing this would be appreciated.

I have yet to try the PoE board actually connected ... a job for later today, but I'm not expecting any issues.

On the software side...

I've implemented the bare bones of an RTOS again, but this is only used by the low performance bits ... telnet, usb_cdc, i2c etc, and will be used by the web server. It makes it easier to do sequential programming and not having to have loads of state machines. Anything performance sensitive will remain in the polling system, so I hope this will give a good balance.

I've added TMP117 sensor support which works very nicely and doesn't show any of the self heating I was seeing with the GXHTC3 (sampling rate and sleep config made a >1 degree difference which really doesn't match a 0.2 degree quoted accuracy! ... and they don't seem to want to reply to me!)

Focus now is software ... and I'm hoping the next hardware run will be the last.

[SirAlucard]

Question, what's stopping you from using a Raspberry pi to control everything? I've made a simple GPIB connector with an arduino, and I imagine you could use the GPIO of the RPi to do the same connecting up to a GPIB connector, then just program in linux or whatever to talk to the GPIB and send off the data to a graphing program/app/server.

Like I said I've got an arduino based GPIB that I've been looking at just connecting directly to a RPi through USB and then logging to a Graphing server, and it made me wonder if it was possible just to connect the Pi directly to the GPIB skipping the need of an arduino based adapter.

[essele]

Question, what's stopping you from using a Raspberry pi to control everything?

Hi .. I'm fairly sure that would work, but it's not particularly elegant. I've got about 8 devices that are GPIB capable that I'd like to connect up, and having 8 Raspberry Pi's with suitable power supplies isn't really going to work (and the Pi PoE option is expensive and noisy.) I am intending to experiment with a Pi CM4 based hub that can be used to control a number of these devices and do the more complex stuff, but for individual device connectivity I want something much smaller.

Also ... even at very low volumes, this is well under the cost of the Pi ... and it's fun!

And ... there's actually more than enough capability in these devices to do the "send direct to a graphing server" bit itself ... I'm just trying not to get carried away at this point (which I did before) and keep it simple to start with.

Lee.