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

electron
Tags: #<Tag:0x00007f1ca36ccf70>

#1

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?


#2

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

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.


#3

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.


#4

@chuank, take a look at this topic:


#5

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.


#6

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… :slight_smile:


#7

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).


#8

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.