Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!cit-vax!tybalt.caltech.edu!madler
From: madler@tybalt.caltech.edu (Mark Adler)
Newsgroups: comp.sys.handhelds
Subject: Re: Easy HP infra-red PC receiver.
Message-ID: <13166@cit-vax.Caltech.Edu>
Date: 6 Jan 90 21:37:45 GMT
References: <5916@sdcc6.ucsd.edu> <10169@microsoft.UUCP> <5941@sdcc6.ucsd.edu>
Sender: news@cit-vax.Caltech.Edu
Reply-To: madler@tybalt.caltech.edu.UUCP (Mark Adler)
Organization: California Institute of Technology
Lines: 67

Some more notes on the IR detector from Radio Shack:

First off, like I said in the last note, the 40 KHz bandpass filter
is not a problem, since it is only down 6 dB (a factor of four in
power) at 32 KHz.  Since the power of an evenly radiated source goes
down as the square of the distance, this is the same as moving the
source twice as far from the detector.  Experimentally, the range of
this link is at least fifteen feet, so the real effect of having the
correct (32 KHz) bandpass filter in there would be to increase the
range to over 30 feet.  But who really needs that?

As far as accurate timing information is concerned, IBM PC's and
clones (and most other computers for that matter) have a high
resolution timer that can be used to measure the time between these
pulses accurately enough to decode the data.  In fact, I have used
the timer in the PC to measure the pulses far more accurately than
needed, effectively using the PC as an oscilloscope to figure out why
I was having the problem with just the first few bytes.  Other than
that problem, I have been able to read bytes from the calculator with
no error whatsoever (the error correction code in my program has
never been activated---if the start bits of the byte are detected,
then the entire byte and the four correction bits are decoded with no
error).  The timing for decoding is not all that stringent.  You only
have to be able to distinguish a time of 427 uS from 854 uS from 1282
uS.  In 427 uS, my machine (an 8 MHz 286) can execute around 100 to
400 instructions, depending on their complexity and how much
branching and looping there is.  And that's more than enough
instructions to do the task at hand.

The only problem I have is when the stream first starts, and the
detector is a little too anxious to produce pulses from the signal.
Then the first few bits, especially the start bits which are pulses
that are only one half bit time apart, get run together into a single
long pulse.  There is no software cure for this, aside from sending
garbage bytes to start with.

Alonzo, perhaps you know what SYSEVAL address in the HP-28S sends a
single byte (with all the framing and parity bits) out the port?  If
so, then I can use that to write a program to send data from the HP
as packets: with a few garbage lead-in bytes, a header, and some
overall packet error detection (besides the byte error detection),
all in one continuous stream, and have my PC-end program receive
those packets.  This would work with the Radio Shack detector
unmodified.

As far as receiving data from the calculator when it is using its
normal print functions, that will require modification to the
detector, if it is possible at all.  I'm working on that.  It is
possible that changing one of the external components would change
either the automatic gain control, or the bandpass frequency, either
of which has a chance of curing the run-together-bits problem.  (Just
by the way Steve, the 4.7 uF (not 47 uF) cap is just there to smooth
out the power source, to reduce noise.  Changing it wouldn't help. 
However, I'm hoping that changing the surface mount resistor or one
of the surface mount capacitors might.)  Also, for others playing
with the part, I found that external noise is killed almost entirely
by connecting the metal case that the detector is in to the
detector's ground.  Apparently, the metal case is there for a
reason.

And also, Steve, you're right not to let the naysayers deter you.

Mark Adler
madler@hamlet.caltech.edu

The opinions expressed here are not, in fact, mine, but rather belong
a small worm that lives on the fourth planet out from Betelgeuse.