Close
0%
0%

Canique Climat

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

Similar projects worth following
Starting from
$52.95
canique has 2 orders / 0reviews
Ships from Austria
Meet the Canique Climat: a unique temperature/humidity sensor.

Ultra low power consumption: 1.87 µA powered via a single 1.5V AA battery (HW revision 0.6.1).

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

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

Read more »

batt-90.ods

Daily average of battery voltage from a sensor (HW rev 0.4)

spreadsheet - 38.06 kB - 08/25/2022 at 22:00

Download

  • HW rev 0.4 / 2500 mAh battery: 3 year timeframe

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

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

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

    canique08/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.

    Battery voltage drop in HW rev 0.4

    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.

    Battery voltage drop in HW rev 0.6

    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

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

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

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

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

  • 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

    Implementation

    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 https://forum.pjrc.com/threads/27442-interrupt-automode-driven-library-for-the-RFM69.

    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 (check_crypto_mode.py). Also, as required with a block cipher, data is zero padded...

    Read more »

View all 11 project logs

Enjoy this project?

Share

Discussions

zeflo wrote 09/22/2022 at 10:37 point

Is the Radio-Protocol open? I'am interested in integrating multiple CaniqueClimat-Nodes in my setup.

  Are you sure? yes | no

canique wrote 09/22/2022 at 12:19 point

Thanks for your interest, zeflo. The radio protocol is not open (it uses ACKs, encryption/decryption, transmit retries, different msg formats etc.)

But:

There is a Raspberry Pi Hat available which basically translates the radio messages into UART commands. This hat can be used (even without a Raspberry Pi) with any device that has UART support. The encryption/decryption is done on the hat itself.

Connections to the outside: VCC, GND, TX, RX, RST

  Are you sure? yes | no

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