TCP-FWM-GPS: RP2040, W5500 and High-Accuracy GNSS for Dynatest FWD

TCP-FWM-GPS: RP2040과 W5500으로 구현한 GNSS TCP 시스템

📌 GNSS 데이터를 측정 장비와 Ethernet으로 동시에 전달하다

TCP-FWM-GPS는 Dynatest FWD(Falling Weight Deflectometer)에 GNSS 위치 정보를 제공하기 위해 개발된 embedded GNSS system입니다.

현재 Rev.4.1의 중심 hardware는 다음과 같습니다.

UM980에서 수신한 NMEA 정보를 RP2040이 처리한 뒤 두 경로로 전달합니다.

UM980 GNSS
    │
    │ Serial1
    ▼
Metro RP2040
    │
    ├── Position / Fix Processing
    ├── Averaging
    ├── IMU Yaw
    └── Antenna Offset Correction
             │
             ├── COM2 → Dynatest FWD
             │
             └── W5500 → Ethernet TCP

단순히 GPS 위치를 Ethernet으로 전달하는 gateway가 아니라, 측정 장비에 필요한 위치 보정과 상태 관리까지 MCU에서 수행하는 것이 특징입니다.

🌐 W5500은 두 개의 TCP 서비스를 담당

W5500은 이 프로젝트의 실제 Ethernet communication path입니다.

현재 firmware에는 두 개의 TCP service가 정의되어 있습니다.

NMEA server에는 최대 4개의 client가 연결될 수 있고, diagnostic server에는 별도의 client가 연결됩니다.

Network configuration은 DHCP를 먼저 시도하고, DHCP를 사용할 수 없는 경우에는 다음 주소를 fallback으로 사용합니다.

192.168.1.22

따라서 실제 data flow는 다음과 같습니다.

Corrected GNSS / NMEA
        │
        ▼
      RP2040
        │ SPI
        ▼
      W5500
        │
        ├── TCP 15919 → NMEA Clients
        │
        └── TCP 15920 → Diagnostics / Commands

W5500은 여기에서 단순한 Ethernet PHY 역할이 아니라 TCP socket을 제공하는 Hardwired TCP/IP controller로 사용됩니다.

🔧 Rev.4.1: W5500용 Cooperative TCP Transport

이 프로젝트에서 특히 흥미로운 부분은 Rev.4.1의 network transport입니다.

일반적인 Arduino Ethernet application에서는 주로 EthernetClient.write()와 같은 API를 사용하지만, Rev.4.1에서는 별도의 W5500Transport.h를 두고 W5500 socket 상태와 buffer를 보다 직접적으로 관리합니다.

코드에서는 다음과 같은 socket information에 접근합니다.

Sn_SR      Socket Status
Sn_CR      Socket Command
Sn_IR      Socket Interrupt
Sn_TX_FSR  TX Free Size
Sn_TX_WR   TX Write Pointer
Sn_RX_RSR  RX Received Size
Sn_RX_RD   RX Read Pointer

TX/RX data 역시 W5500 socket buffer에 직접 접근합니다.

이 구조의 목적은 하나의 느린 TCP client 때문에 GNSS processing loop 전체가 장시간 기다리는 상황을 줄이는 것입니다.

Rev.4.1에서는 각 client의 전송 상태를 독립적으로 관리하며, 새로운 NMEA frame이 들어오면 오래된 pending data를 무조건 쌓기보다 최신 sample을 우선하는 구조를 사용합니다.

GNSS 측정 시스템에서는 오래된 위치 데이터를 모두 뒤늦게 보내는 것보다 최신 위치 정보를 유지하는 것이 더 중요하기 때문입니다.

🛰️ GNSS 데이터를 그대로 전달하지 않는다

TCP-FWM-GPS는 UM980의 NMEA data를 그대로 forwarding하는 단순 converter가 아닙니다.

Firmware는 위치 상태를 다음 세 단계로 관리합니다.

MOVING
   ↓
AVERAGING
   ↓
LOCKED

MOVING

차량이 이동 중인 상태로 현재 GNSS 위치를 계속 갱신합니다.

AVERAGING

차량이 정지한 것으로 판단되면 기본 15초 동안 위치 sample을 수집합니다.

좌표 계산에는 extreme sample의 일부를 제외하는 trimmed mean 방식이 사용됩니다.

LOCKED

평균 계산이 완료되면 안정화된 위치를 사용합니다.

다시 이동하거나 locked position에서 일정 거리 이상 벗어나면 MOVING 상태로 돌아갑니다.

🧭 IMU를 이용한 Antenna-to-Piston Offset Correction

GNSS antenna의 실제 위치와 FWD 측정 지점은 동일하지 않을 수 있습니다.

이를 보정하기 위해 ICM-20948 IMU의 heading 정보를 이용합니다.

기본 antenna-to-piston offset은:

0.55 m

입니다.

Firmware는 GNSS 위치와 yaw 정보를 이용해 antenna 위치를 실제 FWD 기준 위치로 보정합니다.

따라서 처리 흐름은 다음과 같습니다.

GNSS Position
      +
   IMU Yaw
      +
Antenna Offset
      │
      ▼
Corrected Position
      │
      ├── FWD COM2
      └── W5500 TCP

📡 Galileo HAS 지원을 고려한 GNSS 처리

Firmware는 GGA의 fix quality를 이용해 GNSS solution type을 구분합니다.

UM980에서 Galileo E6-HAS를 사용하는 configuration도 repository에 정리되어 있습니다. 완전히 검증된 HAS system으로 표현하기보다는 HAS solution을 처리할 수 있도록 설계된 firmware라고 보는 것이 정확합니다.

🛠️ TCP를 이용한 Remote Diagnostics

TCP port 15920은 단순 상태 출력용이 아니라 interactive diagnostic interface입니다.

예를 들어 다음과 같은 command를 제공합니다.

status
imu
com2
help
magcal start
magcal stop
magcal reset
yawoff
freq
diag on/off

이를 이용하면 Ethernet을 통해:

GNSS 상태
fix 상태
satellite count
IMU 상태
yaw
COM2 전송 상태
calibration
output frequency

등을 확인하거나 설정할 수 있습니다.

이전 BLE 기반 진단 기능은 현재 Rev.4.x에서는 TCP Ethernet 중심 구조로 변경되었습니다.

⚠️ 현재 프로젝트 상태

Repository는 firmware와 main flow를 operational 상태로 설명하고 있으며 RP2040 build와 host-side test도 진행되어 있습니다.

하지만 다음 항목은 아직 구분해서 봐야 합니다.

따라서 완성된 commercial measurement product라기보다 실제 장비 적용을 목표로 계속 검증 중인 engineering project로 보는 것이 적절합니다.

🔗 Related WIZnet Maker Projects

WIZnet Maker에도 GPS/GNSS data와 W5500 Ethernet을 결합한 여러 프로젝트가 있습니다.

Raspberry Pi Pico + W5500 + GPS TCP API Server

RP2040과 W5500, L76K GNSS module을 사용한다는 점에서 hardware 구성이 가장 비슷한 프로젝트입니다.

GPS data를 TCP/HTTP request에 대해 JSON 형태로 제공하는 API server가 중심입니다.

TCP-FWM-GPS는 GPS API server가 아니라 GNSS 정보를 가공하고 측정 장비용 NMEA와 diagnostic TCP를 동시에 제공한다는 점이 다릅니다.

Two Antennas, One Accurate Heading

ESP32와 두 개의 ZED-F9P GNSS receiver, W5500을 이용해 vehicle heading을 계산하고 AgOpenGPS와 통신합니다.

W5500은 UDP, NTRIP, AgIO communication에 사용됩니다.

TCP-FWM-GPS가 하나의 GNSS와 IMU를 이용해 측정 위치를 보정한다면, 이 프로젝트는 두 GNSS antenna의 baseline으로 heading 자체를 계산합니다.

Clock 2 GNSS Ethernet Time Server

GNSS와 W5500을 사용하지만 목적은 위치 전달이 아니라 network time synchronization입니다.

GNSS의 timing/PPS를 기준으로 NTP service를 제공한다는 점에서 TCP-FWM-GPS의 위치/NMEA application과 구분됩니다.

SparkFun RTK Reference Station

