Re: Ir remotes

Liste des GroupesRevenir à e design 
Sujet : Re: Ir remotes
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.design
Date : 21. May 2024, 03:01:52
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v2grq3$8k52$2@dont-email.me>
References : 1 2
User-Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
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?]

Date Sujet#  Auteur
20 May 24 * Ir remotes13Don Y
20 May 24 +* Re: Ir remotes6Don Y
20 May 24 i`* Re: Ir remotes5Lasse Langwadt
20 May 24 i +* Re: Ir remotes3Don Y
20 May 24 i i`* Re: Ir remotes2Lasse Langwadt
20 May 24 i i `- Re: Ir remotes1Don Y
20 May 24 i `- Re: Ir remotes1Jan Panteltje
20 May 24 +- Re: Ir remotes1john larkin
20 May 24 +* Re: Ir remotes2Martin Rid
20 May 24 i`- Re: Ir remotes1Don Y
20 May 24 `* Re: Ir remotes3LM
20 May 24  +- Re: Ir remotes1KevinJ93
21 May 24  `- Re: Ir remotes1Don Y

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal