[Poor choice of subject line but closest I could come up with]

Most (all?) US cars seem to have a three-button "programmable remote"
embedded (typ above the rear view window) to handle garage door
openers without having to clip a "remote" to the vehicle's visor.

I'd like to know what that device is capable of -- by understanding
the sorts of things that it would likely control (and the requirements
imposed by those things).

I see GDOs operating in the 300-400MHz band -- "intermittent duty".

I've seen a report of a 2.4GHz opener but I think that to be in error
(more research required).

Nearest I can tell, a typical user would "pair" these with GDOs and/or
"electric gates" (a GDO in another form?).

[I have one of the three buttons "bound" to the garage light as the
light on the GDO is lame and only of use in certain circumstances]

Anything else that *might* see such use? I.e., something to control
from within the car in order to enter/depart from a property?

Any idea what this seemingly universal 3-button device is called,
in the trade? I.e., how to chase down further information (USPTO)
on it?

Or, ideas as to how it is trained? (do all remotes follow some
preordained data pattern?)

In article <scssvd$ieb$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:

>I see GDOs operating in the 300-400MHz band -- "intermittent duty".

I believe that most commonly you will see them operating at, or around
433.920 MHz. This is one of the bands in which Part 15 operation is
allowed.

The primary frequency-user here is military radar, and secondary is
amateur radio. One occasionally sees stories about military radar
operations disrupting peoples' garage door openers and car
alarm/locking systems in some areas. The commonest problems seem to
be "they don't work" (the strong radar signals saturate the receivers)
but "undesired operation" occurs occasionally (garage doors opening
"by themselves").

>I've seen a report of a 2.4GHz opener but I think that to be in error

>Nearest I can tell, a typical user would "pair" these with GDOs and/or
>"electric gates" (a GDO in another form?).

>Anything else that *might* see such use? I.e., something to control
>from within the car in order to enter/depart from a property?

Disarming the anti-intruder mines and lasers? :-)

>Any idea what this seemingly universal 3-button device is called,
>in the trade? I.e., how to chase down further information (USPTO)
>on it?

"Garage door opener", "car alarm key-fob", etc.

>Or, ideas as to how it is trained? (do all remotes follow some
>preordained data pattern?)

Your best bet is probably to open up either the transmitter or
receiver and find the FCC Part 15 registration ID. You can look this
up on an FCC web site and get at least some information about the
frequency and modulation pattern.

Commonly, these days, each button push will transmit a "rolling code"
packet... a header, a transmitter ID number, a sequence number of some
sort, a button code, and (in good ones) a cryptographic authentication
of some sort (cheaper ones omit this). The reciever is "trained" to
accept a specific transmitter ID (or set of IDs).

The better ones have some sort of transmitter-specific secret (known
to the receiver via the training/programming process) which creates a
cryptographic "signature" in the packet that's difficult to spoof.
The receiver validates this, and also looks at the sequence number to
provide "anti-replay" protection, so somebody can't record one of your
"open the garage door" transmissions and play it back later when
you're away from home. For these, the training process requires
giving the receiver both the transmitter ID and shared secret (and
often the starting sequence number).

Cheaper/older ones lack this sort of strong signature authentication
and anti-playback defense. There are plenty of stories about people
using off-the-shelf receiver dongles (e.g. the RTL-SDR type) to
receive transmissions, PCs to analyze them, and cheap transmitters to
re-send them. Want to unlock your neighbor's car? Want to "fast
forward" your neighbor's transmitter's sequence number a few thousand
times, effectively locking your neighbor out of the car? Not hard to
do, alas.

On 7/16/2021 3:46 PM, Dave Platt wrote:
> In article <scssvd$ieb$1@dont-email.me>,
> Don Y <blockedofcourse@foo.invalid> wrote:
>
>> I see GDOs operating in the 300-400MHz band -- "intermittent duty".
>
> I believe that most commonly you will see them operating at, or around
> 433.920 MHz. This is one of the bands in which Part 15 operation is
> allowed.

I've looked at various (incl legacy) GDO remotes and they seem to
operate (or HAVE operated) at a variety of bands: 310, 315, 360,
380, 390MHz. I.e., it doesn't appear that *one* band is all a
"remote control emulator" would need to handle.

[Part of the reason for my asking is to understand what's happening
inside the "universal remote" without trying to reverse engineer
it (being an automotive product, the volumes are high enough for the
entire design to be fully custom!)]

I'm assuming the "key fob" uses a different subsystem to provide
it's functionality (though it seems the two could easily be integrated).

> The primary frequency-user here is military radar, and secondary is
> amateur radio. One occasionally sees stories about military radar
> operations disrupting peoples' garage door openers and car
> alarm/locking systems in some areas. The commonest problems seem to
> be "they don't work" (the strong radar signals saturate the receivers)
> but "undesired operation" occurs occasionally (garage doors opening
> "by themselves").

I read of one frequency change being prompted by military *radio*.
Not sure how common such interference would be (given that we're not
located on a battlefield!). Nearest military base is some distance away
so no easy way to verify...

>> I've seen a report of a 2.4GHz opener but I think that to be in error
>
>> Nearest I can tell, a typical user would "pair" these with GDOs and/or
>> "electric gates" (a GDO in another form?).
>
>> Anything else that *might* see such use? I.e., something to control
>>from within the car in order to enter/depart from a property?
>
> Disarming the anti-intruder mines and lasers? :-)

Doors, gates, lights -- and a colleague suggested "security systems"
(probably NOT involving mines! :> )

>> Any idea what this seemingly universal 3-button device is called,
>> in the trade? I.e., how to chase down further information (USPTO)
>> on it?
>
> "Garage door opener", "car alarm key-fob", etc.

Colleague offered "HomeLink". That has produced a few hits.
I've been chasing them down to see what they might yield.

>> Or, ideas as to how it is trained? (do all remotes follow some
>> preordained data pattern?)
>
> Your best bet is probably to open up either the transmitter or
> receiver and find the FCC Part 15 registration ID. You can look this
> up on an FCC web site and get at least some information about the
> frequency and modulation pattern.

Yeah, I found a few hits on the fccid website. It will take a while
to sort out which might be most productive/informative. One (which
may not be The One) shows 5 frequency ranges: 286-303, 307-321,
336-398, 411-440 & 902-926. I'll have to see which of these are
likely "legacy support".

[A (previous) neighbor works for Chamberlain. I will chase him down and
see what he can offer regarding their current products -- and, any
history that he can add]

> Commonly, these days, each button push will transmit a "rolling code"
> packet... a header, a transmitter ID number, a sequence number of some
> sort, a button code, and (in good ones) a cryptographic authentication
> of some sort (cheaper ones omit this). The reciever is "trained" to
> accept a specific transmitter ID (or set of IDs).

Yes. And the receiver *tries* to remain in sync with the transmitter
by looking ahead some number of codes (256?) in case the transmitter
had been activated (repeatedly) without the receiver "seeing" those
activations.

This suggests surreptitiously pressing your "friend's" remote button
a few hundred times will leave the transmitter and receiver out of sync
with each other (i.e., "breaking" the control). The receiver can't
look *backwards* in the code sequence as that would allow a replay
attack.

> The better ones have some sort of transmitter-specific secret (known
> to the receiver via the training/programming process) which creates a
> cryptographic "signature" in the packet that's difficult to spoof.
> The receiver validates this, and also looks at the sequence number to
> provide "anti-replay" protection, so somebody can't record one of your
> "open the garage door" transmissions and play it back later when
> you're away from home. For these, the training process requires
> giving the receiver both the transmitter ID and shared secret (and
> often the starting sequence number).

I think (?) the "sequence number" is implicit in the actual code
sent. I.e., if the series of random codes (LPRNG) is:
5, 93, 387, 443, 3726, 423, 445, 9088, 244, 768, ...
then if YOU think the "next" code is "93", you will accept any of the
(256?) codes AFTER "93" as valid -- and, synchronize to THAT point in the
sequence, thereafter. So, if "445" was received, all of those codes up
to ("before" in the sequence) would be invalidated.

This raises some interesting implementation questions:
- if a 'second" remote is in use, does it use an entirely different sequence?
(if not, how does *it* know that the next number is now 9088 instead of 93
or even 387?)
- how does the trainable remote (emulator) know what the sequence is?
are all sequences (from all remote control vendors) using the same
polynomial? (if so, a hacker could anticipate the next code just by
"listening" to your remote, now)

> Cheaper/older ones lack this sort of strong signature authentication
> and anti-playback defense. There are plenty of stories about people
> using off-the-shelf receiver dongles (e.g. the RTL-SDR type) to
> receive transmissions, PCs to analyze them, and cheap transmitters to
> re-send them.

Hmmm... I will have to research that. It's not germane to the problem
I'm trying to address but it "is a puzzlement" (Brynner) worth exploring.

> Want to unlock your neighbor's car? Want to "fast
> forward" your neighbor's transmitter's sequence number a few thousand
> times, effectively locking your neighbor out of the car? Not hard to
> do, alas.

Only a fool bets against the hacker! :< Too often, designers rely on
easily violated assumptions in their designs. Once identified, they
can easily be subverted. So, the security only applies to prevent
casual theft/abuse; a mildly determined adversary is unimpeded.

[I particularly like the hacks of keyless entry devices that simply
require the user to *possess* the key, no button presses required!]

In my case, I just want to leverage what is becoming a ubiquitous feature
in vehicles to provide a "non-wired" link between a vehicle and another
device (avoiding the design, certification, manufacture and PACKAGING
of said device). It is almost second nature to reach up and press
one of these buttons as entering/exiting a property. So, a likely candidate
to "overload" for other functionality!

