Embedded 🐸 - Live Notes and Thoughts 🧵

[Derek-Gutheil]

This is a live chat / notes document for designing and addressing concerns with a non-linux based 🐸 . Specifically this is looking at using the ESP32 as the primary compute device for a 🐸 .

Advantages:

• Low cost (~$3 or less at volume)
• Low power consumption (<20mA in use, a few microamps in sleep)

Concerns:

• Device provisioning and fleet management are not as straightforward as they are with linux

[Derek-Gutheil]

Database:

Pushing data from ESP32 to influxDB is incredibly easy. Influx will literally generate code for you to do this in their "Load Data" tab. I have tested this and it works

[Derek-Gutheil]

Communication with sensors:

All of our hardware sensors are currently I2C, which the ESP32 supports natively

[Derek-Gutheil]

OTA and fleet management:

This is the trickiest one. I don't think we will find an all in one solution for this, but I think something can be pieced together relatively simply.

The ESP32 is reasonably simple to have automatically update from a secure server: https://blog.classycode.com/secure-over-the-air-updates-for-esp32-ec25ae00db43. Basically it just periodically checks a secure server and checks if there is a newer version of firmware that it needs to download.

It may be possible to have that secure server be github itself, so that pushes to the main branch can compile automatically, store the newest version of firmware, and the 🐸 can check against that. That is what I intend to explore first. If that cannot be done, the 🐸 can definitely be updated from a standard cloud server, like AWS or Azure. While that would cost money, we may be able to get it sponsored for a free/open source project. @keenanjohnson

In short, exploring reliable OTA updates is the first puzzle to solve in exploring the viability of an embedded 🐸

[Derek-Gutheil]

Progress:

Using the ESP32 Arduino HTTPS_OTA_Update example, I was successfully able to flash the ESP32 from a binary file hosted on Github.

My notes on the process are here: https://github.com/Derek-Gutheil/ribbit-network-frog-sensor/blob/feature/OTA/firmware/OTA%20Source%20Files/Notes%20and%20information.txt

[keenanjohnson]

Wow this is really awesome that you can flash from a Github hosted file! I had no idea that was an option! I think that really opens up the possibilities for using an esp32!!!! You are crushing this!

[Derek-Gutheil]

Power and Solar notes:

I tested the setup over 65 hours and observed an average power consumption of about 0.6W at 5V. Now, doing some worst case math:
Our daily energy consumption is about 14.5Wh. Assuming 4H of sunlight per day, we would need a solar system that can generate 14.5Wh of energy in 4 hours, meaning we need a system that can produce 3.6W for 4 hours.

So this gives us a need for:

• 3.5W solar panel: ~$40: https://www.sparkfun.com/products/13782 or https://www.adafruit.com/product/500
• Solar charger: ~$15 https://www.adafruit.com/product/4755
• 3.3V SMPS (only needs to support ~150mA): ~$3: https://www.adafruit.com/product/4711

Notes:

• This is at 5V, which is being buck'd down to 3.3V for the system. A SMPS with decent efficiency will reduce the daily power consumption and peak power needs.
• This is assuming that the panel is able to produce peak power for 4 hours per day and no power at all during the other 20 hours.
• This is without a GPS. This is only the DPS310 and the SCD30. GPS will presumably increase power draw significantly
• This is with a 10s polling frequency and no sleep mode support. Slower polling, sleep mode, and data buffering can likely reduce these power numbers.

[Derek-Gutheil]

Ok, some updates. I updated the firmware to be more power efficient and got the power usage down to about 0.624 Wh per day (0.026W on average)

Which means that we can use a really small battery, and one with high cycle life like an LiFePo:
https://www.batteryspace.com/lifepo4-rechargeable-14505-cell-3-2v-600-mah-0-6a-rate-2-22wh-button-top-standard-aa-size-0-18----un38-3-passed-ndgr.aspx

This on its own should last about 3 days without any solar. 2 in parallel would get us 6 days of battery only runtime.

Coupled with a charge pump buck/boost controller like this: https://www.ti.com/product/TPS60120 we should be able to get really good efficiency and long run times.

Although, this chart shows that single cell LiFePo cells tend to run at 3.3V for the vast majority of their discharge, maybe we just run directly off of the cell? https://footprinthero.com/lifepo4-battery-voltage-charts#:~:text=Individual%20LiFePO4%20cells%20have%20a,fully%20discharged%20at%202.5%20volts.

https://www.powerstream.com/LLLF.htm

Might be able to just set the battery charger to 3.5V, and set the undervoltage lockout on (something) to be 3.0V and call that good

This is helpful too: https://www.esp8266.com/viewtopic.php?f=6&t=16379

New solar panel calculations:
using 4 hours per day of sunlight:
0.624Wh per day, in 4 hours = a panel that can output 0.156W for 4 hours.
Something like this for $2 is somehow overkill! https://www.seeedstudio.com/0-5W-Solar-Panel-55x70.html

[keenanjohnson]

@eren-rudy have you been following @Derek-Gutheil 's progress here?

[Derek-Gutheil]

Whoops, looks like I was the victim of a very imprecise USB power measurement tool. Power consumption is currently about 0.36W, which is much closer to our original estimates. I am still quite convinced that we can bring power way down once we implement a proper sleep and get out of early prototypes

[Derek-Gutheil]

Measurements from a real multimeter on an ESP32 Dev kit:

3.3V power supply:

• 0.5mA in Deep Sleep
• 18mA in on (no Wifi activity)

5V power supply:

• 1.2mA in Deep Sleep
• 19mA in on (no Wifi activity)

5V USB power supply (measured from USB meter):

• 4.8mA in Deep Sleep
• 22mA in on (no Wifi activity)

[Derek-Gutheil]

Measurements from a real multimeter on an ESP32 Sparkfun Board:

3.3V power supply:

• 7.2mA in Deep Sleep
• 42mA in on (no Wifi activity)

5V power supply:

• 7mA in Deep Sleep
• 42mA in on (no Wifi activity)

5V USB power supply (measured from USB meter):

• 7mA in Deep Sleep
• 42mA in on (no Wifi activity)

[Derek-Gutheil]

Embedded Ribbit Build:

I built 3 embedded ribbits with an ESP32, SCD30, and the DPS310 (and 1 with the GPS). I made clear plastic containers for them out of takeout food containers, and drilled holes around the top under a lip to allow for good airflow with a modest amount of rain protection. The idea is to put them all outside on my window sill and compare data between all 3 of them to see how stable they are with respect to each other.

[Derek-Gutheil]

Temperature Concerns:

Once I built the Ribbits, I also placed a temperature data logger into the enclosure with Device number 2. The logger is an Elitech RC-5+, which is calibrated from the factory to +-0.5*C. The goal was to test not only how close the DPS310s were to each other, but also to a known source of truth. The ribbits can vary from each other with respect to time, as they are about 1 foot apart each and the sun hits each enclosure at a different time in the morning, but ideally, Ribbit number 2 and Elitech Data logger should be extremely close as they are in the same container.

Unfortunately, the data is not great.

As you can see, the Elitech logger is consistantly 5-6 degrees Celsius warmer than any of the DPS310s.

Full data set can be viewed and analyzed here: https://westeurope-1.azure.cloud2.influxdata.com/share/vy1JB-d8EWqqsY2I4y3D7

[Derek-Gutheil]

Interestingly, the temperature sensor of the DPS310s seem to align more closely with the weather station weather on these days, so maybe it was the Elitech that is wrong:

https://www.timeanddate.com/weather/austria/vienna/historic

[keenanjohnson]

Fascinating. Do you think these effects are due to sensor positioning (sensor is next to something warmer) or actual error in the sensor in your test?

[Derek-Gutheil]

I really don't know. There are a few potential sources of error in my design as is:

• The enclosure is clear plastic: When the sun hits the enclosure, it is going to apply a solar load to the enclosure and the components inside. So the black temperature sensor IC on a black PCB may heat up from that. Painting the enclosure white would probably help with this.
• The ventilation holes at the top may be insufficient to promote the necessary airflow to maintain equilibrium with the outside air. Lifting the enclosure on rubber feet and adding holes to the bottom may help with this.
• Sitting on a windowsill may be introducing building heat to the enclosure from the building itself. Hanging them from a railing may be better than setting them on a window sill.

To test how much the enclosure <-> environment interface may be influencing the design, I may run the datalogger with a ribbit inside my house for a while. Remove solar load from the equation and see how close they are.

[keenanjohnson]

Sounds good! Yeah I know the temperature sensor in the SCD30 suffers from a bit of board heating from the CO2 module and power supply, so there is a software temperature offset parameter in the SCD30 firmware to account for that. I'm not sure if you are setting an offset or not, but it is possible the heating you see could be a real delta from ambient? That also might not be what's going on here haha.

[keenanjohnson]

From an email exchange I had with Sensirion a while back: "The average temperature offset due to self heating of the SCD30 PCB is 3°C. I’d suggest to set the offset to 3°C and see what happens."