ESP32, ZED-F9P multi-band GNSS와 W5500 Ethernet을 갖춘 RTK reference station입니다.

고정된 기준 위치에서 RTK correction infrastructure를 제공하는 장비라는 점에서, 이동식 측정 장비의 위치를 처리하는 TCP-FWM-GPS와 application 목적이 다릅니다.

❓ FAQ

Q. TCP-FWM-GPS에서 W5500은 실제로 사용되나요?
네. 현재 firmware에서 W5500은 NMEA TCP server와 diagnostic TCP server를 담당하며, Rev.4.1에는 W5500 socket/buffer를 직접 관리하는 transport code도 포함되어 있습니다.

Q. MCU는 무엇인가요?
현재 Rev.4.x는 Adafruit Metro RP2040을 사용합니다.

Q. W5500은 단순 Ethernet interface인가요?
아닙니다. TCP socket communication을 담당하며 Rev.4.1에서는 socket status, command, TX/RX pointer 및 socket buffer까지 firmware에서 직접 관리합니다.

Q. GPS data를 그대로 Ethernet으로 전송하나요?
아닙니다. GNSS fix를 확인하고, 정지 상태에서는 위치를 평균하며, IMU heading을 이용해 antenna와 FWD measurement point 사이의 offset을 보정한 뒤 출력합니다.

Q. TCP port는 무엇인가요?
15919는 NMEA streaming, 15920은 diagnostics와 command interface입니다.

Q. Wi-Fi도 함께 사용하나요?
현재 Rev.4.x의 network path는 W5500 Ethernet을 중심으로 구성되어 있습니다. 이전 revision의 Wi-Fi/BLE 기능은 현재 architecture의 핵심 network path가 아닙니다.

Q. Galileo HAS가 완전히 검증됐나요?
아닙니다. Firmware와 UM980 configuration은 HAS를 고려하고 있지만 repository에서는 receiver-side HAS validation이 아직 남아 있다고 명시하고 있습니다.

📌 GNSS for a Measurement System, Not Just a GPS Demo

TCP-FWM-GPS is an embedded GNSS system developed to provide positioning data to a Dynatest FWD while also exposing the processed data and system diagnostics over Ethernet.

The current Rev.4.1 platform is built around:

The RP2040 receives NMEA data from the UM980, processes the positioning information, and delivers the result through two independent output paths.

UM980 GNSS
    │
    ▼
Metro RP2040
    │
    ├── Fix / Position Processing
    ├── Position Averaging
    ├── IMU Heading
    └── Antenna Offset Correction
             │
             ├── COM2 → Dynatest FWD
             └── W5500 → Ethernet TCP

🌐 Two TCP Services over W5500

The W5500 is the project's wired network path.

The firmware exposes two TCP services:

Up to four NMEA clients can be handled, together with a separate diagnostic client.

The system first attempts DHCP and falls back to:

192.168.1.22

when DHCP is unavailable.

The resulting network path is:

Processed GNSS Data
        │
        ▼
      RP2040
        │ SPI
        ▼
      W5500
        │
        ├── TCP 15919 → NMEA Clients
        └── TCP 15920 → Diagnostics / Commands

The W5500 therefore acts as the Hardwired TCP/IP controller rather than merely providing a physical Ethernet interface.

🔧 Rev.4.1: A Cooperative W5500 TCP Transport

One of the most technically interesting parts of the project appears in Rev.4.1.

Instead of relying only on high-level EthernetClient.write() calls, the firmware includes a dedicated W5500Transport.h layer that directly works with W5500 socket state and buffer information.

The transport accesses information corresponding to:

Sn_SR      Socket Status
Sn_CR      Socket Command
Sn_IR      Socket Interrupt
Sn_TX_FSR  TX Free Size
Sn_TX_WR   TX Write Pointer
Sn_RX_RSR  RX Received Size
Sn_RX_RD   RX Read Pointer

and directly manages data in the W5500 TX and RX socket buffers.

The purpose is to prevent a slow TCP client from holding up the GNSS processing loop for an excessive amount of time.

Each client is serviced independently, and the transport favors fresh NMEA data rather than building an unlimited backlog of old position samples.

That is an important design choice for real-time measurement data: the newest valid position is generally more useful than replaying stale samples after a network stall.

