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 / 14163
14162  |  14164
Subject: 
[Fwd: [agenda-dev] IrDA port]
Newsgroups: 
lugnet.robotics
Date: 
Wed, 31 Jan 2001 20:26:59 GMT
Original-From: 
Steve Baker <sjbaker1@*AntiSpam*airmail.net>
Reply-To: 
SJBAKER1@AIRMAIL.NETavoidspam
Viewed: 
818 times
  
I saw this post on the Agenda PDA mailing list. (The Agenda is a palmtop
Linux computer that has *both* CIR and IRDA ports - and thus might be
*IDEAL* for controlling Lego RCX/Scout machines without the Lego IR tower
or any other external hardware).

It gets pretty technical...

Jack Gassett wrote:

Keith,

CIR is used for remote control and IRDA is used for data transmission over
IR. Unfortunately they are pretty much incompatible. IRDA drivers have been
around for awhile now, in our case the IRDA transceiver is wired to the
second serial port. I am not to clear on this, but either the second serial
port is put into IRDA mode and the IRDA pulses are converted into
asynchronous serial data or the IRDA protocol itself is asynchronous serial.
(I can't help but thinking there is some hardware translation at play here.)
But either way the data itself is framed with start and stop bits. And this
is the heart of why IRDA and CIR are not compatible.

Generally speaking CIR data is modulated onto a carrier frequency (38kHz
being the most common). Meaning in the simplest terms a 1 is represented by
a sawtooth wave (usually with a freq of 38kHz) and a zero is the absence of
a sawtooth wave. The length of the sawtooth wave and length of no wave is
determined by the modulation scheme used. I think for rc-5 (the most popular
scheme) Rochester is used. But for our purposes we do not really need to
know what scheme was used to recreate the waveform.

Since CIR waveforms don't have any concept of flow control we will not be
able to capture the correct waveform if we pass the IR stream through a
UART. The UART is going to drop frames when it is expecting a stop bit and
it does not receive one which will distort the waveform possibly destroying
the data. There is a scheme that uses 7N1 @ 115200 Bps, this theoretically
works since it guarantees that there will always be stop bits in the right
places as long as the sawtooth wave lasts for three bytes of data. But from
what I read this is not terribly stable and does not have very good
distance.

So for the best CIR solution we will need direct access to the IR stream.
According to Shane the IR transceiver is wired directly to a GPIO, 19 if I
remember correctly. So this means whatever code we write will need to be in
the Kernel. Since I am new to Linux programming this is a bit daunting for
me. However I have found some code that looks promising from the lirc
(http://www.lirc.org) project. In their serial driver they get around the
framing problem by using the cd pin on the serial port to bring in the data
and the dtr pin to send out the data. They detect CIR by waiting for an
interrupt from the cd pin and then grabbing the IR data. I think we should
be able to modify their code to generate an event when the memory mapped to
GPIO19 (GPIO's above 15 wont generate IRQ's according to the vr4181
datasheet) changes and then grab the data from that memory location. There
are a couple other things that may need to be taken into consideration when
modifying their code. The first is that they use hardware that puts a 1 on
the cd pin for the entire time there is a 38kHz signal. Then when they send
the signal out they change that 1 to a 38kHz signal. I am pretty sure that
our transceiver will pass the raw waveform not a 1 indicating the presence
of a 38kHz signal. The other issue is that the waveform passed will probably
not be a true sawtooth. It will be more of a .5microsecond pulse
representing the positive period of the cycle. The lirc serial driver has
provisions for duty cycle which should address this I think...

If we modify lirc's serial driver we would be able to take advantage of
their existing userland code. I am looking at doing this but since I am
learning everything as I go so it may take me awhile... I am sure this would
be trivial for an experienced C/linux programmer.

Our other option is to use their SIR driver which uses the 7N1 @ 115200 Bps
scheme... This would be the easiest but least stable (and limited to 38kHz)
approach.

This is just a quick overview and I could be wrong on some things since I
wrote this off the top of my head and didn't really look anything up. But
the concepts should be close although I simplified some of them. Anyway I
hope this helps more than it hurts.

Jack.
_______________________________________________
agenda-dev mailing list
agenda-dev@lists.agendacomputing.com
/mailman/listinfo/agenda-dev

--
Steve Baker   HomeEmail: <sjbaker1@airmail.net>
              WorkEmail: <sjbaker@link.com>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net



1 Message in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    
Active threads in Robotics

 
Verified and Trusted Team of Hackers
9 hours ago
Custom Search

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