Indeed . . . . . Assembly
was used to cram a custom protocol for Ired Xmit / Rec. into
approx.
450 slots . We also
decided on our own protocol , because we could tweek the " pulse-width's
",
number of bits , the
pattern . . . . . oh well . . . .the whole scheme. The best part , as you
mentioned ,
this routine will ignore
everything else that's out there and has full recovery from aborts ,
plus
will retry, after an abort
, for up to 3 times ( to be sure it wasn't just a studder ) before it says . . .
.
forget it . . . .
.
The unit emits a 10 msec
" burst " to find other units that are within range . . . when
another
device sees the Ired (
which is modulated at 56 khz. ) it switches immediately into it's
own
Ired Rec. routine ,
measures the burst length . If it's Less than 3 msec . . . . it was
garbage ,
if it's over 3 msec , but
less than 20 msec. , it calls it a " Find " burst and then sends it's
own
sequence ( which is a 30
msec burst , followed by a 1 msec guard-sync , then 24 bits
data).
After sending it's sequence
it immediately drops into a receive ( from the initiating unit )
and
waits up to 5 msec for the
other unit to return the favor ( or Xmit it's 30 msec + data ). In the
first
part of the cycle , if the
" find " burst was measured to be over 20 msec. then it
graciously
accepts the incoming
guard - sync and data bits. After the two units ( or more ) gab for
up
to " four "
cycles ( this is usually only when they are face to face ) , the routine
breaks up the
conversation by inserting
a " wait - period " and then enters the routine again . . . .
.by emitting
up to eight , 10 msec
" find " pulses , each 3 seconds. Naturally . . . . all the
timing is flexible
through the code and we
like to call the system " Talk - When - You - Can " (tm) . . .
because
it reminds us of how people
communicate . They walk up , try to interrupt and when
someone
else is talking , they wait
until they get a nod , repeat their story , as many as " four "
times and
then walk away
:)
We used a 16C65A ,
for the ease of the PWM 's generation of the 56 khz. Ired output and the
input
( 56khz. de-mod ) was
fed into PORTA . . . . . with the routine doing " polling " with an
active signal
generating a sampling
window algorithm . The Ired diode is a " Vishay - TSAL 7600 " ,
which is
giving us 10 feet of range
, with a modest 60 mA / pk drive ( less duty , about 25- 30 mA
). The
detector is a "
Vishay - TSOP 1756 " 56khz. photomodule w/ ttl-cmos compatible
output. If driven
somewhat harder ( 100 mA to
400 mA ) the Ired Diode and Photomodule is easily capable of
30 meters. But, our
app. is portable and we are very happy with the short range . . . . .
.
Regards . . . .
Steve Kelley
Protobyte Inc.
Wagner Lipnharski wrote:
>
> I
am doing a project that uses Atmel AT89C2051 with the unique
function
> to detect IR, decode and simulate six switches for another
uC. The cost
> of those uC are so low that doesn't make sense to
go for a special
> code/decode chip. The good advantage is that
you can create your own
> protocol and coding system (if you build the
transmitter), so no
> interferences from common IR
remotes.
>
> This detector use a regular 36-54kHz IR receiver
(Digikey), the
> At89C2051, 7.3728MHz crystal, RC (reset), and a R+Led
to indicate
> InfraRed presence. All the '2051 software to decode the
SAA3010 remote
> was done in just 115 bytes (assembler for sure, try
to do that in
> "C"...), that's right, it is using just 5.6%
of the 2048 bytes of the
> chip flash code memory, and can identify
the numeric 0-9 keys. A single
> increase at the conversion
table can decode all possible SAA3010
> transmissions with minimum
software increase.
>
> The actual low cost of those uC simply
eliminate the possibility to
> break my neck trying to squeeze more
juice from the actual main uC and
> make it decode the incomming IR...
Fast and easy... why everybody is so
> ashamed to use more than one
uC?.
I have just come to the same conclusion regarding another PIC to
do the job
of the SAA3049 decoder. Any code suggestions for elegant
RECS80 decoding?
Cheers
Dave