Take In Any Wireless Protocol, Get Power and Internet from a Single LAN Cable — 'REPEAT', an IoT Gateway Built on PoE and W5100S

One-Line Summary

An nRF5340-based IoT gateway that bridges data received over BLE to wired Ethernet. On hardware that can extend to Zigbee, Thread, and Matter, the W5100S handles the 100Mbit wired link, and PoE delivers power through a single LAN cable.

What Is This Project?

REPEAT is a smart IoT gateway built around the nRF5340 as its main SoC. It aims to be the bridge (gateway) that carries data from wireless IoT devices to a home or building network over wired Ethernet.

• Wireless it can support: the nRF5340 is an SoC capable of BLE, Zigbee, Thread, and Matter.
• What's actually provided: a BLE→MQTT gateway example is implemented in the repository.
• Room to extend: Zigbee, Thread, and Matter are directions the same hardware can grow into.

Two points stand out about this project.

• A gateway that chose wired: even though it takes in wireless, it chose wired rather than wireless (Wi-Fi) for its own network connection.
• PoE support: that wired port supports PoE (Power over Ethernet), so it receives both data and power over a single LAN cable.

Here, the WIZnet W5100S takes on the role of the 100Mbit Ethernet MAC. Zephyr has a driver for the W5500 but no dedicated driver for the W5100/W5100S, so the developer wrote and published a custom driver adapting the existing W5500 driver to the W5100S.

What WIZnet Brings: The Wired Axis That Attaches the Gateway to the Network

The paradox of a wireless IoT gateway is that the gateway itself must stay reliably attached to the network. Even if it takes in dozens of BLE and Zigbee devices, they all become useless if the gateway loses its upstream connection. REPEAT secures this upstream link with W5100S wired Ethernet.

The Path the Signal Travels

The W5100S connects to the nRF5340's SPI4 bus at 32MHz to provide 100Mbit wired Ethernet. It's specified in the board definition (Device Tree) as a wiznet,w5100-compatible node, with interrupt and reset GPIOs wired up. Data the nRF5340 receives wirelessly goes out as standard Ethernet through this W5100S.

They Wrote the Zephyr Driver Themselves

This is the most impressive part of REPEAT. Zephyr RTOS has an Ethernet driver for the W5500, but no dedicated driver for the W5100/W5100S. The developer identified this gap and, based on the existing W5500 driver, wrote a custom driver — adjusting memory addressing, SPI frame structure, and register addressing for the W5100S — and published it in a separate repository.

Thanks to this, in the example code the W5100S connects straight into Zephyr's L2 Ethernet, socket, and MQTT stacks with just one line, CONFIG_ETH_W5100=y, and a Device Tree node. In other words, this project is both an application using the W5100S and a contribution that adds W5100S support to the Zephyr ecosystem.

Why Wired (W5100S) + PoE?

A gateway is usually installed permanently at one spot in a home. Here Wi-Fi is vulnerable to interference and latency, and a power adapter constrains placement to where an outlet is. REPEAT's choice solves both at once.

• Wired Ethernet (W5100S): A stable, deterministic connection free of wireless interference. Especially for a gateway handling sub-GHz and 2.4GHz radio, making the upstream link wireless too can cause self-interference — wired avoids that.
• PoE (802.3af): Supplies data and power together over a single LAN cable. Since it draws power from a switch or injector without a separate adapter, placement is free and wiring is clean.

Here's how the W5100S is used:

• The chip itself: an Ethernet controller with TCP/IP built into hardware.
• In this project: used in MACRAW mode with Zephyr's network stack, handling Ethernet frame transmission/reception and the physical layer (MAC/PHY).
• TCP/IP processing: handled by Zephyr's software stack, not the chip's hardware stack.
• Connection: communicates with the nRF5340 over SPI (32MHz) to secure a 100Mbit wired link.

How It Works: The BLE-to-MQTT Gateway Example

The repository includes a BLE→MQTT gateway example that demonstrates REPEAT's function. It works like this.

1. Wireless reception: The nRF5340 receives all nearby BLE advertisement packets in observer mode.
2. Data assembly: From each advertisement, it extracts the sender's MAC address, RSSI (signal strength), and raw data, and builds a JSON.
3. Wired transmission (W5100S): It sends this to an MQTT broker over W5100S Ethernet. The topic is of the form /repeat/ble/<MAC address>.

In short, it shows the archetype of a gateway that "gathers BLE signals scattered over the air → normalizes and forwards them over wired MQTT." The nRF5340's wireless reception and the W5100S's wired transmission connect naturally on top of Zephyr's socket API.

The example also ships with overlays, so you can experiment with various transport options such as MQTT over TLS, TLS offload, SOCKS5 proxy, and WebSocket.

What's Worth Noting

• A wireless gateway with a wired upstream: A gateway that takes in wireless devices attaches to the network over W5100S wired. The design philosophy is clear — "the more a device deals in wireless, the more its own backhaul benefits from being wired."
• A single LAN cable, thanks to PoE: With 802.3af PoE (SI3402), it handles data and power over one LAN cable. An ideal configuration for a permanently installed gateway, free of power-wiring constraints.
• A self-made, published Zephyr W5100S driver: It created and published a W5100S driver — absent from Zephyr — based on the W5500 driver. It becomes a practical starting point for developers who want the same nRF5340 + Zephyr + W5100S combination.
• Fully open hardware: An open-hardware design with the custom PCB's KiCad project and schematic published. It integrates an nRF5340 dual-core + nRF21540 RF frontend + W5100S + PoE on one board.
• Extensible multi-protocol hardware: the nRF5340 is a dual-core SoC with separate app and network cores, capable of BLE as well as Zigbee, Thread, and Matter. The provided example is BLE→MQTT, but there's ample room to extend to other wireless gateways on the same hardware. Adding W5100S wired lets it handle wireless and wired in one device.

