During my time in the Aerospace industry, I had a friend whose job was to send sensors and other electronic payloads into space on various shuttle and satellite launches. It was an infinitely interesting job, but it came with great responsibility, as once the technology that was being launched into space was gone, there was no further ability to interact with it other than receiving the data being sent back. Needless to say, there was a supreme amount of planning, testing, and quality assurance on those systems, over many months, to ensure perfect functionality of every piece of hardware and software before it left the lab. There was no ability to later add features, fix bugs, or optimize performance; once it was gone, it had to work flawlessly for months, years, and sometimes even decades.
Luckily, back here on Earth, we can deploy technology today and, with the right hardware and software resources in place, add features and fix bugs tomorrow after the technology is functioning out in the field. But what does that really mean? It sounds great in theory (and in fact is a bit of a “duh” moment because of course we’d want to do that), but the truth is that many wireless devices aren’t equipped with the necessary memory and logic to allow these updates to be made. In some cases, this is an intentional design decision which can be made for reasons such as increased cost for hardware resources or an expected short device life span. However, the vast majority of time, it’s an oversight during the design phase.
To avoid that uh-oh moment when a fixable bug hits your customers, it’s critical that a device is intentionally designed with the ability to be updated over the air (OTA) later. What this may translate to is (1) choosing a microcontroller (MCU) that has sufficient processing and flash memory to support an OTA update, (2) ensuring the right software hooks are in place to be able to process and commit the change, and (3) in the case of battery-operated devices, size the battery to allow for the spikes of power needed to perform the update procedure. This foresight and planning is especially important when devices, like those targeted for the LoRa ecosystem, are expected to have a long life in the field and will very likely need to be patched multiple times during that life.
Here at MachineQ, we understand that doing this correctly the first time is a significant time- and pain-saver, so we’ve done some of the heavy lifting on the software side. Our engineers have developed sample device code and detailed documentation to guide and support the device design and development process so that our customers aren’t doing this for the first time every time.
Armed with the expertise of implementing a large variety of use cases and applications, MachineQ engineers developed this sample code leveraging the multicast and downlink features that come with using Class B and Class C for Class A devices. To achieve this, we temporarily put devices in Class B or C mode at- and for a specified amount of time, push the OTA update using multiple parsed payloads, and switch the devices back to Class A mode. Using this strategy, we protect the battery life of these devices by only using Class B or C in limited time frames to achieve the OTA update, then return them to their normal operations.
The best way to try this out is to get one of our ST Development Kits. First, developers will want to download our sample Class A-to-B or Class A-to-C OTA update code and associated documentation, and then familiarize themselves with it by playing around. Next, we suggest prototyping your own application code interfaced with our sample code using that same dev kit. Finally, once the kinks have been worked out, implement the full functionality on your own hardware and software stack.
Contact us today to get started with your own dev kit and sample code.
