After Moteino R4 has been the long running champion of its lineup, and R5 has had a brief period of glory, Moteino has now been shipping for the past week at revision R6!
Wait, what happened to R5 which was never announced you ask? Well R5 was mainly a transceiver layout change from R4, it also added a u.FL RF connector (which is now offered in the shop) and SMA connector “helper” pads, and few other minor layout changes, nothing too significant and otherwise identical to R4. Customers were now getting HCW and LoRa radios on the same Moteino PCB instead of separate PCBs for HW and LoRa.
However in R6 there are more important changes:
CW transceiver layout has been added in addition to the RFM69/LoRa layout, which means that the whole spectrum of RFM69 and LoRa radios are supported. Note that W and HW, while still in the shop, are no longer available as an option for MoteinoR6 – they are replaced by CW and HCW (which are 100% equivalent from a software and features perspective, but smaller!)
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!
John from John’s DIY Playground put together a nice video of setting up a Weather Node powered by a PowerShield from a LiPo battery, watch his assembly vide and demo below.
Although you could directly power the Moteino + WeatherShield from a LiPo battery, this is a good example of how you might assemble & use the PowerShield to get 5V from any lower voltage and power Moteino and other sensors for low power operation.
James from snorp.net looked into automated blinds but when he saw the eye watering prices he decided to make his own wireless motorized blinds. He posted a great detailed tutorial to do just that. The result is motorized blinds automation device that is wireless, low power and costs just $40 for the DIYer. This is a blast considering commercial devices can cost upwards of 10x or more. Here are the highlights of his project:
after experimenting with Bluetooth, he decided to use Moteino a try for it’s ability to use ListenMode and make the project very low power
the chosen motor was the 28BYJ-48 stepper motor for its low cost ($2), quiet operation and fine control ability
he used Fritzing to design a simple yet very elegant shield to host his motor driver and Moteino and posted the schematic, layout and BOM then fabbed the PCBs at MakerStudio:
the whole assembly is pretty compact, it uses a 4xAA pack to yield a consumption of just 46µA while running the motor an average 12s/day, that comes to a theoretical 7 years life on a set of high quality 4xAAs. In real life that should last at least 2 years. Here’s what it looks like assembled and installed:
I had previously released a MoteinoMEGA with trace antenna, and there is now a regular Moteino with trace antenna. Everything is the same as the MEGA variant, except of course this is the atmega328p based Moteino, the most popular variant. The antenna is tuned to work in the 868-915 bands and should deliver very decent performance, close to the wire monopole. Here it is next to it’s MEGA sister board:
Over the past few months a friend has helped me create a MoteinoMEGA variant with a trace antenna tuned for between 768Mhz to 1.16GHz. So this should be great for 868-915mhz. I’ve tested this variant myself (915mhz) and I was surprised how well it performs compared to a wire monopole (which will still be better given the type of antenna). I did not do extensive testing but I am pretty confident this turned out as a great antenna and I am offering the remainder of this batch for those eager to have one and perhaps do more testing on their own. Depending on the response I may or may not ever make more of these, we shall see. The same antenna could be used with any other Moteino but I want to see the response of the users before I invest too much capital in new batches of Moteinos. The ANT pad and u.FL footprint are still there if for some reason the user wants to cut off the trace antenna and use one of those instead with a monopole or different antenna. Otherwise everything else is the same, well, except the yellow soldermask which has a nice orange hue from my new PCB supplier. I will offer these with RFM69W/HW in 868/915mhz or without a transceiver, your choice. 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!
There is a new variant of Moteino available: MoteinoMEGA with LoRa footprint and onboard FTDI USB-serial converter. This is the first MEGA USB variant. It will also work with RFM69HCW radios if you want a MEGA-USB with RFM69, but for now you will need to source your RFM69HCW from somewhere else. Otherwise all sketches and examples should work as before. I have yet to create a pinout diagram for this variant but it’s pretty much the same as the MoteinoMEGA. Here is a shot of both sides, shown with a RFM95 LoRa transceiver soldered on the bottom:
There is now a new extension to the RFM69 library. It’s called RFM69_ATC aka Automatic Transmission Control. Many thanks to Tom Studwell who implemented this and shared it in the forum. The basic idea behind this extension is to allow your nodes to dial down transmission power based on the received signal strength indicator (RSSI). For instance a sleepy battery node like a MotionMote sits still inside the home and usually has a very strong received signal, somewhere in the range of -30 to -40dBm when transmitting at full power. You could manually tune that down using radio.setPowerLevel(..) in code but its tedious and is a static change, if you move the node or conditions change it will not be smart to adjust the power level to the new environment. However with RFM69_ATC this is done automatically for you, you just need to indicate a target RSSI. On each packet sent and ACK received (using sendWithRetry(…) is required), the node analyzes the actual RSSI and continuously adjusts its own transmission power level of the RFM69 transceiver to attempt to match the target RSSI (+ or -). This way that end node is only “loud” enough to be heard by the gateway, not much louder. Close by nodes can “whisper” while nodes farther away or with more obstacles will “speak up” as necessary but avoid that default fixed maximum “screaming” level. This is “polite” in terms of “RF pollution” and efficient in terms of power consumption. Even non-battery nodes where power is no problem should implement this for the sake of the “polite” factor.
I have updated the Node and Gateway examples to have ATC enabled, and also the MotionMote example is now ATC enabled, in this case with a target RSSI of -90dBm. The noise floor is somewhere around -100dBm with the default RFM69 lib settings, so for static nodes that won’t experience a lot of movement or temperature drifts, a -90dBm target is pretty safe. That will keep the transmitter power to a minimum and save power. We know that the greatest toll on a battery powered node are the spikes of current used when the transmitter is active (up to 130mA for RFM69HW). Reducing the transmit power level to the minimum required will exponentially reduce that spike and result in longer battery life and a more “quiet” sensor network that won’t reach across your whole neighborhood. This is really awesome!
Here is a sample transmission using the Gateway and Node examples linked above. Note how the node starts transmitting at full power, then dials down power to match a test RSSI target of -68dBm. This is output from the Gateway end:
There are a few required changes to a sketch where you want to use ATC:
you must #include<RFM69_ATC.h>in addition to #include <RFM69.h>
you must use RFM69_ATC radio; instead of RFM69 radio;
for the gateway/receiver end the above two changes are sufficient, for the end node that does the power level adjustment you must also do the following:
in your setup() function (after all RFM69 initialization is complete) call this function to set your target RSSI: radio.enableAutoPower(targetRSSI);
targetRSSI is a negative integer, should be from very strong (-30) to very weak (-95). Usually you would want to be closer to the noise floor end (-100) since you want to reduce transmit power to the bare minimum
this is a one time call that enables the dynamic adjustment of the output power on that node
you must use radio.sendWithRetry() instead of just radio.send() or a combination of radio.send() and radio.receiveDone() for the radio to be able to receive the important headers from the gateway that tells it how to handle its power, this was done in the MotionMote example linked above
Once these changes are implemented, the node will start to progressively dial down power (assuming it starts transmitting at full power) with each packet sent, until the RSSI meets the target. When the RSSI is below the target power is dialed up again and so on, in an attempt to stay as close to the target as possible.
In the examples that I mentioned there is a pattern that I followed by implementing a define directive (#define ENABLE_ATC) which when left uncommented will enable ATC at compile time, if removed/commented the sketch will run normally without ATC. As always, bug reports, suggestions and contributions are welcome, the forum is the best place for that purpose.
I must mention here that at this time I have only partially implemented his variant with some adjustments to Tom’s implementation (I left the differences commented out in my version). For now I chose to leave my power control resolution as is. He actually went into more detail allowing a finer control of the power control – this is because of the differences between RFM69W and HW which handle output power control differently. If you’d like to try his variant with that extra control check this forum post or his Github repo. Thanks Tom for your great contributions and inspiring this piece of work and also the awesome forum projects you’ve posted!