Bootloading over radio

I currently have 9 wireless temperature and humidity sensors around the house for testing purposes. If I need to update their software, I collect them and do the update with an ISP programmer and then put each back to their proper place. This is annoying, but still quite doable. However, I'll soon have around 20 sensors around the house, and some in the crawlspace and other hard to reach places. I thus started to think more about the logistics of deploying a software update.

Over the air software updates are the proper solution to the problem. The microcontroller I'm using has a dedicated bootloader section at the end of flash, to which the reset vector can be pointed at, as well as a facility to move the interrupt vectors there also. The plan is to have the bootloader send a packet to the receiver notifying it of the type of reset that has occurred, as well as battery voltage, application program version number and whether the CRC of the application area is valid. This is the command mode. The receiver will then respond by commanding the execution of the application program, by commanding the reprogramming of the application memory or by some other commands such as device address programming.

If the execution of the application program is requested, the bootloader restores the microcontroller to a state similar to that after a reset condition, and jumps to the original reset vector of 0.

Reprogramming the application memory is done page by page, where each page is 128 bytes. The bootloader requests a chunk of data indexed by the page and chunk indexes. When all chunks of a page have been received, the page is erased and programmed. When the entire application program area has been programmed, the bootloader returns back to the command mode.

I'm still somewhat unsure what to do with the possible changes in radio configuration (frequency, bitrate, bandwidth, modulation and so on). One possible solution is to store the radio configuration in EEPROM so that both the application program and bootloader can use the same settings. However, the bootloader needs to store a separate failsafe configuration if the configuration in EEPROM is incorrect.

There also needs to be a facility in the application program to get execution back to the bootloader. Here lies the biggest pitfall. If the application program misbehaves, it might be impossible to return to the bootloader without physically accessing the device. Proper testing should thus be done before submitting an update to devices in hard to reach places.

Wireless temperature and humidity sensors

Our house has a crawlspace which has had some humidity problems in the past. Instead of crawling in there to check every spring and fall, I wanted to place instruments there which would do the monitoring year round. Looking online, all the available devices were either much too expensive or do not really meet my requirements (they had dubious calibration, poor battery life and so on). Partly due to this reason I started developing my own sensors. I had played around with the idea of home automation before, so this seemed like as good a starting point as any other function. Some part of me also thought that I might make a few bucks in the process, but this is yet to happen.

I wanted the devices to be small, cheap and have a long battery life. So that one could just scatter them around the house and basically forget about them. I had played around with low power electronics as well as radio communication before, so I kinda knew what I was doing. I decided on using an Atmel Atmega328P for the CPU and a Silicon Labs Si4432 as the radio IC as I had previous experience with both and knew that both of them are very low power devices with broad voltage ranges (1.8V - 3.6V for the Si4432). Also, instead of playing with all the passives required for the operation of Si4432 on the 433MHz band, I used a complete module called the XL4432 available on both eBay and AliExpress from several vendors. The big question, however, was what to use as sensors.

Figure 1. AM2302 (DHT22) on the left and DHT11 on the right.

Initially I had thought of using either Aosong AM2302 or DHT11 digital temperature and humidity sensors. As these require greater than 3 volt power supplies, and I needed to be able to run down to 2 volts, I needed to power them through a charge pump voltage doubler, which proved successful. While prototyping however it became obvious that these sensors could not be used, as they drew a lot of current at power-on. They could not be left constantly on either, as although the quiescent current was much lower that startup current, it was still far too great for a battery powered device with any significant battery life (say greater than 5 years).

Figure 2. First revision of wireless sensor boards. These use the Aosong HR202L (white box seen in the leftmost and rightmost images) humidity sensor as well as an NTC thermistor (reddish glass bead seen in the middle image).

The second idea was to use an Aosong HR202L passive resistive humidity sensor and a precision NTC thermistor. The resistances of the sensors were measured against reference resistors using the on chip ADC of the microcontroller. This idea proved successful in prototyping and I ordered a batch of PCBs from dirtypcbs.com. The total parts cost ended up around 6 euros per board, which wasn't too bad. I built 9 boards, which have now been measuring around the house for more than half a year. I wasn't completely satisfied with the calibration of the sensors though. They are still reasonably correct, with an error of around 1 degree Celsius in temperature and maybe slightly worse than 5 percent points in relative humidity. Of course they could be further calibrated manually, but that is a hassle I don't want to go through.

Figure 3. Second revision of the wireless sensor boards at different levels of assembly. These use the Sensirion SHT20 (marked as U2 on the lower right board) as the temperature and humidity sensor.

The third iteration uses a Sensirion SHT20 digital sensor, which has a respectable typical sleep mode current of 150 nA. This model is the low accuracy model in the line, but it is still accurate enough for me with a typical temperature error of less than 0.5 Celsius and typical relative humidity error of less than 3 percentage points. I ordered once again a batch of boards and have so far built 4 of them, which are still undergoing development and testing. So far I'm very happy with this change. SHT20 is slightly more expensive than the old solution, but the total parts cost is still only around 7 euros. I'll have my batch of 10 wireless sensors soon assembled.

Current optimization of wireless measurement sensors - part 3

After the previous post, I'm now satisfied with the current consumption of the measurement process. There however still remain a lot of things to optimize in the radio communication. See figure 1.

Figure 1. Current usage obtained in previous post. Smaller spikes are due to measurement while larger spikes are due to measurement and communication. Communication power consumption is targeted in this post.

The communication consists of transmitting the data and waiting to receive an acknowledgement of the data. Currently the processor remains active during transmission and the completion of the transmission is polled. The processor should be put in low clock frequency idle and a transmission complete interrupt should be used to wake to processor up. After transmission, while waiting for the acknowledgement, the processor currently also polls the radio for received data until time out. Here also the processor should be put to low clock frequency idle and a packet received interrupt as well as a timer interrupt for the time out should be used to wake the processor up. The time out value should also be made as short as possible. This requires some optimization also on the sink node side, to minimize the time required to transmit an acknowledgement.

Figure 2. Current consumption after implementing optimizations. Communication current consumption has reduced by one third. Wow.

After implementing the idle mode optimizations, the current profile is as shown in figure 2. The height of the communication current peak has reduced by one third. This is far more significant than I anticipated. The average current dropped by 7% percent, which gives a hypothetical battery life of 20.4 years (on CR2032 @ 250mAh). The time out optimization however still remains to be done.

While these optimization reduce the amount of current used when communicating, the most effective optimization might still be to just communicate less often by sending more measurements per communication. This has the flip side of having a lower success rate for transmission and thus requiring more retransmissions, which affect the real average current consumption in a non-predictable way. I might research this further later, but as the current consumption is already quite close to the lowest limit set by the power save mode current, the pay off may be very slight.

Current optimization of wireless measurement sensors - part 2

In the last post I managed to reduce the average current consumption of my wireless temperature and humidity sensors by about 20% to 1.56 uA just by reducing the measurement resolution. Figure 1 shows the current profile after this optimization. In this post I try to reduce the current used in the measuring process, i.e. the smaller spikes, even further.

Figure 1. Current usage after optimizations implemented last time. Small spikes are humidity and temperature measurements and the large spike is measurement together with radio communication

I'm using the sensors in "hold master" mode, in which the sensor IC keeps SCL of the I2C bus low during the measurement. This is the fastest mode to get measurements out of the sensor as no polling or waiting is required. However, when an I2C line is pulled low, current flows through the pull-up resistor. In my case this resistor is 10 kilo-ohms, which produces a current of 300 uA. This current is equivalent to the amount used by the whole sensor IC itself. Furthermore, although the microcontroller (ATMEGA328P) is in idle sleep mode while the sensor IC measures, the idle mode current consumption is still greater than that of the sensor.

My plan is to switch the measurement mode to "no hold master" so that the sensor IC releases the I2C bus and to put the processor into power-save sleep mode in which only the 32.768 kHz low-power crystal oscillator runs. I don't want to mess with the timer prescale settings so that I still have accurate timestamps on the measurements. The prescaler is set to its maximum, which is divide by 1024. This gives a minimum sleep time of 31.25 ms. The measurement time is significantly shorter than this, but this shouldn't increase the power consumption as the sensor IC will go into sleep mode after it completes a measurement. Figure 2 shows the result of this.

Figure 2. Current usage using "no hold master" mode in measurements and putting CPU in power save mode during measurements.

It is evident that the current consumption increased as a result. I guessed that the reason was that it took such a long time to get the processor out of power save mode (start all the clocks and wait for them to stabilize etc.) that all benefit of that mode was lost. I reverted back to using the idle sleep mode of the processor, but lowered the CPU clock speed before doing so to save power. This is very unstatisfying as the internal RC oscillator of the microcontroller already takes about 100 uA of current. With that amount of current at hand, I can't waste time after the measurement has been completed. With this modification the we get the results shown in figure 3.

