Ir remotes

[Don Y]

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]

[Don Y]

Post by Don Y
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?

[Lasse Langwadt]

Post by Don Y

Post by Don Y
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

[Don Y]

Post by Lasse Langwadt

Post by Don Y

Post by Don Y
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!

Post by Lasse Langwadt
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.

[Lasse Langwadt]

Post by Don Y

Post by Lasse Langwadt

Post by Don Y

Post by Don Y
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!

Post by Lasse Langwadt
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

[Don Y]

Post by Don Y

Post by Lasse Langwadt

Post by Don Y

Post by Don Y
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!

Post by Lasse Langwadt
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

[Jan Panteltje]

On a sunny day (Mon, 20 May 2024 11:50:22 +0200) it happened Lasse Langwadt

Post by Lasse Langwadt

Post by Don Y

Post by Don Y
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

https://panteltje.nl/panteltje/pic/ir_pic/
used it to control my cable modem.
But I also have a Chungop SRM403E remote that can learn codes from other remotes.
In fact many remotes can learn codes from other remotes,
I have an other Chinese one that can.
Makes life sometimes easier, now you only need one remote for say 3 different devices.

[john larkin]

On Mon, 20 May 2024 00:01:18 -0700, Don Y

Post by Don Y
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]

If the IR link is DC-coupled, namely all digital, there is the
thresholding problem. If a photodiode converts light to voltage and
that drives a comparator or equivalent, where should one set the
threshold? What happens when the room light is bigger than the
received light from the remote (which it often is) ? How does one
handle, say, a 1000:1 receive power range?

A tuned front-end dances around these problems.

A mostly-digital receiver would use a fast ADC to digitize the
photodiode output and apply a LOT of DSP horespower. FFTs and such.

Have you researched the actual optical waveforms that remotes make?
There's tons of stuff online, and it might be fun to measure some too.

[Martin Rid]

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.

Cheers

[Don Y]

Post by Martin Rid

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

[LM]

On Mon, 20 May 2024 00:01:18 -0700, Don Y

Post by Don Y
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]

Are you looking for something like this:
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

[KevinJ93]

Post by john larkin
On Mon, 20 May 2024 00:01:18 -0700, Don Y

Post by Don Y
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]

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

Such as:

https://cdn-shop.adafruit.com/datasheets/tsop382.pdf

They do all the analogue processing and just output a datastream to the
decoder.

Typically the bitstream runs about 1kbit/s so easily decoded by software.

The transmitter can also be handled by driving an LED from a timer
programmed to output the 38kHz then doing on-off keying (OOK) to provide
the modulation. Minimal hardware outside a microprocessor is required.

kw

[Don Y]

Post by john larkin
On Mon, 20 May 2024 00:01:18 -0700, Don Y

Post by Don Y
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]

https://en.wikipedia.org/wiki/RC-5

Not directly, no. I was more looking for the details of "The command
data is a Manchester-encoded bitstream modulating a 36KHz carrier.
/(Often the carrier used is 38KHz or 40KHz.../" Or, as Lasse
mentioned 455KHz for some other (possibly non-RC5 compliant)
vendor implementations.

Post by john larkin
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.

I'm not (yet) interested in SENDING data. I'm, instead, looking
at "remotes" as yet another ubiquitous form of UI that users are
already accustomed to using -- especially for certain devices.

E.g., SWMBO has a couple of "bookshelf HiFis" that she uses
daily (and nightly). She is so accustomed to them that she
can operate the remote without even looking at it. (This is
handy in a darkened room; or, when you don't have "reading
glasses" handy; or, when you have eyedrops in your eyes that
distort your vision)

"Remotes" have advantages over other forms of UIs; you can
operate them without "uttering a sound" (so your spoken words
don't disturb others -- or, if you are unable to speak as with
ALS), without seeing them (if blind or otherwise vision impaired
AT THE MOMENT), can indicate the intended device to be controlled
(implicitly or by pointing the remote at the device in question
in the case of two or more colocated devices that could, potentially,
each respond to that remote).

They're reasonably small, don't require you to interact with, for
example, a "menu display". Batteries last a long time. Etc.

They are FAMILIAR to users!

Note that the "remote" has value even in the absence of the
controlled device. E.g., I can emulate SWMBOs "HiFi"
with other hardware (e.g., a media tank) yet still maintain
the UI with which she has become familiar:

"THIS button will turn the HiFi on/off. This OTHER button
will select the most recently selected radio station to be
played at whatever the most recent volume setting..."

The *protocol* also provides a seemless hook to control
Ir-controllable devices -- even WITHOUT the "remote".
E.g., I could locate a device "elsewhere" and push
commands to it using a nearby "remote emulator":
"PRETEND the user was nearby and pressed the power button
on YOUR controller -- even though he's not in the building
and your remote was lost/damaged/discarded previously!"
The optical coupling means you can interface to such a device
without having to disassemble the device and retrofit a
hardwired connection! (i.e., the USER can do this!)

Post by john larkin
There are dedicated deceiver modules which can output that data

It seems that the Receiver ^^^ :> module should be trivial to make
and incorporate into a design -- though not the way lircd approached
the problem (unless you are willing to "settle" for its limitations).

Thanks for the reference! I was just planning on scraping the
configuration files from lircd to get a head start on the
various "command mappings"

[I'm sure the reference only applies to SOME devices. E.g., which
commands would be used to control the Ir-enabled *fan* that I have
in my office?]