Several shops offer cheap 433Mhz RF remote controlled switches. These are nice, but they introduce a few problems as well:
- The cheap ones all have different remote controls, using different protocols;
- We want to control our light switches from our PC, not from the remote controls.
What if you could use a PC to transmit all the RF signals to switch on- and off all devices, and have that PC learn the signals from the remotes? As it turns out, this is very easy to do. Most of these remote control devices use a digital serial protocol of about 1kbaud superimposed on the 433 Mhz signal. That 1kbaud falls well within the range of what a PC sound card can generate or sample. Furthermore, receivers that extract the digital signal and transmitters that turn the digitial signals into an RF signal are readily available.
This page describes how to create an absurdly low-cost USB 433 Mhz transceiver that can serve as a good starting point for your home automation projects.
Before you read any further: the hardware described below is really a very dirty hack and users have reported problems with noise on the input of this device. A more thought-through piece of hardware that does essentially the same thing is described on Avians blog (thanks for your comment Avian). You could first try the hack described below, and if that doesn't work consider Avians approach...
To build this, all you need is a 433Mhz transmitter/receiver pair (or 315 Mhz if appropriate in your country) and a usb audio-"card" (links are to ebay search results). All in all, with the ever decreasing prices for these devices this is about $2,- in materials. Now give yourself a dollar for the soldering work that is about to happen.
Next: some soldering. The result will surely not win any beauty contests and may constitute criminally inhumane treatment of innocent electronics (AKA 'CITIE', AKA 'hack'):
Receiver (top) and transmitter (bottom) soldered to a USB audio card
Obviously, we need to connect the transmitter to the audio output and the receiver to the mic input. The wiring is as follows for the transmitter (see this page for terminology). Bold words refer to pins on the transmitter:
- GND is connected to the sleeve contact on the socket.
- data is connected to the tip contact (left audio channel)
- Vcc to USB 5V, the red wire in the picture.
For the receiver:
- GND to sleeve
- Vcc to USB 5V, red wire
- RxD to tip (for mechanical stability only) and to a bypass (orange wire).
The RxD connection takes some explanation. These USB sound cards have a mic input connector which normally routes the signal throug a high pass filter. Since we want the 'raw' data from the receiver without filtering, we need to bypass that filter. Again, this is not too difficult: we need to find the filtering capacitor. The capacitor in question is found with a volt meter by looking for one that is directly connected to the input (the tip contact). This is the capacitor we need to bypass, and in this particular case I've done it by soldering a wire from the tip connector to the other side of the capacitor.
Note that the exact capacitor to bypass will vary from one soundcard to another. I have found two variations in two different batches bought on ebay. you should definitely look for the right capacitor using the multimeter method.
Also note that you can still get a decent signal without bypass, i.e. by connecting the receiver input to the mic input line. You'll notice that the high-pass filter will push the signal "downwards" to become symmetrical around zero.
Learning remote control signals
After connecting our Frankensteinian contraption, our PC will have another audio 'card'. Mine identifies itself als "Generic USB Audio Device". This device can now be used to record remote signals as if they were audio and to play them back as audio files as well.
I use Audacity to record keystrokes on the remote. It's as easy as pressing the Record-button in Audacity, pressing the key that we want to record on the remote and then pressing the stop button. You should see that Audacity has recorded a few repetitions of the same sequence—the image above zooms in on two such repetitions. You can now verify that the signal was correctly recorded by playing it back to our contraption. The switch should behave as if you pressed the key on the remote. Playing back only one occurrence of such a sequence usually doesn't work, so I try to find the minimum amount of repetitions that reproduce the switching behaviour. Then I save those repetitions in a single wav-file. Now repeat the procedure for the other keys of a remote and create a wav-file for each key. You should end up with wav-files with names like onA.wav, offA.wav, onB.wav, etc.
If you don't like to spend time on configuring existing home automation software and just want to switch something from a command line or script, you only need a command line audio player that is capable to play your sounds to a given audio card. On Windows, vlc might work (I haven't tried). On linux with ALSA installed, aplay fits the bill exactly. In your script, call aplay with the name of the keystroke-file and specify the soundcard, e.g.:
aplay -D plughw:2,0 onA.wav;
Fun project: The script below—when run in the background—will switch off a light when my Ubuntu (gnome) screen saver locks the screen and it will switch it on when I log in again. The light is a halogen spot that lights up the wall behind my monitor...
dbus-monitor --session "type='signal',interface='org.gnome.ScreenSaver'" | (
if echo $X | grep "boolean true" &> /dev/null; then aplay -D plughw:2,0 offC.wav;
elif echo $X | grep "boolean false" &> /dev/null; then aplay -D plughw:2,0 onC.wav;
Integration with home automation software
Instead of writing all the home automation software ourselves, we'd rather create a plugin to integrate this hardware with existing home automation. There seems to be no real widespread, open (and programming language agnostic) protocol for home automation devices (this appears to be a general issue with the internet of things). There is an open protocol though, which is xPL and there is a home automation suite that supports it, domogik. Therefore it seemed like a good idea to implement an xPL bridge for our contraption, and that is exactly what we've done. The source code for our xPL bridge is available on GitHub. This bridge is a small program that runs on linux only (think Raspberry Pi/Beaglebone) and that listens to X10 commands from an xPL hub. This is fairly easy to set up with domogik and it works, as can be seen in the short video below.
16 September 2013 22:27:43
You sir, redefined 'genius'. Well done.
10 December 2013 14:33:46
This is probably the best way to start with home automation. There are alarm systems that use these cheap sensors that work on 433mhz, from PIR, through smokede detectors, window/door openning sensors, tilt sensors , flooding sensoers etc etc :-) Just ordered all parts - great idea / post!
10 December 2013 19:46:52
Thanks! I noticed some interest from home automation folks (Domogik specifically), so yesterday I decided I'd go and try to make a linux xPL implementation for these devices. It'll take some time before anything is done though, working my way through ALSA documentation.
14 January 2014 09:31:53
I have been looking for a simple method to transmit to a PT2272, I was going down the SDR route, but this is simple and elegant, requires no reverse engineering, no GNURadio - 3 bucks in parts - excellent hack!
20 January 2014 21:24:11
Can this be used as a cheap replacement for RFXCOM RFXtrx433 or TellStick Duo to receive data from ex. a weather station?
20 January 2014 23:00:48
I'm not familiar with the RFXCOM or TellStick products, but theoretically, yes. Note that the cheap receivers on ebay are typically not such high quality (transmitters are reasonable), which is fine if you're just using them to record a remote control, but not if you're trying to receive signals from a weather station outside. You should really move to the $8 price point for a receiver with a crystal. The other thing is software: I assume that these products come with some pre-bundled protocols for different systems. For the devices on this page you're on your own (or maybe a bit less once I finally finish the xPL bridge).
23 January 2014 15:41:15
Wow, very smart project!
May the same procedure (soldering and recording-replaying) be working with an arduino IR kit, too?
I wonder if there is a simple and resource friendly way to convert, store and replay the signals - those seem to be binary. If I find out some answer I'll post it here.
24 January 2014 00:35:10
Most arduino IR kits I see are passive only: they have a sensor, but no way to transmit signal from the arduino/usb soundcard. But in essence, yes, this could be done for IR as well as long as you have a way to translate the IR signal into a voltage on the input and to translate a voltage at the output to an IR-output. The signals are indeed binary: officially it is "amplitude modulated", but the amplitude is always either 0 or max. I think that a good compact way to store signals may be the way LIRC (www.lirc.org/) does this: First the waveform for a "1" and for a "0" symbol is described (in terms of how long the signal is up and how long it is down) and then each signal is described as a series of 1s and 0s, binary encoded.
8 June 2014 02:49:24
I am interested in making a wireless audio connection between an xlr dynamic microphone and a 3.5mm plug for input into a camera or computer.
Could one use the principles you have shown here to use a usb sound card to take some audio, convert it into a digital stream,. One would then tap this and feed it into the wireless transmitter. The stream would be received by the digital receiver and converted into audio by another cheap usb sound card.
Could this be done?
cheers Peter email@example.com
9 June 2014 18:02:53
Danny deleted this comment on Mon, 09 Jun 2014 20:34:55 +0000
9 June 2014 18:05:40
Hello! Show please read more connection cards.
9 June 2014 20:43:59
Erhm. Digitizing an analog audio stream is exactly what the ebay-bought usb devices do. On the cheap 433 Mhz transmitters you could reach a maximum bitrate of about 1000 bps. This is barely enough to send encoded speech.
14 June 2014 23:11:45
I'm not sure I understand what you're asking. Do you want to see more connection diagrams? Trouble is that connections may differ for each USB sound card. Most connections are obvious and direct (audio out to transmitter data, 0V, 5V). The only non-obvious connection is between the receiver data line and the "bypass".
You can actually start by connecting the receiver data line to the microphone input. This should work, but does not give the nice square input signals as shown in the audacitiy picture above. The way to get unfiltered input signals is by using a multimeter to find the capacitor that is directly connected to the mic input and bypassing that one.
27 July 2014 21:39:18
Could you probably point a particular (or more) "$8 price point... with a crystal" receiver on ebay?
I'm asking this because I've built the Frankenstein of the article, which is working great along the specifications (good to send, good for recording but not good for receiving), but I'd like to step level towards receiving. I've found many receivers however with better (?, -108/-112/-114/...dBm sensitivity) specs, but have not enough domain knowledge (euphemism; I am far from being an electrical engineer) to choose with confidence.
Thank you in advance!
27 July 2014 22:32:36
Ah, You caught me there... I'm also far from being an electrical engineer. Some buying advice is on this webpage:
However, that doesn't point you to any ebay results. I think the first ones you get when you search for "super heterodyne 433 ASK" are probably better, but I really couldn't tell you what kind of quality you'd be getting or if these are suitable at all. The following one has a "QC Passed" sticker, so it must be good right :-)
But again, I don't know if it is at all suited...
One of the first receivers I ordered from ebay happened to be one without the variable inductor (variable inductor ones are the low quality ones) and it was around the $8 price point. Unfortunately, this was more than 3 years ago, so it's not in my ebay history anymore...
21 August 2014 09:37:27
A while back I wrote a software decoder that decodes a lot of 433 MHz transmissions from remote controls, weather stations and such. I found it useful for exploring what's out there on this radio band. It should work fine with your hardware:
17 October 2014 13:44:58
Awesome guide and I thank you. However I get a LOT of static from the mic and can't record and transmit it since there are not real binary recording. I soldered a bypass from Mic+ to the + side of the capacitator of the mic and to RxD (Data on my reciever, I suppose). Any other way of creating these recordings?
17 October 2014 15:36:33
Sorry to hear that the receiving end doesn't work. In the mean time, I've discovered that on one of my PCs I get similar symptoms (not noise actually, but a persistent ~1Khz signal that seems to come from the PC itself). Can you try your contraption on another PC/laptop?
Avian (the commenter right above you) has spent some actual thought on EMI constraints and created a much cleaner device where he nicely filters the power supply. Maybe this would be an option for you:
24 October 2014 19:07:03
Hi, thank you for the tutorial! Everything works fine but the transmitter always "flood" the ether with some signal, so it's impossibile to use other 433 RF devices. Could you help me? Transmitter code FS1000A.
P.S.: Obviusly I'm newby :)
24 October 2014 20:12:06
Update: "some signal" perhaps could be the carrier... I've told you, newbie
24 October 2014 23:40:46
Other than your other 433 RF devices not working, how do you know it's flooding the ether? These devices are on-off keying, which means no carrier is sent if you offer a "low" signal to the transmitter's input. And even if you offer a high signal to the input, the carrier will stop after a few milliseconds. "Flooding the ether" with these devices can only be done, I think, if a high-frequency signal (a few Khz) is at the transmitter's input.
26 October 2014 07:38:14
Because when I turn on my hacked USB audio card other devices not working and when i turn it off other devices working
23 November 2014 13:18:06
I have a question regarding the frequencies. Some devices work with the frequency of 433.92 MHz. Are these two frequencies compatible? (433 and 433.92)?
25 November 2014 00:21:21
They have been for me. The transmitters on ebay are typically sold as "433Mhz" devices. The switches I control with them are marked "433.05-434.79Mhz" on one set. The other set was bought as a 433.92Mhz set.
15 December 2014 21:30:27
Thanks man, worked perfectly for me!
16 February 2015 18:39:14
How did you find the passfiltering capacitor with voltage meter? I'm quite noob with these things.
17 February 2015 00:23:13
I'm a noob as well :-) I found the capacitor by testing each side of each capacitor and finding the one that was directly connected to the tip (RxD in the crude schematic above) contact of the connector (zero ohms, or rather the one that "buzzes when you use the buzzer"). Then I bypassed that capacitor by soldering a wire from the tip to the _other_ side of that capacitor.
You should also be able to record some signal without that bypass wire, it's just that the signal will be pushed "downwards" to become symetrical around 0.
18 February 2015 17:18:03
Hi! Thanks for reply. I'm going to try this later but when I tried record I got something input even if I had not any devices on.
I' not sure if its real signal or my bad soldering. And sorry for bad English(not native language).
25 February 2015 15:01:55
Thank GOD I'm not the only one struggling with this! Not sure what's happening, but it almost 100% noise. It does record really really weak 433 signals, but it's not good enough to be useful. Tried it on desktop and laptop (no power plugged in), same result. Also tried to mount it with larger wires (20cm), no improvement. I'll gonna read that blog post and see if it's feasible to adjust. But great project indeed btw ;)