(Stupid/Newbie) Question on UART

Alexei A. Frounze wrote about UARTs:
> The oversampling not only makes it possible to determine the position of the
> start bit, but also it combats the noise and errors. The 16 consecutive
> sampled values (each being 0 or 1) are used to decide on the actual bit
> value. If most of these 16 samples are 1, it's 1. Otherwise, it's 0.

I wrote:
> I've never seen a UART that behaves that way.  Such a UART would be
> very unreliable, because if the sender was slightly slow or fast relative
> to the receiver, the 1 bits would get smeared into adjacent bits.

"Alexei A. Frounze" <alexfru@chat.ru> writes:
> I don't see where it's unreliable. The majority tells the final value. Your
> "slightly", which is about 1/16th of the bit duration isn't going to make it
> unreliable so badly.

Sorry, I misread your statement.  Majority voting all 16 samples would
probably be OK, though it would be a little less reliable than majority
sampling only near the center of the bit time.

It's still the case that I've never heard of a UART using more than
three samples near the center of the bit time, and most only use one.

Eric

"Eric Smith" <eric@brouhaha.com> wrote in message
news:qhoedmj5se.fsf@ruckus.brouhaha.com...
> "Alexei A. Frounze" <alexfru@chat.ru> writes:
> > I don't see where it's unreliable. The majority tells the final value.
Your
> > "slightly", which is about 1/16th of the bit duration isn't going to
make it
> > unreliable so badly.
>
> Sorry, I misread your statement.  Majority voting all 16 samples would
> probably be OK, though it would be a little less reliable than majority
> sampling only near the center of the bit time.

If the noise happens to invert two of the middle samples... I think better
would be to have more than 3 and less than 16 to drop the boundary effects
and count on more samples. 8?

> It's still the case that I've never heard of a UART using more than
> three samples near the center of the bit time, and most only use one.


No problem here.

Alex

Alexei A. Frounze wrote:
> "Eric Smith" <eric@brouhaha.com> wrote in message
> news:qhoedmj5se.fsf@ruckus.brouhaha.com...
>> "Alexei A. Frounze" <alexfru@chat.ru> writes:
>>> I don't see where it's unreliable. The majority tells the final
>>> value. Your "slightly", which is about 1/16th of the bit duration
>>> isn't going to make it unreliable so badly.
>>
>> Sorry, I misread your statement.  Majority voting all 16 samples
>> would probably be OK, though it would be a little less reliable than
>> majority sampling only near the center of the bit time.
>
> If the noise happens to invert two of the middle samples... I think
> better would be to have more than 3 and less than 16 to drop the
> boundary effects and count on more samples. 8?

If you are going to be "smart" about it, you would be better
off trying to detect the edges of bits so that you can resynchronize
on each edge.

What happens if you have 13 bits of noise and the real data in the middle
part?

Is the UART data defined as the majority of the bits or the
value of the data at the sample point?
I think if your majority voter is wrong, then you have a severe problem
that needs to fixed elsewhere.


>
>> It's still the case that I've never heard of a UART using more than
>> three samples near the center of the bit time, and most only use one.
>
>
> No problem here.
>
> Alex

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

> Sorry, I misread your statement.  Majority voting all 16 samples would
> probably be OK

Will be a bad idea if the sampling rate (receiver baud rate) is a bit wrong.

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Andrew Smallshaw wrote:
> On a slightly different note, does anyone know why most serial protocols
> use simple voltage levels to denote a logic 0 or 1?  I admit I'm no expert
> but I recall from my A-level electronics an edge-triggered system where a
> '0' would be (say) low-followed-by-high whereas a '1' would be
> high-followed-by-low.  Yes, this means _at_least_ twice as many voltage 
> transitions per bit but I would have thought that given its greater resilience
> mismatched clocks or any stray capacitance it would be worth the trade off.

  This is used already, and is called Bi-Phase or Manchester encoding, 
for the two phase variants of this Clock+Data Scheme.
-jg

"Alexei A. Frounze" <alexfru@chat.ru> writes:
> If the noise happens to invert two of the middle samples... I think better
> would be to have more than 3 and less than 16 to drop the boundary effects
> and count on more samples. 8?

If your line is that noisy, you're unlikely to have good results no matter
how the sampling is done.  I've never seen a serial line have that much
trouble, except on a 150m run from a factory floor to a computer room
three floors above.  On that, the main problem was a difference in ground
potential, and the cure was to switch to a balanced EIA-422 line with
electrical isolation at one end (cheaper than going to fiber, which would
also have worked).

Eric

In article <423699e0$1@clear.net.nz>, Jim Granville wrote:
> Andrew Smallshaw wrote:
>> On a slightly different note, does anyone know why most serial protocols
>> use simple voltage levels to denote a logic 0 or 1?  I admit I'm no expert
>> but I recall from my A-level electronics an edge-triggered system where a
>> '0' would be (say) low-followed-by-high whereas a '1' would be
>> high-followed-by-low.  Yes, this means _at_least_ twice as many voltage 
>> transitions per bit but I would have thought that given its greater resilience
>> mismatched clocks or any stray capacitance it would be worth the trade off.
> 
>   This is used already, and is called Bi-Phase or Manchester encoding, 
> for the two phase variants of this Clock+Data Scheme.
> -jg

Thanks for that but I already knew it existed: I wasn't trying to pretend I
had invented something.  But my original question was why isn't it more 
widely used?  

Hmmm... Manchester encoding.  Is that another great thing my old University
came up with?  The battery on this laptop is about to expire so I've not got
time for a Google search now...

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

>Thanks for that but I already knew it existed: I wasn't trying to pretend I
>had invented something.  But my original question was why isn't it more 
>widely used?  

It is widely used - at least if you are generous on what "it" is.

There are two conflicting properties you want when transmitting data
over a link.  You need transitions in the data stream so the receiver
can do clock recovery.  But useless transitions reduce link bandwidth
efficiency.

Another goal is to make the data stream ballanced so you can run
it through a capicator or transformer.

Manchester is very easy to implement with good DC ballancing but
only 50% efficient.  4B/5B (FDDI) is 80% efficient but not quite
ballanced in some cases.  8B/10B is ballanced but more complicated
to implement.

Typical async RS-232 is 80% efficient and easy to implement as
long as the signal is clean (aka distance is short relative to
the bit rate).

If you have long links, the fiber/cable is the expensive part and
you are willing to work harder (pay more) on clock recovery to get
more bits through the pipe.  On the other hand, for something like
Ethernet or RS-232 with short links, you are generally willing to
trade link bandwidth (or distance) for simpler decoding procedures.

For an alternative approach, google for scrambling as used on SONET.
The general idea is to start with a good clock recovery circuit (say
50 bits without any transitions) and then randomize the data stream
by XORing it with a random pattern so you still have transitions if
the user sends all 0s or whatever the nasty pattern is.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
> >Thanks for that but I already knew it existed: I wasn't trying to
pretend I
> >had invented something.  But my original question was why isn't it
more
> >widely used?
>
> It is widely used - at least if you are generous on what "it" is.

Like if "it" can be equal to Ethernet? :-)

> Manchester is very easy to implement with good DC ballancing but
> only 50% efficient.  4B/5B (FDDI) is 80% efficient but not quite
> ballanced in some cases.  8B/10B is ballanced but more complicated
> to implement.

Just to make this this discussion complete, with 64B/65B and 64B/66B
there are finally encoding schemes with efficiencies worth being proud
of.

[...]
> For an alternative approach, google for scrambling as used on SONET.
> The general idea is to start with a good clock recovery circuit (say
> 50 bits without any transitions) and then randomize the data stream
> by XORing it with a random pattern so you still have transitions if
> the user sends all 0s or whatever the nasty pattern is.

A CID (consecutive identical digits) of 50 bits will cover most
real-world cases of scrambled SONET traffic, but I'd personally want a
CDR with noticably more staying power than that.

Have fun,

   Marc

>A CID (consecutive identical digits) of 50 bits will cover most
>real-world cases of scrambled SONET traffic, but I'd personally want a
>CDR with noticably more staying power than that.

2**50 is 10**15  With a gigabit/sec link, that would be a glitch
every 10**6 seconds or roughtly 10 days.  Note that we are talking
clock-slip which is much worse than a simple bit error.
Adjust for your link speed.

I typed in 50 without much thinking.  Looks like I got in the right
ballpark.  Much lower than that would be a serious problem.  Much
higher would be hard to measure.

I think I remember 70 from years ago on OC-3.  That would be
another factor of 10**6 which would push the problem well
beyond the lifetime of any gear I've ever worked with.

What are current specs/reality for SONET links?  Are there any
interesting alternatives to SONET for long links?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.