It would be nice to add support for Oregon sensors.
You can find some code here: https://github.com/kevinmehall/rtlsdr-433m-sensor

Here's some output:

Tuned to 433920000 Hz.
*** signal_start = 5066203, signal_end = 5184028
signal_len = 117825, pulses = 82
Iteration 1. t: 916 min: 432 (80) max: 1401 (2) delta 1685
Iteration 2. t: 916 min: 432 (80) max: 1401 (2) delta 0
Pulse coding: Short pulse length 432 - Long pulse length 1401

Short distance: 337, long distance: 935, packet distance: 26308

p_limit: 916

[00] {41} 00 08 00 00 00 00 : 00000000 00001000 00000000 00000000 00000000 00000000
[01] {41} 00 08 00 00 00 00 : 00000000 00001000 00000000 00000000 00000000 00000000

Trying to tune to cheap humidity-temperature sensor I found there is already undocumented -f parameter to force frequency.
It would be nice to add this information to usage summary.

I have written a callback for the Auriol temperature sensor Model no Z31743a-TX which works fine.
This sensor is available in the "Auriol temperature station", the package containing both the sensor and the "base station" is available at e.g. LIDL for € 9,99 (at least in DE and NL).

However when testing and triggering different sensor ID's I found out that it may also trigger the prologue_callback. It might be hard to differentiate the 2 callbacks as both devices send 7 identical packets. The prologue callback is triggered when the mentioned id0 is 1001 (as documented) or 0101 (only in the code), so it has a chance of 1/8 of triggering a "false positive" when it receives packets from the Auriol sensor (can be "fixed" by taking the battery out of the Auriol sensor so it generates a new sensor ID that hopefully does not contain one of the mentioned patterns (might need a few retries).

In the prologue_callback there is a remark "FIXME validate the received message better", any chance of making this happen. I would be glad to assist.

The Auriol temperature sensor submits only 32 bits, the Prologue temperature sensor submits 36 bits I read, however the bits_per_row is not available to the callback, so it is not an option to check for that when we want to keep the callbacks simple. Any other ideas?

What testing / qualification needs to be done before submitting the code (pull request)?

Attached some output of triggering the prologue callback by the Auriol sensor:

*** signal_start = 29051340, signal_end = 29280530
signal_len = 229190,  pulses = 233
Iteration 1. t: 102    min: 83 (1)    max: 121 (232)    delta 36
Iteration 2. t: 102    min: 83 (1)    max: 121 (232)    delta 0
Distance coding: Pulse length 102

Short distance: 488, long distance: 977, packet distance: 2319

p_limit: 102

[00] {0} 00 : 00000000
[01] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[02] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[03] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[04] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[05] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[06] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[07] {33} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000

Sensor temperature event at 2014-08-11 20:41:38:
protocol       = Auriol
rid            = 52
temp           = 22.3
Sensor temperature event:
protocol      = Prologue
button        = 0
battery       = Low
temp          = -52.3
humidity      = 112
channel       = 1
id            = 5
rid           = 40
hrid          = 28
52 80 df 57 00

When the sensor ID changes, it no longer triggers the prologue_callback:

*** signal_start = 27438007, signal_end = 27660354
signal_len = 222347,  pulses = 233
Iteration 1. t: 93    min: 69 (1)    max: 117 (232)    delta 36
Iteration 2. t: 93    min: 69 (1)    max: 117 (232)    delta 0
Distance coding: Pulse length 93

Short distance: 493, long distance: 981, packet distance: 2323

p_limit: 93

[00] {0} 00 : 00000000
[01] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[02] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[03] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[04] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[05] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[06] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[07] {33} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000

Sensor temperature event at 2014-08-11 20:41:31:
protocol       = Auriol
rid            = aa
temp           = 21.1

Hi,

I've been trying to use rtl_433 to decode the 433Mhz transmissions from an efergy e2 electricity monitor but haven't had much luck.

I've an understanding of the packet structure from http://electrohome.pbworks.com/w/page/34379858/Efergy%20Elite%20Wireless%20Meter%20Hack but need some help getting the transmission decoded.

I've confirmed the signal is being received ok and is PWM with pulse width varying (short pulse=0), and can decode it manually and confirm the checksum is ok looking at the signal in audacity.

In rtl_433 I've tried changing the bit detection level and the gain level (30dB seems to give better signal looking at audacity) with no luck, rtl_433 always indicates only 1 pulse. I'm not sure if there is a way to work out what the long and short pulse lengths are from audacity?

Some files:
Output from rtl_sdr:
https://dl.dropboxusercontent.com/s/vcbndu2tomg3q3v/rtl_sdr-out-efergyE2.bin?token_hash=AAHZk9niEOTVD94k200UhAmQdgUwLHcSGiG26RdLHNBieA&dl=1

Two files outputted from rtl_433 -f 433460000 -a -t
https://dl.dropboxusercontent.com/s/gh8pichacji36bn/gfile001.data?token_hash=AAFvNb8nxuwWX2zGZV0o28eijui1ggD-2i6tfnpCtTalzA&dl=1

https://dl.dropboxusercontent.com/s/2ra1sqykxjw3k8f/gfile002.data?token_hash=AAE4_yIDMZMFHX9CIn1tdLEji8fo80o-FmFmuSOGq2Ulgg&dl=1

Output from: rtl_433 -f 433460000 -a
Registering protocol[01] Rubicson Temperature Sensor
Registering protocol[02] Prologue Temperature Sensor
Registering protocol[03] Silvercrest Remote Control
Registering protocol[04] ELV EM 1000
Registering protocol[05] ELV WS 2000
Registering protocol[06] Waveman Switch Transmitter
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
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 433460000 Hz.
*** signal_start = 480540, signal_end = 551423
signal_len = 70883, pulses = 1
Distance coding: Pulse length 50882

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 50882

[00] {0} 00 : 00000000

*** signal_start = 1980531, signal_end = 2051473
signal_len = 70942, pulses = 1
Distance coding: Pulse length 50941

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 50941

[00] {0} 00 : 00000000

^CSignal caught, exiting!

User cancel, exiting...

Thanks for any help!
Peter

Hi,

rtl_433 is really great. This evening I was able to add reception of the X10 security protocol to rtl_433. I was able to receive a DS10A sensor with this (changed at 433 Mhz). It should also work with sensors for the Marmitec safeguard alarm system at 433 Mhz. See http://www.marmitek.com/de/produkt-details/home-automation-security/x-10-security/safeguard.php. I have this also at home.

It just took a few hours today. Your hints for short_limit, long_limit and reset_limit are really good. I did not think that I would be so easy!

You may add the following code to rtl_433 for this to rtl_433.c if you want to.
I am looking forward to add other protocols. Unfortunately I did only take a X10 DS10A security sensor to the hotel at vacations....

Have fun!

Regards

Willi

static int x10sec_callback(uint8_t bb[BITBUF_ROWS][BITBUF_COLS]) {
/* validate */
if (bb[1][0]^0x0f == bb[1][1] &&
bb[1][2]^0xff == bb[1][3]) {
fprintf(stderr, "X10SEC: id = %02x%02x code=%02x",bb[1][0],bb[1][4],bb[1][2]);
if (debug_output)
debug_callback(bb);
return 1;
}
return 0;
}

r_device x10sec = {
.id = 6,
.name = "X10-Security",
.modulation = OOK_PWM_D,
.short_limit = 1100,
.long_limit = 2200,
.reset_limit = 10000,
.json_callback = &x10sec_callback,
};

// add this to the init protocol section
register_protocol(demod, &x10sec);

