Downlink Configuration Versus Firmware Version

Designing device firmware is a balancing act of designing flexibility into device operations through a number of parameter settings. The powerful idea behind configuration parameters is that performance can radically change with a few bytes pushed down to the device. For instance, to be compliant with application logic that defines “magnet applied = 0”, a magnetic sensor than normally reads “1” when a magnet is applied could be reconfigured with a parameter setting to read “0” when the magnet is applied.

There are several controls and options that can be designed into the parameter settings. However, this usually comes at a cost of complexity in the device code, a requirement to acknowledge this type of behavioral modification, inducing additional ACK traffic, and time and cost in test and coverage analysis.

The other extreme is designing a device with no configurable parameters. When changes to how a device operates are required, a firmware update is sent over-the-air (OTA). The LoRa Alliance® has approved a mechanism to provide firmware-updates-over-the-air (FUOTA)1. The power of updating firmware is the ability to make changes as needed: as issues are discovered in the field operation of the devices. However, this comes at a cost of an increase in the power consumption required for sending frequent transmissions of the firmware to the device.

As with most of the other suggestions, achieving balance is key in working with configuration parameters and firmware updates. Many applications are developed quickly and iteratively with specifications and customer input rapidly changing the requirements for device performance. Early on, FUOTA is probably a better approach, since it allows for rapid progression of features while application discovery is underway. As the application matures, having more flexible control over device operations (maybe idling some devices while making others report more often) leads to a more configuration/parameter-oriented approach. However, we recommend that parameters be polled from the device as a CRC/MD5 value. Then, that value can be sent in place of the entire parameter, so that the current settings can be validated and verified quickly and reliably, with a two- to four-byte value.