Need help writing decoder

[ajvpb]

I've followed the tutorial as best I can but keep getting hung up when it comes time to mess with the decoder. I don't have any programming experience so thats not helping.

I'm trying to decode some 2GIG 345Mhz glass break detectors. The data sheet is here:
https://www.innersecurity.com/downloads/GB1.pdf

Pertinent info is
Code outputs: Alarm; Alarm Restore; Tamper; Tamper Restore; Supervisory; Low Battery
Transmitter Frequency: 345.000 MHz (crystal controlled)
Transmitter Frequency Tolerance: ± 15 kHz
Transmitter Bandwidth: 24 kHz
Modulation Type Amplitude Shift Keying—On/Off Keying (ASK-OOK)

I already have my honeywell/2gig 345 door sensors working from protocol 70 in the software. Their data sheet is here:
http://assets.cdn.aws.vivint.com/global/vivint.com/products/sensor-door-window/collateral/manual_sensor_door_and_window.pdf

Pertinent info is that it has the same (or very similar) radio parameters and the device file for those known devices inludes: modulation = OOK_PULSE_MANCHESTER_ZEROBIT,

With that information and working through the tutorial I came up with
rtl_433 -X "n=MYFIRSTTEST,m=OOK_MC_ZEROBIT,s=140,l=0,r=260" -r /pathtomyfile

This is where I'm stuck. With the above command I get my 64 length readouts and its hexadecimal code. I've made a glassbreak.c file and through many combinations of tutorial and new device template, I've hit a wall. I've attached all of my radio tests that include pressing the tamper button, putting it into test mode and playing a glass break sound to trigger it, all laid out in the data sheet. I think I've captured all of its functions.

I'll come back and try again tomorrow but I've been at this all day and I'm going cross-eyed. Any helps or hints are greatly appreciated!
radiotest.zip

[zuckschwerdt]

Getting reliable codes is pretty good already. Try to put the codes in a BitBench and annotated them. You might spot something or others will help out.
A general Honeywell / 2GIG description might be in https://github.com/merbanan/rtl_433/blob/master/src/devices/honeywell.c

[ajvpb]

Thanks for the quick reply and the link to bitbench, I hadn't come across that yet.

I'm going to type out a wall of text but its mostly to help me organize my thoughts. Please redirect me if I'm way off base but no one needs to read all of this.

I have 2 separate glass break detectors so I ran the same tests with them and got the following data:

00016808e5fd3e7f [wakeup with tamper switch open]
00016808e5bf26bf [tamper switch open/not pressed]
00016808e5ffbe8f [tamper switch pressed]
00016808e53f968f [glass breaking with tamper switch open/not pressed]
00016808e57f0ebf [glass breaking with tamper switch pressed - normal condition]

000164525bfd9cff [wakeup with tamper switch open]
000164525bbf843f [tamper switch open/not pressed]
000164525bff1c0f [tamper switch pressed]
000164525b3f340f [glass breaking with tamper switch open/not pressed]
000164525b7fac3f [glass breaking with tamper switch pressed - normal condition]

Let me know if I'm on the right track:

It seems like the first 5 digits 00016 are always the same and can be ignored, the preamble if I'm understanding things correctly. So that leaves "808e5" and "4525b" as a device ID. The last position is always an "f" so that can be ignored. Maybe that's a battery state?

Both devices show "bf" immediately after their device id when the tamper switch is open/not pressed and no other condition exists.
Both devices show "ff" immediately after their device id when the tamper switch is pressed.
Both devices show "3f" immediately after their device id when glass break is detected and the tamper switch is open/not pressed.
Both devices show "7f" immediately after their device id when glass break is detected and the tamper switch is closed/pressed.

I'm tempted to drop the "f" after those except that it isn't present in the same position during the wakeup message.

It seems the data I'm really interested in is all in that 11th position. There is obviously lots of other data to be decoded in here but maybe in the meantime I can make a half-assed decoder that just looks at that 11th position and gives me 1 of 4 conditions.

If you made it this far, thanks for reading!

[ghost]

ok, makes sense.

[ghost]

-y00016808e5fd3e7f
gives -R100 here (comes close)
I get this msg twice per day. but mb. irrelevant

[ghost]

good News:
-R70 seems to work after some adjustments
CH9 uses poly 0x8050 too.
edit:
sorry, only one Code works with 0x8050
CRC mismatch
Sorry again

[zuckschwerdt]

it should be -R 70. Notice that the last nibble of the CRC is always 0 which looks strange but is actually ok, all codes work with a CRC-16 poly 0x8050 init 0.
Support added with 14bba0c -- please check all your codes if the flags are as expected. You can test your codes with e.g. rtl_433 -R 70 -y 00016808e5fd3e7f

[ghost]

Yes, you are right.
I produced a bug in my Code lol..
Ox8050,0 works

[ghost]

i see, you corrected the missing "}" "{" in your code.
i got compiler warnings but always ignored..
well done !

[ghost]

one last comment:
some codes collides with -R100 "Honeywell-Security", but -R100 has just a Parity instead of a CRC check
rtl_433 -M protocol -y00016808e5fd3e7f

[ajvpb]

Absolutely incredible! I go to bed and wake up to see all of this has been accomplished. I am floored and truly grateful, thanks so much to both of you!!

[zuckschwerdt]

@ajvpb Thanks for taking the time to get into all this and improve rtl_443!

[ghost]

[zuckschwerdt]

Best to keep it to one topic per issue. Please open a new issue for this.