To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 15514
15513  |  15515
Subject: 
RE: Custom Firmware, IR Problems, and Dead RCXs
Newsgroups: 
lugnet.robotics
Date: 
Tue, 29 May 2001 03:42:17 GMT
Original-From: 
Jim Lee <jlee@+antispam+proaxis.com>
Viewed: 
626 times
  
Matthias Jetleb wrote:

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%)?


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 serial communication stuff - all hardware UARTs sample at
the midpoint of each bit time to determine the state of the bit.  IrDA
transceivers generally sample 1/16 of the way into the bit time.


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.

Again, this makes no sense.  We're talking about the duty cycle of
individual bits, not the duty cycle of the entire communication.  You can be
communicating continuously (100% duty cycle) with each "on" bit lasting,
say, 10mS, and each off bit lasting, say, 90mS (10% duty cycle).  True IrDA,
for example, has a duty cycle of 6.25% (that's what most laptops and PDAs
speak).  The picket-fencing phenomenon that you're suggesting just doesn't
apply.


[over-simplified explanation of Nyquist sampling method deleted]


Again, your comments do no apply.  The Nyquist theory of oversampling only
applies when you are sampling data with multiple frequency components (such
as audio or video).  Here, we have a simple, known-baud-rate data stream.
Once we see a start bit, we can calculate exactly where each following bit
should be, and capture it with one sample.  I won't go into additional
details like bit jitter and clock phasing error over long bit streams since,
again, they do not apply in the case of the RCX and IR Tower.

Just some thoughts to consider before getting too gung-ho.

Matthias Jetleb
VA3-MWJ


Same here.

-Jim Lee



Message is in Reply To:
  Re: Custom Firmware, IR Problems, and Dead RCXs
 
(...) 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 (...) (23 years ago, 29-May-01, to lugnet.robotics)

17 Messages in This Thread:







Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR