Wiznet makers

Welcome to WIZnet Maker

or

Don't have an account yet?

Welcome to WIZnet Maker

or

Already have account?

Reset Password

Know your password?

Need an account?

irina

Published June 19, 2026 ©

172 UCC

5 WCC

104 VAR

0 Contests

0 Followers

0 Following

Original Link

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.

COMPONENTS
PROJECT DESCRIPTION

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

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

 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

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

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 Glance

Wiring: RS-422 TX+/TX- → YL-128 A/B (with 120 Ω bias resistors) → RXD to Arduino D0.

Build & flash (PlatformIO):

pio run -t upload
pio device monitor -b 115200

Configure a target (serial console):

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

Toggle a target remotely (no recompile):

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).

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

FAQ

Q. 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 및 변환 아키텍처

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

 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이 중요한 이유

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

  • 타깃별 하드웨어 소켓 — 8개의 독립 하드와이어드 소켓 덕분에 각 엔진이 안정적이고 격리된 소켓을 갖습니다. HOL 블로킹이 없고, 도달 불가 타깃은 정상 타깃을 멈추게 하지 않으면서 백오프합니다.
  • 레지스터 수준 ARP 튜닝 — 펌웨어가 W5500 레지스터를 패치해 ARP 타임아웃을 기본 3.2초에서 80 ms로 낮춥니다. 목적지 전환이나 타깃 유실이 송신 루프를 멈추지 않게 합니다.
  • MAC 캐싱 — 한 번 해석되면 W5500이 타깃 MAC을 유지해, 브로드캐스트 LAN에서 잦은 목적지 전환 시 발생하는 "ARP 폭주"를 제거합니다.

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

프로토콜 브리지 자체를 넘어, 이 코드베이스는 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):

pio run -t upload
pio device monitor -b 115200

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

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

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

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 프로젝트들 — 나란히 비교해 볼 만한 레퍼런스입니다.

FAQ

Q. 반드시 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 타임아웃 튜닝, 그리고 수 주간 무할당 운영.

Documents
Comments Write