---
title: "XR-FreeD_to_UDP"
url: "https://maker.wiznet.io/irina/projects/xr-freed-to-udp/"
markdown_url: "https://maker.wiznet.io/irina/projects/xr-freed-to-udp/md"
type: "UCC: User Created Content"
author: "SBS-NCENTER"
author_url: "https://github.com/SBS-NCENTER/XR-FreeD_to_UDP"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "SBS-NCENTER"
original_url: "https://github.com/SBS-NCENTER/XR-FreeD_to_UDP"
published: "2026-06-19"
language: "en"
likes: 0
views: 204
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# XR-FreeD_to_UDP

> An innovative XR-FreeD to UDP tracking system powered by Wiznet NanoBanana, enabling real-time, low-latency camera data stream for virtual production.

Original author: SBS-NCENTER (source: https://github.com/SBS-NCENTER/XR-FreeD_to_UDP)

## Article

### **Overview**

Modern virtual production (XR) stages live on the network. Engines like Unreal Engine, Pixotope, and Vizrt expect camera tracking data to arrive as **UDP packets** over Ethernet. But a huge installed base of broadcast camera-tracking hardware still speaks **FreeD (D1) over RS-422 serial** — a point-to-point legacy link with no concept of an IP network.

**XR-FreeD_to_UDP** closes that gap. It is an Arduino-based protocol converter that reads 29-byte FreeD D1 frames from an RS-422 line and re-broadcasts them as UDP unicast packets to up to four production engines simultaneously. The interesting part — and the reason this is a useful W5500 reference — is everything that has to happen on the **Ethernet side** to keep a 60 Hz tracking stream flowing 24/7 without a single dropped frame or stalled socket.

The W5500 hardwired TCP/IP controller does the heavy lifting: per-target sockets, hardware MAC resolution, and register-level ARP tuning that a software stack on a small MCU could never sustain at this packet rate.

---

### **What the Project Implements**

The converter is a complete, field-deployed tool rather than a demo. Implemented and verified features include:

- **FreeD D1 capture** — 29-byte frames (pan/tilt/roll, XYZ position, zoom, focus, checksum) parsed at 60 Hz over 38400 bps RS-422.

- **Multi-target UDP distribution** — up to **4 simultaneous unicast destinations**, each with its own dedicated W5500 socket and synchronized transmission.

- **Per-target socket caching** — the W5500 resolves each target's MAC address once via ARP, then reuses the socket; this cuts ARP traffic from ~60 requests/sec/target down to a one-time handshake.

- **Remote control over UDP (port 50998)** — operators toggle targets on/off from any LAN host with no recompile; changes persist to EEPROM.

- **Diagnostic broadcasting (port 50999)** — a status snapshot (uptime, IP, frame count, per-target state) is sent to the subnet broadcast address every 5 seconds.

- **Lens remapping** — configurable zoom/focus input→output scaling.

- **Resilience layer** — hardware watchdog (~5.59 s), escalating backoff (500 ms → 4 s) for unreachable targets, and smart DHCP fallback to a cached last-lease IP.

---

### **W5500 and FreeD-to-UDP Architecture**

![](https://maker.wiznet.io/upload/ckeditor5/617936971%5F1781879895%2Epng)

The data path is deliberately simple, which is what lets it run reliably for weeks:

```plaintext
 FreeD camera ──RS-422──▶ YL-128 (RS-422→TTL) 
 								──D0──▶ Arduino UNO R4 WiFi
                                                         						 │
                                                   parse 29-byte D1 frame
                                                     						     │
                                              ┌───────────┴───────────┐
                                              ▼     W5500 Ethernet     ▼
                                    socket 0 → Engine A      socket 1 → Engine B
                                    socket 2 → Engine C      socket 3 → Engine D
                                              (UDP unicast, 60 Hz)
```

**Hardware**

- Arduino UNO R4 WiFi (Renesas RA4M1)

- W5500 Ethernet Shield v2

- YL-128 RS-422→TTL converter, with 120 Ω bias resistors for signal conditioning

**Why the W5500 matters here**

![](https://maker.wiznet.io/upload/ckeditor5/617936971%5F1781879937%2Epng)

A naive software UDP stack re-runs ARP and rebuilds socket state constantly when packets fly at 60 Hz to several destinations. This project leans on W5500 hardware features to avoid that:

- **Hardware sockets per target** — eight independent hardwired sockets mean each engine gets a stable, isolated socket. No head-of-line blocking; an unreachable target backs off without stalling the healthy ones.

- **Register-level ARP tuning** — the firmware patches W5500 registers to reduce ARP timeout from the default **3.2 s down to 80 ms**, so a destination switch or a dropped target never freezes the transmit loop.

- **MAC caching** — once resolved, the W5500 keeps the target MAC, eliminating the "ARP flood" that plagues rapid destination switching on broadcast LANs.

---

### **Embedded-Design Reference Value**

![](https://maker.wiznet.io/upload/ckeditor5/617936971%5F1781879969%2Epng)

Beyond the protocol bridge itself, the codebase is a good reference for **24/7 embedded networking discipline**:

- **No dynamic memory allocation** — avoids heap fragmentation over continuous operation.

- **Wrap-safe elapsed-time logic** — correctly handles the 49.7-day `millis()` overflow.

- **Serial budget enforcement** — debug logging is rate-limited so it can never block packet capture.

- **DHCP storm mitigation** — a 1-second gate plus 60-second holdoff on renewal failures prevents blocking loops.

- **EEPROM persistence** — all target/lens settings survive reboots.

These are exactly the patterns a developer building any always-on W5500 product (industrial gateway, telemetry bridge, broadcast tool) needs to get right.

---

### **Practical Limits**

To set expectations honestly:

- The converter is **unicast to a fixed set of up to 4 targets**; it is not a general multicast distributor.

- It targets the **FreeD D1** frame format specifically — other tracking dialects would need parser changes.

- It depends on the **W5500 register patch** for low ARP timeout; porting to a different Ethernet controller would require revisiting that tuning.

- RS-422 wiring (bias resistors, A/B polarity) must be correct — a common first-time deployment pitfall.

---

### **Where It Fits**

This project is most useful for:

- **XR / virtual production engineers** integrating legacy serial camera tracking into Unreal/Pixotope/Vizrt pipelines.

- **Broadcast and OB-van operators** who need a rugged, low-cost serial-to-IP tracking bridge.

- **Embedded developers** looking for a real-world W5500 example of multi-socket UDP, ARP tuning, and 24/7 resilience patterns.

Verified scenarios from the project include 24/7 studio streaming, 4-camera XR stages, mobile OB vans, and 60 fps+ tracking with sub-millisecond converter latency.

---

### **Setup at a GlanceWiring:** RS-422 TX+/TX- → YL-128 A/B (with 120 Ω bias resistors) → RXD to Arduino D0.

**Build & flash (PlatformIO):**

```plaintext
pio run -t upload
pio device monitor -b 115200
```

**Configure a target (serial console):**

```plaintext
target 0 ip 192.168.1.100
target 0 port 50001
target 0 on
save
```

**Toggle a target remotely (no recompile):**

```plaintext
echo "target 1 off" | nc -u -w1 <arduino-ip> 50998
```

Windows operators can also use the bundled `.bat` tools: `xrfd_dashboard.bat` (web UI), `xrfd_shell.bat` (interactive CLI with IP auto-discovery), and `xrfd_monitor.bat` (live diagnostics).

---

### **Related WIZnet Maker Projects**

Other WIZnet Maker projects that bridge a serial/industrial protocol to the network over W5500 — useful side-by-side references:

- [**Art-Net to DMX Converter**](https://maker.wiznet.io/louis_m/projects/artnet-to-dmx-converter/) — The closest conceptual cousin: an Arduino Nano + W5500 turns network **Art-Net (UDP)** lighting data into **RS485 DMX** for stage/broadcast gear. Same idea as XR-FreeD, in the opposite direction (network → serial).

- [**Arduino-based Modbus RTU to Modbus TCP/UDP Gateway (with web interface)**](https://maker.wiznet.io/2021/05/07/arduino-based-modbus-rtu-to-modbus-tcp-udp-gateway-with-web-interface/) — An RS485 serial stream re-exposed over **TCP/UDP with up to 8 W5500 sockets** and a browser dashboard — a direct parallel to XR-FreeD's multi-socket + web-dashboard architecture.

- [**W55RP20: Serial to Ethernet Design**](https://maker.wiznet.io/Alan/projects/w55rp20--serial-to-ethernet-design/) — A dedicated serial-to-Ethernet reference (W5500 + RP2040) with ready-made **UART / RS-232 / RS-422 / RS-485** firmware — relevant if you want to move this kind of converter onto a single-chip platform.

- [**How Can W5500 Ethernet Validate a Go LwM2M Server for Edge Routers?**](https://maker.wiznet.io/Benjamin/projects/how-can-w5500-ethernet-validate-a-go-lwm2m-server-for-edge-routers/) — W5500 used as a protocol-validation endpoint; the reference post this article's format follows.

---

### **FAQQ. Do I need the exact Arduino UNO R4 WiFi board?**
Any board pairing with a W5500 shield can work, but the firmware's register patch and watchdog timing are tuned for the RA4M1 + W5500 v2 combination. Other boards may need adjustment.

**Q. Why UDP and not TCP?**
Camera tracking is real-time and loss-tolerant — a late frame is useless. UDP unicast at 60 Hz with no retransmit is exactly the right transport, and the W5500's hardware sockets make multi-target sending cheap.

**Q. Can it drive more than 4 engines?**
The W5500 has 8 hardware sockets; the project uses 4 for targets and reserves the rest for control/diagnostics. Extending the target count is feasible with code changes.

**Q. Is this production-ready?**
Yes — it has verified 24/7 broadcast use. The resilience layer (watchdog, backoff, DHCP fallback, ARP tuning) exists precisely because it runs in live studios.

**Q. What makes this a good W5500 learning resource?**
It shows the W5500 doing what a soft stack can't sustain: per-target hardware sockets, register-level ARP timeout tuning, and zero-allocation operation for weeks at a time.

---

---

## **한국어 (Korean)**

### **개요**

최신 버추얼 프로덕션(XR) 스튜디오는 네트워크 위에서 돌아갑니다. Unreal Engine, Pixotope, Vizrt 같은 엔진은 카메라 트래킹 데이터를 **이더넷 기반 UDP 패킷**으로 받기를 기대합니다. 하지만 현장에 깔려 있는 방대한 방송용 카메라 트래킹 장비는 여전히 **RS-422 시리얼 위의 FreeD(D1) 프로토콜**을 사용합니다 — IP 네트워크 개념이 없는 점대점 레거시 링크죠.

**XR-FreeD_to_UDP**는 이 간극을 메웁니다. RS-422 라인에서 29바이트 FreeD D1 프레임을 읽어, 최대 4개의 프로덕션 엔진에 동시에 UDP 유니캐스트로 재전송하는 Arduino 기반 프로토콜 변환기입니다. 흥미로운 지점 — 그리고 이 프로젝트가 좋은 W5500 레퍼런스인 이유 — 는 60 Hz 트래킹 스트림을 단 한 프레임도 빠뜨리지 않고 24시간 흘려보내기 위해 **이더넷 쪽에서** 벌어져야 하는 모든 처리에 있습니다.

W5500 하드와이어드 TCP/IP 컨트롤러가 무거운 일을 도맡습니다: 타깃별 소켓, 하드웨어 MAC 해석, 그리고 작은 MCU의 소프트웨어 스택으로는 이 패킷 속도에서 결코 버틸 수 없는 레지스터 수준의 ARP 튜닝까지요.

### **구현된 기능**

이 변환기는 데모가 아니라 현장에 배포된 완성형 도구입니다. 구현·검증된 기능은 다음과 같습니다.

- **FreeD D1 캡처** — 29바이트 프레임(팬/틸트/롤, XYZ 위치, 줌, 포커스, 체크섬)을 38400 bps RS-422에서 60 Hz로 파싱

- **다중 타깃 UDP 분배** — 최대 **4개 유니캐스트 목적지**, 각각 전용 W5500 소켓과 동기화 전송

- **타깃별 소켓 캐싱** — W5500이 타깃 MAC을 ARP로 한 번만 해석 후 재사용 → 초당 ~60회/타깃의 ARP를 1회 핸드셰이크로 감소

- **UDP 원격 제어(포트 50998)** — 재컴파일 없이 LAN의 어떤 호스트에서도 타깃 on/off, 설정은 EEPROM에 저장

- **진단 브로드캐스트(포트 50999)** — 5초마다 상태 스냅샷(가동시간, IP, 프레임 수, 타깃 상태)을 서브넷 브로드캐스트로 전송

- **렌즈 리매핑** — 줌/포커스 입력→출력 스케일링 설정 가능

- **복원력 계층** — 하드웨어 워치독(~5.59초), 도달 불가 타깃에 대한 점증 백오프(500 ms → 4 s), 캐시된 마지막 임대 IP로의 스마트 DHCP 폴백

### **W5500 및 변환 아키텍처**

![](https://maker.wiznet.io/upload/ckeditor5/617936971%5F1781879900%2Epng)

데이터 경로는 의도적으로 단순합니다. 그래서 수 주간 안정적으로 동작합니다.

```plaintext
 FreeD 카메라 ──RS-422──▶ YL-128(RS-422→TTL) 
 										──D0──▶ Arduino UNO R4 WiFi
                                                         						 │
                                                  29바이트 D1 프레임 파싱
                                                          						│
                                              ┌───────────┴───────────┐
                                              ▼      W5500 이더넷       ▼
                        	            소켓 0 → 엔진 A    		  소켓 1 → 엔진 B
                                  		소켓 2 → 엔진 C      		소켓 3 → 엔진 D
                                            (UDP 유니캐스트, 60 Hz)
```

**하드웨어**

- Arduino UNO R4 WiFi (Renesas RA4M1)

- W5500 Ethernet Shield v2

- YL-128 RS-422→TTL 변환기, 신호 정합용 120 Ω 바이어스 저항

**여기서 W5500이 중요한 이유**

![](https://maker.wiznet.io/upload/ckeditor5/617936971%5F1781879930%2Epng)

소프트웨어 UDP 스택은 60 Hz로 여러 목적지에 패킷이 쏟아질 때 ARP를 끊임없이 재실행하고 소켓 상태를 재구성합니다. 이 프로젝트는 이를 피하기 위해 W5500 하드웨어 기능에 의존합니다.

- **타깃별 하드웨어 소켓** — 8개의 독립 하드와이어드 소켓 덕분에 각 엔진이 안정적이고 격리된 소켓을 갖습니다. HOL 블로킹이 없고, 도달 불가 타깃은 정상 타깃을 멈추게 하지 않으면서 백오프합니다.

- **레지스터 수준 ARP 튜닝** — 펌웨어가 W5500 레지스터를 패치해 ARP 타임아웃을 기본 **3.2초에서 80 ms로** 낮춥니다. 목적지 전환이나 타깃 유실이 송신 루프를 멈추지 않게 합니다.

- **MAC 캐싱** — 한 번 해석되면 W5500이 타깃 MAC을 유지해, 브로드캐스트 LAN에서 잦은 목적지 전환 시 발생하는 "ARP 폭주"를 제거합니다.

### **임베디드 설계 레퍼런스 가치**

![](https://maker.wiznet.io/upload/ckeditor5/617936971%5F1781879988%2Epng)

프로토콜 브리지 자체를 넘어, 이 코드베이스는 **24/7 임베디드 네트워킹 규율**의 좋은 참고 자료입니다.

- **동적 메모리 할당 없음** — 연속 운영 중 힙 단편화 방지

- **랩 세이프 경과시간 로직** — 49.7일 `millis()` 오버플로를 올바르게 처리

- **시리얼 예산 제한** — 디버그 로깅이 패킷 캡처를 절대 막지 못하도록 속도 제한

- **DHCP 폭주 완화** — 1초 게이트 + 갱신 실패 시 60초 홀드오프로 블로킹 루프 방지

- **EEPROM 영속성** — 모든 타깃/렌즈 설정이 재부팅 후에도 유지

상시 동작하는 W5500 제품(산업용 게이트웨이, 텔레메트리 브리지, 방송 도구 등)을 만드는 개발자가 반드시 제대로 해야 할 패턴들입니다.

### **실용적 한계**

기대치를 솔직히 정리하면:

- 최대 4개 고정 타깃으로의 **유니캐스트**이며, 범용 멀티캐스트 분배기는 아닙니다.

- **FreeD D1** 프레임 포맷에 특화되어 있어, 다른 트래킹 방언은 파서 수정이 필요합니다.

- 낮은 ARP 타임아웃을 위해 **W5500 레지스터 패치**에 의존하므로, 다른 이더넷 컨트롤러로 포팅하면 해당 튜닝을 다시 검토해야 합니다.

- RS-422 배선(바이어스 저항, A/B 극성)이 정확해야 합니다 — 첫 배포 시 흔한 함정입니다.

### **어디에 적합한가**

- 레거시 시리얼 카메라 트래킹을 Unreal/Pixotope/Vizrt 파이프라인에 통합하려는 **XR/버추얼 프로덕션 엔지니어**

- 견고하고 저비용인 시리얼→IP 트래킹 브리지가 필요한 **방송·OB밴 운영자**

- 멀티 소켓 UDP, ARP 튜닝, 24/7 복원력 패턴의 실전 W5500 예제를 찾는 **임베디드 개발자**

검증된 시나리오: 24/7 스튜디오 스트리밍, 4카메라 XR 스테이지, 이동형 OB밴, 변환기 지연 1 ms 미만의 60 fps+ 트래킹.

### **한눈에 보는 설치배선:** RS-422 TX+/TX- → YL-128 A/B(120 Ω 바이어스 저항) → RXD를 Arduino D0에.

**빌드 & 플래시 (PlatformIO):**

```plaintext
pio run -t upload
pio device monitor -b 115200
```

**타깃 설정 (시리얼 콘솔):**

```plaintext
target 0 ip 192.168.1.100
target 0 port 50001
target 0 on
save
```

**원격으로 타깃 토글 (재컴파일 불필요):**

```plaintext
echo "target 1 off" | nc -u -w1 <arduino-ip> 50998
```

Windows 운영자는 동봉된 `.bat` 도구도 사용할 수 있습니다: `xrfd_dashboard.bat`(웹 UI), `xrfd_shell.bat`(IP 자동 탐색 CLI), `xrfd_monitor.bat`(실시간 진단).

### **관련 WIZnet Maker 프로젝트**

W5500로 시리얼/산업용 프로토콜을 네트워크로 잇는 다른 WIZnet Maker 프로젝트들 — 나란히 비교해 볼 만한 레퍼런스입니다.

- [**Art-Net to DMX Converter**](https://maker.wiznet.io/louis_m/projects/artnet-to-dmx-converter/) — 개념적으로 가장 비슷: Arduino Nano + W5500이 네트워크 **Art-Net(UDP)** 조명 데이터를 무대/방송 장비용 **RS485 DMX**로 변환합니다. XR-FreeD와 같은 아이디어를 반대 방향(네트워크 → 시리얼)으로 구현.

- [**Arduino 기반 Modbus RTU → Modbus TCP/UDP 게이트웨이 (웹 인터페이스 포함)**](https://maker.wiznet.io/2021/05/07/arduino-based-modbus-rtu-to-modbus-tcp-udp-gateway-with-web-interface/) — RS485 시리얼 스트림을 **최대 8개 W5500 소켓의 TCP/UDP**와 브라우저 대시보드로 재노출 — XR-FreeD의 다중 소켓 + 웹 대시보드 구조와 직접적으로 대응됩니다.

- [**W55RP20: Serial to Ethernet Design**](https://maker.wiznet.io/Alan/projects/w55rp20--serial-to-ethernet-design/) — W5500 + RP2040 기반 전용 시리얼→이더넷 레퍼런스로, **UART / RS-232 / RS-422 / RS-485** 펌웨어가 준비되어 있습니다. 이런 변환기를 단일 칩 플랫폼으로 옮기고 싶을 때 유용.

- [**How Can W5500 Ethernet Validate a Go LwM2M Server for Edge Routers?**](https://maker.wiznet.io/Benjamin/projects/how-can-w5500-ethernet-validate-a-go-lwm2m-server-for-edge-routers/) — 프로토콜 검증 엔드포인트로서의 W5500. 이 글의 형식이 따른 참고 글입니다.

### **FAQQ. 반드시 Arduino UNO R4 WiFi 보드가 필요한가요?**
W5500 실드와 짝을 이루는 보드면 동작하지만, 펌웨어의 레지스터 패치와 워치독 타이밍은 RA4M1 + W5500 v2 조합에 맞춰져 있습니다. 다른 보드는 조정이 필요할 수 있습니다.

**Q. 왜 TCP가 아니라 UDP인가요?**
카메라 트래킹은 실시간이고 손실 허용적입니다 — 늦게 온 프레임은 쓸모가 없죠. 재전송 없는 60 Hz UDP 유니캐스트가 정답이고, W5500 하드웨어 소켓이 다중 타깃 전송을 저렴하게 만듭니다.

**Q. 엔진을 4개보다 많이 구동할 수 있나요?**
W5500은 소켓 8개를 가집니다. 프로젝트는 4개를 타깃에, 나머지를 제어/진단에 씁니다. 코드 수정으로 타깃 수 확장이 가능합니다.

**Q. 프로덕션에 바로 쓸 수 있나요?**
네 — 24/7 방송 사용이 검증되었습니다. 워치독·백오프·DHCP 폴백·ARP 튜닝으로 이뤄진 복원력 계층은 실제 라이브 스튜디오에서 돌기 때문에 존재합니다.

**Q. 왜 좋은 W5500 학습 자료인가요?**
소프트 스택이 버틸 수 없는 일을 W5500이 하는 모습을 보여주기 때문입니다: 타깃별 하드웨어 소켓, 레지스터 수준 ARP 타임아웃 튜닝, 그리고 수 주간 무할당 운영.

---

Source: https://maker.wiznet.io/irina/projects/xr-freed-to-udp/