RTL-SDR: 433.92Mhz ASK/OOK Decoding of Various Devices with rtl_433

Since I got into the rtl-sdr craze, one thing I’ve always been interested in doing is decoding various sensors and remote controls which operate using RF. In order to do this, you must first acquire the signal, understand its modulation (FSK, OOK/ASK?) and deconstruct its transmission format (preamble, data (fixed, variable), encoding, error correction). It can be a pretty difficult job – and I have rarely had patience to persist with a particular device beyond trivial attempts to understand their formats (e.g. Efergy HM01).

Thanks to rtl_433 by Benjamin Larsson, we have a starting point. I guess this post isn’t going to be new to some people, so feel free to ignore it if you’re not interested.

Getting Started

It’s not hard to get started – a git clone and following the build instructions should leave you an rtl_433 executable inside the /build/src folder. Invoking it with ./rtl_433 –help gives a full listing of options, but most of the time you really only need to either invoke rtl_433 cleanly (i.e. ./rtl_433) to watch the signals, or in analyze mode (i.e. ./rtl_433 -a) to get a dump of unknown signal decode bits.

It’s pretty much as simple as that. One thing to note is that the rtl_433 sources include all of rtl-sdr, so it will build rtl_fm, etc. It may even be out of date in the future if rtl-sdr makes some new developments, so just be aware of this.

The great thing about open source is that it’s all there for tinkering. Trust me, you will want to tinker – say if you intend to do data logging to print to file or stdout instead of stderr, and to add in dates and times. I’ll leave the reader to focus on this – it is really only necessary to edit the callback function related to the protocol you’re interested in and to log the data you need :).

Aldi Weather Station

Around October in 2010, Aldi Supermarkets in Australia was selling a weekly special – it was branded Ascot Weather Station. It was a clock with a temperature and humidity display for inside and outside and barometric pressure. The outside sensor (one) was provided and uses a 433mhz system to send temperature and humidity data to the clock indoors. The sensor model number is GT-WT-01.

DSC_1092 DSC_1091

The front shows the LCD which shows data when powered, an LED indicating transmission on “button press”, and the openings for the sensors. The unit accepts two AAA cells for power, and the battery compartment has the “force transmit” and Celsius/Fahrenheit toggle button. There is a three position switch to change the “channel”, selections are 1, 2 and 3.

Temperature Monitor Battery Compartment

Being somewhat curious, I wanted to see inside just to check if there would be any clues to what sort of system it was using.

Internals Ascot Wireless Weather Station Sensor

Unfortunately, inside, it wasn’t really telling. The bottom plastic box houses the hygrometer and temperature sensor. The main PCB has metal “snap” buttons, a crystal, a few passives and a chip-on-board “gob top”. This is connected by plastic flex to the LCD, and a wire-connection to a 433mhz transmitter module. The three wire connection appears to be Vcc, Data and Ground.

A close look at the other side of the transmitter reveals clues about its identity.

433mhz transmitter module Ascot Wireless Weather Station

The model GE08-350 leads us to this datasheet from the company, G E-Chip Technology (HK). The datasheet tells us it’s an ASK 433.92Mhz TX module, thus giving us hope that it would be decodable by rtl_433.

ButtonPush-TempSense

It turns out that it does work just fine, and its detected with the Prologue protocol decoder (indicating the sensor has the same type of message format as the Prologue sensor they had analyzed). With the push button pressed for transmit, it shows button = 1. Battery = Low seems to fluctuate a bit with this model, but the channel is correctly detected.

Analyze Output

Invoking rtl_433 in analyze gives us information about the signal and the bits. It seems there’s an octet of 0’s as a pre-amble, and the data is transmitted six times over completely. The seventh time, it seems that one of the bits in the last nibble is toggled.

Data Logging

I was able to modify the code to generate CSV output for the Prologue format for my needs. I placed the sensor in the freezer, and let it log over time.

Prologue-Freezer-Sensor

I managed to repeat this for my fridge too … which seems to prove that both are in good temperature range, maybe a tad on the cold side (although you can’t trust the sensors to be accurate to the degree).

Prologue-Fridge-Sensor

In both cases, you can see the compressor on and off cycling in effect. Further to this, it was observed that due to the distance, noise in the signal occasionally resulted in incorrect decodes of data to implausible values (wrong channel, temperature way out of range). This is to be expected from ASK which can be interfered with by impulse noise easily, and isn’t heavily error protected at all.

1 by One Wireless Doorbell Transmitter

I don’t have many 433mhz devices, but one other one I have is a wireless doorbell transmitter. This one in question comes from a US company (which resells Chinese products) under the 1 by One brand. The particular transmitters look like this:

Doorbell DSC_1116

The rear claims to be a 433.92Mhz transmitter, +/- 0.5Mhz. It’s good news, but what is it made out of?

1byOne Doorbell Internal 1byOne Doorbell Internal Underside

I think you can see the reason for me choosing this model – it uses CR2032 coin cells rather than the slightly more difficult to get 12v car alarm remote style batteries. The rear of the PCB seems to suggests Quhwa as the manufacturer, with the design dated to 16th October 2009. The model is QH-C-CE-3V, and it utilizes a SAW resonator, and a single chip marked MC908T with no information available. The antenna is based on a printed trace towards the top of the board.

To my dismay, the rtl_433 code does not have a protocol filter for this device yet. But the analyze output is coherent and seems to illustrate it’s easy to support this in the future.

As I have three transmitters, I got the analyze output of the three transmitters.

Transmitter 1

*** signal_start = 307866, signal_end = 1014671
signal_len = 706805,  pulses = 1585
Iteration 1. t: 179    min: 88 (391)    max: 270 (609)    delta 5
Iteration 2. t: 179    min: 88 (391)    max: 270 (609)    delta 0
Pulse coding: Short pulse length 88 - Long pulse length 270

Short distance: 89, long distance: 269, packet distance: 1608

p_limit: 179

[00] {1} 00 : 00000000 
[01] {18} 61 bb c0 : 01100001 10111011 11000000 
[02] {18} 61 bb c0 : 01100001 10111011 11000000 
[03] {18} 61 bb c0 : 01100001 10111011 11000000 
[04] {18} 61 bb c0 : 01100001 10111011 11000000 
[05] {18} 61 bb c0 : 01100001 10111011 11000000 
[06] {18} 61 bb c0 : 01100001 10111011 11000000 
[07] {18} 61 bb c0 : 01100001 10111011 11000000 
[08] {18} 61 bb c0 : 01100001 10111011 11000000 
[09] {18} 61 bb c0 : 01100001 10111011 11000000 
[10] {18} 61 bb c0 : 01100001 10111011 11000000 
[11] {18} 61 bb c0 : 01100001 10111011 11000000 
[12] {18} 61 bb c0 : 01100001 10111011 11000000 
[13] {18} 61 bb c0 : 01100001 10111011 11000000 
[14] {18} 61 bb c0 : 01100001 10111011 11000000 
[15] {18} 61 bb c0 : 01100001 10111011 11000000 
[16] {18} 61 bb c0 : 01100001 10111011 11000000 
[17] {18} 61 bb c0 : 01100001 10111011 11000000 
[18] {18} 61 bb c0 : 01100001 10111011 11000000 
[19] {18} 61 bb c0 : 01100001 10111011 11000000 
[20] {18} 61 bb c0 : 01100001 10111011 11000000 
[21] {18} 61 bb c0 : 01100001 10111011 11000000 
[22] {18} 61 bb c0 : 01100001 10111011 11000000 
[23] {18} 61 bb c0 : 01100001 10111011 11000000 
[24] {18} 61 bb c0 : 01100001 10111011 11000000 
[25] {18} 61 bb c0 : 01100001 10111011 11000000 
[26] {18} 61 bb c0 : 01100001 10111011 11000000 
[27] {18} 61 bb c0 : 01100001 10111011 11000000 
[28] {18} 61 bb c0 : 01100001 10111011 11000000 
[29] {18} 61 bb c0 : 01100001 10111011 11000000 
[30] {18} 61 bb c0 : 01100001 10111011 11000000 
[31] {18} 61 bb c0 : 01100001 10111011 11000000 
[32] {18} 61 bb c0 : 01100001 10111011 11000000 
[33] {18} 61 bb c0 : 01100001 10111011 11000000 
[34] {18} 61 bb c0 : 01100001 10111011 11000000 
[35] {18} 61 bb c0 : 01100001 10111011 11000000 
[36] {18} 61 bb c0 : 01100001 10111011 11000000 
[37] {18} 61 bb c0 : 01100001 10111011 11000000 
[38] {18} 61 bb c0 : 01100001 10111011 11000000 
[39] {18} 61 bb c0 : 01100001 10111011 11000000 
[40] {18} 61 bb c0 : 01100001 10111011 11000000 
[41] {18} 61 bb c0 : 01100001 10111011 11000000 
[42] {18} 61 bb c0 : 01100001 10111011 11000000 
[43] {18} 61 bb c0 : 01100001 10111011 11000000 
[44] {18} 61 bb c0 : 01100001 10111011 11000000 
[45] {18} 61 bb c0 : 01100001 10111011 11000000 
[46] {18} 61 bb c0 : 01100001 10111011 11000000 
[47] {18} 61 bb c0 : 01100001 10111011 11000000 
[48] {18} 61 bb c0 : 01100001 10111011 11000000 
[49] {135} 61 bb c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 01100001 10111011 11000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Transmitter 2

