Hello Element14 community!

After short break I am back and today I will show my project contribution to the competition Off-the-Grid Project14 competition. In this blog I will show outputs of my work that consumed most of my free time in recent three months.

It is very compact solar powered temperature sensor with resolution of 0.005°C and accuracy of 0.25°C. Measured temperature and few other service information are remotely transmitted using 868 MHz band to the gateway. Device has absolutely no battery. Instead of battery it relies only on the mini 35 x 14 mm (1.38 x 0.55 inch) solar cell and one supercapacitor which allows running it in field for several years without need of any maintenance. Sensor PCB is designed for fitting compact Hammond waterproof case with transparent cover. Hardware design is prepared to possibly use different (low-power) I2C sensor instead of temperature sensor.

System consists of two parts: remote sensor and gateway for receiving data from the sensor(s) in the nearby area. Before proceeding to detailed description of the project, at first, I would like to thank companies that send me some parts which I used in the project.

Sample Sponsors

• Analog Devices: ADP5091 and ADP5092 Energy Harvesters, MAX41460 RF Transmitter, MAX31889 I2C Temperature Sensor, MAX41470EVKIT RF Received Evaluation Kit
• STMicroelectronics: STM32L053 Microcontroller
• Würth Elektronik: 868 MHz Chip Antenna 748 891 009 2
• Samtec: FTSH-105-01-L-DV-K JTAG/SWD connector

I also used parts from kits which I received for free as part of some Element14 activities:

• Würth Elektronik: Ferrites Kit explained here.
• Kemet: RF capacitors explained here.

I would like to thank all these companies for sending me free parts!

Sensor Device

Sensor device is connected as shown on following block diagram. Device consists of four main chips:

• ADP5091 Harvester which is advanced chip featuring boost converter for converting voltage form the solar cell to the higher voltage and charge supercapacitor using that voltage.
• STM32L053 Ultra low power MCU which controls the most of the device.
• MAX31889 I2C Temperature sensor.
• MAX41460 Transmitter which is configured for transmitting data from the sensor to the gateway using myself designed protocol working on 868 MHz band.

Interconnection of parts is highlighted on following block diagram.

Block Diagram

As you can see on the photo above, I built two units. They are almost the same but there are minor differences.

• One unit has ADP5092 vs ADP5091 energy harvester chip. Difference is very negligible. Meaning of one pin connected to the MCU is different, but current firmware does not process this input so it does not matter.
• Unit with ADP5092 instead of ADP5091 has no JTAG connecter because my stock of JTAG connectors get exhausted.
• Unit with ADP5092 has more properly adjusted voltage divider for ADC measurements of system, battery and regulated voltages.

Schematics

While it looked simple at the beginning to me the practical schematic is quite a complicated. I split it to four pages. Final schematic contains 104 components. You can download full schematics (or KiCad project) at the end of this article. Most important part in this project is Energy harvester chip. It’s connection is shown in following screenshot of schematics which you can download in PDF at the end of this article.

PCB Layout

The full schematic I converted to PCB layout. I designed PCB as 4 layered and dimensions and hole location adjusted to match used box. Top layer is red, inner layer near top is green, bottom layer is blue, inner layer near bottom is orange.

Top and bottom layers are signal layers, green inner layer is ground plane. Note that temperature sensor has ground switched by microcontroller, so the ground plane is split in temperature sensor area. Orange inner layer is power plane and is split to three parts. Bottom part is connected to harvester system voltage, central part is connected to regulated voltage which powers all other chips and finally, there is additional ground plane under RF signal parts. Area under chip antenna is not connected to any signal according to antenna datasheet.

PCB Assembly

The PCB I ordered at JLCPCB and after I received it I assembled my sensor node:

Testing of the device took me several additional days. It is device which visually do nothing, there is no LED, there is no movement, there is no user interaction. It is just a very low-power passive device but still testing and development was quite a challenging because overall system must be power consumption optimized. In following sections I will describe several design aspects and I will describe some interesting issues which I was facing and may be helpful to readers who want to design similar system with the same or similar chips.

