Getting the PoE to work

Found some time to do more testing and tuning.

The first thing I worked on was trying to get the low load control better.  I'm not so used to how primary side control flyback controllers work, the only other experience I've had with them had a chip that sampled the AUX voltage at a specific point in the PWM cycle.  Turns out the chip used here needs a continuous feedback signal from AUX and requires a good deal of filtering, more than I was doing.  I needed a bigger filter cap and things worked better once I hacked it on:

C14 was a 0.1 uF cap, now it's a 4.7 uF.  Which (to keep things affordable and performant) requires a bigger package, 0603 instead of 0402.  It worked fine to hack it on here but I'll have to change the footprint.  I checked the layout and there's enough room to do so in a rev 2.

Making this change made the control loop work better, but the output voltage would still go too high at no load and low load.  The AUX winding would stay nicely regulated but this was not reflected on the secondary at low load.  Primary side control works best with specially designed flyback transformers that have excellent coupling between the secondary and auxiliary windings.  I am using a cheap generic flyback with no such "expensive" requirements.  I don't really want to make the system more expensive for a use case that isn't really useful: there is going to be enough load if a Feather is connected.  We just need to make sure nothing breaks due to overvoltage when nothing is connected.

If only there was a simple way to put on a load when the voltage gets too high... wait, there is of course!  A zener diode will do just that: no load when the voltage is low enough, drawing more and more current as the voltage increases.  This will be self-regulating: as the voltage increases, current will start to flow, which will present a load that will help the system regulate.  Since just a small load is enough to help the primary side regulation system regulate, the current through the zener and its power requirements will be minimal.

Time to hack in a 5.6 V zener:

Testing shows it works very well.  Under no load, the output voltage is ~5.5 V.

So now that the power system was safe to hook up to a Feather, it was time to test that, and the Ethernet PHY.  Since the PHY is powered from the Feather's 3.3 V regulator, none of that had been tested yet.

Getting the W5500 PHY to work

A Feather was connected, successfully powered up from the PoE or USB, and could be programmed.  Following the directions from Adafruit I loaded the Arduino Ethernet WebClient example.  It didn't work.  The micro could communicate with the W5500, but it reported no cable was connected.  The LEDs on the Ethernet jack would light up in a pattern where one would turn on, then the other, then both went off.  Over and over.  I searched for an explanation of W5500 error codes but couldn't find anything.

I tried all kinds of variations of the Ethernet side components but nothing made a difference.  Tried adding decoupling caps, nothing.  Eventually I decided to try to connect it up to a non-PoE cable running from USB and... it worked!

I wasn't certain if this was good news or bad news.  More information and understanding is normally good, but this information seemed to indicate that there was a fundamental problem with the PHY when the PoE section was active!  Not something I liked to learn.  If the PHY just wouldn't work due to interference from the PoE, this project would be dead in the water.

I did a bunch more stuff trying to limit interference, adding bulk caps, etc but nothing made a difference.  At some point I decided to try to reset the PHY.  This did work: the PHY would come up and the Ethernet WebClient example would correctly load the data!

So, it looked like the PHY would work with an extra reset?  I decided to connect the PHY reset to a GPIO and automate the process:

Adding code to do a reset, the Ethernet would come up and work correctly every time!

What is it with Ethernet PHY chips???

To be honest, this situation feels way too familiar.  I ran into similar issues with initialization of the PHY on my #wESP32 project.  Why do Ethernet PHY chips all seem so finicky about their initialization?

Oddly, the PHY only has this problem if powered on when PoE is active.  When powered up from USB, it works without doing anything more, even when PoE is connected later on.  It's just if PoE is operational during the PHY powerup, it doesn't initialize correctly and needs a reset.

While it is possible to solve it with this reset-the-PHY-with-a-GPIO system, it still feels like a hack.  I was going for 100% compatibility with the Adafruit Ethernet FeatherWing, and having to use up a GPIO to reset the PHY and add code to do it kind of trashes this goal.

If I had more room I could add some parts, possibly even the same PMS150C I use on the wESP32, to make sure the PHY initializes correctly without having to burden the user with it.  But there's no space if I want to keep the board single sided.  I could make it bigger, but that would also trash the 100% drop-in compatibility with the Adafruit Ethernet FeatherWing.

So I'm trying to figure out what's the best approach, the lesser evil, to make this work.  I would appreciate user input on what would be more acceptable to potential users: using a GPIO pin and code, or growing the board bigger.

Meanwhile I'm still investigating if there's anything else I can do.  I checked the 3.3 V supply to see if there was anything different between USB and PoE power, whether in noise or rise time.  I couldn't spot any difference.  Maybe EMI is a problem but only during startup?  This is possible--the board is tiny, which crams the PoE section right next to the PHY.  During power up, the PWM and currents are the highest, while the PHY chip may have more high impedance nets right at that time?  I may play a bit with the soft start of the PoE chip to see if this may make a difference.

All in all, I am happy that everything works, even if it requires a hack. :)  Hopefully I'll be able to make it work without the hack, but if it needs it I'll just go ahead with it.  Hack or not, winning or not winning the Take Flight with Feather contest, I'm pretty confident now that this will eventually become a product!