Frank Kunz f311239c9c Add new AP hardware support OpenEPaperLink_ESP32-PoE-ISO_AP (#431)
* Fix filesystem mutex handling

This fixes the re-initialization of the filesystem mutex when the dyn storage
module is reinitialized. Using xSemaphoreCreateMutex would cause a memory leak
when the begin function is called multiple times and a semaphore leakage could
be caused by the re-initialization of the global fsMutex variable while the
semaphore is taken.

The fsMutex should not be taken while the logLine function is called as this
would cause a nested take of the fsMutex, which causes a deadlock.

Signed-off-by: Frank Kunz <mailinglists@kunz-im-inter.net>

* Fix hard coded littlefs in json upload

Signed-off-by: Frank Kunz <mailinglists@kunz-im-inter.net>

* Add new AP hardware support OpenEPaperLink_ESP32-PoE-ISO_AP

This is based on Olimex ESP32-PoE-ISO
https://www.olimex.com/Products/IoT/ESP32/ESP32-POE-ISO/open-source-hardware

It has a SD Card slot that is used to store all filesystem data on SD.
Use the prepare_sdcard.sh script to copy all needed data to an empty
SD card that is formatted with FAT filesystem. The AP firmware will format
the SD if an unformatted or from formatted card is used. This can be used
to intially prepare an empty SD card for usage.

For tag communication a ESP32-C6-WROOM-1(U) is used with the following
connection scheme:

ESP32-PoE-ISO  |  ESP32-C6-WROOM-1
---------------+------------------
  GPIO5        |    EN
  GPIO13       |    GPIO9
  GPIO36       |    GPIO3
  GPIO4        |    GPIO2
  GPIO33       |    GPIO24
  GPIO32       |    GPIO25
               |    GPIO8 pullup 5.1k

Signed-off-by: Frank Kunz <mailinglists@kunz-im-inter.net>

* Avoid error message log print when parsers.json is missing

Signed-off-by: Frank Kunz <mailinglists@kunz-im-inter.net>

* Workaround for IEEE802.15.4 modem stuck issue

The ESP32-C6 esp-idf based modem firmware can run into a case where it
does not receive data anymore from the tags. This can be detected when
it starts to print

"receive buffer full, drop the current frame"

and does not recover from that. In such a case a modem reset is triggered.

Signed-off-by: Frank Kunz <mailinglists@kunz-im-inter.net>

* Add OpenEPaperLink_ESP32-PoE-ISO_AP to release build

Signed-off-by: Frank Kunz <mailinglists@kunz-im-inter.net>

* Add OpenEPaperLink_ESP32-PoE-ISO_AP to condidional build

Signed-off-by: Frank Kunz <mailinglists@kunz-im-inter.net>

* Add Ethernet support

The ethernet support allows to make the network/internet connection
via LAN cable instead of WiFi. LAN is preferred, if a LAN cable is
connected and a valid IP configuration via DHCP can be obtained, WiFi
is switched off. If the LAN cable is disconnected, a fall back to
WiFi is done.

Use those defines in platform.ini for PHY settings:
ETHERNET_PHY_POWER: IO pin where the PHY can be switched of/on, can be
                    -1 if not used.
ETHERNET_CLK_MODE: PHY clock mode, see eth_clock_mode_t in ETH.h
ETHERNET_PHY_MDC: PHY MDC pin
ETHERNET_PHY_MDIO: PHY MDIO pin
ETHERNET_PHY_TYPE: PHY type, see eth_phy_type_t in ETH.h

Limitations:
- only DHCP is supported, no static IP configuration for LAN so far.
- If GPIO0 is used for one of the ETHERNET_CLK_MODE modes, then GPIO0
  cannot be used to clear the WiFi configuration.

Signed-off-by: Frank Kunz <mailinglists@kunz-im-inter.net>

---------

Signed-off-by: Frank Kunz <mailinglists@kunz-im-inter.net>
Co-authored-by: Frank Kunz <mailinglists@kunz-im-inter.net>
2025-03-27 00:48:05 +01:00
2025-03-23 13:55:41 +01:00
2025-02-25 12:03:35 +01:00
2022-12-26 22:33:49 +01:00
2023-07-04 22:04:03 +02:00
2024-10-08 12:36:03 +02:00
2024-12-05 09:45:58 +01:00

OpenEPaperLink

This is an alternative firmware and protocol for the multiple Electronic Shelf Labels. It can be used to set up E-Paper tags and supply them with content.

The software in this project consists of two parts: Accesspoint-firmware and Tag firmware. Additionally, there are various hardware designs for accesspoints and flasher-interfaces to program the tags, preferably using programming jigs

Aims

  • Low power (currently around 9µA with a minimum of 40 second latency)
  • Even lower power when there's no AP around
  • Low latency (tags can check for new data every 40 seconds)
  • High transfer speeds - It can do about 5kbyte/s in favorable RF conditions. This allows for lower power
  • RF-friendly - We don't need to acknowledge EVERY packet, and we don't need to transfer data we already have

On the Wiki there is a ton of information regarding all kinds of tags and building the access points.

The entire setup requires a few tags and an ESP32. A tag is used as an 802.15.4 radio for the ESP32. You'll need a ZBS_Flasher in order to flash the tags. Using the 'mac' option on ZBS_Flasher makes sure a tag flashed with a custom firmware has a valid mac address; it uses the stock mac address assigned to the tag if it hasn't been flashed before. If you want to set it yourself, you can edit the mac address in the infopage.

You can hook the AP tag up to the ESP32 with mod wires or a flex PCB. The esp will flash the AP firmware to the Tag automatically. In some cases, a power off/on cycle is required. Please check the serial console output for status information.

After programming the ESP32, make sure to also program the filesystem. This will upload the 'data' folder to the ESP32, with the webinterface.

The protocol explained

  • The tag checks in with the AP every 40+ seconds. Actual check-in interval is highly dependent on RF conditions, or if the AP tells the tag to delay the next check-in
  • The AP holds a list with tag MACs that have pending transfers.
  • If a tag checks in, the AP replies with either no data, or information about a pending transfer
  • The tag checks if this information is already downloaded to EEPROM, or is already displayed. If this is the case, the transfer is immediately cancelled by issuing a 'transfer complete' packet to the AP.
  • The tag then proceeds to request data in 'blocks' of 4096 bytes. The AP responds with an ACK on the request, and specifies how long it will take to gather the data. The tag sleeps until the AP will send the data
  • The AP requests its block-buffer to be filled by the ESP32, specifying MD5 and blockID
  • Datablock is sent by the AP, which will take about 42 packets for a full block. The tag will keep track of which blocks it has seen
  • After a block has been received with missing parts, the tag will request the same block, with a bitmask of blocks that are missing
  • The AP responds with the parts as requested by the tag. If there aren't too many blocks requested, the AP will fill the block with duplicate parts, to increase the chance of a successful transmission
  • After a full block has been received, the tag will do a simple checksum over all received data. If the checksum matches, the 4K of data is stored in EEPROM storage for later use
  • The tag will now either request the next block, or do a full re-request if the checksum failed
  • If all blocks are received, the tag will send a 'transfer complete'.
  • The AP will report the completed transfer to the ESP32, and removes the pendingData for this transfer from the queue

Known issues:

  • Some tags work better as APs than others. Your range may suck. The boards on these tags are tiny and fragile. For instance, a dab of hot-glue on a board is enough to warp it pretty severely, and will damage the components that are soldered on there. Reportedly, segmented-display Solum tags work well.

Hints and excuses:

  • There is no warranty whatsoever. Nothing. Not implied or otherwise suggested. This code isn't fit for anything. Please don't use this code to do nasty things.
  • Do a make clean between buildings for different boards. It really helps!
  • This repo builds on SDCC 4.2.0 for Linux. Different SDCC versions can behave VERY differently. Source sdcc/setup.sh to setup build a local copy and use it for compiling.
  • We are happy and honored to see your pull requests! But please, no code/indent style changes :)

Credits

Large parts of this repo are based on code written by, and wouldn't be possible without the hard work of:

  • dmitry.gr
  • atc1441

Hats off to these legends!

Automated Builds

  • After a PR gets merged to the main branch, the changed code will be compiled.
  • On release, files are added to enable OTA

Test

Release

License

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)

Description
The OpenEPaperLink core project
Readme 310 MiB
Latest
2026-01-18 14:53:44 +01:00
Languages
C 48.3%
C++ 27.6%
Roff 7.8%
Perl 7.2%
Shell 2.4%
Other 6.6%