The previous SOL design worked great for the most part. It was low power-enough to operate for indefinite time, even through a Northern Michigan winter with minimal sunlight. However, it did have some overall design issues.

• It was set into a deep-sleep mode for storage and shipping, but the current was high enough that without solar charging it would die rapidly (roughly 30 days)
• The system architecture was odd
  • Data was temporarily stored between uploads in the ESP32 flash. This raised concerns about flash wear over time.
  • The ESP32 is very slow to wake up  from deep sleep (~500,000X slower than STM32 in my initial testing), so sampling of solar power cannot be too often without using too much average power.
  • The ESP32 ADC has poor accuracy, so an external I2C ADC was used. This had a limited  bandwidth, also slowing down sampling.

As both a fix to these issues, and a design challenge with the STM32 platform (that I am recently getting experience with), I designed a new version that uses a STM32L432KBU6 ultra-low power Cortex-M4 processor for the hardware interfacing and an ESP32 for WiFi only. The STM32 periodically wakes up, samples power from the solar panel, and stores data temporarily in an FRAM IC. FRAM has no wear limitations like flash, and can be written over indefinitely at full SPI clock speed. To reduce sleep power even further, The STM32 gates power to the ESP32, the temperature sensor, and the voltage divider used to monitor the battery. When data is ready to upload, the STM32 powers on the ESP32, loads data from the FRAM, and sends it over UART to the ESP32 for upload.

---

Reviewing Power Consumption from Previous Version

To understand the upgrades of this design,  we first need to understand the power consumption of the previous version. With the ESP32 awake and connected to WiFi, we see overall 157mA consumption. While high, this system is only in this state for a very small portion every day, when it uploads data. Much more often, it is in deep sleep mode. Here, the power consumption is much lower, down at 0.809mA. The image below shows the current profile in deep sleep. The periodic spikes are due to the accelerometer used for "wake-on-shake" for configuration sampling..

  This power consumption is the main issue, in "storage/shipping" mode, this is the power consumption, and it will drain the battery in ~1 month.

---

Firmware Design and Power Consumption for New Version

The most difficult part of this new design is managing two microcontrollers and their respective states. They are connected with a UART for bidirectional communications, and each has a state machine with timeout to handle the communication. We cannot be sure that any message will be sent or received correctly, so it needs to default back into a low power mode eventually. I generated a messaging interface where each message has two header bytes, a message type byte, two length bytes, the message buffer itself, then a checksum byte.

The key benefit for this new design is that solar power measurement is both much faster (so less time spent in high power awake mode), and the awake mode itself requires less power. Whereas the previous version would require ~1.5s at ~30mA, this new version only requires ~53ms at ~12mA. This is an overall reduction of ~71X for each sample! The image below shows the power profile of a single wakeup-sample-sleep cycle.

The deep sleep mode for this design is also far better than the previous design. The LDO for the ESP32 is disabled in sleep, and the temperature sensor and voltage divider are both power gated so that they require no power in deep sleep. The STM32 is in Stop 2 mode with RTC on, the ADXL362 acclerometer is in wakeup mode (requiring 270nA), and the FRAM is in sleep mode. Overall, the consumption is down to roughly 6-7uA, roughly 130X better than the previous version. The image below shows this current profile. The spikes are the accelerometer sampling.

The low deep sleep power and fast sampling enables some new functionality for this design. The previous version sampled every 60 seconds, and uploaded every 300 datapoints, achieving average current of 0.88mA. This new design can wake up far more often, average the data over time to achieve higher accuracy, then upload periodically. As currently set up, it wakes every 5s, averages over 50 cycles, then uploads sets of 50 averaged datapoints. This uploads slightly more often than the previous version, but averages only 0.24mA, roughly 3.4X lower average power while measuring 12X more often and uploading to the server more often! The image below shows this periodic wakeup and sampling.

With this new design, the real limitation to battery life is uploading data. While uploading, it requires ~25,000X more power than deep sleep, so future work will be done to try to reduce the time it takes to upload data, which could allow for much faster sampling and better time resolution while maintaining low power.