Interlogix door security sensor

[adam1010]

Hi all,

I'm having some trouble receiving binary data from my wireless door/window sensors. The devices run on 319.5Mhz with ASK encoding (Interlogix TX-1012-01-1)

The analyzer sees the signal when I open my door and recommends some settings, but the data it shows is always just lots of zeros. I should be fine decoding the protocol once I can record the bits.

Am I missing something fundamental? (I'm new to signal processing).  I would appreciate any help/advice.  Thank you!!


./rtl_433 -f 319500000 -g 22.9 -A -t sensor
....
Analyzing pulses...
Total count:   61,  width:  4850        (19.4 ms)
Pulse width distribution:
 [ 0] count:   59,  width:    34 [27;36]    ( 136 us)
 [ 1] count:    1,  width:   246 [246;246]    ( 984 us)
 [ 2] count:    1,  width:   125 [125;125]    ( 500 us)
Gap width distribution:
 [ 0] count:    1,  width:   121 [121;121]    ( 484 us)
 [ 1] count:   33,  width:    26 [25;28]    ( 104 us)
 [ 2] count:   26,  width:    56 [55;58]    ( 224 us)
Pulse period distribution:
 [ 0] count:    2,  width:   164 [148;180]    ( 656 us)
 [ 1] count:    1,  width:   271 [271;271]    (1084 us)
 [ 2] count:   32,  width:    60 [58;62]    ( 240 us)
 [ 3] count:   25,  width:    91 [90;93]    ( 364 us)
Level estimates [high, low]:  15921,     41
Frequency offsets [F1, F2]:   -1967,      0    (-7.5 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with startbit/delimiter
Attempting demodulation... short_limit: 79, long_limit: 185, reset_limit: 122, demod_arg: 1
pulse_demod_pwm_ternary(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {56} 40 00 00 00 00 00 00
[01] {4} 00 : 0000

[Benjamin Larsson]

On 07/08/2016 09:03 AM, adam1010 wrote:
> Hi all,
>
> I'm having some trouble receiving binary data from my wireless
> door/window sensors. The devices run on 319.5Mhz with ASK encoding
> (Interlogix TX-1012-01-1

> <http://www.interlogix.com/intrusion/product/micro-door-window-sensors>)

>
> The analyzer sees the signal when I open my door and recommends some
> settings, but the data it shows is always just lots of zeros. I should
> be fine decoding the protocol once I can record the bits.
>
> Am I missing something fundamental? (I'm new to signal processing). I
> would appreciate any help/advice. Thank you!!
>

Hello

Running src/rtl_433 -D -D -l 0 -r ../sensor gives the following output
for the last packet.

Pulse data: 61 pulses
[ 0] Pulse: 41, Gap: 112, Period: 153
[ 1] Pulse: 249, Gap: 27, Period: 276 <-- preamble ends here
[ 2] Pulse: 33, Gap: 26, Period: 59
[ 3] Pulse: 34, Gap: 27, Period: 61
[ 4] Pulse: 34, Gap: 27, Period: 61
[ 5] Pulse: 34, Gap: 27, Period: 61
[ 6] Pulse: 34, Gap: 25, Period: 59
[ 7] Pulse: 35, Gap: 26, Period: 61
[ 8] Pulse: 35, Gap: 26, Period: 61
[ 9] Pulse: 34, Gap: 27, Period: 61
[ 10] Pulse: 34, Gap: 27, Period: 61
[ 11] Pulse: 34, Gap: 27, Period: 61
[ 12] Pulse: 34, Gap: 27, Period: 61
[ 13] Pulse: 33, Gap: 56, Period: 89
[ 14] Pulse: 35, Gap: 26, Period: 61
[ 15] Pulse: 34, Gap: 27, Period: 61
[ 16] Pulse: 34, Gap: 57, Period: 91
[ 17] Pulse: 34, Gap: 58, Period: 92
[ 18] Pulse: 33, Gap: 58, Period: 91
[ 19] Pulse: 33, Gap: 57, Period: 90
[ 20] Pulse: 34, Gap: 56, Period: 90
[ 21] Pulse: 35, Gap: 27, Period: 62
[ 22] Pulse: 34, Gap: 26, Period: 60
[ 23] Pulse: 34, Gap: 57, Period: 91
[ 24] Pulse: 34, Gap: 56, Period: 90
[ 25] Pulse: 35, Gap: 27, Period: 62
[ 26] Pulse: 34, Gap: 26, Period: 60
[ 27] Pulse: 34, Gap: 58, Period: 92
[ 28] Pulse: 33, Gap: 57, Period: 90
[ 29] Pulse: 34, Gap: 57, Period: 91
[ 30] Pulse: 34, Gap: 27, Period: 61
[ 31] Pulse: 34, Gap: 56, Period: 90
[ 32] Pulse: 35, Gap: 56, Period: 91
[ 33] Pulse: 35, Gap: 26, Period: 61
[ 34] Pulse: 34, Gap: 27, Period: 61
[ 35] Pulse: 34, Gap: 57, Period: 91
[ 36] Pulse: 34, Gap: 27, Period: 61
[ 37] Pulse: 33, Gap: 58, Period: 91
[ 38] Pulse: 33, Gap: 28, Period: 61
[ 39] Pulse: 33, Gap: 58, Period: 91
[ 40] Pulse: 33, Gap: 27, Period: 60
[ 41] Pulse: 33, Gap: 28, Period: 61
[ 42] Pulse: 33, Gap: 58, Period: 91
[ 43] Pulse: 33, Gap: 58, Period: 91
[ 44] Pulse: 33, Gap: 26, Period: 59
[ 45] Pulse: 35, Gap: 56, Period: 91
[ 46] Pulse: 35, Gap: 26, Period: 61
[ 47] Pulse: 34, Gap: 57, Period: 91
[ 48] Pulse: 34, Gap: 27, Period: 61
[ 49] Pulse: 34, Gap: 57, Period: 91
[ 50] Pulse: 34, Gap: 27, Period: 61
[ 51] Pulse: 33, Gap: 58, Period: 91
[ 52] Pulse: 33, Gap: 27, Period: 60
[ 53] Pulse: 34, Gap: 56, Period: 90
[ 54] Pulse: 35, Gap: 26, Period: 61
[ 55] Pulse: 35, Gap: 26, Period: 61
[ 56] Pulse: 125, Gap: 58, Period: 183 <-- packet end starts here
[ 57] Pulse: 33, Gap: 27, Period: 60
[ 58] Pulse: 34, Gap: 58, Period: 92
[ 59] Pulse: 33, Gap: 57, Period: 90
[ 60] Pulse: 34, Gap: 2501, Period: 2535

As the pulse is of the same length but the gap varies the modulation is
pulse position on off keying. Try setting the short limit to ((27+57)/2)
* 4. Because the signal has this preamble and packet end, it confuses
the analyzer so much that it can't guess the correct parameters to
decode this. Setting the correct settings in a decoder should output
valid data.

MvH
Benjamin Larsson

[adam1010]

Hi Benjamin -- Thank you so much for the assistance!

I've created a basic decoder/driver that just prints out the bitbuffer -- with the updated short_limit it's now basically just printing out a constant stream of 1s. I can post my code if that would help, but I've pasted the demodulation settings below.  This is probably a stupid question, but how can we be sure that it's using PWM? With OOK/ASK can't the gaps mean 0 and pulses mean 1  (versus PWM where gaps are ignored and the pulses can be either 0 or 1 depending on their characteristics)?  Or does OOK/ASK always need to be used in conjunction with PWM/PPM?

r_device interlogix = {
        .name                   = "Interlogix",
        .modulation           = OOK_PULSE_PWM_RAW,
        .short_limit            = ((27+57)/2) * 4,
        .long_limit             = 185,
        .reset_limit            = 122,
        .json_callback       = &interlogix_callback,
        .disabled               = 0,
        .demod_arg           = 0
};

[Benjamin Larsson]

On 07/08/2016 12:11 PM, adam1010 wrote:
> Hi Benjamin -- Thank you so much for the assistance!
>
> I've created a basic decoder/driver that just prints out the bitbuffer
> -- with the updated short_limit it's now basically just printing out a
> constant stream of 1s. I can post my code if that would help, but I've
> pasted the demodulation settings below. This is probably a stupid
> question, but how can we be sure that it's using PWM? With OOK/ASK can't
> the gaps mean 0 and pulses mean 1 (versus PWM where gaps are ignored
> and the pulses can be either 0 or 1 depending on their
> characteristics)? Or does OOK/ASK always need to be used in conjunction
> with PWM/PPM?
>
> r_device interlogix = {
> .name = "Interlogix",
> .modulation = OOK_PULSE_PWM_RAW,
> .short_limit = ((27+57)/2) * 4,
> .long_limit = 185,
> .reset_limit = 122,
> .json_callback = &interlogix_callback,
> .disabled = 0,
> .demod_arg = 0
> };
>

You need to use the PPM demod. The reset limit should be 5000 or so.

MvH
Benjamin Larsson

[adam1010]

Thanks for the feedback Benjamin!

The output improved to show more rows but it's still just zeros:

./src/rtl_433 -f 319500000 -g 22.9 -l 0
....
bitbuffer:: Number of rows: 25
[00] {0} :
[01] {12} 00 00 : 00000000 0000
[02] {2} 00 : 00
[03] {0} :
[04] {0} :
[05] {0} :
[06] {0} :
[07] {2} 00 : 00
[08] {0} :
[09] {2} 00 : 00
[10] {0} :
[11] {0} :
[12] {1} 00 : 0
[13] {0} :
[14] {2} 00 : 00
[15] {1} 00 : 0
[16] {0} :
[17] {0} :
[18] {0} :
[19] {1} 00 : 0
[20] {0} :
[21] {1} 00 : 0
[22] {1} 00 : 0
[23] {1} 00 : 0
[24] {7} 00 : 0000000

My current configuration is:

{
        .name                   = "Interlogix ",
        .modulation             = OOK_PULSE_PPM_RAW,

        .short_limit    = ((27+57)/2) * 4,
        .long_limit             = 185,

        .reset_limit    = 5000,
        .disabled               = 0,
        .demod_arg              = 0,

[Tommy Vestermark]

Hi Adam,

I think your ".long_limit" is too short causing the many rows. It is a bit confusing, but the limits were changed to be in units of microseconds, whereas the pulse debug data is in number of samples - hence the factor of 4 (with the default sample rate of 250kHz).

So your .long_limit should be a bit more than four times the maximum gap (4*58), so try to set the .long_limit to 300 us.
 
A .reset_limit of 5000 is a bit excessive and will make the decoder prone to merging closely spaced transmissions from other transmitters. A tighter .reset_limit will make the package detection more robust. Try setting it to a bit more than 4 times the long preamble gap (4*112), e.g. 500 us.

Have fun
Tommy

[Benjamin Larsson]

On 07/09/2016 08:36 AM, adam1010 wrote:
> Thanks for the feedback Benjamin!
>

Hi, I have added a decoder template that works with your sample file.
Try it with:

rtl_433 -R 61 -D -F json -r sensor


Registering protocol "Template decoder"
Test mode active. Reading samples from file: ../sensor
Input format: uint8
Template decoder debug section
{"time" : "@8.388608s", "model" : "Template", "type" : "Test"}
pulse_demod_ppm(): Template decoder

bitbuffer:: Number of rows: 2

[00] {0} :
[01] {59} 00 09 f3 3b 2a 6a a9 60
Template decoder debug section
{"time" : "@8.912896s", "model" : "Template", "type" : "Test"}
pulse_demod_ppm(): Template decoder

bitbuffer:: Number of rows: 2

[00] {0} :
[01] {59} 00 09 f3 3b 2a 6a a9 60
Template decoder debug section
{"time" : "@9.437184s", "model" : "Template", "type" : "Test"}
pulse_demod_ppm(): Template decoder

bitbuffer:: Number of rows: 2

[00] {0} :
[01] {59} 00 09 f3 3b 2a 6a a9 60
Template decoder debug section
{"time" : "@9.961472s", "model" : "Template", "type" : "Test"}
pulse_demod_ppm(): Template decoder

bitbuffer:: Number of rows: 2

[00] {0} :
[01] {59} 00 09 f3 3b 2a 6a a9 60
Template decoder debug section
{"time" : "@10.485760s", "model" : "Template", "type" : "Test"}
pulse_demod_ppm(): Template decoder

bitbuffer:: Number of rows: 2

[00] {0} :
[01] {59} 00 09 f3 3b 2a 6a a9 60
Test mode file issued 28 packets



This looks like some what usable data. Make sure to tune the reset_limit.

MvH
Benjamin Larsson

[adam1010]

Benjamin and Tommy -- Thank you SO much for your help!

I'm definitely getting the data coming through now and I think I've deciphered which bit indicates if the door is open (along with the bits that belong to the serial number). I'll need a few more days of testing to be sure.

A  few follow-up questions

1) Is the empty row of zero bits something I can set the configuration to ignore or do I just code around it?

2) Since there is redundancy where the sensor sends out several exact copies of the message -- is there a way to ignore the follow-up messages so only 1 event is recorded?  (Or to be able to compare and then only process the most common version of the message -- ie assuming a couple copies have some errors)

3) Do you know of any Youtube videos or other tutorials that would explain the process you went through when deciding PPM vs PWM and what the decoder timings should be? I would love to be able to figure out new signals going forward.

3) From my earlier question -- does ASK/OOK always have to be used in conjunction with PPM or PWM, or can it be used by itself?  I think I've seen some tutorial videos where people use the gaps to mean 0 and the pulses to mean 1 (instead of with PPM/PWM where gaps mean nothing and pulses either mean 1 or 0 depending on the modulation type). 

Again, I can't thank you enough for your help.

Cheers,
Adam

[Benjamin Larsson]

Hi.

On 07/14/2016 11:02 AM, adam1010 wrote:
> Benjamin and Tommy -- Thank you SO much for your help!
>
> I'm definitely getting the data coming through now and I think I've
> deciphered which bit indicates if the door is open (along with the bits
> that belong to the serial number). I'll need a few more days of testing
> to be sure.
>
> A few follow-up questions
>
> 1) Is the empty row of zero bits something I can set the configuration
> to ignore or do I just code around it?

The first row with 0 is a property of the signal and the demodulator.
Just use row 1+.

>
> 2) Since there is redundancy where the sensor sends out several exact
> copies of the message -- is there a way to ignore the follow-up messages
> so only 1 event is recorded? (Or to be able to compare and then only
> process the most common version of the message -- ie assuming a couple
> copies have some errors)

