Canique Climat

After 4 years this sensor is still sending like a champ: every 30 seconds.

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.

This battery voltage chart shows the previously shown outdoor sensor - now until 6th February 2023:

This chart shows the same sensor as in the previous log entry - now over a timespan of 13 months (until 6th February 2023)

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.

The Canique Climat Set can be ordered now:

• Order Canique Climat
• Order Radio Hat for Raspberry Pi
• Order Canique Gateway

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 now offers full sized charts with more details, on/off switchable temperature/humidity. 24h to 30 days time windows.

Overview:

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

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

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