Finally fixed the BLE Serial API

A project log for STM32L4 Sensor Tile

Small, connected device for smelling and hearing in any environment.

Kris WinerKris Winer 08/13/2022 at 01:470 Comments

It's been more than a year since I have spent any time on Rodan mostly because of a persistent problem we have been having with BLE Serial. After start up of the program I would get a few BLE reports and then after a minute or 30 minutes (random but short time) the device would be undiscoverable by a smartphone even though Rodan responded that it was connected and advertising in the USB serial output. Also, the current draw would increase when this weird event (whatever it was) happened. Turns out that this had to do with miscommunication between the M4F MCU and the BLE-managing M0+ MCU (the STM32WB5MMG is a dual core device, M0+ to manage the BLE stack and M4F for application programming). This was corrected by 1) using the latest ST BLE stack (14.0, the original was 10.0) where a lot of bug fixes were implemented by ST and 2) adding some work arounds deep in the bowels of the system layer to correct known and some new errata. 

Bottom line is that now Rodan works as it should as long as I use BLE stack 14.0 or later and use the latest Arduino core (soon to be posted at Github). With the device updating sensors and BLE every minute, and logging to flash every two minutes I got 58 hours of run time at 64 MHz M4F+ speed (BLE only works at 32 or 64 MHz) using a rechargeable 120 mAH LIH2450 coin cell battery, so ~2.1 mA average current. This is about what I expected considering that the CCS811 air quality sensor alone uses about 400 uA at the longest 60-second update interval and I am sending BLE Tx data updates every minute. 

I could drop the M4F MCU speed to 32 MHz (small savings) and increase sensor, logging, and BLE Tx intervals to try to reduce average power consumption but generally I am at the limit of what I can do and still make the device useful and practical (i.e., waiting 1 minute for a BLE update is already a pain...longer would be intolerable). BLE Tx is the main power user here, although turning off the CCS811 would save a lot of power too, but then air quality is pretty interesting data, no? 

I'll keep these intervals to use as a baseline. Fussing about reducing the power Rodan uses below this already-low level can wait. Instead, I want to know what it takes to keep Rodan going indefinitely via solar charging, which was one of the main design goals.

So next is to test operation of the solar cell in charging the 120 mAH coin cell battery. I would need to develop about 50 mAH per day in order to keep the device running indefinitely. I previously measured ~7 mA charging in direct sunlight using the 50 mm amorphous silicon solar cell I plan to use for Rodan, meaning I would need to have the device exposed to direct sunlight for seven hours a day (or use a bigger battery and/or solar cell!). 

This is not going to happen on my back deck or in my front garden (where I could conveniently receive BLE Tx in my home), which gets about 4 hours of direct sunlight a day but could happen if  I mounted Rodan on the one part of my 2 acres that gets the most sunlight : "the peninsula", as I call it.

I'll start with the garden and see how much more than 58 hours of 120 mAH battery lifetime I can squeeze out of the available four hours of direct sunlight. If I use ~50 mAH per day and generate ~30 mAH per day my net usage would be 20 mAH per day, so I might just manage almost a week of garden logging data this way...TBD