Strategies to upload new firmware remotely when an Electron has to go into deep sleep

[chuank]

Hi all,

As the topic mentions, how would you best approach this scenario?

• The Electron takes sensor readings every 10 minutes, otherwise going into deep sleep (cellular standby)
• Period in which Electron stays connected to the cloud is very short, to conserve battery power and maximise solar charging. Typical run time for the application code is 5 seconds

If the Electron is managed as a product (with just a single device), will there be sufficient time for the cloud to stage a user firmware update for the Electron? Does the Electron ‘call home’ each time it wakes from deep sleep to check for user firmware updates?

Or should I manually write a blocking routine in setup() to listen out for updates? Is this mechanism what the product firmware feature does?

[Rftop]

I'm not sure if a PRODUCT gives you this functionaliity, but WakeOn RI does:

WakeOn RI in SLEEP_NETWORK_STANDBY?

Here’s a more elaborate example. It allows: Wake by cellular Wake by another pin (RISING only) Wake by sleep time expired It requires 0.8.0 (tested with 0.8.0-rc.8) because it require multi-pin wake support and SleepResult. (The example above works with 0.7.0.) It also has a function, variable, and event subscription, and those work too on wake from cellular. To run the test: To go to sleep, pull D2 to GND To wake by pin, pull D3 to 3V3 You can wake by ping, function (“testFn”), variable…

So during SLEEP_NETWORK_STANDBY, Cloud events can wake the Electron.
OTA Firmware Flash, function calls, Particle.Variable Requests, Subscribed Events, etc, can wake the Sleeping Electron.

[chuank]

Thanks @Rftop!

The setup I have uses deep sleep, unfortunately – it's running solar off a 2500mah lipo. It's still an excellent link, never realised a wake on cellular is possible with the Electron.

I'll keep poking around to see what other options there might be to ensure a firmware update request will always get to the Electron when it wakes.

@rickkas7

You can’t wake from SLEEP_MODE_DEEP from a pin other than WKP, so you can’t wake on RI_UC

[peekay123]

@chuank, take a look at this topic:

Product OTA handler

Hi there fellow Particle geeks! I am having some trouble with auto-updates (OTA) with Particle Electrons that belong to a product group. Wondering if someone can point me in the right direction. First, the devices are currently on 0.6.0 with a 3rd party SIM. Keepalive is set at 30 currently. SYSTEM_MODE(SEMI_AUTOMATIC); Typical setup where the device comes out of sleep, collects some sensor date, publishes it, then goes back to sleep. I have the following in my setup function. System.on(f…

[Squid]

I’m new here and newbie as well, but you could, maybe let the connection open for a longer time once every day at a fixed time. I’m working on a similar project but don’t really require OTA but could be a nice add. Altought I’m not sure I’ll achieve this.

[chuank]

Thanks for the suggestion @Squid, I have considered that approach but it would mean having to be on the ready to transmit firmware at that specific time. Because the Electron is in a rural region, connections are not a guarantee and I’d like to minimise battery drain. It is something to come back to as a last resort.

Based on that, it would seem better to set up a mechanism where I flag the device for upload, and when the Electron wakes, read off that flag and switch to safe mode, ready for an update. To me that’s similar to the OTA handling technique that @peekay123 linked so I’ll read up on that and give it a go.

It’s just tricky when reception is not optimal at the site, and you’re far away thinking about the long drive just to flash user firmware…

[Vitesze]

Your case sounds very similar to mine. Putting your devices in a Product and using an OTA handler is the way to go (i.e. the topic @peekay123 linked). If the reception is very poor, I advise to give the devices several minutes though to download the OTA firmware (opposed to the 60s used here).

[chuank]

So I’ve given both options a go, and here’s what I found:

There are a few simultaneous parameters that determined my eventual choice: battery life, the need for emergency OTA updates, and how quickly I wanted the OTA updates to reach the device.

Wake On RI turned out to be the ideal option, at least until real-world tests of battery charge stats provide more insight over time (re: stop mode vs deep sleep).

Relying on just the OTA handler method would have been perfect (and easiest) if I wanted to let my Electron wait a minute or two after it’s done it’s work, right before sleeping. This also allows the use of DEEP_SLEEP. For a remote location, however, having the ability to wake the device up for an OTA was just too valuable.

The OTA method will be something to fall back to should Wake On RI (and its sleep requirement of using only STOP MODE) not work out in the long term, especially re:power usage.

Thanks again everyone for the links.