Hi, I'm looking for a way to get readings from a different temp sensor type (Lacrosse/TFA IT+ protocol) on the 868MHz band using RTL_SDR. I read it's supposed to be "easier" to decode than the one you implemented (signal uses OOK).
Binary protocol is quite well documented on the net (see http://fredboboss.free.fr/tx29/index.php?lang=en, or here if you like french ;) http://www.jacquet80.eu/blog/post/2011/10/Decodage-capteur-thermo-hygro-TFA ) so I think if I could get the "binary data" I could handle the decoding part.
Unfortunately I'm not familiar with "radio decoding" so I have no idea where to start from using rtl_sdr...
Do you think you could help ? Of course I can provide any info you need (sample output from RTL_SDR or whatever). Thanks for your help !

Analyze mode (-a) does a very good job of analyzing many signal types. However it produces inaccurate results when there is an initial start or sync pulse with different timings than the actual signal.

Some signals, especially those that are similar to Infrared (IR) signals sent over RF have long initial start/wakeup pulses. This causes the signals to look pulse width modulated whether they are or not.

For example the X10 signal uses a NEC style IR signal, After the long initial pulse, and long space, the signal is distance based. The initial pulse is approximately 2,250 samples (9,000 uS). Real data pulses are 140 samples (500 uS).

An indication that this is occurring, the number of long pulses will be very small (< 10), such as one for each repeat. Example for the X10 signal, there were nearly 200 short pulses both only 6 long pulses. The signal is repeated 6 times.

Primarily I'm opening this issue to provide information for others trying to climb the learning curve.

*** signal_start = 1003048, signal_end = 1175581
signal_len = 172533,  pulses = 204
Iteration 1. t: 1204    min: 144 (198)    max: 2264 (6)    delta 58
Iteration 2. t: 1204    min: 144 (198)    max: 2264 (6)    delta 0
Pulse coding: Short pulse length 144 - Long pulse length 2264

Short distance: 138, long distance: 458, packet distance: 10060

p_limit: 1204

[00] {34} 80 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000
[01] {34} 80 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000
[02] {34} 80 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000
[03] {34} 80 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000
[04] {34} 80 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000
[05] {34} 80 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000

The first sync pulse in each message is interpreted as a 1, everything else winds up being interpreted as a 0.

Use debug mode (-D) and look at the pulse_distance lines, to see the differences.

Since lots of sensors seem to repeat themselves a lot in one burst i'd like to propose a solution for reconstructing the most plausible sequence.
It works by creating a sum for 1s or 0s in a row (for all the bits). 0s decrease the counter, 1s increase. The final data is then reconstructed by checking if the sum for the bit in this row is positive (so it's a 1) or negative (so it's 0). If the sum is just zero no decision can be made since the propability for it being a 1 or 0 is exactly 50%.

// this tries to get the most plausible bit sequence from sensors
// repeating their data a few times
//  result - where the sequence is stored (usually the size of cols)
//  input   - usually this is bits_buffer
//  rows    - number of repetitions to concider
//  cols    - how many bytes to concider in a repetition
//  offset  - offset for bit buffer (e.g. input[0] usually is a preamble)
//  returns the number of discrepancies (kind of like bit errors)
static int bit_validate(
        uint8_t *result,
        uint8_t input[BITBUF_ROWS][BITBUF_COLS],
        int rows,
        int cols,
        int offset)
{
    int8_t counters[cols * 8];      // one bytes for every bit in a row
                                    // 0s count negative, 1s positive
    int errs = 0;                   // error counter
    int row, col, bit;

    // reset arrays
    memset(counters, 0x0, sizeof(int8_t) * (cols * 8));
    memset(result, 0x0, sizeof(uint8_t) * cols);

    // count number of 1s and 0s per row per bit
    for(row = offset; row < rows + offset; row++)
    {   
        for(col = 0; col < cols; col++)
        {   
            for(bit = 0; bit < 8; bit++)
            {   
                uint8_t val = (input[row][col] >> bit) & 0x1;
                counters[col * 8 + bit] += (val << 1) - 1;
            }
        }
    }

    // use the gathered sums to reconstruct most plausible bit sequence
    for(col = 0; col < cols; col++)
    {   
        for(bit = 0; bit < 8; bit++)
        {   
            int8_t c = counters[col * 8 + bit];
            uint8_t val;

            // actual decision
            // if sum is 0: 1s and 0s are equally distributed so no
            // decision can be made
            if(c > 0)
                val = 1;
            else if(c < 0)
                val = 0;
            else
                return -1;

            // construct resulting byte
            result[col] |= val << bit;
            // and count the errors
            errs += rows - abs(c);
        }
    }

    errs >>= 1;

    return errs;
}

To use it you need to know how many repetitions the sensor is sending, how many bytes are in one "packet" (or repetition) and the first repetition containing useful data to get the offset. Afterwards simply use the result from bit_validate since this is the error-corrected data.

Usage might look like this:

static int unknown0_callback(uint8_t bb[BITBUF_ROWS][BITBUF_COLS]) {
    uint8_t res[5];
    int errs;

    // sensor repeats itself 11 times
    // there are 5 bytes in one repetition
    // useful data starts at the second row, so offset is 1
    errs = bit_validate(res, bb, 11, 5, 1);

    if (res[0] == 0xb2 && res[1] == 0x00) {
        int temp = res[2];
        int pressure = (res[3] << 4) | (res[4] >> 4);
        ...

• Jan R.

on make action i'm facing some error 👍
/home/pi/rtl_433plug/include/rtl_433.h:48:30: error: unknown type name ‘uint8_t’
/home/pi/rtl_433plug/include/rtl_433.h:49:1: warning: no semicolon at end of struct or union [enabled by default]
/home/pi/rtl_433plug/include/rtl_433.h:52:20: error: unknown type name ‘uint8_t’

and

/home/pi/rtl_433plug/src/devices/silvercrest.c:3:33: error: unknown type name ‘uint8_t’
/home/pi/rtl_433plug/src/devices/silvercrest.c:33:30: error: ‘silvercrest_callback’ undeclared here (not in a function)
/home/pi/rtl_433plug/src/devices/silvercrest.c:33:29: warning: excess elements in struct initializer [enabled by default]
/home/pi/rtl_433plug/src/devices/silvercrest.c:33:29: warning: (near initialization for ‘silvercrest’) [enabled by default]

Hi,

When checking out some lost waves out here with RTL_433 I stumbled upon a Floating Point Exception.

Digging in it seams to be the line:
min_new = min_new / count_min;

I suspect a device by 0 action, but have not yet be able to confirm this.

update: confirmed... did a print just before the error and count_min -is- 0 at this point:
TEST!!! 3. t: 117 min: 117 (0) max: 118 (247) delta 1

complete loop output:
*** signal_start = 11050637, signal_end = 11308829
signal_len = 258192, pulses = 247
TEST!!! 1. t: 119 min: 117 (54) max: 121 (193) delta 16
Iteration 1. t: 118 min: 117 (54) max: 119 (193) delta 4
TEST!!! 2. t: 118 min: 117 (6) max: 119 (241) delta 4
Iteration 2. t: 117 min: 117 (6) max: 118 (241) delta 1
TEST!!! 3. t: 117 min: 117 (0) max: 118 (247) delta 1
Floating point exception

Any thoughts would be appreciated!

Johan

Hello,

is this possible to had the possibility to records logs ?

On a CSV format, this way we can use this file as source for any app we want.

readme says:

./rtl_433 -a file_name will save the demodulated signal in a file. The format of the file is >48kHz 16 bit samples.

However, when i open this up in something like audacity and import it as raw pcm at 48000, it plays way to slow, compared to listening to the noise on am receiver (or through gqrx in am demod, etc)

Is it actually stored raw at whatever sample rate, e.g., 250000, that it was captured at?

Can someone help me. I'd like to implement the handling from a WS2310 weather station.
In analyse mode it is picking it up fine (except for the bits are flipped). How do a go about adding this decoding based on the following output (two transmissions) from analyse mode? If needed I can post more. Thanks

*** signal_start = 110666412, signal_end = 111177557
signal_len = 511145, pulses = 416
Iteration 1. t: 207 min: 68 (223) max: 346 (193) delta 8
Iteration 2. t: 207 min: 68 (223) max: 346 (193) delta 0
Pulse coding: Short pulse length 68 - Long pulse length 346

Short distance: 325, long distance: 357, packet distance: 37641

p_limit: 207

[00] {52} f6 f1 28 1d 69 29 20 : 11110110 11110001 00101000 00011101 01101001 00101001 00100000
[01] {52} f6 a1 28 19 dd 62 10 : 11110110 10100001 00101000 00011001 11011101 01100010 00010000
[02] {52} f6 91 28 1f ff 00 20 : 11110110 10010001 00101000 00011111 11111111 00000000 00100000
[03] {52} f6 81 28 00 1f fe 00 : 11110110 10000001 00101000 00000000 00011111 11111110 00000000
[04] {52} f6 b1 28 0d 69 29 d0 : 11110110 10110001 00101000 00001101 01101001 00101001 11010000
[05] {52} f6 e1 28 09 dd 62 40 : 11110110 11100001 00101000 00001001 11011101 01100010 01000000
[06] {52} f6 d1 28 0f ff 00 50 : 11110110 11010001 00101000 00001111 11111111 00000000 01010000
[07] {52} f6 81 28 00 1f fe 00 : 11110110 10000001 00101000 00000000 00011111 11111110 00000000

*** signal_start = 142666549, signal_end = 143048815
signal_len = 382266, pulses = 312
Iteration 1. t: 208 min: 70 (159) max: 347 (153) delta 13
Iteration 2. t: 208 min: 70 (159) max: 347 (153) delta 0
Pulse coding: Short pulse length 70 - Long pulse length 347

Short distance: 323, long distance: 355, packet distance: 37850

p_limit: 208

[00] {52} f6 f1 2a 1d 69 29 40 : 11110110 11110001 00101010 00011101 01101001 00101001 01000000
[01] {52} f6 a1 2a 19 dd 62 30 : 11110110 10100001 00101010 00011001 11011101 01100010 00110000
[02] {52} f6 81 2a 00 1f fe 20 : 11110110 10000001 00101010 00000000 00011111 11111110 00100000
[03] {52} f6 b1 2a 0d 69 29 f0 : 11110110 10110001 00101010 00001101 01101001 00101001 11110000
[04] {52} f6 e1 2a 09 dd 62 60 : 11110110 11100001 00101010 00001001 11011101 01100010 01100000
[05] {52} f6 81 2a 00 1f fe 20 : 11110110 10000001 00101010 00000000 00011111 11111110 00100000

Hello

it will be fine that the results of sniff the temp/humidity was written to file - ex. to json file ( => https://github.com/asdil12/pymultimonaprs )

Regards
Pawel

./src/rtl_433: invalid option -- 'p'

Hello,

I've been using rtl_433 in an application that gathers and reports Oregon Scientific weather sensor data. The app runs on a Raspberry Pi and on a Netgear R7000 router running dd-wrt. So far so good.

Now I'd like to add support for an Efergy current sensor to my app. I have the decoding for the new sensor working, but it uses FSK encoding and requires rtl_fm instead of rtl_433.

My plan is to merge the code for rtl_433 and rtl_fm and send raw rtl-sdr samples to both decoders for processing. Separately, the rtl_fm code uses about 20% cpu on the Rasperry Pi, and the rtl_433 code uses about 12%.

My problem is that the rtl_fm decoder runs at 1,200,000 samples per second and I can't get it working at rates much below that. I've been running rtl_433 at 250,000 samples per second.

To have a shot at merging the code, I need to get both decoders running at the same frequency and sample rate and consuming a reasonable amount of cpu. rtl_433 does fine decoding messages from my OS sensors at 1,200,000 samples per second, but the problem is it uses 60% of the Raspberry pi's cpu to do it.

So I thought maybe I could sample at 1,200,000 s/sec and set decimation using -c 2 so rtl_433 didn't have to work so hard. If I understand how it works, this would get the effective sample rate that rtl_433 has to process to about 300,000, which is close to the default of 250000. Sure enough, when I use "rtl_433 -s 1.2e6 -c 2", the cpu load drops to 20% or less as I had hoped.

The problem is that decoding doesn't work with decimation set to anything other than the default 0. I manually adjusted the short, long, and reset limits in rtl_433 to account for the effective sample rate difference from using -c 2 by dividing the values by 4. I also tried -c 1 with dividing the values by 2. (I also tried these settings with the original values just in case there was some magic adjustment in the code that I didn't see).

Do I understand how this works or am I missing something big? I would have guessed that using decimation would have been fine, since the new sample rate was so much higher than the old one. Are there any other caveats to using the decimation feature to reduce processing load?

Any thoughts on this would be greatly appreciated!

Thanks!

Please add decoding support for the oregon scientific protocol.

You may use http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf for more information.

If you need I can capture some samples...

Regards,
Andreas

The debug_callback prints an excessive amount because it doesn't know how much real data is actually present in the buffer. This is a workaround, to find the "rectangle" that contains non-zero data.

Ideally, the callback protocol needs to be changed to something less simplistic than just passing the bit buffer without any dimensions.

Hello,
I am trying to make Auriol sensor (temperature & humidity, revision 2013, probably similar to proposed Nexus protocol) work and I have encountered a problem with Rubicson/Auriol protocol decoder which provides invalid outputs.

In newer Auriol sensors, the first packet (packet 0) is empty. Because of that, the decoder provides invalid temperature data, e.g.

Sensor temperature event:
protocol = Rubicson/Auriol
rid = 0
temp = 0.0
51 00 00 00 00

If I use a patched version when taking data from the 1st packet instead, the result is correct, but this could break compatibility with the original sensor (which I don't have and can't test):

Sensor temperature event:
protocol = Rubicson/Auriol
rid = 51
temp = 30.5
51 01 31 f3 40

I have decoded the frame format so I plan to write a separate decoder anyway (or extend the Nexus One), but to prevent the invalid detections, maybe you could include following line in the Rubicson/Auriol detection condition:

       (bb[0][1] != 0 || bb[0][2] != 0 || bb[0][3] != 0 || bb[0][4] != 0) &&

Hi,
I am using rtl_433 to try getting readings from wireless temp/humidity sensors (2 old Lexibook used ones that I got for few euros), and so far it works well.
Now I need to understand the "protocol" used by the sensors to encrypt values. I have already found part of it but now I'm a bit stuck.
The good news is I have the weather station "receiver" part so I know the values I should look for.

This is the kind of output I get from rtl_433 -a every minute or so :

Tuned to 433920000 Hz.
*** signal_start = 16661604, signal_end = 16932827
signal_len = 271223, pulses = 298
Iteration 1. t: 100 min: 85 (1) max: 116 (297) delta 25
Iteration 2. t: 100 min: 85 (1) max: 116 (297) delta 0
Distance coding: Pulse length 100

Short distance: 495, long distance: 1012, packet distance: 2232

p_limit: 100

[00] {0} 00 : 00000000
[01] {36} 6b ac 08 a2 50 : 01101011 10101100 00001000 10100010 01010000
[02] {36} 6b ac 08 a2 50 : 01101011 10101100 00001000 10100010 01010000
[03] {36} 6b ac 08 a2 50 : 01101011 10101100 00001000 10100010 01010000
[04] {36} 6b ac 08 a2 50 : 01101011 10101100 00001000 10100010 01010000
[05] {36} 6b ac 08 a2 50 : 01101011 10101100 00001000 10100010 01010000
[06] {36} 6b ac 08 a2 50 : 01101011 10101100 00001000 10100010 01010000
[07] {36} 6b ac 08 a2 50 : 01101011 10101100 00001000 10100010 01010000
[08] {36} 6b ac 08 a2 50 : 01101011 10101100 00001000 10100010 01010000
[09] {0} 00 : 00000000

Looks like the message is 5 bytes long (40 bits) repeated 8 times. Looking at a few messages coming from both sensors looks like the 1st byte (6b) is sensor-specific and never changes.

At this time the base station showed 25.9°C - 45% humidity
I figured out that reversing the bits order may be a first step:

0C 45 10 35 E6 00001010 01000101 00010000 00110101 11010110

And bingo here is the humidity % as BCD (45 - 2nd byte). I have confirmed that with a few other readings, but unfortunately, I can't find the temperature... Does anybody have any idea ?
(I suspect it could be coded on 16 bits after humidity, the last byte being the sensor ID (E6) and the first one (0C) a kind of checksum)

More readings can be found here: http://pastebin.com/YL5Quaeh

Once I get the answer I can try to implement the decoding in RTL_433 !

Thanks a lot !

I am trying to figure out how to read the temperature sent by my OBH oven thermometer (see http://www.obhnordica.se/Files/Filer/Userguides/4775.pdf).

Could you please help me in interpreting the output (http://pastie.org/9098436) that I get when running the command "./rtl_433 -f 433892400 -a -l 3000"? - the receiver says the temperature is constant; 24 degrees celcius.

Your feedback is greatly appreciated.

I'd like decode DSC security contact transmitters. The encoding is OOK, but is a bit odd for rtl_433 detection, so -a isn't helping that much.

Packets are 26.5 mS long

• Packets start with 2.5 mS of constant modulation
• The length of a bit is 500 uS, broken into two 250 uS segments.
• A logic 0 is 500 uS (2 x 250 uS) of no signal.
• A logic 1 is 250 uS of no signal followed by 250 uS of signal/keying
• Then there are 4 sync logic 1 bits.
• There is a sync/start 1 bit in between every 8 bits.
  • A zero byte would be 8 x 500 uS of no signal (plus the 250 uS of silence for the first half of the next 1 bit) for a maximum total of 4,250 uS (4.25 mS) of silence.
  • The last byte is a CRC with nothing after it, no stop/sync bit, so if there was a CRC byte of 0, the packet would wind up being short by 4 mS.
• There are 48 bits in the packet including the leading 4 sync 1 bits. This makes the packet 48 x 500 uS bits long plus the 2.5 mS preamble for a total packet length of 26.5 ms.

Note: Logan Lamb found the protocol description in one of the FCC filings in prep for his 2014 DEFCON talk. The document is here: https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=100988 The FCC ID is F5300NB912

*** signal_start = 167898276, signal_end = 167918759
signal_len = 20483, pulses = 4
Iteration 1. t: 37 min: 22 (3) max: 53 (1) delta 4
Iteration 2. t: 37 min: 22 (3) max: 53 (1) delta 0
Pulse coding: Short pulse length 22 - Long pulse length 53

Short distance: 102, long distance: 0, packet distance: 120

p_limit: 37

[00] {1} 80 : 10000000
[01] {1} 00 : 00000000
[02] {1} 00 : 00000000
[03] {1} 00 : 00000000

*** signal_start = 167959220, signal_end = 167979385
signal_len = 20165, pulses = 2
Iteration 1. t: 27 min: 19 (1) max: 36 (1) delta 0
Distance coding: Pulse length 27

Short distance: 109, long distance: 0, packet distance: 109

p_limit: 27

[00] {0} 00 : 00000000
[01] {0} 00 : 00000000

Hi,

I'm trying to control etekcity remote controlled outlets (http://goo.gl/gB4jFB), I'm going to use them to control various stuff in my house, lights, blinds, fans, water pump etc.. And also to get input from various security system sensors (beam breakers, magnetic switches, IR sensors, glass break detector etc..)

I tried compiling the software but it fails, here is the console output.

motoko build # cmake ../
-- The C compiler identification is GNU 4.8.3
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28")
-- checking for module 'libusb-1.0'
-- found libusb-1.0, version 1.0.19
-- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Udev rules not being installed, install them with -DINSTALL_UDEV_RULES=ON
-- Configuring done
-- Generating done
-- Build files have been written to: /root/rtl_433-master/build

motoko build # make

Scanning dependencies of target rtlsdr_shared
[ 3%] Building C object src/CMakeFiles/rtlsdr_shared.dir/librtlsdr.c.o
/root/rtl_433-master/src/librtlsdr.c: In function 'e4000_exit':
/root/rtl_433-master/src/librtlsdr.c:104:22: warning: unused parameter 'dev' [-Wunused-parameter]
int e4000_exit(void _dev) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'fc0012_exit':
/root/rtl_433-master/src/librtlsdr.c:148:23: warning: unused parameter 'dev' [-Wunused-parameter]
int fc0012_exit(void *dev) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'fc0012_set_bw':
/root/rtl_433-master/src/librtlsdr.c:154:25: warning: unused parameter 'dev' [-Wunused-parameter]
int fc0012_set_bw(void *dev, int bw) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c:154:34: warning: unused parameter 'bw' [-Wunused-parameter]
int fc0012_set_bw(void *dev, int bw) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'fc0012_set_gain_mode':
/root/rtl_433-master/src/librtlsdr.c:156:32: warning: unused parameter 'dev' [-Wunused-parameter]
int fc0012_set_gain_mode(void *dev, int manual) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c:156:41: warning: unused parameter 'manual' [-Wunused-parameter]
int fc0012_set_gain_mode(void *dev, int manual) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'fc0013_exit':
/root/rtl_433-master/src/librtlsdr.c:159:23: warning: unused parameter 'dev' [-Wunused-parameter]
int fc0013_exit(void *dev) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'fc0013_set_bw':
/root/rtl_433-master/src/librtlsdr.c:163:25: warning: unused parameter 'dev' [-Wunused-parameter]
int fc0013_set_bw(void *dev, int bw) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c:163:34: warning: unused parameter 'bw' [-Wunused-parameter]
int fc0013_set_bw(void *dev, int bw) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'fc2580_exit':
/root/rtl_433-master/src/librtlsdr.c:167:23: warning: unused parameter 'dev' [-Wunused-parameter]
int fc2580_exit(void *dev) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'fc2580_set_bw':
/root/rtl_433-master/src/librtlsdr.c:171:34: warning: unused parameter 'bw' [-Wunused-parameter]
int fc2580_set_bw(void *dev, int bw) { return fc2580_SetBandwidthMode(dev, 1); }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'fc2580_set_gain':
/root/rtl_433-master/src/librtlsdr.c:172:27: warning: unused parameter 'dev' [-Wunused-parameter]
int fc2580_set_gain(void *dev, int gain) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c:172:36: warning: unused parameter 'gain' [-Wunused-parameter]
int fc2580_set_gain(void *dev, int gain) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'fc2580_set_gain_mode':
/root/rtl_433-master/src/librtlsdr.c:173:32: warning: unused parameter 'dev' [-Wunused-parameter]
int fc2580_set_gain_mode(void *dev, int manual) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c:173:41: warning: unused parameter 'manual' [-Wunused-parameter]
int fc2580_set_gain_mode(void *dev, int manual) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'r820t_exit':
/root/rtl_433-master/src/librtlsdr.c:180:22: warning: unused parameter 'dev' [-Wunused-parameter]
int r820t_exit(void *dev) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c: In function 'r820t_set_bw':
/root/rtl_433-master/src/librtlsdr.c:182:24: warning: unused parameter 'dev' [-Wunused-parameter]
int r820t_set_bw(void *dev, int bw) { return 0; }
^
/root/rtl_433-master/src/librtlsdr.c:182:33: warning: unused parameter 'bw' [-Wunused-parameter]
int r820t_set_bw(void *dev, int bw) { return 0; }
^
[ 6%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_e4k.c.o
[ 9%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_fc0012.c.o
[ 12%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_fc0013.c.o
[ 15%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_fc2580.c.o
/root/rtl_433-master/src/tuner_fc2580.c: In function 'fc2580_wait_msec':
/root/rtl_433-master/src/tuner_fc2580.c:124:29: warning: unused parameter 'pTuner' [-Wunused-parameter]
void fc2580_wait_msec(void *pTuner, int a)
^
/root/rtl_433-master/src/tuner_fc2580.c:124:41: warning: unused parameter 'a' [-Wunused-parameter]
void fc2580_wait_msec(void *pTuner, int a)
^
[ 18%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_r820t.c.o
/root/rtl_433-master/src/tuner_r820t.c: In function 'R828_Delay_MS':
/root/rtl_433-master/src/tuner_r820t.c:207:8: warning: unused parameter 'pTuner' [-Wunused-parameter]
void *pTuner,
^
/root/rtl_433-master/src/tuner_r820t.c:208:16: warning: unused parameter 'WaitTimeMs' [-Wunused-parameter]
unsigned long WaitTimeMs
^
/root/rtl_433-master/src/tuner_r820t.c: In function 'R828_Filt_Cal':
/root/rtl_433-master/src/tuner_r820t.c:2484:66: warning: unused parameter 'R828_BW' [-Wunused-parameter]
R828_ErrCode R828_Filt_Cal(void *pTuner, UINT32 Cal_Freq,BW_Type R828_BW)
^
Linking C shared library librtlsdr.so
[ 18%] Built target rtlsdr_shared
Scanning dependencies of target rtl_433
[ 21%] Building C object src/CMakeFiles/rtl_433.dir/rtl_433.c.o
/root/rtl_433-master/src/rtl_433.c: In function 'debug_callback':
/root/rtl_433-master/src/rtl_433.c:40:66: warning: unused parameter 'bits_per_row' [-Wunused-parameter]
int debug_callback(uint8_t bb[BITBUF_ROWS][BITBUF_COLS], int16_t bits_per_row[BITBUF_ROWS]) {
^
/root/rtl_433-master/src/rtl_433.c: In function 'sighandler':
/root/rtl_433-master/src/rtl_433.c:185:28: warning: unused parameter 'signum' [-Wunused-parameter]
static void sighandler(int signum) {
^
[ 25%] Building C object src/CMakeFiles/rtl_433.dir/devices/silvercrest.c.o
In file included from /root/rtl_433-master/src/devices/silvercrest.c:1:0:
/root/rtl_433-master/include/rtl_433.h:48:30: error: unknown type name 'uint8_t'
int (_json_callback)(uint8_t bits_buffer[BITBUF_ROWS][BITBUF_COLS],int16_t bits_per_row[BITBUF_ROWS]) ;
^
/root/rtl_433-master/include/rtl_433.h:49:1: warning: no semicolon at end of struct or union [enabled by default]
} r_device;
^
/root/rtl_433-master/include/rtl_433.h:52:20: error: unknown type name 'uint8_t'
int debug_callback(uint8_t buffer[BITBUF_ROWS][BITBUF_COLS], int16_t bits_per_row[BITBUF_ROWS]);
^
/root/rtl_433-master/src/devices/silvercrest.c:3:33: error: unknown type name 'uint8_t'
static int silvercrest_callback(uint8_t bb[BITBUF_ROWS][BITBUF_COLS],int16_t bits_per_row[BITBUF_ROWS]) {
^
/root/rtl_433-master/src/devices/silvercrest.c:33:30: error: 'silvercrest_callback' undeclared here (not in a function)
/* .json_callback = / &silvercrest_callback,
^
/root/rtl_433-master/src/devices/silvercrest.c:33:29: warning: excess elements in struct initializer [enabled by default]
/ .json_callback = / &silvercrest_callback,
^
/root/rtl_433-master/src/devices/silvercrest.c:33:29: warning: (near initialization for 'silvercrest') [enabled by default]
src/CMakeFiles/rtl_433.dir/build.make:80: recipe for target 'src/CMakeFiles/rtl_433.dir/devices/silvercrest.c.o' failed
make[2]: ** [src/CMakeFiles/rtl_433.dir/devices/silvercrest.c.o] Error 1
CMakeFiles/Makefile2:140: recipe for target 'src/CMakeFiles/rtl_433.dir/all' failed
make[1]: *** [src/CMakeFiles/rtl_433.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

Dear Benjamin Larsson,

First of all, thanks for rtl_433. It has been quite useful in monitoring ASK/OOK signals, and I have thoroughly enjoyed using it.

I recently purchased several 1byOne branded (Quhwa manufactured) wireless doorbell transmitters. I have three of them, and I had dumped the analyze data on my blog posting about it at http://goughlui.com/?p=5395

The data looks very sensible, and patterns are visible (last 3 octets of all 3 transmitters are 0xbc0, 49 repetitions). I was wondering if you could add this as a protocol filter to the code as it seems very trivial to implement.

Many thanks,

Gough.

For Pulse Width Decoding (OOK_PWM_P) there is a bug that affects the processing of first bit as well as some differences in the way Pulse Width Decoding is currently handled vs. distance or analyze (-a).

This leads to some unexpected results where analyze (-a) is giving different results than what the call back receives.

Things to be aware of when using OOK_PWM_P

1. For OOK_PWM_P short pulses = 1, long pulses = 0. This is inverted from what pwm_analyze (-a) or distance OOK_PWM_D uses (short pulse = 0, long pulse = 1).
2. OOK_PWM_P considers the first pulse to be a start bit and silently discards it without setting a bit. The call back will be missing the first bit when compared to analyze (-a) even after inverting.
3. There is a bug processing the start bit that causes the first real bit (2nd pulse) to be misinterpreted unless the long_limit is higher than the long pulse period (long pulse width + space width * 2). The sample_counter isn't reset after processing the start bit, which makes it look like the long_limit was reached when it shouldn't have been. Note: Setting the long_limit high enough will work around this bug.

I will submit a patch (pull request) for the bug.

This affects the Acurite processing and the LaCrosse TX (temperature/humidity) processing. See acurite_detect().

The other devices that use pwm_p_decode are silvercrest and waveman. Presumably one or both of these depends on the behavior of discarding the start pulse and inverting the bits. I might submit an alternate pulse width decoder that doesn't have those properties to benefit LaCrosse and Acurite, though I don't currently have any Acurite sensors to test with.

For No. 3, the bug, the fix:

        if (!p->real_bits && p->start_bit && (buf[i] < demod->level_limit)) {
            /* end of startbit */
            p->real_bits = 1;
           //  fprintf(stderr, "start bit pulse end detected [@ %d]\n", p->sample_counter);
+            p->sample_counter = 0;   // <<--- i think this was forgotten.
        } 

For reference: No. 1 from pwm_p_decode:

if (p->pulse_length <= p->short_limit) {
  demod_add_bit(p, 1);
} else if (p->pulse_length > p->short_limit) {
  demod_add_bit(p, 0);
}

vs. pwm_d_decode:

if (p->sample_counter < p->short_limit) {
    demod_add_bit(p, 0);
} else if (p->sample_counter < p->long_limit) {
    demod_add_bit(p, 1);
} else {

Can't build rtl_433 now:
/rtl_433.h:48:30: error: unknown type name ‘uint8_t’

I added #include<stdint.h> to workaround.

Hello!
Sorry to open an issue for this, I couldn't find another way to contact you.
Thanks for sharing your code!
I'm trying to receive readings from the ELV EM 1000 energy meter sensors. Demodulated AM audio:
http://sven.killig.de/SDR/ELV%20EM%201000-S.wav
"-a" log:
http://sven.killig.de/SDR/ELV%20EM%201000-GZ.txt
I just need a short tip how "pulse_distance" (496/978) and "pulse_start distance" (961/1447) correspond to ".short_limit" and ".long_limit". Thanks in advance!

RTL_FM is tuning off-center to dodge the DC spike [1] present in some tuners (like the E4000 and the R820T). This is being corrected in demodulation. Just curious whether this could actually help signal reception in rtl_433 ?

Unfortunately my skills are not good enough to properly implement this (in case it is missing).

[1] http://kmkeen.com/rtl-demod-guide/index.html - FAQ Section

Hi Benjamin,

I am trying to add decoding of data for the Oregon Scientific RMR382 (Sender THN132N) to rtl_433. I am having difficulty understanding how to work out the values for short_limit, long_limit and reset_limit. I have had a go, but I don't think I have the correct values set. I have detailed my values below.

I have also included rtl_433 -a output for an Oregon Scientific THN132N sender and rtl_433 -a output for a Holman Industries iWeather WS5029 sender.

Any assistance in working out these values would be appreciated.

Thanks.

Cheers, Barrie

r_device iweather = {
    /* .id             = */ 9,
    /* .name           = */ "iWeather Weather Station",
    /* .modulation     = */ OOK_PWM_D,
    /* .short_limit    = */ 126,
    /* .long_limit     = */ 248,
    /* .reset_limit    = */ 3000,
    /* .json_callback  = */ &iweather_callback,
};

Registering protocol[01] Rubicson Temperature Sensor
Registering protocol[02] Prologue Temperature Sensor
Registering protocol[03] Silvercrest Remote Control
Registering protocol[04] ELV EM 1000
Registering protocol[05] ELV WS 2000
Registering protocol[06] Waveman Switch Transmitter
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
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.

rtl_433 -a output for an Oregon Scientific THN132N sender

*** signal_start = 5476938, signal_end = 5581042
signal_len = 104104,  pulses = 196
Iteration 1. t: 174    min: 112 (56)    max: 236 (140)    delta 117
Iteration 2. t: 174    min: 112 (56)    max: 236 (140)    delta 0
Pulse coding: Short pulse length 112 - Long pulse length 236

Short distance: 131, long distance: 252, packet distance: 2324

p_limit: 174

[00] {98} ff ff 24 eb 57 ea 9f 7d 2d be dd 7f 80 : 11111111 11111111 00100100 11101011 01010111 11101010 10011111 01111101 00101101 10111110 11011101 01111111 10000000 
[01] {98} ff ff 24 eb 57 ea 9f 7d 2d be dd 7f 80 : 11111111 11111111 00100100 11101011 01010111 11101010 10011111 01111101 00101101 10111110 11011101 01111111 10000000 

rtl_433 -a output for a Holman Industries iWeather WS5029 sender

*** signal_start = 6262899, signal_end = 6499663
signal_len = 236764,  pulses = 576
Iteration 1. t: 178    min: 118 (347)    max: 238 (229)    delta 10049
Iteration 2. t: 179    min: 119 (351)    max: 240 (225)    delta 5
Iteration 3. t: 179    min: 119 (352)    max: 240 (224)    delta 0
Pulse coding: Short pulse length 119 - Long pulse length 240

Short distance: 125, long distance: 247, packet distance: 1225

p_limit: 179

[00] {7} 00 : 00000000 
[01] {96} aa a5 98 5f 01 36 3e 01 30 58 d8 80 00 : 10101010 10100101 10011000 01011111 00000001 00110110 00111110 00000001 00110000 01011000 11011000 10000000 00000000 
[02] {96} aa a5 98 5f 01 36 3e 01 30 58 d8 00 00 : 10101010 10100101 10011000 01011111 00000001 00110110 00111110 00000001 00110000 01011000 11011000 00000000 00000000 
[03] {96} aa a5 98 5f 01 36 3e 01 30 58 d8 00 00 : 10101010 10100101 10011000 01011111 00000001 00110110 00111110 00000001 00110000 01011000 11011000 00000000 00000000 
[04] {96} aa a5 98 5f 01 36 3e 01 30 58 d8 00 00 : 10101010 10100101 10011000 01011111 00000001 00110110 00111110 00000001 00110000 01011000 11011000 00000000 00000000 
[05] {96} aa a5 98 5f 01 36 3e 01 30 58 d8 80 00 : 10101010 10100101 10011000 01011111 00000001 00110110 00111110 00000001 00110000 01011000 11011000 10000000 00000000 
[06] {89} aa a5 98 5f 01 36 3e 01 30 58 d8 00 : 10101010 10100101 10011000 01011111 00000001 00110110 00111110 00000001 00110000 01011000 11011000 00000000 

Hi,

I have china sensor which i can't decode. Is there any chance to get it supported?
Some data i collected:
https://gist.github.com/samm-git/1b0a4fbc4297a8be0df6

It seems that most of the bits are too short? Data is provided when sensor in channel 1. On other channels its looks a bit different:

Channel 1:
https://gist.github.com/samm-git/79cdec1f1234dfc34c40

Channel 3:
https://gist.github.com/samm-git/de57068b15a9eb3c85ea

Is it possible somehow to get this device supported? Thank you.

Right now rtl_433 cannot handle SIGPIPE properly - it goes into endless loop caused by fprintf command inside the sighandler() function (each subsequent fprintf creates another SIGPIPE signal).
The fix is easy (I don't know how to create a pull request here), just add this line at the beginning of sighandler() function in rtl_433.c:

   if (signum == SIGPIPE) signal(SIGPIPE, SIG_IGN);

how to view/analyze data file?
I'm very new to this, learning as I go. I'm trying to decode transmissions from some cheap Chinese weather station sensors of ebay.
but can't make sense of it yet

when temperature displayed 18.3C I got this:
[00] {48} 00 cd b8 f7 00 3a 00 : 00000000 11001101 10111000 11110111 00000000 00111010 00000000
[01] {48} 00 cd b8 f7 00 3a 00 : 00000000 11001101 10111000 11110111 00000000 00111010 00000000
when temperature change to 18.5C I got this:
[00] {48} 00 cd b6 f7 00 cd 00 : 00000000 11001101 10110110 11110111 00000000 11001101 00000000
[01] {48} 00 cd b6 f7 00 cd 00 : 00000000 11001101 10110110 11110111 00000000 11001101 00000000

temperature increased by 0.2 and third element decreased by 2.. I can't understand why is it backwards.
I can't get gnuradio companion (or any other SDR software with more features that I came across) to work on my laptop, after trying and failing for the last two weeks I gave up. Is there any way can analyze data files by my self?
I will appreciate any hints and clues. Thank you

@merbanan: good to see you back and active again. Thanks for this great piece of software!

Lately I have been working on a plugin infrastructure for rtl_433 so that device types can be added at runtime by simply adding or removing a library file per device type. This has been implemented and seems to be working OK. See my branch plugins at https://github.com/Batilan/rtl_433/tree/plugins.

Besides the device callbacks I'm also thinking about implementing the PWM decoders as plugins. This would allow for easier development of alternative (PWM) decoders. Currently the PWM decoders are called by all devices with different time settings for each received message. I think this can probably be made more efficient.

I think for low end devices (like Raspberry) this construct together with calling all all availabale device callbacks as is done now stresses some of these devices quite heavily already and is not really scalable if we want to add more and more devices. The factoring out of the device callbacks by @helgew is quite an improvement and makes adding devices and avoiding conflicts easier (I needed to to the same for the plugin module).

The reason I have not yet submitted a pull request is that I would like to improve the plugin interface so that it is usable in a more generic way. Also the plugin module needs some adaptions to make it work for Windows environments (is this software actually compiled and used by Windows users?). I have tested it only for different Linux environments like Raspberry and x86 distributions.

I would like to exchange some idea's and prevent duplicating of work, however a Github issue is probably not the best communication medium for this?. Lately I have also been exchanging ideas with @rct who has also been doing some nice improvements on rtl_433. I'm motivated to share idea's with any other developer that has idea's about improving the great rtl_433 software. I understand @merbanan also has idea's about improving the software but has limited time, I would like to help with structural improvements making the rtl_433 more scalable so we can remove the line "This software is mostly useable for developers right now."

Looking forward for any responses.

I have an acurite 5-n-1 weather sensor, p/n VN1TX
it has wind direction, wind speed, temp, humidity, and rainfall.

Using rtl_433 in analyze mode, I've been able to (mostly) reverse engineer the packet structures into usable data. Still working on a few specifics, but I can read temp, humidity, wind direction and speed. I'll work on rain gauge later.

Thanks also to a few internet postings which helped lead me in the right direction.
http://www.wxforum.net/index.php?topic=18690.msg180713#msg180713
http://forum.arduino.cc/index.php?topic=145341.0

The trace of this looks very similar to postings in the arduino forum link above, but with a slightly longer data payload section.

It's pulse (width) coding.
Each transmissions has a message repeated 3x with slight difference (i think a sequence id).
Each message has:
4 sync? pulses, 1250 uS period, 50% duty cycle
65 data pulses, short pulse ~200-250 uS, long pulse ~350-400 uS

I'm currently trying to implement the timing in rtl_433.c, but having some trouble understanding how to setup the structure for these timings.

Not sure how i should setup the limits based upon my timings.
I think the {short,long,reset}_limits should be samples, but unsure exactly if this is the low or high limit of detection, and whether its based upon 250k (default) or 1024k (mentioned in source code above device structs).

r_device acurite5n1 = {
    /* .id             = */ 10,
    /* .name           = */ "Acurite 5n1 VN1TX",
    /* .modulation     = */ OOK_PWM_P,
    /* .short_limit    = */ ?, 
    /* .long_limit     = */ ?,
    /* .reset_limit    = */ ?,
    /* .json_callback  = */ &acurite5n1_callback,
};

jens@spire:~/build/rtl_433/build$ src/rtl_433 -a
Registering protocol[01] Rubicson Temperature Sensor
Registering protocol[02] Prologue Temperature Sensor
Registering protocol[03] Silvercrest Remote Control
Registering protocol[04] ELV EM 1000
Registering protocol[05] ELV WS 2000
Registering protocol[06] Waveman Switch Transmitter
Registering protocol[07] Steffen Switch Transmitter
Registering protocol[08] Acurite 5n1 VN1TX
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
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.
*** signal_start = 1635516, signal_end = 1689257
signal_len = 53741,  pulses = 207
Iteration 1. t: 69    min: 39 (134)    max: 99 (73)    delta 2434
Iteration 2. t: 67    min: 37 (128)    max: 98 (79)    delta 5
Iteration 3. t: 67    min: 37 (128)    max: 98 (79)    delta 0
Pulse coding: Short pulse length 37 - Long pulse length 98

Short distance: 61, long distance: 118, packet distance: 164

p_limit: 67

[00] {1} 80 : 10000000 
[01] {1} 80 : 10000000 
[02] {1} 80 : 10000000 
[03] {1} 80 : 10000000 
[04] {65} c6 88 71 00 a6 00 9f 04 00 : 11000110 10001000 01110001 00000000 10100110 00000000 10011111 00000100 00000000 
[05] {1} 80 : 10000000 
[06] {1} 80 : 10000000 
[07] {1} 80 : 10000000 
[08] {1} 80 : 10000000 
[09] {65} d6 88 71 00 a6 00 9f 14 00 : 11010110 10001000 01110001 00000000 10100110 00000000 10011111 00010100 00000000 
[10] {1} 80 : 10000000 
[11] {1} 80 : 10000000 
[12] {1} 80 : 10000000 
[13] {1} 80 : 10000000 
[14] {65} e6 88 71 00 a6 00 9f 24 00 : 11100110 10001000 01110001 00000000 10100110 00000000 10011111 00100100 00000000 

*** signal_start = 1758238, signal_end = 1778264
signal_len = 20026,  pulses = 1
Distance coding: Pulse length 25

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 25

[00] {0} 00 : 00000000 

^CSignal caught, exiting!

User cancel, exiting...

Hi there, new to Linux and rpi.
Installed rtl433 on my rpi with a 433mhz rx/TX chip on breadboard. But when I execute ./rtl_433 it's says no supported device. What am I doing wrong?

Hi,
it would be great to add support for uhd based devices.

Hi merbanan,

I realy like rtl_433 project a lot. I'm a little experienced in hacking chinese digital thermometers. I hacked my own a few month ago with Arduono. Now I want to decode another thermometer. The bit rows are on pastiie:

http://pastie.org/6122963

There are 17 bit to level up rx. Then a 4000ms break. Then 20 (did not count exactly ;) ) data bits. This row is sent twice.

Where must I change code to see all the raw data bits? I chagned code like that

http://pastie.org/6122982

But raw bit mode (the [00] 0010101010101010 thing) show always the same data and not the matching data.

Thank you very much. An keep up the good work!

When using '-r' to play back record files, the call back function will not get called if the reset_limit is higher than the number of quiet samples at the end of the test file.

In my case, I had set a high reset_limit (20,000 samples), but the recorded file had approximately 10,000 quiet samples after the signal at the end.

I suggest that during development with recorded files, set the reset_limit below 10,000.

I'm not an export on these things but I really want it to work, but I failed so far. anybody have any idea why?

tom@Toshiba:~$ rtl_433
Registering protocol[01] Rubicson Temperature Sensor
Registering protocol[02] Prologue Temperature Sensor
Registering protocol[03] Silvercrest Remote Control
Registering protocol[04] ELV EM 1000
Registering protocol[05] ELV WS 2000
Registering protocol[06] Waveman Switch Transmitter
Found 1 device(s):
0: Realtek, RTL2841UHIDIR, SN: 00000001

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
usb_claim_interface error -6
Failed to open rtlsdr device #0.
tom@Toshiba:~$ lsusb
Bus 001 Device 006: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0930:130b Toshiba Corp. F3507g Mobile Broadband Module
Bus 002 Device 003: ID 04f2:b096 Chicony Electronics Co., Ltd
Bus 003 Device 002: ID 0930:0508 Toshiba Corp. Integrated Bluetooth HCI
Bus 006 Device 003: ID 2635:0601
Bus 007 Device 002: ID 08ff:1600 AuthenTec, Inc. AES1600
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

something unexpected has changed with the new merged code base from pull request #74 I'm not getting any LaCrosse output. I'm also getting a very low number of call backs.

Hi,

I recently bought a Honeywell RCWL300A1006 and hope to receive the signal and play a custom chime from my computer speakers when the button is pressed. I discovered that it uses 916.8Mhz and was able to capture the signal using rtl_433 but it was not able to decode anything. I suspect that maybe the device is using FSK to encode the signal...
http://yourhome.honeywell.com/home/Products/Door+Chimes/Wireless+Doorbell+Push+Buttons/RPWL300A.htm

*** signal_start = 1421354, signal_end = 1743672
signal_len = 322318, pulses = 1
Distance coding: Pulse length 302317

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 302317

[00] {0} 00 : 00000000

signal_bszie = 655360 - sg_index = 524288
start_pos = -313746 - buffer_size = 3145728
restart_pos = 2831982

Hello,

i'm working on vairous project to add OSV protocol 3 sensor

on devices/oregon_scientific.c

line 243 you decode a thgr810 sensor and that works great !

i want to add pcr800 (rain gauge) and wgr800 (wind gauge)

actually working on PCR800 i'm facing a bad chacksum calculation.

i'm sure my problem is line 244

if (validate_os_checksum(msg, 15) == 0) {

how get 15 ?

my PCR 800 sensor message is like this :

/* PCR800 Rain Gauge Sample Data:
// 0 1 2 3 4 5 6 7 8 9 A
// A2 91 40 50 93 39 33 31 10 08 02
// 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5
// 10100010 10010001 01000000 01010000 10010011 00111001 00110011 00110001 00010000 00001000 00000010
// -------- ------- bbbb--- RRRRRRRR 88889999 AAAABBBB CCCCDDDD EEEEFFFF 00001111 2222CCCC cccc

// byte(0)_byte(1) = Sensor ID
// bbbb = Battery indicator(7) My investigations on the anemometer would disagree here.
// After exhaustive low battery tests these bbbb bits did not change
// RRRRRRRR = Rolling Code Byte
// 222211110000.FFFFEEEEDDDD = Total Rain Fall (inches)
// CCCCBBBB.AAAA99998888 = Current Rain Rate (inches per hour)
// ccccCCCC = 1 byte Checksum cf. sum of nybbles
// Message length is 20 nybbles so working in inches

Information from lostbit arduino osv3 logger

did some one can help me ?

I am trying to get the TX7U sensor to work. As I understand it it presently does not work.

Here is an example frame I was able to capture with my radio shack scanner antenna and "rtl_433 -a -l 800":
[00] {44} f5 f6 88 87 88 10 : 11110101 11110110 10001000 10000111 10001000 00010000

27.8 degrees celsius is the correct temperature decode for the above frame.

As I understand it (according to http://forum.arduino.cc/index.php?topic=155483.0), this breaks down as follows:

|11110101 1111|0110 100|0|1000| 1000|0111| ... this I don't know: 10001000 00010000
| MODEL ID |SENSORID|P|TENS|ONES|TENTHS|
Where the TENS position is subtracted from ten, and the ones and tenths position are subtracted from 15 to yield the actual values at those positions.
so, 10-TENS = X * 10^1
15 - ONES = X * 10^0
15 - TENTHS = X * 10^-1

That's for the temperature. As for the humidity, I am also getting two frames in sequence per cycle that look like this:

11110101 00010110 1000|1010 _1110_1111 10101110 10110000

with a different model Id, but sent very shortly after the first two frames that have the 11110101 1111 in the header portion that contain valid temperatures. The humidity ones place is starred (subtract from 15).

I've written a few scripts, that when run simultaneously, report the temperature and humidity, but, I am not sure about the TENS place in the humidity, and at least 2 times in the cycle, an unusual alternating temperature (1111) and humidity (0001) frame appears, but with invalid humidity data.

I may be receiving data from two different sensors. I am not sure.

Thanks,

Michael Sabino

Below is a bash script that will decode the temperature and humidity that I've been using (sorry if the bash looks hackish, I haven't done much of this):

Bash script I've been using to decode: http://pastebin.com/gXHink2c

Hi,
I'm trying to decode frames of the above transmitter by recording about 15 seconds frames of 2 transmitters near by the rtl-dongle via rtl_fm. Every frame is Manchester encoded and has 10 bit preamble(unknown), 24 bit address, 192 bit payload and 16 bit CRC. How i have to create a new protocol, or what i have to to do to get this frames decoded. When i run rtl_433 (see below) i get some results and the final result of 38 detected packets is looking good.
Please have a look to the results of rtl_433.
Thanks for all
Fritz

BBb:root@~/rtl_433/build/src# ./rtl_433 -a -t -m 0 -r 2xflarm
output:
Registering protocol[01] Rubicson Temperature Sensor
Registering protocol[02] Prologue Temperature Sensor
Registering protocol[03] Silvercrest Remote Control
Registering protocol[04] ELV EM 1000
Registering protocol[05] ELV WS 2000
Registering protocol[06] Waveman Switch Transmitter
Registering protocol[07] Steffen Switch Transmitter
No supported devices found.
Found 0 device(s):

Using device 0:
Failed to open rtlsdr device #0.
WARNING: Failed to set sample rate.
Sample rate decimation set to 0. 250000->250000
Bit detection level set to 10000.
WARNING: Failed to enable automatic gain.
Test mode active. Reading samples from file: 2xflarm
*** signal_start = 25270, signal_end = 104342
signal_len = 79072, pulses = 35
Iteration 1. t: 28 min: 12 (19) max: 44 (16) delta 277
Iteration 2. t: 28 min: 12 (19) max: 44 (16) delta 0
Pulse coding: Short pulse length 12 - Long pulse length 44

Short distance: 190, long distance: 21319, packet distance: 30703

p_limit: 28

[00] {9} 30 00 : 00110000 00000000
[01] {26} b8 5b e3 00 : 10111000 01011011 11100011 00000000

signal_bszie = 262144 - sg_index = 393216
start_pos = -53462 - buffer_size = 3145728
restart_pos = 3092266
*** Saving signal to file gfile001.data
*** Writing data from 3092266, len 53462
*** Writing data from 0, len 208682
*** signal_start = 150757, signal_end = 227118
signal_len = 76361, pulses = 29
Iteration 1. t: 30 min: 12 (6) max: 48 (23) delta 325
Iteration 2. t: 30 min: 12 (6) max: 48 (23) delta 0
Pulse coding: Short pulse length 12 - Long pulse length 48

Short distance: 38, long distance: 14392, packet distance: 25445

p_limit: 30

[00] {21} fe fe 38 : 11111110 11111110 00111000
[01] {8} 77 00 : 01110111 00000000

signal_bszie = 262144 - sg_index = 655360
start_pos = 192090 - buffer_size = 3145728
*** Saving signal to file gfile002.data
*** Writing data from 192090, len 262144
*** signal_start = 264904, signal_end = 316123
signal_len = 51219, pulses = 28
Iteration 1. t: 29 min: 13 (9) max: 45 (19) delta 317
Iteration 2. t: 29 min: 13 (9) max: 45 (19) delta 0
Pulse coding: Short pulse length 13 - Long pulse length 45

Short distance: 46, long distance: 3156, packet distance: 22799

p_limit: 29

[00] {14} 1f fc : 00011111 11111100
[01] {14} e6 e0 : 11100110 11100000

signal_bszie = 131072 - sg_index = 786432
start_pos = 501172 - buffer_size = 3145728
*** Saving signal to file gfile003.data
*** Writing data from 501172, len 131072
*** signal_start = 378257, signal_end = 450554
signal_len = 72297, pulses = 28
Iteration 1. t: 28 min: 10 (3) max: 47 (25) delta 218
Iteration 2. t: 28 min: 10 (3) max: 47 (25) delta 0
Pulse coding: Short pulse length 10 - Long pulse length 47

Short distance: 99, long distance: 11141, packet distance: 37554

p_limit: 28

[00] {13} 7f f8 : 01111111 11111000
[01] {15} fb f6 : 11111011 11110110

signal_bszie = 262144 - sg_index = 1048576
start_pos = 638962 - buffer_size = 3145728
*** Saving signal to file gfile004.data
*** Writing data from 638962, len 262144
*** signal_start = 490492, signal_end = 900535
signal_len = 410043, pulses = 107
Iteration 1. t: 31 min: 15 (25) max: 48 (82) delta 394
Iteration 2. t: 31 min: 15 (24) max: 48 (83) delta 0
Pulse coding: Short pulse length 15 - Long pulse length 48

Short distance: 146, long distance: 20876, packet distance: 45209

p_limit: 31

[00] {27} 3b fc ef 00 : 00111011 11111100 11101111 00000000
[01] {13} ef 98 : 11101111 10011000
[02] {14} b3 74 : 10110011 01110100
[03] {27} ff d8 3f e0 : 11111111 11011000 00111111 11100000
[04] {12} ff f0 : 11111111 11110000
[05] {14} fb fc : 11111011 11111100

signal_bszie = 917504 - sg_index = 1966080
start_pos = 883564 - buffer_size = 3145728
*** Saving signal to file gfile005.data
*** Writing data from 883564, len 917504
*** signal_start = 940261, signal_end = 1099902
signal_len = 159641, pulses = 52
Iteration 1. t: 32 min: 17 (10) max: 47 (42) delta 452
Iteration 2. t: 32 min: 17 (10) max: 47 (42) delta 0
Pulse coding: Short pulse length 17 - Long pulse length 47

Short distance: 246, long distance: 19864, packet distance: 47140

p_limit: 32

[00] {27} 37 f5 fe e0 : 00110111 11110101 11111110 11100000
[01] {25} e6 ff fd 80 : 11100110 11111111 11111101 10000000

signal_bszie = 393216 - sg_index = 2359296
start_pos = 1806586 - buffer_size = 3145728
*** Saving signal to file gfile006.data
*** Writing data from 1806586, len 393216
*** signal_start = 1179598, signal_end = 1448913
signal_len = 269315, pulses = 87
Iteration 1. t: 29 min: 11 (18) max: 48 (69) delta 353
Iteration 2. t: 29 min: 11 (18) max: 48 (69) delta 0
Pulse coding: Short pulse length 11 - Long pulse length 48

Short distance: 194, long distance: 16665, packet distance: 36169

p_limit: 29

[00] {14} 77 38 : 01110111 00111000
[01] {16} ef db 00 : 11101111 11011011 00000000
[02] {15} 3b fc : 00111011 11111100
[03] {14} fd f4 : 11111101 11110100
[04] {15} f7 7a : 11110111 01111010
[05] {13} f7 f8 : 11110111 11111000

signal_bszie = 655360 - sg_index = 3014656
start_pos = 2242464 - buffer_size = 3145728
*** Saving signal to file gfile007.data
*** Writing data from 2242464, len 655360
*** signal_start = 1499288, signal_end = 1547814
signal_len = 48526, pulses = 26
Iteration 1. t: 32 min: 19 (7) max: 46 (19) delta 452
Iteration 2. t: 32 min: 19 (7) max: 46 (19) delta 0
Pulse coding: Short pulse length 19 - Long pulse length 46

Short distance: 70, long distance: 7297, packet distance: 18581

p_limit: 32

[00] {13} 36 f0 : 00110110 11110000
[01] {13} ff c8 : 11111111 11001000

signal_bszie = 131072 - sg_index = 131072
start_pos = -181174 - buffer_size = 3145728
restart_pos = 2964554
*** Saving signal to file gfile008.data
*** Writing data from 2964554, len 131072
*** signal_start = 1613040, signal_end = 1794649
signal_len = 181609, pulses = 52
Iteration 1. t: 30 min: 13 (11) max: 48 (41) delta 317
Iteration 2. t: 29 min: 11 (10) max: 47 (42) delta 5
Iteration 3. t: 26 min: 7 (8) max: 46 (44) delta 17
Iteration 4. t: 26 min: 7 (8) max: 46 (44) delta 0
Pulse coding: Short pulse length 7 - Long pulse length 46

Short distance: 277, long distance: 20108, packet distance: 43198

p_limit: 26

[00] {14} fe 5c : 11111110 01011100
[01] {13} f1 f8 : 11110001 11111000
[02] {25} fa ff ff 80 : 11111010 11111111 11111111 10000000

signal_bszie = 393216 - sg_index = 524288
start_pos = 50352 - buffer_size = 3145728
*** Saving signal to file gfile009.data
*** Writing data from 50352, len 393216
*** signal_start = 1852528, signal_end = 1917329
signal_len = 64801, pulses = 28
Iteration 1. t: 29 min: 11 (7) max: 48 (21) delta 146
Iteration 2. t: 29 min: 11 (7) max: 48 (21) delta 0
Pulse coding: Short pulse length 11 - Long pulse length 48

Short distance: 40, long distance: 2500, packet distance: 37743

p_limit: 29

[00] {13} f7 f8 : 11110111 11111000
[01] {15} 23 be : 00100011 10111110

signal_bszie = 131072 - sg_index = 786432
start_pos = 557856 - buffer_size = 3145728
*** Saving signal to file gfile010.data
*** Writing data from 557856, len 131072
Iteration 1. t: 31 min: 14 (32) max: 48 (110) delta 377
Iteration 2. t: 30 min: 14 (31) max: 47 (111) delta 1
Iteration 3. t: 30 min: 13 (30) max: 47 (112) delta 1
Iteration 4. t: 30 min: 13 (30) max: 47 (112) delta 0
Pulse coding: Short pulse length 13 - Long pulse length 47

Short distance: 174, long distance: 24823, packet distance: 40667

p_limit: 30

[00] {32} 7e b8 ff d7 00 : 01111110 10111000 11111111 11010111 00000000
[01] {27} f3 3f 7e e0 : 11110011 00111111 01111110 11100000
[02] {6} fc : 11111100
[03] {19} ff ef e0 : 11111111 11101111 11100000
[04] {30} b6 7d 37 fc : 10110110 01111101 00110111 11111100
[05] {15} e7 be : 11100111 10111110
[06] {13} 2f e8 : 00101111 11101000

Test mode file issued 38 packets
Filter coeffs used:
a: 32768 31754
b: 506 506
BBb:root@~/rtl_433/build/src#

Sorry, Iam linux noob, but how to install your files? ./configure && make && make install seems not the right way

Does any have an idea why rtl_444 generates segfault? I use it under i386, but moved into amd64, githubbed clean repo, cmake, make, rtl_433 ->
Registering protocol[01] Rubicson Temperature Sensor
Registering protocol[02] Prologue Temperature Sensor
Registering protocol[03] Silvercrest Remote Control
Registering protocol[04] ELV EM 1000
Registering protocol[05] ELV WS 2000
Registering protocol[06] Waveman Switch Transmitter
Registering protocol[07] Steffen Switch Transmitter
Registering protocol[08] Acurite 5n1 Weather Station
Segfault

dmesg shows:

[14190.217587] rtl_433[21585]: segfault at 0 ip 00007fa33d944294 sp 00007fff96da4e90 error 4 in libc-2.13.so[7fa33d89c000+182000]
[14195.813128] rtl_433[21586]: segfault at 0 ip 00007f163b58d294 sp 00007fff494fab00 error 4 in libc-2.13.so[7f163b4e5000+182000]
[14220.146136] rtl_433[21592]: segfault at 0 ip 00007f67074c7294 sp 00007fff670af930 error 4 in libc-2.13.so[7f670741f000+182000]
[14857.105725] rtl_433[22594]: segfault at 0 ip 00007f5a2bb51294 sp 00007fff6edad4e0 error 4 in libc-2.13.so[7f5a2baa9000+182000]

Hello,
Can you please add support for Auriol weather station? Or guide me how to do it? Here is the protocol spec: http://www.tfd.hu/tfdhu/files/wsprotocol/auriol_protocol_v20.pdf
And here is output of rtl_433 -a -D: http://pastebin.com/DRJs3mFV

It would be nice if we could use packet length further narrow down protocol detection to prevent false positives. I tried to implement it within the callback but I think I cannot access parameters to work things out.

Any hints about implementing this into rtl_433??

Hi!

Thanks for the nice work!

I am trying to comprehend the source, since I want to try to make it do more. One thing I lack is units (and more info) on the output from -a. I will keep digging through the code and try to decipher it,but for me, having reverse analyzed wireless ISM protocols with a logic analyzer and writing code to make an Arduino decode it, times in µs or ms is essential, and I would really love a graphical representation of the signal train (not necessarily from your code, could be optional output to file for visualization by other software.)

When working on your code I already replaced most of the output to stderr with the proper output to stdout, since I noticed that a simple output redirection would just give me an empty file.

I would like the decoders and all related code to be in either one file or maybe each decoder should have a file of its own.

I too am looking forward to decoding and implementing the Efergy protocoll, Elite in my case. My Arduino code already handles two different temperature sensors, one with humidity sensing too, but I never got around to the Efergy stuff.

What unit are the values for signal_start, signal_end, signal_len and so on?

The source mentions some different PWM protocols, but many of the simple wireless ISM protocols use some kind of Manchester encoding (that your software seems to be able to decode, non the less).

Timing is vital if you want to implement a transmitter. Consider the TellStick project, for example.

I am not sure whether to fork this project or try to contribute. (Another thing I do not understand/approve of is the inclusion of the entire rtl_sdr source tree, when rtl-sdr.h should be available after a successful installation of that part.)

I seem to be so close to cut the wire and use my Raspberry Pi for temperature logging. All my attempts with GPIO connected 433 MHz receivers failed. Now, with a SDR approach and your solution I seem to be close to the goal.

I have several sensors around the house, one of which also measures humidity. I am not sure if what I am receiving is coming from that sensor. I would already be happy to receive a temperature. Could you please assist me in interpreting the output (http://pastie.org/private/exdyxwgomasmfwcub0pkfw)? The only pattern I see are static zeroes and ones, there is nothing, I think, that could be an identifier.

Your feedback us greatly appreciated.