Of utmost importance to IoT designers is often the power budget, as battery powered devices may need to be manufactured to meet a given lifetime on a non-rechargeable battery. Efficient radios, power conversion circuitry, microcontrollers and software are necessary to make the most of the power budget while considering peak power usage demands and cost.
In this blog, I try to characterise the power consumption of the SDAWIR03 cube using a Rohde & Schwarz HMP4040.04 Bench-top Power Supply and a Rohde & Schwarz RTM3004 Mixed-Domain Oscilloscope. I also examine the traffic patterns over the I2C bus to verify how the cube firmware and sensors are operating.
Operating Voltage Window
My first curiosity was to understand what the operating voltage window is for the cube. Being able to be powered from two CR2032 cells implies that it is able to handle at least a little more than 6V input, but how low can we go before it stops working entirely?
As it turns out, the answer appears to be about 2.029V. Below about 3V, the LEDs stop functioning entirely and the flow sensor appears to act a little strange, but packets are still being sent to and from the hub. This appears to correlate well with the ZWIR4512 datasheet which claims that the supply voltage can be as low as 2V if the ADC is not used (as per this case), requiring at least 2.4V if the ADC is used.
Then, you might be wondering, why does the unit need two CR2032 cells? After all, the HS3001 can handle voltages down to 2.3V as well. The answer probably lies in the fact that CR2032 cells have a fairly high internal resistance and are hence generally best suited to loads averaging about 0.5mA at most (although it is possible to get away with loads of several mA but it would be unlikely to be able to use all of the capacity). By having two cells and a higher voltage, the onboard switching step-down converters can produce a stable lower voltage for the sensors and radio circuitry at a higher current and thus extract more run-time from the battery. It also means that during high current bursts, the voltage would not dip low enough to stop the unit from working.
That being said, based on the previous run-time experiments, we can see that when the battery voltage measures about 3.3V to 4V, the unit stops working. This is because that is probably the “idle” voltage – a transmission burst consumes enough power that the voltage of the cells would collapse below the ~2V required to operate the module.
Power Consumption Profile
Based on the previous run-time experiment, I determined that operating at a 2000ms interval with the temperature sensor alone would probably consume about 1.1mA average current from the CR2032 cells. I would like to know with more accuracy, what the load looks like, as this will have a bearing on the types of battery that can be used and the lifetime that can be expected. Understanding the current requirements both with and without the flow sensor should give an idea of the current consumption of the flow sensor. Examination of different transmission parameters would also give a better understanding of how the report rate influences battery use.
In order to do this, I decided to clip the positive to the battery supply positive and the negative through a shunt resistor to the shell casing of the USB micro-B port, which is commoned to ground. I started with 100-ohm 5% resistor but this was too high, so I settled on a 12-ohm 1% resistor to make my measurements.
5V 2000ms Interval
With both sensors installed, the current profile looks like this:
There is a constant background draw of about 29mA, much of which is attributable to the flow sensor itself, which according to the datasheet has a typical 30mA current consumption. The cyclical 2mA pattern in the background is due to the LED on the flow sensor module, which flashes whenever the sensor is powered. I suspect this is because the flow sensor may have its own microcontroller which is always active. The spikes above this are the periods where the ZWIR4512’s microcontroller has powered up, is querying the I2C bus and is transmitting data. The average consumption is 29.477mA. This makes it clear why operating from CR2032 cells is not possible.
With just the temperature sensor installed, the current profile drops significantly:
The background draw is closer to 1mA which represents the consumption of the ZWIR4512 with the transmitter off (0.7mA) and the draw from the temperature sensor (0.6-24µA depending on mode), plus losses in the regulator. The average consumption is 1.6891mA. I cannot be certain whether the ZWIR4512 is placed into the lower consumption states of stop/standby which consume even less (3.5µA-26.5µA) but I suspect not based on the measured results. Perhaps the power draw could be further optimised.
5V 1000ms Interval
Dropping the interval to 1000ms and repeating the experiment gives the following results:
With both sensors in place, the average current is now 30.166mA and 2.3118mA respectively. A reduction of transmission interval by half results in a power consumption increase by 2.34% and 36.87% respectively. This is due to the way the idle overhead affects low-duty cycle operation compared to the burst current required for transmission.
5V 500ms Interval
Dropping the interval to the minimum 500ms and repeating the experiment results in unusual results as the unit appears not to be sending at the requested 500ms interval but is sending as often as it can.
In this mode, the average current is now 43.778mA and 16.249mA, an increase of 48.52% and 862% over the 2000ms interval mode respectively. The actual interval appears to be closer to 110ms.
Close-Up on the Burst, LED & Voltage Influences
To better understand peak current consumption, a close-up examination of the burst is necessary. To reduce the noise, the 20MHz bandwidth limiter was engaged. Samples are with the temperature sensor only, as the flow rate sensor really skews the results with a big quiescent draw and periodic LED blink.
Starting with the 5V burst, we can see the background level is about 1.0156mA with the peak burst being about 28.944mA. There are several phases to the “active” period of the ZWIR4512’s microcontroller. The initial level around 10mA suggests that the software has “woken up” the radio and it has become active in receiving mode. In this initial time, queries were probably made on the I2C bus with a wait of about 40ms for the measurements to be complete. The first long spike may be the data being sent followed by a wait for an acknowledge. The second spike may have been another piece of data being sent, followed by a wait for acknowledge then power-off of the radio. Active time measures about 120ms.
To understand whether input voltage has much influence on the current, I repeated the tests at 3.3V and 2.5V.
At 3.3V, the measured currents were 1.2109mA and 33.006mA, slightly higher probably as the regulator is not stepping down at all now. At 2.5V, it became 1.0156mA and 30.389mA which is about the same as it was at 5V. As a result, the current does not seem to change much, although operating at this lower voltage, the reduced current may be due to the characteristics of the ICs themselves rather than due to regulator (in)efficiency.
To try and understand what the peaks are, I decided to (very carefully) probe the I2C and radio indicator LEDs with the current profile. The results are as follows:
It appears that the LEDs may be responsible for almost 2.5mA of consumption each. Removing them would improve the efficiency of the unit operating on battery. In general, it seems the LEDs corroborate my interpretation of what is happening with the spikes corresponding to active periods on the communications LED and the initial ~40ms+ window being attributed to I2C communication.
I2C Bus Transactions
This got me wondering as to what transactions were flowing across the I2C bus. With some careful probing, it was possible to observe the bus and decode the data.
It was determined that the I2C pins exhibit a “start” condition with no data as the microcontroller of the ZWIR4512 “wakes up”. This is followed by one burst initially, a space of about 35ms, then another burst.
Because of the long timebase, the data was not decoded successfully on this capture, so instead I took both bursts individually instead.
The first transaction appears to be a write to the Flow Sensor of seven bytes. The datasheet does not seem to elaborate as to the possibility of writing anything to the sensor, only saying that the data is read as two bytes from the sensor. I suspect this may be an undocumented command to identify the type of sensor installed. This is followed by a read of four bytes which returns a reading in the first two bytes and two extra bytes. Then, the Humidity and Temperature sensor is addressed, which starts a measurement request. Conversion time required is about 17ms from sleep, although instead of polling for status, it seems that the microcontroller just waits a fixed time before reading the humidity and temperature sensor, followed by the flow sensor in the second burst.
By looking at the transaction, it is clear why the temperature readings are limited in resolution. The HS3001 is capable of 14-bit resolution for both humidity and temperature, returning four bytes of data, humidity first. As the read is terminated after three bytes, the best temperature resolution capable with just the MSB is calculated to be 0.64457059 degrees Celsius, which is what is observed. I think this “shortcut” is not a particularly good one to take, as the conversion time of the sensor is constant, so the accuracy doesn’t cost extra energy or time on the sensor side. Processing an extra byte is probably not that much of hardship either.
The gas flow sensor has a sample rate of 0.4096 seconds per sample, but can continually output data to I2C, thus the “wait” time of about 35ms seems to be a bit excessive and perhaps wastes battery power unnecessarily. Reading the value more frequently than the sample rate of the sensor is also wasteful (e.g. when set to 500ms interval and actually returning samples every ~110ms).
There appears to be no other requests on the I2C bus, so it appears the kit does only support these two types of sensor from IDT without modification.
The SDAWIR03’s sensor cube was determined to operate as low as 2.029V from a bench power supply, with the LEDs failing to function below about 3V. This matches well with the ZWIR4512 datasheet which allows operation down to 2V without use of ADC or 2.4V with the use of ADC. Use of two CR2032 cells is necessary to ensure the voltage does not fall below this level during peak current demands (e.g. during transmission), especially as CR2032 cells have rather high internal resistances as they are designed for continuous loads of about 0.5mA.
The power consumption profile as measured shows that with the flow sensor installed, a background consumption of about 29mA is registered with a cyclical component of about 2mA corresponding to the LED on the flow sensor, making it clear why battery operation is impractical. At 2000ms intervals, with both sensors installed, average current is 29.477mA. With just the humidity/temperature sensor installed, this falls to 1.6891mA, with the background closer to 1mA which suggests the ZWIR4512 is sitting with the radio off but not in its deeper standby/sleep modes. This suggests there could be room for further improvement, especially as the I2C and radio indicator LEDs were also observed to consume about 2.5mA each.
With the duty cycle changed to 1000ms intervals, the current increased to 30.166mA and 2.3118mA. At 500ms, the module reported about every 110ms and consumed 43.778 and 16.249mA respectively. The difference is mainly due to the quiescent draw versus the peak draw.
Looking at the current profiles closely, it appears that the unit wakes up and spends about 40ms on I2C communications, followed by two spikes for communication. The current draw did not change much with voltage, peaking in the 28-30mA ball-park.
Decoding the I2C bus makes clear that the unit seems to query the Flow Sensor in an undocumented way, perhaps to determine its model, followed by waking the temperature sensor for a measurement. It waits a fixed period of time (about 35ms) before reading the values from the temperature sensor, followed by the flow sensor. This amount of time is longer than the 17ms claimed by the datasheet, resulting in excess energy consumption. Only reading three-bytes of results means the LSB data for the temperature is lost, limiting the resolution to 0.64457059 degrees Celsius rather than the datasheet stated 0.015 degrees Celsius that the sensor is capable of. This seems to be a rather unfortunate tradeoff. No other addresses were seen to be queried by the bus, thus only these families of sensors from IDT are supported without modification.
This blog is part of the IDT SDAWIR Wireless Flow Rate, Humidity and Temperature Sensing Evaluation Kit RoadTest