RFM69_ATC: Automatic Transmission Control

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!

More Awesome DoorBell Control


UPDATE: I eventually decided to use a single switching regulator that I found on digikey which is both awesome and well priced. See this blog post update about it.

My first DoorBell Mote prototype was working nicely and it allowed monitoring the door bell (while also triggering it remotely – toddlers love it). But I wanted more. On weekends the family likes to get a well deserved nap during the day and often those pesky solicitors ring the bell and wake everyone up. So naturally the doorbell has to be disabled also, without major effort or any disconnected wires. Sounds like the perfect addition to the Door Bell Mote. So I made a new revision and a proper PCB for this, below is the schematic with the changes and the proto PCB from OSHPark. Actually I made more changes to the schematic after putting together the PCB, so there are some differences. I’ve tried a LTV814H optocoupler for AC detection instead of the more expensive H11AA11, it works just as well, but both can be used on this PCB:


There are 2 regulators on this PCB. One is a 12V linear LM7812. The second is a 3.3V linear regulator getting input from the 12V LM output, both in TO220 packages. I know they are super inefficient to convert rectified 16VAC to DC voltages and the critics will stone me for doing this. But here’s the deal – the linears are about 50cents each and I had both among my junk parts. An efficient switching regulator is somewhere between $5-$10. The linears run somewhat warm. The 3.3V regulator only gets warm when I use the disable relay. So they can get warm but not hot, which is fine by me, it’s just a tradeoff. I might make a new revision where I have a single switching regulator such as this one, a drop in replacement for the LM linear regs. Continue reading

Autonomous filming of GPS+Moteino moving objects

Hackaday.io user [Walker Eric] is an RC airplane enthusiast who wanted to record his plane flights autonomously, without the need of a 3rd hand or having to ask a friend to stand by for this purpose. The flying target should ideally be in the center of the camera field of view. For this purpose he designed a nice video-tracking system composed of a small LiPo powered Moteino+GPS unit that is mounted on the moving target (the RC plane). This reports frequent GPS positioning to the base receiver unit which controls a video camera movement via motors and follows the fast moving RC airplane.

He has managed to produce a really good prototype and has even submitted this as a 2015 Hackaday Prize entry. Zooming is desirable and it’s one of the features he is still working on. Overall this was a great project that Eric has shared with me and I’m quite happy that the Moteinos involved can handle the GPS coordinate transmission between the moving airplane and the base station.

This project could of course be used to autonomously record video of other types of RC moving objects. I can also think of people who want to film themselves doing some activity or record a moving object/animal etc. Check out his project page for more videos, photos and details of the build, and give him a skull!

Moteino Compost Sensor Network with Adafruit-FONA GPRS relay

I occasionally get emails from people that use my products in their projects and some of them are real gems. Other times I just run into them online somewhere or someone tips me off somehow. I did a poor job of keeping track of these but lately I thought I should start presenting the nice ones, maybe there are other people that have interest in similar things.

In this post I’d like to present a compost sensor network built by instructables member kinasmith. Who knew composting can be so interesting and complex.CompostNetwork2

It sounds like composting on a large scale requires careful monitoring of certain parameters so that the pathogens that aid in the process are kept happy and efficient. [Kinasmith] shows off a detailed and beautifully put together instructable that uses Moteinos, temp sensors and a solar powered Moteino+AdafruitFONA gateway to relay the data to his Sparkfun cloud, among other things. He goes into a lot of detail and I really like the nice touches and the effort that went into giving this project more than that hobby level feel. Check this cool project out on instructables.


Gateway Dashboard Overview

I’ve been talking about a new gateway interface for a while in the forum. I will release more details and the source code soon. Here’s an overview that I’ve put together the past week,  and some screenshots below with graphs and other available features:

Here are some more screenshots:


This content will be updated and improved on the dedicated Moteino Gateway page where all the source code and details will be published.

DoorBell + Moteino = Awesome

UPDATE: Check out the new version of this, now with bell enable/disable function!

A lonely doorbell activated by a boring push-button at the front door is not very exciting in a world of Arduino and “Internet of Things”. I’ve been wanting to Arduinize the doorbell into the Moteino Framework gateway interface so that I could:

  • observe/count/graph when the doorbell is used
  • get notified when someone rings it if I am not at home (email, SMS etc)
  • play a sound when I am in my lab where I have a hard time hearing the chime (did I hear it or not? should I go upstairs to check? nah… I’m too busy for that)
  • ring the bell if I want to, *remotely* from your mobile device (why not right? just detecting is too boring)

Below is a schematic of what a typical wired door bell circuit looks like, and also a photo of what it looks like in my house. The dotted green rectangle is the circuit that I have physical access to – pictured next to it in my basement (and I don’t have a back door button):

I have a single button (front door) and probably most houses do. So I only care to inject my solution for that front door button. There is typically a 16VAC transformer powered from mains that activates the chime when the switch is pressed. So there are a few issues to solve in order to tap into this circuit, detect button presses and also being able to control it via Moteino:

  • Power our circuit from the 16VAC doorbell transformer. This is a good exercise to  create a DC power source from an AC source. We’ll use a simple half wave rectifier to achieve this
  • Detect when this 16VAC current flows through the wire coming from the outside button. When the button is pressed, the chime will ring and our circuit detects the AC current and outputs a digital HIGH for the Moteino input pin that monitors it
  • Make the Moteino “press” the door bell button when it receives a “RING” wireless message

I will explain these points step by step. Let’s get to work! Continue reading

Moteino R5-USB & FTDIAdapter R2

There is now a new revision of Moteino USB (R5). It has 27ohm resistors on the D+/D- lines and pulled up the RST line on the FT231XS chip which should help with any upload issues, see this forum post for more details.

Also the new FTDI Adapter (R2) fixes the same issue and also switches from FT232RL to FT231XS. The reason being the economics of using a chip that is not only cheaper while doing the same function, but also the one and only USB-serial converter I now use.

I assemble all these boards on a pick and place machine and having a reduced and more efficient BOM makes a big difference. The FT232RL came in a wide 24mm tape which occupied a separate 24mm feeder. Buying a full reel of those parts is an impossibility given the price, and partial reels require a leader to load into the feeder, an extra fee every time you buy anything less than a full reel. Plus, some of the leader tapes I buy from Digikey break off pretty easily and so it’s a pain to work with individual feeders and I’m trying to avoid leader tape whenever I can. The FT231XS come in tubes which makes it much easier to work with using the vibe feeder. The only downside is that I have to reload them more often (58 parts per tube).

Moteino now on CodeBender.cc!

IMPORTANT NOTE: unfortunately codebender announced they are shutting down on or after Oct. 20, 2016. Hence forth this page is only kept for reference and it will eventually be removed. The codebender programming instances below might become inactive, display an error or show a blank space once codebender shuts down these services. You are encouraged to start programming or move your code in the Arduino IDE.

This is really awesome news!
The guys at codebender.cc have done a great job creating an online place to create, edit, store, share your Arduino sketches. It’s very easy to install and use right in your browser!

UPDATE: Check the new Moteino Programming Guide.

And now Moteino has been added to their fleet of supported devices, along with the RFM69, SPIFlash libraries. Once your Moteino is connected to your computer, you can edit your sketch, or load the example(s) of the many integrated libraries (like the Node example in the RFM69 library) edit the settings to match your hardware and upload it to your board. Another awesome feature of codebender is embeddable sketches, that’s right, any sketch can be embedded in another web page, like the Node example below, you can upload it right from this blog post (see below for browser plugin requirements, or check this getting started guide):

To be able to use CodeBender you will need to create an account, then install a browser plugin that allows access to your computer’s serial ports, which in turn make it possible to reset and upload sketches to your Moteinos (or whatever other board you may have and they support). Also you need to choose your target board, protocol (USBtinyISP for Moteino) and serial port it’s attached to, then click “Run on Arduino” and that will compile/upload the sketch. That’s about it. Please check their getting started guide as well.

I warmly recommend using CodeBender with Moteinos since it’s easy and much nicer than the clunky Arduino IDE, and it’s probably going to get even better as they add more features. Plus I will work with them to ensure the libraries are in sync with the latest releases, and new examples will also be posted on CodeBender. Of course, you can always add your own sketches to your CodeBender repository, just like you did in Arduino, or you can clone an example and load your own settings and modify the code as you like. I will probably start using embedded sketches whenever I want to share code since it allows CodeBender users to upload it right from this blog rather than going to GitHub, copy pasting, making sure they got all the latest updated libraries, etc.

To celebrate this great milestone I am reducing the pricing on all Moteinos by $2, a saving of 10-15% depending on your options, to last through the end of December!

Happy CodeBending!

Moteino Framework architecture decisions

My vision for Moteino was to create an affordable/open/ideal/easy hardware platform that would fuel a new generation of wireless internet-of-things, and I think it came out pretty decent. My Hackaday Prize entry even made it in the top 50 semifinalists (out of 800+). More devices are being added to the Moteino Framework and existing ones are being improved to make it fun for those makers who like to DIY and solder their internet-of-things from easy to assemble kits. The end users have maximum freedom as far as using/building stuff with Moteino. They can build absoltely everything from scratch, as some have done, but some prefer to just save time and buy building blocks. Hence I funded my way through this adventure by selling ready made Moteinos and kits in my webshop.

People have asked many times why the Moteino was designed the way it was, and why not use this and that and the other type of MCU, transceiver type, radio band, or wireless technology. The number one reason why Moteinos are what they are today is because in the end they need to be designed to manufacture, work well, be reliable, license free, easy and fun to use in a friendly board format, cheap to buy or make, achieve long open air range or excellent indoor obstacle penetration when used with transceivers, etc. Here is my reasoning behind all these decisions and the answers to some frequently asked questions. Continue reading

Moteino Framework submitted to The Hackaday Prize!

The Moteino Framework (of connected things) is submitted to The Hackaday Prize. If you want to support this entry you can give it a “skull” on the project entry page. Here is the stage-1 video presentation and overview:

If it gets past the first stage I will continue to add more details and refine the entry. Thanks for your support!