← Back to Projects

Internet-of-Things (IoT) GPS Relay Baton

MAE 4220  ·  Cornell University  ·  4-person Team (Member)

I built the electronics, firmware, software, and electromechanical design for a real-time GPS relay baton tracker, deployed for the Seneca 7, a 77.7-mile relay race with no reliable cellular coverage along most of the course.

LoRaWAN Embedded C++ (Feather M0) GPS / GNSS MQTT Streamlit / Python Fusion360 FDM Prototyping User Research Field Testing Technical Leadership

Situation

  • Seneca 7 is a 77.7-mile relay race around Seneca Lake with 300+ teams and 2,000+ runners, currently run on slap-bracelet handoffs with no real-time location data, no performance metrics, and no automated handoff detection.
  • Cellular coverage is inconsistent along substantial portions of the course, ruling out a standard cellular GPS uplink.
  • Design, fabricate, and deploy a reusable IoT baton that tracks GPS position, detects handoffs, and streams live data to race officials and runners, in direct consultation with the race director and runners.

Outcomes

  • Built the electronics, firmware, and electromechanical design across three full prototype generations: the Minion, the Newt, and the Finalist.
  • Built the full software stack: onboard LoRaWAN transmission, TTN integration, an MQTT listener, and a live Streamlit map and stats interface with CSV export.
  • Ran the field testing program: campus verification runs, a mobile-gateway deployment near Seneca Lake, and live data collection at the Belle Sherman 5K.
  • Confirmed reliable LoRaWAN transmission and handoff detection at 30-second intervals, and characterized baton-to-gateway range limits with MATLAB signal analysis.

The Problem

The Seneca 7 is a 77.7-mile relay race organized by Red Newt Racing and the Finger Lakes Running Club that circles Seneca Lake, drawing over 2,000 participants from 16+ states across 300+ competing teams annually. The race raises approximately $20,000 per edition for 20+ local non-profit organizations. The existing setup uses a slap bracelet as the baton, which provides no real-time location data, no per-runner performance metrics, and no automated handoff detection. This creates a significant operational burden for volunteers and limits the race data available to participants and staff.

The core engineering challenge is connectivity. Cellular coverage along the lake, particularly on the eastern shore through Yates and Schuyler counties and the western shore between Watkins Glen and Dresden, is inconsistent. A standard cellular GPS device would fail in these zones. RFID was explicitly excluded by race staff based on past dead-zone failures in the gorge sections along the course. LoRaWAN was selected as the communication protocol given its ability to transmit data up to 10 to 16 km in rural line-of-sight conditions without cellular infrastructure.

The project objective was to design, fabricate, and deploy a reusable IoT baton that tracks GPS position at 30-second intervals, detects handoffs via an integrated push-button, and streams live data to race officials and runners through a custom web interface, operating entirely over a private LoRaWAN network.

Three gateway configurations were explored before selecting the final approach. A satellite uplink would provide coverage regardless of geography, however the dense tree cover around Seneca Lake breaks satellite line-of-sight, and the cost and latency were not practical for this project. A fixed high-elevation gateway in Dundee was the second option, given the city's elevation advantage over the race route, however a deployment site could not be secured from a willing property owner within the project timeline.

The selected approach is a mobile gateway: a MultiTech MTCDT-L4N1 LoRa gateway powered by a 99.9 Wh JIYHF P100 portable power station, deployed in a support vehicle that follows the race field. This configuration maintains consistent proximity to the baton throughout the race and eliminates the siting problem. A PowerDrive PWD120 car-outlet inverter provides backup power for extended runtime when a vehicle is available. Each baton transmits a unique ID, GPS coordinates, and button state to The Things Network every 30 seconds, and the gateway forwards the data into the processing pipeline regardless of where on the course the baton is located.

Minion

First Fixture (V1)

The first 3D-printed alpha prototype, named for its blue-and-yellow color scheme. A larger casing with room for the battery, the Feather M0 board, antenna, and the rest of the electronics. Confirmed basic TTN connectivity and GPS acquisition before anything else was optimized.

Newt

Reliability Pass (V2)

Swapped the GPS module for a NEO-M8 over TX/RX, added heat shrink inside the button for reliability, and slimmed the casing. Split into two parallel designs, V2a for fixturing reliability and V2b for ergonomics, after a design contradiction between the two goals forced a real tradeoff decision.

Finalist

Race-Ready (V3)

The first fully usable electromechanical design: ergonomic grips, a carabiner loop, weather-protected access ports, and a woven rear strap, all printed in matte PLA. This is the version used for all verification testing, the Seneca 7 race, and the Belle Sherman 5K.

The V2a/V2b split reflected a direct design contradiction. V2a was optimized for reliable fixturing of the button and Feather board. V2b was optimized for ergonomics and brought the outer diameter down to approximately 1.5 inches based on user testing feedback. Both objectives were valid but could not be fully satisfied by a single design, which is why two separate models were developed in parallel. A design review across both produced the Finalist: reliable fixturing from V2a, the ergonomic form factor from V2b, and the addition of weather-protected ports and a multi-configuration strap system informed by the user study results.

MicrocontrollerSparkFun Feather M0
RadioLoRaWAN, via TTN
GPS moduleNEO-M8 (TX/RX)
Handoff detectionIntegrated push-button
EnclosureMatte PLA, FDM-printed
MountingCarabiner loop, woven strap, handheld grips
GatewayMultiTech MTCDT-L4N1, mobile-deployed
Transmit interval30 seconds

Software

The software stack has two components. Onboard the Feather M0, firmware reads the GPS module and button state and packages a unique baton ID, latitude, longitude, and handoff status into a LoRaWAN packet transmitted to TTN every 30 seconds. Basic encryption is applied to the payload given the scale of the data involved. On the backend, I built a Streamlit application hosted on GitHub with a custom MQTT listener that authenticates against the TTN console, decodes incoming packets using a Python script, and renders a live map and per-runner statistics accessible from desktop and mobile browsers. The app uses caching to store transmitted data, so anyone with the link can view both live updates and historical records.

The interface includes two controls at the top: Clear All to reset the session data, and Export All to download the full dataset as a CSV for post-race analysis. The architecture was kept intentionally minimal to limit streaming delays. Every layer between the baton and the browser is a potential point of delay or data loss, and the 30-second transmit interval is only meaningful if the rest of the pipeline does not introduce additional lag.

Verification testing ran in three stages. The first stage was campus runs with the Finalist baton, pressing the handoff button at regular intervals while monitoring the Streamlit UI in real time to confirm the full data pipeline end to end. The second stage was a field deployment near Seneca Lake with the mobile gateway operating from the support vehicle, which confirmed gateway-to-baton connectivity but did not yet establish a clear range curve. The signal was strong in close proximity, however the maximum reliable transmission distance had not been isolated.

The Belle Sherman 5K served as the third stage and produced the key technical finding. The environment had fewer obstructions and less elevation change than the lake course, which provided a cleaner test to isolate the critical variable: distance from the gateway. With a stationary gateway, only two data points were received over TTN across the full run. This led to the primary technical observation: the baton and gateway communicate reliably only within approximately 600 feet of each other. Signal data from the run was processed in MATLAB to characterize received signal strength as a function of baton-to-gateway distance, and this now serves as the baseline for future enclosure redesigns.

30 sec
GPS and handoff transmit interval
~600 ft
Reliable baton-to-gateway range
3
Electromechanical generations built

The most significant limitation of the current prototype is the degradation of LoRaWAN transmission range caused by antenna compression within the V3 enclosure. Compacting the design to reach the 1.5-inch ergonomic target reduced antenna clearance and measurably reduced effective range. The next enclosure iteration should allocate dedicated clearance volume for the antenna or evaluate an external stub antenna routed through a sealed port. Additionally, the current enclosure has not been tested against any formal ingress standard. Given the outdoor race environment and exposure to rain and sweat, a minimum IP54 rating is recommended for future iterations.

Only one Finalist unit was produced in this development cycle. Race-scale deployment requires one baton per competing team, meaning approximately 300 devices transmitting simultaneously over shared TTN gateway bandwidth. Packet collision rates, duty-cycle compliance, and gateway throughput at that scale are untested. A batch of at least 10 units should be fabricated and tested concurrently to characterize network behavior under realistic load. A systematic LoRaWAN signal survey of the full 77.7-mile course is also needed to identify coverage gaps before race deployment. Transitioning the enclosure material from PLA to PETG or ABS would also improve UV and impact resistance across multiple race seasons.

The complete data pipeline from GPS acquisition through LoRaWAN transmission, TTN routing, MQTT decoding, and live display was verified end to end across three real-world test environments. That is the foundation the next development cycle can build on.