esp32_mmdvm_hotspot

How to Build an ESP32 Digital Radio Hotspot with Reliable Networking using W5500

COMPONENTS Hardware components

WIZnet - W5500

x 1

PROJECT DESCRIPTION

What the Project Does

This system can be understood as a self-contained digital radio gateway.

It connects RF communication (via an external modem) to modern IP-based services:

Radio Layer (MMDVM Modem)
Handles digital voice/data protocols such as DMR and POCSAG
ESP32 Core System
Acts as the control plane:
- Runs FreeRTOS tasks for each service
- Manages networking (Wi-Fi / Ethernet)
- Handles logging, storage, and OTA updates
Network Services Layer
Provides connectivity to:
- MQTT brokers (telemetry)
- Telegram bots (alerts)
- WireGuard VPN (secure remote access)
- Web UI (configuration and monitoring)
User Interface Layer
- Web dashboard (status, config, control)
- OLED display for local status

System Analogy

Think of this system as a networked radio base station in a box:

The modem speaks “radio protocol”
The ESP32 translates it into IP traffic
The network stack delivers it to cloud services and users

Where WIZnet Fits

The project uses the WIZnet W5500 as the Ethernet interface, connected to the ESP32 over SPI and integrated into the system’s networking stack.

In this architecture, the W5500 operates as:

A wired Ethernet interface (MAC/PHY over SPI)
A stable transport layer for IP communication
A dedicated network path for services such as MQTT, Web UI, and remote access

Role of W5500 in This System

Within the system, W5500 is responsible for:

Providing reliable wired connectivity alongside the ESP32 networking stack
Enabling continuous IP communication for:
- MQTT telemetry
- Web-based configuration interface
- Remote access services (e.g., VPN)
Acting as the physical network bridge between the embedded system and external infrastructure

Unlike Wi-Fi, this wired path offers:

Consistent latency
Reduced packet loss
Immunity to RF interference

Why It Matters Here

From the codebase analysis :

The system is characterized by:

High task concurrency (multiple FreeRTOS services running in parallel)
Frequent network operations (MQTT, HTTP, OTA, messaging)
Blocking I/O paths (SD card access, web streaming)

These conditions make network stability a critical factor.

Using W5500 as the Ethernet interface provides:

Stable, interference-free communication compared to Wi-Fi
Predictable network behavior under continuous load
Separation of concerns between RF (radio modem) and IP networking
Improved reliability for long-running deployments

Architectural Impact

By introducing a dedicated wired Ethernet interface, the system evolves from:

A wireless-dependent embedded node

to:

A hybrid communication gateway with a stable wired backbone

This is particularly important for MMDVM-based systems, where:

Continuous connectivity is required for protocol synchronization
Network instability directly affects communication quality

In this design, the W5500 strengthens the system by ensuring that:

Network transport remains consistent
Higher-level services (MQTT, Web UI, VPN) operate reliably
The ESP32 can maintain predictable behavior under load

Implementation Notes

1) Existing Network Architecture

From the project structure :

system_wifi.cpp → Wi-Fi manager with fallback logic
system_eth.cpp → LAN8720 Ethernet (RMII)
service_mqtt.cpp → MQTT client
system_webserver.cpp → HTTP server

All networking depends on ESP32’s internal TCP/IP stack (LwIP).

2) Key Architectural Limitation

Example (MQTT payload generation):

json += "{\"id\":\"wifi\",\"label\":\"WiFi\",\"enabled\":true,\"connected\":" +
        String(wifiConn ? "true" : "false") + "},";

Issue:

Dynamic memory allocation
CPU-heavy string concatenation
No hardware offload

Combined with:

15+ concurrent tasks
Continuous network activity

→ Leads to fragmentation and unpredictable latency

3) Conceptual W5500 Integration

Conceptual integration example based on WIZnet ioLibrary

#include "wizchip_conf.h"

// SPI interface binding
reg_wizchip_spi_cbfunc(spi_read, spi_write);

// Allocate socket buffers (8 sockets)
uint8_t txsize[8] = {2,2,2,2,2,2,2,2};
uint8_t rxsize[8] = {2,2,2,2,2,2,2,2};
wizchip_init(txsize, rxsize);

// Network configuration
wiz_NetInfo netinfo = {
    .mac = {0x00,0x08,0xDC,0xAA,0xBB,0xCC},
    .ip  = {192,168,1,50},
    .sn  = {255,255,255,0},
    .gw  = {192,168,1,1}
};

wizchip_setnetinfo(&netinfo);

Where It Connects in This Project

Replace WiFiClient in service_mqtt.cpp
Replace socket layer in system_webserver.cpp
Integrate into system_eth.cpp as alternative backend

4) Critical Code Insight (Why Networking Stability Matters)

From the analysis :

reading = random(20, 30);
cpuUsage = (float)random(0, 100) / 100.0;

This shows:

System observability is unreliable
Debugging performance issues becomes difficult

With W5500:

Network load becomes predictable
Easier to correlate system behavior with actual workload

Practical Tips / Pitfalls

SPI wiring must be stable; avoid long traces at high clock speeds
Use static IP for initial bring-up before enabling DHCP
Monitor socket usage (W5500 supports 8 sockets max)
Avoid mixing Wi-Fi and W5500 without clear routing strategy
Replace String with fixed buffers in hot paths
Ensure proper task prioritization (modem must not be preempted)
Validate Ethernet link status before starting services

FAQ

Q: Why use W5500 instead of ESP32 Wi-Fi in this project?
A: This system runs many concurrent tasks and network services. W5500 offloads TCP/IP processing, reducing CPU load and eliminating Wi-Fi-induced latency jitter that can disrupt real-time radio communication.

Q: How would W5500 connect to the ESP32 here?
A: Via SPI (MISO, MOSI, SCK, CS). It can be integrated as an alternative to LAN8720 in system_eth.cpp, with minimal hardware changes.

Q: What role would W5500 play in this hotspot?
A: It would handle all TCP/IP communication (MQTT, web server, VPN transport), allowing the ESP32 to focus on modem handling and task scheduling.

Q: Can beginners build this system?
A: This is an advanced embedded system involving RF protocols, FreeRTOS, and networking. Prior experience with ESP32 and networking stacks is required.

Q: How does W5500 compare to LAN8720 or LwIP?
A: LAN8720 relies on ESP32’s LwIP stack, consuming CPU and memory. W5500 includes a hardware TCP/IP stack, reducing overhead and improving determinism in multi-tasking systems.

Source

Original Project Analysis: ESP32 MMDVM Hotspot Review
License: Not specified

Wiznet makers