*** signal_start = 1025477, signal_end = 1748502
signal_len = 723025,  pulses = 1585
Iteration 1. t: 183    min: 90 (335)    max: 276 (665)    delta 8
Iteration 2. t: 183    min: 90 (335)    max: 276 (665)    delta 0
Pulse coding: Short pulse length 90 - Long pulse length 276

Short distance: 91, long distance: 276, packet distance: 1463

p_limit: 183

[00] {1} 00 : 00000000 
[01] {18} e9 3b c0 : 11101001 00111011 11000000 
[02] {18} e9 3b c0 : 11101001 00111011 11000000 
[03] {18} e9 3b c0 : 11101001 00111011 11000000 
[04] {18} e9 3b c0 : 11101001 00111011 11000000 
[05] {18} e9 3b c0 : 11101001 00111011 11000000 
[06] {18} e9 3b c0 : 11101001 00111011 11000000 
[07] {18} e9 3b c0 : 11101001 00111011 11000000 
[08] {18} e9 3b c0 : 11101001 00111011 11000000 
[09] {18} e9 3b c0 : 11101001 00111011 11000000 
[10] {18} e9 3b c0 : 11101001 00111011 11000000 
[11] {18} e9 3b c0 : 11101001 00111011 11000000 
[12] {18} e9 3b c0 : 11101001 00111011 11000000 
[13] {18} e9 3b c0 : 11101001 00111011 11000000 
[14] {18} e9 3b c0 : 11101001 00111011 11000000 
[15] {18} e9 3b c0 : 11101001 00111011 11000000 
[16] {18} e9 3b c0 : 11101001 00111011 11000000 
[17] {18} e9 3b c0 : 11101001 00111011 11000000 
[18] {18} e9 3b c0 : 11101001 00111011 11000000 
[19] {18} e9 3b c0 : 11101001 00111011 11000000 
[20] {18} e9 3b c0 : 11101001 00111011 11000000 
[21] {18} e9 3b c0 : 11101001 00111011 11000000 
[22] {18} e9 3b c0 : 11101001 00111011 11000000 
[23] {18} e9 3b c0 : 11101001 00111011 11000000 
[24] {18} e9 3b c0 : 11101001 00111011 11000000 
[25] {18} e9 3b c0 : 11101001 00111011 11000000 
[26] {18} e9 3b c0 : 11101001 00111011 11000000 
[27] {18} e9 3b c0 : 11101001 00111011 11000000 
[28] {18} e9 3b c0 : 11101001 00111011 11000000 
[29] {18} e9 3b c0 : 11101001 00111011 11000000 
[30] {18} e9 3b c0 : 11101001 00111011 11000000 
[31] {18} e9 3b c0 : 11101001 00111011 11000000 
[32] {18} e9 3b c0 : 11101001 00111011 11000000 
[33] {18} e9 3b c0 : 11101001 00111011 11000000 
[34] {18} e9 3b c0 : 11101001 00111011 11000000 
[35] {18} e9 3b c0 : 11101001 00111011 11000000 
[36] {18} e9 3b c0 : 11101001 00111011 11000000 
[37] {18} e9 3b c0 : 11101001 00111011 11000000 
[38] {18} e9 3b c0 : 11101001 00111011 11000000 
[39] {18} e9 3b c0 : 11101001 00111011 11000000 
[40] {18} e9 3b c0 : 11101001 00111011 11000000 
[41] {18} e9 3b c0 : 11101001 00111011 11000000 
[42] {18} e9 3b c0 : 11101001 00111011 11000000 
[43] {18} e9 3b c0 : 11101001 00111011 11000000 
[44] {18} e9 3b c0 : 11101001 00111011 11000000 
[45] {18} e9 3b c0 : 11101001 00111011 11000000 
[46] {18} e9 3b c0 : 11101001 00111011 11000000 
[47] {18} e9 3b c0 : 11101001 00111011 11000000 
[48] {18} e9 3b c0 : 11101001 00111011 11000000 
[49] {135} e9 3b c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 11101001 00111011 11000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Transmitter 3

*** signal_start = 7525657, signal_end = 8249795
signal_len = 724138,  pulses = 1585
Iteration 1. t: 191    min: 98 (445)    max: 284 (555)    delta 85
Iteration 2. t: 191    min: 98 (445)    max: 284 (555)    delta 0
Pulse coding: Short pulse length 98 - Long pulse length 284

Short distance: 84, long distance: 269, packet distance: 1641

p_limit: 191

[00] {1} 00 : 00000000 
[01] {18} 76 0b c0 : 01110110 00001011 11000000 
[02] {18} 76 0b c0 : 01110110 00001011 11000000 
[03] {18} 76 0b c0 : 01110110 00001011 11000000 
[04] {18} 76 0b c0 : 01110110 00001011 11000000 
[05] {18} 76 0b c0 : 01110110 00001011 11000000 
[06] {18} 76 0b c0 : 01110110 00001011 11000000 
[07] {18} 76 0b c0 : 01110110 00001011 11000000 
[08] {18} 76 0b c0 : 01110110 00001011 11000000 
[09] {18} 76 0b c0 : 01110110 00001011 11000000 
[10] {18} 76 0b c0 : 01110110 00001011 11000000 
[11] {18} 76 0b c0 : 01110110 00001011 11000000 
[12] {18} 76 0b c0 : 01110110 00001011 11000000 
[13] {18} 76 0b c0 : 01110110 00001011 11000000 
[14] {18} 76 0b c0 : 01110110 00001011 11000000 
[15] {18} 76 0b c0 : 01110110 00001011 11000000 
[16] {18} 76 0b c0 : 01110110 00001011 11000000 
[17] {18} 76 0b c0 : 01110110 00001011 11000000 
[18] {18} 76 0b c0 : 01110110 00001011 11000000 
[19] {18} 76 0b c0 : 01110110 00001011 11000000 
[20] {18} 76 0b c0 : 01110110 00001011 11000000 
[21] {18} 76 0b c0 : 01110110 00001011 11000000 
[22] {18} 76 0b c0 : 01110110 00001011 11000000 
[23] {18} 76 0b c0 : 01110110 00001011 11000000 
[24] {18} 76 0b c0 : 01110110 00001011 11000000 
[25] {18} 76 0b c0 : 01110110 00001011 11000000 
[26] {18} 76 0b c0 : 01110110 00001011 11000000 
[27] {18} 76 0b c0 : 01110110 00001011 11000000 
[28] {18} 76 0b c0 : 01110110 00001011 11000000 
[29] {18} 76 0b c0 : 01110110 00001011 11000000 
[30] {18} 76 0b c0 : 01110110 00001011 11000000 
[31] {18} 76 0b c0 : 01110110 00001011 11000000 
[32] {18} 76 0b c0 : 01110110 00001011 11000000 
[33] {18} 76 0b c0 : 01110110 00001011 11000000 
[34] {18} 76 0b c0 : 01110110 00001011 11000000 
[35] {18} 76 0b c0 : 01110110 00001011 11000000 
[36] {18} 76 0b c0 : 01110110 00001011 11000000 
[37] {18} 76 0b c0 : 01110110 00001011 11000000 
[38] {18} 76 0b c0 : 01110110 00001011 11000000 
[39] {18} 76 0b c0 : 01110110 00001011 11000000 
[40] {18} 76 0b c0 : 01110110 00001011 11000000 
[41] {18} 76 0b c0 : 01110110 00001011 11000000 
[42] {18} 76 0b c0 : 01110110 00001011 11000000 
[43] {18} 76 0b c0 : 01110110 00001011 11000000 
[44] {18} 76 0b c0 : 01110110 00001011 11000000 
[45] {18} 76 0b c0 : 01110110 00001011 11000000 
[46] {18} 76 0b c0 : 01110110 00001011 11000000 
[47] {18} 76 0b c0 : 01110110 00001011 11000000 
[48] {18} 76 0b c0 : 01110110 00001011 11000000 
[49] {135} 76 0b c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 01110110 00001011 11000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

I think it’s clear that you can notice a pattern from the data.

  • It begins with an octet of 0’s (preamble).
  • The data itself is 3 bytes, and ends with the three nibbles 0xbc0.
  • This is repeated 49 times, and on the 49th time, it is postfixed with many 0x00 bytes.

It seems as if they send the data over and over to allow a “sleeping” receiver some time to notice the signal and confirm it in the presence of noise and or weak signals.

I might contact the developer and see if he can quickly code-up a callback to handle it. After all, with a wireless doorbell sender, there’s only ONE state it can send, i.e. button pushed! There’s no configurable code or channel options (not user configurable).

Conclusion

If you have any 433Mhz devices which use ASK or OOK (not FSK), there’s a good chance rtl_433 will help you analyze and make sense of the signal. Even if it’s just the analyze mode output of raw bits, that takes the difficulty of the “decoding” the physical transmission part away. If you have one of those weather station sensors – you know you can get it to work right away! Give it a try :).

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Radio and tagged , , , . Bookmark the permalink.

30 Responses to RTL-SDR: 433.92Mhz ASK/OOK Decoding of Various Devices with rtl_433

  1. Pingback: Using and RTL-SDR and RTL_433 to Decode Various Devices - rtl-sdr.com

  2. Anonymous says:

    Aldi also sell that exact doorbell, under the Delta brand

  3. urs says:

    hi
    did I miss something?
    what usb receiver did you use???
    thanks

  4. Kukk says:

    How did you plot the data from the application? How did you log it?

    • lui_gough says:

      You can modify the .c code to add a file handle and use fprintf to print the data in a format you prefer (e.g. .csv, by using comma delimited fields), suitable for importing into a spreadsheet like Excel. Typically you would modify only the callback function relevant to the temperature sensor in use.

      Alternatively, you can choose to pipe the output from rtl_433 into a file using the Linux terminal operator > and then re-process that with your own program.

      Remember, when it comes to hobby development, it’s not about being plug and play. You will have to do some work to mould it into something you like or is suitable. There are no guarantees or warranties – it’s all free.

      – Gough

      • RasPi tinkerer says:

        I currently work with the output of “rtl_433 -a” by redirecting it to a text file which I then grep for the data of my (unsupported) sensors. I don’t speak C, would you mind sharing your code changes to get the output CSV formatted? Thanks.

        • lui_gough says:

          Unfortunately, you might have to learn a little basic C to get it done, however, if you have played with Arduino/Wiring, you will find it pretty similar. The idea is to assemble the data you want into a comma separated string, so in my case, it was looking through the source code for the callback that handles my specific sensor (i.e. the Prologue one) and modifying the fprintf statements to print something else and send it to stdout instead.

          In my case, I decided to comment out all the fprintf statements and extract the data variables from the lines which printed temperature and humidity and assemble them into a new printf statement (this prints to stdout, which can then be logged by piping into a file). Alternately, you might open a file handle to a file in append mode, and use fprintf to print to that handle.

          It’s all coding, and unfortunately, it’s been that long since I’ve looked at it that the SD card in my Pi that I used for that experiment had been written over at least 10 times. I can’t even begin to tell you exactly how you can achieve that for the -a analyze mode as it tends to output a lot of raw signal data instead, and I’m not familiar enough with it.

          – Gough

  5. hurjup says:

    Hi

    I recently followed this project: http://rurandom.org/justintime/index.php?title=Cheapest_ever_433_Mhz_transceiver_for_PCs but once range was poor even with a 173mm antenna attached, and also received lots of noise (like here or even worse: http://hblok.net/blog_pics/433/audacity_overview.png). I’m not an electrical engineer, so I don’t know if I did something wrong, or it is normal. Using an rtl-sdr dongle, would the range and noise show a better figure?

    If you have some experience with LIRC: What do you think, instead of hacking rtl_433, could LIRC – as an out-of-the-box solution for the masses – probably be used for the same capturing of remote weather sensor signals? (I’m not sure about if it can handle dynamic data. Since everybody seem to code a custom solution for such reasons I assume the answer should be ‘no’ anyway.)

    Thank you in advance

    • lui_gough says:

      The transciever made in that fashion seems to suffer from a few issues. One issue is that the ASK transmitter modules normally expect the DATA pin to be pulled high (5v) or low (0v), rather than being driven with audio-line-level 0.7v signals. As a result, that might reduce the range, along with antenna considerations and noise from the PC. The other issue I foresee is that the transmitter module is probably powered permanently through USB, and that would keep a weak “leakage” signal coming out of the transmitter module.

      However, for a receiver module, it’s not a bad effort for analyzing the pulse trains, as long as the pulse train data rates are fairly low (normally, they are). From your screenshot, the noise is very normal – noise is everywhere, and it’s pervasive. Regardless of solution, you will have noise in your signal. The beauty of digital formatted transmission is that the noise is small compared to the possible states of the signal, so you can filter the noise or make it irrelevant. It’s also why there are special multi-bit pattern pre-ambles to each transmission which allows the receiver to distinguish between a valid signal and general noise.

      If you think of noise, think of a radio tuned in between stations. If you operate the RTL-SDR using a regular SDR receiver program with AGC, what happens is that during periods of low signal, the signal is amplified and you get the white-hiss background. When the signal comes on, the gain gets turned down, and the signal is comparatively strong compared to the noise. I’m sure this is also the case for the receiver modules to some degree – which is why you get random spikes. The radio spectrum isn’t “clean” – you will always have noise. Whether it is better or worse depends on how far you go in making a matched antenna, and in developing your demodulation algorithm.

      The best approach is to design a demodulation algorithm which is resistant to random noise by utilizing the transmission format and validating the format carefully.

      Unfortunately, the RTL-SDR approach will not help you to transmit as it is a receive only SDR. Since it’s relatively cheap to purchase, why don’t you try it for yourself? rtl_433 was mainly developed for weather station sensors and push button remote signals, so depending on what chipset and product, it may or may not be supported out of the box.

      In the meantime, LIRC is a bit different – it’s mainly tasked with decoding IR signals (raw 38k carrier or actual demodulated data signal). The issue will have to do with the encoding – LIRC is unlikely to already have the algorithms required to decide your data formats – and remote codes are typically short compared to 433mhz data transmissions. It will take a lot of work, and in the end, I’m not sure it will be worth it. A good lateral thought however.

      – Gough

  6. adriankoooo says:

    Dear Lui,

    What antenna do you use? I am able to receive signal from my Weather Station module within a few centimeters only.

    Regards,
    Adrian

    • lui_gough says:

      I use the supplied cheap whip antenna that comes with the dongle itself. I have no troubles receiving it from across the house with the sensor in the fridge. You might need to check the wire near the base – some poorly made antennas have broken joints with the coax meaning the antenna isn’t even connected. Another possibility is to try playing with the gain settings of the RTL-tuner and checking for the crystal frequency offset (ppm) and using that in the command to get your tuning slightly more accurate. Remember that higher gain isn’t necessarily better – as some of the higher gain settings amplify the noise more than the signal making it harder to decode correctly.

      – Gough

  7. Bob says:

    I would love to have a go at this BUT I fell at the build process for Rtl_433. Cmake fell over, then I had to get MinGW, that fell over. I’m not familer with building exe from C so can I just find an exe already done?

    • lui_gough says:

      As far as I know, I’m not aware of a version which has been compiled under Windows available as a binary, nor have I ever got anything rtl-related that requires direct USB access to build smoothly under Windows. Someone else who is more familiar with Cygwin/MinGW might be able to help.

      Otherwise, you’ll have to use Linux if you’re interested in it.

      – Gough

  8. David says:

    I don’t know where Anto found his but I came across a 32bit windows binary at http://sven.killig.de/SDR/

  9. edwin says:

    There is some information on the doorbel here: dont miss the plugin
    http://www.listenlive.nl/blog/2015/01/SelectPlus

  10. m. says:

    /*
    my grundig doorbell is ringing with the following code
    I had 2 use the audacity recording thing to extract the code
    one block consists of long [email protected] beginning
    followed by what I call As and Bs:
    A: longlow + short High
    B: short low+ long high

    */

    char *Grundigcode;
    Grundigcode= “ABBBBABBABBABBBBB”;

    void sendCodeGrundig(byte ntimes){
    for (int nRepeat=0; nRepeat<ntimes; nRepeat++) {
    //start each block with long high:
    digitalWrite(sendPin, HIGH);
    delayMicroseconds(1010);
    digitalWrite(sendPin, LOW);
    int i = 0;
    while (Grundigcode[i] != '') {
    switch(Grundigcode[i]) {
    case 'A':
    sendA();
    break;
    case 'B':
    sendB();
    break;
    }//switch
    i++;
    }//while
    delayMicroseconds(5850);//pause zwischen blöcken
    }//for
    }
    void sendA(){
    //longlow + short High: 1,16ms; 0,29ms
    digitalWrite(sendPin, LOW);
    delayMicroseconds(1160);
    digitalWrite(sendPin, HIGH);
    delayMicroseconds(290);
    digitalWrite(sendPin, LOW);
    }

    void sendB(){
    //short low+ long high: 0,44ms; 1,01ms
    digitalWrite(sendPin, LOW);
    delayMicroseconds(440);
    digitalWrite(sendPin, HIGH);
    delayMicroseconds(1010);
    digitalWrite(sendPin, LOW);
    }

  11. Emily Taylor says:

    Surpised you can get 433 devices in region 2, since its a ham radio band. I always hear chatter from repeater links on that frequency.

    • lui_gough says:

      Dear Emily,

      Well spotted, and yes, 433Mhz is ham band here but because they’re low-power, it’s normally no big issue for the hams. On the contrary, when hams use their handhelds, all our temperature sensors, doorbells, wireless headphones etc will be totally “captured” by the strong emission, but that’s life.

      The WIA bandplans here allocates 433Mhz area frequencies for mostly simplex use, so interference, if any, will be localized.

      – Gough

  12. kshitij says:

    Hey,

    i’m new to the RTL-SDR field, but i’m looking for something to aid in satellite communication.
    Basically i have a transmitter that’s transmitting OOK/ASK signals at 15 Bps.
    I need a receiver in the ground station to test this.
    How good will the RTL-SDR do, and how do i configure it for ASK/OOK.
    Thanks

    • lui_gough says:

      Unfortunately, this is a more involved thing than I will have sufficient time to explain, but let me break it down into a few points.

      The RTL-SDR is basically a TV tuner dongle found to have high rate ADC ability, in essence, passing “raw” spectrum digitized at up to ~2.4MS/s at 8-bits resolution. As it is a TV tuner, it’s not as sensitive, or linear as a good purpose built communication receiver or commercial SDR receiver. It is also more prone to intermodulation/aliasing (i.e. interference from strong signals nearby). The 8-bit resolution also results in limitations in its reception quality. Despite this, it can be adequate for many tasks.

      For satellite work, an important issue will be the antenna – you will need sufficient gain (noting that the RTL-SDR is decently sensitive, but not class-leading in any regard), and the correct polarization. A good front-to-back ratio is desirable as well as a narrow beam-width to exclude interfering signals. You will also need to take note of the frequency – it has to be within the reception range of the front-end of your dongle. Reception sensitivity typically falls off as you approach or exceed 1Ghz.

      The software is what does the magic of “decoding” signals within this digitized spectrum. Different reception modes will require different algorithms (think Digital Signal Processing) and sometimes different software. If you have specialized requirements, it’s unlikely that any existing software will be a perfect match to your needs, although that’s not to say you can’t take rtl_433, dissect it and try to make it accommodate your needs. After all, that’s the beauty of open source!

      The RTL-SDR can be used to receive satellite signals, with some people successfully receiving APT pictures from orbiting weather satellites using RTL-SDR. However, this is not always the easiest or most reliable route. As you’re looking for a specific 15bps OOK/ASK modulation signal, I don’t think there are many pre-made decoders available that could accommodate this. You should try testing your transmitters with different software to see what the result is – or better yet, learn some DSP techniques, and build your own decoder from the basic GNU Radio blocks.

      GNU Radio is basically a collection of digital signal processing blocks which can be used together in various ways to build more complex communication systems – say decoders, encoders, modulators, scramblers etc. It can accept input live from an RTL-SDR and process in real-time if your signal processing demands are not too high. GNU Radio runs best in Linux.

      Unfortunately, I can’t really provide any more guidance than this. Good luck with your adventures.

      – Gough

  13. MP Parsley says:

    Hi, See https://github.com/MPParsley/WiringPi-SelectPlus for a Raspberry Pi implementation to ring the Quhwa doorbell.

  14. svicarsvicar says:

    Helo
    I have exact the same weather station from Aldi.
    I want to capture package from outdoor station with arduino and logging the values
    how to start?

    • lui_gough says:

      Hardware wise, you will need a 433.92Mhz ASK/OOK receiver module. Software wise, I’m not sure if anyone has coded any particular software for it, but you will need to reverse engineer the transmission or the existing decoding routines to detect the start pre-amble, the data, and the checksum to extract the data. Such receiver modules constantly put out noise and relatively random 0/1 transitions when there are no transmissions on the air – so getting this all done correctly is going to be a bit of a challenge.

      Good luck.

      – Gough

  15. Andrew Que says:

    You *really* need to show the actual commands – not just the outputs! Makes it almost useless as we have to dig through the options and guess what you used!

    • lui_gough says:

      I didn’t write the article as a tutorial or guide for others. I wrote it to document results, mainly for myself. If you’re not bothered to do a tiny bit of reading of documentation – that’s your own problem and not mine. But that being said, given this article is now five years old – I’m certain I have mentioned it somewhere.

      Under the Getting Started sub-heading, I’ve already provided the necessary commands – I quote:
      “It’s not hard to get started – a git clone and following the build instructions should leave you an rtl_433 executable inside the /build/src folder. Invoking it with ./rtl_433 –help gives a full listing of options, but most of the time you really only need to either invoke rtl_433 cleanly (i.e. ./rtl_433) to watch the signals, or in analyze mode (i.e. ./rtl_433 -a) to get a dump of unknown signal decode bits.

      It’s pretty much as simple as that. One thing to note is that the rtl_433 sources include all of rtl-sdr, so it will build rtl_fm, etc. It may even be out of date in the future if rtl-sdr makes some new developments, so just be aware of this.”

      If you don’t know how to git clone the repository – then it’s:
      git clone https://github.com/merbanan/rtl_433

      If you don’t know where the build instructions are, see BUILDING.md at the same repository: https://github.com/merbanan/rtl_433/blob/master/BUILDING.md

      Even the repository’s front page gives you all of the relevant documentation. There’s no need for me to repeat this. It’s not my software, it’s not my job to document it.

      – Gough

Error: Comment is Missing!