---
title: "esp32_mmdvm_hotspot"
url: "https://maker.wiznet.io/TheoIm/projects/esp32-mmdvm-hotspot/"
markdown_url: "https://maker.wiznet.io/TheoIm/projects/esp32-mmdvm-hotspot/md"
type: "UCC: User Created Content"
author: "Albert Einstein"
author_url: "https://github.com/javastraat/esp32_mmdvm_hotspot"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Albert Einstein"
original_url: "https://github.com/javastraat/esp32_mmdvm_hotspot"
published: "2026-04-02"
language: "en"
hardware: ["WIZnet W5500"]
likes: 0
views: 2871
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# esp32_mmdvm_hotspot

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

Original author: Albert Einstein (source: https://github.com/javastraat/esp32_mmdvm_hotspot)

## Components

- **WIZnet W5500** x 1 ([docs](https://docs.wiznet.io/Product/Chip/Ethernet/W5500))

WIZnet parts: W5500 ([Datasheet](https://docs.wiznet.io/Product/Chip/Ethernet/W5500/datasheet?utm_source=maker&utm_medium=project&utm_campaign=w5500), [product hub](https://maker.wiznet.io/products/w5500/))

## Article

## 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):

```plaintext
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**

```plaintext
#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 :

```plaintext
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

## Tags

#W5500 #ESP32 #MMDVM #DigitalRadio #MQTT #Ethernet #EmbeddedSystems #FreeRTOS #IoT #VPN

---

Source: https://maker.wiznet.io/TheoIm/projects/esp32-mmdvm-hotspot/