Yaugi 4: GPIB Ethernet PoE Adapter

[essele]

Just about a year ago I first posted about a project I was working on to produce a USB to GPIB adapter along the lines of many others you could buy, but with a goal of being somewhat lower cost.

https://www.eevblog.com/forum/metrology/yet-another-usb-gpib-interface-(yaugi)/msg2744372/#msg2744372

Anyway ... I have continued developing this, but have switched away from USB in favour of ethernet, and specifically PoE (802.11af) ... it's not ready yet, but I've seen a few things over the last few days that's made me think I should talk about what I'm doing.

It's designed to be a single device controller, so not intended to run a long chain of GPIB cables, the idea being that they should be low cost enough that you just throw one in each device. I understand that might not be ideal from a triggering perspective, but given most new devices are ethernet based and not GPIB I'm sure it's not the end of the world.

I've redesigned the GPIB handshake and moved it from software bit twiddling into the programmable logic on the PSoC device, so it's much faster, it also has a hardware timeout mechanism and so far I've not managed to lock it up at all.

It uses a W5500 ethernet controller and I've implemented (from scratch) a DHCP client, a mDNS responder, a VXI11 rpc based client, and a web server to handle config and even firmware updates. (Now you know why it's been a year!) It also accepts TCP and UDP based queries, so can be used with things as simple as nc. It also seems to work ok with LabView and other NI tools although I've only done very rudimentary testing.

I'm using a Silvertel Ag9900 PoE module, which really feels like the lowest cost way of achieving PoE (and now are available from Mouser, the first few I had to get direct!) Still mulling whether to add a USB port for power in for non-PoE scenarios.

I've got a version with the GPIB connector directly on the PCB (see photo in 3d printed case) and I've just built another version with an IDC connector and ribbon cable, which I think is more practical for use behind kit in tight spaces etc.

So far it's largely working, I still need to implement the VXI11 abort and interrupt channels, and there is still a fair amount of work to do on the web browser and web based UI.

My best guess at this point (as I've just found some lower cost ethernet magjack options) is that at small scale this is likely to be $30 to $40 of board and components. My last order of 5 assembled IDC ones from JLCPCB was $40 + shipping/tax and you just need to add the PoE module, PSoC, MagJack, and ribbon cables/connectors.

Interested in thoughts/feedback. No commercial intent - doing it for my own use, and will be very happy to share once it's working reasonably well.

(And yes, there is a bodge wire in the photo ... my new MiniProg4 seems to be missing a pull-up on the UART so receives garbage during reset and programming, so this will be added on the next revision, but only needed for debug)

Lee.

[ve7xen]

I really like the concept. PoE power is a nice idea, just get a small PoE switch and power several of these on the bench from one power supply. Much prefer it to janky USB solutions for this, even if it is a bit more expensive.

I'd be concerned about availability of the PoE module, especially if you're presenting this as a project for DIYers and not a product for sale, but for your own personal use, who cares! It doesn't seem to be available from any of the normal suppliers; at a glance I can't even find anywhere to buy it online in singles. I assume it's also fairly expensive - curious where you got them from? There are lots of integrated PoE-PD / DC-DC converter ICs available on the market (e.g. NCP1083, Si3404, TPS23757), even if it's a somewhat larger footprint, I think I'd rather a discrete implementation. Probably cheaper too, if you're doing this in quantity.

[essele]

Thanks ve7xen.

I'm fairly confident the PoE modules are reasonably available, when I first started looking at this I had to get them "direct" (was actually through a distributor, but I was able to buy 2 modules at a reasonable price even with shipping to the UK), but now they are available at Mouser...

https://www.mouser.co.uk/ProductDetail/silvertel/ag9905lp/?qs=OlC7AqGiEDm9ZoM6zJQCoQ==&countrycode=GB&currencycode=GBP

I did look at a discrete implementation as I think I would prefer it, but I couldn't find any way of doing it that was going to be lower cost, and definitely would have used more board space. I even looked at the IC's used in the silvertel module, but couldn't figure out what they are.

If anyone has a suggestion that's going to beat £6 then please let me know.

[dietert1]

This is a great project, if you implement a nice subset of VXI and if it works reliable. About ten years ago i made some USB-GPIB adapters based on a XILINX CPLDs and FTDI USB-parallel chips. Those GPIB adapters have been running for months. Usually until the DLINK USB hub gets stuck, maybe when someone touches the cables.

As far as i remember POE is something in the making. It started as something simple to supply IP Phones, but nowadays it can supply a PC. Meanwhile power conversion got sophisticated rules and signalling, that can't be implemented without special chips. As far as the chip implements all the rules it should be/will be tolerant to future POE upgrades. The situation compares well to the different USB standards, if you consider those USB-C connectors Apple introduced.

Regards, Dieter

[ve7xen]

Oh yeah, I didn't realize the part number is slightly different than the series number . Looks to be available at Mouser at least, so that's not so bad.

About $9 USD for the module doesn't seem too bad in small quantity. In larger quantity I'd be confident the discounts are going to ramp much faster on the discrete components, especially the magnetics. And sometimes magnetics availability is an even bigger problem! In onesy-toosies, wouldn't be surprised if it's similar / more to do it yourself. Fair enough decision.

As a quick thought experiment, I took a look at the Si3404 EVB isolated flyback configuration. Assuming passives are free, adding up the transformer and active components I get about $8 USD at qty 1. Add a dollar or so for passives and it seems slightly more expensive at low quantity (looks like the folks at Silvertel did their homework lol). At high quantity sourcing most of the stuff from Asia, the gap widens pretty quickly, at only qty 100 it's down to about $5.50.

Technically isolation is required for this, since it connects to an external device (the test equipment), but in practice you could probably get away without it and it greatly simplifies / shrinks the design. If you did that, I think you'd be closer to $4 at qty 1 and $3 and qty 100.

Doing PD-powered gadgets (or just a breakout board) has been something on my mind for a while so it's interesting to evaluate the options, and good to know about those Ag modules.

[essele]

It's interesting you picked the Si3404 ... I did look at that as a potential option, however I always get stuck when it comes to the magnetics. I can't find a source for the TOEP13-0155S1, and whilst the datasheet is available it doesn't appear to be off-the-shelf. What source are you using?

There are some HanRun and TNK parts on LCSC that look "similar" (with a small 's') but it really not an area I'm familiar with so don't understand the implications of different choices. Maybe an interesting learning exercise to build a few different variants??

EDIT: Hmmm ... have just found some low-cost/low-power coilcraft transformers ... I fear a rabbit hole appearing!

[dietert1]

Just noticed the Silvertel module AG9905M requires a minimum load current of 200 mA, otherwise it will emit audible noise and may cause POE failure. See 8.3 in the datasheet.

Regards, Dieter

[essele]

Hi Dieter,

Yes indeed, I was slightly concerned when I first saw that but the W5500 uses 128mA when it has a 100M link, and then you add the PSoC and a couple of led's and it's all getting pretty close anyway.

Also, in my testing I never heard a peep even with the W5500 in power down mode ... with various versions I'm on about module 6 from three different batches as well all with no issues and no audible noise .. so don't think it's an issue, at least in this application.

Edit: hadn't really registered the MPS "maintain power signature" comment properly before, but on investigation this is actually only 10mA, so not a problem here.

[ve7xen]

It's interesting you picked the Si3404 ... I did look at that as a potential option, however I always get stuck when it comes to the magnetics. I can't find a source for the TOEP13-0155S1, and whilst the datasheet is available it doesn't appear to be off-the-shelf. What source are you using?

There are some HanRun and TNK parts on LCSC that look "similar" (with a small 's') but it really not an area I'm familiar with so don't understand the implications of different choices. Maybe an interesting learning exercise to build a few different variants??

Good point. It seems like these flyback converters are generally designed with a very specific transformer in mind. At least they never seem to give you the applications information needed to select another one, and I'm not bona fide enough to be able to do it from first principles.

I had originally looked at the Si3402, but switched my post to Si3404 when I realized it's pretty similar but a slight bit cheaper. However, the flyback design in the 3404 EVB at least uses the AUX winding from the special transformer, while I was still using the CoilCraft FA2924/FA2805 from the Si3402 EVB. Use of the AUX winding is optional, and the parameters of the CoilCraft transformers seem similar enough that they could be a drop in replacement if you cut the AUX winding from the design, but not confident about it. Not really too sure what the main differntiators between the two are other than that the 3402 is in a slightly larger package and seems to be an older design with a simpler DC-DC converter; doesn't seem like enough to justify a new part, but I don't know the market.

EDIT: Hmmm ... have just found some low-cost/low-power coilcraft transformers ... I fear a rabbit hole appearing!

Oops 

[nightfire]

Thats a nice way of getting new life into old gear- I also was thinking of getting some old hardware for usage in my home lab, but the most interesting stuff had only GPIB, not even a RS232 interface...
As I personally try to avoid having proprietary interface cards (and drivers) ready, some standardized interface like ethernet/scpi is most welcome for a moderate price.

[mjkuwp]

+100 for this idea.

I've recently been doing some automation with power supplies and electronic loads.  I started out with USB or RS-232 interfaces but found it a real hassle to develop on Windows and then implement these in Linux.  There are enough differences to make this a real pain.

I switched to all Ethernet by buying different equipment or the LXI firmware upgrades and discovered this solution is far better for ease of use.  I've set my router to assign IP addresses based on the MAC address of the device and now I can seamlessly develop on Windows but then run the scripts from a Raspberry pi that is running on PoE.

i've never used GPIB but I have instruments that have this and no other interface.  I would also consider buying an older instrument if I could upgrade it with such a device.

.......
So far it's largely working, I still need to implement the VXI11 abort and interrupt channels, and there is still a fair amount of work to do on the web browser and web based UI.
....

what is the web browser and web based UI for?   without these features would it be useable by writing code?  A person can use the python-vxi11 library to send IVI /scpi commands?

I guess there must be some amount of work to port GPIB things to IVI commands.

[uski]

Pretty cool ! I developed a commercial USB-GPIB interface years ago as part of my work, so it is cool to see some activity in this space still in 2020
I would love to build a few units for my own use too, especially if the firmware is open source.

[essele]

Thanks for all the positive comments.

The web browser was the easiest way to enable config ... dhcp vs static, names and values for discovery etc, plus any GPIB configs (EOI management etc.) Also, it turned out to be the easiest way to enable to firmware update.

I've also just got a simple "send GPIB command" page working as well ... not really the main way of using it, but useful to test things.

It's already usable by writing code, the vxi11 interfaces work already, so I'm testing with python, but it also works with netcat (nc) and the lxi command line tools.

I have just discovered that the cheap plastic 24-way IDC Centronics connector doesn't actually fit a 3458A -- way too loose, although it fits a 34401A perfectly! Very strange ... but the central bit is quite a bit smaller. Need to rethink this.

[enut11]

Yes, the plastic 24 PIN is also loose on my HP3456A. The workaround for me was to open the area around the mounting screws. This allows the connector to sit further in. To hold it in place I use short screws with large flat washers.

[essele]

I’ve come up with a small adapter board that converts to a standard IDC header. That way I can use the higher quality (but still low cost) GPIB connectors.

Also ... I’m just waiting for the second version of my PoE DC/DC converter, if it works as expected then it’s between about $4 and $5 total cost, so a viable replacement for the Silvertel module (although will use slightly more board space.)

[essele]

Quick update on the DC/DC converter...

The test boards have just arrived, and with an extra 100uF cap seem to work perfectly (and the Yaugi already has a 100uF onboard) ... nice regulation and low ripple at 300mA, which is my target for now (also seems good at 500mA.)

At 300mA it's 75% efficient, which is exactly what I see with the Silvertel board (and 78% at 500mA, but all very coarsely measured for now.)

This is with a HanRun HR051067 transformer, which is $1.01 in single quantities! I've also got some Pulse and Bel transformers to try, but if the Hanrun works then it's the lowest cost.
 
There's a large amount of ripple and audible noise without the extra cap, which I don't get on the various other PoE modules I've had, so I will try to get to the bottom of that, likely a school boy error, plus I want to spend a bit of time looking at thermals. I've not included any thermal considerations on this test board so need to understand that before building this into the base Yaugi board.

All of the components are part of the JLCPCB SMT service other than the PWM chip and the transformer ... the 100V caps and the zeners cause quite a consumption of "extended components" which adds to the PCBA cost for small runs, so I need to look at options there too. Final board space permitting, is there any reason not to use two 50V in series?

Not tested the actual PoE signature bit yet, that's pretty simple, so hopefully will be ok.

Schematic attached ... this is all based on the FAN7601 application note and what I see on some of the existing modules. Very keen to hear feedback if anyone can help (although probably getting off topic for the metrology section, happy to start another project thread if better done that way.)

Lee.

[MiDi]

...
the 100V caps and the zeners cause quite a consumption of "extended components" which adds to the PCBA cost for small runs, so I need to look at options there too. Final board space permitting, is there any reason not to use two 50V in series?
...

If voltage accross those 100V caps exceed 40Vp, it is recommended to use balancing resistors if 2 series caps are used instead.
That adds to board space and usually to bom cost.
Usually it does not make sense to put 2 caps in series.

[essele]

Very quick update ...

New board with integrated DC/DC converter is back ... so far all seems ok.

The transformer is too close to the opto-coupler (wouldn't be a problem with the Bel-Fuse ones), but other than that initial power-up was good and everything appears to be working.

I'll look at thermals tomorrow, and actually test the GPIB functionality (although that's not changed) ... I've also included the required USB connections since the PSoC has the capability as per my previous designs, so this board should work with PoE or USB power, and be able to communicate over both USB and ethernet.

I'll probably switch to the 1.27mm pitch shrouded headers and 0.635mm ribbon cable for the main GPIB connectivity to make the cable a bit more manageable.

This is all manufacturable using JLCPCB's PCBA service with just a few things to add: the transformer, the PSoC, the PWM controller, the FRAM (I hate the PSoC eeprom emulation), ethernet jack, and the various headers.

[essele]

Ok ... final board spin looks good, there are few changes that I think work well...

1. The debug port is back to standard 10-way 1.27mm pitch shrouded header, but at right angles and brought out so it can be accessed from outside the case ... this is probably mostly for my benefit during development as I need to keep re-flashing them!
2. The serial port is now a right angled header 4-pin (+V, RX, TX, GND) also brought out from the case, this will double as a mechanism for resetting to defaults (not 100% sure yet, jumpering something) and also provides another method of powering.
3. I've switched to 0.625mm pitch ribbon and 1.27mm pitch IDC connectors. This is much more manageable and shaved a bit off the board. I've also reworked the adapter for the GPIB connector, which also seems to work ok. You can have the ribbon cable any size you like to suit your needs.
4. The USB port is tested and working for both power and data.

Main focus for a bit now is going to be the software side ... lots to do, including a complete re-write of the USB stack, but I'm going to focus on the ethernet/VXI first.

There are some "mapping" things I can do to make things easier with some devices ... for example I've added an option to intercept a VXI "*IDN?" request, so I can return whatever the device returns (i.e. no change), I can return a fixed string, or I can return the response to a different GPIB request ("END ONCE; ID?" for a 3458A for example.) ... [the lxi tools do a *IDN? when discovering!]

I have plenty of rom and fram available, so I could also easily have a mapping table so "non-standard" devices could be somewhat mapped to standard commands.

I'm also thinking about some "automated" measurement options, where the Yaugi configures a specific measurement and then periodically measures and sends the results to a grafana type solution.

But first ... a bit of work on the config side, and then I need to complete the VXI stack. I'm also looking into how I can do some rudimentary EMI testing, (a) because it interests me, (b) because I've just got a shiny new SSA3000X (inc VNA thanks to this board!), and (c) because I'm going to have these things next to sensitive equipment and I still don't trust my DC/DC converter.

[MilkmanCDN]

This is exactly what I've been looking for.   Are you planning on making these available via eBay or some other outlet?

[essele]

This is exactly what I've been looking for.   Are you planning on making these available via eBay or some other outlet?

Hi ... I wasn't actually planning on selling these, I'm mostly doing it for fun and the learning experience, and my own use of course, but if there's interest then I could certainly make a few available.

I've just submitted another rev of the board ... I wanted to tighten up some of the loops on the DC/DC converter which should hopefully improve noise and ripple, it's wasn't too bad, but there was an easy optimisation I could do. But more importantly this version includes a TQFP64 version of the PSoC so that I have the option of more memory and flash (32k/256k) .. that way there should be enough space to try to embed eLua and have an onboard scripting capability. I still need to look at "screen dumps" and I have a feeling that might need some more memory.

I've also switched to 3.3V rather than 5V for the main supply (there's still a 3.3V regulator for when you are USB powered), this gives me a greater choice of FRAM so I can also get a larger device in there as script storage.

