Yaugi 4: GPIB Ethernet PoE Adapter

[jeremy]

One neat thing I have discovered recently is these PoE adapters: https://www.aliexpress.com/item/1005001356576287.html?spm=a2g0o.productlist.0.0.661565c8IYvQj2&algo_pvid=ee1192e4-44f0-4ff6-8db2-90ec1fab1217&algo_exp_id=ee1192e4-44f0-4ff6-8db2-90ec1fab1217-0&pdp_ext_f=%7B%22sku_id%22%3A%2212000015796991602%22%7D&pdp_npi=1%40dis%7CAUD%7C%7C5.4%7C%7C%7C1.73%7C%7C%400bb0624716516672126222457eeb82%7C12000015796991602%7Csea - they seem to be available all over the place.

It basically gives you PoE without much mucking around. I actually use them to power raspberry pis, they are much more convenient than the shield IMO, and they can be reused once the pi is no longer needed. Maybe could save you some hassle with the PoE board, although if you are doing it for fun then I don't mean to stop you 

[dietert1]

Yes, i remember ordering one from ebay after a discussion in another thread. I cut the USB type connector and used something better to connect to the power pins on the RPi extension connector and it worked well. As far as i remember a RPi works better with a supply that sustains 3 or 4 A. I wanted to check supply isolation/noise, that needs to be done yet.

Regards, Dieter

[Kean]

When working with PoE powered devices, it is worth remembering that some PoE switches or injectors can have unexpected earth referenced power rails.

In some units the negative rail on the PoE splitter could be sitting at something like -48V referenced to earth.  With the Edimax PoE+ splitter I'm using right now, it is actually sitting at +42V.

Thus you need to be careful if you start connecting those PoE powered items to other devices that are earthed, like a PC or a scope.

[essele]

Quick update:

Lots of work on the ethernet interface driven by finding issues as I worked more with LWIP, it now seems very robust, copes with fragmented and rapid sequential packets (it was missing some packets before.)

I have implemented an RPC system, a portmapper and most of the VXI11 interface, and it's working well. I've also implemented the raw TCP interface and the friendly command line telnet interface. lxi tools work, as do the NI tools on Windows.

Code: [Select]

Searching for LXI devices - please wait...

Broadcasting on interface lo
Broadcasting on interface ens18
  Found "KEITHLEY INSTRUMENTS,MODEL DMM7510,04451981,1.7.5b" on address 10.55.0.142
  Found "HEWLETT-PACKARD,34401A,0,9-5-2" on address 10.55.0.156

Found 2 devices


The DMM7510 is a real network capable device, it's useful to make sure my responses match ... the 34401A is obviously not network capable natively, so this is using the Yaugi.

From a benchmark perspective I can get about 70 requests per second (using lxi benchmark) if it actually involves going through GPIB (it does repeated *IDN? queries), however if I short circuit the GPIB to test the network code and responsiveness I get about 1500 requests per second on RAW and about 600 using VXI, this compares with 2100 and 1100 on the DMM7510 which has a gigabit rather than 100meg interface so I'm actually very pleased with these numbers, and I've tested with 100's of thousands of calls and it stays up and responsive.

Lots still to do ... I haven't implemented the VXI abort or interrupt channels yet, and I'm not sure how to test them, but I think I'll look at them next. Then I'll get onto USBTMC which actually has a lot of similar logic to VXI11 so I'm hoping all the internal interfaces will already be pretty much right, and with pigrew's tinyusb implementation already in place this should be reasonably simple.

The NI tools make use of the lxi identification XML document which needs to be served by a web server, so I need to get that done as well.

On the hardware side, I think I'm going to change to 3.3V on the PoE board to reduce power consumption mainly to reduce the transformer temperature ... it's not crazily hot, but I want to 3D print a case, so the lower temperature the better. Otherwise I think the hardware is working well ... I do have a free GPIO so I'm wondering if an LED would be useful.

[essele]

Quick update...

USBTMC now working nicely (basic functionality) ... it did require a small change to the tinyusb framework (@pigrew - I have sent you a pm with details of this, I'll try to submit to the developers if I don't here anything back from you) ... this is to support a non immediate response for a read_stb call. Having pigrew's framework in place made this 100 times easier than my previous attempts!

The web server is also working, but I haven't implemented the identification page yet.

I did also manage to repair a long waiting LeCroy scope with a broken PSU and I've been testing the GPIB interface to that .. the good news is that the Yaugi worked right out of the box. Screen dumping highlighted a small issue with multiple reads, which is now fixed ... so the screendump works perfectly with the lxi tools!

I continue to fight with the PoE side of things -- the 3.3v version is problematic because of audible noise, which I think is a mixture of it's low-power mode and the aux winding not generating enough power when at low duty. But I think I finally have an approach that I'm happy with .. I now have a prototype using mostly the same schematic but switching the FAN7601 out for a microcontroller (EFM8BB51 or 52) it can drive PWM into the mosfet and then use an onboard comparator and onboard logic to control the signal based on the feedback. This can all be done with no CPU intervention and actually results in a surprisingly good result -- better than the FAN for efficiency, ripple, and overshoot!

