Wiznet makers

What the Project Does

이 컨트롤러의 데이터 흐름은 “센서 입력 → 네트워크 메시지”로 단순합니다.

입력(Inputs): 3D 조이스틱 2개(여러 축의 가변저항 + 버튼)

취득(Acquisition): 조이스틱의 아날로그 전압을 MCP3208(12-bit ADC) 로 디지털화합니다. 저장소 설명에 따르면 ESP32 내부 ADC는 정확도/재현성 측면에서 제약이 있어(특히 무선 사용 시 영향을 받는 경우) 외부 ADC를 선택한 맥락이 있습니다.

처리(Processing): 펌웨어가 여러 축(예: 6채널)과 버튼 상태를 읽고, 범위를 정규화/스케일링한 뒤 채널별 OSC 주소로 메시지를 구성합니다.

출력(Output): 구성된 OSC 메시지를 네트워크로 송신해, 수신 측(PC 앱, 로봇 컨트롤러, 미디어 엔진 등)에서 매핑하여 동작을 수행합니다.

이 형태는 아래 3가지 사용 사례에 자연스럽게 들어맞습니다.

로보틱스 텔레옵: 조이스틱 축 → 속도/조향/팬틸트/그리퍼/모드 전환 등의 명령으로 매핑 (LAN 상에서 원격 조작)

AV 컨트롤러: OSC를 지원하는 미디어/조명/사운드 시스템에 실시간 파라미터 입력 장치로 연결

상용 프로토타입: 데모/QA/현장 테스트에서 “끊김과 변동”을 줄이고 재현 가능한 유선 컨트롤 엔드포인트로 사용

이미지 출처 : AI 생성

Where WIZnet Fits

이 빌드는 Ethernet 출력에 WIZnet W5500을 사용합니다. 저장소 README에는 “ESP32에도 Ethernet MAC이 있지만, 외부 PHY 보드보다 W5500 개발보드를 구하기 쉽고 프로토타이핑이 빨라서 W5500을 선택했다”는 취지의 설명이 포함되어 있습니다.

아키텍처 관점에서 W5500의 역할은 명확합니다.

ESP32는 입력 샘플링(ADC) → 값 정규화 → OSC 포맷에 집중

W5500은 유선 Ethernet 링크 및 네트워크 송신 경로를 담당

결과적으로 루프는 “읽고 → 가공하고 → 보낸다”로 단순해지고, 컨트롤러에서 중요한 일정한 업데이트 주기와 예측 가능한 동작을 만들기 쉬워집니다.

Practical Tips / Pitfalls

SPI 배선/노이즈: W5500와 ESP32 사이 SPI 라인을 짧게 유지하고, 그라운드 기준을 깔끔하게 잡아야 합니다. CS가 다른 SPI 디바이스와 공유될 경우 충돌이 없도록 설계/펌웨어에서 관리하세요.

링크 업 확인: IP 문제인지 케이블/스위치 문제인지 분리하기 위해, 초기에는 링크 상태(LED/시리얼 로그)를 반드시 확인하세요.

DHCP vs 정적 IP: 개발은 DHCP로 시작해도 되지만, 텔레옵/AV에서 고정 매핑(방화벽, 라우팅, 수신 앱 프리셋)이 필요하면 정적 IP가 운영에 유리합니다.

OSC 전송(대개 UDP): UDP 기반이라면 패킷 유실 가능성을 감안해 수신 측에서 타임아웃/하트비트, 또는 간단한 시퀀스 처리를 고려하세요.

업데이트 레이트 최적화: 지나치게 높은 주기는 네트워크/수신 앱을 불필요하게 압박합니다. 데드밴드(미세 변화 무시)나 고정 주기 송신으로 트래픽을 안정화하세요.

ADC 기준 전압/그라운드: 조이스틱 흔들림(지터)이 심하면 아날로그 기준(3.3V 레퍼런스, 그라운드 루프, 배선)을 재검토하세요. 외부 ADC를 쓰는 이유 자체가 “재현 가능한 입력”을 확보하기 위한 경우가 많습니다.

FAQ (5 questions, all WIZnet-focused)

1) 왜 이 프로젝트는 WIZnet W5500을 선택했나요?
저장소 설명에 따르면, ESP32의 Ethernet MAC을 활용하는 구성도 가능하지만 외부 PHY 보드 기반 개발보다 W5500 개발보드로 프로토타이핑하는 편이 수급/구성 측면에서 빠르고 단순해서 W5500을 선택했습니다. 입력 장치 프로젝트는 초기 bring-up 속도와 재현성이 중요하므로 이런 선택이 흔합니다.

2) W5500은 ESP32에 어떻게 연결하나요?
일반적으로 SPI(SCLK/MOSI/MISO/CS) 로 연결하고, 모듈에 따라 RESET/INT 핀을 추가로 사용하기도 합니다. Arduino Ethernet 계열에서는 보통 Ethernet.init(CS_PIN)과 Ethernet.begin(...) 형태로 초기화합니다.

3) 이 프로젝트에서 W5500은 정확히 어떤 기능을 담당하나요?
조이스틱 입력을 외부 ADC로 읽어 만든 값을 OSC 메시지로 포장한 뒤, 그 메시지를 유선 Ethernet으로 송신하는 네트워크 출력 역할을 맡습니다. 즉, ESP32가 “값을 만들고”, W5500이 “유선으로 내보낸다”는 분업 구조입니다.

4) W5500을 처음 써보는 초보자도 따라갈 수 있나요?
SPI 배선과 기본적인 IP 개념(DHCP/정적 IP, 서브넷, 게이트웨이)을 알고 있다면 가능합니다. 가장 쉬운 순서는 링크 확인 → IP 획득 → 테스트 OSC 송신 → 조이스틱/ADC 루프 결합입니다. PlatformIO를 쓰면 라이브러리 의존성 관리도 한결 수월합니다.

5) 이 용도에서 W5500과 Wi-Fi/소프트 스택 기반 방식은 어떤 차이가 있나요?
이 프로젝트의 핵심은 “입력 업데이트의 일관성”입니다. Wi-Fi나 소프트 스택 접근은 환경/부하에 따라 지연과 변동이 커질 수 있고, 디버깅 변수가 늘어납니다. W5500 기반 유선 출력은 네트워크 경로가 단순하고 상태가 눈에 잘 보이기 때문에(링크/케이블/스위치 등), 텔레옵·AV·데모 환경에서 운영 난이도를 낮추는 선택이 될 수 있습니다.

What the Project Does

This controller’s data flow is simple: “sensor input → network message.”

Inputs: Two 3D joysticks (multiple potentiometer axes + buttons)

Acquisition: The joystick’s analog voltages are digitized using an MCP3208 (12-bit ADC). Based on the repository’s notes, the ESP32’s internal ADC can be limited in accuracy and repeatability (and may be affected when wireless features are active), which is why an external ADC is used.

Processing: Firmware reads multiple axes (e.g., 6 channels) and button states, then normalizes/scales the values and builds OSC messages using per-channel OSC addresses.

Output: The generated OSC messages are sent over the network, where the receiver (PC application, robot controller, media engine, etc.) maps them to actions.

This pattern naturally fits three use cases:

Robotics teleoperation: Joystick axes map to commands such as velocity, steering, pan/tilt, gripper control, or mode switching (remote operation over a LAN).

AV controller: The device becomes a real-time parameter controller for media/lighting/sound systems that support OSC.

Commercial prototyping: A reproducible wired control endpoint helps reduce dropouts and variability during demos, QA, and on-site testing.

Image source: AI-generated.

Where WIZnet Fits

This build uses a WIZnet W5500 for Ethernet output. The project README explains the motivation: while the ESP32 has an Ethernet MAC, the W5500 was chosen because it was easier to obtain as a development board than an external PHY board, enabling faster prototyping.

From an architecture perspective, the W5500’s role is clear:

The ESP32 focuses on input sampling (ADC) → value normalization → OSC formatting.

The W5500 provides the wired Ethernet link and the network transmit path.

As a result, the main loop stays simple—“read → process → send”—which makes it easier to maintain a consistent update rate and predictable controller behavior.

Practical Tips / Pitfalls

SPI wiring / noise: Keep the SPI lines between the W5500 and ESP32 short and maintain a clean ground reference. If the chip select (CS) is shared with other SPI devices, manage it carefully in both hardware design and firmware to avoid bus conflicts.

Verify link-up early: During bring-up, always check link status (LEDs or serial logs) to separate cable/switch issues from IP/DHCP configuration problems.

DHCP vs static IP: DHCP is fine for development, but static IP is often better for teleop/AV setups where fixed mappings (firewall rules, routing, receiver presets) matter.

OSC transport (usually UDP): If you’re using UDP, assume packet loss can happen. Consider receiver-side timeouts/heartbeats or lightweight sequencing if reliability is important.

Update-rate tuning: Excessively high send rates can overload the receiver or the network. Use a fixed update interval and consider a deadband to avoid transmitting tiny joystick noise continuously.

ADC reference / grounding: If you see joystick jitter, re-check your analog reference (3.3 V rail stability, grounding, wiring). Using an external ADC is often about achieving more repeatable input behavior.

FAQ (5 questions, all WIZnet-focused)

1) Why did this project choose the WIZnet W5500?
According to the repository notes, an ESP32 Ethernet design using the built-in MAC is possible, but a W5500 development board was easier to source and simpler to prototype with than an external PHY-based setup. For input devices, fast bring-up and repeatability are often more important than squeezing maximum integration.

2) How does the W5500 connect to an ESP32?
Typically over SPI (SCLK/MOSI/MISO/CS), with optional RESET/INT depending on the module and how you structure your firmware. With Arduino Ethernet-style libraries, initialization is commonly done with Ethernet.init(CS_PIN) and Ethernet.begin(...).

3) What exactly does the W5500 do in this project?
It provides the network output over wired Ethernet. The ESP32 reads joystick values via an external ADC, packages them as OSC messages, and the W5500 handles the Ethernet transmit path. In short: ESP32 “creates values,” W5500 “puts them on the wire.”

4) Can beginners follow this if they’ve never used a W5500 before?
Yes—if you’re comfortable with SPI wiring and basic IP networking concepts (DHCP vs static IP, subnet, gateway). A practical sequence is: verify link → obtain an IP → send a test OSC packet → integrate the joystick/ADC loop. PlatformIO also helps by managing dependencies cleanly.

5) For this use case, how is W5500 different from Wi-Fi or a software-stack approach?
The core requirement here is consistency of input updates. Wi-Fi and software-heavy approaches can introduce more latency variation and debugging variables depending on environment and load. With W5500-based wired Ethernet, the network path tends to be simpler and easier to observe (link/cable/switch state), which can reduce operational friction in teleop, AV, and demo environments.