Re: Re:Ir remotes

On 5/20/2024 9:13 AM, Martin Rid wrote:

Don Y <blockedofcourse@foo.invalid> Wrote in message:r

My understanding is that Ir remotes modulate an Ir "carrier" signalin a particular pattern to express a particular "code" corresponding tothe key pressed/held.And, that different "chipsets" use different carriers and encodings.Is there a front-end that is tuned to the particular carrierin the receiver?  Or, is all of this done "digitally"?I.e., with a fast-enough (Ir) photodetector, should I be able todecode ANY signal from ANY "remote"?Said another way, is the fact that a particular device ONLYrecognizes a particular remote related to its use of a particularchipset (or, equivalently, decoding algorithm in software)?[The former would be hard to change but the latter should be relatively easy]

 Yes, its modulated as others pointed out.
I think the Philips protocol is the most common. Played with
  decoding a hauppauge remote years ago.  I think there's a
  preamble to set the timing for 1 and 0, then the data follows.
  Pretty simple.

Yes, I suggested that in my question.  What I wanted to know was why this
sort of expectation (as embodied in lircd) wasn't enough to address ALL
remotes.  The hardware used for such is relatively trivial leaving all
of the work to the associated software.
And, if those exceptions were of a particular type or for a particular
type of equipment or to support a particular set of capabilities.
[I.e., maybe I wouldn't *care* about supporting them!  I've not seen
a published EXHAUSTIVE list of "these won't work with this approach"]