Author Topic: OTA on a sleeping Moteino?  (Read 4853 times)

syrinxtech

  • Sr. Member
  • ****
  • Posts: 347
  • Country: us
    • Syrinx Technologies
OTA on a sleeping Moteino?
« on: May 20, 2016, 04:29:04 PM »
After trying a few times and not succeeding, I thought I would ask the combined knowledge base what I hope is a simple question/answer:

Can you program a Moteino OTA when either of the RFM69 or the MCU itself is sleeping, or both?


Thanks in advance

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: OTA on a sleeping Moteino?
« Reply #1 on: May 20, 2016, 05:37:07 PM »
After trying a few times and not succeeding, I thought I would ask the combined knowledge base what I hope is a simple question/answer:

Can you program a Moteino OTA when either of the RFM69 or the MCU itself is sleeping, or both?


Thanks in advance
You could wake a Mote that is in Listen Mode and then launch a wireless programming cycle.  With Listen Mode the MCU is sleeping and the radio is in an idle/rx cycling mode.  Done right with a extremely low duty cycle, you can achieve very low power but still have on demand wakeup/programming.

Tom

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Re: OTA on a sleeping Moteino?
« Reply #2 on: May 22, 2016, 12:42:21 PM »
Hi,

sorry to hijack the thread, but how many of you are using Felix's method of OTA upgrade with Listen Mode? And what tools are you using?

I've modified the MoteinoWirelessProgramming_Gateway to send a specific "OTA!" burst to wake up the node, which then exits Listen Mode and prevents CPU going to sleep for a while to listen for the actual Hex transmission.   I can use the python script to send OTA updates with no problem, but for the faster 3-line capability I've tried both Felix's v1.3 GUI tool and the WirelessHexProgrammer.exe (by Sabolic), both of which timeout too quickly.

In gateway code there's a 3 second timeout (which is plenty for Listen Mode), but I can see that both GUI apps give up already approximately after 1 second, and quite rarely the node will wake up in such a short time and send the ACK.

Here's the excerpt from Felix's app:
Code: [Select]
Opening COM4 @ 115200baud ...
SET TARGET: TO:10
Moteino: [TO:10:OK]
TARGET SET OK
FLX?
FAIL: No response from Moteino programmer, is it connected to COM4?
   

With only 1 line/packet, it takes now 1 minute @ 22 mA to upload a  30 KB update, which is forever for CR2032 powered node  :(

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: OTA on a sleeping Moteino?
« Reply #3 on: May 22, 2016, 10:42:50 PM »
Guys,
This is another thing I'd like to improve. I just could not do much in the way of R&D in the past months.
I would really like the GUI to be able to work with a sleepy node, wake it with LM (listen mode) then update it. 1 minute upload is way too long. Maybe that could be improved with a high speed transfer, and removing the ACKs - actually getting smarter with ACKs - right now there is 1 ACK per packet which slows things down. It will happen, just don't know when I will get to it.

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Re: OTA on a sleeping Moteino?
« Reply #4 on: May 23, 2016, 12:38:57 AM »
Felix,

thank you for your reply. 

The OTA stuff seems to be work of progress for many of us, and I've read people hacking their own custom solutions to suit their needs. But yes, it would be nice if the "official" OTA method could work out of the box also with sleepy nodes (or at least with minor modifications)  :)

For the time being, could it be possible to just extend the timeout on GUI side to 3-4 seconds? Just getting the OTA speed to 2-2.5x with 3 lines/packet would help a lot!
 
Guys,
This is another thing I'd like to improve. I just could not do much in the way of R&D in the past months.
I would really like the GUI to be able to work with a sleepy node, wake it with LM (listen mode) then update it. 1 minute upload is way too long. Maybe that could be improved with a high speed transfer, and removing the ACKs - actually getting smarter with ACKs - right now there is 1 ACK per packet which slows things down. It will happen, just don't know when I will get to it.

davegravy

  • Jr. Member
  • **
  • Posts: 56
  • Country: ca
Re: OTA on a sleeping Moteino?
« Reply #5 on: May 23, 2016, 10:38:45 AM »

With only 1 line/packet, it takes now 1 minute @ 22 mA to upload a  30 KB update, which is forever for CR2032 powered node  :(

Personally I'm not so concerned with the time it takes to upload as I am with repeated current spikes during OTA that seem to drive coin cell voltages into the ground.  If it takes an hour (extreme example) to update a node but the node is smart enough to sleep between transmissions to avoid brownout conditions / allow voltage recovery,  then I'm ok with that.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: OTA on a sleeping Moteino?
« Reply #6 on: May 23, 2016, 11:07:28 AM »

With only 1 line/packet, it takes now 1 minute @ 22 mA to upload a  30 KB update, which is forever for CR2032 powered node  :(

Personally I'm not so concerned with the time it takes to upload as I am with repeated current spikes during OTA that seem to drive coin cell voltages into the ground.  If it takes an hour (extreme example) to update a node but the node is smart enough to sleep between transmissions to avoid brownout conditions / allow voltage recovery,  then I'm ok with that.
For this reason, the method I use is a 'pull' model where the gateway, on the next contact with the node, tells the node that the gateway has a download for it with a key.  The node then contacts the gateway requesting one or more packets using the key and an offset into the entire image block.  The gateway sends the requested data and the node can determine whether to get more or simply sleep until its battery has recovered.  Only when the entire image is downloaded will the node restart with the new image.  It could take all night as far as I'm concerned...

This, of course, is a simplified description of the actual code, but the model is straightforward. 

Tom

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: OTA on a sleeping Moteino?
« Reply #7 on: May 23, 2016, 11:31:20 AM »
For this reason, the method I use is a 'pull' model where the gateway, on the next contact with the node, tells the node that the gateway has a download for it with a key.  The node then contacts the gateway requesting one or more packets using the key and an offset into the entire image block.  The gateway sends the requested data and the node can determine whether to get more or simply sleep until its battery has recovered.  Only when the entire image is downloaded will the node restart with the new image.  It could take all night as far as I'm concerned...

This, of course, is a simplified description of the actual code, but the model is straightforward. 

Tom
Good model Tom. One thing I'd like to be able to see as an admin is progress of the upload (% is enough). How do you determine when an upload is complete?

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: OTA on a sleeping Moteino?
« Reply #8 on: May 23, 2016, 12:29:50 PM »
For this reason, the method I use is a 'pull' model where the gateway, on the next contact with the node, tells the node that the gateway has a download for it with a key.  The node then contacts the gateway requesting one or more packets using the key and an offset into the entire image block.  The gateway sends the requested data and the node can determine whether to get more or simply sleep until its battery has recovered.  Only when the entire image is downloaded will the node restart with the new image.  It could take all night as far as I'm concerned...

This, of course, is a simplified description of the actual code, but the model is straightforward. 

Tom
Good model Tom. One thing I'd like to be able to see as an admin is progress of the upload (% is enough). How do you determine when an upload is complete?
In my case, the node checks the accumulated packets and determines when the load is complete, including any missing packets (which it can re-request any random packet) and then informs the gateway that the download is complete.   Since the node is periodically requesting packets with offset into the image, the gateway could have a pretty good idea of progress (assuming there are not a significant number of lost packets - in my experience, I've never noticed any gaps in lost packets, just retries on a few packets).   I don't keep track of this, but the information is there.

Tom

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: OTA on a sleeping Moteino?
« Reply #9 on: May 23, 2016, 01:09:44 PM »
I don't keep track of this, but the information is there.
The reason I wanted to ask is because whatever scheme I go with I will have to be able to support easily. This would be used by a few pros, but mostly less than savvy experts who will want to have a feel that the scheme works, how to tell, and more importantly how to debug when it doesn't work.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: OTA on a sleeping Moteino?
« Reply #10 on: May 23, 2016, 03:21:21 PM »
Quote
For this reason, the method I use is a 'pull' model where the gateway, on the next contact with the node, tells the node that the gateway has a download for it with a key.  The node then contacts the gateway requesting one or more packets using the key and an offset into the entire image block.  The gateway sends the requested data and the node can determine whether to get more or simply sleep until its battery has recovered.  Only when the entire image is downloaded will the node restart with the new image.  It could take all night as far as I'm concerned...

That's pretty much how mine works, too. I try to batch data responses as much as possible, so the client sends a request for up to 10 pages (128 byte each, just enough to fill the sad, sorry, little memory of the 328p). Then the server sends those back at 200kbit.

The client just re-requests packets it didn't receive with the next request. That's how I can send a 28k sketch in ~ 3 seconds. It helps that I can use the full ram because the bootloader is the only thing running at the time.

Marcus

  • NewMember
  • *
  • Posts: 18
  • Country: fi
    • Wetware Labs
Re: OTA on a sleeping Moteino?
« Reply #11 on: May 23, 2016, 04:44:07 PM »
Quote
For this reason, the method I use is a 'pull' model where the gateway, on the next contact with the node, tells the node that the gateway has a download for it with a key.  The node then contacts the gateway requesting one or more packets using the key and an offset into the entire image block.  The gateway sends the requested data and the node can determine whether to get more or simply sleep until its battery has recovered.  Only when the entire image is downloaded will the node restart with the new image.  It could take all night as far as I'm concerned...

That's pretty much how mine works, too. I try to batch data responses as much as possible, so the client sends a request for up to 10 pages (128 byte each, just enough to fill the sad, sorry, little memory of the 328p). Then the server sends those back at 200kbit.

The client just re-requests packets it didn't receive with the next request. That's how I can send a 28k sketch in ~ 3 seconds. It helps that I can use the full ram because the bootloader is the only thing running at the time.

Wow! JoeLucid and Tom, that sounds amazing! Any chance you could release (at least some parts of) your code?  ;)
 

furieux

  • NewMember
  • *
  • Posts: 7
Re: OTA on a sleeping Moteino?
« Reply #12 on: April 09, 2018, 02:44:01 PM »
Guys, has anybody implemented this? I mean how to upgrade firmware OTA on a sleeping node? Any code example please?

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: OTA on a sleeping Moteino?
« Reply #13 on: April 09, 2018, 05:27:32 PM »
Guys, has anybody implemented this? I mean how to upgrade firmware OTA on a sleeping node? Any code example please?
For publicly available code, the best bet is to have your gateway tell the 'sleeping' node that there is an OTA update available when the sleeping node momentarily wakes up and sends something to the gateway.  This message can be returned in the ACK from the Gateway.  The 'sleeping node' can then stay awake and start polling for program update packets. 

As far as I know, the OTA bootload process mentioned in this thread is not available in open source form.

Tom