Wireless Boot in 2.5 Seconds / High-Speed Datastreams

[joelucid]

I think you could run these sensors just fine at 8mhz using the internal oscillator if you continue having problems with the level converters. The sensor code just sits in delay and that takes the same time regardless of processor frequency.

[executivul]

I like to test first on breadboard then go the soldering route. What you see there it's just the alpha state switch node prototype. I was curious how much power they draw, how hot the LM2596 gets, how do all parts work together. Looks promising until now.
After I receive my 3D printer tomorrow and get it assembled and running ok I can start building one or two "betas" of the future wall switches, all soldered using kynar and cat5 for power.

Joe I have no delays in my main loop(), all readings are done in a state-machine way since having a few variables for states is no problem, I use only 35K of flash and 2K of RAM. The only delays/locking loops are the ones used in libraries. Servicing the encoders takes quite a few lines of code for each and there are 8 of them, the Ada display library is a huge mess, about the DHT, 1Wire and I2C I have no idea since I didn't have the time to take a look at their code.
Still working on a state-machine RFM69 hack to get rid of those while() in tx and rx but that's another story.

[WhiteHare]

I just now noticed that there was a notionally similar approach to OTA wireless programming back in 2012:  http://jeelabs.org/2012/10/31/meet-the-wireless-jeeboot/#comments and http://jeelabs.net/projects/jeeboot/wiki/Design_Notes

Unfortunately, it apparently never got developed much beyond the initial POC, and it seems to have more or less died on the vine.  What a pity!

[joelucid]

I just now noticed that there was a notionally similar approach to OTA wireless programming back in 2012

Very interesting! I hadn't seen that. Anybody know why it died?

[Felix]

From what I gather it's actually very different technically than joe's method.

[WhiteHare]

I doubt it's as refined.  It does have the virtue of being published, though, so for folks like executival who are chomping at the bit, maybe it makes sense to have a look and/or try it rather than just waiting indefinitely.  Interestingly, its bootloader is only about 2K in size.

[joelucid]

From what I gather it's actually very different technically than joe's method.

At least on the protocol level it's very different - given it takes a minute for an install to complete with his method. And I think that also explains the difference in code size. Otherwise there are many similarities. That is to be expected since we're solving the same problem.

[executivul]

Thank you WhiteHare. I've searched a lot for other OTA bootloaders, found some NRF24 (nekromant's) but did not stumble upon this.
Now I'm working on the node code itself and maybe in the meantime Joe will share his solution. Hope dies last!

[joelucid]

Hope dies last!

I'm working on it. If I change my plan I'll let you know.

[executivul]

Thanks Joe! I mean it!
I won't be able to move in the new house until spring/summer next year. It's still under construction, building brick walls and roofs. In a few months I hope to start placing the wires and pipes, until then I must finish designing the switches so I can choose a in-wall box size for them. I've bought a 3d printer to help me build a frame to hold all the components inside the in-wall box. I must finish drawing the wiring schematics for 220V, 12V, Ethernet, TV, alarm. Some things are switched locally by small relays, like lights, while some are switched at the fuse box by large relays (big loads like washers). Radiators are individually controlled. Lots of things to consider. Then I must finish building all the nodes and I must test everything for reliability, WAF must be as close to 100% as possible and remaining in the dark/cold is not an option.
So until I move in the new house and start running with my laptop from node to node to change a sketch the wireless bootloader is not really needed.
Please take your time and release it whenever you consider.
Sorry for the off-topic and I promise not to bug you anymore about it.

[TD22057]

So I've been re-reading this thread and it seems to me like there are two separate features that joe has implemented:

1) Radio speed improvements.  Streaming mode, bit rates, and radio code w/o any waits.  This is pretty general purpose radio functionality and should be useful to any project I would think.

2) Automatic wireless programming.  From what I can see, this is a feature of the gateway which transmits code to the nodes if a new set of firmware is available for that node.

I was thinking more about 2) and it seems like that should be pretty straight forward to implement now (at a slower rate than joe's) by using the command line wireless programming tool that already exists.  Basically run a small script that looks for new firmware in some set location on the gateway and initiates a download when it shows up.  This isn't really different than now using wireless programming, just that the transmission starts from the gateway, not the user.  This doesn't require any new boot loader or listening modes to achieve - that makes be think I'm missing something about this feature though.  So do I have this right or is there something else going on that I'm not thinking about?

[joelucid]

So do I have this right or is there something else going on that I'm not thinking about?

The piece you might have missed is that the boot loader does it without the need for an external flash chip. That's one of the biggest benefits and enables much smaller or more fully featured designs.

Listen mode helps a bit since if allows you to trigger a reboot in an ultra low power node where you'd otherwise have to wait for it to phone home. But it's a pretty independent feature.

[TD22057]

The piece you might have missed is that the boot loader does it without the need for an external flash chip. That's one of the biggest benefits and enables much smaller or more fully featured designs.

Thanks - I felt like I must have been missing something there. 

[brolly759]

Joe, I used xbeeBoot code in one application already, is this pretty much the same concept but with RF69 chips?

https://github.com/davidsainty/xbeeboot

[zingbat]

Hey Joe,

Would you be willing to release the bootloader? I'm very interested in unbrickable, remotely programmed nodes for locations that will be hard to access. I'm happy to modify the bootloader and de-couple it from the protocol/throughput enhancements you made, unless you'd be willing to share that too.

Thanks!
Jeff