I did prepare a board using the QFN64 but I'm yet to really get to grips with hand soldering these, so thought I'd stick with the more forgiving TQFP's for now.

[psynautic]

I would be interested in at very least, a board or two and the STL's for the enclosure.

[MilkmanCDN]

Hey there,

Drat.    I'd be happy to pay you whatever you think it's worth for one of these to test.    PM me if you're interested.   I'm looking to control my older Espec SH-241 oven (GPIB only) via ethernet, and this seems like the cleanest solution. 

[H.O]

I'd certainly be interested would you make them available.

[essele]

Just a quick update ... the 3.3V change all seems to be fine, and the DC/DC converter seems stable and pretty good from a ripple and noise perspective -- although I do want to re-test with a Bel Fuse 3.3V transformer as I would hope it should be better than the HanRun 5V one for this use case.

The switch to the 64 pin PSoC also worked fine, this has enabled quite a few improvements given the extra memory, so I've been focusing on building some good capabilities into the firmware.

The biggest change is the incorporation of Lua as a scripting language, I had originally intended to use eLua, but it's quite a major codebase diversion from the main Lua distribution and is therefore stuck on a fairly old version. So I've created my own embedded Lua version which is focused on minimal code changes and really just adding supporting for read-only strings and tables ... it seems to work really well, just over 3K (compared to over 20K normally) of used memory on the PSoC with all the relevant modules loaded.

I also incorporated a Cortex-M0+ math library (used by Lua) which saved a huge amount of flash compared to the standard library functions.

There are also DNS lookups supported, so you will be able to send data to data logging services by name.

I've also added the PSoC "real time clock" ... which is a challenge since I don't have an accurate crystal, so I've also incorporated a simple form of NTP and some clock skewing to keep the time reasonably accurate for scheduled activities (i.e. run an ACAL at 1am every morning.)

In working with the web server code, to support running Lua scripts and getting streaming results, and also looking at how this is going to work with blocking GPIB read/writes, I've decided that my DIY cooperative scheduling approach is going to be a problem, so I'm now working on getting it all up and running on FreeRTOS ... this enables much simpler code paths for complex activities which should also make for much easier debugging.

I am definitely in the scope creep phase ... but I am enjoying it ... and I do think the move to FreeRTOS will ultimately make everything much more manageable.

Lee.

[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.

[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?