Wiznet makers

Summary

MeshCam is an ESP32-based wildlife camera network that transfers motion-triggered images through a low-bandwidth LoRa mesh and forwards them to a self-hosted server through an internet-connected gateway. The current wired gateway uses an ESP32-WROOM board with a LAN8720 RMII Ethernet PHY and Power over Ethernet. This project does not currently use WIZnet products. A WIZnet W5500 could replace the existing RMII Ethernet path in a custom gateway by providing SPI-connected Ethernet with hardware-managed TCP/IP sockets, but that change would require adapting the firmware’s UDP, HTTPS, OTA, and network-status layers.

What the Project Does

MeshCam is designed for trail-camera deployments where cellular service is unavailable, undesirable, or too expensive to provide for every camera. Solar-powered camera nodes remain in deep sleep until a PIR sensor detects motion. A node then captures an image, applies an on-device TensorFlow Lite person-or-animal filter, and sends accepted images through a Reticulum network running over SX1262 LoRa radios.

The network is divided into several firmware roles:

• Leaf nodes capture and classify images before transferring them as Reticulum Resource objects.
• LoRa relays move encrypted Reticulum traffic through the mesh.
• Gateways receive LoRa resources and upload completed images and metadata to an ingest API.
• RNS-over-UDP interfaces connect embedded Reticulum nodes with Python Reticulum peers on the local network.
• Development bridges provide laptop-assisted ingestion and transport validation.

The design explicitly accepts LoRa’s low data rate. The repository describes typical throughput in the kilobit-per-second range and uses a thumbnail-first, full-image-later model. Reticulum supplies routing, addressing, encryption, and arbitrary-size resource transfer, while store-and-forward behavior prevents an interrupted path from immediately discarding a capture.

At the gateway, the data path is:

ESP32-S3 camera
    ↓ JPEG image
Reticulum Resource over SX1262 LoRa
    ↓
ESP32 gateway
    ↓ UDP, HTTPS and local management
Ethernet or Wi-Fi
    ↓
MeshCam ingest server and gallery

The gateway firmware supports two hardware families. Heltec V3 builds use Wi-Fi and an onboard SX1262. The wired build targets the LILYGO T-Internet-POE, which combines an ESP32-WROOM, LAN8720 Ethernet PHY, and 802.3af PoE input. An external SX1262 is connected to remaining GPIO pins.

Where WIZnet Fits

This project does not currently use WIZnet products.

The repository’s production wired gateway uses a LAN8720. The LAN8720 is an Ethernet PHY connected to the ESP32 through RMII. The ESP32 and its software network stack remain responsible for Ethernet frame handling, IP networking, UDP, TCP, and TLS-related operations.

A WIZnet W5500 would occupy a different architectural position. It connects through SPI and implements IPv4 networking and TCP/UDP sockets inside the Ethernet controller. In a MeshCam gateway variant, it could provide:

• DHCP or static IPv4 configuration
• Reticulum UDP transport on port 4242
• TCP connections used by image-ingest requests
• Ethernet link-state monitoring
• Hardware packet buffering
• A wired path for remote management

The W5500 would not participate in the LoRa mesh itself. Reticulum routing and SX1262 radio communication would remain on the ESP32. The W5500 would only replace the gateway’s LAN-facing transport.

This separation can be expressed as:

SX1262 LoRa interface
        ↓
Reticulum router and Resource receiver
        ↓
Gateway application
        ↓
W5500 socket interface
        ↓
Local Ethernet network
        ↓
Ingest API or Python RNS peer

The W5500 is potentially useful where the gateway controller has limited networking resources or where a custom PCB cannot dedicate the ESP32 pins required by RMII. W5500 integration requires SPI signals, chip select, reset, and optionally interrupt, while the existing LAN8720 implementation reserves RMII data pins, management pins, a clock-output pin, and a PHY-reset pin. The current board reserves GPIO 5, 17, 18, 19, 21, 22, 23, 25, 26, and 27 for its Ethernet PHY.

The trade-off is software compatibility. The current gateway relies on the ESP32 Arduino Ethernet interface and lwIP-compatible networking classes. W5500 hardware sockets do not automatically behave like the existing native ESP32 Ethernet interface in every library. UDP transport is relatively direct to migrate, but HTTPS uploads, OTA, web status pages, DNS, time synchronization, and reconnect behavior must each be verified against the selected W5500 library.

Implementation Notes

The repository provides direct evidence of the current Ethernet implementation.

Existing Network Selection

File: gateway/platformio.ini

[poe_common]
flags =
    ${gateway_common.flags}
    -DGW_NET_ETH
    -DGATE_B_WIRED_SX1262
    -DDEFAULT_UDP_PORT=4242

The GW_NET_ETH build flag selects the wired gateway path. The same environment configures an external SX1262 and assigns UDP port 4242 to Reticulum-over-UDP traffic. The configuration targets the LILYGO T-Internet-POE rather than a W5500-based board.

Existing LAN8720 Dependency

File: gateway/platformio.ini

[env:poe-gateway-home]
framework = arduino
platform = espressif32@6.9.0
board = esp32dev
board_build.partitions = partitions_ota_4mb.csv

The repository pins the ESP32 platform because the gateway uses an older ETH.begin() signature for the LAN8720 interface. Comments in the configuration identify the target as an ESP32-WROOM with a LAN8720 and explain that newer ESP32 Arduino releases changed the Ethernet API.

Existing Ethernet Initialization Model

The earlier bridge-poe validation firmware documents the working startup sequence:

1. Configure the LAN8720 pin map.
2. Call ETH.begin().
3. Wait for DHCP and an Ethernet IP address.
4. Start the microReticulum UDP interface.
5. Form a Reticulum link with a Python peer.
6. Transfer resource payloads over wired Ethernet.

The bridge test completed 5 KB and 10 KB Reticulum resources with SHA-256 verification. The repository also reports successful Ethernet OTA on a PoE-powered board. This validation project was later superseded by the full gateway builds.

A central implementation detail is that microReticulum’s original Arduino UDP interface assumed Wi-Fi. MeshCam removed the hard-coded Wi-Fi startup and allowed the WiFiUDP object to operate through the ESP32 lwIP stack after Ethernet was initialized. That works because both Wi-Fi and LAN8720 Ethernet are exposed through the same underlying ESP32 network stack.

W5500 Integration Architecture

Replacing the LAN8720 with a W5500 would require a new build target, such as a dedicated w5500-gateway environment, rather than changing the existing PoE target.

A practical integration sequence would be:

1. Add board-specific SPI, chip-select, reset, and interrupt definitions.
2. Initialize the W5500 before starting Reticulum interfaces.
3. Run DHCP or apply a static network configuration.
4. Create a UDP adapter compatible with microReticulum’s interface contract.
5. Bind the adapter to the existing Reticulum UDP port.
6. Add a W5500-compatible TCP client for ingest uploads.
7. Verify DNS, TLS, time synchronization, web status, and OTA separately.
8. Preserve the existing LoRa interface and Resource-completion handlers.

The current design assumes that UDP, HTTP clients, the status server, and OTA share the ESP32’s native network abstraction. A W5500 port should therefore introduce a narrow transport abstraction rather than scattering W5500-specific socket calls throughout main.cpp.

The most important boundary is:

Gateway business logic
    ├── completed Resource handling
    ├── ingest metadata construction
    ├── adaptive radio control
    └── telemetry
             ↓
Network transport abstraction
    ├── existing ESP32 Wi-Fi
    ├── existing LAN8720/lwIP
    └── proposed W5500 socket backend

This keeps Reticulum resource handling independent from the physical Ethernet controller.

Practical Tips / Pitfalls

• Confirm that the selected HTTP and TLS libraries can operate over W5500 sockets before redesigning the hardware. Plain UDP support does not prove that HTTPS ingestion will work.
• Avoid sharing the SX1262 and W5500 on an SPI bus without separate chip-select control and explicit transaction settings. The radio and Ethernet controller may require different SPI modes or clock limits.
• Allocate W5500 socket memory around actual gateway traffic. Reticulum UDP, HTTPS upload, DNS, NTP, status access, and OTA can compete for the controller’s eight sockets.
• Preserve completed images until the server acknowledges ingestion. Ethernet link recovery should not cause the gateway to discard a LoRa resource that arrived successfully.
• Use the W5500 interrupt output for link and socket events where possible, but retain watchdog-based recovery for missed interrupts or stalled TCP states.
• Plan PoE separately. W5500 provides Ethernet networking but does not implement the powered-device side of IEEE 802.3af; a PoE PD controller and isolated power stage are still required.
• Test large JPEG uploads rather than only small UDP packets. The existing ESP32-WROOM validation found memory pressure when originating larger Reticulum resources, demonstrating that transport success with small payloads does not prove full application stability.

FAQ

Q: Why would a MeshCam gateway use the W5500?

The W5500 can provide wired IPv4 networking through SPI without using the ESP32’s RMII peripheral or requiring the application to process the full TCP/IP stack in software. This can simplify custom gateway PCB routing and reduce the number of dedicated Ethernet pins. It is most useful when the gateway’s required services can be mapped cleanly onto the W5500’s eight hardware sockets.

Q: How would the W5500 connect to the MeshCam gateway platform?

It would connect to the ESP32 through SPI using SCK, MOSI, MISO, and chip select, plus reset and optionally interrupt. The SPI bus could be shared with the SX1262 only if each device has an independent chip-select signal and the firmware wraps every transaction with the correct SPI configuration. A separate SPI host is preferable when sufficient ESP32 pins are available.

Q: What role would the W5500 play in this project?

The W5500 would carry gateway-side IP traffic. That includes Reticulum-over-UDP packets, image-ingest connections, telemetry, and management traffic. It would not receive camera images directly from the leaf nodes and would not replace the SX1262; LoRa remains the field network between cameras and the gateway.

Q: Can beginners add a W5500 to MeshCam?

The electrical connection is manageable for a developer familiar with ESP32 SPI peripherals, but the firmware port is not a basic Ethernet example. The developer must understand microReticulum interfaces, UDP transport, TCP socket lifecycles, HTTPS client compatibility, DHCP, DNS, reconnect handling, and SPI bus arbitration. A UDP-only validation bridge should be completed before attempting the full gateway.

Q: How does W5500 compare with the project’s LAN8720 interface?

LAN8720 connects through RMII and integrates with the ESP32’s native Ethernet and lwIP path, which lets existing Arduino UDP, HTTP, and OTA components share a familiar network interface. W5500 connects through SPI and offloads TCP/IP socket processing, but libraries must explicitly support its socket model. LAN8720 offers tighter ESP32 stack integration and higher raw interface bandwidth; W5500 uses fewer specialized pins and provides hardware-managed sockets