Solar Harvester

Solar Haverstor is core part of the project. I used it for a first time and at the beginning I was not sure that it will work. But after some tweaks it works. I was not sure that so small solar panel can charge so large capacitor but it works. It takes over 4 hours when providing light from iPhone camera light from the distance of 4.5 cm far from the solar panel to reach level when system get charged enough to power parts (from 0 to 2.2V). Debugging the chip is quite a complicated. I originally did not realized importance of configuration options of that chip. There are 6 voltage dividers which configures voltages, thresholds and hystherisis of the chip. Initially I set all values to make chip start powering parts as soon as possible. ADP5091/2 support starting from 2V so I configured thresholds to about 2.1V but this idea was too simple. The issue which I did not realized originally is inrush current. ADP5091 works in a way that first charge its system voltage to about 2.2V and then start charging backup storage (supercap). After supercap voltage reach configured thresholds, harvester start regulator and generates output for the rest of the system (MCU, Radio, Temperature Sensor). But the inrush current can cause behaviour that system will never boot. It happens when inrush current is too high and discharges the supercap so much to the level when harvester disable regulator again. It charged supercap to about 2.1V, then started regulator, then inrush current of the circuit discharges the charged supercap back to 1.9V, harvester terminated regulator and started charging supercap again until it reach 2.1V. Then the same behaviour repeat. I originally did not realize that configuration of voltage when regulator starts depends on inrush current and supercap capacity but it depends. You can solve it by increasing voltage when system starts, increasing power good hysteresis or increasing backup storage capacity. You need to adjust it not only by taking minimum voltage required by your circuit. Similarly, I originally did not realize that my circuit has some inrush currents but it has. At first powerup of MCU, it starts with default clock (MSI prescaled to 2.097 MHz) which is faster than clock later used by my firmware (MSI prescaled to 0.524 MHz). Before clock reconfiguration, MCU consume more energy than later in execution time after reconfiguration. But in fact, this is not the biggest source of inrush currents. The biggest source of inrush current are decoupling capacitors. I used Nordic PPK for power consumption measurements and inrush current peek was 120 mA for 0.3 ms. It is extremely high for circuit consuming 1.8 uA in average!

For debugging I recommend do not connecting supercap and especially, large supercap. As mentioned at beginning, everything in the system with supercap is extremely sloooooooooooooow. ADP5091 datasheet mention that minimum recommended capacity is 100uF, so for easier ADP5091 debugging I recommend start with 100 to 1000uF electrolytic capacitor before going with supercap immediately. Note that with 100uF supercap you most probably will face never-booting issue mentioned above. With 100uF (measured as 113 uF) electrolytic capacitor and no power consumption of the external parts (only harvester powered) and solar panel disconnected from the system the 100uF capacitor voltage drops from 3.5 to 0.6V in 8 minutes which is much better for debugging. Similarly charging is much faster.

Even without supercap system is slow and it cost me lot of time when troubleshooting my first circuit (note that schematic above have lot of resistor values tweaked since my first draw). ADP5091 updates lot of parameters like tracking best power point of solar panel once per 16 seconds. If power point is not adjusted properly, the performance will be low. So, for example when I attached light near solar panel and was watching system voltage I noticed it do not grow and even worse it is decreasing. I attached light and after 10 seconds voltage was still decreasing instead of expected growth. Big disappointment. But after some time I realized that I need just wait more because after 16 second period elapsed, ADP5091 revaluated best power point of solar (which changed when I attached high-intensity light) and then voltage start increasing, slowly, but increasing.