Use Cases

• BLE sensor collection gateway: Gather scattered BLE beacon/sensor data and reliably send it to a server over wired MQTT
• Extend to a Matter/Thread gateway: Since the nRF5340 supports Matter and Thread, it can extend into a gateway linking wireless Matter/Thread devices to a wired backbone
• PoE-based commercial installation: Install the gateway with only a LAN cable even where there's no outlet, such as ceilings or walls
• Extend to a Zigbee hub: Can also be applied as a hub that takes in wireless Zigbee devices and bridges them to a wired network
• Interference-sensitive environments: Installations that handle sub-GHz and 2.4GHz radio while needing to avoid self-interference on the upstream link

Comparison with Related Projects on WIZnet Makers

WIZnet Makers (maker.wiznet.io) also hosts projects with points of contact to REPEAT. Here's a comparison with two whose actual content we verified.

BLE to Ethernet Thin Gateway (eric_g) A gateway that collects BLE heart-rate data with nRF51 + WIZ550io (W5500) and transmits it to a cloud server over Ethernet. The structure is Data Sender (BLE) → Data Collector (nRF51 + WIZnet Ethernet) → cloud.

• Similarities: The core gateway idea — "put data received over BLE onto the upstream network via WIZnet Ethernet" — is exactly the same as REPEAT. The combination of a Nordic nRF series + WIZnet Ethernet is identical too.
• Differences: Where eric_g's project is a relatively simple collector handling a single BLE protocol, REPEAT implements a BLE→MQTT example on hardware extensible to Zigbee/Thread/Matter, and adds PoE power, a self-made Zephyr W5100S driver, and a custom PCB — a more evolved form. They're close to the early and mature forms of the same gateway lineage.

W5100S-EVB-PICO Custom Board in Zephyr (TheoIm) A technical write-up on porting the W5100S-EVB-PICO (RP2040) board into the Zephyr environment as a custom board. It explains the process of cloning and modifying the rpi_pico board definition to make a W5100S board.

• Similarities: The task of "creating a custom board definition to use the W5100S in Zephyr" overlaps exactly with REPEAT. REPEAT also defines the Device Tree of its own board (repeat) and registers a W5100S node.
• Differences: TheoIm's article focuses on the introductory methodology of getting the off-the-shelf W5100S-EVB-PICO board onto Zephyr. REPEAT goes a step further — it wrote a driver adapting Zephyr's existing W5500 driver for the W5100S and integrated it into its own hardware (nRF5340 + PoE). It went beyond board porting to a driver contribution.

In short, the two threads — "building a BLE gateway with Nordic nRF + WIZnet Ethernet" and "using the W5100S in Zephyr" — already exist on Makers. What sets REPEAT apart is combining the two and raising the level of completeness with PoE, extensible multi-protocol hardware, a self-made driver, and a custom PCB.

Tech Stack Summary

FAQ

Q. What role does the W5100S play? The W5100S is REPEAT's 100Mbit wired Ethernet MAC. Connected to the nRF5340 over SPI (32MHz), it's the path that sends wirelessly received data out to the wired network. The W5100S chip itself embeds hardware TCP/IP, but in this project it works with the Zephyr network stack in MACRAW mode, acting as the Ethernet MAC/PHY while TCP/IP is handled by Zephyr's software stack.

Q. It's a wireless gateway — why connect it over wired? The wireless devices below only have meaning if the gateway itself stays reliably attached to the upstream network. Wired Ethernet is free of wireless interference and latency, and especially for a device handling sub-GHz and 2.4GHz radio, it avoids the self-interference that making the upstream link wireless too could cause.

Q. Why does PoE matter? REPEAT supports 802.3af PoE. Because it receives data and power simultaneously over a single LAN cable, it can be installed wherever you like without a separate power adapter or outlet. It's an especially good fit for a gateway that must stay always on.

Q. Can you use the W5100S directly in Zephyr? Zephyr has a driver for the W5500 but none dedicated to the W5100/W5100S. So this project's developer wrote a custom driver adapting the W5500 driver for the W5100S and published it in a separate repository. With this driver installed, you can use the W5100S in Zephyr's standard network stack with just the CONFIG_ETH_W5100=y setting and a Device Tree node.

Q. Which wireless protocols does it support? The main SoC, the nRF5340, is capable of BLE, Zigbee, Thread, and Matter. Its dual-core structure with separate application and network cores is favorable for such multi-protocol handling. That said, the example actually provided in the repository is a BLE→MQTT gateway, and Zigbee/Thread/Matter are directions the same hardware can extend to.

Project Links

• GitHub: WojtaCZ/repeat
• Zephyr W5100S driver: WojtaCZ/zephyr-w5100
• Hardware (KiCad): WojtaCZ/repeat-hw
• WIZnet W5100S: https://docs.wiznet.io/Product/Chip/Ethernet/W5100S

Related Projects on WIZnet Makers

• BLE to Ethernet Thin Gateway (eric_g)
• W5100S-EVB-PICO Custom Board in Zephyr (TheoIm)