Kernel hacking for the RFM12B

RFM12BI’ve been busying myself with fixing up and adapting the RFM12B Linux driver. My first thought was simply to give people support for sending and listening for OOK signals as an extension, then taking the device support in the rtl_433 decoder to extend RFM12B driver to include lots of OOK device support for things like weather stations and energy monitors.

JeeLib already does most of this work on Arduino so for the most part this is simply a matter of joining lots and lots of code together from different places and making sure it sits right. I’ve decided that in order to do this it would probably be better to re-write the driver while trying to fix some of the original driver’s TODO list along the way.

The driver will loosely allow :-

  • Compatibility with the original RFM12B driver & original JeeLib compatibility.
  • Send OOK, FSK messages to devices.
  • Listen for OOK, FSK messages from devices.
  • Set tuning to a specific frequency.

As far as hardware support is concerned, there are currently 2 distinct branches for hardware support on github :-

  • Raspberry Pi, Pi2, beaglebone.
  • Gumstix

I’ll work on merging these branches so support for all boards is in one place. I think that adding support for other boards is fairly trivial and as I’m following a similar design ethos in code as the original RFM12B driver. It should also be easy to add support for other hardware over time.

I’ll add support for other RFM boards over time too, as there have been some slight improvements in the more modern HopeRF components, I don’t think that much has changed though but always best to test the latest devices.

One final component of putting all of this stuff together is to implement a learning capability in an SDR for the 315, 434, 868, 915 bands. I think the idea would be to have something which tunes to the band, listens wide enough to catch signals, isolates them and decodes them. This kind of thing will allow you to zone in on any RF hardware which operates on those bands and then replace the controllers or receivers with a Raspberry Pi. Then together with the power of the internets build up a library of recognisable signals which can be shared online. The RF remote version of LIRC I guess. LRFC Perhaps?

The trouble of course is how to represent this in the kernel, and how to change modes appropriately. It all depends on how much is user space versus how much is kernel space. There’s a fine line between asking the hardware to do something, and asking the kernel driver to do everything. For the most part the device control will simply be a matter of sending an ioctl call to the driver, then reading from or writing to the device file.

[auction-affiliate tool=”lister”]