Thanks for your comments! I'll see what else I can find... I was
hoping to get a feel for what the trainable device COULD do (there is
no formal specification available, that I can find -- it works, or it
doesn't). Then, contemplate how they would implement such functionality.

Then, figure out how to verify that as well as leverage it for MY needs.

test
Don Y wrote:

<snip>

> Yeah, I found a few hits on the fccid website. It will take a while
> to sort out which might be most productive/informative. One (which
> may not be The One) shows 5 frequency ranges: 286-303, 307-321,
> 336-398, 411-440 & 902-926. I'll have to see which of these are
> likely "legacy support".

418 MHz is good and cheap and probably provides the best "legacy"
support because it was formerly widely used in Europe until newer
products migrated to 433.92 MHz.

Which frequency should I use when planning to design a RF
(Radio Frequency) product in the United States?

...

418MHz is a good frequency to use in the US as it is not
very crowded. This gives the least likely chance for
interference and therefore the best performance.

...

https://www.solidremote.com/blog/rf-remote-control-frequency-selection-315mhz-418mhz-433-92mhz-or-915mhz/

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

On 7/16/2021 8:43 PM, Don wrote:
> test
>
> Don Y wrote:
>
> <snip>
>
>> Yeah, I found a few hits on the fccid website. It will take a while
>> to sort out which might be most productive/informative. One (which
>> may not be The One) shows 5 frequency ranges: 286-303, 307-321,
>> 336-398, 411-440 & 902-926. I'll have to see which of these are
>> likely "legacy support".
>
> 418 MHz is good and cheap and probably provides the best "legacy"
> support because it was formerly widely used in Europe until newer
> products migrated to 433.92 MHz.

I'm actually trying NOT to design such a device. The HomeLink units
in vehicles already have the ability to masquerade as any number of
such devices. I would want to have them masquerade as devices that
are "new (modern) enough" that support for them wouldn't be elided
from the next iteration of the HL design.

[E.g., HL can emulate devices that emit *fixed* codes; I suspect these
are increasingly rare (i.e., GDOs), "in the wild", and that capability
may be bred out of the HL design's evolution -- in favor of support
for even more "clever" future designs.]

Once I can settle on a "safe" remote to be emulated (or, remote
*technology*), I'd have to build a "programmer" -- essentially a
remote with just enough output power to be seen by the HL device
when in programming mode. Hopefully, this can be low enough
that the device doesn't pose a nuisance attracting FCC attention.

[I suspect the HL device is intentionally crippled to only
detect signal in very close proximity -- less than a foot -- so
this may be a challenge]

On 17/07/2021 09:56, Don Y wrote:
>
> [I suspect the HL device is intentionally crippled to only
> detect signal in very close proximity -- less than a foot -- so
> this may be a challenge]
>

In units I have seen the close range reception in programming mode is
achieved by merely using a crystal radio type diode detector - not any
"proper" receiver at all!

piglet

On 17/7/21 6:56 pm, Don Y wrote:
> On 7/16/2021 8:43 PM, Don wrote:
>> test
>> Don Y wrote:
>>
>> <snip>
>>
>>> Yeah, I found a few hits on the fccid website.  It will take a while
>>> to sort out which might be most productive/informative.  One (which
>>> may not be The One) shows 5 frequency ranges:  286-303, 307-321,
>>> 336-398, 411-440 & 902-926.  I'll have to see which of these are
>>> likely "legacy support".
>>
>> 418 MHz is good and cheap and probably provides the best "legacy"
>> support because it was formerly widely used in Europe until newer
>> products migrated to 433.92 MHz.
>
> I'm actually trying NOT to design such a device.  The HomeLink units
> in vehicles already have the ability to masquerade as any number of
> such devices.  I would want to have them masquerade as devices that
> are "new (modern) enough" that support for them wouldn't be elided
> from the next iteration of the HL design.
>
> [E.g., HL can emulate devices that emit *fixed* codes; I suspect these
> are increasingly rare (i.e., GDOs), "in the wild", and that capability
> may be bred out of the HL design's evolution -- in favor of support
> for even more "clever" future designs.]
>
> Once I can settle on a "safe" remote to be emulated (or, remote
> *technology*), I'd have to build a "programmer" -- essentially a
> remote with just enough output power to be seen by the HL device
> when in programming mode.  Hopefully, this can be low enough
> that the device doesn't pose a nuisance attracting FCC attention.
>
> [I suspect the HL device is intentionally crippled to only
> detect signal in very close proximity -- less than a foot -- so
> this may be a challenge]
>

Don,

IDK if it's useful to you, but the open source "rtl_433" software can
demodulate and decode many of these types of keyfobs. Hundreds, anyway.

I suspect that reading the code would give you a lot of insight into the
variety of encodings used. You could even get an RTL dongle and listen in.

CH

On 7/16/2021 6:46 PM, Dave Platt wrote:
> The primary frequency-user here is military radar, and secondary is
> amateur radio. One occasionally sees stories about military radar
> operations disrupting peoples' garage door openers and car
> alarm/locking systems in some areas. The commonest problems seem to
> be "they don't work" (the strong radar signals saturate the receivers)
> but "undesired operation" occurs occasionally (garage doors opening
> "by themselves").

Hello, I find this VERY interesting. I won't go into the whole story
since it is very long but I have a customer that has an alarm system
that I installed. It has wireless sensors for doors and such.
There has been a few times that the system does not receive signals
from the transmitters for periods of time from 45 minutes to 2 days.
During this time their garage door opener remote does not work unless
you hold it in you hand reach up to within 18" of the opener antenna
and then it will work.

During that time the problem or source can't be determined.
In discussions with neighbors it has be determined that at least
4 others, next door and across the street have experienced the same
with there openers.

Then it all stops and goes back to normal operation???

This happened about 2 years ago and then again about a month ago.
That I know about that is.

Needless to say when it IS NOT happening it is absolutely impossible
to find. When it IS happening it is absolutely impossible to find.

The openers have a red LED on the unit that is used for learning in
a remote button. Normally it is off until it receives a signal from
a remote to open. During these events the LED is solid red for the
entire time frame. Then during the end of the event it starts to
flicker and then off.

The security devices are on 319.5 Mhz and the door opener is on 318 Mhz.

Is there any thoughts here as to what other than Military Radar that
could be causing this issue with such intensity in a small area??

There is a local airport with control tower about 2 miles away.

I say a small area (200' square box maybe??) but it could be effecting
a larger area but I have no way to know or to find out without having
a town meeting.

Any thoughts on the subject would be most helpful.

Thanks,

Les

On Saturday, July 17, 2021 at 9:07:50 AM UTC-4, ABLE1 wrote:
> On 7/16/2021 6:46 PM, Dave Platt wrote:
> > The primary frequency-user here is military radar, and secondary is
> > amateur radio. One occasionally sees stories about military radar
> > operations disrupting peoples' garage door openers and car
> > alarm/locking systems in some areas. The commonest problems seem to
> > be "they don't work" (the strong radar signals saturate the receivers)
> > but "undesired operation" occurs occasionally (garage doors opening
> > "by themselves").
> Hello, I find this VERY interesting. I won't go into the whole story
> since it is very long but I have a customer that has an alarm system
> that I installed. It has wireless sensors for doors and such.
> There has been a few times that the system does not receive signals
> from the transmitters for periods of time from 45 minutes to 2 days.
> During this time their garage door opener remote does not work unless
> you hold it in you hand reach up to within 18" of the opener antenna
> and then it will work.
>
> During that time the problem or source can't be determined.
> In discussions with neighbors it has be determined that at least
> 4 others, next door and across the street have experienced the same
> with there openers.
>
> Then it all stops and goes back to normal operation???
>
> This happened about 2 years ago and then again about a month ago.
> That I know about that is.
>
> Needless to say when it IS NOT happening it is absolutely impossible
> to find. When it IS happening it is absolutely impossible to find.
>
> The openers have a red LED on the unit that is used for learning in
> a remote button. Normally it is off until it receives a signal from
> a remote to open. During these events the LED is solid red for the
> entire time frame. Then during the end of the event it starts to
> flicker and then off.
>
> The security devices are on 319.5 Mhz and the door opener is on 318 Mhz.
>
> Is there any thoughts here as to what other than Military Radar that
> could be causing this issue with such intensity in a small area??
>
> There is a local airport with control tower about 2 miles away.
>
> I say a small area (200' square box maybe??) but it could be effecting
> a larger area but I have no way to know or to find out without having
> a town meeting.
>
> Any thoughts on the subject would be most helpful.

Here's my two cents worth. My home town, Frederick, MD is host to Fort Detrick. Maybe 10 or 20 years ago they announced some change in their emissions (no details provided I believe) so that these garage opener type devices may malfunction. With a number of homes in close proximity of the base there were garage doors opening at will and remotes no longer functioning. I believe at that time there were many fixed code devices and few, if any rolling code devices. It's not clear to me if that makes a difference, but a rolling code may be more suseptable to jamming in that if enough triggers are received as valid I believe the rolling code can desync your remote requiring you to sync it up again.

If enough units use the same brand of receivers/remotes is it possible that frequent use causes rolling code collisions that desync remotes? I'm thinking the wrap around count is sufficiently large that this is a near impossibility.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On Sat, 17 Jul 2021 01:56:58 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 7/16/2021 8:43 PM, Don wrote:
>> test
>>
>> Don Y wrote:
>>
>> <snip>
>>
>>> Yeah, I found a few hits on the fccid website. It will take a while
>>> to sort out which might be most productive/informative. One (which
>>> may not be The One) shows 5 frequency ranges: 286-303, 307-321,
>>> 336-398, 411-440 & 902-926. I'll have to see which of these are
>>> likely "legacy support".
>>
>> 418 MHz is good and cheap and probably provides the best "legacy"
>> support because it was formerly widely used in Europe until newer
>> products migrated to 433.92 MHz.
>
>I'm actually trying NOT to design such a device. The HomeLink units
>in vehicles already have the ability to masquerade as any number of
>such devices. I would want to have them masquerade as devices that
>are "new (modern) enough" that support for them wouldn't be elided
>from the next iteration of the HL design.
>
>[E.g., HL can emulate devices that emit *fixed* codes; I suspect these
>are increasingly rare (i.e., GDOs), "in the wild", and that capability
>may be bred out of the HL design's evolution -- in favor of support
>for even more "clever" future designs.]
>
>Once I can settle on a "safe" remote to be emulated (or, remote
>*technology*), I'd have to build a "programmer" -- essentially a
>remote with just enough output power to be seen by the HL device
>when in programming mode. Hopefully, this can be low enough
>that the device doesn't pose a nuisance attracting FCC attention.
>
>[I suspect the HL device is intentionally crippled to only
>detect signal in very close proximity -- less than a foot -- so
>this may be a challenge]

I've never had a GDO, but for programming it may have near-field only
antennas, precisely to make programming from the street outside
impossible.

Joe Gwinn

In article <vjs5fg9im19ln3hska3ctk673k6ilashfe@4ax.com>,
joegwinn@comcast.net says...
>
> I've never had a GDO, but for programming it may have near-field only
> antennas, precisely to make programming from the street outside
> impossible.
>
>
>

Most garage door openers have very low power so not much over 100 to 200
feet of range.

If someone has a much more powerful transmitter then a mile or two would
be possiable. I am not talking about 1000 or more watts but maybe 10
watts for the transmitter.

Much like the key thing for the cars . They have a very short range. The
transmitter is very low power because of the size of the battery. No
one would want a key FOB the size of a 2 or 3 cell flashlight.

On 7/17/2021 8:10 AM, Joe Gwinn wrote:
> On Sat, 17 Jul 2021 01:56:58 -0700, Don Y

>> [I suspect the HL device is intentionally crippled to only
>> detect signal in very close proximity -- less than a foot -- so
>> this may be a challenge]
>
> I've never had a GDO, but for programming it may have near-field only
> antennas, precisely to make programming from the street outside
> impossible.

Note that the HL device is not a GDO; it's a GDO *remote* (emulator).
For the GDOs that are push-button programmed (press button to
enter programming mode), they use the existing receiver design
to "capture" the signal from the remote. So, you can program
the GDO at the same distance as you could normally actuate the
opener.

Many years ago, we discovered that *our* remote would open our
GDO *and* the neighbor across the street! I'm still unsure
as to how this could have happened. I.e., even if he happened to
have been in "programming mode" when we (drove in/out and) actuated
*our* GDO, he would have known that his remote wasn't working properly
and would have tried again.

Unless his GDO "saw" our remote's action, responded and he
never verified that his remote *would* operate his (i.e.,
a pure coincidence?)

On 7/17/2021 9:19 AM, Ralph Mowery wrote:
> Most garage door openers have very low power so not much over 100 to 200
> feet of range.

The HL devices are rated at 2mW.

> If someone has a much more powerful transmitter then a mile or two would
> be possiable. I am not talking about 1000 or more watts but maybe 10
> watts for the transmitter.
>
> Much like the key thing for the cars . They have a very short range. The
> transmitter is very low power because of the size of the battery. No
> one would want a key FOB the size of a 2 or 3 cell flashlight.

No, there are other reasons for the limited range.

- you wouldn't want the car NEXT to you to respond to your signal
(or interfere with your vehicle's response)
- you want to know the HAND that is now grasping the door handle
belongs to the individual with the fob on their person (~30 inches)
- you want to know that the fob is located:
by the driver side door (so the driver's door will unlock when the
driver's door handle is sensed)
by the passenger side door (so the passenger's door will unlock when
the passenger's door handle is sensed)
[you don't want an adversary approaching your vehicle to be able to
let himself *in* on the passenger side just because "you" happened
to have brought the fob close to the vehicle]
by the "hatchback" (so the hatchback can be opened when commanded)
close to the ignition switch (so the vehicle could be started)
is no longer contained within the confines of the vehicle (so
the occupants aren't locked out of a RUNNING vehicle)

My other half and I frequently travel together. Each of us carrying
our own fob (driver's fob adjusts the car to that person's preferences).
Owing to the way that we park in the garage, the passenger usually passes
by the driver's door on their way to their spot. If the driver
(following the passenger) grabs the door handle too soon after the
passenger (and fob!) has passed the driver door, the car will think
hat the *passenger* is driving and will set things up for the
passenger-as-driver.

This is annoying. The driver has to close the door and repeat the
exercise to "change the car's mind" (this also takes a few moments
as the seat and mirrors have to be repositioned from that false
input)

[Thankfully, the car doesn't get confused with the passenger *seated*
near the driver! So, very near-field operation]

On 7/17/2021 4:53 AM, Clifford Heath wrote:
> IDK if it's useful to you, but the open source "rtl_433" software can
> demodulate and decode many of these types of keyfobs. Hundreds, anyway.
>
> I suspect that reading the code would give you a lot of insight into the
> variety of encodings used. You could even get an RTL dongle and listen in.

Hmmm... I don't know. I will have to think about what I could do with that
capability. And, if I could use it "in production" to make the device
more usable (?). Maybe I could use it to *receive* commands issued
by the HL device (though I'd still have to sort out how to "program"
the HL device -- with a "synthetic remote")

My current thinking is that the GDO (and any other "remote activated"
device) should NOT be responding to a remote (because then there is the
possibility that it will perform and/or enter a state that "I" don't
endorse). "I" should capture the commands from the remote and decide
what to do with them.

E.g., I am frequently working in the garage. I don't want someone
"coming home" to open the door and drive in (I may be accessing the
ceiling area ABOVE the raised garage door so would be harmed by its
opening).

Folks with multiple garage doors (I have a buddy with *8*) could
use the remote to signal "open *a* door" and which door may be
determined by noting which stalls are "in use".

[Ideally, it would be nice to be able to lock the remote XMIT "on"
and use this to sense the *presence*/approach/departure of a
vehicle. But, not an allowed use so rely on other technologies
to do that!]

Someone else might use *a* button (recall there are three) to
signal they are waiting "out front" and the occupant should
come out (for their ride to work).

I'll have to think on this. And, collect more data on "remotes".
Thanks!

On 7/17/2021 2:14 AM, Piglet wrote:
> On 17/07/2021 09:56, Don Y wrote:
>>
>> [I suspect the HL device is intentionally crippled to only
>> detect signal in very close proximity -- less than a foot -- so
>> this may be a challenge]
>>
>
> In units I have seen the close range reception in programming mode is achieved
> by merely using a crystal radio type diode detector - not any "proper" receiver
> at all!

I can clearly see an antenna trace in the FCC filings. One has to
wonder why (given that it is obviously produced in HUGE quantities
and can be damn near anything it WANTS to be) they made the deliberate
effort to limit the device's *receiving* range. Yeah, you want to
have some assurance that the signal you are receiving is INTENDED for
you (while "learning") but even a mmistaken capture could easily be
verified: "when the red light stops flashing (signaling the
remote has been programmed) press the button to verify the GDO operates..."

Ralph Mowery wrote:
> In article <vjs5fg9im19ln3hska3ctk673k6ilashfe@4ax.com>,
> joegwinn@comcast.net says...
>>
>> I've never had a GDO, but for programming it may have near-field only
>> antennas, precisely to make programming from the street outside
>> impossible.
>>
>>
>>
>
> Most garage door openers have very low power so not much over 100 to 200
> feet of range.
>
> If someone has a much more powerful transmitter then a mile or two would
> be possiable. I am not talking about 1000 or more watts but maybe 10
> watts for the transmitter.
>
> Much like the key thing for the cars . They have a very short range. The
> transmitter is very low power because of the size of the battery. No
> one would want a key FOB the size of a 2 or 3 cell flashlight.
>

I'm sorry, but in an electronic design newsgroup, 'GDO' has got to mean
'Grid Dip Oscillator' and nothing else.

Garages, humph. ;)

Cheers

Phil Hobbs

(Whose garage is opened and closed fully manually)

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On 2021-07-17, ABLE1 <somewhere@nowhere.net> wrote:

> The security devices are on 319.5 Mhz and the door opener is on 318 Mhz.
>
> Is there any thoughts here as to what other than Military Radar that
> could be causing this issue with such intensity in a small area??
>
> There is a local airport with control tower about 2 miles away.
>
> I say a small area (200' square box maybe??) but it could be effecting
> a larger area but I have no way to know or to find out without having
> a town meeting.
>
> Any thoughts on the subject would be most helpful.

Build or borrow a directional antenna for 318 MHZ, get a portable receiver
that provides signal strength information, and go on a fox hunt.

--
Jasen.

On 7/17/2021 6:07 AM, ABLE1 wrote:
> Hello, I find this VERY interesting. I won't go into the whole story
> since it is very long but I have a customer that has an alarm system
> that I installed. It has wireless sensors for doors and such.
> There has been a few times that the system does not receive signals
> from the transmitters for periods of time from 45 minutes to 2 days.

2 *days*? Are you sure someone isn't (illegally) operating
a transmitter, nearby?

> During this time their garage door opener remote does not work unless
> you hold it in you hand reach up to within 18" of the opener antenna
> and then it will work.
>
> During that time the problem or source can't be determined.
> In discussions with neighbors it has be determined that at least
> 4 others, next door and across the street have experienced the same
> with there openers.
>
> Then it all stops and goes back to normal operation???
>
> This happened about 2 years ago and then again about a month ago.
> That I know about that is.
>
> Needless to say when it IS NOT happening it is absolutely impossible
> to find. When it IS happening it is absolutely impossible to find.
>
> The openers have a red LED on the unit that is used for learning in
> a remote button. Normally it is off until it receives a signal from
> a remote to open. During these events the LED is solid red for the
> entire time frame. Then during the end of the event it starts to
> flicker and then off.

Verify the *complete* behavior of the indicator. Usually, when
in "learn mode" (activated by a button on the RECEIVER), the
indicator will flash (until it times out).

Some flash when they detect an obstacle in the path of the door
(either photoelectrically or by sensing an increased current
draw by the motor)

Does "lit" coincide with the *entire* open/close cycle? I.e.,
the behavior you are seeing SHOULD be accompanied by the door
moving (?)

> The security devices are on 319.5 Mhz and the door opener is on 318 Mhz.
>
> Is there any thoughts here as to what other than Military Radar that
> could be causing this issue with such intensity in a small area??

Almost anything can be an "unintentional radiator" -- even things like
christmas lights!

I'd wonder if someone wasn't (naively) putting a bunch of hash out.
The "45 minutes" sounds like someone might be "doing something"
(or USING something) for a short period. The "2 days" suggests it
got left *on*!

I lived in a house with the garage located beneath the master bedroom.
Vacuuming the carpet in the MBR would often result in the garage door
opening. We'd come out, the next morning, to leave for work and
wonder which of us had "*left* the door open"! (Ans: neither)

> There is a local airport with control tower about 2 miles away.

Possible. Why not go sniffing for signals? TV or radio stations
nearby?

> I say a small area (200' square box maybe??) but it could be effecting
> a larger area but I have no way to know or to find out without having
> a town meeting.
>
> Any thoughts on the subject would be most helpful.

When the problem next manifests, try to shield the affected unit.
This would at least give you an idea if the interference was radiated
or conducted. In most places, several homes are fed from a single
transformer. So, your line is a direct reflection of what's happening
in your neighbor's homes. Neighbors served by *another* transformer
will have two transformers acting to attenuate signals between your
home and theirs.

[Here, it's 4 homes per xformer -- and I can easily deduce which homes are
serviced "together" (or service is all below grade)]

On Sat, 17 Jul 2021 14:19:03 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 7/17/2021 6:07 AM, ABLE1 wrote:
>> Hello, I find this VERY interesting. I won't go into the whole story
>> since it is very long but I have a customer that has an alarm system
>> that I installed. It has wireless sensors for doors and such.
>> There has been a few times that the system does not receive signals
>> from the transmitters for periods of time from 45 minutes to 2 days.
>
>2 *days*? Are you sure someone isn't (illegally) operating
>a transmitter, nearby?
>
>> During this time their garage door opener remote does not work unless
>> you hold it in you hand reach up to within 18" of the opener antenna
>> and then it will work.
>>
>> During that time the problem or source can't be determined.
>> In discussions with neighbors it has be determined that at least
>> 4 others, next door and across the street have experienced the same
>> with there openers.
>>
>> Then it all stops and goes back to normal operation???
>>
>> This happened about 2 years ago and then again about a month ago.
>> That I know about that is.
>>
>> Needless to say when it IS NOT happening it is absolutely impossible
>> to find. When it IS happening it is absolutely impossible to find.
>>
>> The openers have a red LED on the unit that is used for learning in
>> a remote button. Normally it is off until it receives a signal from
>> a remote to open. During these events the LED is solid red for the
>> entire time frame. Then during the end of the event it starts to
>> flicker and then off.
>
>Verify the *complete* behavior of the indicator. Usually, when
>in "learn mode" (activated by a button on the RECEIVER), the
>indicator will flash (until it times out).
>
>Some flash when they detect an obstacle in the path of the door
>(either photoelectrically or by sensing an increased current
>draw by the motor)
>
>Does "lit" coincide with the *entire* open/close cycle? I.e.,
>the behavior you are seeing SHOULD be accompanied by the door
>moving (?)
>
>> The security devices are on 319.5 Mhz and the door opener is on 318 Mhz.
>>
>> Is there any thoughts here as to what other than Military Radar that
>> could be causing this issue with such intensity in a small area??
>
>Almost anything can be an "unintentional radiator" -- even things like
>christmas lights!
>
>I'd wonder if someone wasn't (naively) putting a bunch of hash out.
>The "45 minutes" sounds like someone might be "doing something"
>(or USING something) for a short period. The "2 days" suggests it
>got left *on*!
>
>I lived in a house with the garage located beneath the master bedroom.
>Vacuuming the carpet in the MBR would often result in the garage door
>opening. We'd come out, the next morning, to leave for work and
>wonder which of us had "*left* the door open"! (Ans: neither)
>
>> There is a local airport with control tower about 2 miles away.
>
>Possible. Why not go sniffing for signals? TV or radio stations
>nearby?
>
>> I say a small area (200' square box maybe??) but it could be effecting
>> a larger area but I have no way to know or to find out without having
>> a town meeting.
>>
>> Any thoughts on the subject would be most helpful.
>
>When the problem next manifests, try to shield the affected unit.
>This would at least give you an idea if the interference was radiated
>or conducted. In most places, several homes are fed from a single
>transformer. So, your line is a direct reflection of what's happening
>in your neighbor's homes. Neighbors served by *another* transformer
>will have two transformers acting to attenuate signals between your
>home and theirs.
>
>[Here, it's 4 homes per xformer -- and I can easily deduce which homes are
>serviced "together" (or service is all below grade)]

Buy one of those $50 (ish) Tiny SA Spectrum alalyzers and see if
there is any RF signals around that frequency above the level there is
when the door IS working and compare.

That would tell you something. Then you could either get a
directional antenna for it or possibly drive around the neighborhood
trying to find where the signal gets stronger.

But first you need to see if nearby RF interference is even the issue
and what it looks like.

I wonder if there are any high power transmitter near by on another
frequency that could de-sense this garage door receiver ? Overload,

boB

On 18/7/21 6:03 am, Don Y wrote:
> On 7/17/2021 4:53 AM, Clifford Heath wrote:
>> IDK if it's useful to you, but the open source "rtl_433" software can
>> demodulate and decode many of these types of keyfobs. Hundreds, anyway.
>>
>> I suspect that reading the code would give you a lot of insight into
>> the variety of encodings used. You could even get an RTL dongle and
>> listen in.
>
> Hmmm... I don't know.  I will have to think about what I could do with that
> capability.  And, if I could use it "in production" to make the device
> more usable (?).

I don't think you want to run an SDR as a receiver. I only meant that
you could read the code to learn about the types of encodings that have
been used.

> E.g., I am frequently working in the garage.  I don't want someone
> "coming home" to open the door and drive in (I may be accessing the
> ceiling area ABOVE the raised garage door so would be harmed by its
> opening).

Door openers have "stuck" detectors that shut the motors down when there
is a blockage. If your door is installed in a way that any operation is
unsafe, you should fix that before worrying about how to control it.

> I'll have to think on this.  And, collect more data on "remotes".

The data you probably want is in that code.

CH

On Sat, 17 Jul 2021 12:19:07 -0400, Ralph Mowery
<rmowery42@charter.net> wrote:

>In article <vjs5fg9im19ln3hska3ctk673k6ilashfe@4ax.com>,
>joegwinn@comcast.net says...
>>
>> I've never had a GDO, but for programming it may have near-field only
>> antennas, precisely to make programming from the street outside
>> impossible.
>>
>>
>>
>
>Most garage door openers have very low power so not much over 100 to 200
>feet of range.
>
>If someone has a much more powerful transmitter then a mile or two would
>be possiable. I am not talking about 1000 or more watts but maybe 10
>watts for the transmitter.
>
>Much like the key thing for the cars . They have a very short range. The
>transmitter is very low power because of the size of the battery. No
>one would want a key FOB the size of a 2 or 3 cell flashlight.

I was not worrying about the battery. My issue is to hinder criminal
misuse.

Joe Gwinn

On 7/17/2021 5:07 PM, Clifford Heath wrote:
> On 18/7/21 6:03 am, Don Y wrote:
>> On 7/17/2021 4:53 AM, Clifford Heath wrote:
>>> IDK if it's useful to you, but the open source "rtl_433" software can
>>> demodulate and decode many of these types of keyfobs. Hundreds, anyway.
>>>
>>> I suspect that reading the code would give you a lot of insight into the
>>> variety of encodings used. You could even get an RTL dongle and listen in.
>>
>> Hmmm... I don't know. I will have to think about what I could do with that
>> capability. And, if I could use it "in production" to make the device
>> more usable (?).
>
> I don't think you want to run an SDR as a receiver. I only meant that you could
> read the code to learn about the types of encodings that have been used.

I've already planned several SDR-based receivers. It lets me adapt the
hardware to the *present* reception needs.

But, watching for a "remote" to be activated is something that can't
easily be "scheduled" (like listening to an HD FM broadcast vs. tuning
a TV's audio or listening to WWV/CHU or...). So, it would require
pretty much dedicating a receiver to that purpose (or, sharing one with
some other low-occurrence use)

>> E.g., I am frequently working in the garage. I don't want someone
>> "coming home" to open the door and drive in (I may be accessing the
>> ceiling area ABOVE the raised garage door so would be harmed by its
>> opening).
>
> Door openers have "stuck" detectors that shut the motors down when there is a
> blockage. If your door is installed in a way that any operation is unsafe, you
> should fix that before worrying about how to control it.

Most detection is focused on preventing the door from closing on
an obstacle in its path. Often, their remedy is to *open* when
that is detected. It's not as common for someone to be in the path of
a *rising* door!

I've also noticed that the "sense" is pretty sluggish wrt activation.
E.g., if I was working directly in the plane of the door but *above* it,
I am sure I would be injured before the door even noticed that it had
hit me or knocked me from my ladder.

The point is to provide ADVANCE knowledge of problem situations
instead of relying on the opener itself to detect them, after the
fact. The methods that it uses are pretty crude (like
parking a car by noticing when you *hit* something!)

>> I'll have to think on this. And, collect more data on "remotes".
>
> The data you probably want is in that code.

On 7/17/2021 5:19 PM, Joe Gwinn wrote:
> On Sat, 17 Jul 2021 12:19:07 -0400, Ralph Mowery
> <rmowery42@charter.net> wrote:
>
>> In article <vjs5fg9im19ln3hska3ctk673k6ilashfe@4ax.com>,
>> joegwinn@comcast.net says...
>>>
>>> I've never had a GDO, but for programming it may have near-field only
>>> antennas, precisely to make programming from the street outside
>>> impossible.
>>>
>>>
>>>
>>
>> Most garage door openers have very low power so not much over 100 to 200
>> feet of range.
>>
>> If someone has a much more powerful transmitter then a mile or two would
>> be possiable. I am not talking about 1000 or more watts but maybe 10
>> watts for the transmitter.
>>
>> Much like the key thing for the cars . They have a very short range. The
>> transmitter is very low power because of the size of the battery. No
>> one would want a key FOB the size of a 2 or 3 cell flashlight.
>
> I was not worrying about the battery. My issue is to hinder criminal
> misuse.

IIRC, the fob (or at least *some* fobs) have a handshake with the
vehicle. So, the fob doesn't have to be emitting signal constantly;
instead, it waits to be "woken up" by the car.

I read of an attack whereby a tag team of hackers can gain access to
a vehicle by shadowing the owner as he/she exits the vehicle. The
party closest to the owner has a transponder in their possession
while their accomplice has the other end of the link in his
possession -- and has placed himself in close proximity to the vehicle's
door.

The probe from the car jumps the gap between the two accomplices
and makes the car think the owner is located nearby -- because
it acts as a simple "range extender" for both car and fob.

The accomplice at the vehicle opens the door and then steps in
to the driver's position and engages the ignition. Again, the
transponders extend the range so the car thinks the owner is
seated within. Car starts. Driver goes around to fetch his
partner and they drive off.

All is well until the engine is shut off -- at which point,
it can not be restarted. But, if your goal is to drive it
to a chop-shop (or use it to rob a bank), that single use
may be all you need!

On 18/7/21 11:54 am, Don Y wrote:
> On 7/17/2021 5:07 PM, Clifford Heath wrote:
>> On 18/7/21 6:03 am, Don Y wrote:
>>> On 7/17/2021 4:53 AM, Clifford Heath wrote:
>>>> IDK if it's useful to you, but the open source "rtl_433" software
>>>> can demodulate and decode many of these types of keyfobs. Hundreds,
>>>> anyway.
>>>>
>>>> I suspect that reading the code would give you a lot of insight into
>>>> the variety of encodings used. You could even get an RTL dongle and
>>>> listen in.
>>>
>>> Hmmm... I don't know.  I will have to think about what I could do
>>> with that
>>> capability.  And, if I could use it "in production" to make the device
>>> more usable (?).
>>
>> I don't think you want to run an SDR as a receiver. I only meant that
>> you could read the code to learn about the types of encodings that
>> have been used.
>
> I've already planned several SDR-based receivers.  It lets me adapt the
> hardware to the *present* reception needs.
>
> But, watching for a "remote" to be activated is something that can't
> easily be "scheduled" (like listening to an HD FM broadcast vs. tuning
> a TV's audio or listening to WWV/CHU or...).  So, it would require
> pretty much dedicating a receiver to that purpose (or, sharing one with
> some other low-occurrence use)
>
>>> E.g., I am frequently working in the garage.  I don't want someone
>>> "coming home" to open the door and drive in (I may be accessing the
>>> ceiling area ABOVE the raised garage door so would be harmed by its
>>> opening).
>>
>> Door openers have "stuck" detectors that shut the motors down when
>> there is a blockage. If your door is installed in a way that any
>> operation is unsafe, you should fix that before worrying about how to
>> control it.
>
> Most detection is focused on preventing the door from closing on
> an obstacle in its path.  Often, their remedy is to *open* when
> that is detected.

Stop, is as common as reverse.

> It's not as common for someone to be in the path of
> a *rising* door!

Right, the overload sensor is weaker or inactive on open, because it's
safer for a door to be open than closed, so more important to reach that
state against whatever resistance.

> E.g., if I was working directly in the plane of the door but *above* it,

Then your door is unsafe already. It should be boxed in so that you
cannot be above it. There's not a good electronic solution to that.

Clifford Heath.

On Saturday, July 17, 2021 at 9:54:28 PM UTC-4, Don Y wrote:
> I've already planned several SDR-based receivers. It lets me adapt the
> hardware to the *present* reception needs.
>
> But, watching for a "remote" to be activated is something that can't
> easily be "scheduled" (like listening to an HD FM broadcast vs. tuning
> a TV's audio or listening to WWV/CHU or...). So, it would require
> pretty much dedicating a receiver to that purpose (or, sharing one with
> some other low-occurrence use)

You don't need to dedicate a receiver if there are other tasks that can be done on a duty cycle. The first step is to scan for energy above a threshold. That can be done over the band of interest on a low duty cycle. When energy is detected it then needs to have a drop receiver tuned to see if it is a signal of interest. I don't know the modulation scheme used in these things, probably ASK which doesn't even need a dedicated receiver. The signal can be sampled periodically to recover the modulated data.

> Most detection is focused on preventing the door from closing on
> an obstacle in its path. Often, their remedy is to *open* when
> that is detected. It's not as common for someone to be in the path of
> a *rising* door!

They do care if the door is stuck for any reason. It can signal a failure that might prove dangerous, so the door is stopped. That's how mine works. I think it is a bit crude though since it relies on the motor pulling on it's mounts. The sensitivity is limited by the natural factors in the mechanism.

> I've also noticed that the "sense" is pretty sluggish wrt activation.
> E.g., if I was working directly in the plane of the door but *above* it,
> I am sure I would be injured before the door even noticed that it had
> hit me or knocked me from my ladder.
>
> The point is to provide ADVANCE knowledge of problem situations
> instead of relying on the opener itself to detect them, after the
> fact. The methods that it uses are pretty crude (like
> parking a car by noticing when you *hit* something!)

Yeah, when your sidewall scrubs against the curb. Isn't that how everyone does it? I had a boss once who had to replace tires because he wore out the sidewalls. He might have learned the lesson, or maybe not. It's odd that Teslas don't let you see the sides at the curb when parking. But then if you have the time to let it, the car will in theory parallel park itself!!!

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209