Richard Prosser wrote:
>
> Hi Mike,
> No, I'm just using standard ASCII encoded charecters. It was initially
> intended as a test bench to try out different encoding schemes and
> eroor detection/correction etc. But it turned out adequate for a
> monitoring project and I left it at that.
> I did find I had to send a reasonably long preamble to get the data
> slicer setup proerly and that the quoted 10kb/sec ? (9600 in my case)
> was unreliable.(IIRC it was 10k for the transmitter and 5k for the
> receiver anyway).  I think I ended up using 2400. I've still got a
> spare transmitter somewhere that I intend to use to expand the system
> so I might have a look at improving things as you suggest.

The performance is only decent if the DC average is zero, within a short 
time period < x3 clock rate.
Maxim has a decent application note explaining the dataslicer theory and 
how you need to change the various Cs and Rs to match your clock rate 
and why it has to be manchester encoded (least time for zero DC 
average). Data rate is of course 1/2 clock rate.

the data slicer can work with as few as 2 preamble bits, but 5 is 
better, if you have all the time constants right.

You can use a zero crossing detector instead of a Data Slicer, and you 
need no preamble, but it's very much more sensitive to noise.

The transmitter doesn't care about the datarate as it's just a SAW 
stabilised  Colpitts oscillator and with decent UHF transistor will turn 
on/off >20kbps. The "data" in is usually just bias resistor to base of 
transistor. 



-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist