Re: Ir remotes

On 5/20/2024 4:47 AM, Lasse Langwadt wrote:

On 5/20/24 13:07, Don Y wrote:

On 5/20/2024 2:50 AM, Lasse Langwadt wrote:

On 5/20/24 09:15, Don Y wrote:

On 5/20/2024 12:01 AM, Don Y wrote:

My understanding is that Ir remotes modulate an Ir "carrier" signal
in a particular pattern to express a particular "code" corresponding to
the key pressed/held.
>
And, that different "chipsets" use different carriers and encodings.
>
Is there a front-end that is tuned to the particular carrier
in the receiver?  Or, is all of this done "digitally"?
>
I.e., with a fast-enough (Ir) photodetector, should I be able to
decode ANY signal from ANY "remote"?

>
And, before anyone mentions the obvious, I've already looked at lircd
which is the reason behind this post; why do they claim they can handle
ALMOST all remotes?  Is this a limitation of their hardware implementation?
Or, timing problems in the way they try to process the raw video signal?

>
afaik almost all use a 30-50kHz carrier, nominally something like 38kHz,
I think the common IR receivers have build in bandpass filter, so it is just a matter of interpreting bits (there's a few common protocols)
>
I know that B&O (used to?) be an exception with a 455kHz carrier, I'm guessing

>
Yikes!
>

because someone clever many decades ago thought to use an AM IF filter

>
If that is the case, then signaling an interrupt on each edge/cycle
would obviously kill a linux kernel (I've handled 140KHz interrupts
but 455KHz would really be an annoyance)  50KHz would be a piece of cake.
>
Thanks.  I should be able to verify this by looking to see what sort
of B&O devices are (or are NOT) supported.

 I see no reason to deal with the carrier directly, for receive you just need a bandpass and deal with the much slower bits, for manay recievers that's is all yo can do, the output is data

I don't see it as a problem.  The flaw lies in how the lircd folks approached
it.  I can see the same hardware used slightly differently to address the
wider range of carriers.
But, by keeping that in mind from the onset (instead of trying to shoehorn
a capability into an existing OS/hardware design).

for transmit use a HWtimer/uart/spi whatever to generate the burst of carrier

I haven't decided if I want/need to handle transmission (at least not with the
same hardware).
A single receiver can listen for signal from many different, potential remotes
in a space.  A transmitter tends to need a more direct line of sight to
its intended device; blanketing an area with Ir in the hope that the device for
which it is intended "sees" it seems an iffy proposition.  It seems like
you would want an Ir emitter more closely coupled to the device if you wanted
to be sure to "talk" to it.
[And, wouldn't need the device to be sited in the same place as the "remote"]
device it is