close-circle
Close
0%
0%

STM32L4 Sensor Tile

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

Similar projects worth following
close
This is a 20 mm x 20 mm four-layer pcb tile full of interesting sensors (ICS43434 I2S Digital Microphone, MPU6500 acclerometer/gyro, BME280 pressure/temperature/humidity, and CCS811 air quality) with a Rigado BMD-350 UART BLE bridge for sending data to a smart phone all managed by a STM32L432 host MCU.

The STM32L432 is programmed using the Arduino IDE via the USB connector and serial data can be displayed on the serial monitor to verify performance and proper function, etc. But it is intended to be powered by a small 150 mAH LiPo battery for wireless sensing applications. The STM32L4 is a very low power MCU and with proper sensor and radio management it is possible to get the average power usage down to the ~100uA level, meaning a 150 mAH LiPo battery can run the device for two months on a charge.

There is a 1 MByte SPI flash memory on board which allows either data storage for very low duty cycle BLE radio transmission and/or to store a firmware upgrade for OTA reprogramming of the STM32L4.

There is a MAX1555 LiPo battery charger on board, a power switch that controls the enable on the NCV8170 LDO, and 3V3, GND, SDA, and SCL are exposed as through holes on the board for ease of testing and in case another I2C sensor needs to be added.

The pcbs are available at OSH Park in the shared space.

Arduino-programmable STM32L432 development boards can be purchased here.

Update February 12, 2017

I assembled the first three pcbs I received from OSH Park. and on at least one of them I got almost everything working. Assembly was difficult since the board is crowded on both sides with not a lot of edge to grab onto. I guess this is the price of a small, compact board with lots of sensors!

I verified that the STM32L4 can be programmed via the USB using the Arduino IDE, of course, and that I can blink the on-board led on pin 13, read the internal temperature sensor and VDD voltage, as well as get time and date from the embedded RTC.

I also verified that the BME280 pressure/humidity/temperature sensor, ICS43434 microphone, 1 MByte SPI flash, and MPU6500 accel/gyro work as expected.

I had a bit of trouble with the CCS811 air quality sensor, partly because it is new to me and mostly because the land pattern is pretty tight for a LGA package. I might have to redo the footprint to make it more likely to make a good connection to the board. Of the three boards I (partially) assembled, one has a short between 3V3 and GND due to the poor soldering of the CCS811, one functions well enough but the I2C address of the CCS811 is 0x5B when it should be 0x5A since I set the ADO pin to GND in the design. So there is obviously some kind of connection problem on that one too. The third one seems fine, the I2C address of the CCS811 is 0x5A as it should be. I can't get proper data out of either of these last two and the heater current shows zero Amps and the heater voltage shows 0.83 V so the heater circuit doesn't seem to be working properly. I have asked AMS for access to the application notes so I can figure out how to properly configure this sensor.

The battery charger works as does the battery voltage monitor connected to an ADC of the STM32L432. The 12-bit ADC makes it possible to detect changes in battery voltage of 0.01 V, so one can watch the battery voltage slowly rise in just a few minutes as it charges. The temperature measured by the BME280 and internal STM32L432 temperature both rise several degree when the battery is being charged. I guess this draws a lot of current through the MAX1555 (~100 mA IIRC).

The Rigado BLE module is missing since Digikey won't have them in stock for another week or two. I have two samples from Rigado I assembled into breakouts for testing; I suppose I could harvest one of these to add to the Sensor Tile but I think I will just wait to get a real supply of them.

So what is the rationale for these sensors, are they chosen at random? Not really. The device will find first applications in sensing emplaced capital machinery. The idea is that there are a lot of expensive industrial machines operating in production lines that do not have adequate monitoring of their function and performance. Or such data needs to be manually accessed and printed out of a controller designed twenty years ago, etc. So this sensor tile is designed to be mounted to these machines, and return data wirelessly, automatically, and remotely. So it has to last a long time on a LiPo battery, has to send data that can be funneled up to the cloud or to a server, and has to measure things worth knowing.

One thing worth knowing is whether the machine is operating or not. This is easy to tell just be monitoring the vibrations detected by the accelerometer, which tend to have normal modes at the 60, 120, and 240 Hz supply voltages of AC motors that run them. In...

