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"?
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?
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
because someone clever many decades ago thought to use an AM IF filter
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.
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 because someone clever many decades ago thought to use an AM IF >filter
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: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
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? >>>
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
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"?
Said another way, is the fact that a particular device ONLY
recognizes a particular remote related to its use of a particular
chipset (or, equivalently, decoding algorithm in software)?
[The former would be hard to change but the latter should be relatively easy]
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 thatis 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
Don Y <blockedofcourse@foo.invalid> Wrote in message:rthat 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
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
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.
My understanding is that Ir remotes modulate an Ir "carrier" signalhttps://en.wikipedia.org/wiki/RC-5
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"?
Said another way, is the fact that a particular device ONLY
recognizes a particular remote related to its use of a particular
chipset (or, equivalently, decoding algorithm in software)?
[The former would be hard to change but the latter should be relatively easy] Are you looking for something like this:
On Mon, 20 May 2024 00:01:18 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:
My understanding is that Ir remotes modulate an Ir "carrier" signalAre you looking for something like this:
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"?
Said another way, is the fact that a particular device ONLY
recognizes a particular remote related to its use of a particular
chipset (or, equivalently, decoding algorithm in software)?
[The former would be hard to change but the latter should be relatively easy]
https://en.wikipedia.org/wiki/RC-5
Years ago a long range remote used IR leds which could take 1A
current, but only for a microsecond or so. Microsecond pulses were
modulated with 33-38kHz "carrioer" and that was keyed with data,
around 1-2kHz.
There are dedicated deceiver modules which can output that data
On Mon, 20 May 2024 00:01:18 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:
My understanding is that Ir remotes modulate an Ir "carrier" signalAre you looking for something like this:
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"?
Said another way, is the fact that a particular device ONLY
recognizes a particular remote related to its use of a particular
chipset (or, equivalently, decoding algorithm in software)?
[The former would be hard to change but the latter should be relatively easy]
https://en.wikipedia.org/wiki/RC-5
Years ago a long range remote used IR leds which could take 1A
current, but only for a microsecond or so. Microsecond pulses were
modulated with 33-38kHz "carrioer" and that was keyed with data,
around 1-2kHz.
There are dedicated deceiver modules which can output that data
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 415 |
Nodes: | 16 (2 / 14) |
Uptime: | 93:30:32 |
Calls: | 8,690 |
Calls today: | 5 |
Files: | 13,250 |
Messages: | 5,947,125 |