RF Bitbanger ported to Raspberry Pi

RF Bitbanger on Raspberry Pi

A rather simple way to control electrical lighting could be accomplished with wireless remote control plugs and a small 433 MHz transmitter module connected to your Raspberry Pi.
RF Bitbanger is using a lirc_serial style bitbanging kernel driver (rfbb) on top of GPIO, together with a small utility (rfbb_cmd), to control remote switches such as the Nexa/Proove/Sartano plugs.

See https://github.com/tandersson/rf-bitbanger for additional details.

Raspberry Pi with 433 MHz Tx module for RF Bitbanger.

rpi_tx433_lores.jpeg (59.31 KiB) Viewed 9592 times

An activated remote plug using Raspberry Pi, rfbb, rfbb_cmd and a 433 MHz TX module.

plug_lores.jpg (50.29 KiB) Viewed 9592 times

So you buy a TX433N, connect it to a GPIO, do some software stuff, and you can control devices via 433.92 Mhz?

If so ... Ouch! See what I've done:

viewtopic.php?f=37&t=11280
http://eva-quirinius.blogspot.nl/2012/0 ... ights.html

I had thought before of connecting the Raspi directly to the RF transmitter, but I thought the GPIO module was too un-realtime to control it correctly.

BTW:

I reverse engineered the keyboard and dip switch of my remote control, and this is the logic:

the DIP switch drives A0 - A4
switch A, B, C or D drive A5 - A8
"On" resp. "Off" drive A10 resp A11

Does that mean I can write 00000 - 1000 - 10 to the TX433N, and Switch A will go to on?

EDIT:

Is the price of the TX433N around 9 - 10 Euro? FWIW: My complete Elro set (1 remote controller with a TX433N-like built in, 3 switches) costed ... 15 Euro.

Additonal question:

I'm tryting to compile the rfbb from github, but the make gives an error. I must say I don't understand the "KERNELDIR=~/linux", as I have no ~/linux directory.

So, what should I do to get the kernel modules rfbb etc compiled?

Code: Select all

pi@raspberrypi ~/AanUit/rfbb $ git clone https://github.com/tandersson/rf-bitbanger.git
Cloning into 'rf-bitbanger'...
remote: Counting objects: 62, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 62 (delta 18), reused 52 (delta 8)
Unpacking objects: 100% (62/62), done.

pi@raspberrypi ~/AanUit/rfbb $ cd rf-bitbanger/rfbb

pi@raspberrypi ~/AanUit/rfbb/rf-bitbanger/rfbb $ make KERNELDIR=~/linux
make -C /home/pi/linux M=/home/pi/AanUit/rfbb/rf-bitbanger/rfbb   modules
make: *** /home/pi/linux: No such file or directory.  Stop.
make: *** [default] Error 2
pi@raspberrypi ~/AanUit/rfbb/rf-bitbanger/rfbb $


I had thought before of connecting the Raspi directly to the RF transmitter, but I thought the GPIO module was too un-realtime to control it correctly.

My experience is that it is too slow, but WiringPi is fast enough - viewtopic.php?f=37&t=10667

Bitbanger does seem a good way of working around these issues.

@Sander

the DIP switch drives A0 - A4
switch A, B, C or D drive A5 - A8
"On" resp. "Off" drive A10 resp A11

Does that mean I can write 00000 - 1000 - 10 to the TX433N, and Switch A will go to on?

Unfortunately not. You have to decode the actual protocol and implement it as a set of write calls to rfbb (high/low + bit length). The rfbb_cmd utility does this for NEXA/Proove/ARC switches using a protocol that is described here:
http://elektronikforumet.syntaxis.se/wiki/index.php/RF_Protokoll_-_Nexa/Proove_%28%C3%A4ldre,_ej_sj%C3%A4lvl%C3%A4rande%29

Is the price of the TX433N around 9 - 10 Euro?

I guess you can get it cheaper if you shop around. I bought my TX433N at Kjell & Company in Sweden for approximately 10 Euro. You might also be able to reuse the sender's TX circuitry, which could be more or less tricky, depending on the actual hardware.

