# Secure LoRa Firmware Update with Adaptive Data Rate Techniques +
## 3 Results
### Implementation  
The secure firmware transfer process was validated in hardware using the test setup shown in Figure 10, which consists of a host computer, a Microchip SAMR34 Xplained evaluation board, and a Roper sensor printed circuit board (PCB) powered by a 200 mAh lithium polymer battery. The computer controls the update process via a.NET program which initiates the exchange, transmits the images, and then requests execution of the new application code. The host computer user interface that is used to test the prototype is shown in Figure 11. In order to securely transfer the update, the host program parses the new firmware update file, encrypts the firmware image, generates the MAC, and then transfers the encrypted image via Universal Serial Bus (USB) to the base station. The SAMR34 Xplained Pro evaluation board serves as the base station and acts as a USB-to-LoRa converter to handle RF communications at 915 MHz. The last byte of the USB message indicates the transmit and receive setting, and then all other bytes are transmitted over LoRa. In addition, the device data received by the base station is relayed asynchronously to the host along with the measured RSSI and signal-to-noise ratio (SNR) data. This custom code was developed and then loaded onto the base station.  
The firmware for the cattle monitoring device represents 30% of the firmware image while the boot loader represents 25% of the image. Therefore, the constraints discussed earlier allow the next firmware update to be stored in internal flash memory. The sensor operation executes after the ADR is complete and the initial code load address has been initialized. An interrupt is generated when a packet is received, which allows the sensor  
Figure 8: The energy consumption required to update a 128 kB firmware image.  
Figure 9: The energy consumption breakdown for the secure implementation.  
to validate the packet, decrypt the data, and then write it to flash. Upon receiving a valid packet, an acknowledgement is sent to the base station to confirm that a successful transfer occurred. After the complete image has been transferred, a CRC is computed on the new code image. If the calculated CRC matches the transmitted CRC, a start application command is sent, which causes the sensor to reset and begin executing the new application code.  
In order to validate the modeling, the energy consumption is measured for the firmware update process using settings 7 through 11. The results are shown in Table 4. The total energy consumption is estimated by measuring the battery open circuit voltage (OCV) before and after the firmware update. We then used a third-order OCV-to-battery-capacity mapping function to approximate the change in capacity. The firmware image used in the update is 106.6 kB which requires 6666 packet transfers when using the packet format specified in Figure 12. The total number of packets is calculated by dividing 106.6 kB by 16 since 16-bytes of firmware data are transferred per packet. The hardware results are within 13% of those obtained from simulations except for setting 7. The most notable sources of error are given as follows: (1) The hardware experienced packet re-transmissions after failed transfers that were not present in the simulations. (2) The hardware experienced additional delay with the receiver on but without data being received. The root cause of this issue is attributed to delays in the processing time between the PC program and the base station. (3) The OCV-to-capacity model is temperature dependent, but we only  
Figure 11: The PC interface to control the firmware update.  
Figure 10: The experimental setup used to validate the firmware update process.  
applied the mapping under room temperature conditions. Any deviation in temperature would shift this capacity measurement slightly.