Power Consumption

When not measuring/transmitting data, Canique Climat roughly draws 1.87 µA at a voltage of 1.5V in hardware revision 0.6, and only 1.02 µA in hardware revision 0.7. We're going to have a look at revision 0.6 here.

What does this amount of consumption mean for battery life? Powered by a single AA cell with a typical capacity of 2500mAh, we can expect the following theoretical battery lifetimes at ~ room temperature - the estimated battery self discharge rate is specified in brackets:

Transmission intervall	Battery Life Time @ High TX Power	Battery Life Time @ Low TX Power
30s	11* years [15%]	16* years [20%]
60s	20* years [20%]	27* years [20%]

*) The values beyond 10 years are theoretical values since a typical alkaline battery itself has a shelf life of 10 years. Hence the real estimated battery life time is about 10 years.

In the lowest TX power setting, measuring/transmitting takes about 30ms and consumes 11.6 mA on average. In the hightest TX power setting (see image below) the 30ms stay unchanged but the average consumption goes up to 18.2mA. The image shows the current drawn from a 1.25V lab power supply - using a uCurrent in mA setting.
On the image you can see the different stages after wakeup:

Sensor measurement
Encryption
TX @ 13dBm
RX of acknowledgment
Decryption

Something that has even a bigger influence on the battery is temperature. When the temperature is very low, battery capacity might drop by 50%. At -20°C you can expect a bad performance from any typical alkaline battery. This is also due to the fact that the internal battery resistance increases at low temperatures.

But there is a simple solution to this problem: non rechargable lithium batteries. They are available in AA size, and they have no troubles at extremely low temperatures, as low as -40°C!

So, what would the estimated theoretical battery lifetime be with a 3000mAh AA sized Energizer Ultimate Lithium?

Transmission interval	Battery Life Time @ High TX Power	Battery Life Time @ Low TX Power
30s	14 years [15%]	20 years [15%]
60s	25* years [15%]	35* years [15%]

This time the battery itself has a shelf life of 20 years (!), besides the battery will run at very low temperatures, and on top of that it has an increased capacity of 3000mAh. So you can expect a battery life of 20 years using a 1 minute transmission interval.

All these figures are related to the revision 0.6 of the Canique Climat. (I posted different figures earlier this week that have improved with this latest revision)

Reducing message size

So, how to achieve this low level of power consumption?

The one thing is hardware - selecting components that are ultra low power. The second thing is software: Canique Climat makes use of low power modes excessively. It also keeps transmitted messages as short as possible.

Just 1 example from the software perspective: Say you want to send a temperature measurement of 23.54°C and a humidity level of 69.12%. How would you send this data?

A beginner might send characters, each character is enclosed in brackets here for readability:

[2][3][.][5][4][*][6][9][.][1][2]

That's 11 bytes in total.

Now you could leave away the 2 dots and the asterisk, because the message always has the same format - first the 4 digit temperature, then the 4 digit humidity. Then the message size would still be 8 bytes.

Sending bytes instead of characters would signficantly reduce payload size. We could send 23 as 1 byte, 54 as 1 byte, 69 as 1 byte and 12 as 1 byte. So we'd have cut the message size to a total of 4 bytes.

The alternative would be to look at the temperature as 2354 centi degrees. This would also fit into a 2 byte integer. Same thing for humidity: 6912 %*100. But we'd still be at 4 bytes total message length.

We started at 11 bytes and shrank the message to 4 bytes.

Canique...

HW rev 0.4 / 2500 mAh battery: Still running
canique • 04/20/2025 at 16:38 • 0 comments

After 4 years this sensor is still sending like a champ: every 30 seconds.
HW rev 0.4 / 2500 mAh battery: 3 year timeframe
canique • 02/02/2024 at 11:46 • 0 comments

This battery voltage chart shows a Canique outdoor sensor sending every 30 seconds - from March 2021 until February 2024.

From looking at the chart you can conclude, that 10+ years battery lifetime should be easily achievable.
In 3 years we had a total battery voltage decrease of about 0.1V. Note that the battery cutoff voltage is somewhere < 0.9V. So we can drop another 0.1V at least 4 times before the battery is depleted. That's 4 times another 3 years, or: 12 years to go.
HW rev 0.4 / 2500 mAh battery: 2 year timeframe
canique • 02/06/2023 at 13:52 • 0 comments

This battery voltage chart shows the previously shown outdoor sensor - now until 6th February 2023:
HW rev 0.6 / Varta Industrial: battery voltage over 13 months
canique • 02/06/2023 at 13:37 • 0 comments

This chart shows the same sensor as in the previous log entry - now over a timespan of 13 months (until 6th February 2023)
Battery voltage drop over 1.5 years
canique • 08/25/2022 at 21:57 • 0 comments

HW rev 0.4
This is the plotted battery voltage data of a sensor (HW rev 0.4) ranging from 2021-03-11 until 2022-08-25: thus showing battery voltage over an almost 1.5 year time frame using an Alkaline 2500 mAh AA battery.

The battery voltage drops from roughly 1.57V to 1.5V after this time.

You can also see that the voltage drop is not linear - it starts fast and then stabilizes around 1.5V.

Please note that this HW rev. 0.4 has a a higher quiescent current than HW rev 0.6 - thus with HW rev 0.6 the battery voltage drop will even be smaller.

The cutoff voltage will be around 0.9V.
HW rev 0.6 / Varta Industrial

The next chart shows a HW rev 0.6 sensor with a Varta Industrial AA battery over a nearly 9 month time frame.