Read more »

  • Lower power with CCS811 at 50% duty cycle

    Kris Winer11/15/2017 at 05:10 0 comments

    11/14/2017

    I ran the latest experiment using the same Sensor Tile as I used in the previous log, so it doesn't have the low-power battery charger yet. I modified the sketch to put the CCS811 in idle mode for twenty minutes, and then run in Mode 3 (continuous measurement at once per sixty seconds interval) for twenty minutes; so a 50% duty cycle. I expected this to save half of the 550 uA that I previously measured for Mode 3 or ~275 uA, but it also should saved half of the 200 uA that the CCS811 would ordinarily use keeping the heater on and membrane warm between measurements. So overall, I expected to cut the average power usage by ~375 uA. In fact, using a fully charged 105 mAH LiPo battery the experiment ran for 177 hours (seven plus days) for an average power usage of 593 uA, about what I expected.

    The downside of using this strategy is that the heater has to restart every twenty minutes and the air quality data doesn't become reliable until  near the end of the twenty minute active period. I wasn't sure what kind of response to expect but the data looks like the sensor is still able to measure meaningful data even at this erratic pace:

    More than half of the air quality (eCO2 and VOC) data points are zeroes but the data do register excursions in air quality that seem reasonable. For the first three of the seven days I was having some windows replaced and the repairmen were in and out of the house (I kept the Sensor Tile indoors in the main hallway). This shows as larger and more frequent variations in eCO2 and VOC. There is a particularly large excursion after noon on the second day. I am not sure what caused this.

    So the verdict is still out whether this is a sensible way to measure environmental data. It certainly saves a lot of power, but I need a better test of  the impact on air quality data fidelity. Perhaps a second test with the Sensor Tile placed in a sheltered spot out of doors.

  • SensorTile3: Continuing Evolution

    Kris Winer11/06/2017 at 02:28 0 comments

    11/05/2017

    It's been two months since the last log entry and the Sensor Tile has gone through another redesign iteration since then. I changed the size of all of the passive footprints and made them smaller to ease assembly and I replaced the SDA/SCL exposed at the board edge with the BMD-350 SWD port to enable replacing the Rigado firmware with my own in an attempt to lower power usage of the BLE module. Turns out this is really not necessary, at least not yet. I'll get back to this point in a second.

    I started with several tests of the new Sensor Tile being powered via a BQ25504 and a solar cell. I redesigned the BQ25504 to tighten up the specs and ended up wasting a lot of time because the battery would get to about 50% of the full charge and the entire Sensor Tile would stop working because the BQ25504 undervoltage threshold was too high. So I gave up trying to perfect the BQ25504 and went back to the previous design which worked just fine, but I still had some problems getting the full use of the LiPo battery. Since the number of hours of sun dropped to less than three in my testing area I went back to simple power usage tests using just a LiPo battery. In the first attempt at this rain stopped the experiment after twelve days and in the last attempt I finally got a complete experiment and was able to measure the average power; it only took two months of fooling around to get there.

    The results are five hours shy of fifteen full days of running on a 350 mAH LiPo battery. This represents an average current of 987 uA, which is significantly less than in previous tests for a couple of reasons. Firstly, I turned off the microphone; I still haven't figured out how best to use this in an environmental data logger. I also took advantage of improvements to the STM32L4 Arduino core which takes care to properly put unused GPIOs in a hi-Z state to minimize power usage. I also started disabling the SPI just after writing to the SPI flash and enabling SPI just before. Likewise, I put the SPI flash into its deep power down state unless writing data. Lastly, I started using forced mode for the BME280 to get a data reading just once every ten seconds. In other words, I fussed over every uA and looked for ways to cut power while still recording all the data (except audio) every ten seconds.

    Here is some of that data:

    Turns out 15 days worth of data, 42 bytes every ten seconds, is a lot of data, 109500 lines of spreadsheet in fact and it takes quite some time to process this even on Windows 10 and an Intel i5 core. Fifteen days represents only about half the data the 8 MByte SPI flash can record, so as I continue to drop the average power the flash capacity will become better matched to the 350 mAH LiPo battery lifetime (yes, both arbitrary with different data write frequencies and battery size).

    It is interesting to see the diurnal variations of the data as well as the longer term variations of trend. It got significantly cooler after Halloween as a weather front moved into the area; the data nicely capture the end of our Indian summer.

    This < 1 mA average power usage included broadcasting pressure, temperature, humidity, eCO2 and VOC as well as battery voltage and % charge remaining every ten seconds via BLE.  I thought the BLE module was the big power hog on the Sensor Tile 3. But I measured the CCS811 average power to be 550 uA in a previous log so that now it seems it is the air quality sensor that is the dominant component even though I am using the "low-power" pulse setting reading CCS811 data once per minute.

    Of course, I could just disable the CCS811 to save power but I really like having the air quality data. One thing I will try is to put the CCS811 in idle mode for, say, an hour and then let it run twenty minutes; a 25% duty cycle, which should save ~330 uA but still provide useful air quality data, which like pressure doesn't change that rapidly. Maybe a 50% duty cycle would be better;...

    Read more »

  • SensorTile3

    Kris Winer09/04/2017 at 22:33 0 comments

    09/04/2017

    I finally got the pcbs back from OSHPark with the latest useful changes and a corrected error and put one together this weekend and was pleasantly surprised that everything worked the first time. Always nice.

    I moved the BME280 to the back of the board along with the CCS811 so these two "air breathers" could be shielded from sunlight hitting the VEML6040 on the board front. I also got rid of the resistor divider for monitoring LiPo battery voltage relying on the battery voltage, state-of-charge, and charge rate measured by the MAX17048 fuel gauge. I used the analog pin freed up for the orange indicator led that used to be on pin 13 (SPI flash CLK) to allow indication (in this case on for 10 ms whenever the SPI flash page is written --- once every sixty seconds). Lastly, I replaced the 1 MByte SPI NOR flash with an 8 MByte SPI NOR flash for what should be ~24 days of complete, continuous data recording at 0.1 Hz.

    I also redesigned the BQ25504 solar cell LiPo battery charger by resizing the resistor network to tighten the under- ( 3.27 --> 3.58 V) and over- (4.27 --> 4.15 V) voltage thresholds as well as changed the layout to conform to the reference design in the datasheet. I also got rid of the battery OK led on the board. This is useful for indication of proper charging but is really not appropriate for a ultra-low-power system.

    Last improvement was to take advantage of inexpensive plastic boxes for packaging the whole system in a more convenient and more permanent mounting. The plastic boxes from Bud Industries are perfectly sized for the solar cells I am using and I even made a small hole to expose the VEML6040 to more direct sun to get a more accurate correlation between charging and incident light. For mounting the Bud box on the pole, the solar cell on the outside of the Bud box, and the SensorTile3 on the inside of the Bud box I used pieces of VHB foam tape; a very handy addition to any maker's tool kit!


    Overall, the system is a lot closer to a deployable environmental sensor than it has ever been. I want to make sure the new BQ25504 design performs properly and that I can make use of the data on the SPI flash. No reason to think these won't work but it is always prudent to test a new (or newly revised) design just to make sure. So after the test results are analyzed it will be time to put one or more of these devices out into the wild (we live in the middle of an oak forest) and see what can be seen... and smelled... and heard.

    Even this last shake-out test is happening at an opportune time since there is a wildfire somewhere nearby producing waves of smoky, stinky air that ebb and flow as the wind shifts; a good test for the CCS811.

  • Using a Solar Cell Charger...Part 3

    Kris Winer08/14/2017 at 16:43 0 comments

    8/14/2017

    Got a break in the fog so I resumed my solar cell charging experiment with the same LiPo in the same state as when I stopped the last experiment. That is I didn't bother to charge it in the usual way seeing as how the solar cell is working pretty well.

    I did orient the SensorTile2 more in line with the solar cell to catch the full sun and get a better measure of the incident lux. I got three days of data before the fog came back. These are the results:

    You can see that the sunlight pegs the VEML6040 at 16500 lux so the actual light incident on the solar cell for most of six hours a day is greater than this. We can estimate how much greater in a second.

    Zooming in:

    you can see that when the SensorTile2 is directly exposed to full sunlight, the humidity drops like a rock (the temperature soars too). This because these MEMS pressure/humidity/temperature sensors are notoriously sensitive to incident light, which is why most people cover them with porous foam when accurate ambient measurements are the goal. In this case, I sacrificed humidity and temperature accuracy during the day anyway to get a better measure of the incident sunlight. Can't have everything on a 0.67 sq. in. pcb!

    After the direct light is removed the humidity (and temperature) return to accuracy and I had to end the experiment on the third evening as the fog rolled in and the humidity climbed toward 100%.

    The most interesting thing about this slightly extended experiment is that the charge state drops to 70+/- 1 and rises to 90 +/- 1 for three days. I don't see much if any dimunition in peak charge and it looks like the SensorTile2 would just keep going indefinitely under these conditions. The next revision will have an 8 MByte SPI flash so I will be able to measure for three weeks instead of three days to confirm this.

    If the SensorTile2 is at steady state, then the ~1.8 mA x 24 hours ~43 mAH of required power must be provided by ~43mAH/6 hours ~ 7.2 mA of average current from the solar cell. At 17 mA per 50,000 lux (per the data sheet) this must mean the sunlight peak is closer to (7.2/17) x 50,000 ~ 21k lux, which is quite plausible.

    It is gratifying to be at or near steady state with this little 50 x 33 mm solar cell. This means my goal of a perpetual environmental sensor in a compact package is close at hand. I just need to find a way to protect it from the fog!

  • Using a solar cell charger ...Part 2

    Kris Winer08/11/2017 at 17:46 0 comments

    8/11/17

    First attempts to use the solar cell charger outside were not entirely successful. This time of year we have high humidity and fog in the evening and this is interferring with one or more of the sensors on the SensorTile2. In the first attempt, I placed the SensorTile2 on a pole with the solar cell facing the sun:


    You can see the green "Battery OK" led of the BQ25504 charger and the SensorTile2 hanging below it. You can also see it is overcast and not too sunny. The fog rolls in after sunset and the humidity rises...it rises so much that the humidity sensor reached saturation (got wet in fact) and the SensorTile2 simply stopped working.

    The second attempt was a little more successful. I placed the SensorTile2 on a black side "table" of our barbeque with the solar cell angled to face South and more or less get the full sun from ~11 AM to ~4:45 PM. I put a glass bowl over the whole shebang after sunset to try to protect it against dew formation, which sort of worked. But the air quality sensor stopped working the first evening so I ended the experiment after two days. This is the result:


    I did some scaling so everything of interest would fit on the same plot. You can see that the humidity saturates after midnight; somehow almost everything kept working into the next day.

    The ambient light was measured (using the highest-range setting of the VEML6040 == 40 ms integration time) to be ~15 klux at the peak. This measurement isn't really representative of what the solar cell sees since the SensorTile2 is not at the same orientation and, in fact, gets oblique sunlight for most of the ~6 hours of direct sun exposure. I might try to orient them more closely on the next experiment to get a better measure of incident light on the solar cell.

    Even at 15 klux the solar cell should be producing (15/50) x 17 mA or ~5 mA, which with  ~6 hours of sunlight is  ~30 mAH per 24 hour cycle. Since the device is using ~1.8 mA x 24 hours = 43 mAH per day, and the 15 klux is likely an underestimate of what the solar cell sees, this arrangement is getting close to self-sustaining. In fact you can see that the charge level measured by the MAX17048 and the battery voltage measured by the voltage divider and STM32L432 ADC both return to their maxima after the second day.

    I need to repeat this experiment when the weather becomes a bit drier (which will happen soon enough). I also redesigned the SensorTile2 to replace the 1 MByte SPI flash with an 8 MByte SPI flash so I will be able to record data for ~24 days at the current (0.1 Hz) rate. Looks like, if I can keep the SensorTile2 dry, I should be able to capture a lot more data with the help of the solar cell...

  • Using a solar cell charger...Part 1

    Kris Winer08/08/2017 at 19:53 0 comments

    08/08/17

    First experiment using the BQ25504 solar cell LiPo charger with SensorTile2. I used the same sketch as I had run before where I was getting 100 hours of run time on a 150 mAH battery or 1.5 mA average power usage. This time I used a half-charged 105 mAH LiPo battery I just happened to have lying around to connect to the BQ25504 charger, and connected the BQ25004 system power and ground to the SensorTile2. I placed the whole apparatus on an inside window ledge where the sun shines directly for about three hours a day. This is the setup:

    Cool spider webs, eh? The LiPo battery connects to the battery port of the BQ25504 breakout. The small 50 x 33 mm solar cell generates 40 mA @ 2.2V peak for 100 mW/cm^2 incident sunlight according to the specs. This location has direct (albeit somewhat oblique) sunlight for about three hours per day. Is this going to be enough to keep the Sensor Tile going?

    In a word, no. First of all, the datasheet says 17 mA at 50,000 lux typical current. I am seeing peak ~5000 lux in this location. Three hours a day of 1.7 mA power is only 5.1 mA. I am consuming 1.5 mAH for the SensorTile2 plus 280 uAH for the battery OK led on the BQ25504 (which I should disable but haven't yet). So, 24 x 1.8 mA = 43 mA total consumed in 24 hours and 5.1 mA produced. This would be an average power usage of 1.57 mA.

    Here is the actual results of the experiment:

    In direct sunlight, the ambient light sensor is pegged at 5500 lux (the VEML6040 has a maximum range of 16500 lux for integration time of 40 ms, whereas in this experiment I am using 160 ms*) so the actual intensity could be higher, but the direct sun only lasts ~3 hours or so at this window sill location. The BQ25504 definitely works, as the slight rises in charge level indicate while the sunlight is available. The half-charged 105 mAH LiPo battery lasted 43 hours which translates into ~1.2 mA average power usage. Really ~0.9 mA when we subtract off the 280 uA for the BQ25504 battery OK led. And this is a significant improvement over the 1.5 mA average power usage I was seeing without the BQ25504. Even the ~1.2 mA with OK led is better than the 1.57 mA I estimated above, so this likely means the actual light intensity is ~30% higher than the clipped peak measured. So likely closer to 7000 lux.

    Could this scheme ever perpetually run the SensorTile2? Using a larger area solar cell, sure. But if I change location and position of this little solar cell, I would need to get 18,000 lux for six hours a day to produce ~37 mA per day and if I disable the BQ25504 led I would consume ~36 mA per day. So it is possible. But even if I could just double the run time from 100 to 200 hours total or so it might be worth the effort. I am running this experiment next.

    * Yes, this is due to an error in the sketch where the sensitivity was being calculated as Gsensitivty/(integrationTime + 1) instead of Gsensitivity/(1 << integrationTime). So Gsensitivity was being divided by 3 and not the correct 4 at integration time of 160 ms.

  • More on light sensing...

    Kris Winer08/06/2017 at 01:43 0 comments

    08/5/17

    I ran another test of the SensorTile2 correcting some of the power issues and integer cast issues I had on the last test.

    First, I disabled the power-on green led, turned off the microphone, and changed the BLE output rate to once every ten seconds. Even so, the SensorTile2 ran for just 100 hours, so an average power usage of 1.5 mA. This is almost exactly what I estimated I might save (2.1 mA from the last test - ~570 uA estimated savings ~ 1.5 mA) but still this is a little disappointing; I have to remember that the air quality sensor uses ~550 uA all by itself, and outputting BLE every ten seconds instead of every second doesn't seem to drop the power used by the nRF52 (BMD-350) module very much. I used up the 4095 pages of SPI flash for logging after ony ~80 hours. Well, everytime I run one of these tests I learn how to use the device better.

    At least I am reliably getting a lot of data over a long enough time to be interesting. All of the initial trouble I was having with lost flash data, incorrect dates and times, etc is gone. Here just a reminder of what kind of data I am getting:

    and I am not even including the accelerometer data, which is available in the log, or any audio data which is not. I am still thinking how to use these vibration/sound sensors for environmental logging.

    What's interesting about the eCO2 data above (SensorTile2 placed just outside my front door again in a covered location) is the changed characteristic of the signal starting at ~6 AM on August 1. The eCO2 level transitions from a subdued 500 +/- 100 ppm level for most of two days to spiking well above 1000 ppm and remaining generally higher thereafter. The transition coincides with a falling pressure (most easily seen with the pressure-derivative altitude rising from 900 to 1000 feet) and a general cooling trend. So the change in the weather seems to be able to affect the pollutant (CO2 and TVOC) levels. Looks like there is a lot that can be learned by correlating disparate data; I need to either add a larger SPI flash for longer data logging or figure out how to get a continuous stream of data for long-term logging. More on this in a minute.

    I also fixed the integer cast error I had in analyzing the ambient light sensor (VEML6040) data and now I am getting much more sensible output with no negative light levels! Here is what the data look like:

    I am plotting total light received in lux as well as the red, green, and blue components in uW/cm^2. Remember the SensorTile2 was placed in a covered location so these values are quite low compared to the ones I showed in the previous log when the VEML6040 was exposed to the open air and direct sunlight for part of the day. Interestingly, the peak lux drops noticeably on August 1 corresponding to the increase in eCO2 levels, all due presumably, to the change from clear skies to cloud cover.

    Zooming in we can see the relative components of the ambient light:

    Somewhat to my surprise red and green seem to dominate the shadows; I guess this makes sense since all of the light the Sensor Tile2 sees in this covered location is scattered light and red is scattered most (that's why the sky is blue). The small excursion at ~10 PM each day is when the front porch lights are turned on.

    Since I have a nifty battery monitor on the SensorTile2 and I want to see if I can have a perpetual environmental sensor the next experiment will use a BQ25504 boost converter and a solar cell to run the SensorTile2. I am particularly interested to capture the charging/discharging behavior in a location with only a few hours of sun each day. So I will essentially repeat this experiment using one of these and report results in a week or two.

  • SensorTile2

    Kris Winer07/30/2017 at 19:12 0 comments

    07/30/17

    Technically, this is SensorTile3 since I changed the original Sensor Tile by replacing the switch and substituting the BMA280 for the MPU6500. But since it was this modified Sensor Tile that was used for initial testing, gathering the first real data and sending that data over the BLE UART bridge as well as starting low power consumption testing, etc I will call the latest incarnation SensorTile2.

    SensorTile2 is just like SensorTile1 except I have added two new components. The first is the VEML6040 RGBW ambient light sensor (white arrow) and the second is Maxim's MAX17048 LiPo battery fuel gauge (red arrow). Here is a picture of the SensorTile2:

    It's starting to get a little crowded on the pcb!

    Both of these components use I2C to communicate to the STM32L432 host. The VEML6040 has no interrupt but the MAX17048 does. Unfortunately, I have no GPIOs left. The VEML6040 measures ambient light resolved as red, green, blue and white (total) counts which, with proper scaling, can return  R, G, and B light intensity in uW/cm^2 and total lux. The VEML6040 takes ~200 uA of power so I have made use of the embedded enable/disable capability to limit overall power usage.

    I tried to extend the battery life in this first SensorTile2 experiment by updating the data sent via BLE every ten seconds instead of every second. I only got 70 hours, or an average power usage of 2.1 mA which is higher than the 1.75 mA I measured in a similar experiment using SensorTile1 with BLE update at 1 Hz. The reasons for this include that facts that I had the VEML6040 reading data at 1 Hz (~200 uA), I forgot to disable the green power-on led (just above the USB connector) which unnecessarily burns ~140 uA, I have the microphone powered on even though I am not really using it (~230 uA), and I am performing FFT analysis on the sound data when available at 1 Hz. I'll repeat the experiment after disabling the power-on led, reading the VEML6040 at 0.1 Hz, and turning off the microphone which should save at least ~570 uA and so I am hoping to finally get the average power at or below 1 mA.

    In the meantime, I did get some interesting data with these new components. First the ambient light data:

    I am plotting red, green, and blue light intensity as well as temperature in Fahrenheit over the seventy hours of the experiment. Note the date and time (24 hour PDT) are finally correctly recorded. The SensorTile2 was located on a metal bench on the back porch, mostly shielded from direct sun except for a short period twice a day, as can be seen by the spikes in both the light data and the temperature. I think there is a conversion error in the program since I am reading the data as int16_t, which can and does go negative occasionally, but I think this should be uint16_t. One more thing to fix. The initial spike in light coincides with sunrise and the second spike with overhead sun. There is a lot of detail in the shape of the light curves having to do with the particular siting of the sensor wrt the trees and house, etc. Not apparent on this scale but there are subtle changes in relative color components of the light that occur; there is more red at sunrise and sunset, for example, while green and blue dominate during mid-day.

    The battery fuel guage measures battery voltage, state of charge (in percent) and charge/discharge rate. When I first tried it while using the SensorTile2 to charge the 150 mAH LiPo battery, I was surprised that the charge rate was still positive and the state of charge was less than 100% after the red charging light went out. After another hour or so the charge rate dropped to ~1% and the state of charge reached 100% (actually 101% !). The way the fuel cell works is that it has a model of the battery whose parameters are automatically adjusted over a few battery charge/discharge cycles. So I guess I shouldn't expect the model will be correct at first and, indeed, the recorded data show some odd results:

    First the state of charge starts at 101%...

    Read more »

  • Upgrading BMD-350 Firmware, Hot Swapping AT Mode

    Kris Winer07/19/2017 at 03:03 0 comments

    07/18/2017

    The BMD-350 comes loaded with firmware that creates a BLE UART bridge such that simply writing Serial2.print (the BMD-350 is on the STM32L432 host's Serial 2 port) in the host's Arduino sketch sends anything one would normally write to an IDE serial monitor to the UART console in the Rigado Toolbox app on the smart device (iPhone in my case). This is convenient for checking on current conditions or proper sensor operation during a logging session, for example. And the BMD-350 UART configuration (baud rate, TX power, etc) can be changed on the fly using the Rigado Toolbox app.

    The way the BMD-350 is configured in the host sketch is by entering AT Command mode, passing some configuration statements via Serial2.write, and then entering UART bridge mode for normal functioning. In order to enter AT Command mode one has to 1) hold the AT Mode pin on the BMD-350 module LOW, 2) then hold and release BMD-350 Reset LOW to reset the module. Of course, these pins are connected to STM32L432 GPIOs for this purpose. When the module powers on it senses the AT Mode pin and if it is LOW, the module enters AT Command mode. After the commands have been entered, the reverse process puts the BMD-350 back into UART bridge mode for normal operation. All of this takes a bit of time (~seconds), but for a one-time initial configuration (i.e., in setup) this is fine.

    Rigado has impemented a hot swap AT mode such that if the hot swap is enabled during the BMD-350 initialization, then simply holding the AT Mode pin LOW during the running of the sketch will put the BMD-350 in AT mode and the configuration can be changed "on the fly" in the same way the configuration can be changed from the Rigado Toolbox app on the smart phone. Resetting the AT Mode pin HIGH returns the BMD-350 to BLE UART bridge mode. This is very convenient. More on this in a moment...

    I upgraded the firmware on the BMD-350 nRF52 BLE module on the Sensor Tile since I wanted to be able to use the hot swap capability just added to the new protocol 3 firmware; the BMD-350 came with protocol 2 from the factory. After some initial fussing and after I finally decided to actually follow the directions on the Rigado website I succeeded in getting the firmware update to work. The update process was accomplished via OTA from the iPhone and required e-mailing myself three separate .bin files, a bootloader, the S132 soft device and the new BMDware (firmware). For each file I used the Rigado toolbox firmware upgrade tool to load the corresponding .bin file and after a few false starts got everything properly loaded. In order to make my Sensor Tile work again with the new firmware I had to "restart" bluetooth on my iPhone, meaning I had to disable and re-enable it in Settings for the changes to "take". Don't ask me why, it all finally worked so---no harm no foul!

    Now the initial idea for my interest in hot swapping was so I could set the Tx power to the lowest setting, as I have been doing, but just before a Serial2.write I would bump up the Tx power to 11 or at least a higher-than-minimum value to temporarily increase the range. Then after the message was sent, bump it back down to the minimum to save power. Nice idea, but it takes time to effect the mode changes even without having to reset the module twice. For data update rates of ~1 Hz like I am using on the Sensor Tile this is simply not practical. The reason is that it takes ~100 ms or so each direction. So my idea of using hot swapping as a power saving strategy isn't going to work.

    But there is another potential application of hot swapping that might.

    Turns out BLE, despite the hype about BLE 5.0, is often best as a near-field protocol. Meaning for a lot of applications, people choose BLE because it requires a lot less power than wifi. The lowest power is achieved with the lowest Tx power settings, meaning using the BLE as a near-field communication protocol for when someone brings a smartphone close, say within a few feet, is where...

    Read more »

  • Sensor Tile Ears to Add to the Nose

    Kris Winer07/16/2017 at 22:52 0 comments

    07/16/2017

    I finally got around to playing with the ICS43434 I2S digital microphone on the Sensor Tile. I used the I2S library that is part of the STM32L4 Arduino core and Sandeep Mistry's Arduino Sound library for the FFT analysis. Both are very easy to use. But for some reason the I2S mic did not play well with the SPIFlash.h class I created. Both work well without the other and the SPIFlash class works well all of the time but there is some conflict I haven't yet discovered so in order to make some progress, I just regressed to having the SPIFlash functions in the main code. Now all is well.

    I am reading the microphone data at 8000 samples per second, rather low for CD-quality music but perfectly fine for voices and machine chatter, etc. I capture 128 sound samples, perform an FFT and then normalize the spectrum and output only those frequencies that are 50% or higher of the maximum intensity of 64 frequencies in the spectrum. So if there is nothing but low ambient sound, nothing is output onto the serial monitor. If I speak, then a handful of frequencies appear. I am only plotting the few major modes once a second just to get a feel for what the data might look like.

    Here is an example of the output on the serial monitor:

    This from me holding some more or less constant tone voice sound. Apparently the sound has a dominant frequency of ~250 Hz. It is interesting to see the normal modes, and it would be easy to use this capability to detect clapping, for example, or detect when someone was speaking. But I can see already that I will want to capture complete time series of the data for speech recognition. How cool would it be if the Sensor Tile could recognize and respond to the key words "Open the pod bay door HAL" or "Soylent Green is people"!

    I managed to send these dominant normal modes to the iPhone via BLE so when I speak I can see the response on the UART console. I had been converting the floats to strings using dtosrtf and assembling into a packet for transmission via serial and the BLE UART bridge using sprintf but I finally realized all I need to do is a Serial2.print to send the data to the iPhone serial console! Not sure why I started with the string packaging. Not necessary in Arduino.

    If I hum a constant note (as well as I can anyway) I see one or two dominant frequencies at 250 Hz or 300 Hz or whatever note I can hold (see above). I checked with a metronome tone generator set for 440 Hz and I see 437 Hz with a small side band at 500 hz. I think the way I have the FFT set up the frequency resolution is only 62.5 Hz (8000 Hz sample rate divided by 128 FFT size) so I am not discriminating very finely yet. For normal voice recognition I should probably set the sample rate to 2000 or 4000 Hz or so. Or I can increase the FFT size to 256 or 512 to get better frequency resolution, but at the cost in compute power. The STM32L432 has a Cortex M4F processor and the floating point engine is not really taxed at these kinds of rates. Not sure where the limit is though.

    The bigger problem is the flash memory required to hold the FFT code. The full sketch is 214 kB of which ~175 kB is the FFT package alone; this is getting close to the ~245 kB flash memory limit on the STM32L432. I think there are a lot of lookup tables and what not driving this load and I would like to find some lighter implementation of the FFT analyzer, but as far as I can tell everyone uses this CMSIS FFT package.

    The point of all this is that all of the sensors including the I2S microphone now work and work together with a lot of the relevant data being sent to the smartphone via BLE.

    The smartphone is convenient as a check but I want to start using the nRF52 in central role as a point-to-point gateway so I can get the data onto the Arduino IDE serial monitor running on the laptop. I am having the nRF52 add-on I designed for the Butterfly produced in China and I expect to start using this to monitor several of these Sensor Tiles at once for real-time data analysis....

    Read more »

View all 17 project logs

Enjoy this project?

Share

Discussions

tBStar wrote 11/09/2017 at 04:26 point

Kris,

Can you share how are you flashing the BLE module? dedicated hardware or using UART?

Thanks

  Are you sure? yes | no

X666999 wrote 09/22/2017 at 09:38 point

Hi Kris. Nice project you got going there... I have a somewhat simular project here:

https://www.cron.dk/home-environment-part-1/

https://www.cron.dk/home-environment-part-2/

https://www.cron.dk/home-environment-part-3/

https://www.cron.dk/home-environment-part-4/

I have a comment on your power savings on the CCS811.... You can't get any trustworthy readings the first 20 minutes after the device has powered up. You can read that in the datasheet.

I can confirm this, thats why I have a 20 minute warmup time on my sensor before I start logging data.

  Are you sure? yes | no

Kris Winer wrote 09/22/2017 at 15:40 point

Looks great! I keep hearing about MQTT but have never tried it, looks like I ought to.

Yes, I expect no good data for the first 20 minutes or so, and in fact for new CCS811 it's more like 24 hours until the heater "burns in" and a baseline can be established. At this point, my studies are about best combination of sensors, how to get them to work well, and especially how to get them to work well at the lowest power usage. I could never do this with the ESP8266/85 since the power draw is 10x what I can get from the STM32L4+nRF52.

My goal has always been environmental sensing out of doors. I am able to do this well now for a week at a time on a 350 mA LiPo, which serves most of my needs. I am still experimenting with augmenting the LiPo battery with a small solar cell, where I have determined I can get 7 mAH of power per hour of sun. So if I use ~40 mA of power per day, I need 6 hours of sun to go forever. But practically, especially now in Fall and soon Winter, even a few hours of Sun I expect will prolong the lifetime of the battery by several days. But I am having trouble properly setting the limits on the BQ25504 I am using. It keeps shutting off when the battery power is only down to ~35% or so.

Lot's more to do on this project. Thanks for the like!

  Are you sure? yes | no

lagunacomputer wrote 09/05/2017 at 02:03 point

I just could not get any of the examples to compile with the arduino 1.8.2 IDE, i tried changing boards and everything, any suggestions?  whats the secret sauce?  thx sir

  Are you sure? yes | no

Kris Winer wrote 09/22/2017 at 15:34 point

Well, are you using an STM32L432 and do you have the STM32L4 boards loaded into your Arduino IDE?

  Are you sure? yes | no

Kris Winer wrote 08/16/2017 at 03:58 point

The pcb proper has solder mask, of course, which offers some insulating and weather protection. I hadn't considered adding any other coatings like heat shrink or silicone (obvious options), not sure it makes sense since the CCS811 (eCO2 and TVOC) and BME280 (pressure/temperature/humidity) sensors need to be exposed to the ambient air to function properly. Maybe a small plastic box with air holes on the bottom to keep the dew out; I could mount the solar cell on top, etc. Haven't got to the packaging part of the project and probably won't until I work out all of the power and processing issues.

  Are you sure? yes | no

warhawk-avg wrote 08/16/2017 at 03:18 point

Nice...do you have any conformal coating to protect the boards (minus the sensors of course)?

  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