Pushing our own firmware over the air to trackers built on a pre-certified LTE-M module
We build pallet trackers on a pre-certified LTE-M/GPS module (it has its own FCC ID and modular approval), our own firmware on it, reporting to Hermetry over MQTT. About 300 in the field in the US and NZ, next batch of 1,000 soon.
Management wants firmware updates over the air from Hermetry instead of collecting trackers. Our compliance person raised a worry: if we change the firmware, are we changing a certified radio, and does every update mean re-testing? Nobody here has done this before. Separately, if anyone has done OTA at this scale with Hermetry, what should we set up so a bad image doesn’t brick 1,000 pallets?
Which part of the firmware do you change, only your application or anything in the modem’s radio settings? And is the antenna the one listed in the module’s grant?
Only our application on the host MCU, the modem firmware is the vendor’s and we don’t touch TX power or bands. Antenna is the reference one from the module’s grant.
Not a lawyer, but I went through this with a test lab for a BLE product. The modular grant covers the radio as long as you stay inside it: same antenna type and gain, no changes to output power, frequencies or modulation, and the module’s FCC ID shown on your label («Contains FCC ID …»). Updating your own application code doesn’t touch that. The host product still needs its own unintentional-emitter check (Part 15B), once, not per update. Ask your lab to put that in writing for your file, it’s a short email for them.
Where you could break the grant is if an update ever lets the radio config change, so lock that: the app should have no command or setting that changes bands or power.
On the Hermetry side, what I’d set up before the first real rollout:
- Register your signing public key under Firmware > Signing keys and keep «Allow unsigned images» off on the tracker profile. Only an owner can add keys, and the device must refuse an image whose signature doesn’t verify, so build that check into your bootloader.
- Fill in Hardware models on each upload, so a rev B image never goes to rev A boards.
- Use Send in waves on the profile assignment, start with your own 10 test trackers.
- Leave «Allow updates over LTE» off until you know the image size and your data plan, otherwise each tracker downloads it on cellular the moment it’s assigned.
- Report
current_fw_versionafter every connect. Hermetry only marks an update done when the new version actually shows up, and flags it if the old one comes back.
All on Firmware updates (OTA).
Lab confirmed by email: application updates within the grant are fine, they added a note to our file. First wave of 10 went through yesterday on LTE (allowed only for those 10). One failed with a signature error because our build script signed the debug image, bootloader refused it as it should. That alone made the setup worth it.
Keep the private signing key off the build server people log into. HSM or at least a separate box.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.