You can then also do soft start, and even spread-spectrum if you want to engage the CPU ... I've got both of these working, the spread spectrum can almost eliminate the switching peaks (on a near-field probe) at the expense of some ripple. It's quite impressive!

It does mean I need to include a linear regulator to power the MCU, but I've found an 80V capable at JLC for low cost and it only has to deliver a couple of mA, but I can also dump a few components for the aux supply so it should be generally neutral from a cost and board space perspective.

[maat]

Quick update...

USBTMC now working nicely (basic functionality) ... it did require a small change to the tinyusb framework (@pigrew - I have sent you a pm with details of this, I'll try to submit to the developers if I don't here anything back from you) ... this is to support a non immediate response for a read_stb call. Having pigrew's framework in place made this 100 times easier than my previous attempts!

The web server is also working, but I haven't implemented the identification page yet.

I did also manage to repair a long waiting LeCroy scope with a broken PSU and I've been testing the GPIB interface to that .. the good news is that the Yaugi worked right out of the box. Screen dumping highlighted a small issue with multiple reads, which is now fixed ... so the screendump works perfectly with the lxi tools!

I continue to fight with the PoE side of things -- the 3.3v version is problematic because of audible noise, which I think is a mixture of it's low-power mode and the aux winding not generating enough power when at low duty. But I think I finally have an approach that I'm happy with .. I now have a prototype using mostly the same schematic but switching the FAN7601 out for a microcontroller (EFM8BB51 or 52) it can drive PWM into the mosfet and then use an onboard comparator and onboard logic to control the signal based on the feedback. This can all be done with no CPU intervention and actually results in a surprisingly good result -- better than the FAN for efficiency, ripple, and overshoot!

You can then also do soft start, and even spread-spectrum if you want to engage the CPU ... I've got both of these working, the spread spectrum can almost eliminate the switching peaks (on a near-field probe) at the expense of some ripple. It's quite impressive!

It does mean I need to include a linear regulator to power the MCU, but I've found an 80V capable at JLC for low cost and it only has to deliver a couple of mA, but I can also dump a few components for the aux supply so it should be generally neutral from a cost and board space perspective.

Holy Moly. You are really going to town with this thing. Keep up the good work, I can't wait to see the result.

[essele]

I think I've sorted the PoE side now ... and I'm very pleased with myself.

The new board can deliver well over 300mA at 3.3V with absolutely zero audible noise at any load, slow start, and excellent characteristics (ripple, overshoot, and thermals.)

This is based on an EFM8BB51 MCU which drives the mosfet through PWM, but also with some logic making use of the CLU's on the device to cut off the PWM when the voltage goes over the feedback threshold. I've also used the logic to "latch" the condition in each PWM cycle so you don't get it coming back on again if the voltage drops below the threshold.

The board pictured uses a high voltage 3.3v linear regulator to supply power to the MCU, I've managed to tune it down to about 1.5mA so this works well, however this is an "extended" part for JLCPCB assembly, so I'm going to switch it out for a simple zener/transistor regulator down to 5V and then a standard 3.3V regulator. It's a few more parts, but the total part cost is almost exactly the same and it saves the $3 premium for extended parts (there are already quite a few of them and it contributes signficantly to the cost, especially at low numbers.)
 
I'm just waiting for the MCU's to be added to my "global parts library" so that the whole thing can be assembled, then I'll run off one more spin to confirm the new regulator approach.

Finally I'm happy with the PoE board!

[maat]

I think I've sorted the PoE side now ... and I'm very pleased with myself.

The new board can deliver well over 300mA at 3.3V with absolutely zero audible noise at any load, slow start, and excellent characteristics (ripple, overshoot, and thermals.)

 

[nexus]

This project looks great! Will you be offering this adapter for sale or making it open source?

As far as the software ecosystem is concerned, how does it communicate with VISAs? Curious to see how it is implemented once connected via LAN to a host PC.

[essele]

This project looks great! Will you be offering this adapter for sale or making it open source?

Thanks ... probably both. I've always intended to open source it, but having 50 made brings the cost down *significantly* so I am also thinking about that. I'm doing this for fun, so just want to cover costs really.

As far as the software ecosystem is concerned, how does it communicate with VISAs? Curious to see how it is implemented once connected via LAN to a host PC.

The Ethernet side presents a couple of interfaces ... you can telnet to the device and use "raw" comms, or you can use VXI11 (RPC) based comms, or you can use a web interface (just for testing really.)

The linux LXI tools (which I assume are also available on Windows) all work nicely with this, even for screen dumps on supported devices -- they can work with both the raw and VXI11 interfaces.

The VISA tools also seem to work, but I'm still getting fully to grips with them. At the moment the device is automatically discovered when it's scanned for, and then it auto-connects whenever the tools are running (which is actually quite annoying from a testing point of view!) and queries and responses all seem to work ok.

You also have the USB side which works with the VISA tools too -- there you can use USBTMC or a CDC-serial interface.

I've also had a quick play with eez-studio which seems to work, but I got a bit stuck properly understanding it, so will come back to it later.

I needed a break from microcontroller stuff yesterday so I did a very quick mock-up of a case ... far from complete ... but gives an indication of what it could look like. (Note: the debug connector wouldn't be populated normally so that hole wouldn't be there, that's just for my ongoing debugging.)

[MegaVolt]

Great looking box!

I thought: debugging pins can be used to connect a temperature sensor

[essele]

Great looking box!

I thought: debugging pins can be used to connect a temperature sensor

Good idea, but no need ... the four pin connector next to the USB (you can't really see it that clearly in the photos) is specifically for a I2C temp sensor and I already have most of that code working for a couple of different devices.

The debug connector does have the two SWD pins (which can be software driven if needed), and a UART-TX pin, and a way to get at the normal PICO reset mechanism (so you can do a USB based firmware load) ... so there options if needed.

[nexus]

Excellent! I'm surprised PoE GPIB adapters are not a common tool in today's T&M industry where automation tools are so widely available. This adapter will also be a great asset to older equipment that lacks native LAN or USB capability.

Looking forward to the release and I certainly would like to pick up a few for the lab! I've got an counter, vna, and electronic load that could certainly benefit.

[dietert1]

With GPIB products, success may depend on mechanical robustness as well. Is there a way to use standard GPIB screws, e.g. to fix the adapter to a cable?
The advantage of a LAN cable over a USB cable is that the latter happens to unplug all by itself..

Regards, Dieter

[nexus]

Hey, just checking in on this project to see if there has been any progress. Looking forward to the first release!

[JoeMeta]

Essele, you are doing some amazing work here.  I've read through all 2 or 3 of your forum threads detailing your development work on this project over the last two or three years.  I have to say I am very impressed!  This version is looking very elegant and I'd love to be able to look at the code.  I really admire how you've stuck with this project.

I'm sponsoring a student project to use the Raspberry Pi Compute CM4 as a networked data logger and graphing device for test equipment, including some old HP devices with GPIB.
I'd love to be able to share your project with them as a jumping off point for their final year project.  And as part of that, I think the students & community could start contributing code modules for driving and reading from various GPIB devices.

Further to this, if you aren't going to be releasing the PCB publicly, I'd be happy to purchase some modules from you at the current HW revision.  Hopefully, as the student's project mentor I can get them to be helpful collaborators for you.

[essele]

Apologies to all, I've had a few distractions which have taken me away from this for a little while ... firstly I got fed up with the slow flashing times using the standard PicoProbe so I ended up taking a few weeks to build a new version of that which is significantly quicker. (Available here on GitHub: https://github.com/essele/pico_debug)

Then my day job has got a bit more intense and I've been struggling to get my brain back in gear for the Yaugi.

So I think it's probably best to open it all up now so other people can contribute. I noticed while doing the new picoprobe that they now have an lwip implementation in the standard sdk (rather than the extras) so I'll need to do a little bit of work to get that to build cleanly, and then I'll try to document some of my plans (for example why have I embedded a low memory use implementation of Lua? ... I can't help but ignore my keep it simple goal ;-))

The final PoE boards also arrived, so I need to test them and document the flashing instructions and code for that.

So hopefully in the next week or so I'll have all that done and will open up the git repository (and add the PCB's to the repository also.)

@JoeMeta -- thanks for your comments, I'm very happy to help in any way I can. Drop me a PM if you want to talk further.

[ddavidebor]

Hi Yaugi,

Looking forward to the release! Will certainly try it out when I have the time

[dazz1]

I needed a break from microcontroller stuff yesterday so I did a very quick mock-up of a case ... far from complete ... but gives an indication of what it could look like. (Note: the debug connector wouldn't be populated normally so that hole wouldn't be there, that's just for my ongoing debugging.)

Very nice project.  Just what I was looking for.

My only minor suggestions to improve the case mock-up is to:

• include bulges or recesses in the 3D printed enclosure for finger grips to aid insertion/removal from the equipment. 
• round the corners to make them finger friendly.

If a group buy was organised, I'd definitely join in.

[dazz1]

Hi Yaugi

Just wondering if you can provide an update.   This is a project I want to build.  I have 3x GPIB instruments plus an ethernet instrument that I want to link up.
Can I assist with development?

[Kofen]

Hi essele

I'm not sure if you are monitoring this post, but in case you are:
You have done a truly fantastic job here! Great work!
I don't know if this project has stranded(I know all to well how life and other projects can get in the way), but I would really like to see this come to life.

If you don't mind, would you consider sharing the project as is so maybe the community can help finish it?
I would be more than happy to contribute, the poe gpib is just what I need so I am hesitating starting on my own since you have laid such a massive foundation to work on. USB based option does not fit my setup very well.
I currently own one(expensive) prologix ethernet gpib, but number of gpib only instruments has been growing and not all are complaint to not load the bus when they are off. This leads to a lot of patching or living with a lot of unnecessary fan noise and heat. I would gladly spend some(many!) evenings to just get a single poe powered adapter to each instrument to work around that.

Again, great work!