Even though Bluetooth LE has been designed as a low power consuming Communication Protocol, the effectiveness of BLE in this project as a battery saver is a matter of debate, which needs to be checked practically.
Bluetooth LE has an energy curve or “Current Draw Cycle) like the one in the figure below. As can be seen from the figure below, BLE remains in the “Sleeping” mode most of the time for its operation while it only “Wakes Up” during data transmission. Then it processes the data and sends/receives it as packets.
As can be seen, the most amount of power is consumed during Tx/Rx or data transmission. This is the main difference between traditional Bluetooth and Bluetooth LE (Previously Bluetooth Smart). But in this case, the patient will be wearing the device during testing, and data will be sent from the peripherals during the whole time without any break. So, the device will not have the chance to enter into any power-saving mode.
Low power modes play a crucial role when the device needs to be turned on for a long time and requires sending data occasionally. The exact values of current draw (i.e., power consumption) are more device-dependent than the communication protocol itself. Moreover, the other components of the device require power as well. So, the ideal power consumption provided by the Bluetooth authority for BLE is not the only power our battery requires to supply during data acquisition and transmission form the est subjects. For esp32, power consumption in each mode can be found from its datasheet, as provided in following table:
As can be seen from the table above, Bluetooth (BT), or Wi-Fi cannot function during any low power mode. So, the low power of the feature of BLE is literally unutilized during this project, where the patient will wear the device for some time during the day (during which the device should function non-stop). Then it would remain shut down the rest of the time.
Now, based on this, the power consumption of the esp32 module during BLE data transfer was checked using a Universal Serial Bus (USB) based Digital Multimeter, as shown in the figure below.
The USB represents the current draw (A), Voltage (V) and Power Consumption (W) per unit time, and the energy consumption in Watt-hour (Wh). Both the current draw per unit time and energy consumption were studied in order to understand the power consumption of the device during BLE operation.
The USB Tester has a timer in it. Data transfer via BLE was performed for 1 hour in order to record the total energy consumption. It was observed that the current drawn was varying over time, discretely from 0.05A to 0.14A (as well as power). But the total energy consumption recorded was about 0.4 Wh, i.e., in one hour, the device consumed around 0.4W power. Mentionable that the voltage supplied for the esp32 was approximately 5V.
For performing a simple calculation for battery life, let the battery capacity be 1000 mAh (since Li-ion or LiPo batteries are planned to be used for their rechargeability, their service life is normally measured in terms of mAh). Li-ion or LiPo batteries supply 3.7V. So, the energy rating of the battery will be around 3.7Wh.
Then the battery can safely run the circuit for 9.25 Hours approximately. So, if someone wants to use the device half an hour a day, it will take him/her about 19 days to deplete the battery from 100% without recharging it.
Mentionable that the test was performed on a prototype esp32 board from Heltec Co. While the board planned for the project is TinyPico esp32. Their power consumption needs to be justified before soldering them on the PCB. But it should not be very much different from this value, preferably less. The reason is esp32 Wi-Fi kit from Heltec has an onboard power LED constantly blinking, which consumes extra power, which will cost a lot in the long run.
Possible ways to cut down power consumption,
- Turn off the onboard power led (It requires to be disconnected. Since it is hardwired, it cannot be turned off by code). TinyPico does not blick it normally, except while charging a battery.
- Minimize CPU usage on the peripheral side. It can be done in many ways. For example, lowering down the Tx/Rx power. But in that case, the tradeoff will be required to be done on the connection stability and power consumption.