No, this something for the upper layer to handle, the purpose of rtl_433
is to just relay the data as unaltered as possible. One option is to add
a filter like the one for conversion to si units (-C si).

>
> 3) Do you know of any Youtube videos or other tutorials that would
> explain the process you went through when deciding PPM vs PWM and what
> the decoder timings should be? I would love to be able to figure out new
> signals going forward.

Sorry I did write some docs for it but lost it in a file system
corruption. I have it on my todo list to rewrite it but never got the
motivation.

>
> 3) From my earlier question -- does ASK/OOK always have to be used in
> conjunction with PPM or PWM, or can it be used by itself? I think I've
> seen some tutorial videos where people use the gaps to mean 0 and the
> pulses to mean 1 (instead of with PPM/PWM where gaps mean nothing and
> pulses either mean 1 or 0 depending on the modulation type).

There are 3 ways to do it with OOK.

Fixed length of pulses, varying the length of gaps. -> PPM
Varying the length of pulses, fixed length of gaps. -> PWM
Varying the length of pulses, varying the length of gaps. -> PWM

How you map bits depends on how complex you want to do it.

>
> Again, I can't thank you enough for your help.
>
> Cheers,
> Adam

MvH
Benjamin Larsson

[Brent Bailey]

Hi Adam,

Can I help with this?  Do you or Benjamin still have the decoder template that was showing data?

Thanks,

Brent Bailey

[adam1010]

Hey Brent,

What's your question? I implemented the driver for it a year or so ago and haven't had any trouble with it. Are you not picking up any signals?

Thanks,
Adam

[Brent Bailey]

I don't see it in the repo?  

https://github.com/merbanan/rtl_433/tree/master/src/devices

Am I overlooking it? 

[adam1010]

Hey Brent,

You're right -- I apologize for the confusion. I was thinking of the GE window/door sensor driver that I wrote.

I was never able to fully reverse engineer the Interlogix protocol. I gave up and bought GE sensors instead. On that note, I do have 4 Interlogix sensors I can sell you really cheap :-)

Cheers,
Adam

[Brent Bailey]

Ah ok.  It might have been something as simple as the frequencies being off.  Can you point me to the decoder template that was showing some data?

Thanks

Brent

--
You received this message because you are subscribed to a topic in the Google Groups "rtl_433" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtl_433/edm1gmOXCzc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtl_433+unsubscribe@googlegroups.com.
To post to this group, send email to rtl...@googlegroups.com.
Visit this group at https://groups.google.com/group/rtl_433.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/d0198a3b-79a6-4720-87c9-032b89551e6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[adam1010]

Hey Brent,

I don't have any of the driver code other than the fragments I posted above (like the OOK_PULSE_PWM_RAW  settings for the driver).

You can take a pretty simpler driver (like my GE/Honeywell one) and strip out all the bitmask / manipulation stuff (and replace the r_device profile at the bottom with the one earlier in this thread) and that should give you a pretty good starting point. To make it easier I just directly edit an existing driver when I'm first starting out and then re-compile (versus trying to register a new driver from the start).

Cheers,
Adam

To unsubscribe from this group and all its topics, send an email to rtl_433+u...@googlegroups.com.

[Brent Bailey]

Thanks Adam.

Benjamin, if you have any of the settings you used or the original template that showed some data, will you let me know?

Thank you!

[Brent Bailey]

I have this pretty well tested and decoding properly (just need to work through validating the crc checksum) but I am still trying to think through the best way to handle the multiple packets sent by these devices.

The devices emit 3 duplicate messages when there is a 'poll' message and they emit 8 duplicate messages when there is a state change message. I see that some of the other device code is written to loop through multiple rows/messages to handle situations similar to this but I am not sure that this approach will work for these devices. In the situation where 8 messages are emitted, the total duration of the 8 messages is almost 2.5 seconds. I assume that waiting this long to capture all 8 messages would be problematic in a 'noisy' environment where there are 25+ devices all emitting data.

I guess in summary, I wanted to confirm that handling duplicate messages like this really should be done outside of the rtl_433 template. If so I need to think through how to build a state machine in my code to deal with normally open or normally closed devices.

[Benjamin Larsson]

Yes, 2.5 seconds is too long for a protocol handler to emit only one
output message. The exact limit is not known, but it should correlate to
the maximum length of other devices transmitting on the same band.

The main idea to get rid of duplicates is to add time based hash table.
So if the signal content is the same as the previous within the last 1
second then do not output it.

MvH
Benjamin Larsson

[Christian Zuckschwerdt]

