Close
0%
0%

PoE-FeatherWing

Like the Adafruit Ethernet FeatherWing, but with Power over Ethernet built-in!

Similar projects worth following
This projects aims to create a WIZ5500 / Power over Ethernet FeatherWing, fully isolated, in the same size and compatible with the official Adafruit Ethernet FeatherWing (which does not have PoE).

This idea was originally suggested to my by @professor after I released my #wESP32 and has been waiting in the wings for quite a while now. The Adafruit Feather contest made the time seem right for it to come to fruition.

I think it was originally in September of 2018 that @Prof. Fartsparkle suggested to me right here on Hackaday.io to make a project like this as a "successor" to the #wESP32.  Since at the time the wESP32 wasn't even released yet, that seemed a bit premature to me. :)  But I liked the idea enough to do a good brainstorming session.  I don't see it as a successor so much as a nice addition to the PoE products that are available to makers.

There were a couple of potential snags in making a PoE FeatherWing.  The first is that the Feather system didn't intend for FeatherWings to back power the main board.  That doesn't mean that nobody has done this tough. :)  I think many Feather boards now include a diode to prevent back powering the USB port, and for those there is no issue.  There are some that don't include this circuitry though, so the problem had to be managed carefully.

I do this by putting ~4.5V on the USB pin, instead of 5V.  Since the flyback converter of the PoE supply has a diode rectifier on the output, it will just not provide power if there's a voltage higher than its own output on the USB pin already.  I've tested this with a Feather M0 Adalogger which does not include a diode, and my USB port was not blown up. :)

The second potential snag was of course size.  Feather boards are tiny, and Ethernet jacks and flyback transformers are not.  It took a 4-layer board, going to 0402 parts from my usual 0603 (really not an issue nowadays) and using plenty of resistor and capacitor arrays versus individual components to get the needed density.  Initially I wanted to keep all components on one side, and I succeeded in this for the main functionality if you don't count the (optional) 24AA02E48 on the bottom.  But since my CM has no issue or extra charge for double sided components, it's not really an issue.

I used the WIZnet W5500 just as it is used on the Adafruit Ethernet FeatherWing, so it is fully compatible with all the existing software out there.  I also added a 24AA02E48 chip to fix the annoying issue that WIZ5500 chips don't come with a MAC address built-in.

For the PoE side of things, this had to shrink significantly from what I was using on the wESP32.  To that end, the design was built around the TI TPS23758 instead of the Silicon Labs Si3404A.  The chip is slightly bigger, but it implements primary side regulation using the flyback transformer's auxiliary winding, making it possible to drop the huge opto-coupler and all the circuitry around the secondary side shunt regulator.  I also used a 5W instead of the wESP32's 13W flyback transformer as I had done on the #LiFePO4wered/ESP32, since Feather systems don't tend to be power hungry, and the tiny size would just not allow such power while keeping it isolated.  In the end, you can confidently get 3W out of it, 4W is possible but pushing it.  Not bad since the normal USB power into a Feather system is limited to 2.5W.

PoE-FeatherWing-2.pdf

PoE FeatherWing rev 2 schematic

Adobe Portable Document Format - 37.76 kB - 01/09/2020 at 16:51

Preview
Download

PoE-FeatherWing-1.pdf

PoE FeatherWing rev 1 schematic

Adobe Portable Document Format - 35.41 kB - 11/21/2019 at 20:10

Preview
Download

  • Crowd Supply campaign live!

    Patrick Van Oosterwijck07/16/2020 at 18:40 0 comments

    Whew, too much going on!  I forgot to post here that my PoE-FeatherWing Crowd Supply campaign is live!

    https://www.crowdsupply.com/silicognition/poe-featherwing

    We made a good start and are nearly halfway funded, but we still need your help to make it.  Thank you for your support!

  • CircuitPython troubles and flyback change

    Patrick Van Oosterwijck06/02/2020 at 20:15 0 comments

    Much progress has happened, here's a recap:

    CircuitPython troubles

    I previously reported that I had successfully tested compatibility with CircuitPython.  Seems I wasn't thorough enough: this had proven compatibility from a software standpoint, that the W5500 CircuitPython driver worked correctly with the PoE-FeatherWing.  Problem was: to see what was going on by console prints, I also had the USB connected.

    A problem became obvious when I was building the test fixture, which I'm basing on a Feather M4 running CircuitPython.  It would not run my test code with powered from the PoE-FeatherWing.  I adjusted my demo code to light up some LEDs and confirmed that my demo code also didn't run when powered from the PoE-FeatherWing, without USB connected.

    The system kept ending up in "safe mode", which meant it would not run my Python code.  After some diffing through the CircuitPython source code, I found out that safe mode was in this case being triggered by a brown out detector (BOD) reset.  Did my power supply really brown out?

    Turns out, the problem was because of the pretty slow ramp up of the PoE power.  CircuitPython sets the BOD level to a pretty high 2.77V in its initialization code, to make sure the system voltage stays within the safe range for SPI flash chips.  Power on reset would release at 1.7V, the micro would start initializing and get to the point where the BOD level was set to 2.77V before the power supply had time to reach this level!  This would cause a BOD reset, the chip would start initializing again, and by the time the BOD level change was reached, it would the power supply was high enough and the system would run.  But, because of the BOD reset, it would run in safe mode, not loading any Python code.

    It was obvious this could be fixed with a software change, but because I really did not want to start maintaining a separate CircuitPython branch for PoE-FeatherWing compatibility, I filed an issue with CircuitPython and simultaneously started to see if I could do anything in hardware.

    I found that I could make the code run if I added a 4.7 uF capacitor from the EN pin to GND.  In combination with the pull-up on the Feather, this would delay the turn-on of the 3.3V regulator on the Feather, enough to give the input voltage time to ramp up before the BOD level was changed to 2.77V.

    While it would be possible to add this to my PoE-FeatherWing, it still felt like a hack.  It depended too much on the exact implementation of the EN pin on the Feather, something out of my control.  And a quick check showed that various Feathers used different values of pull-up resistors, and different 3.3V regulators that may have different enable thresholds.  There was always the risk that even if I tested that it would work with every Feather currently on the market, it could still fail on a Feather released in the future that used some different arrangement on EN.

    Luckily it turned out to not be necessary.  In a prompt response to the issue I had submitted, I was told that this had been solved in the UF2 bootloader.  They had already added code to wait for the voltage to reach 2.77V before loading CircuitPython in bootloader version 3.9.0.  Although I had updated the CircuitPython on both my test boards, I had failed to also update the bootloader.  Moral of the story: update both the CircuitPython image and the bootloader on every Feather you buy before use!  Oh, the joys of modern software development.

    So, this turned out to be a tempest in a teapot.  I'm glad there is a software solution already in place, as it is the best way to solve this.  With this unblocked I could also continue on my test fixture.

    Flyback change

    On the #wESP32 I had used a Hanrun HR861153C PoE Ethernet jack, but I had tested and confirmed that equivalents from other manufacturers such as Link-PP worked just as well.  Link-PP...

    Read more »

  • More testing completed

    Patrick Van Oosterwijck05/20/2020 at 00:10 0 comments

    I found the time to do more testing, and most of it is good!

    The first thing on my list was to test with CircuitPython.  This turned out to be more involved than expected.  Turned out the Feather M0 Adalogger was not compatible with the W5K CircuitPython driver due to the use of longs.  So I had to get a Feather M4 Express to make it work.  Then it didn't seem to be working, until I remembered it was probably a good idea to update my board to the latest version of CircuitPython, versus using the one the board came with.  That solved all my problems:

    Yes, I also have USB connected to be able to see the console, but it works without as well.

    I added this code to the standard Adafruit example to read the MAC from the 24AA02E48 and use it:

    # Read the MAC from the 24AA02E48 chip
    mac = bytearray((0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED))
    i2c = busio.I2C(board.SCL, board.SDA)
    while not i2c.try_lock():
        pass
    i2c.writeto(0x50, bytearray((0xFA,)), stop=False)
    i2c.readfrom_into(0x50, mac, start=0, end=6)
    i2c.unlock()
    
    # Initialize ethernet interface with DHCP and the MAC we have from the 24AA02E48
    eth = WIZNET5K(spi_bus, cs, mac=mac) 

    Next up: the Giant Board!

    I just followed the documentation to get the Ethernet FeatherWing to work on the Giant Board, with one small exception: instead of having to run a separate wire to "connect the IRQ pin on the end of the Ethernet FeatherWing to the pin PD31 on the Giant Board", you can just bridge the solder jumper!

    That's so much better.  After doing this and putting the boards together, it worked right away!  Here you can see me doing an `apt upgrade` through the Ethernet, and powered from Ethernet, connected over ssh:

    Success!

    I had one weird thing happen though, and it's a bit worrying.  At some point, I was using a stupid cable of which the clip had broken off, and the cable disconnected in the middle of an `apt update`.  No worries, I reconnected with a better cable, but after that, the PoE-FeatherWing didn't work right any more.  The symptoms are very bizarre.  At first I wondered if it was just a problem with the Giant Board, but my two other Feathers showed the same issue.  The W5500 works, but only if connected to my router without PoE.  The PoE power works as well, but no data communication happens when connected to (and power conversion happening from) the PoE router.

    I don't have a clue yet what exactly happened.  Just disconnecting the cable can't really have done it (whatever 'it' is), because I've done that a lot with other boards, and there's never an issue.  Currently my theory is that the "sliding out" causes a long term intermittent connection that may have over-stressed something.  Not something I enjoy finding out, but at least I can hopefully track down what failed and fix it before producing the remaining 900.

    Last thing on my list was load testing.  I need to do it on more boards, but at least on the couple I have tested, I've been able to pull 1A and keep the voltage above 4V, which is sufficient to keep the 3.3V regulated.  The secondary Schottky diode rectifier gets quite hot at this current:

    While it would be nice to play the numbers game for marketing and say that the design supports 4W, I think with the space constraints we're dealing with, it's probably not the best idea to run at 4W.  On USB, Feather systems have 2.5W available to them, and I think specifying the PoE-FeatherWing as a 3W system is a safe conservative number.

    This is a thermal shot when running at 3W:

    Still toasty, but much better!

    Next up: figure out what went wrong with the unit that won't communicate when running from PoE.

  • First CM prototypes!

    Patrick Van Oosterwijck05/10/2020 at 01:04 0 comments

    It's been quite a while since the last update.  First there was the Chinese new year, and then the Covid-19 situation caused major delays with pretty much everything.

    In my case, the delay was mostly due to delays in the manufacturing of the flyback transformer and Ethernet jack by Link-PP.  I had decided I had enough confidence in the rev 2 layout to go to my contract manufacturer KingTop instead of doing another prototype round myself.  The plan was to immediately order 1000 pieces (to get bulk pricing) or most parts, but only 100 PCBs at first.  Then when everything seemed alright with the 100, have the 900 remaining units built.

    I finally received word from KingTop that Link-PP had delivered the parts necessary to build the first round of 100.  They had received 1000 Ethernet jacks and 100 flyback transformers (since we hadn't tested their flybacks before).

    Then I got some bad news: the Ethernet jacks had an extra pin and did not fit into the PCBs!

    That was an unexpected horrible thing to happen!  Both the datasheet and the samples I had previously received from Link-PP had this pin missing.  Now we ordered 1000 pieces and they were all wrong.

    Luckily, KingTop and Link-PP were both responsive and helpful to deal with the problem.  Link-PP confirmed that the pinout was correct and the extra pin was unused.  They just seem to have a variant of this jack with and without that pin.  Odd that they would have the same part number, that seems to be asking for trouble!

    It was decided that for the build of 100 prototypes, KingTop would cut the pin, while they shipped the remaining 900 back to Link-PP for replacement.  With that settled, KingTop went to work quickly and built the units.

    Looking good!  They shipped them and I received them late this week.  I added pins to a test unit:

    Then I put it to the test by connecting it to a Feather M0 Adalogger board programmed with an Arduino sketch and hooking it up to a PoE switch:

    It immediately worked!

    I have now confirmed the PoE section works, the W5500 works, and I also checked that I could load a valid MAC from the 24AA02E48 chip.  Still to do:

    • Check how much power the PoE section can deliver, on a statistically relevant number of boards.
    • Test that it works with the W5500 CircuitPython module.
    • Test that it works with the Giant Board.
    • Get to work on the Crowd Supply campaign. :)
    • Design and build a test fixture for production.
    • Get KingTop to build and test the remaining 900 units.

  • Rev 2 layout

    Patrick Van Oosterwijck01/08/2020 at 19:06 0 comments

    Revision 2 of the PCB layout implements the changes needed to make rev 1 functional, plus some additional goodies:

    • Added D5 5.6V zener diode on the PoE output voltage to limit the output voltage under no or low load conditions by providing a minimum load if the voltage goes too high.
    • Changed C14 to 4.7uF in 0603 package to make the primary side regulation stable.
    • Removed L1 ferrite bead and added C16 and R10 to reset the W5500 on power-up.
    • In addition to the default-closed solder jumper that connects the W5500 CS line to pin 22 of the Feather footprint, as present on the Adafruit Ethernet FeatherWing, I also added a default-open solder jumper to connect the W5500 IRQ line to pin 24 of the Feather footprint.  This keeps it 100% out-of-the-box compatible with the Adafruit Ethernet FeatherWing, while at the same time making it compatible with the Giant Board without having to run extra wiring, but by just bridging this jumper instead.
    • As mentioned before, I had the desire to have a 24AA02E48 on the board to provide a globally unique MAC address since the W5500 doesn't come with one, but I ran out of space for it.  I decided to add footprints for this chip plus I2C pull-ups and decoupling cap to the bottom of the board (U3, R8, R9 and C17).  Maybe I can produce versions with and without the chip, or maybe I'll just leave them unpopulated so the user can add the parts if desired, or maybe it won't be a problem for the CM to always have it.  Either way, it doesn't hurt to have the footprints present while I figure it out.  I'd like to get feedback on how useful you think this is in the comments!
    • Renamed the solder jumpers SJCS and SJIRQ to make it more clear what's what.

    The resulting layout looks like this:

    Time to get some boards made!

  • W5500 initialization

    Patrick Van Oosterwijck01/08/2020 at 18:25 0 comments

    In the last update I reported that I needed to find a way to reset the W5500 after power-up from PoE for it to initialize correctly.  I found some time to work on that yesterday.

    Resetting something isn't particularly hard, the main problem I had to deal with was doing it as simply as possible because I have no space for anything fancy on this tiny board.  So I started out the simplest way I could think of.  Since the W5500 datasheet mentions that there's a 77K nominal pull-up resistor on the RSTn pin, I decided to just add a 0.1uF capacitor from this pin to ground.  The simplest reset circuit, the idea being that the RSTn would release with a little delay after power came on.

    I scraped the solder mask off a GND connected via and soldered a cap to it on the bottom of the board.

    It worked! :)  Then it didn't. :(

    The first time plugged in, the PHY came up correctly.  Then unplugging and replugging, it didn't.  What was going on?  I decided to measure the voltage on the cap, and found that it was still at 2.5V or so after the power was removed.  Discharging very slowly.  I decided to short the cap and plug it in, and the PHY came up correctly.  My cap was just not discharging when the power went away.

    It seems the pull-up "resistor" is actually a highly resistive PFET that isn't active when the chip is off.  This is a very common thing to do for pull-ups on chips, since FETs are much smaller than resistors on chips, and size equals cost.  But I had expected that the cap would still discharge through the ESD diode that typically goes from a chip IO to the positive power supply.  Turns out the W5500 has 5V tolerant IOs, which means the ESD protection has to be implemented differently (likely with zener diodes) and there is no diode going from the IO pin to supply.  Hence no discharge path for the cap on RSTn when power goes away, only self-discharge.

    Unfortunately this means adding another part, a diode or resistor.  Resistor hopefully, since it's smaller and cheaper.  I added a 680K from RSTn to VCC.  As I had been considering where I could possibly fit this parts, I decided to get rid of ferrite bead L1, since that seemed like the only good place for these extra parts to go.  Filtering the PHY power supply is a good thing, but likely not a make of break situation like the PHY not initializing correctly.  Space-wise, I was going to have one or the other and that made an easy choice, but I needed to check it would indeed work without the bead.

    Tried it and... success!  The W5500 would initialize correctly every time!

    I implemented this on both prototypes and it works good.  When L1 is gone, I can fit this new capacitor and resistor in 0402 package on the top side of the board where L1 was, keeping it single sided.  Time to implement all changes in a rev 2 PCB layout!

  • It works! Sort of.

    Patrick Van Oosterwijck12/17/2019 at 05:24 0 comments

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

    Read more »

  • Prototype build

    Patrick Van Oosterwijck12/11/2019 at 18:09 0 comments

    The PCBs arrived from JLCPCB, looking excellent as usual:

    Time to build some prototypes!  So I headed to the Tinkermill to assemble two of them:

    Then through reflow:

    Looks pretty clean, except for some shorts on the Wiznet W5500.  Also, odd that the tape on the flyback transformers was adversely affected, since it's supposed to be able to deal with lead-free reflow.  This was not the case with the professionally built LiFePO4wered/ESP32 prototypes that use the same flyback transformer, so I'm chalking it up to the lower quality desktop reflow oven I used.

    After cleanup and final through-hole assembly, I had some prototypes to test!

    First thing to try: do we get PoE power?

    The answer is yes, we are getting power!  The output voltage shown on the load is low because I'm measuring through the wiring, at the PCB the voltage was above 4 V at 1 A load.

    Heat generation is reasonable, concentrated on the secondary side Schottky diode, while the PoE controller stays pretty cool:

    Oddly, things are worse at low load.  It looks like the primary side regulation control loop isn't working great and the output voltage would go way too high (around 15 V) at low and no load.  The picture below shows the situation with just enough load to keep things in control:

    Low load makes the PoE controller run way hotter.  Turns out this is because just like the output voltage went way high, the auxiliary voltage that feeds the chip does the same thing, and it was actually exposing the chip to out-of-spec voltages.  More testing at no load eventually killed the chip.

    Looks like I still have work to do to get this to behave properly. :)  Tuning the control loop tends to be a slow, labor intensive process of trial and error.  Still, I find this a promising start.

    Only after I get a stable output voltage will I hook this up to a Feather to test the Ethernet controller part, since this is powered by the Feather's 3.3 V.  Since most Feathers from Adafruit seem to use an AP2112 LDO, I'll have to make sure the PoE voltage doesn't go above 6 V since that is its maximum operating voltage.

  • Layout done!

    Patrick Van Oosterwijck11/21/2019 at 20:22 0 comments

    I managed to cram it all into a layout the same size as the Adafruit Ethernet FeatherWing!

    I had to go to a 4-layer board with 4 mil trace/spacing, 0.2mm minimum drill and 0402 size components to make everything fit.  But that's OK, there isn't anything bleeding edge about it that board and assembly houses would have trouble with nowadays.

    I managed to pretty much keep the same functionality as the Adafruit Ethernet FeatherWing.  It uses the same SPI signals, with an option to cut SJ1 if it's necessary to move the chip select to a different pin.  CS, RST and IRQ are still available, but they are on surface pads instead of through-hole.  One thing I didn't keep is the mode selection solder jumpers, but I don't think that's a big loss.  The WIZ5500 will just auto-negotiate the correct speed and duplex settings.

    I unfortunately did not find the space to add a 24AA02E48 chip to solve the issue of having to get your own (or make up your own) MAC address.  It's the same as the Adafruit Ethernet FeatherWing in that respect as well. :)  It's unfortunate the Feather spec doesn't integrate I2C pull-ups on the main board but they are expected to be on the FeatherWings (wrong in my opinion).  Maybe I would have stood a chance if I didn't also have to add the pull-up resistors.  Still, it would be tough no matter what, due to the location of the I2C pins next to the Ethernet jack.

    I managed to keep reasonable isolation between the local power and the remote PoE power.  I'm not going to make any claims about how much voltage it can withstand, but the Ethernet side is completely isolated from local ground and power.

    I have uploaded the schematic so you can see what's going on.  This is the first time I've used the TPS23758 PoE chip in a project so it's entirely possible I screwed something up.  PCBs are on order with JLCPCB, so we'll find out if it actually works after I get the boards and build up some prototypes! :)

  • Rough floorplan

    Patrick Van Oosterwijck11/11/2019 at 21:09 0 comments

    I got the project far enough to come up with a rough floorplan:

    It took quite a bit of fiddling with combining loose parts into resistor and capacitor arrays, reducing resistors to 0402 size and throwing out optional parts, but I think I have enough confidence to say now that this might be possible!

    The design will be isolated, but things are just too tight to be able to keep recommended clearances and make any claims about the isolation voltage.  I will have to go to smaller via sizes and trace widths and clearances than I usually do, but that's alright.  Most board houses nowadays have no issue with 4 mil traces/spacing and 0.2 mm via drills.

View all 10 project logs

Enjoy this project?

Share

Discussions

xqdzn wrote 02/06/2020 at 22:37 point

Man this is very interesting! I've been looking for small microcontroller with PoE and Ethernet ability this whole time. And finally someone make it happen!

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 02/14/2020 at 22:13 point

Thanks!

  Are you sure? yes | no

Prof. Fartsparkle wrote 11/08/2019 at 22:51 point

Oh hey that's great! Glad you got around to it :)

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 11/08/2019 at 23:18 point

Right! It only took more than a year. ;)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates