Back to engineering work

Embedded telemetry + browser interface

GNSS and LoRa race tracking

Firmware and a browser interface for a radio-based race-tracking system. The work covers position and status packets, a LoRa-to-web gateway, map updates and GPX route logging.

GNSS and LoRa race trackerSystem development
Project browser map interface with route overlay
Project map interface with route overlay. This capture does not establish a live field track.

Engineering scope

  • GNSS data handling and compact LoRa packets
  • Gateway integration and WebSocket updates
  • Browser map presentation and GPX route logging

Documented system flow

From position data to a route record

  1. Read GNSS measurementsCollect position and status values.
  2. Create a radio packetPackage telemetry for the LoRa link.
  3. Bridge to the webPass gateway updates to browser software.
  4. Show and record the routeUse the map interface and GPX logging.

Radio packets and gateway integration

Compact packets carry position and status over LoRa. The gateway converts the embedded data into WebSocket updates for the browser map, keeping radio transport and presentation separate.

Position validity handling

The sampling function checks location and satellite validity before copying coordinates. A fix flag distinguishes unavailable-position zero placeholders from valid coordinates. Auxiliary fields are checked independently and also default to zero when unavailable.

Validation scope

The source excerpt documents sampling logic; the project record covers the wider gateway, map and GPX logging. Radio range, positioning accuracy and completed field validation are not established by the available material.

Firmware flow

How the tracker prepares a GNSS sample

Complete GNSS sample-building routine.

ActionRead the decoded GNSS fields
CheckPosition valid and satellites available?Location and satellite-count fields must be valid, with at least one satellite.
Action · YesKeep the measured coordinates
Action · NoMark no fix; use zero placeholders
ActionAdd available speed, height and quality fieldsEach auxiliary field has its own validity check and a zero default.
ResultUpdate the latest fix status

Check that position and satellite data are valid with at least one satellite. Keep the coordinates when a fix is available; otherwise mark no fix and use zero placeholders. Add independently valid auxiliary readings, then update the latest fix, quality and satellite status.

The check is for reported field validity, not sample freshness or an accuracy threshold. Zero coordinates are placeholders when there is no fix. LoRa transmission, browser maps and GPX logging are outside this excerpt.

Read the implementation

buildGpsSample · selected source lines 1040–1053. Source inspection is not a hardware test.

void buildGpsSample(GpsSample &out) {
  out.fix         = gps.location.isValid() && gps.satellites.isValid() && gps.satellites.value() > 0;
  out.lat         = out.fix ? gps.location.lat()   : 0.0;
  out.lon         = out.fix ? gps.location.lng()   : 0.0;
  out.alt_m       = gps.altitude.isValid()   ? gps.altitude.meters() : 0.0;
  out.spd_mph     = gps.speed.isValid()      ? gps.speed.mph()       : 0.0;
  out.heading_deg = gps.course.isValid()     ? gps.course.deg()      : 0.0;
  out.hdop        = gps.hdop.isValid()       ? gps.hdop.hdop()       : 0.0;
  out.sats        = gps.satellites.isValid() ? gps.satellites.value(): 0;

  lastGpsFix = out.fix;
  lastHdop   = out.hdop;
  lastSats   = out.sats;
}
Open the exact source-level diagram
All projectsArchive record

Project enquiries

Discuss your project.

Tell us what you’re developing and where you need engineering support.

Discuss your project