🛰️ More Than NMEA Forwarding

TCP-FWM-GPS does not simply forward the GNSS receiver's output.

The FWM firmware manages three operating states:

MOVING
   ↓
AVERAGING
   ↓
LOCKED

When the vehicle stops, the system collects position samples over a default 15-second averaging window.

A trimmed mean is used to reduce the influence of outlying samples before the final position is locked.

Movement or sufficient displacement causes the state machine to return to MOVING.

🧭 Correcting the Antenna-to-Piston Offset

The GNSS antenna and the FWD measurement point are physically separated.

TCP-FWM-GPS uses the ICM-20948 heading information to compensate for that offset.

The default antenna-to-piston distance is:

0.55 m

The corrected data path becomes:

GNSS Position
      +
   IMU Yaw
      +
Antenna Offset
      │
      ▼
Corrected Position
      │
      ├── COM2
      └── W5500 TCP

📡 Galileo HAS-Aware Processing

The firmware interprets the incoming GGA fix-quality field to distinguish solution types.

The repository also documents UM980 configuration for Galileo E6-HAS.

Receiver-side Galileo HAS validation is still listed as pending, so the project should be described as HAS-aware rather than as a fully validated Galileo HAS product.

🛠️ Diagnostics over TCP

TCP port 15920 provides an interactive diagnostic interface.

Commands include:

status
imu
com2
help
magcal start
magcal stop
magcal reset
yawoff
freq
diag on/off

The Ethernet connection can therefore be used to inspect GNSS state, fix quality, IMU information, COM2 transmission, calibration data and output frequency.

⚠️ Current Development Status

The repository describes the main firmware flow as operational and documents RP2040 builds and host-side testing.

However, several items remain separate from those software results.

TCP-FWM-GPS is therefore best viewed as an actively validated engineering system rather than a finished commercial product.

🔗 Related WIZnet Maker Projects

Several WIZnet Maker projects also combine GNSS/GPS data with W5500 Ethernet.

Raspberry Pi Pico + W5500 + GPS TCP API Server

This project is particularly close at the hardware level because it also combines an RP2040, W5500 and a GNSS receiver.

Its primary goal is to expose GPS information through a TCP/HTTP JSON API.

TCP-FWM-GPS instead processes GNSS data for a measurement system and provides both NMEA streaming and a separate diagnostic TCP service.

Two Antennas, One Accurate Heading

This system combines an ESP32, two ZED-F9P receivers and W5500 Ethernet for AgOpenGPS.

It uses the physical baseline between two GNSS antennas to determine heading and sends navigation information through UDP and NTRIP-related channels.

TCP-FWM-GPS instead combines one GNSS receiver with IMU heading to correct the measurement position.

Clock 2 GNSS Ethernet Time Server

Clock 2 also combines GNSS and W5500 Ethernet, but its application is network timing.

GNSS and PPS provide the reference for an NTP server rather than supplying measurement-position data.

SparkFun RTK Reference Station

The SparkFun RTK Reference Station combines an ESP32, a ZED-F9P receiver and W5500 Ethernet.

Its role is to operate as fixed RTK infrastructure, while TCP-FWM-GPS processes and distributes position data for a mobile measurement system.

❓ FAQ

Is W5500 actually used by TCP-FWM-GPS?
Yes. The current firmware uses W5500 for the NMEA and diagnostic TCP services, and Rev.4.1 includes a dedicated transport layer that directly manages W5500 socket state and buffers.

Which MCU does the current version use?
The current Rev.4.x firmware targets the Adafruit Metro RP2040.

What are the TCP ports?
Port 15919 streams NMEA data and port 15920 provides diagnostics and interactive commands.

Does it simply forward GPS data?
No. The firmware evaluates GNSS fix state, averages position while stationary, uses IMU heading and applies an antenna-to-measurement-point offset correction before generating its output.

Does the current version use Wi-Fi?
The current Rev.4.x networking architecture is centered on W5500 wired Ethernet. Wi-Fi and BLE appear in earlier historical revisions rather than the current network path.

Is Galileo HAS fully validated?
Not yet. The firmware and UM980 configuration are designed to recognize HAS-related solutions, while receiver-side validation is still listed as pending.