Figure 3. Current usage using "no hold master" mode in measurements and putting the CPU in low clock frequency idle mode during the measurements.

This modification had the side effect that I also used a lower CPU clock frequency while waiting to receive an acknowledgement of data over the radio. The current used for the radio communication thus also slightly decreased. Longer time period plots of the current usage before and after this optimization are shown in Figures 4 and 5, respectively.

Figure 4. Current usage before this optimization.

Figure 5. Current usage after this optimization.

With these modifications the hypothetical battery life (using CR2032 @ 250mAh) of the measurement devices has gone up from around 14 years to 17.5 years to 18.9 years. Of course this is probably nowhere near the actual battery life as real batteries have non-ideal behavior such as self discharge and high internal resistance, also these measurements assume a 100% success rate in radio transmission. I'm confident though that they'll last at least a couple of years.

Current optimization of wireless measurement sensors - part 1

I've been developing wireless temperature and humidity sensors as commercially available ones are not good enough or too expensive, often both.

I'll post on the sensors perhaps later, but right now I'm working on reducing their power consumption. They have an approximately 1 uA sleep current, which I currently don't know how to reduce further.

Initially, when measuring every 5 minutes and transmitting 3 measurements at a time over the radio, I got an average current consumption of around 2 uA. Initial current consumption over time is show in figure 1. This was measured using the setup described in the previous post and using the data port of my UT61E.

Figure 1. Initial current usage.

The smaller spikes in figure 1 are due to measurement only while the larger spikes are due to both measurement and communication over radio.

The measurement time used by the sensor (Sensirion SHT20) is significantly reduced when the measurement resolution is lowered. According to the data sheet of SHT20, the measurement with full resolution takes a maximum of 350 uA for 114 ms, which translates to about 40 uC of charge. The measurement with the lowest resolution however takes a maximum of 350 uA for 15 ms, which translates to about 5 uC of charge. This was the first course of action to reduce current consumption. The result of the first try of this is shown in figure 2.

Figure 2. Current consumption with what I thought was reduced resolution measurements.

Surprisingly the measurement resolution didn't seem to have any impact on the current usage. I suspected some error in configuring the sensor, and sure enough, after a long time debugging, I found the problem. I had assumed the datasheet listed the configuration bits in order and didn't pay attention to the actual indexes... Figure 3 shows the current consumption when actually using reduced resolution measurements.

Figure 3. Current consumption with reduced resolution measurements.

As can be seen, the reduction while measuring is quite significant, bringing the average current down by about 20%. However, integrating over a single measurement spike gives around 20 uC (this is computed ignoring the background current of ~1 uA). This is quite large compared to the maximum of 5 uC used by the sensor, and suggests that the majority of the current is consumed elsewhere. This will be the course of investigation in the next part.

Measuring average current of low power devices

Low power devices often spend most of their time in some sort of sleep mode, in which the power supply current is very low (some hundreds of nanoamperes typical). However, at times they wake up and can draw very large currents for a short period of time. The average current of such devices is often of interest, for example to estimate battery life.

Measuring the current directly is infeasible, due to the very large current range as well as the short duration of the high current pulses. A simple solution however is to measure the current through a RC filter circuit as shown in figure 1.

Figure 1. Measurement setup.

There are a couple of things to consider though when doing this.

• The time constant of the RC filter needs to be much longer than the measurement period of the multimeter used
• Electrolytic capacitors initially exhibit large non-constant leakage currents
• Resistive voltage drop

A nice trick is to use the measurement resistor of the multimeter as the R of the circuit and to choose the capacitance then accordingly. My UT61E updates twice per second and has a measurement resistance of 1 kilo-ohm in the microampere range. I've used a capacitance of around 15000 uF, which gives a time constant of 15 seconds. The time constant shouldn't be too long either, as it makes the required measurement time longer.

The leakage current of electrolytic capacitors may require a long time to stabilize. After 24 hours of operation my bank of 15000 uF still had 500 nA of leakage, but decreased to around 40 nA after 48 hours. Constant leakage currents due to the measurement setup are simply subtracted from the measured average current.

I've never had a problem with any significant voltage drops with this setup. However, the voltage drops can be made smaller by increasing the capacitance. Notice that the average voltage seen by the load is still dependent on the average current and the resistance.