Module Index

The node is a ThreadX application: no superloop. Each responsibility is its own thread, and threads talk to each other through one shared struct (telemetry_data), semaphores, and ring buffers. This page is the map of every module and where it's documented.

Threads

Application threads are created in App_ThreadX_Init() (app_threadx.c); the networking threads in MX_NetXDuo_Init() (app_netxduo.c). Lower priority number = higher priority in ThreadX.

Thread	Prio	Rate / trigger	Job	Docs
CAN RX	15	on RX IRQ	Drain RX ring buffer → ingest frames	CAN
CAN TX	15	on TX request	Push queued frames to FDCAN hardware	CAN
CAN Periodic TX	16	20 Hz	Snapshot → pack derived values → re-broadcast	CAN
UDP	(NetXDuo)	20 Hz / 5 Hz, starts after DHCP lease	Snapshot → CSV → UDP to the pit	Networking
NTRIP	(NetXDuo)	streaming, starts after DHCP lease	Pull RTK corrections over TCP	Networking
GPS	14	on UART RX	Drain UART ring buffer → lwGPS → telemetry	GPS
GPS Sender	14	on RTCM ready	Push RTCM corrections to the receiver	GPS
Lap	(tunable)	on GPS update	Detect finish-line crossings, count laps	Lap Tracking
SD Buffer	12	50 Hz	Snapshot → CSV line → ping-pong buffer	SD Logging
SD Writer	12	on chunk full	Flush a full buffer to the card via FileX	SD Logging
Blink	31	2 Hz	Heartbeat LED, proof the scheduler is alive	n/a

All numbers come from sys_conf.h.

Interrupts vs. threads

Peripherals (FDCAN, UART DMA) do the minimum in their ISRs: copy bytes/frames into a ring buffer and post a semaphore. The heavy work (parsing, decoding, ingesting) happens in the corresponding thread once it wakes. This keeps ISRs short and moves the real work into the scheduler where it can be prioritized.

Modules by group

• Communication: CAN, Networking
• Data Processing: Telemetry Model, Data Format
• Sensors I/O: GPS, Lap Tracking
• Storage: SD Logging

At the track? Skip the theory and go straight to Track Operations: quick checks, LED signatures, failure modes, and the pre-event checklist.