I'm tryting to compile the rfbb from github, but the make gives an error. I must say I don't understand the "KERNELDIR=~/linux", as I have no ~/linux directory.

This is needed for driver compilation.
The KERNELDIR is where you put your compiled linux tree that matches the kernel that you use. If the kernel headers package had been available (I don't think it is at the moment), you could install this instead. The slow route (at least 6-8 h) is to clone the source code of the distro's kernel to your target, build the kernel, and change the KERNELDIR path to where your linux tree is. However, I guess that you can find additional and better information on how to compile kernel drivers in other parts this forum.

First of all: sorry for my late reply. I thought I would get a mail in case of a folluw-up, but apparantly not.

I've bought this 433 Mhz transmistter: http://www.sparkfun.com/products/10534 . Quite cheap, and it works on 3.3 V (the Raspi GPIO's voltage, right?).

I've got an Elro set. I think Elro is a Dutch brand. I will try the rfbb_cmd to see if it works (as soon as I have the hardware, and rfbb running).
I already used a scope to sample the communication from the HX2262 to the 433Mhz transmitter. Hopefully that will be useful to mimic the protocol.

About compiling: I'm an long-time Ubuntu *user*, not a kernel hacker. I searched this forum, but compiling modules and/or a kernel is too complicated for me.

So: Is there any other way to get the rfbb.ko for my Debian Wheezy? Maybe someone uses Debian Wheezy too and can run the command to compile the module?

Quite cheap, and it works on 3.3 V (the Raspi GPIO's voltage, right?).

Yes.

I already used a scope to sample the communication from the HX2262 to the 433Mhz transmitter. Hopefully that will be useful to mimic the protocol.

Try to get hold of the data sheet for the IC. It could be similar to PT2262 and SC2262. That could make the process easier!

So: Is there any other way to get the rfbb.ko for my Debian Wheezy? Maybe someone uses Debian Wheezy too and can run the command to compile the module?

Send me a PM.

I've got an Elro set. I think Elro is a Dutch brand. I will try the rfbb_cmd to see if it works (as soon as I have the hardware, and rfbb running).
I already used a scope to sample the communication from the HX2262 to the 433Mhz transmitter. Hopefully that will be useful to mimic the protocol.

I have now ported the Sartano protocol to rfbb_cmd. It might be the same protocol as the Elro set. Tested OK with my Brennenstuhl RCS1000R switch based on HX2272 decoder set to system-code 1 and receiver A.

Code: Select all

./rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 1000010000 -l 1


Two things:
a) the HX2262/2272 is 100% compatible with the PT2262/2272, so the software should work.
b) the protocol has been analysed by countless people for Home Automation with the Arduino. The best library to my knowledge:
https://bitbucket.org/fuzzillogic/433mh ... /wiki/Home
A brief description of the protocol can be found here:
http://bertrik.sikken.nl/433mhz/index.html

A brief description of the protocol can be found here:
http://bertrik.sikken.nl/433mhz/index.html

Thank you! At the moment you posted this, I was analyzing the Elro protocol with a logic analyzer. It certainly resembles the "Remote controlled wall socket" on that URL you gave.

I use the library I linked with my arduino and the same ELRO sockets you have got. Works like a charm. The library comes with an analyser that will print on the serial port what code a key pressed on the remote has.

If you want details on the protocol, you will find it on pages 4 to 6 in the following PDF:
http://www.princeton.com.tw/downloadpro ... 2262_1.pdf

If you can post code of how you use the ELRO sockets with the Raspberry Pi, I'd be interested. I will try the Bitbanger at some stage (and possibly monitor it with my Arduino), but that may well be in 3 months time...

Try to get hold of the data sheet for the IC. It could be similar to PT2262 and SC2262. That could make the process easier!

My Remote Control uses a SC5262S IC - the Datasheet (http://www.alldatasheet.com/datasheet-pdf/pdf/116104/SILAN/SC5262S-RF.html) looks like the one of the PT2262.
So are my RC-Wall Plugs compatible to RF-Bitbanger?

About compiling: I'm an long-time Ubuntu *user*, not a kernel hacker. I searched this forum, but compiling modules and/or a kernel is too complicated for me.

So: Is there any other way to get the rfbb.ko for my Debian Wheezy? Maybe someone uses Debian Wheezy too and can run the command to compile the module?

I've never did something like this before, but here is how I got it to compile (CrossCompiling on my Ubuntu 12.04 ofcourse):
It's basically just this http://elinux.org/RPi_Kernel_Compilation

Code: Select all

sudo apt-get install gcc-arm-linux-gnueabi make git-core ncurses-dev
mkdir raspberrypi
cd raspberrypi
git clone https://github.com/raspberrypi/linux.git
cd linux

Then I got my .config from my current Pi Image, direct on the Pi itself:

Code: Select all

zcat /proc/config.gz > .config

and transferred this file using MidnightCommander (mc) to the linux dir we switched in the code box above.

On the PC:

Code: Select all

make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- oldconfig
cd ..
git clone https://github.com/tandersson/rf-bitbanger.git
cd rf-bitbanger/rfbb

There I had to edit the Makefile (used nano for it)
I just added this before the line that starts with PWD

Code: Select all

ARGS += ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-

Then I called make like this

Code: Select all

make KERNELDIR=~/raspberrypi/linux

The rest of it should be analog to the Wiki Page (Final step: Making the 'kernel.img' for your Pi and Transferring The Image To The Raspberry Pi) and the ReadMe on Github (https://github.com/tandersson/rf-bitbanger)

I received my TX433N today.
After a bit bruteforcing with rfbb_cmd using the SARTANO protocol I found out how to use my Sockets
My Sockets (German Plug): http://www.conrad.de/ce/de/product/6464 ... ifeld-30-m

Similar Looking (UK Plugs): http://www.maplin.co.uk/remote-controll ... ack-348217

To turn the plugs on use the following commands:

Code: Select all

rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 1000100000 -l 1 ### I - 1
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 1000010000 -l 1 ### I - 2
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 1000001000 -l 1 ### I - 3
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 1000000100 -l 1 ### I - 4

rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0100100000 -l 1 ### II - 1
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0100010000 -l 1 ### II - 2
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0100001000 -l 1 ### II - 3
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0100000100 -l 1 ### II - 4

rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0010100000 -l 1 ### III - 1
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0010010000 -l 1 ### III - 2
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0010001000 -l 1 ### III - 3
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0010000100 -l 1 ### III - 4

rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0001100000 -l 1 ### IV - 1
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0001010000 -l 1 ### IV - 2
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0001001000 -l 1 ### IV - 3
rfbb_cmd -d /dev/rfbb -i RFBB -p SARTANO -c 0001000100 -l 1 ### IV - 4

ABCD1234XX
0000000000

To turn them off you just have to replace the -l 1 with -l 0
It doesn't make a difference if you change the last 2 digits of the 10 digit code. The socket still turns on/off

Hello fabi280,

you seem to be German, correct? Could you write me a PM (unfortunately I just registered and can't send PM's)

Just found out that the NEXA protocol works fine for the Dutch "Klik aan klik uit" or "KAKU" system.
That is, for the old-fashioned version with the two dialing wheel at the back.

After compiling and insmod-ing the rfbb.ko driver I now would like it to be loaded after a reboot Including the making of the /dev/rfbb device.

Any hints on how to do that?

Users in the United States might try using the USB connected X10 CM19A pictured here:
http://www.x10.com/products/x10_cm19a.htm
with the Python X10 remote control script from this site:
http://m.lemays.org/projects/x10-cm19a-linux-driver

I think it might work with the Raspberry Pi. I'm certainly going to try it (or something similar) as soon as I get my Pi.

After compiling and insmod-ing the rfbb.ko driver I now would like it to be loaded after a reboot Including the making of the /dev/rfbb device.

Any hints on how to do that?

Add your setup commands to /etc/rc.local.
If you need to switch your sockets on/off at regular intervals, crontab might be handy!

Sorry - I can't edit my "Tutorial" Post - but here is a much shorter version how to compile rfbb and load the module

Code: Select all

sudo apt-get install linux-headers-3.2.0-3-rpi
git clone https://github.com/tandersson/rf-bitbanger.git
cd rf-bitbanger/rfbb
make KERNELDIR=/lib/modules/3.2.0-3-rpi/build
sudo insmod rfbb.ko
sudo mknod /dev/rfbb c 252 0
sudo chown root:dialout /dev/rfbb
sudo chmod g+rw /dev/rfbb

Note: It should work. I didn't have the chance to try the compiled module yet

Has anyone got this working with this wall socket?


I've seen some people making it work with arduino.. I also found the codes for this sockets but I don't know what to do with them, since the ones that bitbanger accepts are a lot different..
http://linux-utils.blogspot.pt/2011/08/ ... hacon.html

Hey,

thanks for Bitbanger and your advice howto compile the driver

when I try to

sudo apt-get install linux-headers-3.2.0-3-rpi

I get this error

E: Unable to locate package linux-headers-3.2.0-3-rpi
E: Couldn't find any package by regex 'linux-headers-3.2.0-3-rpi'

so if anybody know where i can get the package ?

i already upgrade the Kernel and the Firmware but the only Kernel Headers i can find are armhf but i need the armel.

Which image did you use ? The one from RPi Homepage ?

greets Preemo

So you buy a TX433N, connect it to a GPIO, do some software stuff, and you can control devices via 433.92 Mhz?

If so ... Ouch! See what I've done:

viewtopic.php?f=37&t=11280
http://eva-quirinius.blogspot.nl/2012/0 ... ights.html

I had thought before of connecting the Raspi directly to the RF transmitter, but I thought the GPIO module was too un-realtime to control it correctly.

You are right that a multitaking OS is not first choice for producing such waveforms in realtime, but it can do it. One thing I noticed was that as you drop down to a pulse width in the hundreds of microseconds there was an error creeping in. In my case this was a constant of around 90 microsseconds extra. So a 430 microsecond pulse would typically scope at around 520 us. This delay is likely to because by the sleep routine I was using (nanosleep) which needs to call into the kernel.

For my implementation of internet controlled mains sockets (http://www.mhr.me.uk/projects/RemotePowerRpi.html) I introduced a constant offset in the code so that I arrived at the right pulse widths. This was not ideal but worked. A more precise outcome could have probably been achived using NOPs instead of delay(), but actually I had no operational problems with the pulse width generation so saw no reason to change it in the prototype.

Hey,

thanks for Bitbanger and your advice howto compile the driver

when I try to

sudo apt-get install linux-headers-3.2.0-3-rpi

I get this error

E: Unable to locate package linux-headers-3.2.0-3-rpi
E: Couldn't find any package by regex 'linux-headers-3.2.0-3-rpi'

so if anybody know where i can get the package ?

i already upgrade the Kernel and the Firmware but the only Kernel Headers i can find are armhf but i need the armel.

Which image did you use ? The one from RPi Homepage ?

greets Preemo

I can find the Package. Works on Raspbian.

Code: Select all

root@raspbmc:~# apt-cache search linux-kernel-headers
linux-libc-dev - Linux support headers for userspace development
root@raspbmc:~# apt-cache search linux-headers
linux-headers-2.6-mx5 - Header files for Linux mx5 configuration (dummy package)
linux-headers-2.6-omap - Header files for Linux omap configuration (dummy package)
linux-headers-3.2.0-3-all - All header files for Linux 3.2 (meta-package)
linux-headers-3.2.0-3-all-armhf - All header files for Linux 3.2 (meta-package)
linux-headers-3.2.0-3-common - Common header files for Linux 3.2.0-3
linux-headers-3.2.0-3-rpi - Header files for Linux 3.2.0-3-rpi
linux-headers-mx5 - Header files for Linux mx5 configuration (meta-package)
linux-headers-omap - Header files for Linux omap configuration (meta-package)
linux-headers-vexpress - Header files for Linux vexpress configuration (meta-package)


Although I've never tested the Kernel Header Method. Only compiled the whole kernel on my own.

Hey thx for the wuick reply,
I tried it with the Debian Wheezy Image, will try the Raspberian Image.
greetz Preemo