Subject:
|
Re: IR Collision avoidance
|
Newsgroups:
|
lugnet.robotics.handyboard
|
Date:
|
Mon, 3 Mar 1997 06:23:45 GMT
|
Original-From:
|
Bill Richman <bill_r@inetnebr.comSAYNOTOSPAM>
|
Reply-To:
|
bill_r@inetnebr.com&Spamcake&
|
Viewed:
|
1652 times
|
| |
|
|
Well, at risk of being branded a heretic, since you've brought up the
issue of modulated IR, I'm going to throw out an observation
I've made about the Radio Shack IR sensors which several other people
on the mailing list have privately disagreed with me about. In my
experiments with the IR sensors, they have shown little or no
interest in a constant 40Khz carrier; the output goes active for a
moment when the 40Khz is first switched on, but then goes inactive
until something interrupts the beam. A couple of people have
explained to me in private mail that there is no need to modulate the
40Khz, because the sensor will pick it up no matter what. That has
not been my experience on the test bench, and a friend who is an
electrical engineer and who has used similar devices to design
touch-screen displays and the like explained it to me. The Sharp IR
sensor sold by Radio Shack has a built-in "automatic gain control"
circuit to allow it to adjust to the background IR noise level in the
environment. Otherwise, in some environments, it would constantly
trigger from background noise, and in others would not be sensitive
enough to pick up the transmitter. The net effect of this is that if
you just shine an LED modulated at 40Khz at the sensor (or bounce one
off a wall into the sensor), in a short time the sensor's gain
control has effectively "averaged out" your signal as being part of
the normal background IR environment, and no longer reacts to it. My
friend went on to explain that if you look at the signal from an IR
remote control for a TV or other device, you will see a burst of
"wake up" pulses at the beginning of each transmission, to help the
gain control calibrate itself to the remote's signal level (which
changes depending on the distance, battery voltage, etc), prior to
sending the real data. Otherwise, he says, the first couple of bits
of data would often be lost before the sensor reacted to the new
signal level. That has been my exact experience in testing with the
sensors Radio Shack carries. This led me to build the circuit which
is included in the spec sheet (which Radio Shack will fax to you if
you dial the number given on the back of the package (800-323-6586)
and request document number 3313. To get an index of documents
available, request document number 9999.) Actually, I built the
portion of the transmitter that generates the 38Khz carrier, using a
single 555, and on the same board built the 567 portion of the
circuit, and then connected the signal on pin 5 of the 567 to pin 4
on the 555 to gate the 555 on and off at 200Hz. Since the 567 is
also generating the modulating frequency (a luxury you don't have on
a standard remote-control setup, since the transmitter and the
receiver are eletrically separate from each other), it doesn't even
matter if the frequency drifts, because the frequency the detector is
looking for will always match it. Feeding the output of one of the
IR sensors to the input of the 567 (as shown on the spec sheet)
allows the 567 to lock perfectly onto the modulated IR carrier, and
produces a solid TTL-level output that can be fed to the Handy Board.
Now all I have to do is figure out a way to easily multiplex several
IR sensors to one copy of this circuit. Since there are plenty of
inputs, but few outputs on the HB, I'm thinking of using a 74151
one-of-eight multiplexor chip and a BCD counter to connect each IR
sensor in sequence to the 567 tone decoder, and connecting the output
of the 567 along with the 3 bit BCD count value being fed to the '151
to 4 of the inputs on the HB, so if it sees an active input from an
IR sensor, it can read the sensor number that is currently being
scanned, and take appropriate action. I know this is probably a lot
more information that you wanted, but since I've had several people
e-mail me privately to either a) ask how I was implementing the
sensors, or b) tell me that this complication is not necessary, since
they claim the sensor reacts to a steady 40Khz signal as well as a
modulated one, I thought it might be useful to get it all on the
table at once. The only thing that comes to mind that may allow them
to get away with not explicitly modulating the 40Khz is that either
they are scanning the LEDs on and off fast enough that it gives the
same effect as modulating the beam (i.e. it wakes up the IR sensor's
AGC circuit), or the fact that the wall or other surface they are
bouncing the beam off of is irregular enough that it serves to "chop"
the reflected beam, thus keeping the AGC circuit from turning down
the gain to a point the signal is no longer seeen? Comments?
-Bill
>
> >
> > The transmitter is basically a modulator made from two 555 timer chips.
> > One timer does 200-1000 Hz (we use 500) while the other does 38 KHz. On
> > a scope, the output looks somewhat like..
> >
> > |||||||||| |||||||||| ||||||||||
> > | | | | | |
> > | | | | | |
> > ----------- ----------- ----------- ----------
> >
> > ^ ^ ^ ^
> > One complete cycle The high of each cycle
> > of 500 Hz pulses the 38KHz
> >
> > The tone decoder (receiver) demodulates the signal. If is senses the
> > 38KHz signal it puts out a logic one (or zero depending on design) that
> > can go to any available digital port. The port is processed like...
>
> I have a few questions for you. How did you combine the 38khz and 500hz
> signal. In a design that I am working on now I have two signals similar to
> yours and an enable signal running into a three input AND gate. I haven't
> built it yet but it simulated correctly. In my design I am going to have
> 14 individual sensors being activated and sequenced with a decoder and
> multiplexor. I want to have the external circuits of the signal do as much
> work as possible so that the CPU has more free time. I need to know if I
> can use a 567 tone decoder to sense the 500 Hz signal coming from the
> detector. This is important to me because I can't have the CPU constantly
> looking for the signal. Thanks for all your help. If you have no idea
> what I am asking or need more information please e-mail me.
>
> Keith
>
>
> Keith Soldavin
> kas219@email.psu.edu
> http://www.personal.psu.edu/users/k/a/kas219/
>
>
-Bill Richman
bill_r@inetnebr.com
http://incolor.inetnebr.com/bill_r
|
|
Message has 1 Reply:
 | | Re: IR Collision avoidance
|
| At any point are you making an effort to detect your 40kHz IR signal? If you use the sharp IR detector to receive your 40kHz signal you are going to get an initial burst when the thing first turns on and then it will average out to zero just like (...) (28 years ago, 3-Mar-97, to lugnet.robotics.handyboard)
|
Message is in Reply To:
| | Re: IR Collision avoidance
|
| (...) I have a few questions for you. How did you combine the 38khz and 500hz signal. In a design that I am working on now I have two signals similar to yours and an enable signal running into a three input AND gate. I haven't built it yet but it (...) (28 years ago, 2-Mar-97, to lugnet.robotics.handyboard)
|
5 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
