Canique Climat

A temperature/humidity sensor ecosystem designed for ultra low power and ultra high security.

Similar projects worth following
Meet the Canique Climat: a unique temperature/humidity sensor.

Ultra low power consumption: 1.24 µA powered via 1 AA battery (with latest revision 0.7).

Ultra long battery lifetime: up to 20 years with a single AA lithium battery, up to 10 years with a single AA alkaline battery.

Ultra secure: AEAD cipher with 256 bit of symmetric security and replay attack protection.
Firmware updates that are signed with an asymmetric elliptic curve signature and encrypted with 256 bit symmetric encryption.

Ultra precise: 0.2°C absolute accuracy between 0°C and 60°C

Power Consumption

When not measuring/transmitting data, Canique Climat roughly draws 2.5 µA at a voltage of 1.25V in hardware revision 0.6, and only 1.24 µ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 intervallBattery Life Time @ High TX PowerBattery Life Time @ Low TX Power
30s11* years [15%]16* years [20%]
60s20* 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:

  1. Sensor measurement
  2. Encryption
  3. TX @ 13dBm
  4. RX of acknowledgment
  5. 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 intervalBattery Life Time @ High TX PowerBattery Life Time @ Low TX Power
30s14 years [15%]20 years [15%]
60s25* 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:


 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 Climat...

Read more »

  • Hardware revision 0.7

    canique06/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 VoltageQuiescent Current
    0.8 V2 µA
    1.0 V1.56 µA
    1.25 V1.24 µA
    1.5 V1.02 µA  

  • Firmware Updates - Part 1

    canique05/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 -

    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
    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:

  • Cryptography used in Canique Climat

    canique05/22/2021 at 15:11 3 comments

    Security Goals

    First off, let's have a look at the security goals for this project:

    1. Measurements must be authentic: they must stem from the sensor, and not be manipulated or injected by some other third party
    2. Measurement data must be transmitted in a secure way: a third party who is listening to the radio traffic must not be able to conclude what has been measured


    To fulfill 1) encryption alone is not sufficient - some kind of message authentication code is required. Canique Climat uses an AEAD: Authenticated Encryption with Associated Data.
    There are 2 robust AEAD ciphers: AES-GCM and Chacha20-Poly1305. Canique Climat uses the latter one. The message format looks like this:
    [Message header] [Encrypted Payload] [Authentication Tag]

    The message header provides information about who's sending to whom, and how to decrypt the message. The authentication tag is calculated based on the payload and the message header. To calculate the authentication tag, you need to have the secret key used to encrypt/decrypt the message.
    The tag changes whenever the message header or payload changes.
    If any bit is incorrect (e.g. transmission error) in the message header or payload or if the authentication tag itself has been manipulated, the authentication tag won't match the message and the receiver of the message will treat the message as a fake message.

    When you want to encrypt/decrypt a message with Chacha20-Poly1305, you need 3 things: the key, the message and an IV (96 bit long initialization vector).
    The IV must be unique for every single message where the same key is used. This is an absolute security requirement. So it is wise to have some sort of a counter in the IV. Sender and receiver must use exactly the same IV for successful encryption/decryption of the same message - but with every message the IV must change to some IV never used before. The IV itself is not secret. So you can transmit it or parts of it (like the counter).

    Canique Climat transmits parts of the message counter in the message header. The receiver reconstructs the full IV from that counter. It is important to note here that when building the authentication tag the full IV needs to be authenticated.

    So by using Chacha20-Poly1305 we can make sure that both our requirements 1) and 2) are fulfilled.

    Replay attacks

    Now imagine the following scenario: Your authentic device transmits the value -18.59°C at 15:00. 2 hours later an attacker retransmits the very same message, bit for bit. This is called a replay attack.
    Some valid transmission recorded beforehand is replayed by a third party. The real temperature might have rosen to -12.00°C but your receiver is thinking the temperature is still -18.59°C.
    The same scenario works for door status - Canique Climat can also be used as a reed sensor by the way. By using a replay attack you could fool a receiver into thinking the door is still closed/open or has just changed its state.
    Canique Climat has a countermeasure against this kind of attack. It's a counter in fact. The message counter used for the IV is also used for replay attack prevention. If the receiver receives a message with a message counter that he has already received and successfully decrypted, the next message that the receiver will accept will be one with a higher message counter. The latest/highest message counter is stored and compared to the currently received one.

    Hardware Cryptography in RFM69

    Now let's compare Canique Climat's rather sophisticated software based approach to the hardware AES engine in the RFM69 (SX1231 transceiver)
    RFM69 is said to be using AES-ECB mode - see

    Quoted from that forum:
    I checked the cipher mode used in the radio module, (I couldn't find it in the datasheet), the AES cipher mode turned out to be ECB unfortunately ( Also, as required with a block cipher, data is zero padded...

    Read more »

  • Hardware revision 0.6

    canique05/22/2021 at 12:36 0 comments

    The latest revision offers:

    • reduced quiescent current from 9.5µA to 2.5µA (@ 1.25V)
    • reduced ripple voltage during RX to 4.5mV (@ 1.25V)

    Total quiescent current @ different voltages, room temperature

    Input VoltageQuiescent Current
    0.8 V3.55 µA
    1.0 V2.83 µA
    1.25 V2.25 µA
    1.5 V1.87 µA

View all 4 project logs

Enjoy this project?



Simon Merrett wrote 05/18/2021 at 07:02 point

Hi, I'm definitely interested in a follow-up log on crypto in this application. Thank you for offering. 

  Are you sure? yes | no

canique wrote 05/18/2021 at 11:13 point

Thank you for your interest. By the end of the week I'll write more about crypto and compare the crytography used here versus AES encryption in RFM69 modules.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates