Currently I’m working on a project communicating and transmitting signals over the air with an 433 MHz radio module called “rfm12“, produced by HopeRF, soldered onto devices capable of running OpenWrt and having at least 3 accessible GPIO’s.
Short story long:
These radio modules are capable of sending / receiving over the ISM frequency band, as e.g. 433 MHz or 868 MHz and just cost about 5 Euros.
The idea was to get the module working on several embedded boards running Linux, e.g. routers, microcomputers such as the NanoNote, etc. via a generic software interface.
The rfm12 module is controlled via the 4-wire protocol SPI which basically is based on toggling pins between the machine’s logic-levels (high/low) at an individual non-specified clock-speed (http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus).
Since most of mentioned boards do not own a native SPI bus, but several GPIO’s (most LED’s are connected via GPIO’s on such devices), SPI can be “emulated” by toggling these GPIO’s in a specific way (also called “bitbanging“).
That way there’s no need for any other electronic peripherals such as microcontrollers, semiconductors, resistors, etc. – the chip is directly connected with the board – everything is done in software.
Inspired by the project “ethersex” – a project programming and maintaining a software for Atmel AVR micro-controllers used for home- / building automation – and an approach of soldering the module onto a specific router, communicating via SPI over GPIO’s (however used code is rather old, unmaintained and board-specific) – the idea came up to write a generic linux kernel module to support the module from within linux directly.
Based on the ideas realised with the ethersex project, I decided to aim my project on being able to switch remote controlled power sockets of which I own several (to each other incompatible) modules.
Because the rfm12 module is (only) capable of doing FM (modulating payload data on top of the frequency), but lot’s of devices are controlled via AM (most remote controlled power sockets included), we emulate AM by simply turning the module on and off in a specific sequence.
Since this operation is timing critical and needs to be atomic, we need to do basic stuff in the kernel space rather than from userspace.
The whole project is going to consist of 4 major parts:
- the rfm12 driver as kernel module which provides an API (accessible via a character device) to the userspace
- an userspace library which contains all the information and protocol (meta)data for such remote controllable devices, providing an (more or less) generic interface and configuration of devices
- an actual application using the library, so controlling the devices – maybe exporting the available functions via RPC (json, xml, etc.) to provide network access
- a remote usable UI (for mobile devices as phones (android/meego), web-related, qt/gtk…)
My testing device is an old Netgear WGT634U I had in spare which has a broadcom 47xx SoC working in and 4 unused GPIO’s available.
Implemented yet is support for the most common radio controlled sockets sold – the ones which have a 2272/2262 IC built in (including these Chinese versions which get on fire – http://ec.europa.eu/consumers/dyna/rapex/create_rapex.cfm?rx_id=142 #25) and the ones using an P801B chip.
I also have a set of radio controlled dimmers which protocol I’m going to implement soon…
For now the source code is hosted on github: https://github.com/mirko/rfm12-ASK-for-linux – there’s no project site yet but will be created if the project is growing / interest is getting raised 🙂
UPDATE: In case you’re willing to participate, you’re more than welcome! Just drop me an email… There’s lot’s of stuff I’d like to see implemented, especially usable (G)UI’s… but for sure it’s not just about me: patches, feedback, enhancements and feature-requests (in a certain extent) are highly appreciated!
9 replies on “RFM12 under Linux and remote controlled power sockets”
If you would use the RFM12 to transmit data to another RFM12 unit, I would have suggested the RFM22, as it has less bugs and does more on its own.
I’m aware of the bugs the RFM12 has and it almost did drive me crazy, however since I’m using just a fraction of it’s functionality (no interrupt handling, no bidirectional communication, no FIFO handling – but just turning the module on and off in a sequence) I guess it could have hit me even harder).
Still the RFM12 is used in quite some projects and therewith there is at least some known-to-work example code available (e.g. the ethersex project) which helped me a lot.
Also the RFM22 is quite unavailable in Germany (at least all the shops I visited only had the RFM12(B) – if at all).
lynx-dev.com is a quite stable source in Berlin for these.
[…] the Ben NanoNote (ingenic JZ47XX) allows us to put the microSD pins into GPIO mode, so we can (as already done for the first device, the Netgear WGT634u router, I connected an rfm12-module to) create and export an SPI bus on top of them to be able communicating with the module. rfm12 module […]
So you are turning the radio on an off in order to transmit serial data, not using any of the features inside?
Maybe you should, it would give some advantages…
As I wrote inside the article, the sockets expect AM (amplitude modulation) – not FM (frequency modulation).
The latter one (FM) is handled in hardware, the former one (AM) not – so it’s done in software (sort of PWM).
[…] a Linux kernel, and that it have a few GPIO pins available. One example is fairly straight forward, a Netgear router. Many, if not most routers run a Linux kernel natively and most have solder points on the board for […]
What/how did you connect the rfm12 to the gpio pins?
[…] and wirings between the rfm12 modules and GPIOs of the devices providing them (in my case the Netgear WGT634U router / the Qi NanoNote) I’d like to try making some things […]