Dedicated hardware

[nliaudat]

Here is a new board that can replace the esp32-cam with PoE support.

https://hackaday.io/project/193356-esp32-stick-camesp32-s3activepassivepoecamera

The board developper knows ai-on-the-edge and is open to make a custom board for our needs !

I've asked :

• 4 RGB leds for backlight in series
• 4 mounting holes
• 1 sdcard

do you have any further requests ?

@jomjol @caco3

[jomjol]

One major drawback of the ESP32CAM is the high power consumption in deep sleep due to the permanent power to the camera and the high current for the power converter.

If we think about going for battery version the following things are in my mind:

• If we think about a battery drivern version, a complete shutdown of the power consumption for the camera as well as the sd-card with a transitor with very low power consumption by itself, that could be switched with one of the GPIOs would be great.
• Also if a power connector for a 3.7 V LiPolymer accu would be great. I have tested 3.7V LiPo-battery and it is sufficient for the camera, sd-card and internal flashlight.
• In order to controll the battery charging state a high ohmic voltage divider to controll the battery voltage with an analog port would be cool, too. It also should be switched of with the transistor to avoid power loss during deep sleep.

4 MB of PSRAM is a clear must.

[nliaudat]

Response from @allexoK :
So the list of requirements goes as follows:

• 4 RGB (WS2812 is led strip) LEDs connected in series to GPIO12 according to the https://jomjol.github.io/AI-on-the-edge-device-docs/External-LED/ documentation.

• SD-card reader, (SD card connected via SPI?(no need for SDIO, right?). If SPI, can it it be same SPI line as W5500 Ethernet chip?).

• 4 Mounting holes (M2 size? Positioned at the corners at the board?(If yes, I will move the Eth connector or increase the board size)).

• Esp32-S3 with at least 4MB PSRAM.

• Low-power transistor shutdown of camera and SD card.(Note to myself: don't forget, to do the smart way, so Esp32-S3 doesn't have to 'hold' the pin(so it can deep sleep))

• Battery connector(+Battery charge/protection circuits?).(Battery charging with 500 mA?-If yes it will need at least 500mA battery, which is, I think, minimum to reliably power SD card+Esp32-S3)

• Battery measurement with high-ohmic divider (can be shut down).

• Size requirements?(Two side assembly=smaller board=bigger price)

• Any specific connectors, pin positions?(Stemma QT can be cool to solderlessly daisy-chain Adafruit/Sparkfun sensors/displays via I2C?)

[yoshimo]

I found it difficult to get a proper case that suits the needs for the specific meters around the house.
So a custom board should be accompanied by a set of 3d models and a table that says: you need this model x for your meter y.

What about connections? Wifi, Bluetooth, Zigbee, Thread, Matter, Ethernet for data are options and then you could think about powering over usb-c , micro usb or ethernet.
It is not all about battery power which can run out in a dark cellar

[allexoK]

Speaking about other protocols, it may be beneficial to make Mikrobus-style female pin headers. (Just a suggestion)
Viz pic, sorry for dirt, it's a very old and very dead board:)


Click modules are costly, but are standardized.
It's possible to insert different communication modules (like this https://www.mikroe.com/zigbee-click or https://www.mikroe.com/lr-click). Maybe later the custom Click-shield can be made for the chosen protocols.
I also have experience with Esp32-C6 design, which supports all the protocols you mentioned, but it will not have enough pins for Camera+SD+Ethernet.

[Slider0007]

4 RGB (WS2812 is led strip) LEDs connected in series to GPIO12 according to the https://jomjol.github.io/AI-on-the-edge-device-docs/External-LED/ documentation.

• In my opinion, just use a free suitable GPIO. Software wise it has not to be mandatorily GPIO12.

SD-card reader, (SD card connected via SPI?(no need for SDIO, right?). If SPI, can it it be same SPI line as W5500 Ethernet chip?).

• I'd suggest using SDMMC interface (available on ESP32S3) for SD card because quicker and dedicated or at least a dedicated SPI to avoid performance issues.

