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

Can RFM12B talk to RFM69?

I was asked this question a lot of times. Didn’t have a clear answer because in my early attempts to make them talk to each other I didn’t have success. I didn’t spend a lot of time on that since my interest has leaned towards RFM69 transceivers since they are much nicer and feature-rich overall (nicer packet engine, hardware AES encryption, digital RSSI etc).

Forum user timw has forked my RFM12B and RFM69 libraries and modded them to make them compatible, see this forum post for details. Turns out these mods makes communication possible between RFM12B and RFM69 transceivers. This is great news!

I was able to load his version of the libraries in my Arduino/libraries folder (I had to move/remove my original libraries because of conflicts), and using the examples that come with the two libraries (Struct_receive example on the RFM69 side, and Struct_send on the RFM12B side) I was able to see data coming through the RFM69 end. Seems very stable too. The signal strength (RSSI) fluctuates a little more than if I had RFM69 radios on both ends but it’s great to actually see a signal strength for a RFM12B transmitter:

The caveat is that the encryption must be turned off on both ends with the current version of the libraries. That’s because RFM69 uses hardware AES encryption and RFM12B does not support hadware encryption but uses a software XXTEA algorithm instead. The two are not compatible. One workaround would be to port/duplicate the XXTEA encryption on the RFM69 side, probably a little slower but worth it if encryption is important.

So anyway this should help folks that are trying to salvage their RFM12B nodes and make use of them while moving towards RFM69 based nodes. For me personally I will likely just upgrade everything to RFM69 moving forward but still this is a great development. Thanks timw for sharing your work!

Mailbox notifier project upgrade

Time for an upgrade to my mailbox notifier. I long wanted to give it an upgrade and folks kept asking. Here are the things I wanted to change/add:

  • the transistor was a rather unnecessary complication and it made assembly more difficult. The hall sensor could simply be powered from a Moteino pin
  • a more weather proof enclosure would be nice
  • use more velcro to keep the thing from falling off (happened a few times when the mailman was more violent with my mailbox door).
  • how about battery voltage reading too!
  • upgrade code to use structs since all I’m sending is a bunch of integers
  • I wanted a standalone receiving unit with a LCD screen which I could operate from another 9V battery or just plug into an FTDI for quick reading. The other receiver on the RaspberryPi could still receive the same packets and still send an SMS


Continue reading

Sump pump alert with Moteino & HC-SR04

UPDATE: This project has been replaced/updated with SonarMote. See this blog post for a more rencent implementation of what you see here. The alerts are now implemented as simple events on the Moteino Gateway.

Here’s another project I wanted to do for a long time. I wanted a sump pump flood warning alert system in place, for peace of mind when I’m gone from home for prolonged periods. For whatever reason I thought this was going to be more difficult but no, it’s almost as easy as pie!

All I needed was a HC-SR04 sonar sensor and a USB 5V wall supply. The sensor only works at 5V so this method of powering the Moteino was very convenient since I already have an outlet close by for the sump pump.

The sensor has 4 pins clearly marked: VCC, GND, TRIG and ECHO. I connected VCC to VIN on Moteino, ECHO goes to D3 and TRIG to D4.


I used some of the code this instructable to get started and added my wireless code to handle packets and blink the LED and was done in no time. The setup was very simple, I estimated a good spot underneath the sump pump cover where there are no obstructions inside, cleaned it up, taped some velcro, secured the wires and that was pretty much it.

 Moteino_HC-SR04_SumpPumpAlert_cover Moteino_HC-SR04_SumpPumpAlert_installed

I added a few lines of code to my main Python script running on the RaspberryPi.
By the way, here’s how my RaspberryPi setup looks like, including the ATXRaspi power controller, the power button and the gateway Moteino (it’s an older R1 but just as good for as a gateway):


The Python script logs the data to EmonCMS and here’s a graph of how that looks like, the Moteino reports the distance to the water surface, so the spikes means the sump pump just kicked ON, and as water rises the distance decreases until the pump starts again:


It’s been a rainy spring so far here and I knew my pump kicks ON quite often, now I can see it in real time, and setup alerts if the water rises too much. Seems like the pump is always pumping water out when it rises to 32cm below basement surface. So setting an alert to something like 20cm below surface should be enough since I don’t expect the water to ever rise so much as long as the pump works. The alert code will send me a SMS message when this happens, here’s a test level, I set the live value at 20cm:


You can of course setup other types of alerts – like audio alerts or maybe a LED visual indicator (less useful when you’re not in your basement).

Fun/Scary fact: The sensor is very accurate even though there’s a variance of 1cm between some readings (resulting in a sawtooth graph) as water rises. Based on the graphs, how often the water is pumped (every ~23 minutes), and how big the reservoir is, I figured my sump pump removes roughly about 18.5 liters every cycle, or about 1158 liters (306 gal) every day, wow!

So now there’s an extra level of peace of mind when I leave on vacation. I guess being gone for even 1 day could mean disaster if the sump pump breaks down at the same time!

Time to think about how to gather/store all that water instead of throwing it away, after all, I pay something like $11 for every 1000 gallons of city water.

Source code is on GitHub:

Moteino wireless programming source code

I managed to put together a library and refactor the code that I used to achieve Moteino wireless programming.

There’s a new WirelessHEX file in the SPIFlash library. There are new WirelessHEX classes for RFM12B and RFM69W/HW transceivers. These files contain helper code that handles the new sketch over-the-air transmission for both the transmitting and receiving ends. It will increase your sketch size by a few KB, that is just an unavoidable tradeoff.

The target node that is to be wirelessly reprogrammed will need to have code to listen for a potential new sketch. I uploaded the example sketch along with everything else to the RFM12B library examples.

The gateway node sketch, target node sketch, python script that passes the HEX file to gateway node are all located here:

The custom DualOptiboot bootloader allowing the reflashing with the sketch stored on the external SPI FLASH memory chip is here:
I managed to keep the size just under 1k. So in the future Moteinos will probably ship All Moteinos (R2 and R3) are now shipping with this bootloader to allow for potential wireless reprogramming if you also have the FLASH chip onboard the target mote.

I would call this an alpha release even though it works pretty well. Sometimes it’s a hit or miss because of the delays I’ve set in python. Those could be refactored and code improved to be smarter about initial requests for a sketch transmission. But it seems in most cases it works the first try.

Further improvements are:

  • increase speed of transmission
  • test with larger sketches
  • refactor python script, WirelessHEX library and gateway/target node sketches

I’ll try to keep up with changes and updates. Right now I have no idea if anyone will find this useful or not.

Wireless programming step 2: SUCCESS!

It works! I was able to reprogram a remote Moteino over the air with a blinky sketch!

Definitely not a ground breaking achievement, but it really felt like “Hello World” all over again! 🙂

I didn’t expect to overcome this so soon but I managed to get past what I thought would be the biggest hurdle: customizing Optiboot for wireless programming. Actually it’s just reading the new flash image from the external flash chip and transferring it into the internal flash memory. The “wireless” part happens in Step 1. Continue reading

Quick update: Moteino back in stock

A new revision of Moteino is back in stock. Parts and PCBs finally arrived after a long delay which was out of my control. I should be able to fulfill the preorders in 1-2 days and then be able to ship new orders.


There are 2 obvious changes to Moteino:

  • they are now Green
  • they contain a new footprint that can be used to solder Atmel serial FLASH memory. This can be handy for data logging and/or other interesting applications that I have in mind for Moteino in the near future.

I also have the 915Mhz version of the RFM12B radio in stock. I have done some testing and was very surprised to see this radio performs just as well or better in certain circumstances. The 434Mhz version still seems to have a slight advantage in penetrating obstacles.

Stay tuned for updates on these changes, and more on the 915 vs 434 frequencies.

RFM12B air transmission speed calculator

I uploaded an excel spreadsheet on Github with a table of achievable air transmission rates for the RFM12B radios, including code instructions for my RFM12B library.

You can tweak these to achieve better range or better penetration. It’s hard for me to provide specifics since in my case the default 38kbps works well. This guy on the jeelabs forum achieved much better reception by lowering the kbps to ~9kbps in his environment.

If you use this and get interesting results, I’d love to hear about it.


Custom Optiboot for Moteino

The Moteinos have an LED onboard. But it’s not on D13 as regular Arduinos, instead it’s on D9 (PWM pin, can be faded). I’d like the LED to flash when the bootloader starts and when Moteino is programmed from the Arduino IDE. So I rebuilt Optiboot for this purpose and all future orders for Moteinos will come with this tweaked Optiboot that will make use of the onboard LED when you reprogram it.

This is a video of how I program and test Moteinos before I ship them to you, also showing the updated Optiboot in action: