protocol improved to support variable HEX record length
various other minor bugs fixed
removed the logging delay in v1.5 since it was causing some glitching
Since v1.5 (release notes here) you may know that this OTA GUI can also invoke the OTA.py script which is included with it. This way you may customize the OTA.py script to your own needs, the windows GUI uses the same algorithm. The GUI includes the IronPython runtime and libraries required to invoke this python script right from the app. You may of course simply use the OTA.py script independently if you’re so inclined.
I spent a few days doing testing and I would like to invite Moteino users to try this new version and report any bugs via the contact form.
For those interested in future releases – last year I developed a new OTA algorithm which cuts the upload time dramatically. I mentioned this briefly in the forum but I got distracted in many other directions and it’s not finalized. It is more complex and needs a lot of testing and fine tweaking. It was originally intended for transferring small files via non-wifi subGhz transceivers (RFM69) and would need porting and adjustments for OTA purposes. I would like to hear feedback and see the level of interest about wireless programming of Moteinos (aka OTA programming). Feel free to drop a line and share your experience so far and change requests.
In past times (see this and this post), wireless programming of a remote Moteino used to be done via a python script. This took a compiled Moteino sketch (hex file) and passed it to a programmer Moteino which would relay it to the target node . Later this python app was migrated to a windows desktop app (see release post and upload speed update). At which point non-windows folks were left with a somewhat out of date python script. I was asked about the status of the python app many times. So I decided to merge the python script and windows app so all platforms can use it. This was done via IronPython which can invoke a python script straight from a windows app. Hence wireless programming for Moteinos has gone through several changes:
the windows app now can run both natively (windows code) or invoke a new updated OTA.py python app which you can control and modify if you’d like
This is the best of both worlds. The new OTA.py script is cross platform and independent of the windows app, just needs to be invoked with the right parameters (run `python OTA.py -h` for details). Those on windows can just use the desktop app (runs the protocol in native C# code), or can click the “Run OTA.py” checkbox to instead invoke the OTA.py script dynamically. The parameters are passed from the desktop app into OTA.py and the desktop app conveniently remembers your programming parameters next time you open it.
Most significantly the WirelessProgramming.exe is now 3.8MB (vs 29KB) because it bundles all the required self contained IronPython runtime to run the OTA.py script. It also requires the pythonLibs.zip file that was added in the same directory.
Give this free tool a try and let me know if there are any issues or bugs. Enjoy!
The Wireless Programming GUI app that I introduced in an earlier post is now at version 1.2 (get exe here). It features the ability to bundle up to 3 HEX file lines per RF packet (instead of the default 1), which yields a significant transfer speed increase. Let’s just do the TL;DR first and gaze at the results of transferring a compiled sketch of 13,858 bytes:
running with 1 line per packet (the same as before) yields 866 packets and ~43s OTA time:
running with 3 lines per packet yields 290 packets and ~18s OTA time:
That’s an average 58% speed gain, not too bad! By comparison, the same sketch uploaded directly via FTDI/serial takes about 13s, so much closer to that figure than before. I think a few other techniques could be used to squeeze yet more speed (increasing RF bitrate!) but that’s for another day.
Note that the same exact data is transferred, except in fewer longer packets. I had to make some changes to the WirelessHEX69 library to support these longer packets. Also I fixed some bugs that emerged during this development, see the github commit for all the changes.
To support the new GUI v1.2 speed increase you only need to update your WP programmer Moteino with a new version of the WirelessProgramming_gateway sketch (to refresh the WirelessHEX69 code) to make it support the faster WP speed (ie also update the WirelessHEX69 lib!). Everything else is completely backwards compatible, and you can use the new GUI v1.2 with an older WP programmer Moteino if need be (1 line per packet only), and also all old target nodes that are OTA/WP programmable are not affected at all and can be updated at the new speed. FWIW you can actually use 1 or 2 (not sure why you would) or 3 lines per packet (the new default going forward). Experiment and see what your own speed gains are! Please report any bugs or issues in this forum!
Not much to it really, a mere 300 lines of loosely written code, last (mid)night. Here’s a rundown of the features, I tried to make this a bit more useful and intuitive to use than the command line python script, so that would be the main attraction other than being a GUI:
gives you a list of available serial ports so you don’t have to guess (you still have to know which serial port your wireless programmer Moteino is connected to)
allows you to type/paste or browse for a hex file
allows a numeric target node ID
once all settings are populated with valid info, the Start! button is enabled
upon exit, it saves the settings to registry and attempts to read them back in future launches
Clicking Start! will do some validation and start the OTA protocol just as the python script did it, but also gives you more visual feedback with a progress bar at the bottom:
I will potentially expand this to allow remote wireless programming through a tcp port, just like the 3rd party vb6 app, but I doubt that will be very popular so I am sticking to the basics for now. If there are any bugs let me know.
This is it for 2015, see you on the other side of 2016!
The Wireless Programming library and examples are updated to fix bugs and support the MEGA as well. Another important change is the introduction of radio.ACKRequested() function in the RFM69 lib which should be used instead of the radio.ACK_REQUESTED variable. This ensures that ACKs requested by a broadcaster are ignored and only targeted ACKs are responded to. Please update your examples for proper wireless programming behavior. All examples have been updated to reflect this change. Also the SwitchMote sketch has been updated.
I consider this a major release and hence your constructive feedback and notification about anything that was omitted is appreciated.
I’m close to being done coding the SwitchMote, I think the code will be released tomorrow. I’ve been testing the code on the SwitchMote here in the lab because I can physically interact with the buttons on it. Needless to say, every time I want to upload the new firmware I cannot disconnect the breaker, unscrew the wall plate and the mains wiring, detach the unit from the wall to be able to upload through FTDI, that would be awful.
Enter wireless, over the air, magic, programming of Moteinos. I’ll just say that it comes in very handy when your project is in the wall!
I’ll cut this short and let you watch how it happens, too bad the flashing LED is not very visible on the video while upload is in progress:
One note to mention is that I’ve recently patched the wireless programming library to shift frequency up by 8Mhz during upload so the heavy RF traffic would interfere less with the rest of the network packets. Also I added an option to use another LED to be flashed during upload – handy for SwitchMote which has a bunch of LEDs on the front panel which are all on other pins than the default D9. I’m also planning to experiment with increasing the bitrate during the upload, maybe double it, and see how much faster and reliable that is. But that might prove tricky since several other settings depend on that, so all settings have to be changed back to what they were after the upload is complete.
I put together a quick video to show the progress of SwitchMote and a simple demonstration of how it works and how it can be used in home automation. My goal is to offer a smart wireless light switch controller that allows syncronization with other units independently (without the need of a gateway/coordinator) to create light scenes, and increase the usability of a regular light switch.
They are mostly tweaks, bug fixes and simplifications of the sample code. Hopefully things will be smoother now. As always, please let me know if the libs are not performing and I will do my best to patch the code and fix the bugs.
The last few weeks I have spent a lot of time tweaking the RFM69 library and trying to get the wireless programming to work. I believe the RFM69 library is now more stable and ready for some prime time and also the wireless programming is working nicely for Moteino R3. If you think about it, being able to reprogram a mote that is 200m away, or somewhere in a tree, underground, in your attic, or on the bottom of your pool, is a pretty cool thing.
I reorganized the Github repository a little, moved some files and now the classes for wireless programming are in their own repository to avoid conflicts with the SPIFlash lib:
The initial code commit for wireless programming was a little sluggish and the performance wasn’t very good. I had to add delays to make sure everything was synch-ed and the protocol was working. The result was a rather slow wireless upload of a new sketch, especially if it was a large sketch. But it worked…
Today I worked on improving the protocol and was able to cut down the over-the-air upload time by a factor of ~5. The gains are mostly from improved serial communication. This will still take about twice as long as normal sketch uploads by means of an FTDI adapter. For instance, a 9,8Kbyte sketch takes me about 11 seconds to upload directly to a Moteino using an FTDI cable; wirelessly programming that same sketch takes about 22 seconds. Not bad given how involved the whole handshaking protocol works. And much better than almost 1 minute with the old code. So I’m classifying this new release as a beta. More improvements or bug fixes might be added later, but it’s definitely a functional release. I’ve uploaded different sketches of around 10KB several times without a glitch.
The wireless sketches examples (gateway and node) and the python script are in their github repo. The SPIFlash library was also updated (the WirelessHEX part of it), so get latest before you try this.
As mentioned before, the target node of the wireless programming protocol will need to have an SPI Flash chip attached (if they don’t have one already), and also run the DualOptiboot bootloader for this to work. Moteinos come with this bootloader (all orders since the other Wireless Programming post and code was released). If you have all these components right, any Arduino clone with an RFM12B transceiver and an SPI Flash chip of at least 32Kbytes of memory will do the job.
Just for fun, here’s how the end of a wireless upload looks like, notice there were 617 packets sent all the way from the PC (through the python script) to the attached Moteino (gateway), wirelessly to the remote Moteino (target node):