OpenMANET radio buildout: pace car mesh comms at Watkins Glen
OpenMANET HaLow mesh build for pace car and track-side comms. Covers hardware, PTT, Watkins Glen layout, and Starlink backhaul.
When you are in the pace car at a track event, radio silence is not an inconvenience. It is a safety failure. The pace car is not a parade float. It sets speed, closes gaps, communicates with race control, and sometimes becomes the only link between a stranded car and the people who can clear the course. If your comms drop at the wrong moment, you are not debugging a hobby project. You are explaining to a race director why you did not hear the call to pick up the pace or hold position at the entrance to the Boot.
That is the frame for this build. The Gridlife radio buildout post is the chronological predecessor: the event context and the analog side of the stack. This post covers the IP mesh layer: an OpenMANET node built around a Raspberry Pi 4B, Morse Micro Wi-Fi HaLow at 915 MHz, and field hardware sized for a pace car mount without pretending the venue has reliable LTE.
Prologue: why comms failure is not acceptable
Track events punish assumptions. Watkins Glen International is a beautiful circuit and a hostile RF environment. Hills, trees, metal fencing, dozens of teams on Baofeng-adjacent frequencies, generator noise, and temporary infrastructure that moves every weekend. Cell coverage exists in pockets. Venue Wi-Fi is for spectators, not for the person in the Mustang pace car trying to coordinate with grid, safety, and the operations channel at the same time.
The path from SimpleGUIChat (broadcast TCP on localhost) to MANET topology, floor control, and dual PTT surfaces the same design questions. The lesson that stuck: session setup, membership, floor control, fan-out. A chat server and a mesh voice node ask who hears what, who may transmit, and what happens when a node drops behind the hill at Turn 6.
For pace car work specifically, the requirements are blunt:
- Low latency for tactical calls, not "eventually consistent" messaging
- No single point of failure, no one server in a trailer that everyone routes through
- Mobile nodes: the pace car moves; pit and grid nodes are semi-fixed
- Graceful degradation: when the mesh partitions, you still need a plan B
This build is not about replacing every analog radio on the grid. It is about owning an IP comms plane when towers, venue Wi-Fi, and congested FM simplex fail the people who need to hear each other.
Why OpenMANET
The stack did not start with OpenMANET. It started with requirements and worked backward.
Alternatives considered:
| Approach | Why it was evaluated | Why it did not win (for this role) |
|---|---|---|
| Cellular / LTE push-to-talk apps | Zero hardware, familiar UX | Spotty at WGI; venue load; latency; no control when the tower is saturated |
| LoRa / Meshtastic | Proven mesh, low power | Text-first; voice not the primary design center for pace car tactical |
| Commercial mesh radios (Motorola, etc.) | Battle-tested | Cost, licensing friction, less hackable for ATAK and custom routing |
| DIY 2.4/5 GHz Wi-Fi mesh | Cheap, Pi-friendly | Range and penetration poor vs. HaLow at 915 MHz in outdoor track terrain |
| Reticulum / custom packet stacks | Maximum control | Higher integration tax; field-proven MANET firmware was the priority |
OpenMANET is an open-source ecosystem for Raspberry Pi–based MANET radios on Wi-Fi HaLow (IEEE 802.11ah) using Morse Micro chipsets. The project gallery shows the intended use cases clearly: civilian SAR, disaster response, airsoft, and field ops where centralized infrastructure does not exist. Mesh without a central server. ATAK multicast support. Sub-GHz propagation that behaves better around hills and foliage than 2.4 GHz ever will.
That matched the research path: mesh without centralized infra, ATAK-friendly positioning for future map overlays, and a community that already solved Pi + HaLow integration so engineering time could go to PTT, mounting, and network layout instead of reinventing the radio driver stack.
Hardware BOM
Raspberry Pi 4B is the reference platform in OpenMANET documentation. The build follows that baseline with automotive power and field mounting in mind.
| Item | Role | Notes |
|---|---|---|
| Raspberry Pi 4B (4 GB) | Compute / mesh node | Reference OpenMANET platform; active cooling recommended in enclosed case |
| Morse Micro HaLow HAT / module | 915 MHz IEEE 802.11ah radio | Per OpenMANET docs: Wi-Fi HaLow chipset; sub-GHz mesh |
| MicroSD card (32 GB+, A2) | OS + OpenMANET stack | High-endurance or industrial-rated preferred for heat/vibration |
| USB-C PD input or 12 V automotive feed | Power | PD buck for bench; fused 12 V → 5 V for in-car (pace car cigar or hardwired) |
| 915 MHz antenna(s) | RF front end | Match connector and gain to mounting; external mag-mount or stubby for enclosed test |
| OpenMANET 3D printed case | Enclosure | MakerWorld design; Pi + HAT stack; field mounting bosses |
| USB-C / GPIO cabling | Power + PTT | Short, strain-relieved runs; GPIO leads for PTT if hardware-keyed |
| Optional USB GPS | ATAK / position | u-blox-class module; external antenna if windshield-mounted |
Not on the BOM but in the trailer: a bench supply, a second Pi for pit-side relay testing, ferrite on long USB runs, and labeled Ethernet for admin when you temporarily wire in a secondary Wi-Fi AP for configuration.
Enclosure build
The MakerWorld OpenMANET radio case is the mechanical foundation. Printing in PETG or ASA is worth the extra effort; a pace car cabin and a July paddock both exceed PLA's comfort zone.
Field mounting considerations:
- Vibration: use thread-lock on machine screws; pad the SD slot; avoid dangling USB sticks
- Heat: HaLow HAT + Pi 4B in a closed box needs airflow; drill pattern or vented lid if the print allows
- Antenna egress: strain relief on coax; keep bend radius sane; route away from USB 3.0 noise sources
- Serviceability: you will reflash SD cards at 6 AM; lid retention should be tool-free or one-tool
- Mount points: dash bracket, Velcro + safety tether, or magnet base depending on vehicle assignment
Treat the enclosure as part of the RF design, not an afterthought. A bad mount detunes effective range more than a marginal antenna choice.
PTT challenges
Push-to-talk sounds simple until you integrate it with an existing radio workflow. Half-duplex discipline is cultural and technical.
GPIO hardware PTT. Keying a GPIO line to trigger transmit is the cleanest mental model. You get a physical button, debouncing in software, and an obvious "floor held" state. Challenges: voltage levels, isolating the Pi from vehicle electrical noise, and routing a second PTT cable when the driver already has an analog radio mic in hand.
Audio routing. OpenMANET voice paths are not "plug a Baofeng into the Pi aux jack." You need a defined capture/playback device, ALSA or PipeWire routing that survives reboot, and gain staging so keyed audio does not clip or whisper. USB sound cards add another failure point; HAT audio paths depend on your stack.
Half-duplex behavior. Mesh voice is not a full-duplex phone call. Software must enforce TX/RX state, optionally mute local speaker on key, and handle tail delays so the last syllable is not cut off. If software PTT lags, operators double-key and talk over each other, exactly what pace car comms cannot afford.
Software vs hardware PTT. Software PTT (screen tap, keyboard) is fine for bench test. In the car, you want hardware. The target stack is hardware PTT primary, software override for pit bench, and a visible TX indicator (LED or small display) so the driver knows when the mesh is hot.
Interfacing with existing radio workflows. Dual PTT ergonomics from the SimpleGUIChat lineage: one plane for immediate analog crew, one for mesh IP. The hard part is muscle memory: different buttons, different latency, same emergency. Training beats clever UI.
Open questions still on the list: VOX vs strict PTT on mesh, sidetone presence, and whether a foot switch is viable in a pace car with a clutch (usually no; wheel or dash mount).
Network architecture for Watkins Glen
Watkins Glen International is not a flat parking lot. The circuit runs through elevation changes, tree lines, and structures that shadow 915 MHz differently than UHF FM. The mesh plan assumes nodes, not coverage magic.
Proposed node roles:
| Node | Location (conceptual) | Role |
|---|---|---|
| N1 (Pace car) | Mobile, roof/dash mount | Roaming mesh participant; primary tactical voice for pace operations |
| N2 (Pit / grid) | Paddock hardstand | Semi-fixed relay; high antenna; bridge to ops laptops |
| N3 (Start/finish or control) | Near timing loop | Low-latency path to race control coordination |
| N4 (Optional hill relay) | Turn 6 / Boot elevation | Fill shadow behind the hill; may be battery + tripod |
Interference. 915 MHz ISM is shared. Monitor for coexistence with other sub-GHz gear. Antenna polarization and height often beat raw transmit power.
Range expectations. HaLow favors penetration and distance vs. 2.4 GHz, but WGI is still a system test, not a datasheet number. Plan link tests a week before the event: walk/drive the course with RSSI logging, note partition points, adjust N4 placement.
Failover. Mesh partitions will happen. Plan:
- Analog FM simplex remains the immediate crew fallback (Gridlife stack)
- Mesh text/data may route when voice path is degraded
- Pre-agreed channel plan so nobody hunts frequencies mid-session
Testing plan before event:
- Bench: two nodes, PTT loop, record latency mouth-to-ear
- Paddock: three nodes, pit + car idle + car lap at partial speed
- Full course: pace lap with logging; mark dead zones on a track map for N4 candidacy
- Fail drill: kill one node, confirm others re-converge without manual IP surgery
Optional add-ons
Not required for first light, but on the roadmap:
- GPS module: ATAK position multicast; pace car on map for ops
- External antennas: mag-mount 915 MHz on roof vs. stubby in cabin
- Battery packs: USB-C PD banks for tripod nodes without generator access
- Waterproofing: condoms for connectors, gasketed lid prints, silica in box
- Secondary Wi-Fi (2.4/5 GHz): admin SSH and config only; isolate from HaLow mesh role
- Ethernet dongle: pit bench provisioning without flashing SD in the car
- Cooling fan: 5 V PWM on GPIO if summer heat tests fail
- Status display: small OLED for IP, mesh peers, TX indicator
Each add-on is a reliability trade. More cables, more connectors, more things to shake loose on a pace lap.
Beyond line of sight: Starlink as upstream gateway
Mesh excels on site. It does not magically connect remote team members, cloud logging, or internet-backed ATAK feeds. When the mesh ends, you need a deliberate bridge, not a hope that someone's phone hotspot works.
Starlink as upstream gateway is the optional backhaul layer:
- A fixed or vehicle-mounted Starlink terminal on a trailer or ops van provides internet
- One mesh node (likely N2 pit) runs routing policy: mesh ↔ Starlink
- Remote ops, logging, or map tiles reach the field without touching congested LTE at the track
Caveats (read these before bolting a dish to a pace car):
| Factor | Reality |
|---|---|
| Latency | Starlink is fine for data; voice backhaul over internet adds delay and is not a replacement for local mesh voice |
| Power | Dish + router draws serious watts; pace car alternator is the wrong default home |
| Mounting | Vehicle motion and tree cover affect dropouts; trailer/ops post is more realistic |
| Failover | Internet path dies → mesh local traffic should continue; do not route all voice through the cloud |
| Cost / logistics | Another box to transport, align, and secure |
The mental model: Starlink extends the MANET to the internet; it does not replace HaLow between pace car and pit. Mesh for tactical local; satellite for reach-back.
Next steps and open questions
This post documents the engineering case as it stands going into integration test, not a victory lap. Concrete next steps:
- Complete PTT hardware path: GPIO button, debounce, TX LED, audio device pinning in OS image
- Flash and pair two nodes: validate OpenMANET mesh join and voice between Pi units on bench
- Print and assemble case: MakerWorld enclosure, antenna routing, automotive power harness
- WGI site survey: pre-event drive with logging; finalize N3/N4 placement
- Dual PTT drill with Gridlife analog stack: document which calls live on which plane
- Starlink trial (optional): pit-only backhaul test; measure latency for data, not voice
Open questions:
- Final Morse Micro HAT revision and driver stability on current OpenMANET release
- Legal / band compliance for 915 MHz at a private event (verify local rules and ERP limits)
- Whether one mesh voice channel is enough or crew/logistics need VLAN-style separation
- ATAK multicast integration timeline vs. event date
- Long-term: hardened enclosure IP rating vs. quick-swap SD maintenance
If you are building along similar lines (pace car, SAR, convoy, airsoft command), the through-line is the same: reliability is a requirement, not a stretch goal. OpenMANET supplies the mesh stack; the rest is discipline, testing, and refusing to accept "we'll figure it out in the paddock."
Prior context: Gridlife radio buildout. Lineage from chat sockets to field mesh: SimpleGUIChat.