Subject:
|
[Fwd: [agenda-dev] IrDA port]
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 31 Jan 2001 20:26:59 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmail.*SayNoToSpam*net>
|
Reply-To:
|
sjbaker1@NOMORESPAMairmail.net
|
Viewed:
|
1609 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
|
|
|
|
