(Stupid/Newbie) Question on UART - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it

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
snipped-for-privacy@sdf.lonestar.org

Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: (Stupid/Newbie) Question on UART

Quoted text here. Click to load it
pretend I
more

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

Quoted text here. Click to load it

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

[...]
Quoted text here. Click to load it

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


Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: (Stupid/Newbie) Question on UART

Quoted text here. Click to load it
a

Yes, you did.

Quoted text here. Click to load it

Yep - until you start feeding PRBS test streams into the scrambler,
which can make your equipment look less reliable than it would be
against a real-world stream.

Quoted text here. Click to load it

I don't think there is an absolute minimum requirement, but a commonly
accepted number is 72 digits - so your memory is quite good.  Modern
CDR's tend to be able to handle even more digits than that, but as you
said, the probability starts getting so low that it is well beyond the
lifespan of just about anything (humans, electricty, copper wire, etc).
 Somewhere I got it that the V2Pro MGT can handle over 75 CID (to try
to insert at least one FPGA related item to this post).

As for long haul links, if you want protection, SONET is still the main
choice.  I think that RPR is trying to make in-roads, but has been slow
out of the gate and from what I've heard third hand, is slow to be
adopted by the carriers.  I believe a third alternative is protected
DWDM (not as intelligent as SONET or RPR, but that means maintenance is
considerably less expensive).  There may be others I can't recall at
the moment.

Have fun,

   Marc


Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it

I'm missing something.  Why is a PRBS test stream going to make errors?

To make a long string of 0s, you have to send something that
matches the pattern in the scrambler register.  That pattern
is supposed to be random - hard to guess and hard to hit by
sending malicious data.

Is there a trick or quirk I don't know about?

--
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
We've slightly trimmed the long signature. Click to see the full one.
Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it
errors?
Quoted text here. Click to load it

Howdy Hal,

   I did a poor job of editing your original response, and an even
poorer job of explaining mine - sorry!  I was actually trying to
provide an example in response to your "much lower would be a serious
problem" statement.  We've chased phantom bugs in our equipment before
where a weekend long test would take a data hit.  It was eventually
tracked down to a device that effectively had a very short run-length
tolerance.  It wasn't a CDR, but the result was the same.  We've also
had a (different) vendor tell us that we had to order the STS's within
our scrambled data stream in a certain way, or downstream devices may
lose CDR lock.

BTW, the 75 bit CID number for the V2Pro CDR can be found here:

http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath15%035
http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath15%049
http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath15%055

   Marc


Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it
the

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.

Quoted text here. Click to load it
noise

That's fine.

Alex



Re: (Stupid/Newbie) Question on UART
Alexei A. Frounze wrote about UARTs:
Quoted text here. Click to load it



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

Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it
Your
make it

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?

Quoted text here. Click to load it


No problem here.

Alex



Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it

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

Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it

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

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
We've slightly trimmed the long signature. Click to see the full one.
Re: (Stupid/Newbie) Question on UART
Quoted text here. Click to load it

You are correct, that it is technically possible to SEND at 1.842MHz,
and some modern UARTS have this option ( see Oxford semi ).
The problems are on RECEIVE, where historically a 16x sample rate
was chosen for the RX Clock. The 16x is not mandatory, but a trade off
between speed and clock drift/edge jitter tolerance.
Some devices have variable sample rates : /8 is often seen, and even /5,
and some uarts can output/input a clock, but by that stage they have
morphed away from the ASYNC approach.
Because the issue is one of phase of sample, not frequency per-se, with
devices like FPGAs that have Digital Delay lines, you could design a
UART with a RX clock == BAUD rate, and choose the delay line tap, on
each start bit.
-jg


Site Timeline