Subject:
|
Re: Custom Firmware, IR Problems, and Dead RCXs
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 29 May 2001 02:59:54 GMT
|
Viewed:
|
727 times
|
| |
|
|
> IR Tower. I agree with your observations, but have a question: Is the
> processor in the IR Tower controllable (i.e. downloadable, like the RCX)?
Actually, it's the computer itself that determines the duty cycle.
This does mean that you could change the duty cycle, but you should be
aware that it would be at the expense of noise immunity and would
require a higher sampling rate from the RCX.
> 50%. You can keep the same baud rate and framing characteristics, but
> modify the individual bits so that they only turn on for, say, the first 10%
> of their allotted bit time. At the other end of the link, all that needs to
> be done is to have the receiver sample each bit earlier in the cycle, during
> the first 10% rather than near the midpoint. Of course, if the IR Tower and
I know what you mean to say, but it brings up an interesting technical
point:
Think about it - if you were sampling at the midpoint of the signal,
how whould you know where that was if you didn't already take a sample
at the start of the signal? You can't have a midpoint without a
beginning...and if you already took a sample to determine when a bit
has begun, what's the point in sampling it again at the mid-point (or
at 10%)?
What the RCX does in trying to receive a signal is analogous to you
wandering around with your eyes closed and opening them every few
seconds to sample your surroundings. Imagine doing this in a
completely dark room with someone turning the lights on and off at a
50% duty cycle. You're only going to able to take in your surroundings
if your eyes are open when the lights are on. Drop the duty cycle down
to 10% and the chances are you will be opening your eyes to darkness.
Note that like the RCX you have no way of knowing when the lights are
going to be turned on next, except by a rough estimate of the timing.
This is known as asynchronous communications and, while being simple
to implement, it has drawbacks in terms of reliability, speed and the
amount of attention the receiver must pay to data that may or may not
be coming. There are two solutions to this. The first would be the
modem in your computer. This is a dedicated chip that does nothing
except wait for the next possible data bit and signals the computer
when it arrives. The RCX doesn't have a dedicated modem, so we use
option two - continuous sampling. This attempts to achieve the same
goal at the expense of performance. Note that at a 10% duty cycle,
(each data cycle gets divided up into 10 time slices, one of which
contains a valid data bit) you *must* sample at slightly higher than
10 samples per data cycle to ensure that you capture the data bit.
20 samples per data cycle is actually ideal (double the frequency of
the highest data rate - this is refered to as the Nyquist rate)
If you reduce the duty cycle to 5% you end up sampling at slightly
more than 20 times per data cycle (ideally 40 times).
This will reduce the electrical stress on the components but the
processor time taken to read and anylize samples will become a
significant burden to the exclusion of other tasks.
It should also be pointed out that as you reduce the IR transmission
time, you become increasingly susceptible to spurious IR sources (IR
noise) and data transmission will become more unreliable.
Just some thoughts to consider before getting too gung-ho.
Matthias Jetleb
VA3-MWJ
P.S.: I haven't tried it yet, but I still think the best method of
saving the IR transmitters from an untimely fate is to add another one
or two IRLED's in series with the existing ones. This will reduce the
current in much the same way that the resistor does, but at least the
extra energy dissipated will be in the form of IR light (useful) as
opposed to heating a resistor (wasted).
|
|
Message has 2 Replies:
 | | RE: Custom Firmware, IR Problems, and Dead RCXs
|
| (...) Ummm, that doesn't make sense. You know where the midpoint is by knowing the baud rate, and hence the bit width. The only time you need to sample at the beginning of the bit time is to look for a start bit. This is all very basic asynchronous (...) (23 years ago, 29-May-01, to lugnet.robotics)
| | | RE: Custom Firmware, IR Problems, and Dead RCXs
|
| (...) <snip> (...) <snipped more> Well, no. The RCX receiver is a standard IR unit tuned to the carrier frequency. when I look a the signal on my scope, I get a nice square-shaped wave that is the same as the data byte (with start and stop bits) (...) (23 years ago, 29-May-01, to lugnet.robotics)
|
Message is in Reply To:
| | RE: Custom Firmware, IR Problems, and Dead RCXs
|
| Ralph, Thank you for painting a much clearer picture of the internal design of the IR Tower. I agree with your observations, but have a question: Is the processor in the IR Tower controllable (i.e. downloadable, like the RCX)? If it is, then there's (...) (23 years ago, 28-May-01, to lugnet.robotics)
|
17 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
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
