wESP32: Wired ESP32 with Ethernet and PoE

A low cost ESP32 core board with Ethernet and PoE for convenient "single cable" deployments

Public Chat
Similar projects worth following
The ESP32 is very popular among makers as the brains for various projects. Usually it is connected to the internet with WiFi, but an often overlooked feature of the ESP32 is that it also contains an Ethernet MAC. This project aims to create a hacker friendly ESP32 + Ethernet + PoE core board to make it very easy to apply the power of the ESP32 in new areas such as home automation, factory automation, smart buildings and data centers, where the use PoE provides major advantages in installation and maintenance.

Due to the high power consumption of WiFi, most ESP32 based systems already require wired power. Since you already need a wire, why not provide power and connectivity through a single wire and bypass deployment hassles associated with WiFi credentials and RF performance in hard-to-reach locations?

Plus the high power available with PoE makes it possible to not only make ESP32 based sensor nodes, but to create smart network-connected actuators as well!

I just completed an application-specific ESP32 based PoE board for a customer, and it got me thinking: how much interest would there be in a generic ESP32 PoE core board?

By using PoE, a single cable provides power as well as connectivity, easing deployment headaches for large installations.  PoE can provide up to 12.95 W to a load while PoE+ specifies up to 25.50 W.  Plenty for an ESP32 which takes only a watt or so, making it possible to power other loads.  PoE capable network switches and injectors are also becoming quite common and have come down in price as well.

The nice thing about the ESP32 is that it's low cost and powerful, and provides WiFi and Bluetooth in addition to Ethernet.  So even if a deployment would be mostly Ethernet and PoE based, it would still be possible to connect a node with WiFi powered from another source if necessary.  Or it could be set up as an access point for other WiFi or Bluetooth LE based sensors.

While it would be nice to support as much power as possible, previous experience has taught me that high power opens all sorts of cans of worms related to heat dissipation and EMI.  So it seems prudent to not start at the highest power levels possible.  Some potential users also showed interest in compact, very low power systems, but there are plenty who were excited about the idea of having a decent amount of power available.  So I decided to take the middle road and do a 12.95W PoE class 3 design to start with.

The ability to use local power instead of PoE is a nice feature, but also adds complexity and cost.  The problem is that PoE uses 48V nominal to reduce wiring losses, but commonly available wall warts use lower voltages for safety.  Supporting both would require the circuit to support for a wide input voltage range making things more complex.

So I settled for the following solutions: local power can provided either by adding a PoE injector, or through the (optional) USB port.  Of course, from the USB port, only 5V will be available.

Talking about the USB port, several potential users expressed the opinion to not burden every board with something that would likely only be used during once during programming and never again after that.  I agree, so I made the USB programming/terminal port an optional module.

Other than those concerns, I want this module to be fully isolated (to prevent issues with long cabling), full featured (Ethernet, WiFi, Bluetooth LE, many ESP32 pins exposed), low cost and small.


Complete schematic of wESP32 core module

Adobe Portable Document Format - 45.40 kB - 04/20/2018 at 18:30



Schematic of ESP32 programming submodule

Adobe Portable Document Format - 19.41 kB - 04/20/2018 at 18:30



Ethernet Phy with RMII interface

Adobe Portable Document Format - 1.02 MB - 04/18/2018 at 18:20



USB UART bridge for programming the ESP32

Adobe Portable Document Format - 953.87 kB - 03/19/2018 at 18:17



Pulse Electronics EP13 transformers, I'm interested in the PA2467NL specifically

Adobe Portable Document Format - 1.92 MB - 03/19/2018 at 18:15


View all 7 files

  • Crowd Supply campaign ending!

    Patrick Van Oosterwijck11/12/2018 at 17:51 0 comments

    The Crowd Supply campaign has been going very well and will be ending soon, so if you haven't put in an order yet and you want one, now is the time! :)

    I've been putting quite a bit of work into the software side of things during the campaign, to make it as easy as possible for anyone wanting to design something with this to get started.

    First of all, there's now a web site at  It contains information on the hardware and on software development in different environments.  Most importantly, it contains a link to the Product Brief, which is pretty much the go-to for all detailed information.

    While the web site contains guidance on how to use the wESP32 with different development environments, there is now also a wESP32 demo code repository on Github, which contains full projects to get you started!  At the time of writing it has the iperf Ethernet IDF code I used to get the performance numbers mentioned in my project logs, an ESP32-Arduino example to control a display from a web server, two simple MicroPython examples to control an LED light, one from a web server and one using, and a Mongoose OS demo that allows you to control an LED light very simply from an automatically generated web app!

    If you take a look at these examples, you can see that most of them are quite simple and don't require much code at all.  For instance, here's the LED control from code:

    import machine
    import time
    import urequests
    # Initialize light PWM, flash for 1/4 sec on boot
    led = machine.Pin(23, machine.Pin.OUT)
    ledpwm = machine.PWM(led)
    # Get the ESP32 unique ID as a string
    uid = ''.join(['{:02x}'.format(x) for x in machine.unique_id()])
    # Check every two seconds to get and update the light level
    while True:
        light_level = int(urequests.get(
        print ("Light level {}".format(light_level))

    So if you thought the wESP32 was interesting but would be too hard to get started with, think again!  There are still a couple of days left to change your mind and get your own wESP32 by backing my campaign! :)

  • Crowd Supply campaign now live

    Patrick Van Oosterwijck10/05/2018 at 21:40 0 comments

    The wESP32 Crowd Supply campaign is now live!  I have parts for about 230 units in-house, so if you want one before the end of the year, at the time of writing there are less than 100 of those left!  If you order later, they will ship from a new batch which is scheduled for February 2019.

    As I mentioned in the first campaign update on CS, I received the production PCB panels for the first batch:

    I'm really pleased with how these turned out, my wasp is finally black and yellow as it should be. :)

  • Crowd Supply pre-campaign page live

    Patrick Van Oosterwijck09/05/2018 at 00:17 0 comments

    The wESP32 Crowd Supply pre-campaign page is now live!

    Check it out and sign up if you want to be notified when the campaign goes live!  There will be some early bird specials so signing up may land you a special deal. :)

  • Coming to Crowd Supply!

    Patrick Van Oosterwijck08/31/2018 at 18:43 0 comments

    The wESP32 is coming to Crowd Supply!  After seeing how successful our #LiFePO4wered/Pi+ campaign was, it made sense to repeat the same thing for the wESP32.  I hope to have the campaign up very soon now so you can start ordering!

    I've been very busy the past week with ordering boards, ordering components, and coming up with marketing materials.  A campaign video is in the works, and we need demos to show off some cool stuff you can do with the wESP32.  One simple idea was to make a "remote status display" you can send messages to:

    You'd probably want a bigger screen for the real deal, but is conveys the idea. :)

    @martinschki had a good question in the comments: "How much heat do they emit under a low power application?"  I've been doing tests and taking thermal pictures at high load, but I never thought of doing it for low loads!  And in applications such as his where things get built into a wall this is important.  So here's a thermal image under low load, running the demo shown above:

    So it looks like the hottest thing on the board is the Ethernet phy chip.  At 51°C I don't expect any problems for having it in a wall.  But if you're going to use this to build an environmental sensor, you definitely need to keep this heat in mind when you design your device or your readings will be way off!

  • Final performance checks

    Patrick Van Oosterwijck08/21/2018 at 18:19 0 comments

    I had left off my data performance testing last time wondering why the iperf UDP data rate was so low.  Well, @aenertia on Twitter gave me a hint: you need to specify the amount of bandwidth you want to test on the client side, otherwise the UDP test defaults to 1 Mbit/s!  So, just an average case of operator error. :)  The iperf on ESP32 example code is too simple and doesn't provide / need this option, and I haven't played enough with this kind of stuff before to know things like that.

    Here are the results for UDP when the wESP32 is the client (outgoing traffic):

    Around 70 Mbit /s, nice!

    So to test server, I used the following command on the client:

    iperf -c -i 3 -t 60 -u -b 100m

     This sets the target bendwidth to 100 MBit/s.

    Here are the results for UDP when the wESP32 is the server (incoming traffic):

    Wow, >90 Mbit/s!  That's close to the theoretical maximum!

    Now I'm pretty sure that from the moment the ESP32 would start to do anything with this data other than throw it away, the data rate would go down, but it's still nice to see that the Ethernet data system as implemented on the wESP32 performs very well.

    One last thing left on my list to validate the design was to test power performance when the 5V power option is selected by bridging the solder jumper.  As mentioned before, the whole power system is optimized for 12V power, and the 5V option was a little bit of an afterthought but it could be useful to many people.  So how does it do?

    In my first test I was really pushing it:

    Trying to push >2A through a power path that was designed for 1A: not a good idea.  That poor diode was frying, but it lived.  So, intermittent 10W may be possible at 5V, but don't run it like this continuously.

    Here's a more moderate test:

    That's better.  At 6W output (1.2A), the diode temperature isn't so bad.  Still, when running at 5V, your continuous average load should probably be kept below 5W.

    These results are fine though.  If you need high power, use 12V.  It keeps the currents much more reasonable.  If you really need high power at 5V, add your own buck converter.  The on-board option for 5V will likely still be very useful for the majority of people who need 5V in their system though.  5V sensors, keypads, displays, etc. usually don't need that much power.

  • More data performance

    Patrick Van Oosterwijck08/19/2018 at 05:14 3 comments

    After I posted the previous log, I kept working on trying to figure out the data rate figures, the worrying one being iperf performance when the wESP32 was the server, which was really poor.

    Taking a step back, the reason I was doing these tests in the first place was to validate the hardware.  Before I go to production, I need to have confidence that the design is sound, and in the case of this test, that there aren't any circuit or layout issues that are making the signal path performance poor, such as interference from the PoE power system or impedance mismatches causing reflections and affecting the signal to noise ratio.  Such issues would result in high packet loss, making retransmission necessary, which in turn is observed by poor data rates.

    So from the previous tests, it looked like the outgoing signal path had been validated as working well (iperf client), but the incoming signal path was suspect (iperf server).  So I started looking at the layout to see if there was anything obviously different between the incoming and outgoing signal paths.  Not really, both the TXP/TXN and RXP/RXN were laid out as impedance matched differential pairs.  In the picture below, you can see them as the 4 fatter traces under the "Wired ESP32 with PoE" writing:

    While I was perusing the LAN8720A phy datasheet to see which pair was suspect, I looked at the "Architectural Overview" block diagram on page 5, and I noticed something I had forgotten: that this chip implements "Auto-MDIX", a feature that automatically switches the TXP/TXN and RXP/RXN pairs as required to work correctly with either straight or crossover Ethernet cables.

    This gave me an idea: if I used a crossover cable, the incoming and outgoing data would switch on which differential pairs they were travelling, and the phy would internally switch them back so things would still work.  If the problem moved from incoming to outgoing when I did this, then I'd know one of the data pairs was performing poorly.  If nothing changed, and the performance on the outgoing data test was still good, I'd know both data pairs were performing well.

    After locating a crossover cable, I ran the test, and the results were identical to the ones from the test with the straight cable.  This means both data pairs are performing equally well and the data path is sound!  Yay! :)

    So, the question remained: why was the iperf server test working so poorly?  Even though I had pretty much validated the hardware, this still bugged me so I kept trying to see if I could figure out the issue.  I decided to play with some of the settings offered in 'make menuconfig'.  In the process of doing this, at some point I got the client performance to >80 Mbit/s, but the server performance remained poor.  Eventually I did find something that made the TCP test work: the option "CONFIG_EMAC_L2_TO_L3_RX_BUF_MODE".

    The docs explain that "when Ethernet MAC doesn’t have any unused buffers left, it will drop incoming packets (flow control may help with this problem, to some extent)".  Still, the docs recommend to keep this turned off if unsure, because it involves copying data instead of passing pointers, which decreases performance.  Still, the iperf test was apparently running into the problem that the MAC didn't have buffers left, because turning it on made a big difference.  Here are the results of the iperf client test with this config:

    And here are the results of the server test, which now performs well:

    That's when testing with TCP.  Oddly, the UDP server test still performs very poorly: I only get around 1 Mbps.

    Obviously, this is some other configuration issue.  Since TCP was working well, I called it a day.

    Overall, I'm very happy with the performance of these first prototypes: the power output beats my expectations and the spec, the attainable data rate is very good and beats my expectations as well.  With these prototypes working as well...

    Read more »

  • Data performance

    Patrick Van Oosterwijck08/17/2018 at 18:41 0 comments

    After confirming the PoE power subsystem performance, I wanted to make sure that the data path was sound as well.  To do this, I needed some performance test.  The ESP-IDF contains an iperf example for WiFi, but there isn't any for Ethernet.  So I decided to try and hack the Ethernet example and the WiFi iperf together.  It's messy and ugly, but eventually I got it to work.  Here are the test results:

    Around 63-64 Mbit/s, not too shabby for a little chip!  Of course I don't really have much to compare to.  Anyone have any numbers on how much speed can be expected from an Ethernet connected ESP32?

    The first test was in TCP mode.  Then I tried the same thing in UDP mode:

    Wow, more than 70 Mbit/s, even better!

    Then I decided to try the ESP32 as a server instead of client:

    Whaaa?  That's just weird, something seems wrong.  Anyone have any idea why this would happen?

  • Initial test results

    Patrick Van Oosterwijck08/02/2018 at 03:16 1 comment

    Initial test results are in!

    I used my electronic load to see if the wESP32 prototypes would achieve my target of 12.95W output power to meet the 802.3at Type 1 PoE specification.  Here's my setup:

    Yes, you are seeing that correctly on the display of the electronic load: 13.5W!  What's more, I kept it running like this for a couple of hours and it was stable!  No over current or thermal shutdown.  And this is without any heat sink attached to the mounting hole!  I never expected I would get full target power without extra heat sinking.

    The hot spots are as expected the Si3404A PoE power converter chip and the secondary side Schottky rectifying diode.  The diode is hot, but it's within acceptable limits:

    The power chip is getting much hotter, not enough to trigger over temperature protection apparently, but too hot to run like this for a long time:

    Although it works, I would not recommend running at full power without any heat sinking.  So how much difference does connecting a heat sink to the mounting hole actually make?  Let's find out:

    It may be noted that I'm not trying very hard here to provide an optimal heat sink.  I'm just using a flat piece of aluminum with a stand-off screwed into it, screwed to the mounting hole.  No thermal grease is used.

    As you can see, I decided to really push it and bumped power up to 14.7W.  This was stable with the extra heat sinking.  Of course, the diode got a little hotter now:

    Still perfectly acceptable.  The power chip on the other hand is cooler now, because the heat sink is doing its job pulling heat away from the chip:

    I decided that to compare apples to apples, I better reduce the output load to the same 13.5W as before so I could see how much difference in temperature the heat sink actually makes:

    That's 25°C cooler, at an acceptable temperature while running at a load that's higher than demanded by the spec.  I call that good enough. :)

    An interesting detail in the latter thermal images: the resolution is good enough to see a couple more small hot spots: one by current sense resistor R20 and one by resistor R10 of the RCD clamp.  Both are normal and expected: the current sense resistor senses the current through the primary winding and will dissipate around 0.1W under high load, while the RCD clamp is there to dissipate energy from self-inductance of the primary flyback winding, to prevent this energy from resonating and producing large (noisy and potentially damaging) voltage spikes.

    It should be noted that in all these tests the actual load is a little higher than what I see on the electronic load display because the 3.3V buck converter, ESP32 and Ethernet Phy consume some power as well.  But I decided to ignore it for these tests since it's less than 0.5W or so.

    So how does the flyback converter's output power look?  How much noise is on it under various loads?  I had planned to show some scope traces, but I decided against it because they were very boring: just a flat line. :)  That's excellent!  Even under the highest load, the V+ power bus looks very clean.  I haven't had this design tested for EMI but if/when I do, it looks like it may be fine.

    Very happy with these results.  Next, I need to check what happens when 5V output is selected, and try to figure out what's wrong with the two prototypes that aren't fully functional, plus build some more prototypes for the people who are waiting to buy them for their own testing.

  • Prototypes... built and tested!

    Patrick Van Oosterwijck07/28/2018 at 04:30 5 comments

    I found time to build four wESP32 prototypes yesterday!  Here are some shots taken during the (manual) assembly process.

    Stencil with board ready to be pasted:

    Boards with solder paste, ready for assembly:

    Most components placed:

    After reflow:

    All boards needed some touch up, my solder pasting was kinda messy with the frameless stencil and the old paste, so there was some bridging on the QFNs that needed to be fixed up.

    Then after I completed the assembly of the first prototype I plugged in the PoE Ethernet jack and immediately measured 11.4V on the V+ rail!  Yay, what a relief! :)  The PoE section seems to be immediately operational.  I had some trouble programming the ESP32 using the ESP32-Prog submodule though.  Switched to a different prototype I finished up, and on that one I could program the ESP32 right away!  So I loaded the ESP-IDF Ethernet example and plugged it in:

    Behold, blinking LEDs on the Ethernet jack and a sure sign of success! Checking the serial monitor, I could tell the device was successfully getting an IP address from DHCP as well. :)

    This is what has been verified to work so far on some of these prototypes:

    • PoE produces 11.4V on the V+ rail, and 5.1V when the 5V solder bridge is closed.
    • Buck converter produces 3.3V to power the ESP32 and Phy.
    • Ethernet Phy is operational and communicates with the ESP32, tested to the point of getting an IP address from DHCP.
    • ESP32-Prog submodule and on-board logic manages the EN and IO0 signal correctly to allow programming, serial monitoring and 50MHz EMAC clock to work correctly.

    I have two prototypes where all the above works, a third seems to work but for unknown reason it is not getting an IP address from DHCP, and on the fourth I can't seem to program the ESP32 yet.  Still work to do to get those going but it seems likely these are just assembly issues and not a problem with the design.  Let's hope.

    More testing is still needed to make sure the design is sound:

    • Check the power supplies and see how noisy they are, optimize snubbers and filters in the flyback stage to minimize noise and optimize the EMC.
    • Check how much power can be pulled from the PoE with and without a heat sink attached.  See if we get to 12.95W which is the target for 802.3af (802.3at Type 1).  I hope to get there with a heat sink, but expect a lower maximum when no heat sink is used.
    • Check how much power we can pull when the 5V option is selected.  I'm not expecting to reach 12.95W here, since the flyback is optimized for 12V.
    • Check if we have enough power and good enough signal with really long cables (does anyone know if there is a way to get a signal qualify figure from the phy?).
    • Check how much power is available from the 3.3V rail for the specification.

  • ESP32-Prog prototype

    Patrick Van Oosterwijck07/25/2018 at 23:27 0 comments

    The last three months have been absolutely crazy.  Between vacation, selling a house, buying a house, remodelling 4 bedrooms, moving, visits by family and friends, an audit, and getting the #LiFePO4wered/Pi+ Crowd Supply campaign going, I've had very little time to work on the wESP32 unfortunately.

    So I'm relieved that I finally found some time to relax and work on some electronics!  Here's the result: I built 3 ESP32-Prog prototype modules for the wESP32:

    They are built manually with the hot air rework station so they're a little messy, but they seem to work!  After adding a little patch wire that is.  It's nearly impossible to see, but on the top right corner of the CP2102N, I forgot the connection between pins 7 and 8.  So dumb: Eagle told me clearly there was an air wire left and I completely missed it.

    I tested them by connecting them to my PC and /dev/ttyUSB0 showed up.  Then I ran:

    screen /dev/ttyUSB0 115200

     and when I connected TX to RX, the characters I typed were echoed back.  What I haven't tested yet is whether the EN and IO0 management circuitry works.

    I have all the parts to build wESP32 protos as well, but I'm doing that one the "proper" way with solder paste, a stencil and reflow oven.  Hopefully later this week!

View all 19 project logs

Enjoy this project?



Vipul Garg wrote 12/03/2018 at 14:35 point

Is the hardware is open source, if it is then where i can find pcb files 

  Are you sure? yes | no

kesh27 wrote 10/24/2018 at 18:10 point

How are you hoping production would look after the crowd supply campaign is finished?  I got in early on the campaign for half a dozen to experiment with for campus/dc monitors. If cost and volume numbers are good, we would be interested in 50-100 units and I'm curious how that might look in the new year?

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 10/24/2018 at 18:30 point

I will definitely keep producing these after the campaign.  The campaign is just to get eyeballs and get them in people's hands to start designing, but I'm expecting this to be more of a B2B / bulk product once people have designed something with them and put it in production.

I'm keeping an eye on orders and will soon be starting procurement for the next batch, which I expect could be produced by late December / early 2019.

  Are you sure? yes | no

aloismbutura wrote 09/16/2018 at 14:25 point

I just subscribed to your crowd supply campaign. My slight request is on the footprint. The WROVER and WROOM32 have compatible footprints on a PCB. Check the REV4 of the ESP32 devkit-c. This will allow upgrading of the ESP32 module on the board or even offering the WROVER as a different tier on the campaign due to the larger RAM/SPI flash benefits.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 09/16/2018 at 18:22 point

Unfortunately my layout is really dense to try and keep the board as small as possible, so there's no extra room on my board to accommodate the larger WROVER module.

  Are you sure? yes | no

Emanuele Tessore wrote 09/12/2018 at 16:06 point

Hi there, this is great stuff! I'll use it to convert my light switches to smart switches and eventually drop a bunch of sensors inside and outside my home!

Have you tried any sort of remote programming on this board? for example TFTP or, even better, network boot.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 09/12/2018 at 16:28 point

I've been amazed at what functionality is already available in some of the software frameworks that exist for the ESP32.  That said, I'm more of a hardware guy myself than software or application, so I'm very interested in what OTHERS will be able to cook up with these boards. :)

  Are you sure? yes | no

Emanuele Tessore wrote 09/12/2018 at 17:48 point

Thank you so much for beeing an hardware guy, cause I've tried to wire route a simple flip-flop button debouncer with some bad results :D.

I can't wait to have a couple of these on hand :) First of all I'll try to make a light switch that uses no mains power and comunicats to a central server (something like a Raspberry) where some logic decide the light to be turned on or off... 

I've a proof of concept running on an ATmega328P (Arduino) but I'm stuck on finding a board small enought to be mounted inside the electrical box and with a decent amount of memory and wired network. 

Your board will also save me from wiring all the boxes with a low voltage CC line :) Best of all this board will probably save me from using some (very pricy) KNX devices.

So I'll need a sample of 3 boards for development and if everything on my side works a grater batch (maybe 50 pieces) in something like 6 months... Are you planning to have some future run or make these boards available on demand in reasonably small batches?

Thank you, again :) Cheers

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 09/12/2018 at 18:25 point

Yes, the Crowd Supply campaign is just to get as many boards as possible into the market quickly and to establish demand. Later they will be available for sale through various channels including Tindie.

  Are you sure? yes | no

CLQ wrote 09/07/2018 at 09:33 point

Hi everyone,

It's really an awesome project. 

Have you planned to share the software ? Did you used ISP-EDF or somethong else (ESP-Arduino, so on) ?

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 09/12/2018 at 16:26 point

I hope to have broad software support.  I've tested with ISP-IDF, Arduino, Lua-RTOS-ESP32 and MicroPython up till now.  I have pull requests in to upstream board support in arduino-esp32 ( and Lua-RTOS-ESP32 (  They are very easy merges but up till now they haven't been pulled in yet, so if you can add your voices to those projects to have them pulled in that would be helpful. :)

  Are you sure? yes | no

fabian wrote 09/01/2018 at 17:55 point

ideal for tor server. Plug in bibliotek or other place and increase tor network speed and anonimity

  Are you sure? yes | no

martinschki wrote 08/27/2018 at 18:04 point

Great Project!!

Looking for something like that for a loooong time!!!

I want to use these as room controller with a BME280 and a light sensor. Nothing fancy at all. Just sending sensor data every couple of seconds to a MQTT server.

They will go into a wall so my only concern and also question is: How much heat do they emit under such a low power application?? 

Since the sensors basically cover the hole they are put into it would impact the measurements...


  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/31/2018 at 18:44 point

Thanks Martin!

I quickly did a test under low load and put a thermal image up so you can check it out, it's in this project log:

  Are you sure? yes | no

martinschki wrote 09/20/2018 at 08:53 point

thank you Patrick, looking forward to your campaign 

  Are you sure? yes | no

Sheepinator wrote 08/22/2018 at 03:48 point

Excellent project and something I've been looking after for quite some time.

If you had to, what SoC would you use to get just ethernet and none of the wifi. (Consider an industrial application with RF restrictions.)


  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/31/2018 at 17:40 point

I haven't really given it much thought to be honest, and I tend to spend a lot of time on component selection, so I would take a while to figure it out. :)  I'd probably start by looking at Cortex-M4's and Cortex-M7's from ST and NXP.  Any SoC you would recommend?

  Are you sure? yes | no

Mikhail wrote 08/21/2018 at 07:47 point

Thanks for your great project, Patrick!


Personally I don't like ESP32-WROOM module and do prefer ESP32-PICO-D4  with a 3D antenna for better Wi-Fi connection and lower overall power consumption, but it will make a board a lot more complicated, so that's not an real issue now for PoE solution, just a wish.


As I see now your project is close to prototype completion, so any estimates now for release date and production costs for small quantities? (~100pcs batches after initial evaluation) 

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/21/2018 at 17:41 point

I use the ESP32-WROOM because it has modular FCC certification, which I wouldn't get if I did my own antenna.  Likely the WiFi won't be used on this board in most cases, but I am interested in the Bluetooth functionality as it can make this a useful Bluetooth sensor aggregator / hub.

I have parts for a 240 piece batch on order, and am talking to Crowd Supply to do another campaign like the one I'm running for the #LiFePO4wered/Pi+ right now (

  Are you sure? yes | no

Mikhail wrote 08/21/2018 at 21:41 point

Don't really care about certification - still need to recertify everything for production devices, at least where I am (Russia).

OK, count on me as very interested for samples and maybe larger quantities. It will depend on price and performance vs our current prototypes that are made using  PoE splitter and Ethernet module add-ons.

Personally I do like using Bluetooth for connecting speakers to ESP32. (just sharing an idea)

  Are you sure? yes | no

John wrote 08/21/2018 at 07:13 point

This is really awesome, Patrick! I am looking forward to get a few of these boards when they are available!  I'm trying to learn more about how PoE works and was wondering why you decided to use a RJ45 jack with a bridge rectifier and an external transformer over an RJ45 jack with a built in transformer and an external bridge rectifier. Excuse my noob-question on this. Still at baby steps in understanding PoE. Thanks

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/21/2018 at 17:35 point

Thanks John!  The RJ45 jack does contain the Ethernet magnetics ("transformers") for the data path.  The external transformer is for PoE power conversion only, and as far as I'm aware, nobody produces an RJ45 jack with this power transformer integrated.  It wouldn't make sense to do this since a lot of circuitry is involved (all the circuitry between the RJ45 and flyback transformer).

The jack I use integrates the PoE diode bridges in addition to the Ethernet magnetics, which is nice because these bridges tend to take up a lot of PCB space.

  Are you sure? yes | no

John wrote 08/22/2018 at 13:53 point

Thanks for the reply. Ah! Now I understand. I got confused about the power transformer and thought this was the ethernet magnetics.

Follow up question on ethernet jacks. Did I get this correct that the jack you use uses all 4 pairs for power, and two pairs are data? If so, the PHY only uses one pair for data? I am trying to understand how some hobbyists may just split open an RJ45 cable and add 12v to it, and what that might result in. Sorry again for the noob-question.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/22/2018 at 16:42 point

The phy uses two pairs for data.  For IEEE 802.3at compliant PoE, the power can either be on the same pairs as the data, or it can be on the spare pairs, so the Ethernet jack contains two diode bridges to cover both cases.

The DIY 12V or "passive PoE" are not standard compliant and not supported by the wESP32.

  Are you sure? yes | no

Prof. Fartsparkle wrote 08/19/2018 at 22:22 point

Great stuff! I really miss Ethernet with all these modern MCUs, even if they support it natively, barely anyone makes boards that support it.
Will you sell it afterwards? This would definitely be interesting for some work projects.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/20/2018 at 05:24 point

Yes!  As all major systems have been checked out and I'm very satisfied with the performance of the design, getting to production is being worked on right now! :)

  Are you sure? yes | no

Prof. Fartsparkle wrote 08/20/2018 at 12:22 point

Great! Do you have a price target yet?

  Are you sure? yes | no

Bub Rascal wrote 08/17/2018 at 04:16 point

Hey Patrick, that's an awesome project! But did you possibly place C11/TC/RC on the wrong side of the bead? In the datasheet it's connected to the VDD1A/VDD2A side instead of the 3.3V side. Cheers!

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/20/2018 at 05:23 point

I moved it to the other side of the bead to make my layout easier. :)

Would it be "better" if this connection was on the other side of the bead?  Maybe.  Then you have to define "better".  Is the bead there to give the Ethernet signal path a cleaner power source, or to prevent switching noise from the Ethernet to get back to the 3V supply?  I don't know which they had in mind, probably both.  In the end, engineering is about compromises, and I would have had difficulties with my layout had I made these connections after the bead, so I decided to connect them to 3.3V instead.

The proof is in the pudding as they say and in this case "better" is probably just a matter of performance.  With 63 Mbit/s up and 55 Mbit/s down, I'm perfectly happy with the performance as it is. :)

  Are you sure? yes | no

K.C. Lee wrote 08/20/2018 at 12:59 point

You want to prevent digital noise getting into a long piece of Ethernet cable which can act as an antenna to the outside world.  i.e. keep the power clean at the Ethernet side.  So a LC filter would have the caps etc at the receiving side of the bead,  At least that's the way I would do it even if it means that I have to rip up all my nets and do another rounds of routing.  I don't settle at something that "works".

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/20/2018 at 17:03 point

I agree 100%, but please check in the schematic what he's talking about first.  He's talking about the supply to the center taps of the secondary side signal transformers.

The power system connected to the primary (cable) side does have the recommended filter circuitry at the input (L3, L5, C26, C27).

  Are you sure? yes | no

SK wrote 07/29/2018 at 11:33 point

Hey there, very interesting project.
Olimex recently announced a similar board - ESP32-POE. There is no confirmation yet, but I am guessing they will release it as an OSHW design (all their other ESP32 boards are OSHW):

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/16/2018 at 20:09 point

Yeah, I saw that, and at first I thought: "With competition from such a known player I might as well shelve this project".  But then I looked at the info that was available and noticed:

- There's no flyback transformer which means their design provides no isolation as required by the IEEE 802.3af/at PoE specification.  Prototyping will be fine but actual installations with long wire runs in buildings will likely be troublesome.

- I haven't seen any specification on available output power.  The size of the inductor makes me think 12.95W as specified for IEEE 802.3at Type 1 is not attainable.

- It uses the CH340 for programming which is really undesirable.  My friend's Macbook got bricked by trying to install the driver for this device.

All of this (especially the first point) puts their device firmly in the hobbyist category.  I'm under no illusion that this still represents stiff competition as their price will be better than mine and most people will hear about theirs and not mine, but I'm hoping there will be a niche for me when people are looking at professional deployments that are IEEE 802.3at compliant.

  Are you sure? yes | no

hennie.tempelman wrote 07/07/2018 at 21:22 point

Hi Patrick, really great project.

For years I have been using the Propox Wiznet module with ATMEGA128A and Ethernet. Very much like the AVR-Studio. I work in industrial automation (gas turbines); I even implemented the Siemens S7 protocol on my AVR and now can do great stuff such as native peer comms and talking to a DDE/OPC server. This gives me great 'eyes' to my projects.

But time moves on. Got myself an ARM board (Atmel SAM D20) because everybody says you should be 32 bit; with this I would be able to use Studio for that too. But I couldn't really see the benefit of moving to 32 bit 'just because', so it grinded to a halt.

Then recently I did get kind of stuck. I want to make a weather station (based on a recent Elektor design), but with my good-old Wiznet. But pulling yet another Ethernet cable... A Wifi add-on for the ATMEGA seems expensive and clumsy. And the ESP32 has it all out of the box, and so much more. And oh-yes, it is 32 bit and amazing clock speeds - thus future proof. And cheap.

But... Wifi is fine for a weather station. But not for important stuff such as domotics, machine automation and what else. But with the standard ESP32 solutions on the market I was now loosing my Ethernet. Except for some poor Olimex designs (too bulky for integration).

Then I found your project. I think it is almost perfect, and I totally agree with all your considerations. I think the initial price you have in mind is just fine; I pay a similar price for the Propox module and that never stopped me.

So when you have some for sale; I'd be happy to buy a few to try and use in my next projects.

I have a question: Can the module also be powered WITHOUT POE? (i.e. will it merrily accept 3.3 V or 5 V on the power pins?) I guess yes, but asking to be sure.

I also have another question (to you or others): would I be able to use my favoured AVR-Studio still with an ESP32 signature file or so? If not, what similar environment would you recommend. Whilst I do a lot with AVRs, I never had a go at Arduinos (and don't really want to either), so I am not familiar with that environment .

And 'if' you consider a redesign, then I'd suggest to make a DIP-style pinning. This is easier for use on a breadboard (as double pin rows cause a short). And on a final product you achieve mounting stability without any need for screws and such. Just check the Propox module (and others) as example.

Thanks - Hennie.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 07/28/2018 at 03:15 point

Hello Hennie,

Thanks for your kind words! :)  Here are some answers to your questions:

- Yes, you can supply power to the V+ pin or, if the ESP32-Prog module is installed, it can power the ESP32 over USB.

- I have no idea if you can program an ESP32 from AVR Studio, I would assume not but I don't know how flexible it is.  Not a fan of Arduino myself, I consider it yesterday's cool way of doing things and behind the times.  For C you can do ESP-IDF and MongooseOS, Espruino and MicroPython work well too for higher level development.  PlatformIO provides a nice environment as well.  Anything's better than Arduino. ;)

- DIP-style: I was considering this at some point but someone else said dual row header was what they preferred and it was the only feedback I got at the time.  In hindsight, it was the better option as well to be able to do the really dense layout to keep it small.  There are ribbon cable header to breadboard adapters in the market that should work.  I agree prototyping concerns are important, and there should be solutions provided even if they take some extra parts, but this project is mostly production optimized for people who want to use it in the field.

  Are you sure? yes | no

Giovanni wrote 06/10/2018 at 23:27 point

Hi Patrick, great project! 

Quick question - will there be 5V available from the board along with 3.3V for powering external components? That would be very handy!

BTW Did you think of starting a small Kickstarter or Indiegogo campaign? I know this is quite a niche project so perhaps the audience will be limited but on the other hand you may not need that much money to complete it either.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 06/11/2018 at 11:23 point

By default there is 12V and 3.3V available.  But I included a solder jumper to switch from 12V to 5V on the power output.  Total output power will likely be less when configured to 5V compared to 12V since the flyback turns ratio is optimized for 12V.  You can of course do your own conversion from 12V to 5V as well.

Doing a campaign is definitely on the table.  First need to confirm everything works though. :)

  Are you sure? yes | no

Andreas wrote 05/26/2018 at 09:25 point

Hi Patrick, - I like your thoughts on PoE with ESP32 because I am looking for a way to replace a working door lock system for 30 doors in one building that I designed in about 2008 (together with an EE) that still works well but so far, it's a prototype. Technology has moved on since then.

I am choosing the ESP32 now because it seems to be the only small, affordable microcontroller out there capable of a decent encryption (AES etc.). Wifi does not make sense for me because it can be blocked and might be unreliable. What I'd need as an adaption of the WESP32 that connects a numerical keyboard (we can manufacture that here, inox steel for outside), three LEDs and a relay to open a door opener magnet. The 12 V version of PoE seems fine to me, but I'd have more questions. Would you be available for some questions? I could not find an email address so far. My website is and I am thinking of sponsoring your development of the WESP32 if this is still on the table :) - and then we could talk about paid modifications..


  Are you sure? yes | no

Patrick Van Oosterwijck wrote 06/11/2018 at 09:57 point

Hello Andreas,

Sorry I didn't see this sooner, seems to be very flaky about sending comment notifications.  Sometimes it does, sometimes it doesn't.  I haven't found any logic in it yet.

Your application looks perfect for something like this!  We can discuss your questions over email and I am certainly interested in your sponsoring offer! :)  I'll shoot you an email.


  Are you sure? yes | no

bbz wrote 05/18/2018 at 20:33 point

You mention the prize funding a lot, how much is it? I would have thought there'd be enough interest in this to cover it.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 05/21/2018 at 04:16 point

I think once it's ready to sell, I'll be OK, but getting there would have been easier/quicker with the Hackaday funding ($1000), that's all.  Instead of having funds to live off while I work on this and pay for prototypes etc, I have to work on other (paying) projects to live off and fund the prototypes, so getting this to market will be slower.

Plus more eyeballs of course when you're a finalist.  You can have a great project but if no one knows about it, it won't sell enough to matter.  Having people find out about your product is always the biggest hurdle to overcome.

  Are you sure? yes | no

kesh27 wrote 05/14/2018 at 20:44 point

Looking forward to a prototype. This would make a great little data closet monitor with something like a BME280 sensor.

  Are you sure? yes | no

Netoperz wrote 05/12/2018 at 16:42 point

There is one most important thing ever , level shifters.

I have build a automation system for building on esp32 and it is working over year now, i have used many type of boards from many brands, and i have made some my own designs.

There always you face 3 problems

1. power supply (solved here as it is POE)

3. interfaces to the external modules/devices and those never use 3,3v ttl level, most automation things use 5v (keypads, locks readers...) so there always  is a must to add additional level shifter (nad this solution does not solve the problem)

4. size - in most cases you would like to put that board in the wall mount (just lunder the power socket or switch, or just in that hole as it is esy to buy them and put on building project to make them)

So if this board want's to be something "new" it must have POE and level shifting, board should have uSD card socket for storage, it is better for firmware updates or database processing.

I would say that OLIMEX

have made the perfect one, but it lacks poe and level shifting.

If you will make something like that but with poe and level shifting you may sell them a lot, i would order a few hundreds for my projects.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 05/18/2018 at 15:09 point

Hi, thanks for your comment!

I disagree on integrating level shifters on a generic core board like this though.  Sure, _your_ application needs them, but there are many that don't.  Most new environmental sensors are 3.3V, just ask all the people still stuck in 5V Arduino land that need to level shift day and night.  If the I/O signals were level shifted to 5V by default, many people would have to level shift back to 3.3V, which would be silly of course.  I consider level shifters firmly in the "application specific" realm.  You likely need specific connectors for your keypad, lock reader etc, anyway.  So if you use something like this, your level shifters can be on a little add-on PCB that converts from the generic ESP32 I/O header to your application specific connectors.  Selectable 5V or 12V is available on the I/O header to make this easy.

The current size would fit in a wall mount I think (75 x 40mm).  If your application specific adapter board folds back over the ESP32 area, you can have a nice compact solution since it would sit next to the tall components on the other end of the wESP32 board.

I though about integrating an SD card slot but decided against it.  The SD card is considered application specific as well, but I made sure to have all the needed I/Os available on the header as I understand it would be of interest to many people.  It would have taken up a ton of space and made the board significantly larger though, so I favoured size.

I'm happy with this being something "new" as it is, since I don't think there are any PoE ESP32 boards on the market, and definitely not any there are this small.

  Are you sure? yes | no

icodk wrote 05/24/2018 at 16:08 point

I agree with your priorities. Keep it as generic as possible

  Are you sure? yes | no

Prakhar Birla wrote 05/04/2018 at 02:56 point

Great project! I hope you get the prototypes this month. 

  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