The battery voltage drops from 1.62V to 1.56V during that time. It has not stabilized yet and will probably do so once the nominal voltage of 1.5V is reached.
We can roughly say that within 9 months the battery voltage has decreased by 60mV. If we assume the decline is linear (which it isn't, the steepness gradually decreases), then we could expect an 80mV loss every year (=12*60/9).
After 8 years the battery voltage would reach 980mV (cutoff ~800-900mV). So even in the worst case we can expect an 8 year battery lifetime here. Note that this is with a linear approach. The battery can last longer because after reaching 1.5V the battery voltage will drop slower than currently. You can even see it in the chart if you look closely: the width of the steps is getting larger and larger. At first there are many tiny steps, and at the end the voltage stays at the same level for a longer time.
Temperature vs Voltage Reference

The reason why the second chart seems much cleaner (voltage dropping like a staircase in steps) than the first chart is probably because the first sensor is mounted outside and affected by big variations in temperature. This influences the internal voltage reference used for measuring the battery voltage. That's why sometimes the first chart has little spikes to the upside.
Ordering possible now
canique • 01/02/2022 at 19:19 • 0 comments
The Canique Climat Set can be ordered now:
The Radio Hat for Raspberry Pi is a cheaper alternative to the gateway. If you already own a Raspberry Pi, it is be a better fit.

So you can use
Canique Climat + Radio Hat to have a running system OR
Canique Climat + Gateway

What else is there to say?
- Canique Climat's bootloader is passwort protected and uses Ed25519 to verify the authenticity of the image. Firmware images are encrypted and signed. Firmware Updates are done via UART (so one need's a USB to UART converter) using a python script as of now. An update roughly takes 10 seconds.
- Canique Gateway's bootloader has no password protection but also uses Ed25519 to check the authenticity. Firmware images are again encrypted and signed. Firmware Updates can be done directly within the device - no need for any external circuit.
Web Cockpit: latest state
canique • 10/10/2021 at 12:04 • 0 comments

Web Cockpit now offers full sized charts with more details, on/off switchable temperature/humidity. 24h to 30 days time windows.
Overview:
Web Cockpit is evolving
canique • 09/02/2021 at 12:22 • 0 comments
Web Cockpit is available
1. in the local network via the IP address of the Canique Gateway (no internet access needed) and
2. on the internet via an https URL
Sensor values (including battery status and signal strength indicator) are updated live as soon as new measurements arrive. Widgets are automatically grayed out if no values arrive for a certain period of time.

Web Cockpit runs in all modern browsers: Tested on iPad Safari, Android Chrome, Linux Chrome

Features
- Gateway offline indicator (web version)
- Sensor outdated indicator (if no sensor values arrive for a certain period of time)
- Graph outdated indicator (if chart cannot be updated)
- Live sensor reading / battery status / signal strength / sensor label updates
- Switchable chart between temperature and humidity (by clicking on it)
- Regular automatic chart updates
- Automatic reconnect on connection loss
- Connection indicator (top right corner)
- Sophisticated configurable alarm triggers (notification via e-Mail) with javascript expressions
Hardware revision 0.7
canique • 06/23/2021 at 14:38 • 0 comments

The latest revision 0.7 uses a Cortex M4 MCU instead of a Cortex M0+.
This even further reduces quiescent current: The total sleep consumption compared to rev 0.6 is reduced by 1 µA under typical conditions.

Total quiescent current @ different voltages, room temperature

Input Voltage Quiescent Current
0.8 V 2 µA
1.0 V 1.56 µA
1.25 V 1.24 µA
1.5 V 1.02 µA
Firmware Updates - Part 1
canique • 05/30/2021 at 10:59 • 2 comments

As far as secure firmware updates are concerned, I'd like to refer to François Baldassari to get in-depth information - https://interrupt.memfault.com/blog/secure-firmware-updates-with-code-signing

Basically you have 2 options when deploying firmware updates:
You either use
a) symmetric crytpography alone or
b) also make use of asymmetric crytpography.

As for a)
You can use an AEAD cipher again for encrypting/signing your image. The problem is: If you use the same symmetric key for all devices, then once 1 device gets hacked and the internal key extracted, an attacker can sign firmware updates for ALL devices! That's the problem with symmetric encryption: The key that's used for verifying whether an image is authentic, is also used for signing the image.
So you'd need to install a unique key on every single device. That again would mean that when deploying a firmware update, your update server would need to know all the keys of all the devices where you want to send updates to.
This would probably mean that your update server needs to store all device keys, which is a security risk per se.

As for b)
In scenario b) symmetric encryption is used to keep the firmware secret, and asymmetric cryptography is used to verify the authenticity of the firmware.
Encryption could still be some symmetric AES or Chacha20 cipher with a key common to all devices. The worst thing that could happen is, that once an attacker gets hold of the device internal key, he can decrypt all future images. But if the attacker has managed to extract the key already, he'll probably also manage to read the rest of the firmware anyway.
When it comes to authentication you'd go with ECDSA - a digital signature algorithm based on elliptic curves which is computationally very intensive (unlike symmetric ciphers).
You create a key pair - a public and a private key. The private key is used to sign the firmware update and should not be on a machine that is online. The public key -on the other hand- is stored on every IOT device. It's public.
Even if it is extracted from the device, it cannot be used to sign an image as is the case with a). The public key can only be used to verify an image.
An ECDSA library can be found under https://github.com/ncme/c25519
Some are using a library called micro-ecc but it has many unresolved issues - I wouldn't recommend it therefore.
While writing this, I stumbled upon an ECDSA implementation for Cortex M4 written in assembler: https://github.com/Emill/P256-Cortex-M4