RF Wireless Kernel Module For Raspberry Pi, BeagleBone And Others

rfm12b-kernel-module

If you’ve done any wireless work with hobby electronics you probably recognize this part. The green PCB is an RFM12B wireless board. They come in a few different operating bandwidths, the 433 MHz is probably the most common. They’re super easy to interface with a small microcontroller but what about an embedded Linux board? That is the focus of this project, which builds a kernel driver for the RF module.

You can get your own RFM12B for a few bucks. They’re quite versatile when paired, but a lot of inexpensive wireless consumer goods operate on this band so the board can be used to send commands to wireless outlets, light fixtures, etc. [Georg] has been working with the BeagleBone, BeagleBone Black, and Raspberry Pi. His software package lets you build a kernel module to add an entry for the device into the /dev directory of a Linux system. So far the three boards listed are all that’s supported, but if you have five I/O pins available it should be a snap to tailor this to other hardware.

Wondering what else you can do with the setup? This will get the receiving end of a text-messaging doorbell up and running in no time.

21 thoughts on “RF Wireless Kernel Module For Raspberry Pi, BeagleBone And Others

    1. Compared to pure RF transcievers these modules have a few neat features.

      Most importantly, they take care of the low level RF stuff. This way you just have to push / read the data bytewise per SPI and in the mean time you can do other stuff.

      Most of the cheaper modules require you to directly set the signal state. This means that you also have to take care of timing, coding, matching a preamble and that you have to continously listen. On the other hand, this gives you a lot more flexibility as well.

    2. You might also think of the 2.4GHz ones, like the NRF24L01. The RFM12 has some advantages and disadvantages over this one: longer range but lower data rate, no automatic packet handling, harder to block by standing near it (the 2.4GHz is easily blocked by standing close to the receiver), easier to find at big vendors etc.

      I am a bit skeptical about the PI servicing the interrupt fast enough to get data one byte at the time when the CPU load is high…. Maybe a RFM23 would have been better? It has a 64B fifo, which could store an entire packet. They are about 30% more than the RFM12 with a lot more features.

  1. I’m constantly pondering the fact that 433MHz is right smack in the licenses amateur radio bands. I know I had to go through this with TI to get my Chronos watch, had to provide my amateur radio license. And according to the 70cm band plan, 433MHz is right where repeater inputs start.

    1. I beg your pardon! 433MHz is also part of the ISM band. Where are you located, that you needed to go through that insanity? Its legal in Europe, although the band next to it, 868MHz is also used by ISM hardware. As for the Chronos Watch I might get one if I found a use for the thing.

  2. 433MHz is legal for ISM use in europe. I tend to use the 868MHz ISM band (which is primary ISM) to not disturb amateur radio. Some repeaters have very stupidly been assigned an input frequency on the same channel car remotes operate, so you sometimes hear one being repeated if someone else is talking and has keyed up the transmitter.

  3. This is really great. Previous attempts to get this working from user space have failed because the small FIFOs on the RFM12B resulted in buffer underruns and the like. I just wish the 12B had a programmable sync word so it could interoperate with my CC1021 based weather station.

    1. You might like to look at “FIFO and Reset Mode Command” and “Synchron pattern Command” for the RF12; have no idea if the kernel module in question exposes these… I’m no expert but I’m pretty sure you can program at least the first eight bits of the sync pattern; if you use 16 bit sync word, I would have to resort to a test instrument to check the other eight, documentation is pretty vague on that.

      The RF12 is pretty flexible within it’s limitations – the next question is what documentation do you have about the modulation scheme for that weather station (…)

  4. Nice that their is a driver for this but has Linux actually put in an SPI driver at the kernel level yet. Seems like a good idea to me with all the embedded work going on.

  5. Hi I have a few toys laying and some good batteries I also have a spare airhogs action replay ready for scrap parts with a spare rf board from a controller for the ps3

    The helicopter has ir and I will be desoldering almost everything to make a wind generator to charge some batteries and am wondering if I can gather information somehow and keep a log of how much power I gain

    I would like to put in the right direction

    So if anyone can help I would be very happy to have taken a step closer Sent from my iPhone

  6. Hi,

    Your video is really helpful to me that I m currently working on interfacing CC1101 module on RasPi. I m wondering which pin did you connect on RasPi with nSEL(chip select)?.

    Thanks!

  7. Hi Man, Your code is very helpful for me to build a similar driver of CC1101 for raspi, But I have a problem with spi_sync during the setup function, once it was executed, the kernel was crashed and go to kdb for a kernel panic. Just wonder have you ever experienced the kernel panic by spi_sync? Thanks!

  8. Hello guys, I see that you have been playing around with rfm12, I have just bought an rfm69pi and was wondering what modules and piece of software to use to get data from 433mhz magnetic door sensors, I am trying to build a simple alarm system …any suggestions where to start?thanks

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.