Security+ 2.0?

[gcormier]

I've got my LimeSDR Mini picking up a remote

However, no serial output from secplus_rx.py.

Opened is an 895MAX. Compatible with all LiftMaster, Chamberlain, Sears Craftsman garage door openers manufactured since January 1993. If your garage door opener has a Green, Orange Red, Purple or Yellow round learn button with a Yellow antenna wire, this remote will work

Some light googling brings me to https://www.stardoorparts.com/Liftmaster-895MAX-Elite-Remote-Control-p/895max.htm

With that compatibility chart, I fail to see how they could deviate from the standard and stay compatible going back to 1993 such that there is no output from your tool?

[argilo]

That waveform appears different than the older Security+ protocol, so I'm not surprised that secplus can't decode it. Unfortunately I don't have any Security+ 2.0 hardware available, so I'm not sure how it works.

[gcormier]

Okay I'll see if I can dig up more information via patents as you did.

Would you be willing to accept hardware donations? I could mail it to you, or leave it somewhere at my place (mailbox_ if you'd rather not give out your address. (We're in the same city I think?)

[argilo]

Sure, I would be interested to explore Security+ 2.0. Reach out to me by email (argilo@gmail.com) and I'll send you my address.

[gcormier]

sec2plus.pdf Patent from Oz with some details.

Table of technologies: Source

Color of Learn Button	Color of Antenna	Technology	Color of LED next to Learn Button
Yellow (square)	Gray	DIP Switch	Red
White	Gray	DIP Switch	Red
Gray	Gray	DIP Switch	Red
Green	Gray	Billion Code	Green
Red/Orange	Gray	Security + Rolling Code 390Mhz	Amber/Yellow
Blue*	Gray	Security + Rolling Code 433Mhz	Amber/Yellow
Purple	Purple	Security + Rolling Code 315Mhz	Amber/Yellow
Yellow (round)	Yellow	Security +2.0 310, 315 & 390Mhz	Amber/Yellow

[gcormier]

FCC filing

[argilo]

I've implemented a Security+ 2.0 encoder and decoder, and updated the receive flowgraph to process both Security+ and Security+ 2.0 packets: https://github.com/argilo/secplus/compare/0f245d21d4ace03d9a0b1e9d4fa291d79852aa39...d393908e919257425522ef7bfa1a5e9e6fe7c060

Some of the details are covered in https://patents.google.com/patent/US20110317835A1/ and I reverse engineered the rest by observing packets.

Sample output:

Security+ 2.0:  rolling=240124638  fixed=70678577664  (button=16 remote_id=1959100928)
Security+ 2.0:  rolling=240124639  fixed=70678577664  (button=16 remote_id=1959100928)
Security+ 2.0:  rolling=240124640  fixed=70678577664  (button=16 remote_id=1959100928)
Security+ 2.0:  rolling=240124641  fixed=62088643072  (button=14 remote_id=1959100928)
Security+ 2.0:  rolling=240124642  fixed=66383610368  (button=15 remote_id=1959100928)
Security+ 2.0:  rolling=240124643  fixed=74973544960  (button=17 remote_id=1959100928)

This output came from the remote you sent me. The button presses I made were: A, A, A, B, C, D.

Tomorrow I'll add a transmit flowgraph and update the readme.

[gcormier]

This is awesome! Gonna dig out the remote from the car and give it a shot tonight or tomorrow :)

[gcormier]

Totally works - thanks for the effort!

[argilo]

I made a few final tweaks, updated the readme, and added documentation to the Python module. Since Security+ 2.0 is now implemented, I'll close off this issue.

If you notice any bugs, please open another issue.

If you have any other devices available (e.g. a PIN pad) I'd be interested to see how the information is encoded. (Presumably parts of the fixed code would be used for that purpose, like in Security+.)

[gcormier]

Sure, I was thinking of getting one (if it exists) that supports multiple PIN codes instead of just one. If so, I can give you the old one.