First, get one of these:
This the tuner chip that is used in digital TV that has been hooked to a USB interface and enclosed in a plastic case. The chip is a RTL2832 and has a huge bandwidth; it can be used to receive AM, FM, SSB, etc all the way up past the 900MHz range that the AcuRite transmits on. It's a fun device in and of itself and is the subject of blog posts all over the web. You can listen in to commercial flights, the cops parked at the corner watching your garage, even the doorbell transmitter in your neighbors house. I didn't want it for boring things like this, I wanted to get the rainfall count out of my 5n1 sensor set without using the console.
So, I downloaded a great tool for doing this kind of thing called SDRsharp and installed it on my laptop. After visiting several web sites that described how to use its features, and listening to the five or six FM stations I can receive out here, I went looking for the AcuRite sensor. I found it.
That's it, the spike that is showing on the capture. It took me a little while prowling around the spectrum to find it, but there it is, Oh ... wait ...
Notice in the bottom panel that there are three different signals that are on almost exactly the same frequency? Yep, I'm picking up three devices up in the 433MHz area and any one of them could be what I'm looking for. After a bunch of looking, it turns out the first one I found is the one I want, but how to I get the data out of it? Heck, how do I separate the one I want from the others?
This has already been solved for us under Linux by a tool called rtl_433. But before we talk about that, use SDRsharp to zero in on the frequency you need to use. There's a little drift between devices both at the radio and at the transmitter, getting the exact frequency reading will help you later. Write it down somewhere.
OK, I'm getting too technical without explaining what is going on. These little tuner chips were designed for digital TV and the description (stolen from here <link> is:
What is RTL-SDR?
RTL-SDR is a very cheap software defined radio that uses a DVB-T TV tuner dongle based on the RTL2832U chipset. With the combined efforts of Antti Palosaari, Eric Fry and Osmocom it was found that the signal I/Q data could be accessed directly, which allowed the DVB-T TV tuner to be converted into a wideband software defined radio via a new software driver.There's an entire web site dedicated to these little devices at http://www.rtl-sdr.com/ and another at http://www.rtlsdr.com that describes many of the uses people have come up with, so I won't go into it much more deeply.
Essentially, this means that a cheap $20 TV tuner USB dongle with the RTL2832U chip can be used as a computer based radio scanner. This sort of scanner capability would have cost hundreds or even thousands just a few years ago. The RTL-SDR is also often referred to as RTL2832U, DVB-T SDR, or the “$20 Software Defined Radio”.
Next, there's a Linux library that supports this and a really cool tool you can run on your PC to play around. The tool is called SDRsharp and has a dedicated website <link>; just go there and select the download link to get it. The screenshots above are taken from this tool
Now, before I get into describing how to use this on a Raspberry Pi, you should be aware that these little radio receivers pull a lot of power. When you plug them into the Pi, it will suck so much power that the Pi will reset and have to boot back up. If your power supply is not up to it, the radio won't work properly. A powered hub will help isolate the Pi from the high current, but isn't absolutely necessary if you power supply is strong enough and you don't mind it rebooting when you plug the receiver in.
The Linux library is called rtl_sdr and is at http://sdr.osmocom.org/trac/, but don't download it yet. Don't misunderstand, this is a nice tool, but not exactly what you want to read the AcuRite weather head. What you want is a tool called rtl_433 that was developed specifically to decode the various devices that operate in the same unlicensed frequency range. Things like temperature sensors, doorbells, full blown weather stations, etc.
There are a lot of blog posts out there on how to install the rtl_433 tool, but none of them worked for me. I had to actually follow the instructions as written in the readme file that came with it because the authors had recently added the general purpose library for SDR (software defined radio) when they found out it needed to be changed to help their tool work better. When I downloaded the zip file, I got it all. It took me about three days to figure that out and get it to compile and work. Then, when I went back later in preparation for this post, they had changed rtl_433 a bunch. I guess someone got a burst of energy and they updated everything in sight. They had gone back to installing rtl_sdr as a separate step and that would make things much harder.
I just created a new one under my login on GitHub. I really didn't like the idea of things changing every time I wanted to do something and using it for my weather station would depend on two projects out there that can change at any time. I tried to use the Git fork and other tools and got totally confused with the various methods of backing up in a respository; I guess my very own version isn't a bad solution.
There is a dependency on libusb though. If you've already installed my USB code that previous posts described, you've got that requirement already. If you haven't, you'll need to install libusb. Go to my post on this <link> and follow the part about installing libusb and libudev-dev. This is a USB device (of course) and is very, very similar to the code I created to read the console device.
Now you're ready to work on rtl_433, so just go to github and grab it <link> by clicking on the 'Download ZIP' button on the lower right. To build it though, they use a tool called 'cmake' that isn't on the Pi by default. Fortunately, it can be installed easily
sudo apt-get install cmake
Now you can (finally) just follow the instructions in the readme that comes with the library to build it. Don't do like I did and think I knew everything and install the rtl_sdr library and try to get it to link up properly with rtl_433; that is a path to almost terminal frustration. Just build rtl_433 from my copy. You'll probably want to rename it once you get it unzipped to something easier to type. Here's the commands I used to build mine:
cd Desert-Home-rtl_433-master mkdir build cd build cmake ../ makeNow, you are almost ready to actually read the RF from the weatherstation, but (another one of those) the decoder included with rtl_433 is wrong. I don't know if the author of that particular piece had the same kind of problems I did originally, but he made some of the same mistakes I did. So, I put together my own version that decodes my weatherhead and corresponds with the console. These changes are part of the zip file you downloaded; you don't have to do anything special.
The great thing about doing it this way is the weatherhead provides a checksum on the data. That means no more undetected short packets or weird data because something in the AcuRite console is messed up. It also means you only get the 5 sensors included in the weatherhead: temperature, humidity, wind speed, wind direction, and rainfall count. But, since I installed my own barometer <link>, and plan on building anything else I may need, that's good enough for me.
Just for completion's sake, here is sample output from my weatherhead:
pi@deserthome2:~/src/Desert-Home-rtl_433-master/build$ cd src pi@deserthome2:~/src/Desert-Home-rtl_433-master/build/src$ rtl_433 Registering protocol Rubicson Temperature Sensor Registering protocol Prologue Temperature Sensor Registering protocol Silvercrest Remote Control Registering protocol ELV EM 1000 Registering protocol ELV WS 2000 Registering protocol Waveman Switch Transmitter Registering protocol Steffen Switch Transmitter Registering protocol Acurite 5n1 Weather Station Found 1 device(s): 0: Generic, RTL2832U, SN: 77771111153705700 Using device 0: Generic RTL2832U (e.g. hama nano) Found Rafael Micro R820T tuner Exact sample rate is: 250000.000414 Hz Sample rate set to 250000. Sample rate decimation set to 0. 250000->250000 Bit detection level set to 10000. Tuner gain set to Auto. Reading samples in async mode... Tuned to 433920000 Hz. Detected Acurite 5n1 sensor wind speed: 2.0 mph, temp: 54.5F, humidity: 67% Detected Acurite 5n1 sensor wind speed: 1.5 mph, wind direction: NE, rain counter: 344, Detected Acurite 5n1 sensor wind speed: 1.5 mph, temp: 54.5F, humidity: 67% Detected Acurite 5n1 sensor wind speed: 1.5 mph, wind direction: NE, rain counter: 344,Notice how the build process put the files in the directory rtl_433/build/src/ ? I'm not responsible for that ... that was the way I got it. Just move them wherever you want them to reside at run time.
Remember way above I told you to write down the frequency you found the weather head transmitting on? This is where you may have to use it. If it drifted far enough, you won't get a good signal from the transmitter up on the roof or out in the yard. You can simply specify the frequency you want to listen to with the '-f' parameter like this:
rtl_433 -f 433.915e6
This means to set the receiver at 433.915 MHz. I actually use this number for my weather head.
There's still some stuff to be done from my perspective, I want to put some code in to present the data as a JSON string so it can be used exactly like I did in the other version. I also want to wait until I have both types of messages in hand before I output anything. I'll be doing that over time and moving to exclusively use the RF from the weather head. That will eliminate all the little irritations that the console entails. So, if you grab the code at some point down the line, there will be changes that reflect my specific use; if you want this particular version, the commit # in Github is 5c72e32 and you can get to it by clicking on 'Commits', then finding the number in the list and clicking on the browse next to it that looks like this <> . That will get you back through any changes to the level it was when I wrote this.
This will also make the Raspberry Pi a possible replacement for their expensive bridge device that is limited in what it can do and completely closed to us changing it.
But what will I do with the console? It's actually an attractive device and I think I'll put it in the kitchen somewhere. It will give me a nice conversation piece in the most often used room.
Edit Feb 13, 2015: One of the readers, John, had a problem with attaching to the SDR device. He chased it down to some code needing to be added in the USB open code. He emailed it to me and I tried out his fix and it worked fine. The problem relates back to removing the default hardware driver when starting up like I mentioned way back in a previous post <link>. I tested it to be sure it would work for me as well and it was great. I've already put the change into the github repository as commit number 86c70cf . See, it does pay off to read all the posts after all. Feel free to grab it