The last interesting issue which I have seen is that even things which are described in the datasheet in an analog way, they are implement digitally. It is for example termination voltage evaluation. Terminal voltage specified at which level the harvester stop charging backup storage. In case of supercap you can set it to the rated voltage of the supercap. In case of using lithium-ion battery you can set it to terminal voltage of battery (usually 4.2V). But when I was using circuit with 100uF storage I noticed that harvester for some reason allows exceeding this voltage. After some time with violated terminal voltage it stop charging and wait until it decreases below this limit and then start charging it again without any boundary for some time again. Later after some experiment I realized that the time is exactly 16 second (note that it is the same interval as updating best power point of solar panel). And now we are again in the situation when the impact of issue depends on capacity of storage element. With supercap used violating termination voltage for 16 second is not a issue because system will not overcharge supercap so much in that short time. But with 100uF capacitor charging is fast, and harvester can overcharge it significantly which can cause stressing parts (capacitor, harvester, MCU ADC channels, …) above absolute maximum ratings. I have limit originally set to 4.9V and at one moment I measured 5.7V at 100uF capacitor when charging system by high-intensity light from iPhone camera light!

But at the end device work well. 1F/5.5V supercap is suitable for running this even when using very small solar panel. Charging from 0 to 4V took approx. 7 hours on direct sun and from 4V to 2V it drops in about 1.5 days when “no sun” is provided for some reason. More realistic scenario is that voltage in day increase from ~3V to 4.6V (which I later set as termination voltage taking in account possible overcharging mentioned above) and in night decreases to about 3.8V from which it start charging again at the morning. Based on these experimental results it looks that even lower capacity supercap is suitable. I think 0.47F/5.5V should work well also. Note that system will behave differently in winter when there are less light so having some reserve is good idea.

Firmware

The most important part of the system is MCU and its firmware. Firmware directly influences power consumption of the system. As an MCU I selected ultra-low power STM32L0 MCU. Firmware is developed in a very low-power way. It regularly wakes up every 30 seconds. In every cycle it measures temperature and battery voltage, system voltage and regulated voltage. After elapsed 15 minutes, it does regular measurements but also prepares packet with data based on previous measurements, encodes the data to packet, encrypt the packet except device ID part (which is on received side used as a lookup for decryption key) turn on the radio and transmit the packet. After processing the data, the firmware turns off all peripherals and let MCU sleep until next wakeup event occurs in about 30 seconds.

RF Communication

For a RF transmission I used MAX41460. I connected it according to the schematic in evaluation kit including values for antenna matching network. I tweaked trace width according to KiCad Impedance calculator but my traces between parts are very short, so it has minimal impact, I think. Parameters are set for communication on 868 bands. More precisely currently firmware uses 868.3 MHz frequency. For a modulation I used simple ASK and OOK. It is my first RF project, so I begin with this simple mode. Disadvantage is that performance is not very good and when receiver is in home after several walls it lost most of the packets. For real use I will later improve reliability by improving protocol by supporting retransmissions and possibly switching to more advanced GFSK modulation instead of ASK. All used chips are ready to support this and currently it is just about SW implementation.

Transmitted data begins with alternating zero and one following non-manchester coded sync word and Manchester-coded data. Data has a fixed size of 20 bytes. 4-bytes are used as device ID and remaining 16-bytes are one block of AES encrypted data containing information about minimum, average and maximum temperatures measured during previous 15 min window as well as 3 snapshots of battery voltage measured at the time of sending packet, 5 minutes ago, and 10 minutes ago. Finally, there is CRC (which is also as part of the encrypted data) and few bits for some header information which are currently unused. Except this information there is boot ID which is randomly generated number at power up and packet number which is incremented after sending every packet. This two information are send in encrypted part of every packet and are used for basic protection against replay attack and ensure that packets transmitting the same data twice will be different (packet number is different).

Power consumption

Power consumption of the whole device and firmware is 0.94 uA in sleep and overall average power consumption is 1.8 uA. For measurements I used Nordic PPK II.

