2009/8/18 PicDude : > > Oops, this should be 400 us (*micro*seconds) long each. > > > > PicDude wrote: >> >> ... over 70 sequential data bits which are around 400ms long each... >> > > -- > View this message in context: http://www.nabble.com/Better-way-to-read-a-serial-data-stream--tp25018655p25018667.html > Sent from the PIC - [PIC] mailing list archive at Nabble.com. > Picdude. I think you need to organise a system in which the errors don't accumulate. I used a method (many years ago) that maintained bit synch that may be useful. Trouble is it's a bit hard to explain. Basically you sample twice per period, once at the transition and once at the anticipated midpoint. If the midpoint reading agrees with the transition reading but the bit has changed from the previous bit (midpoint), then you assume that you have sampled late and your clock is a bit slow. Similarly, if the bit has changed, and so has the reading since the transition, then you figure your local clock is fast and adjust it slightly accordingly. Providing the adjustment is small, you can retain lock in quite noisy environments - we were using a radio link. It looks a bit complicated but actually coded into quite a compact block of assembler. ('6805 in the case in point) Richard P -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist