Close
0%
0%

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
Starting from
$59.00
xorbit has 1700 orders / 65reviews
Ships from United States of America
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.

wESP32-7-CCBYSA.pdf

Schematic of wESP32 rev 7 with RTL8201 Ethernet PHY

Adobe Portable Document Format - 43.26 kB - 01/14/2022 at 18:15

Preview
Download

wESP32-3-mechanical.pdf

Mechanical drawing of the wESP32 rev 3

Adobe Portable Document Format - 88.38 kB - 01/07/2020 at 16:37

Preview
Download

wESP32-Prog-1-Eagle.zip

Eagle CAD source files of the wESP32-Prog programming submodule

Zip Archive - 50.43 kB - 10/07/2019 at 14:41

Download

wESP32-Prog-1.pdf

Schematic of wESP32-Prog programming submodule

Adobe Portable Document Format - 19.49 kB - 10/07/2019 at 14:41

Preview
Download

wESP32-3.pdf

Schematic of wESP32 rev 3 with PMS150C to manage PHY reset

Adobe Portable Document Format - 43.55 kB - 03/19/2019 at 23:10

Preview
Download

View all 11 files

  • Revision 7 is available for sale!

    Patrick Van Oosterwijck09/30/2021 at 16:10 1 comment

    A little late posting here, but just a heads-up that revision 7 has arrived and is making its way to various distribution channels!

    New 4-layer PCB, much more decoupling capacitance on-board, RTL8201FI Ethernet Phy and now 16 MB of flash!

    Tindie: https://www.tindie.com/products/silicognition/wesp32/

    Mouser: https://www.mouser.com/ProductDetail/Silicognition/CS-WESP-04?qs=sGAEpiMZZMu3sxpa5v1qrriU3DaWTQdbHa4MxnML6FE%3D

    Amazon: https://www.amazon.com/Silicognition-wESP32-Isolated-Ethernet-802-3at/dp/B084RV91NQ/

    Note that the lead time shown on Mouser is bogus, they had 100 units shipped to them already.  Should ship much sooner than the lead time indicates.

  • Documentation update

    Patrick Van Oosterwijck09/13/2021 at 17:59 0 comments

    A quick heads-up that I finally found the time to update the wESP32.com website with new information related to the changes in revision 7 such as 16 MB of flash and RTL8201 Ethernet PHY.  The product brief has also been updated, make sure to check the code examples to see the changes you may need to make to your software for this revision!

  • Kingtop finished production

    Patrick Van Oosterwijck09/09/2021 at 16:30 0 comments

    A quick progress report.  MicroPython 1.17 dropped on September 2 2021 which meant that I finally had an officially released binary with support for the new wESP32 with 16 MB flash.

    To remove the biggest bottleneck in production called "me" from the equation as much as possible, I had my CM Kingtop build a fixture so they could program and test them, instead of me still having to do that with every board.  They built a nice fixture:

    Much better looking than my fixture hacked together from two perf boards. ;)  That worked, but hurt your hand when running too many boards.  Big improvement.

    Kingtop finished populating the through-hole parts and programmed and tested all boards:

    They reported two boards that failed on initial test, but they were able to correct the problem.  So an initial failure rate of 0.2%, and 0% after rework, that speaks very well to their build quality and processes.  Believe me, I've seen much much worse!

    They are ready to ship them now and it's still looking good for getting stock mid-September.

    Now I only have to harass Mouser some more to try and get them to send me a PO for the new part numbers generated for this revision, after begging for months already.  But why do something ahead of time when you can do it when it's too late, right? 🙄

  • Revision 7 production progress

    Patrick Van Oosterwijck08/20/2021 at 22:00 1 comment

    After waiting for four months since I ordered them, Mouser finally shipped the SI3404A PoE chip to my CM, so they have started production.  I received this picture of the new PCBs:

    Looking good.  I think there shouldn't be confusion about which PHY this uses, since I have it in pretty big letters on the bottom.  Last night, I received this picture with surface mount components mounted:

    Nice progress!  You can see the new RTL8201FI Ethernet PHYs and the ESP32-WROOM-32E module with 16 MB of flash.

    Meanwhile, I have also managed to get a custom board config merged into upstream MicroPython so you can actually make use of all that flash memory!  Up till now, I used the generic ESP32 images but they are made to use only 4 MB of flash.  The flash memory will be partitioned with two nice 2.4 MB OTA partitions so we should be safe for a while as MicroPython keeps growing, and a nice 11 MB of flash will be available for the MicroPython file system!  I'm hoping that version 1.17 will be released soon so I can give an official release to my CM to program in to the boards.  As usual, the boards will also come with a custom boot.py file that will set up the LAN for you.  So if you use the built-in MicroPython, the change to a different PHY chip will be completely transparent.

    I also ran some more performance testing and compared performance of the old LAN7820AI with the new RTL8201FI using the latest IDF's ethernet iperf example.  It looks like the LAN8720AI is marginally faster with UDP, while the RTL8201FI is marginally faster with TCP.  Overall, performance seems to be just fine.  The following numbers are approximate:

    LAN8720AIRTL8201FI
    iperf UDP ESP32 serving
    88 Mbit/s
    83 Mbit/s
    iperf UDP ESP32 client
    61 Mbit/s
    60 Mbit/s
    iperf TCP ESP32 serving
    23 Mbit/s
    25 Mbit/s
    iperf TCP ESP32 client
    27 Mbit/s
    30 Mbit/s

  • Bye bye LAN8720AI, hello RTL8201FI

    Patrick Van Oosterwijck05/27/2021 at 22:49 3 comments

    It had come to my attention that some customers had problems that some of their boards would stop working.  When they returned them and I did a postmortem, it was always the LAN8720AI Ethernet PHY that had died.

    Eventually I was able to recreate a setup that would reliably kill the LAN8720AI.  If I had a wESP32 connected to a particular PoE switch, with the USB programmer connected to a particular laptop, the chip would die when plugging in the Ethernet jack.  So I set out to try and determine root cause and find a solution.

    Doing some measurements on what exactly happened when plugging in the Ethernet using a battery powered oscilloscope, I could see some spikes occur on the 3.3V supply and ground when the cable was plugged in.  My theory was that maybe the charges on the various EMI caps connecting primary to secondary in the PoE switch power supply, the laptop power supply and the wESP32 would redistribute on connection and cause ground bounce that would for a very short time expose the LAN8720AI to out of spec voltages.

    Now doing these kinds of measurements, you're never really sure about what you're seeing, what's real and what's just a measurement artifact.  So I wasn't really sure, but it was something to go after.  I would try to improve supply filtering, add TVSes for ESD protection on the supply and signal pairs, and add filtering in the ground connection between the EMI cap and the circuit ground.

    I first changed supply filter caps on an existing board.  I tried larger bulk caps, and smaller close-to-the-pin caps for better response to high frequency spikes.  Didn't help.  I ordered TVSes, and added one to the 3.3V supply and filtered analog PHY supply.  No difference.

    I decided to create a new, 4-layer board layout with footprint for ESD protection on the Ethernet differential pairs, the supply, and a differential filter that would including filtering ground spikes that might be coming through the PoE supply's EMI cap.  I went to 4-layer with a 3.3V power plane adjacent to GND through 0.1 mm prepreg to provide improved HF power supply filtering.

    Here's the prototype:

    Here's the ESD protection chip I added to the data pairs, the little chip above the wasp:

    Aaaaand it didn't help squat. 😠  The PHY died just the same as before.

    Now what?  Stock was running low, and I really would rather not make another 1000 potentially troublesome boards that might die in some setups.  My goal is for the wESP32 to be powerful and reliable, able to take whatever you can throw at it.  Dying when connected to certain equipment just won't do.  I've only had a few customers complain about it, usually in some situation where there's external power, so it doesn't seem to be a widespread problem.  But still, I don't find it acceptable.

    I did some investigating, and found that in the years since the wESP32 was first released, the ESP-IDF has come to support more PHY chips.  It looks like IDF 4.x added more options, and the ESP32 Arduino core also already supports them.  In the mean time, MicroPython has dropped the IDF 3.x based images that supported Ethernet, but support may be coming in the IDF 4.x based images.  So, this opened possibilities.  IDF, Arduino and MicroPython support are the most important for me, other software is likely to follow as it gets migrated from IDF 3.x to IDF 4.x.

    I had tried to avoid changing PHY chips because I don't like forcing customers to have to change their software.  It's only a change in the PHY definition, so it's minimal effort, but it's still a change that needs to be made.  I had considered it a last resort, but after all this effort and killing tons of chips while testing, I had to finally admit defeat in my efforts to stop the LAN8720AI from dying.  I had really tried hard, tried everything I could think of to protect the chip, to no avail.

    So I set out to create a prototype with the RTL8201FI...

    Read more »

  • Second production run

    Patrick Van Oosterwijck05/10/2019 at 18:36 4 comments

    "Silicognition" PMS150C-559

    As mentioned in the last update, I ordered factory programmed Padauk PMS150C-U06 chips from Sino-Mos to provide a reliable reset for the PHY chip on every board.

    I expected everything to be OK with them, but you never know 100% for sure if everything was understood correctly when dealing with China, until you actually have something in-hand. For one thing, I was relieved that they had indeed re-reeled them. It would have been a big bummer if I would have received a bag of loose SOT-23’s. :)

    Then I had to make sure they were indeed programmed. So I reworked another 12 boards from the first batch that didn’t initialize the PHY correctly with chips from one of these reels, and after rework they all work flawlessly!

    Getting these chips has actually been a smoother experience than I had expected. It’s kind of cool to now have a low-cost custom chip that does exactly what I want it to do, with its own partnumber and everything. PMS150C-559 is now forever an “ESP32 Ethernet PHY reset manager”. Maybe I should write a datasheet for it. :)

    Also, since I have 9,000 of them, I can definitely spare some if anyone is making their own ESP32 board with Ethernet and wants a canned solution to deal with the LAN8720A PHY reset. There’s an updated schematic that shows how the chip is used on the new wESP32 revision. So get in touch if you want to buy some.

    Rev 3 PCBs

    I took a little risk and ordered new PCB panels that use the PMS150C-559 before I had verified the factory programmed chips. But it had all been taking much longer than expected already and some backers have been wondering when they’d receive their reward, so I tried to recoup some time that way.

    Having everything in-house I made a kit to send to a CM I was going to try in Mexico.  That's when things started to go really sideways.

    The scourge that is customs

    The first customs issue I ran into: how to do the paperwork correctly. This was going into Mexico temporarily just to have it assembled and then it was coming right back to the US. I sought advice from the CM and a local export company, and yes, I received information on some generalities, but no one really gave me any concrete answers on what codes to use, exemptions to claim or checkboxes to tick. So after wasting almost a week waiting for guidance I gave up and shipped the box with the documentation as good as I could figure it. I marked the shipment with the AES 30.37(q) to indicate a temporary export that would be returned within a year. Whether that is correct or not I don’t know. Nobody had told me what to do and it seemed the right thing to do.

    DHL got the box to Mexico after 4 days or so. Then the trouble started. First they claimed they couldn’t contact the CM at the telephone number I had been given and had put on the forms. They wouldn’t tell me why they needed to contact them. DHL was giving me options like “we can send your package back, or send it somewhere else for an extra charge, or we can destroy it for you (!)”. This nonsense took a week or so, a week of anxious freaking out for me. Then after wasting what they must have deemed sufficient time, they somehow did manage to get in touch with them and supposedly needed a tax ID from me. I run a passthrough LLC and certainly wasn’t going to give them my SSN! That sort of blew over after some work done by the CM and then they found that the contents of the box didn’t match the PI I had included. This was partially my fault: I had based the PI on the BOM, but even though neither me nor the CM cares about the exact part number of a reel of resistors, of course customs paper pushers do. I also had included some full and partial reels in the kit and amounts on the PI didn’t match. I really didn’t think anyone cared just how many parts were left on a partial reel, but of course they did.

    What a joke. None of it should have mattered of course. The parts are temporarily...

    Read more »

  • The PHY reset saga

    Patrick Van Oosterwijck03/11/2019 at 16:09 4 comments

    Finally, a long overdue update! The silence doesn’t mean we’ve been taking it easy, on the contrary: we’ve been hard at work to make the wESP32 even better!

    A yield problem

    After the initial build of 245 units, we were able to ship 205 units that were good right away. There were various issues with the remaining 40, but the vast majority of them had the same problem: the Ethernet PHY would not get initialized properly.

    The LAN8720A Ethernet PHY is kind of a difficult part. It has several pins that have double use: during reset their logic level indicates various configuration settings, while after reset they are used in the RMII interface to communicate with the ESP32. An extra difficulty is that the chip expects the 50 MHz clock to be present during reset, so the chip can clock in these configuration settings.

    Unfortunately, the ESP32 by default uses the IO0 pin for the Ethernet MAC clock. (More options have become available for dealing with the Ethernet MAC and PHY clocks, but because IO0 was the first option available in the SDK, it enjoys the broadest firmware support so that’s why I keep using it. Plus to keep as many other ESP32 pins as possible available to the user!) The ESP32 IO0 pin is kind of a difficult pin as well, since it is used on reset to determine whether the ESP32 should go into programming mode or run the current firmware. So we have a perfect storm of an IO0 pin that needs to be high at boot to run normally, but low at boot to go into programming mode, and needs to have the 50 MHz clock on it after boot to allow Ethernet communication, and that before the PHY comes out of reset.

    When I designed the wESP32, I just looked at how Olimex dealt with the IO0, ESP32 reset and PHY reset on their ESP32-GATEWAY and copied that for the wESP32, figuring they must already have found a good solution since this was a product in production. On my first hand-built prototypes, it all worked well, so I went ahead with it in production. Then I found that more than 10% of the boards had an issue. Interestingly, in their latest revisions, Olimex has changed their product to use IO17 as PHY clock output to bypass the whole problem! This might be a smart thing to do, but I am loath to make backwards incompatible changes and take a precious GPIO pin away from the user. So I started looking at other ways to deal with this.

    Looking for a solution

    I needed a solution that would act as a reset manager for the 50 MHz oscillator and Ethernet PHY and would be triggered by the EN signal to the ESP32. When EN is low on power-up and when triggered by a programmer, the 50 MHz oscillator needs to be off, so the programmer can drive the IO0 pin low to enter programming mode, or the IO0 can stay pulled high and the system boots. The PHY needs to be kept in reset as well, because its reset can only be released after the 50 MHz clock has started up. After the ESP32 has had the opportunity to determine the boot state, the 50 MHz clock needs to be turned on, and only after the clock signal is present can the PHY reset be released.

    I had assumed there would be plenty of low cost, SOT packaged voltage detectors and reset managers that could replace my existing solution in the space I had available, but to my great surprise, nothing I could find in the market really seemed to fit the bill. There are plenty of supervisors that monitor multiple voltages and generate a reset, but I couldn’t find any low cost options that monitor one input and generate two reset signals with separate delays.

    So I started thinking outside the box: did I really need to add a little microcontroller to do this? There are several microcontrollers that are cheaper than higher end supervisor chips, and it would give me full flexibility to generate the reset signals exactly how I wanted them. On the other hand, I didn’t really want to deal with programming this micro on every board. I would need to add programming pads and a manufacturing...

    Read more »

  • Don't blow up your Ethernet phy!

    Patrick Van Oosterwijck01/16/2019 at 16:29 0 comments

    You may have noticed a warning at the bottom of the MongooseOS demo in the demo code repo, about accidentally blowing up the Ethernet phy while playing with MongooseOS demo code.

    I didn’t find any time to pursue this further, but I have to give the people at MongooseOS credit for getting to the bottom of this! I received this message from them:

    We did some research, and found the problem with ethernet. It happened to be quite stupid: the default config for the built-in LED used pin 22, which conflicts with the ethernet TX.
    So, this command should set the board correctly:
    mos flash esp32
    mos config-set eth.enable=true eth.mdc_gpio=16 eth.mdio_gpio=17 board.led1.pin=-1 board.btn1.pin=-1

    This highlights an issue that can happen with other firmwares as well: misconfigured pins doing damage to the phy. By default, the wESP32 ships with MicroPython installed and it is configured correctly out-of-the-box for the Ethernet phy as it is configured on the wESP32. If you load different firmware though, it is your responsibility to ensure the ESP32 pins are configured correctly and will for instance not configure an ESP32 pin as an output that connects to a phy output, and thus cause a short. Please refer to the schematic to make sure. The wESP32 website section on Software provides more information on wESP32 support in different environments.

    If you have ordered one or more wESP32's, I recommend you try it with the default MicroPython firmware when you first receive it, to confirm the hardware is sound and it receives an IP address (check with lan.ifconfig()) from DHCP over Ethernet, which only happens if the phy is working. All units are tested to do this before they are shipped, but this way you can prove to yourself the hardware is OK and nothing bad happened during shipping. After that you are free to use whatever firmware you want of course, but I will not replace defective units once they have been flashed with different firmware, as I cannot know what happened to them.  Thanks for understanding!

  • We are shipping

    Patrick Van Oosterwijck01/16/2019 at 16:24 0 comments

    On Monday 1/7, we finally received completed panels from Colorado Tech Shop!

    So we spent most of this week doing final assembly (installation of two through-hole electrolytic capacitors and the Ethernet jacks) and testing for all 245 boards in the first batch. I am quite pleased with the result, I hope you backers will be happy as well!

    Some boards were used for internal testing, some had to be sent back to Colorado Tech Shop for rework after finding issues during test, but today we were able to ship the first 205 units to Crowd Supply for delivery to backers next week.

    One of the boards was used for an experiment. I wanted to see if the board worked with the AI-Thinker ESP32-S module instead of the ESP32-WROOM-32:

    I’m happy to report it seems to work just the same, so this module could be used to provide a future U.FL antenna connector option!

  • Production update, and testers!

    Patrick Van Oosterwijck12/30/2018 at 06:39 0 comments

    Last week it dawned on me that time keeps passing and I hadn't given much thought yet to how I was going to test the wESP32 and wESP32-Prog boards before we ship them!  A very important issue to start cranking on, especially with holidays and vacation eating up a good amount of time.

    wESP32-Prog tester

    The wESP32-Prog board is quite simple and because of this, the tester can be simple as well.  Building the tester only took half a day and this is what I ended up with:

    The hardware consists of a little STM8S103F3 board that can be had for less than a dollar on AliExpress.  I had it laying around and all I needed for this was a simple UART capable chip, so this was perfect.  I used the Sduino project project to speed up firmware development.   It looks slightly different from normal Arduino code because the SDCC compiler doesn't support C++, only C.  It was simple enough to get it to work though, resulting in this code:

    // wESP32-Prog tester using STM8S103 board and sDuino
    
    #define IO0   PA1
    #define EN    PA2
    
    void setup() {
      // Initialize digital pin LED_BUILTIN as an output.
      pinMode(LED_BUILTIN, OUTPUT);
      digitalWrite(LED_BUILTIN, 1);
      // Initialize EN and IO0 test pins as input with pullup
      pinMode(IO0, INPUT_PULLUP);
      pinMode(EN, INPUT_PULLUP);
        // Init serial port to 115200 bps
      Serial_begin(115200);
    }
    
    void loop() {
      // Read a byte from serial port
      int c = Serial_read();
      // Did we get a byte?
      if (c >= 0) {
        // Set lowest bit to value of IO0
        c = (c & 0xFE) | (digitalRead(IO0) ? 0x01 : 0);
        // Set second lowest bit to value of EN
        c = (c & 0xFD) | (digitalRead(EN) ? 0x02 : 0);
        // Echo byte back with altered IO0 and EN bits
        Serial_write(c);
        // Set the green LED state according to the second highest bit
        digitalWrite(LED_BUILTIN, (c & 0x40) ? 0 : 1);
      }
    }

     All this does is when a byte comes in, echo it back with the bottom two bits replaced by the current state of the IO0 and EN signals.  The second to highest bit also sets the tester board's on-board LED state.

    This firmware works in conjunction with a little Python script on my Linux box:

    #!/usr/bin/env python3
    
    import os
    import glob
    import serial
    import time
    from termcolor import colored
    
    while True:
    
      print("Waiting for wESP32-Prog...")
        ports = []
      while not ports:
        ports = glob.glob('/dev/ttyUSB*')
        time.sleep(0.1)
    
      print("Serial port detected, waiting for access...")
        while (not os.access(ports[0], os.R_OK|os.W_OK)):
        time.sleep(0.1)
        print("Testing wESP32-Prog...")
        test_ok = True
      s = serial.Serial(port=ports[0], baudrate=115200, timeout=0.1)
    
      s.setRTS(False)
      s.setDTR(False)
      s.write(b'0')
      res = s.read(1)
      if (res not in [b'0', b'1', b'2', b'3']):
        print(colored("ERROR: Serial data did not echo correctly, is the tester connected?", 'red'))
        test_ok = False
      if (res != b'3'):
        print(colored("ERROR: IO0 and/or EN pulled low when neither is asserted!", 'red'))
        test_ok = False
    
      s.setRTS(True)
      s.write(b'0')
      if (s.read(1) != b'1'):
        print(colored("ERROR: EN not pulled low correctly!", 'red'))
        test_ok = False
    
      s.setDTR(True)
      s.write(b'0')
      if (s.read(1) != b'3'):
        print(colored("ERROR: IO0 and/or EN pulled low when both are asserted!", 'red'))
        test_ok = False
    
      s.setRTS(False)
      s.write(b'0')
      if (s.read(1) != b'2'):
        print(colored("ERROR: IO0 not pulled low correctly!", 'red'))
        test_ok = False
    
      if (test_ok):
        print(colored("OK! All tests passed.", 'green'))
        s.write(b'@')
    
      s.close()
      print("Please unplug wESP32-Prog.")
        while ports:
        ports = glob.glob('/dev/ttyUSB*')
        time.sleep(0.1)

     What this does is wait for the wESP32-Prog board to be plugged in, which will create a /dev/ttyUSB0 device.  For some reason, trying to immediately open the serial device after this threw an access error, so we wait until it becomes accessible and then open it.

    Testing ensures that when we send a byte, the STM8 micro echoes a (modified) byte back to us.  We do this with various states of the RTS and DTR signals which control...

    Read more »

View all 29 project logs

Enjoy this project?

Share

Discussions

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 

https://www.cnx-software.com/2017/06/21/olimex-launches-22-euros-esp32-gateway-board-with-ethernet-wifi-and-bluetooth-le/

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

bbz wrote 04/20/2018 at 20:30 point

making good progress

  Are you sure? yes | no

hackadoy wrote 04/10/2018 at 07:46 point

Great project. Is there any planned launch date?

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 04/10/2018 at 14:30 point

No, I have too many other projects at the moment to be able to dedicate a firm amount of time on it.  That said, it's my favorite "distraction" at the moment, so I'm making decent progress.  I expect to have prototypes in the next month or two.

Stay tuned! :)

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 03/30/2018 at 23:10 point

Thanks for the input everyone, very useful! :)  It may be hard to fulfil everyone's wishes, but I'll try to keep all your comments in mind!

  Are you sure? yes | no

Ashton Smith wrote 03/26/2018 at 23:07 point

Do this! ive been looking for basically exactly this, and i was going to try to use the PoEPi project (https://hackaday.io/project/9455-poepi-pi-zero-power-over-ethernet-with-phy) but this would be perfect - im afraid i cant provide much help, but i would buy for sure!

  Are you sure? yes | no

bbz wrote 03/26/2018 at 13:13 point

I've been using the olimex boards for development and considering making a board like you describe for production use. Other than lacking PoE and being not small enough for my use they are great.

External PoE is cheap (like https://www.amazon.co.uk/DSLRKIT-Active-Splitter-Ethernet-Raspberry/dp/B01H37XQP8/ ) so to make a new board worth while it'd need to be better than that combination. Passive PoE is not worth bothering with, people can do that themselves trivially

I aim to build this board into things for monitoring and control. I prefer wired over wireless as they will be hard to access and I don't want to be swapping batteries on loads of them, wireless is also too unreliable for control applications (and adds security/electrical interference risk). With PoE I can remotely reset any unresponsive device.

My ideal form factor is to have it built in the ethernet jack like https://www.digi.com/products/embedded-systems/system-on-modules/digiconnectme and https://www.lantronix.com/products/xport/ Both those are too expensive, lack i/o and lack PoE. Sadly ESP32 lack ethernet PHY otherwise building it in an oversized jack might work.

Things I'd be looking for in a board -

Ideal size is not larger than a match box, approx 45 x 30 x 15 mm if can't fit in ethernet jack

Active PoE, I value size over price so the extra cost of a lower power profile than 12W is fine, I see you are going for 12W on cost, perhaps a smaller low power version later.

I'm using ethernet not wireless so not worried about compliance, thus can use the pico chip directly for smallest size instead of the larger complaint modules. One exception is that for door readers I want to use the BT but could use a different board there.

I'd like to add specialist i/o around it so option to stack a small board replacing direct i/o. For most cases we'd have direct i/o like https://www.amplicon.com/MandC/product/Remote-Distributed-tET-tPET-4632.cfm (I use these devices but they aren't open to adding your own code, I want our code to feed into MQTT)

A space for a dc/dc convertor to power external things (like smoke detectors, PIRs, door locks) would be great, there are small ones that could be installed as needed like - https://uk.rs-online.com/web/p/isolated-dc-dc-converters/1247615/ which are available in a range of voltages and power. If you're making your own PoE converter then it may be better to feed this converter upstream of the output or even incorporate it. The plan is for most cases not to need an external supply. For larger things we can use pass through PoE splitters that will take 60W, provide DC out and onward PoE for this board (hence not wanting this board to signal than it needs 12W when it only needs 3).

I don't have a need for a usb serial programming interface, it wastes space and is only needed on dev boards. An external one is fine for initial load but after that it'll be OTA updates.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 03/30/2018 at 23:21 point

I'm afraid I won't be able to make it quite as small as you wish.  I'm aiming for small (always!), but there are limits as to how small you can get with PoE.  A quick calculation shows that just the Ethernet jack, flyback transformer, ESP-WROOM-32 module and IO header take around 11.4 cm^2 by themselves.  That has eaten up the majority of the 13.5 cm^2 you're looking for. :)

For the "general purpose" first version, I'm aiming for 12W, with WiFi and BLE ability as well as there are certain use cases for this.  To get it tiny, I'd have to go for 3W with a ESP32-PICO-D4 without antenna instead.  I may do something like that in the future if I see enough demand.

  Are you sure? yes | no

bbz wrote 03/31/2018 at 21:35 point

Yes, see how the 12W version goes, I may later commission you to do a smaller 3W version more as I described

  Are you sure? yes | no

Tom Bull wrote 03/26/2018 at 11:24 point

Would love to help out with this. I've been starting to do something very similar - but I'd like to seriously reduce the cost (flyback transformer, PoE MagJack, etc). I'm currently based in Shenzhen - so if there's anywhere that the cost can be reduced, it's here. Let's talk!

  Are you sure? yes | no

cata2109 wrote 03/20/2018 at 21:07 point

Smart Wall switch. 

  Are you sure? yes | no

Chris wrote 03/20/2018 at 18:47 point

Awesome projet. A few usages I can think of:
- Combined with a display, it could be used to create a network diagnostic tool.
- With 5V/12V output it could power a GPS and serve as a ntp server. The ethernet connection would be faster/more reliable than wifi.
- Again with 12V output, it could be used to power a lot of small appliances (router/wifi access point/radio/baby monitor/led strips). The ESP could monitor or talk to the device. Add a relay and it could switch the device on/off.
- A network speaker to play music. Use the PoE for the amplifier and the esp's bluetooth to act as a wireless speaker.
- It could be used to control multiple servos/sensors somewhere you can reach with an ethernet cable but wifi and/or power isn't available (outside or industrial environment).


  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