The biggest issue was with ADC on STM32. After using them power consumption grows to 13uA (over 13x) in all consecutive sleep cycles. I tried to deinitialize it but without any effect. I tried to disable clock for this peripheral, but still I was unable get rid of 12uA power consumption added after first use of ADC. Finally, I without success manually checked registers that there is no enabled feature, all internal sources are disabled and so on. All register was exactly the same as they were before enabling and configuring ADC for a first time, but power consumption was still 12uA higher after first use. For some reason STM32L0 ADC has some internal part inside which works independently and increase power consumption as it is hard to get rid of it. The last attempt which I did was try to reset peripheral by generating reset signal using RCC and luckily, this turned off the problematic internal part. So, the proper way how to fully disable ADC before going sleep on STM32L0 is following one:

HAL_ADC_DeInit(&hadc);

// reset peripheral before disabling clock. Reduces power consumption from 13 uA to 1 uA
__HAL_RCC_ADC1_FORCE_RESET();
__HAL_RCC_ADC1_RELEASE_RESET();

__HAL_RCC_ADC1_CLK_DISABLE();

(Internet) Gateway

For receiving data from nearby sensors I designed gateway. It is device which listens for the wireless data, decodes them and transmit them using UART to external computer which in my case is Raspberry Pi. It is visualized on the following diagram.

In real it look as follows:

Main MCU (MAX32655) configures the Radio Received EVKIT. Note the similar names of Rx and Tx chips. MAX41460 is transmitter (used in sensor module) and MAX41470 is receiver (used in gateway). Microcontroller is used in the design for its realtime capabilities of processing wireless data. It runs state machine which detects initial pulses of received packet, then matches sync word and in case of detecting sync word start processing and decoding Manchester coded data. In case of success, it prints received binary data over UART. The only wire needed is for rerouting wireless data signal to different MCU pin because for processing data I use timer in dual edge capture mode and MAX32655 support this feature on different pin than the signal was on evaluation kit shield routed to. Currently I do not send data to the cloud and instead I just logging packets to the text file. Note that in this step packets are still encrypted. My current software is split to two parts. One of them do logging and second part do decryption and export to CSV. Both parts are written in VB.NET and can run on Linux.

BOM

Following BOM table contains list of parts needed to build one sensor node and one gateway.

Sensor Node BOM

Gateway BOM

Summary

This was very exciting project for me, and I learnt a lot. While it originally looked as simple project with simple PCB connecting 4 chips at the end I have project with -layered PCB with over 100 components, designed my own RF protocol, wrote ultra-low power firmware, debugged advanced power harvester and tested the concept in overall. At the end results are very positive, I think. Harvester work even when used very small solar panel and super cap is capacity enough for running sensor without light for over one day. Slightly disappointed I am currently from RF communication which is very unreliable but can be improved by software changes. At the end I evaluated the cost also. I am not very satisfied with this because part used in the project are quite an expensive (supercap, box, 4 chips, antenna and other RF parts) but companies who sent me free samples helped me very much. I also ordered some parts which I later did not use. For example, lot of resistors values in 1 to 10 MOhm range for testing harvester configurations. In the section below you can find all resources which you can use if you decide to build the same system. I am making this project as Open Hardware which means that all resources (schematics, PCB layout and software) are available to download. Thank you very much for reading this blog and enjoy rest of the day!

Resources

• Sensor Module PCB Gerbers (ZIP)
• Sensor Module PCB KiCad Project (ZIP)
• Sensor Module PCB Schematics (PDF)
• Sensor Module Firmware Sources (ZIP) (remember to set AES encryption key in App.c or in compiled binary)
• Sensor Module Firmware Precompiled Binary (ELF) (remember to set AES key or preferable download sources and edit it in source code)
• Gateway MAX32655 Firmware Sources (ZIP)
• Gateway MAX32655 Firmware Precompiled Binary (ELF)
• Gateway UART to File Packet Logger Sources (ZIP)
• Gateway UART to File Packet Logger Precompiled binaries for Raspberry Pi (ZIP)
• Gateway Packet File Decryptor Tool Precompiled binary for Windows x64 (ZIP)
• Gateway Packet File Decryptor Tool Sources (ZIP)