If you’ve been using Wirelessly Programming, a unique feature that comes with all Moteinos, you will love this new update to the OTA GUI. The main requirement for this release was the ability to change the Programmer Moteino settings right from the GUI without reprogramming through the Arduino IDE. Here is the summary of changes:
A few UI changes and improvements and a new settings section:
support for on-the-fly change of Programmer RF settings: networkID, nodeID, frequency (in Hz), EncryptionKey (either blank for no encryption, or 16-character key), BitRate (either default or 300KBPS). Existing RF Settings can also be read from the OTA Programmer. Note: for the settings feature to work, the latest OTA Programmer sketch is required
UI no longer locks during transfer! The GUI window can be moved/minimized, log can be cleared at any time
ability to CANCEL a transfer
ability to refresh the COM ports dropdown
backward compatible with older programmer/target code
various bugs fixes and improvements
When you change settings on the Programmer, for the OTA transfer to work, those same settings need to match on the Target (sample starter Target code here), or the target has no way to intercept any packets from the Programmer.
If you’d like to change the RF settings on the Target, then first compile the sketch with the new settings into a HEX file, transfer it as you’d normally do, then change the settings on the Programmer via this new GUI, and you’re ready to do more OTA transfers once settings match.
The ability to change to 300KBPS instantly is very useful. That makes transfers significantly faster:
As always, if you run into any issues, have suggestions or bugs to report, please don’t hesitate reach out or start a discussion in the forum.
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: