rrw@naucse.cse.nau.edu (Robert Wier) (02/05/91)
Occasionally I have seen discussions here regarding the
remote controls used in tv/vcr/etc circuits. All of a
sudden I need some information on this quickly (for a
student demo lab we are trying to set up by Feb 22nd).
I have an IR receiver circuit, and have been looking at
the pulses coming out of it (from a Magnavox remote) on
a scope. What looks like is happening is that there
is an initial burst of information which is complex, followed
by much simpler repeats. I seem to recall that the initial
burst is a manufacturer/device ID so that conflicts between
different pieces of equipment can be avoided. The pulses are
sent at about 40khz.
Widths between pulses (which I assume denote a new
"number") are on the order of 1.8 ms.
So I'm seeing a lot of stuff, but I don't know what I'm looking
at! I'm certain that Don Lancaster or Steve Circida (sp?) has
had things on this in the past. If anyone had been experimenting
with this, I'd greatly appreciate any suggestions on reference
materials (RE? Byte? Circida's Circuit Cellar? IEEE? ... etc).
If there is a standard on this, I'd really appreciate a reference.
Please either e-mail me or post here. THANKS!
- Bob Wier
-------------- insert favorite standard disclaimers here ----------
College of Engineering
Northern Arizona University / Flagstaff, Arizona
Internet: rrw@naucse.cse.nau.edu | BITNET: WIER@NAUVAX | WB5KXH
or uucp: ...arizona!naucse!rrwrick@ofa123.fidonet.org (Rick Ellis) (02/08/91)
On <Feb 05 09:12> Robert Wier writes:
RW> What looks like is happening is that there
RW> is an initial burst of information which is complex, followed
RW> by much simpler repeats.
Many remotes do this, some just repeat the entire code, some don't repeat at
all, some repeat 2 or 3 times only, ad nauseum.
RW> I seem to recall that the initial
RW> burst is a manufacturer/device ID so that conflicts between
RW> different pieces of equipment can be avoided. The pulses are
RW> sent at about 40khz.
There is no real "standard" so it very much depends on what remote you're
looking at. Just about every encoding scheme you can think of has been used and
many more you'd never think of.
--
Rick Ellis
Internet: rick@ofa123.fidonet.org
Compuserve: >internet:rick@ofa123.fidonet.org
BBS: 714 939-1041
--------------------------------------------------------------------------greg@ccwf.cc.utexas.edu (Greg Harp) (02/09/91)
In article <2407.27B2CBE1@ofa123.fidonet.org> rick@ofa123.fidonet.org (Rick Ellis) writes: >On <Feb 05 09:12> Robert Wier writes: > > RW> What looks like is happening is that there > RW> is an initial burst of information which is complex, followed > RW> by much simpler repeats. > >Many remotes do this, some just repeat the entire code, some don't repeat at >all, some repeat 2 or 3 times only, ad nauseum. > > RW> I seem to recall that the initial > RW> burst is a manufacturer/device ID so that conflicts between > RW> different pieces of equipment can be avoided. The pulses are > RW> sent at about 40khz. > >There is no real "standard" so it very much depends on what remote you're >looking at. Just about every encoding scheme you can think of has been used and >many more you'd never think of. This looks like a good time to jump in with a question I thought of this morning. I came up with the (probably not very original) idea of "digitizing" remote control codes with my computer and playing it back via software control. Then not only could I add timing features to my audio/video equipment, but I wouldn't have a pile of remotes to deal with. (No, I don't like those universal remotes.) Now, I have a working knowledge of electronics, and I'd done quite a few projects, but I know little about the codes used by remote controls. (I knew that they tended to be 40kHz, but that's about it.) Anyway, what is the feasability of sampling these codes using basically a phototransistor hooked to some input (say a digital joystick port or parallel port)? I know that the digital audio samplers for the Amiga (the computer I'd be doing this with) on average max out at around 56K/sec at 8 bits-per-sample. Some claim to be much faster, but I've never really looked into them. Basically, my idea was to make 1-bit samples of the phototransistor's state at up to, say, 50K/sec (I don't know how fast I could push this yet). I would then play back these samples using an IR LED. At that speed could I expect a positive result? Also, what is the typical length of the code before it repeats? I could search for repeating patterns to shorted sample length. I guess I should ask for some info on the transmission technique. Is the signal just a set of bits that are transmitted one per forty-thousandth of a second, or is another signal modulated at 40kHz, or what? In that case, would it make more sense to sample at 40kHz? It is possible that I could use the first pulse to sychro-start (to steal a casio keyboard phrase :-) the sampling. Am I just plain insane? Greg -- -------Greg-Harp-------greg@ccwf.cc.utexas.edu-------s609@cs.utexas.edu------- "Confutatis maledictus "When the accursed have been counfounded Flammis acribus addictis, == And given over to the bitter flames, Voca me cum benedictis." -- Mozart Call me with the blessed."
bender@oobleck.Eng.Sun.COM (Michael Bender) (02/09/91)
In article <43935@ut-emx.uucp> greg@ccwf.cc.utexas.edu (Greg Harp) writes: >This looks like a good time to jump in with a question I thought of this >morning. I came up with the (probably not very original) idea of "digitizing" >remote control codes with my computer... > [...] >Basically, my idea was to make 1-bit samples of the phototransistor's state >at up to, say, 50K/sec (I don't know how fast I could push this yet). I >would then play back these samples using an IR LED. At that speed could I >expect a positive result? Also, what is the typical length of the code before >it repeats? I could search for repeating patterns to shorted sample length. you know what might be slick? have two "learn" modes to your device; one learn mode would just sample the incoming data stream at some arbitrary sample rate and store whatever it received from the phototransistor, and the other learn mode would be a smarter mode, where you could tell your device what kind of remote you had, i.e. a Sony TV remote, or a Panasonic VCR remote, etc... and the code in your computer would know that these specified remotes have a certain data stream, and you could sample at a rate at which the "known" remote outputs data, rather than sampling at an arbitrarily fast rate. of course, if you know the data rate of a given remote, you may probably also know what the data format is, so that you wouldn't have to sample the remote at all, you could just synthesize the data with your computer. manufacturers should get their act togther, and come up with a SINGLE remote protocol, with well-defined extensions for future options, rather than everyone going out and inventing their own format. but like most other things in this world, they probably see more $$$$ in having a proprietary format. mike -- Won't look like rain, Won't look like snow, | DOD #000007 Won't look like fog, That's all we know! | AMA #511250 We just can't tell you anymore, We've never made oobleck before! | MSC #298726
psfales@cbnewsc.att.com (Peter Fales) (02/11/91)
In article <43935@ut-emx.uucp>, greg@ccwf.cc.utexas.edu (Greg Harp) writes: > This looks like a good time to jump in with a question I thought of this > morning. I came up with the (probably not very original) idea of "digitizing" > remote control codes with my computer and playing it back via software > control. Then not only could I add timing features to my audio/video > equipment, but I wouldn't have a pile of remotes to deal with. (No, I don't > like those universal remotes.) Check out the March 1987 issue of Byte. The "Circuit Cellar Ink" column describes hardware and software to build your own "Trainable Infrared Master Controller." To really do the job right, you need to sample at a much higher frequency than the carrier of the IR signal you are attempting to reproduce and this probably requires special hardware. I built a box using the ideas in this article, though I used different hardware implementation. It includes both an Ultrasonic and IR transmitter so that it can control my X-10 devices using the (no longer available?) ultrasonic base station as well as devices with IR remotes. A fun toy. -- Peter Fales AT&T, Room 5B-420 N9IYJ 2000 N. Naperville Rd. UUCP: ...att!ihlpb!psfales Naperville, IL 60566 Domain: psfales@ihlpb.att.com work: (708) 979-8031
bame@hpfcbig.SDE.HP.COM (Paul Bame) (02/12/91)
I obviated the need to sample fast enough to catch the ~40KHz IR carrier by using the "IR Receiver Module" available at Rat Shack and other places. This module demodulates the mess and gives you a nice slow data stream to play with - about 1KHz seems typical. Another advantage is that it's usable across the room and so forth because it includes the amp and filter which you'd have to go to some length to re-create yourself - not bad for less than $4.00(US). Beware that it can aparently be overloaded by bright, close IR sources (remotes) and that your pulse timing may not be precisely reproducable under all circumstances due to its low-pass filter. -Paul "Spice is the Variety of Life" bame@fc.sde.hp.com N0KCL
rick@ofa123.fidonet.org (Rick Ellis) (02/13/91)
On <Feb 09 05:50> Michael Bender writes:
MB> manufacturers should get their act togther, and come up with a SINGLE
MB> remote protocol,...
That's one of the areas the EIA's CEBus addresses (the SR bus). It will remain
to be seen how well the industry will accept it.
--
Rick Ellis
Internet: rick@ofa123.fidonet.org
Compuserve: >internet:rick@ofa123.fidonet.org
BBS: 714 939-1041
--------------------------------------------------------------------------rick@ofa123.fidonet.org (Rick Ellis) (02/13/91)
On <Feb 09 03:51> Greg Harp writes:
GH> This looks like a good time to jump in with a question I thought of this
GH> morning. I came up with the (probably not very original) idea of
GH> "digitizing" remote control codes with my computer and playing it back
GH> via software control.
That's what we do in our remote.
GH> Then not only could I add timing features to my audio/video
GH> equipment, but I wouldn't have a pile of remotes to deal with. (No, I
GH> don't like those universal remotes.)
What don't you like about them?
GH> Basically, my idea was to make 1-bit samples of the phototransistor's
GH> state at up to, say, 50K/sec (I don't know how fast I could push this yet).
You'd lose the carrier information since 50k is well below Nyquist.
GH> I guess I should ask for some info on the transmission technique. Is the
GH> signal just a set of bits that are transmitted one per forty-thousandth of
GH> a second, or is another signal modulated at 40kHz, or what?
Most remotes modulate a carrier of about 40kHz onto the IR and then turn the
whole thing on and off at a much slower rate. Others, mostly older equipment
and cable boxes, use no carrier and just send fast single pulses.
--
Rick Ellis
Internet: rick@ofa123.fidonet.org
Compuserve: >internet:rick@ofa123.fidonet.org
BBS: 714 939-1041
--------------------------------------------------------------------------scott@blueeyes.kines.uiuc.edu (scott) (02/15/91)
In article <43935@ut-emx.uucp> greg@ccwf.cc.utexas.edu (Greg Harp) writes: > >This looks like a good time to jump in with a question I thought of this >morning. I came up with the (probably not very original) idea of "digitizing" >remote control codes with my computer and playing it back via software >control. Then not only could I add timing features to my audio/video >equipment, but I wouldn't have a pile of remotes to deal with. (No, I don't >like those universal remotes.) > >Now, I have a working knowledge of electronics, and I'd done quite a few >projects, but I know little about the codes used by remote controls. (I knew >that they tended to be 40kHz, but that's about it.) Anyway, what is the >feasability of sampling these codes using basically a phototransistor >hooked to some input (say a digital joystick port or parallel port)? I humbly suggest that you ftp to mrcnext.cso.uiuc.edu and download zapper.* from the /video directory. ZAPPER is an article which describes in detail precisely the project you're talking about. Have fun! -- Scott Coleman tmkk@uiuc.edu "Unisys has demonstrated the power of two. That's their stock price today." - Scott McNealy on the history of mergers in the computer industry.
rick@ofa123.fidonet.org (Rick Ellis) (02/19/91)
On <Feb 11 21:22> Paul Bame writes:
PB> and that your pulse timing may not be precisely
PB> reproducable under all circumstances due to its low-pass filter.
While the length of the pulses will not be at all precise (due to ringing in
the 40khz filter) the distance between pulse starts should be very good.
--
Rick Ellis
Internet: rick@ofa123.fidonet.org
Compuserve: >internet:rick@ofa123.fidonet.org
BBS: 714 939-1041
--------------------------------------------------------------------------