[time-nuts] Pictic II mods

[Chuck Harris]

Is accuracy of your data timing an operating goal?  If your communication
connection gets 100% reliable data transmission, at a speed that is
adequate to your needs, isn't that good enough?

I suppose you could use a C-Beam standard to drive your async timing clock,
and then use the ability to derive C-Beam accuracy from your async data
as some sort of goal.... but I think I will pass on that.

-Chuck Harris

Peter Putnam wrote:
> List Members,
>
> How casually the time-nuts treat data timing... on one hand, errors of
> parts in ten to the minus 12 are cause for great concern, and on the
> other hand, throw in an extra stop bit and hope for the best.
>
> Consider how a UART receives data from an asynchronous data transmitter.
>
> The beginning of a received START bit starts a clock running at 16 times
> the data rate. At 8 clock ticks, the middle of the start bit is
> established. The middle of the first data bit is sampled 16 clock ticks
> later, as are the succeeding bits. The center of an "on-speed" STOP bit
> occurs on the 144th tick. If the incoming stream is fast, such that the
> stop bit is ending at 144 ticks, or slow, such that the stop bit is just
> beginning at 144 ticks, timing errors can be expected. The maximum
> combined receiver and remote transmitter clock error can then be
> established as 144 +/- 8 or +/- 5%. Errors are not cumulative; each
> incoming byte restarts the process.
>
> The penalty for this tolerance of clock errors is the overhead involved;
> ten bits are transmitted for each 8-bit byte.
>
> Peter Putnam
>
>
>
>
> On 7/2/2010 10:01 PM, Chuck Harris wrote:
>> Hi,
>>
>> I only worry about the UART working with other UARTS. And at the 1% spec,
>> the PIC UARTs , in my experience, always do....
>> If you are concerned, use 2 stop bits.
>>
>> -Chuck Harris