# Development of a Multi-Radio Device for Dry Container Monitoring and Tracking
## 5 Discussion  
This section discusses the results of the tests described in Section 4, with a special focus on the power consumption of the CTD. After verifying that the firmware is capable of correctly handling the various functions of the device, namely NB-IoT transmission to the OneM2M-compliant platform for sensor data (Figures 10 and 11), BLE Mesh network provisioning by the provisioner/client node (Figures 12 and 13), and data transmission to the OneM2M-compliant platform, by the provisioner node in NB-IoT/BLE Mesh gateway mode (Figures 14 and 15), specific current measurements were taken to size the battery pack. Section 4.3 explores the power consumption of the CTD in various scenarios through multiple tests. The first test measures the current consumption of the device with ESP32 in active mode with the BLE radio turned on but no sensors attached. The result is depicted in Figure 18. The active mode current consumption for ESP32 is about 75 mA. Spikes indicate that the device periodically transmits beacons via the BLE Mesh radio. This fits fine with the current consumption values declared in the ESP32 datasheet [32]. Figure 17 illustrates the graph of the tests in which all the modules were installed and were active. Figure 19: Current consumption during BLE Mesh usage [36]. Figure 18: Current consumption without sensors ESP32 in active mode with BLE turned on, transmitting periodical beacons [36]. The interval of this window is one minute. It can be seen that the CTD is performing the cycle of mesh provisioning, sensor reading and transmitting the data to the cloud twice a minute. During the time interval of 13 s, the current consumption increased significantly due to the activation of all the radios, including the GNSS antenna. This information can be used to verify the current consumption calculations presented below and to propose a battery pack suitable for the intended use. Figure 19 shows the energy consumption during data transmission via BLE Mesh; the average consumption over 7 s is slightly higher than the value of a full cycle of 60 s (with NB-IoT and GNSS on), as expected, but the peak value is lower because, in the full cycle, the peaks are caused by the NB-IoT/GNSS module operations. Since the test shown in Figure 17 contains all the modules in the active mode, it is taken as the worst-case scenario for sizing the battery pack. As can be seen, the data transmission window is large, approximately 13 s, and occurs twice a minute. On the other hand, the data are being read from the sensors for approximately 34 s between the transmissions. When the data are being sent to the cloud, the pulses reach the maximum current of approximately 350 mA and an average value of 215 mA. Hence, the worst-case scenario would be when the device constantly consumes an average of 215 mA, when it is in transmission mode, while when the device is reading the data from the sensors and not transmitting it to the cloud, the CTD consumes approximately 150 mA on average. Therefore, in a minute, the CTD is in transmission mode two times for 13 s each and consumes 215 mA and then obtains the data from the sensors for 34 s, consuming 150 mA. With this information, the total current consumption in a minute can be calculated, and building on that, the current consumption of CTD in one year can be estimated to verify if the proposed battery pack is viable. According to the intended use, the CTD will transmit data to the cloud four times a day, and each transmission window is large, i.e., 5 min. We refer to this as \"active mode\". When the CTD is not in active mode, the processor turns off all radios and reduces its operations, going into \"deep-sleep mode\".