The typical reset_limit is below 10ms. If the packet spacing is bigger or the whole transmission is rather long (2.5s seems a bit much) I wouldn't try to coerce a single bitbuffer, especially if there is a CRC. Like you say, using a script to process single JSON messages will be the best option.

[Robert Terzi]

Lately I've been thinking the structured data output module would be a better place to suppress duplicate messagess (along with a setting for what interval to suppress) rather than complicating all the device handlers.

--Rob

[Christian Zuckschwerdt]

Always important to keep a balance, and perhaps sometimes re-evaluate design deciscions. There doesn't seem to be a one-size-fits-all solution. Not all decoders benefit from a simpler approach: a small number of repeats in a quick burst might been seen as "the protocol" and not "retrying a transmission", i.e. the decoder can judge the data based on a recuring pattern (or even apply a majority rule), especially in absence on any MIC.
On the other hand I can see decoders start "spamming" (some smoke detectors and alike will output a continous transmission) and some smart rate limiting of dups could help.

[Robert Terzi]

Security sensors are going to have different requirements than weather/environmental sensors. However, they may share the same frequency and receiver.  If a door opens and closes twice within a second or two, is that a duplicate or not?   Clearly, it depends on the application.

Personally, I think it should be up to the consumer to make it's own judgements about what is a duplicate based on the application.  I think rtl_433 ought to provide access to the messages and get out of the way.  I think that's particularly the case for security sensors.

However, I understand there are users of rtl_433 that are just logging to a file, possibly CSV, so duplicate suppression is more important. Additionally hey might want duplicate suppression that goes beyond a single burst.  For example, the Acurite tower temperature/humidity sensors that transmits every 18 seconds, you might want to suppress to 1,2 or 5 minute intervals for typical environmental monitoring.

[Benjamin Larsson]

On 12/06/2017 06:14 PM, Robert Terzi wrote:
> Security sensors are going to have different requirements than
> weather/environmental sensors. However, they may share the same
> frequency and receiver.  If a door opens and closes twice within a
> second or two, is that a duplicate or not?   Clearly, it depends on the
> application.
>
> Personally, I think it should be up to the consumer to make it's own
> judgements about what is a duplicate based on the application.  I think
> rtl_433 ought to provide access to the messages and get out of the way.
> I think that's particularly the case for security sensors.
>
> However, I understand there are users of rtl_433 that are just logging
> to a file, possibly CSV, so duplicate suppression is more important.
> Additionally hey might want duplicate suppression that goes beyond a
> single burst.  For example, the Acurite tower temperature/humidity
> sensors that transmits every 18 seconds, you might want to suppress to
> 1,2 or 5 minute intervals for typical environmental monitoring.

Agree on all points. rtl_433 should give the user granular information
depending on the application. But it should have a sane default. Anyway
a configurable duplicate suppression step should address all needs for
this. Now all that is needed is that someone writes the code ... (too
many kids exception for me)

MvH
Benjamin Larsson

[Robert Terzi]

On 12/6/2017 10:53 AM, Brent Bailey wrote:
> The devices emit 3 duplicate messages when there is a 'poll' message and they emit 8 duplicate messages when there is a state change message. I see that some of the other device code is written to loop through multiple rows/messages to handle situations similar to this but I am not sure that this approach will work for these devices. In the situation where 8 messages are emitted, the total duration of the 8 messages is almost 2.5 seconds. I assume that waiting this long to capture all 8 messages would be problematic in a 'noisy' environment where there are 25+ devices all emitting data.

Note: The longer the reset limit, the greater the chance that a bitbuffer would contain messages from multiple devices or more than 1 message from a single device.   What does the Interlogix sensor do with a fast open and close?  Does it preempt any of the repeats, or is it transmitting for up to 5 seconds?   If all the sensors use the same protocol, it's possible a door and a motion sensor might be tripped within a second of each other and could wind up in the same bitbuffer with a longer reset limit.  I think the notion that a bitbuffer will contain one complete transmission cycle with all the repeats from a single device is problematic, particularly in terms of robustness.

BTW, I think the number of repeats the Interlogix sensors send is actually a good thing.  The DSC sensors I'm using only transmit 4 times on events, and 2 times on "heartbeats", making the probability that an event could be lost somewhat higher than I'd like.

[Benjamin Larsson]

On 12/06/2017 06:35 PM, Robert Terzi wrote:
> I think the notion that a bitbuffer will
> contain one complete transmission cycle with all the repeats from a
> single device is problematic, particularly in terms of robustness.

The first object model was based on each protocol creating it's own
demodulator flow. To be able to scale I switched to the current model.
While I tend to think that the current model is not optimal it is able
to handle most signals good enough. The more processing power you
through on signal handling the better reception you get.

The thing with the current design is that you can redo the individual
steps on their own. The step we are discussion now is the framing of
signals. In theory we could expand this step and frame a signal several
times, demodulate it and then feed it though the protocol decode step.
And output differently depending on the outcome.

To illustrate better lets say we frame a signal with a 1 second
duration. At the start of the signal protocol A is transmitting for 0.75
seconds. After 0.25 seconds protocol B starts transmitting for 0.75
seconds. The current design will just feed the whole 1 second signal to
the demodulator and then through the protocol decoding step and hope for
the best. Most likely only protocol A will get a message decoded and
then only if 1 or more repeats get though without signal overlap. If we
had dynamic framing we could send a 1 second frame though as well as
several other smaller frames with different interval in the main signal.
With this logic it would be possible for protocol B to get decoded also.

So more complexity but better in terms of robustness. And is it worth
the complexity and most important will anyone code it?

MvH
Benjamin Larsson

[Christian Zuckschwerdt]

In principle we could even decode both overlapping A and B in that example. The carrier won't be exactly the same, thus shifting the signal (complex multiplication with a sine, easy) and low-pass (needs cpu) or decimation will isolate the transmission. There is a catch (other than processing power) though: We'd need to make some assumptions (bandwidth, windows, ASK/FSK,... ).
I guess rtl_433's versatile nature blocks some of those specialized assumptions. (I experience CC1101 a much more reliable platform for single, very narrow, applications here.)

Maybe someone wants to add something in the spirit of tcpdump or socat, a PCAP-like recipe compiler -- feeding tailored protocol recipies to rtl_433!  The r_device timings mostly. It sure would be very handy for debugging/development (not talking about a GRC like level of complexity -- for the moment ;).

[Benjamin Larsson]

On 12/06/2017 07:59 PM, Christian Zuckschwerdt wrote:
> In principle we could even decode both overlapping A and B in that
> example. The carrier won't be exactly the same, thus shifting the signal
> (complex multiplication with a sine, easy) and low-pass (needs cpu) or
> decimation will isolate the transmission. There is a catch (other than
> processing power) though: We'd need to make some assumptions (bandwidth,
> windows, ASK/FSK,... ).
> I guess rtl_433's versatile nature blocks some of those specialized
> assumptions. (I experience CC1101 a much more reliable platform for
> single, very narrow, applications here.)

That would be a step before the current framing logic. But as you say
that needs more processing power in the form of band splitting filters.
But it would be possible to make it quite generic. Sample at max 2.56MHz
split the whole spectrum in 20 overlapping bands (via low-pass
decimation). Feed it though the framing logic and then through the
protocol decoding step. Then filter out the duplicates at the end.

>
> Maybe someone wants to add something in the spirit of tcpdump or socat,
> a PCAP-like recipe compiler -- feeding tailored protocol recipies to
> rtl_433!  The r_device timings mostly. It sure would be very handy for
> debugging/development (not talking about a GRC like level of complexity
> -- for the moment ;).

It would be nice with an sample input mode so other SDR hardware could
be used and a bitbuffer input mode.

MvH
Benjamin Larsson

[Christian Zuckschwerdt]

Sample at max 2.56MHz
split the whole spectrum in 20 overlapping bands (via low-pass
decimation). Feed it though the framing logic and then through the
protocol decoding step.

I tried this once, as I have senders that are quite far apart in the spectrum. And I fried a few cheap dongles along the way (at 3.2M bandwidth). The more expensive NooElec SMArt can handle the heat, custom heatsinks did help for a while. In the end I settled for multiple dongles at 1M bandwidth.

 

It would be nice with an sample input mode so other SDR hardware could
be used and a bitbuffer input mode.

I might have talked myself into something here. I think I'll try this parametrized general-decoder approach -- maybe just to stop people from writing scripts around -A/-a :p

For the opposite there is already -y <code> to test bitbuffers on the decoders.

Maybe we could explore SoapySDR, like rx_fm does for rtl_fm. But I'm not sure if people with a HackRF would use rtl_433 :)

[Benjamin Larsson]

On 12/06/2017 08:40 PM, Christian Zuckschwerdt wrote:
>
> Maybe we could explore SoapySDR, like rx_fm does for rtl_fm. But I'm not
> sure if people with a HackRF would use rtl_433 :)

One of my aims with rtl_433 was that people was going to turn to rtl_433
as a one stop shop for decoding signals instead of firing up GnuRadio
and friends. The -A analyzer is really capable but I think we need some
better modes and tools to visualize the data. Then I think people would
use rtl_433 because it would be so much faster to use compared to other
methods.

For example gnuplot output, wav file header generation for easy opening
in Audacity. Correct suffix of the signal files so Inspectrum would open
them directly. Command line options for signal demodulation. And a
in-depth tutorial covering signal analysis and writing a protocol decoder.

MvH
Benjamin Larsson

[Matthew Beals]

Benjamin,

Is the template you used to decode this the same as is currently in the repo (new_template.c)? I'm working on a slightly different interlogix sensor and the template isn't decoding anything. Before I dig in too deep, I wanted to make sure I was starting at the right place

[Brent Bailey]

Hey Matthew.  I wrote the logic for these devices but it hasn't been merged yet.  I am making a few enhancements to support key fobs and will submit another pull request shortly but in the meantime feel free to use the branch below.

https://github.com/baileybrent/rtl_433/blob/master/src/devices/interlogix.c

What device are you using?

On Dec 30, 2017 7:31 PM, "Matthew Beals" <beal...@gmail.com> wrote:

Benjamin,

Is the template you used to decode this the same as is currently in the repo (new_template.c)?  I'm working on a slightly different interlogix sensor and the template isn't decoding anything.  Before I dig in too deep, I wanted to make sure I was starting at the right place

--
You received this message because you are subscribed to a topic in the Google Groups "rtl_433" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtl_433/edm1gmOXCzc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rtl_433+unsubscribe@googlegroups.com.
To post to this group, send an email to rtl...@googlegroups.com.

Visit this group at https://groups.google.com/group/rtl_433.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/44886513-9d25-4db3-a372-6fbb79a7c8d9%40googlegroups.com.

[Matthew Beals]

Thanks!  That actually worked right out of the box.

I have a house that is full of (as far as I can tell) NX-650N sensors ( http://www.interlogix.com/intrusion/product/wireless-door-window-sensors ) and some glass break sensors that I still need to check.  I'll let you know how things go

[Christian Zuckschwerdt]

Brent, quick note on Git. I find it much easier to work on feature branches than on master. I.e. you then can use

git checkout master
git pull
git checkout feat-interlogix
git rebase master
git push -f

to cleanly sync to current upstream.
I don't mean to impose a style, just a practical tip.

[Khalid Baheyeldin]

Brent,

I came here to say that I cloned your repository, compiled the program, and used the following command:

rtl_433 -f 319500000 -R 98 -F json

It recognized the sensors, and outputs the data for them.

Thank you so much ...

However, for some sensors, the data cannot be decoded.

Preamble not found, exiting! bit_offset: 0
GE/Interlogix Wireless Devices Template Callback
bitbuffer:: Number of rows: 1
bitbuffer:: Length of 1st row: 51
bitbuffer:: Printing 1st row:
000[some data]
Found valid preamble but message size (37) too small, exiting!

GE/Interlogix Wireless Devices Template Callback
bitbuffer:: Number of rows: 1
bitbuffer:: Length of 1st row: 2
bitbuffer:: Printing 1st row:
01

Sometimes there is no preamble:

Preamble not found, exiting! bit_offset: 0
GE/Interlogix Wireless Devices Template Callback
bitbuffer:: Number of rows: 0
bitbuffer:: Length of 1st row: 0
bitbuffer:: Printing 1st row:

This is from a sensor that is closer to the antenna than another one that does send valid data that is successfully decoded in full.

I tried varying the frequency from 319495000 to 319505000, but that does not affect the result: the ones that work continue to work, the ones that don't still don't.

Are there any other options that I can turn on to help with this?

What else could it be?

On Saturday, December 30, 2017 at 9:27:36 PM UTC-5, Brent Bailey wrote:

Hey Matthew.  I wrote the logic for these devices but it hasn't been merged yet.  I am making a few enhancements to support key fobs and will submit another pull request shortly but in the meantime feel free to use the branch below.

https://github.com/baileybrent/rtl_433/blob/master/src/devices/interlogix.c

What device are you using?

On Dec 30, 2017 7:31 PM, "Matthew Beals" <beal...@gmail.com> wrote:

Benjamin,

Is the template you used to decode this the same as is currently in the repo (new_template.c)?  I'm working on a slightly different interlogix sensor and the template isn't decoding anything.  Before I dig in too deep, I wanted to make sure I was starting at the right place

--
You received this message because you are subscribed to a topic in the Google Groups "rtl_433" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtl_433/edm1gmOXCzc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rtl_433+u...@googlegroups.com.

[Brent Bailey]

Are you using the latest source?  Should be from yesterday.  Try that and you should not have a problem but let me know if you do. 

To unsubscribe from this group and all its topics, send an email to rtl_433+unsubscribe@googlegroups.com.
To post to this group, send email to rtl...@googlegroups.com.

Visit this group at https://groups.google.com/group/rtl_433.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/84f3cfc5-2e12-48a9-9b38-971d3f2fa4a4%40googlegroups.com.

[Brent Bailey]

If the sensors are the same model from the ones that are decoded properly then you probably have a frequency/signal issue.  I use 319511500 as the frequency which is just above the 319.508 actual frequency (feel free to also set the offset via the -p parameter).  I would also take a look at your antenna size/design and placement.  I am using a stock rtl antenna that works fine but the shorter SMArt works marginally better (http://www.nooelec.com/store/nesdr-smart.html). The group here might have some better ideas about how to determine your offset but I used SDR# and found the peak of the frequency for my specific device.

Let me know what you find. I also don't have any smoke/heat sensor but would be interested in testing the existing logic and/or updating the code to support those sensors.  Feel free to upload some samples and an image to the rtl_433_tests repository and I will be happy to take a look.

[Brent Bailey]

I should also mention that it might just be a gain issue.  If you don't specify the gain, using the -g option, the auto-gain logic is used and it is marginal at best.  I use a gain around 38-39 if that helps any.

On Saturday, January 27, 2018 at 7:26:58 PM UTC-5, Khalid Baheyeldin wrote:

[Khalid Baheyeldin]

Brent,

I wanted to report back that reception is now great. All sensors are picked up.

First, I use a gain of 40, like you suggested.

Second, I placed the antenna in the middle of the house, on top of the fridge. A friend who is into HAM radios told me placing it on top of a metal plane would help, and it did.

The frequency that I use is 319492900.

Thanks for the great work on this. Saved me a ton of time and effort.

Found some key fobs for sale at a reasonable price, and when I get them, I will test them out.

[Brent Bailey]

Glad to hear.  I also purchased a few other sensors (like the garage door sensor) off of ebay and they all work well.

On a side note, I recently read that Interlogix has sold over 5 million of these devices.  That is a huge market!

https://twitter.com/Interlogix/status/951163738035453953

[Stephen Johnson]

I'm so glad that I'm not the only one doing this... First, I'll discover all of the existing Interlogix glass break & door sensors. Then I'll really consider adding some for my garage doors and some other parts of the house.  It will not be long before the Concord Express controller is replaced by a Raspberry Pi and the RTL-SDR dongle.  Yesterday, I thought that these 319.5MHz sensors would be a large obstacle. 

[Chris Weakland]

Were you able to trigger your glass break sensors? If I take the cover off I see this message:

$rtl_433 -f 319511500 -F json
...

{"time" : "2019-03-21 18:08:36", "model" : "Interlogix", "id" : "924079", "device_type" : "unknown", "raw_message" : "41152c", "battery" : "OK", "switch1" : "CLOSED", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}

If I clap, bang, whistle, you name it, I cannot get these to trigger. I even tried banging two beer bottles together in front of the sensor, no luck :(

Any help would be much appreciated.

Chris

[Brent Bailey]

I don't have a glass break sensor but I am pretty sure it was tested by someone. The protocol doesn't have any other unmapped bits so the data should be there.

--
You received this message because you are subscribed to a topic in the Google Groups "rtl_433" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtl_433/edm1gmOXCzc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtl_433+u...@googlegroups.com.

To post to this group, send email to rtl...@googlegroups.com.

Visit this group at https://groups.google.com/group/rtl_433.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/37e67ab1-0070-4b7e-ac8a-4f3b682ffcbb%40googlegroups.com.

[Stephen Johnson]

I found a way to trigger the Interlogix glass break sensor.

I took a large pot (like a 3 gallon one for pasta) and a metal spoon.  Placed the pot opening facing the sensor and hit the inside of the metal pot repeatedly until it triggered and the red LED remained on.

I was able to trigger it two times using this method.  It looks like switch1 just closes when triggered.

The output below is from the event:

{"time" : "2019-03-22 18:59:11", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "4d1528", "battery" : "OK", "switch1" : "OPEN", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:11", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "4d1528", "battery" : "OK", "switch1" : "OPEN", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:11", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "4d1528", "battery" : "OK", "switch1" : "OPEN", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:12", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "4d1528", "battery" : "OK", "switch1" : "OPEN", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:12", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "4d1528", "battery" : "OK", "switch1" : "OPEN", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:12", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "4d1528", "battery" : "OK", "switch1" : "OPEN", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:13", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "4d1528", "battery" : "OK", "switch1" : "OPEN", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:13", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "4d1528", "battery" : "OK", "switch1" : "OPEN", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:15", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "c11430", "battery" : "OK", "switch1" : "CLOSED", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:15", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "c11430", "battery" : "OK", "switch1" : "CLOSED", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:15", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "c11430", "battery" : "OK", "switch1" : "CLOSED", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:15", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "c11430", "battery" : "OK", "switch1" : "CLOSED", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:15", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "c11430", "battery" : "OK", "switch1" : "CLOSED", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:16", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "c11430", "battery" : "OK", "switch1" : "CLOSED", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:16", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "c11430", "battery" : "OK", "switch1" : "CLOSED", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}
{"time" : "2019-03-22 18:59:16", "model" : "Interlogix", "id" : "91d3e0", "device_type" : "unknown", "raw_message" : "c11430", "battery" : "OK", "switch1" : "CLOSED", "switch2" : "OPEN", "switch3" : "CLOSED", "switch4" : "OPEN", "switch5" : "OPEN"}