With the LiPo battery “blipping” along happily for years now, I’ve started two new tests, based on the JeeNode Micro v3. Here’s the boost unit, running an updated radioBlip2.ino:
This one converts the incoming 1.2 .. 1.4 V from a single-cell Eneloop AA battery to roughly 3.0 V, as you can see in this overview in HouseMon (using an updated “radioBlip” driver):
The other new node runs off a CR2032 coin cell, which is struggling a bit to maintain a stable voltage each time a packet gets sent out, as indicated by the 3.20 -> 3.08 V drop. In case you’re wondering how a node can report its battery voltage after already having sent the data, simple: measure the voltage and send it out in the next packet.
The technique used to measure one’s own battery voltage was described in a post last year. Measuring the battery voltage in this way does not consume very much power in itself, since the ATtiny is placed in a special low-power “ADC-only” sleep mode while doing so:
The energy used for the measurement is the area under those last four little “blips” after the main packet transmission: there’s almost no penalty in performing this measurement before and after each packet transmission. Over time, hopefully the trend of the before + after voltages can be used as predictor for the amount of life left in them little coin cells…
PS – The main change in the radioBlip2 sketch, apart from adapting it to work on the ATtiny, is that the packet now includes a “sender ID” byte. This way all the battery test nodes can re-use the same node ID here at JeeLabs – since the number of ID’s used is starting to become a concern (there are 30 unique ID’s in each net group). For nodes like these, which only send, it’s no problem at all to “re-use” node ID’s this way.
Update – I’ve added a “BOOST” option to report the battery input voltage, which is much more useful. It’s measured with a jumper from PWR to the AIO pin (PA0, analog 0).
FYI: The link to the updated “radioBlip2.ino” is broken (I’d love to see the source to that sketch though :-)).
Good catch, thanks – fixed. It’s in the usual place: in the examples/ folder in JeeLib.
Murphy: Does PA0 draw a unsignificant current from the battery?
Should be ok – no voltage divider, direct analog input, as Vbat is less than Vcc (i.e, boost output).
An ATMel I/O pin is indeed a curious beast. Even with all possible options of driving/listening to the pin turned off, it leaks ~1µA at 21ºC with a strong temperature dependence. Now here is the oddity – the direction of the leak is undefined (phase of the moon stuff)!
In this particular case, with chip Vcc higher than Vbatt, the leak is out of the pin, in a tiny way charging the battery back up again, so should not go on the “loss” scorecard as is.
Perpetual motion anyone? ;-)