Category Archives: Code/Library

Can RFM12B talk to RFM69?

Posted on by

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!

RaspberryPi home automation gateway – Hardware and Demo

Posted on by

UPDATE: An updated version of this gateway install guide is published here. The rest of this post is kept here for legacy purposes, some links to source files might be obsolete or not work any longer, please see the linked guide above for the latest code and walkthrough.

In this last part of the RaspberyPi home automation gateway series I will show an example of hardware implementation that talks to the RaspberryPi secured realtime home automation gateway, and share the firmware source code.

GarageMote is a garage door controller shield that can be used to remotely control a garage door from anywhere on the web or from your smartphone.

GarageMote was created for several reasons. Mainly because as I’m adding more Moteino based home automation devices around my property, one of the nice things I wanted to be able to do is control the garage door remotely. It’s become so routine to close the garage door when I leave from home that sometimes when I’m already 5 or 10 minutes away I wonder if I actually closed it. And so I want to be able to check the door status and close it if it was left open by mistake, without having to drive back home. Or maybe it’s useful to be able to let someone in without giving them the garage code every time.

Continue reading →

RaspberryPi home automation gateway – Setup

Posted on by

In this third part of the RaspberyPi home automation gateway series I’d like to present the RaspberryPi software stack that will allow a secured realtime webserver-websocket gateway to your home automation project.

As a webserver I decided to try Nginx. I’ve previously used Apache which always felt a bit slugish and had a large disk and memory footprint. There are many bechmarks that contrast webservers performance, here’s a nice one that focuses on RaspberryPi, and it includes Nginx and Apache.

The stack will be a webserver (Nginx) and a websocket server (Socket.io). The websocket will be proxied through Nginx, and everything will be encrypted with SSL and authenticated with auth_basic. A bunch of other things need to be setup and configured to make these work nicely together. Continue reading →

Temperature and RC-Calibration for RFM69

Posted on by

I added two new functions to the RFM69 library: readTemperature() and rcCalibration(). Thanks to John for contributing.

  • readTemperature() function reads the internal CMOS 8bit temperature value, it’s fairly useful for situations where temperature varies a lot and RC calibration would be needed.
    The Gateway example has been updated to reflect its usage.
  • rcCalibration() will trigger a calibration of the internal RC oscillator. This is automatically performed at power-up according to the Semtech SX1231 datasheet section 4.3.5. But it can be triggered with this new function, as John has mentioned in the forum that when temperature changes, the RC oscillator will be affected, and a dramatic temperature shift will result in a frequency shift as well, causing a link to possibly be broken (for instance when your receiver is inside your house at room temperature and the transmitter is outside in bitter cold winter).

With the combination of these two functions, you can now recalibrate the RC based on temperature change, and also report a rough ballpark of what the temperature is. If you need more accuracy, a separate temperature sensor like the DS18B20 should be used.

 

Update & RFM69 lib bug fixes

Posted on by

For those wondering what’s going on with the silence, I have been quite busy but I am continuing to work on improving Moteino and the libraries behind it. I hope to release news on what I’m up to in a few weeks.

The forums are now picking up activity and they are a good place to check out for various support questions that have already been answered and also to see what others are saying/sharing about Moteino.

I encourage you to keep an eye on the library source code on github for bug fixes. I am working to extend the RFM69 library and occasionally I find code that I can improve and even bug fixes. For instance right now I patched a fix for the setPowerLevel(byte level) function which was declared incorrectly as protected and also had a bug. This bug fix is especially important for those that have Moteinos with RFM69HW radios. Overall my feeling as I develop with the RFM69 library is that it’s becoming a more and more stable piece of code. I do rely partially on others to provide feedback and I appreciate those who can participate and submit suggestions.

Wireless programming Moteino R3

Posted on by

It works!

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:

https://github.com/LowPowerLab/WirelessProgramming

