• Ir remotes

    From Don Y@21:1/5 to All on Mon May 20 00:01:18 2024
    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]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Don Y on Mon May 20 00:15:52 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt@21:1/5 to Don Y on Mon May 20 11:50:22 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Lasse Langwadt on Mon May 20 04:07:24 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt@21:1/5 to Don Y on Mon May 20 13:47:51 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to llc@fonz.dk on Mon May 20 12:37:41 2024
    On a sunny day (Mon, 20 May 2024 11:50:22 +0200) it happened Lasse Langwadt <llc@fonz.dk> wrote in <v2f6cv$3tvoi$1@dont-email.me>:

    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

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Lasse Langwadt on Mon May 20 06:07:09 2024
    On 5/20/2024 4:47 AM, Lasse Langwadt wrote:
    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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john larkin@21:1/5 to blockedofcourse@foo.invalid on Mon May 20 06:41:28 2024
    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" 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Rid@21:1/5 to Don Y on Mon May 20 12:13:16 2024
    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.

    Cheers
    --


    ----Android NewsGroup Reader---- https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Rid on Mon May 20 11:46:05 2024
    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"]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From LM@21:1/5 to blockedofcourse@foo.invalid on Mon May 20 23:07:54 2024
    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" 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From KevinJ93@21:1/5 to All on Mon May 20 14:43:18 2024
    On 5/20/24 1:07 PM, LM wrote:
    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" 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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to All on Mon May 20 18:01:52 2024
    On 5/20/2024 1:07 PM, LM wrote:
    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" 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

    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.

    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!)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)