Anybody using the new Windows OTA tool?

[TomWS]

Any thoughts on where the bottleneck might be?  Is it the write-time to the flash memory? 

I expect it's the 'wordy' protocol used in the Wireless Hex transfer.  Lots of exchanges of ASCII data...

I use my own binary transfer method (HEX file converted at the source) so packets are stored directly into flash (although in a secondary region - so that I can totally lose random packets and these will get re-requested in time).  This method is not to shorten the update time, in fact, my method takes much much longer, but is used to shorten the RX/Mote awake time to save battery life.  Re my comment about taking longer, I only accept blocks for a short period of time and then will sleep for the normal sampling period.  Next time around I'll grab some more blocks. Definitely a 'pull' technology. Eventually the whole image is gathered and only then, transfered to low flash in a way compatible with the Dual Optibootloader.  Definitely NOT a fast update method, but definitely a battery efficient one.

However, once Sammy Sentient gets his wireless bootloader available to us this will all be replaced. 

Tom

[WhiteHare]

I just ran a quick and dirty test by raising the OTA bitrate to 200,000 on both the gateway and the node.  Actually, at that bitrate the gateway's serial connection  of 115,200 baud is a bottleneck relative to the 200,000 OTA bitrate, but whatever, because the serial baud is a fixed given by the v1.3 program.  Anyhow, total time was only slightly reduced to 19.63 seconds, which by itself is not a meaningful improvement. 

Do you believe the replacement you're referring to is likely to be available sometime in 2016?

[joelucid]

I don't know the protocol Felix uses but I suspect that the speed issues are caused by frequent acknowledge packets from the client. That really slows things down in particular when using a usb/serial bridge (see http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf for causes and fixes).

My boot loader is making good progress. Get this: I now have an app that replaces dualoptiboot with my boot loader without the need for an ISP. Just upload the sketch to your Moteino and you're set for wireless installs without external flash.

In terms of speed an upload of a 28k sketch in under 3s is definitely doable.

[joelucid]

Do you believe the replacement you're referring to is likely to be available sometime in 2016?

Yes.

[WhiteHare]

My boot loader is making good progress. Get this: I now have an app that replaces dualoptiboot with my boot loader without the need for an ISP. Just upload the sketch to your Moteino and you're set for wireless installs without external flash.

In terms of speed an upload of a 28k sketch in under 3s is definitely doable.

That would certainly make for easy installation.  Sounds fabulous!

[joelucid]

That would certainly make for easy installation.  Sounds fabulous!

Yeah - the consequence being though that it really needs to be absolutely rock solid. If the bootloader fails people without ISP programmer it's pretty bad. But I thought it was pretty cool that there was enough flexibility in the DualOptiboot to make installing without ISP possible.

[Jfisher]

I got :
FAIL: No response from Moteino programmer, is it connected to COM14?
I clicked the start button a few times, (without touching any hardware!) and eventually got a
Moteino: [FLX?OK]
HANDSHAKE OK!
followed by a successful upload.

Same issue here, managed to send a sketch twice with a few failures in between with the above error,  but now I can't seem to get a response from the Moteino programmer at all.
No settings were changed, and it appears random.
Debug was set to false on both programmer and receiving end, using V1.3 OTA on Windows 7.

Has anyone had a similar experience and fixed it to run reliably?
The node I'm testing on will be in a remote place, so I'd like to make sure I can program it without having to get the ladder out every time  .

EDIT:
-----------
Programming from Moteino R4 to Moteino R4, using Felix's FTDI programmer, updated to the latest RFM69HW & Wirelesshex libraries & OTA binary. Fiddled with WirelessProgramming_Gateway sketch timeouts as last resort. Can't seem to figure out why the programmer does not respond to 'FLX?'.

I haven't tried the command line method yet; if that's more reliable I might give that a go next.

[ssmall]

I have run into this before as well.  I figured out it is because I'm using ATC.  If I move the wireless programming node closer to the node I want to program it works just fine.  If you are too far away the programming node probably does not receive the acks.

[Felix]

I've just added a change to the ATC lib to allow the mote dialing power up when it can't get the ACK through. Without this change, a lower threshold would effectively lockup the end mote. You may want to try this or increase your ATC threshold.
See this comment and Tom's response for more details.