A Look Inside the Firmware of a Production NB-IoT Dog Collar
Dennis Knake
Posted On 27th July 2026
A systems architect describes, in an English-language field report, the firmware decisions that kept an STM32-based NB-IoT dog collar running reliably under field conditions for three years.
Key Takeaways
- Developer Vitaliy Gribko documents on HackerNoon the development of an NB-IoT dog tracker that, according to his account, was commercially deployed for three years under the brand of a major telecommunications provider.
- The article is structured as a retrospective case study and treats several problem areas as equally important: unreliable battery-status signals, hanging NB-IoT modems, error-prone GPS cold starts, and a hardened firmware update procedure.
- The firmware’s guiding principle throughout is to treat unreliable hardware as the default rather than the exception, catching every failure case in software instead of relying on stable field conditions.
What is the article about?
Vitaliy Gribko, described as a systems architect specializing in firmware and embedded Linux, describes building a tracking collar for dogs: temperature, speed, step count, and GPS location, implemented on an STM32L4 board with a Neoway N25 NB-IoT modem and FreeRTOS as the underlying operating system. According to his account, a two-person prototype grew into a product that a major telecommunications provider marketed under its own brand for three years — discontinued in 2025, per the author, not because of technical shortcomings but due to GPS and cellular jamming in certain deployment regions.
What field problems does the article cover?
Rather than offering a build guide, the text works through problem area after problem area. One example: according to Gribko, the charge-status pins of the installed charging IC show the same signal combination in certain states as an over-temperature fault — so the firmware instead relies on the battery fuel-gauge chip to reliably detect charging states. Another example concerns the NB-IoT modem itself: if it hangs under poor signal conditions, a watchdog mechanism detects this and automatically restarts the modem via a fixed hardware sequence, rather than letting the device become unusable in the field.
How does the firmware handle risky firmware updates?
A dedicated section covers safe over-the-air updates: a new firmware version is first staged entirely on external flash memory and verified in small blocks via checksum before a single byte is written to the microcontroller’s internal memory. Only after passing verification does the firmware set a ready flag that triggers the actual update process. On the general approach to unreliable hardware, Gribko writes concisely:
„treat unreliable hardware as the default, not the exception.”
Conclusion
The full field report is worth reading for anyone developing their own battery-powered NB-IoT devices — from motion-triggered wake-up logic to GPS cold-start handling and dealing with fragmented UART responses from the modem. The original English-language article is available on HackerNoon.
