THE CHALLENGEThe Hardware Works on the Bench and Fails in the Field
A tracker that passes bench testing still drops records the moment it hits a dead zone, drains its battery because the modem never sleeps, or bricks itself on the first OTA. The hard part is not reading NMEA sentences. It is keeping the modem reconnecting without blocking the GNSS task, buffering data through hours of no coverage, sleeping the MCU between reports without missing an ignition or motion event, and shipping an update to thousands of units that cannot survive a bad image. This work is usually needed when an off-the-shelf module firmware will not bend to your power target, your reporting cadence, or your reliability requirement. Firmware written to the part level makes the radio behaviour, the power model, and the data path one coherent system.
A component of the broader GPS tracking device engineering capability, often deployed with Device-to-Cloud Protocol Engineering.
WHAT'S INCLUDED
Firmware Scoped to Your Board and Power Budget
MCU and RTOS Bring-Up
Firmware on STM32L4, STM32F4, ESP32, and Nuvoton, with FreeRTOS or Zephyr task design. GNSS, modem, sensor, and storage are split into bounded tasks with clear priorities so no single subsystem can stall the others.
GNSS Position Engine
NMEA and UBX parsing with fix validation, HDOP and satellite-count gating, and configurable reporting on distance, heading change, and time. Noise is filtered so the cloud receives clean, deduplicated position records.
Modem AT State Machine
A modem driver built as an explicit AT command state machine with URC handling, PDP context setup, signal monitoring, and a reconnect ladder with backoff that recovers from network drops without manual intervention.
Store-and-Forward and OTA
A ring buffer on external flash or EEPROM that queues records during outages and drains them in order, plus OTA with A/B partitions, signed images, and rollback so a deployed fleet updates without a recall.
TECHNICAL APPROACH
How It Is Built, Part by Part
GNSS Parsing and Fix Logic
NMEA GGA, RMC, and GSA sentences are parsed, or UBX binary for u-blox receivers, the fix is validated against HDOP and satellite count, and reports are gated so a momentary loss of fix does not flood the link with bad points.
Modem URC and Reconnect
The AT state machine tracks registration, signal quality, and socket state, parses unsolicited result codes as they arrive, and walks a reconnect ladder with backoff when the PDP context or TCP socket drops.
Store-and-Forward Buffer
A ring buffer in external SPI flash or EEPROM holds timestamped records when the device is offline. On reconnect it drains in order with per-record acknowledgement and retry, so no position is lost or duplicated.
Low-Power State Management
The MCU drops into stop and standby modes between reports and wakes on ignition line, RTC alarm, or motion interrupt from an accelerometer. The modem is powered down or idled to hold the quiescent current the battery budget allows.
OTA with A/B and Rollback
Updates land in the inactive partition, pass a signature and CRC check before the bootloader switches over, and roll back to the last known good image automatically if the new build fails its post-boot health check.
Watchdog and Field Reliability
An independent watchdog, per-task heartbeats, and brown-out handling keep field units recovering on their own. Fault causes are logged to flash so a returned unit shows why it reset.
INTEGRATION AND OUTPUTS
What You Get and Where It Connects
Deliverables include flashable firmware images, the bootloader and OTA tooling, the device-side protocol that talks to your backend, and the test logs from bench and field runs. The firmware connects upward to your platform over MQTT, raw TCP, or a compact binary protocol, and connects sideways to the rest of the hardware through the GNSS UART, the modem interface, the accelerometer and ignition lines, and the external storage bus. When the hardware needs designing alongside the firmware, or the cloud protocol and battery model engineered to match, those run as connected workstreams.
FAQ
Common Questions
Which MCUs and RTOS does the firmware target?
Supported targets include STM32L4 and STM32F4 for low-power and higher-throughput trackers, ESP32 where Wi-Fi and BLE provisioning matter, and Nuvoton for cost-sensitive builds. Task design runs on FreeRTOS or Zephyr depending on the driver ecosystem and the power model the device needs.
What happens to data when the device loses coverage?
A store-and-forward ring buffer is written to external SPI flash or EEPROM. Position and event records are timestamped and queued when the link is down, then drained in order once the modem reattaches, with acknowledgement and retry so the cloud sees no gaps.
How is the cellular modem handled reliably?
The modem is driven as an AT command state machine with explicit URC handling, PDP context recovery, and a reconnect ladder with backoff. The modem runs as its own task so a stalled network registration never blocks GNSS parsing or the sensor loop.
Is OTA supported on already-deployed fleets?
Yes. OTA uses A/B partitions, a signed image check, and automatic rollback if the new build fails to confirm health after boot. A field fleet gets updated without a recall, and a bad image self-recovers to the last known good partition.
Have Tracker Hardware That Needs Firmware?
Share your board, your GNSS and modem parts, your power target, and your reporting cadence to get a scoped plan covering the RTOS task design, the modem stack, the buffering, and the OTA path, ending in firmware that holds up in the field.
Schedule a Free Consultation