Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Re:Ir remotes
Date: Mon, 20 May 2024 11:46:05 -0700
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <v2g5pg$4fiq$3@dont-email.me>
References: <v2esfv$3s1ts$1@dont-email.me> <v2fsqt$2lbv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 20 May 2024 20:46:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5d80f1dc6dc80e940061abf9488d5484";
	logging-data="147034"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/CZDv+Hd5NkcTH1n7d8zIl"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:mH9DUlGkoSIGoYiBotjMdqokxTw=
Content-Language: en-US
In-Reply-To: <v2fsqt$2lbv$1@dont-email.me>
Bytes: 2697

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"]