Bob Axtell wrote:
> Dave Tweed<pic@dtweed.com> wrote:
> > PicDude wrote:
> > > Okay, that seems like a surprisingly simple solution to this problem.
> > > I'm evaluating on paper for now, and can't see it working well with
> > > 4x the bit rate, but 5x seems to work well... so far. This is assuming
> > > minimal error for now, but I'll try factoring in a few percent error
> > > to see how 5x would handle it. What's nice is that the ISR processing
> > > for this is indeed very minimal, so a faster sample rate is fine.
> >
> > Like I said, the interval depends on the exact characteristics of the
> > data you're trying to decode.
> >
> > Actully, I misspoke. Suppose the data is high for 40% of the bit
> > interval for a zero, and 60% for a one. In that case, you'd need to
> > sample with a period that is less than -- with some margin -- 20% of
> > the bit interval in order to reliably resolve the difference.
> 
> I would drop the internal RC clock and use a ceramic resonator or
> crystal instead. Otherwise you will be driven to despair by timing
> errors,
> 
> I'd sample at least 4x per bit if possible then nudge the centerline
> slightly. Timer2 and PR2 will work, I've done it. With a good clock.

I think you missed the point of the scheme I'm outlining. It doesn't
require the sampling clock to be synchronized with the data at all.
The only requirement is that the sampling period be less than the time
intervals you're trying to resolve, with sufficient margin based on
things like CPU clock accuracy and sampling jitter.

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