Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lasse Langwadt <llc@fonz.dk>
Newsgroups: sci.electronics.design
Subject: Re: Ir remotes
Date: Mon, 20 May 2024 13:47:51 +0200
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <v2fd98$3vdis$1@dont-email.me>
References: <v2esfv$3s1ts$1@dont-email.me> <v2etb9$3s8ci$1@dont-email.me>
 <v2f6cv$3tvoi$1@dont-email.me> <v2fate$3usaf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 20 May 2024 13:47:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a75d9c77c2cedba5e73953b84cdb6c19";
	logging-data="4175452"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/WxOIb4rWtceoKuJogCUK5QmNbOKhxazM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:nkQd3WU9AZoumfMq43kvPStu8ko=
In-Reply-To: <v2fate$3usaf$1@dont-email.me>
Content-Language: en-US
Bytes: 3149

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

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