Networking

The node streams telemetry live to the pit over UDP, and pulls RTK GPS corrections from an NTRIP caster over TCP. Both run on Azure RTOS NetXDuo over the STM32H5 Ethernet MAC. The services live in udp_service.c and ntrip_service.c; the threads are created in app_netxduo.c.

Startup: DHCP gates everything

The node has no static IP: it runs a DHCP client and the NetXDuo init thread blocks until a lease arrives. The UDP and NTRIP threads are created suspended and only resumed once the address is assigned. A separate link thread polls the Ethernet cable and re-runs DHCP after a reconnect.

No DHCP server = no telemetry stream

On a bench or at the track, the node must be on a network with a DHCP server (router). A direct laptop-to-node cable without one means the UDP stream and NTRIP never start; CAN, GPS, and SD logging keep working regardless.

UDP telemetry stream

The UDP thread (App_UDP_Thread_Entry) is the live link to the pit. It sends two message streams over one socket to UDP_SERVER_ADDRESS:UDP_SERVER_PORT.

Fast and slow messages

Stream	Rate	Prefix	Payload
Fast	UDP_SEND_HZ = 20 Hz	1,	MSG_TYPE_FAST line (dynamics, powertrain, GPS)
Slow	UDP_SLOW_SEND_HZ = 5 Hz	2,	MSG_TYPE_SLOW line (BMS detail, temps, dashboard)

Every loop iteration (20 Hz) sends a fast message. A separate tick counter fires the slow message once every 1/5 s. Splitting the data keeps the high-value dynamics flowing fast while the bulky BMS data rides a slower channel (see Data Format for exactly what's in each).

The send loop

1. Snapshot telemetry (telemetry_snapshot); skip the tick on failure.
2. Check the dashboard LTE toggle: if streaming is disabled, sleep and continue. (Note: the dashboard ingest is currently commented out in telemetry.c, so dbg_buttons_valid stays 0 and the stream is effectively always on.)
3. Build the fast line prefixed with "1,", allocate a NetXDuo packet, append the data, and nx_udp_socket_send().
4. If the slow interval has elapsed, do the same with a "2," prefix and a MSG_TYPE_SLOW line.
5. Sleep to hold ~20 Hz.

UDP is fire-and-forget

There's no retransmit: a dropped datagram is the next one's problem. That's the right trade for live telemetry: you always want the freshest sample, not a replayed stale one. The SD log is the complete, lossless record.

NTRIP client (RTK corrections)

The NTRIP service connects to a correction caster and pipes RTCM messages into the GPS receiver so it can compute an RTK-fixed position.

• Connects to NTRIP_CASTER_IP_ADDRESS:NTRIP_CASTER_PORT with an HTTP GET + Basic auth for NTRIP_MOUNTPOINT, and accepts an ICY 200 OK / HTTP 200 response.
• Incoming RTCM bytes are pushed into the shared RTCM ring buffer, and the RTCM semaphore is posted.
• The GPS Sender thread drains that buffer out to the receiver over UART.
• On any error or disconnect the socket is torn down and the thread retries after a delay; the connection self-heals, no intervention needed. If the ring buffer overflows, excess bytes are counted and dropped (RTK degrades gracefully to normal GPS).

Set real caster details

NTRIP_MOUNTPOINT, NTRIP_USERNAME, and NTRIP_PASSWORD in sys_conf.h are development placeholders ("TEST" / "test"). Configure the real caster before running on track.

Endpoints at a glance

What	Where	Define
Telemetry out	46.224.70.166:9000 (UDP)	UDP_SERVER_ADDRESS, UDP_SERVER_PORT
Corrections in	192.168.1.101:2101 (TCP)	NTRIP_CASTER_IP_ADDRESS, NTRIP_CASTER_PORT

All configurable in sys_conf.h.