A sea level measurement station is a good example of an IoT use case of monitoring at remote locations, where requirements on the internet accessibility and long battery life are high. It is also a good showcase of few steps that can be taken in the product development to assure low current consumption hence less battery drainage. In this blogpost we go through two of the steps, with detailed measurements shown in the associated part 2 video that you can watch below.
As a recap, the DYI sea level indicator device is based on an Arduino MKR1400 GSM, which contains a SAMD21 Cortex-M0+ 32bit low power ARM MCU, and a SARA-U201 HSPA module from u-blox, that with an added SIM card provides 2G and 3G connectivity. It is connected to an ultrasonic transducer, KS103 for the actual water level measurements. The entire set-up is powered by 3.7V LiPo battery, in this case simulated by Otii.
In this set-up, with no energy optimization efforts made, the results show an average power consumption of 16.6 mA, for a simple activity: Send Data (SMS), Wait 1h, and Repeat.
The first step of the optimization would be to put the MKR1400 in sleep mode using Arduino RTCZero library, and making sure unused pins are not floating. This brings the average current to 3.3 mA. However there are still peripheral components awake which means that this Idle state is still using a lot of energy, more precisely 90 % of it.
To further lower the power consumption we added Arduino Pro Mini with a MOSFET to control the power to the entire MKR 1400 and KS103.
Adding Arduino Pro Mini as a power switch to peripheral components results in the current decreased to 5uA, which then results in the average current of 0.4 mA, for the activity: Send Data (SMS), Wait 1h, and Repeat.
The hardware design considerations such as adding the possibility to switch off the peripheral components besides putting the modem and CPU in idle mode can give significant improvements in energy consumption. As showcase here, the increase of the battery life of this sea level indicator can be up to 40 times, compared to the initial non-optimized setup. Additional thing to consider is the activity type, what is its purpose and if the active part (sending data) can be less frequent without losing the purpose of the device.
Regardless of what steps are being taken in the development of the IoT device, the important thing is to measure the performance at all instances, to get better insights of the system performance of the device when optimizing.
The Qoitech Team