OTA & U

Jason von Nieda, Firmware Developer

There’s always work to be done when you’ve launched a new product. And so it is for Jason, a Firmware Engineer here at FireBoard Labs. Programming since age seven, Jason’s interest in all things development landed him at FireBoard in 2017. Until then, founder Ted Conrad was the primary firmware developer, handling OTAs for the first generation FireBoard. Now, with over 25,000 units in the field, Jason heads the Firmware department.

A quick rundown: OTA stands for “Over the Air Update”: the “Update” is implied. Companies are able to remotely update firmware on a device, usually over WiFi. Firmware is software that runs on a standalone device, such as a FireBoard, that makes it act like a FireBoard. Living somewhere between software and hardware, firmware is easier to change than physically modifying the device (hardware) but not as easy as downloading an app (software). Back in the day, device firmware was relatively stagnant, and a consumer would have to return it to the manufacturer in order to receive an update. 

OTA updates are usually triggered by the release of a new feature or an important product improvement. For example, when a new feature is developed in the app, the FireBoard firmware needs to be updated so the feature can work. Sometimes the update is purely cosmetic. For example, after the launch of the FBX2 series, it looked like the battery was never able to reach full charge. Although the batteries were indeed fully charged, the charge level display would only show 95%. No impact on performance, but important nonetheless, so an update was deployed. If there were such a thing as a typical update, it would include things like a new feature, such as the Drive Programs feature released last year, or a user interface improvement based on customer feedback. 

Example of FireBoard code.

Jason constantly monitors device performance, reviewing customer troubleshoot requests to look for patterns and identify possible update requirements. You could say that his job is equally divided between being proactive and reactive: proactive to roll out new features, reactive to fix bugs.

An unpleasant word, isn’t it? Bugs. But it’s a fact of firmware, and that’s why it is so important to be able to effectively deploy OTAs. The FireBoard is generally able to function during an OTA without operational interruption, which is a nice feature of the device. Still, it’s a delicate process, and Jason exercises caution when updates are ready, avoiding deployment around major holidays. Incremental updates are key, as programming always presents the possibility of unintended consequences. You could consider an OTA deployment “simplistic” in the purest sense of the word. 

First, the update goes to the FireBoards of a few employees. Who better to make sure the update is effective than the man behind it?

Testing an update.

It’s here that some real world testing of the update can occur before moving on. Next, a limited number of updates are released into the field; if something’s amiss, it’s easier to address and rollback here than it would be if the entire user base has been updated. The devices are monitored as Jason collects diagnostics to make sure it’s working the way it should. From there, it’s a matter of slow, incremental rollout to a portion of the user base, with an execution time ranging anywhere between a few days to a few weeks. Finally, if everything looks good, the update is pushed for full public release, and all FireBoards will update over the next few days.

Will the updates ever end? Not likely. We’re constantly improving our products, and that means there will always be updates. While Jason may be a department of one, he’s certainly not alone in product development. Our team continues to explore new features, leading to improved performance for consumers and, inevitably, OTAs for Jason. The good news is that not only does he take pride in his work but he also uses a FireBoard, so the updates are as important to him as they are to you.