• Interference reduced routing of camera clocks (up to 20Mhz) and far away from WLAN antenna to avoid wlan connection issues. With ESP32-CAM this is a big hardware drawback. Lots of issues are related to this.

• Additional external wlan antenna connector, internal antenna as default

• Powering via USB should still be possible

• Min. 8MB RAM / min. 8MB flash

Size requirements?(Two side assembly=smaller board=bigger price)

• In my opinion size does not matter.

[caco3]

• I would suggest to have an external antenna by default as most need one anyway.
• PoE is cool, but most users will not have Ethernet in reach, thus 5V (USB-Wall-Charger) is more practical.
• If we go for a custom design, I it would be nice to have 8MB RAM (id we can fully support it which is not possible with the currently used ESP32-CAM.
• Also note that it seems to use the S3 CPU which currently is not supported by our project.
• If we go for such hardware, we have to think about what to do with the current hardware. Do we continue to develop or both? Or will be split the firmware to 2 separate parts?
• The price will be higher for this custom hardware by several factors. Will users be willing to pay this? IMO the current hardware works well (once you get a board with 4 MB of RAM).

In any way, I am an electrical engineer and could help on the schematics review and commissioning.

[allexoK]

• Yeap, the CPU used is Esp32-S3. Unfortunately, vanilla Esp32 doesn't have enough pins to run Ethernet+SD+Camera:( (Maybe possible if Ethernet+SD share the SPI)

[allexoK]

Hi @caco3, could you please take a look at this schematic? It's a direct copy of my Esp32-Stick-PoE-A-Cam board, upgraded to support an SD card, 4x WS2812B LEDs, battery charging, protection, and measurement, as well as sleep mode turn-off circuitry. The PoE, Ethernet and Camera circuitry should still work since I didn’t change them.
I couldn’t find an Esp32-S3 module that supports an external antenna, so I'm unsure whether to take the easier path by using the ESP32-S3-WROOM-1U version(external antenna only) or use a bare ESP32-S3R8(antenna RF matching may be painful)...
Schematic_esp32-S3-POE-A-CAM+_2024-10-10-2.pdf

[allexoK]

Hey everyone,
So ping me after you reach some kind of consensus:

• PoE, Ethernet board with Esp32-S3 (customer price: 35-40USD for 1 piece), according to requirements you specified.
• Slightly upgraded Esp32 Board without PoE(customer price: around 14USD for 1 piece), but according to other requirements you specified (battery support, better shutdown for sleep modes, leds, mounting holes)
• Stick to the existing hardware
• Some other variant

[nliaudat]

Just found : https://oshwlab.com/sentsor-project/sentsor-core-esp32-embed or https://oshwlab.com/sentsor-project/sentsor-core-esp32-micro
just missing the cam part ;(

[caco3]

I do not want to be in the way for new hardware, I mentioned my points above.
But I think the reason this project is used so often is because the hardware is cheap and easy to get. Yes, there are bad boards, but once you get a good one, it provides whatever is needed. Because of this I do not really see the need for custom hardware, at least not as a replacement.

[Dennis1000]

Any latest news on the POE device?

[Fywqdk]

Personally I agree that while PoE is nice, it's probably a lot more niche? In my own situation I have my watermeter in an isolated well in the middle of my front yard lawn and it matters little if it is an ethernet cable or an AC power cable, it's not going to be feasible for me. Battery-optimized hardware on the other hand is probably the only solution here.

One thing I wonder is if LORAwan would be nice? The range is good and as far as I know it's also fairly low power compared to wifi, and thus more battery friendly. The downside is a receiver is needed and it's less plug-and-play. But would probably excel since the data manipulation is running on-chip before transmitting.

[allexoK]

Hey @nliaudat @caco3 @jomjol , long time no see:) I think I will have some free time this month, is your PoE hardware request still relevant? (Perhaps you already developing something, don't really want to be a competition :) ).

[Dennis1000]

+1 for POE

[nliaudat]

Hi,
Actually, esp32-cam is end of life and it will be waste of time to recreate one.
There are new interesting boards like Seeed Studio XIAO ESP32S3 Sense or T-Camera S3

I mean the support of S3 boards is the goal to achieve.

Only my opinion.
Regards

[SybexX]

this is a much better board: https://www.ebay.de/itm/315533473713?_skw=esp32+s3+n16r8&itmmeta=01J9KXSV94QNJJ0427FT0CZB6J&hash=item497742b7b1%3Ag%3AqYMAAOSwB8xmAUkF&itmprp=enc%3AAQAJAAAA8HoV3kP08IDx%2BKZ9MfhVJKmFQNea1faWev22naVLZv0AhaGIYkzhxCLtuaJSZysTrJ7zpuycBRgKan%2BjQWvZuJzpZ%2FSUNZQO3y6G8j59swoyhCDvSO4czI6dV%2Fa79E2i4hilQEgmurHlcL%2FXFKrw6if8SROUDCzCEq69u9LK%2BupNw5%2F00j8L%2FUEn2Ufuah0H5bFsh91jL3ZycvX2MEV3CqSsFBj9vszmkcBcXTdNL5JLwKkPQV1CDTHWILZe2qHhGPMXVq%2BKSyv%2FjqYUzmA1yj4B%2F7MWC%2BLlGR5KmWwRHHnhQxQg4tOJciiXNkUu9L3nQQ%3D%3D%7Ctkp%3ABFBM3LTn_cxk&var=613992247099

[nliaudat]

It depends on your needs :

• Seeed Studio Sense as building battery support
• Lilygo has a big RGB led
• Yours (no marks) is cheaper

[SybexX]

• The board has an RGB LED, which is completely sufficient.
• The board has the same size/structure, so no changes to the existing case are necessary

[nliaudat]

I bought one to test the compilation changes

[allexoK]

The ESP32-S3 is nice, but I'm fine with either option. If the vanilla ESP32 is better from a software point of view, I'll make the board with the ESP32. However, it may lack enough pins to control the circuitry in sleep mode. Do you think it would be easier to add IO expander support to AI-on-the-edge-device or port it to the ESP32-S3?

[nliaudat]

https://wiki.seeedstudio.com/XIAO_ESP32S3_Consumption/

[allexoK]

I think you misunderstood me:) I want to make a custom hardware for AI-on-the-Edge, but I'm not sure whether to use the ESP32 or ESP32-S3. As @caco3 and @jomjol pointed out in the past, there is currently no support for the ESP32-S3, and there are no plans to support it (#2721, #2801 (comment)). So, my question is: As of today, is this still the case, or are there plans to support the ESP32-S3 in the future?

[SybexX]

I'm currently at it, I just have to rework the whole IO implementation^^
Many of the necessary changes have already been added to the main branch/16.0.0-RC4.
The performance is simply great compared to the normal ESP32^^
@Slider0007 has already implemented it: https://github.com/Slider0007/AI-on-the-edge-device/tree/esp32s3wroom

[allexoK]

Great, that's really all I wanted to know. Thanks a lot for your swift response!

[caco3]

Just some thoughts:
The benefit we have now with the existing ESP32-CAM hardware is that everybody can buy it wherever he wants.
If we build our own, specific hardware, it gets more tricky:
Either somebody steps in and sells it (if possible worldwide), or we are able to provide it fully opensource and with suggested places where to produce and fully assemble it.

If we can not provide this service longterm, I think it is better to stick to commercially available hardware.

One option would be to support a commercial board and additionally our optimized board. We then would have to provide the firmware for both versions or the firmware would have to support both.

Strictly speaking, if we support multiple hardwares, we also should test with them or at least provide support for all of them.

[allexoK]

Selling worldwide is no problem for me, I already sell on Mouser , Tindie, Elecrow, Amazon and on my local store in Czech Republic :)

[firebowl]

I'll add my own comment here. I don't need POE but generally LAN because the WLAN coverage at the location is very poor or non-existent.

[caco3]

IMO PoE would imply that Ethernet works as well.

[firebowl]

Sorry, I expressed myself badly. LAN would be enough for me, of course that is part of PoE.

[SirNoName2705]

breakout board for ring light led?
These ring lights would be for placement around the camera which would provide very good lighting.

[Aitch-ko]

I’d like to suggest adding support for the ESP32-S3-ETH module with Camera and PoE capabilities. Here is the link to the hardware: https://www.waveshare.com/esp32-s3-eth.htm?sku=28772

This board offers several advantages:

• Built-in Power-over-Ethernet (PoE), which simplifies power supply in network environments.
• Enhanced performance thanks to the ESP32-S3 processor.
• Compatibility with cameras for image-based tasks.

Given the project’s focus on edge device applications, this board could provide a powerful alternative to existing supported hardware.

[SybexX]

I can't give you an exact list of everything that needs to be changed because I have integrated a lot of other things into my private firmware and therefore don't know exactly.

• esp32-camera needs to be updated to master
• minizip, server_file and server_ota need to be changed
• TemperatureSensor needs to be changed
• SmartLeds needs to be updated
• server_GPIO needs to be changed
• html needs to be changed
• partitions.csv and sdkconfig.defaults for the board must be created
• platformio.ini needs to be changed
• defines.h needs to be changed
• and maybe other things

These are the rough things that are necessary for this.

Implementing new hardware that you don't have is very difficult and not fun because you always have to rely on others to test it and therefore quickly lose interest^^

[RichMar]

Hello, great job! Have you tried running it on battery? Is there any power saving? Just yesterday I put a classic ESP32-CAM into operation with a battery power supply. I don't need to take readings that often, like once a week. I wanted to treat it with some hardware timer, which would switch it off e.g. for 5 minutes before reading. But if your solution has a reasonable readout, that would be ideal.

[SybexX]

The OV2640 is not that well suited for battery operation (at least not if you want to read more often), so I would rather use an OV5640.
The OV5640 fully supports DeepSleep, the OV2640 can be sent to DeepSleep, but then you have to briefly disconnect the power supply to restart it and therefore it has to be reinitialized.

With the esp32-s3-eth there could be a problem with data transfer/page loading, as the Ethernet runs over spi and this is relatively slow (you might have to slim down the html).

[Aitch-ko]

I can't give you an exact list of everything that needs to be changed because I have integrated a lot of other things into my private firmware and therefore don't know exactly.

• esp32-camera needs to be updated to master
• minizip, server_file and server_ota need to be changed
• TemperatureSensor needs to be changed
• SmartLeds needs to be updated
• server_GPIO needs to be changed
• html needs to be changed
• partitions.csv and sdkconfig.defaults for the board must be created
• platformio.ini needs to be changed
• defines.h needs to be changed
• and maybe other things

These are the rough things that are necessary for this.

Implementing new hardware that you don't have is very difficult and not fun because you always have to rely on others to test it and therefore quickly lose interest^^

Thank you so much for the files and the detailed list of changes—it’s incredibly helpful!

Just to clarify: Are these files based on the original AI-on-the-edge-device firmware or on your customized fork? I want to make sure I’m working with the right starting point.

Thanks again for your time and effort!

[SybexX]

This is the AI-on-the-edge-device main with the necessary changes, but the config htlm still needs to be adjusted regarding the GPIOs. I tested it roughly with my ESP32-Cam and ESP32-S3-Cam and don't know if any further changes are necessary, this needs to be found out through more thorough testing.

[nliaudat]

I think it's becoming too difficult to maintain hardware with so many features.
@jomjol s first idea wasn't wrong, because he separated the processing part from the hardware.

That's what I'm proposing now with https://github.com/nliaudat/meter-reader

The idea is that any hardware can generate an image, very simply with esphome for example.

On the other hand, it's complicated to extract numbers and requires a lot of C++ code in the current version. This also makes it difficult to maintain the purely hardware part, or components such as mqtt, influx, etc.

The solution of decentralizing the digitizing process may seem trivial, but I think it's a solution for the future to separate ourselves from the hardware and concentrate solely on digitizing "rotary" digits.