Select Processor Option for Solar Powered Sensor

[keenanjohnson]

Building a Solar Powered Frog Sensor would be great for the sustainability of the project. However, the power consumption of a large always-on device like a Raspberry Pi is too much to have a reasonably sized solar panel + battery.

There are at least two ways to solve this:

• Build a custom power management system to turn of power to the compute module (Raspberry Pi) periodically to reduce power consumption.
  • Challenge: Custom hardware engineering to support this
• Use a different process option like a microcontroller that has a proper sleep mode.
  • Challenge: Creating a fleet management / Over-Air-Update System for a microcontroller fleet. Our current solution (Balena) does not support this

[keenanjohnson]

@eren-rudy and @djgood FYI.

[djgood]

I've been thinking of additional possible solution which is a hybrid approach to the two possible ways you've already suggested above: Keep a Linux-capable chip so that we can keep using Balena since it's giving us the huge benefit of simplifying provisioning and deployment (for free! 🤯), but have it turn off / sleep and delegate most of the data acquisition to a lower power microcontroller.

Best of both worlds but highest level of complexity.

[keenanjohnson]

Indeed but perhaps it’s the best solution! There is a Balena playground example where the balena image can flash firmware to an ESP32 microcontroller for example, which might be a good approach to realize what you mentioned below! https://github.com/balena-io-playground/esp32

…

On Wed, Nov 3, 2021 at 4:15 PM Desmond Good ***@***.***> wrote: I've been thinking of additional possible solution which is a hybrid approach to the two possible ways you've already suggested above: Keep a Linux-capable chip so that we can keep using Balena since it's giving us the huge benefit of simplifying provisioning and deployment (for free! 🤯), but have it turn off / sleep and delegate most of the data acquisition to a lower power microcontroller. Best of both worlds but highest level of complexity. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQ3FRKCYC2PBZCIPE6RY3UKHGD7ANCNFSM5HKCN5QQ> .

[daveb377]

Seems like a significant amount of hardware overhead and cost driven by a desire to use Balena to update a linux platform I suspect there are lower power solutions out there.

[keenanjohnson]

Definitely so! I would reframe that statement as saying it is a priority of the project to have a good Over-The-Air Update system. Balena is just the only option we've identified that will work easily without us writing a TON of software.

Definitely open to trialing other options as we find them! For example, I've been trialing https://golioth.io/ as a service for OTA with ESp32 devices, but that feature isn't done in development yet.

[keenanjohnson]

The other comment to note that is we're an open-source project, so minimizing recurring software costs is a big priority! That's the biggest advantage to Balena is that we can use their service for free as an open-source project, which is a big cost savings.

[keenanjohnson]

I was introduced to https://toit.io/ as a fleet management software tool for ESP32. It seems really new, but at least seems done. I Will attempt to get trial access for that tool to assess if it is suitable. I'm a bit wary because this requires a proprietary language.

[keenanjohnson]

Here's my slack chat with the Toit developer team.

The summary is that there isn't a way for end device users to reconfigure their wifi connections via ToiT at the moment and we would need to wait on the Toit team to add support for this before it's possible.

[keenanjohnson]

See toitware/public#31 for the feature request on the Toit side.

[Derek-Gutheil]

Hey @keenanjohnson can you explain the need for OTA updates to the sensor?

[keenanjohnson]

Hey @Derek-Gutheil! It's a good question!

The main reason is that I consider our backend database (currently based on influxdb), to be a prototype at best. Given that, it's extremely likely we'll need to update the software on devices in the future as we learn and grow the project and establish the best practices for collecting this data.

In theory, we don't "need" OTA, however, I believe it is possible to ship a system with it, so I think it's a goal worth shooting for unless we prove that it can't be done.

Another point of information, I have heard that Golioth.io now supports OTA for ESP32, if someone wanted to try that out, it could unlock that as a processor option!

[Derek-Gutheil]

I don't have experience with fleet management for IOT devices, so forgive my ignorance. I'm looking at this from more of an embedded device perspective.

Doing a bit of digging, it looks like the ESP32 supports OTA updates natively

Looking up a tutorial here they show how the ESP32 can be triggered via serial to look for updated firmware from an AWS S3 bucket. Could the devices simply be triggered from a timer (once a week, once a month, etc.) or a response variable from the server when they upload data to check the S3 bucket for new firmware? The rollout of new firmware images wouldn't be instantaneous, but it seems like a vast majority of devices could feasibly be updated within a week or so without using an external service like balena, golioth, toit, etc.

Again, apologies if I don't understand the complexities of fleet management.

[keenanjohnson]

That is definitely possible @Derek-Gutheil ! The challenge comes from dealing with security and edge cases which is where the additional services you have mentioned create value. For example, what is the power to the device is disrupted during the update download? For security,

These are solvable engineering challenges to be sure, but in my experience, it takes significant software engineering effort to solve them (person-months generally). As an open-source project, ensuring that we take on the least technical risk with our technology decisions is important to keep shipping products given that we don't have a full-time staff. So I just want to be sure that we do an adequate make vs buy trade study here.

[Derek-Gutheil]

Got it, that makes sense! I'd love to help with that make vs buy study, let me know how I can.

[charlesrg]

Just saw this project today, this is definitely a job for a solar powered ESP32 not a Raspberry PI.

[fosteman]

This gets me thinking:
Rspberry PI Zero with a solar panel https://www.arrow.com/en/research-and-events/articles/can-you-run-a-raspberry-pi-on-solar-power

Also wondering about the solar panels being winter-proof. I'm in MTL, and would love it to work 365 days with least amount of snow-cleaning.

[keenanjohnson]

That's a great goal @fosteman ! Cold resilience is something we should definitely prioritize!

The raspberry pi zero is a good option for low power, but here are a few challenges (that are probably solvable), which have caused us to stay away from it:

• Even though the raspberry pi zero is the lowest power of all the raspberry pi options, it still doesn't have a proper "sleep" mode, meaning the power draw is still in the 10s or 100s of milliamps all the time. This is really challenging to use with any reasonably sized battery to have a persistently "on" device.
• The wifi antennae on the pi zero is quite bad compared to the big external one on the CM4 for example, which isn't great for a sensor that goes outside.

Like I said all of these are certainly solvable, but so far our take has been that using an easier hardware like an ESP32 microcontroller for example is the better hardware choice in exchange for more software complexity ex: Ribbit-Network/ribbit-network-frog-software#6.

Definitely curious for your thoughts though.

[keenanjohnson]

We're moving to an esp32-based frog for the foreseeable future, so closing this as selected since the esp32s3 should be adequate for future solar developments.

New software repo below:

https://github.com/Ribbit-Network/ribbit-network-frog-software