RF wireless kernel module for Raspberry Pi, BeagleBone and others


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.


  1. qwerty says:

    Kernel driver aside, which is a great thing, what’s so special about this module? I see there are cheaper ones on ebay and other online vendors.

    • saw0 says:

      From what i understand,without a Kernel Driver you would need a external MCU or LogicIC for the cheap RFs for the embedded Linux Boards like the Pi

    • NsN says:

      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.

    • Bogdan says:

      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.

  2. truthspew says:

    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.

    • 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.

  3. Dojo says:

    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.

  4. DeKay says:

    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.

  5. Old'un says:

    Frequencies, not bandwidths…

  6. lwatcdr says:

    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.

  7. someone says:


  8. Alex says:

    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

  9. George says:


    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)?.


  10. George says:

    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!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s