Hi Zack,

> i am busy with an experiment to send asyncronis data from
> one pic 16c57 to anather pic 16c57 via a rf link. i would like
> to find out if i can run both pic's on  a rc osc. configuation.
> i had a look at the accuracy and in the aplication notes it is
> stated as 28%, according to that it does'nt seem possible
> because it gives you an error off at least 56%.

It will give you the 56% error over 2 bits, over the more
usual 10 bits it will have accumulated more than 280% of a bit
time uncertainty.  This makes it useless for normal fixed rate
async data.

However not all is lost if you are prepared to write some code.

Seeing as the serial drivers are software modification is not
the end of the world.  You have a few choices here.

Remember that the instantaneous frequency stability of the RC
occilator is pretty good (assuming a stiff powersupply) but even if
this were not so you could use a protocol that uses two pulse
lengths for the '1' and '0' bits and have the receiver retrain
on each bit knowing that the longer ones have to be, say, '1's
and the shorter ones '0's.  If you send a '0' as the start bit
you know the relative timing speed of the transmitting device
at the receiver from this and if your '1' bits are twice as long you
can decode them and fine tune your decision point by keeping a
moving average of the short and long pulses and then testing if a
pulse if more or less than half way.

If you want to send ASYNC data then you could always make sure that
your protocol has some special character a Null or a $FF and the
receiver measures the pulse and uses this in the receive timing loops
for the current packet.  This will break down if you loose packet
synchronisation unless you continuously measure the shortest bits
and use this as a bit interval then more than half of the possible
byte values will have a single bit transition which will recallibrate
the receiver.

The third method is to send a special preamble that will callibrate
the receiver, synchronise the packet state machine.  Barcodes use
this method and you can see that there is a special patterns of
(narrow) bars at the ends of a UPC code that will not occur elswhere.
The Microchip KeeLoq code hopping devices make use of this and the
first method above.  This gives a protocol that is very robust and
insensitive to bit rate.

The PICs certainly have enough bandwidth to achieve any or all of
these methods if they are not otherwise very busy.

Cheers
--
Kalle Pihlajasaari     kalle@data.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751