If you have a Moteino R3 (or R2) with the onboard FLASH chip, you are ready to try programming it wirelessly, go ahead, it’s pretty neat.

The examples for Moteino R2 and R3 are in the directories for their libraries: RFM12B and RFM69.

More great stuff is coming, I got a lot of ideas for Moteino R3, I am thinking of migrating my home wireless sensor network to R3 and implementing a lot more home automation on these.

RFM69 library and Moteino R3

Posted on by

This is the library that I’ve been working on for the new RFM69 modules from HopeRF. I consider this an initial beta release and it surely is a work in progress, it may contain bugs, but the provided Gateway and Node examples should work out of the box and illustrate basic usage. Please let me know if you find issues. The syntax is a little similar to that of the RFM12B library, but I went with some new conventions on naming and overall structure to improve readability and overall code quality.

This is a video introduction to Moteino R3:

This is a new product and the library needs more testing and performance tuning. The library currently is tuned for fixed 433/868/915 Mhz frequencies, and a 50khz bitrate, 50khz frequency deviation. I am hoping others will contribute and test the library to find the best combination of these settings and power level vs range vs frequency vs bitrate, etc.

Continue reading →

Wireless programming update

Posted on by

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):

Transmission_end

SPIFlash memory library for Arduino/Moteino

Posted on by

I posted the SPIFlash library I was talking about in previous posts. I have not found a convenient library for that purpose hence this library written by myself.

Get it at my Github repository: http://github.com/LowPowerLab/SPIFlash
Also added a basic usage example under the library.

The All-About-Moteino page describes how you can add a flash chip to your Moteino or even to your Arduino. To access this chip you will need a library such as this one to conveniently read or write bytes to the chip. I would recommend getting used to the chip itself by doing some reading in the datasheet of the chip you are using – there are some particularities as to how these chips work. The library attemps to abstract most of these things so you don’t have to worry about them. At the very least please read the comments in the code for now. Soon I will hopefully add more info and tutorials. Stay tuned for the complete solution code for wireless/in-field programming of Arduino/Moteino using this library. I am working to get all that code organized and posted on this blog.

RFM12B library

Posted on by

I’ve been using the RF12 library from Jeelabs for some time for my Moteino testing. This worked just fine and it was a great starting point. However some things were really confusing and I spent a lot of time redoing the same thing over and over again (eg. copy paste from known working code) just because there was a lot of code-overhead to do simple things like sending, receiving, and ACK management, and of course I couldn’t remember any of the functions or macros. Right from start, the need emerged to tweak it into a more flexible and more configurable library, so I kept hacking and modding it until it dawned on me… a new library had to be born. So I decided to completely rewrite it, and wrap the useful functionality in a dedicated C++ class. I modified some of the core features of the Jeelabs version, like adding another header byte to allow 7-bit source and destination addresses (Jeelabs only supports either source or destination in an attempt to save 1 byte), and allow low level configuration of the radio. This yielded a clean and easy to use, yet powerful library (at least it made my life easy). Here’s a summary:

  • easy API with a few simple functions for basic usage
  • 127 possible nodes on 256 possible networks
  • 66 128 bytes max message length
  • customizable transmit power (8 levels) for low-power transmission control
  • customizable air-Kbps rate allows fine tuning the transmission reliability vs speed (transmitting slower is more reliable but takes more time which implies more power usage)
  • Sleep/Wakeup functionality for power saving
  • Low battery detector with customizable low voltage threshold
  • Interrupt driven
  • Support for targeted ACK instead of broadcasted ACK (possible because of the new source byte in the header)
  • encryption with XXTEA algorithm by David Wheeler, adapted from http://en.wikipedia.org/wiki/XXTEA
  • Support for these chips: ATMega8 family (ATmega168, ATMega328) ATMega2560, ATMega1280, ATMega644P, ATTiny84, ATTiny44, ATMega32u4. So far only tested on ATMega 328/P
  • The source code and examples are on GitHub: RFM12 Library

Continue reading →