Alexei A. Frounze wrote about UARTs:
I wrote:
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
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?
No problem here.
Alex
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.
-- 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
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
This is used already, and is called Bi-Phase or Manchester encoding, for the two phase variants of this Clock+Data Scheme.
-jg
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
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
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.
pretend I
more
Like if "it" can be equal to Ethernet? :-)
Just to make this this discussion complete, with 64B/65B and 64B/66B there are finally encoding schemes with efficiencies worth being proud of.
[...]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
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.
a
Yes, you did.
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.
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
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 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.
errors?
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:
Marc
There are no clock-recovery PLLs in USB. FS/LS is specifically designed to be implemented by a 4x DLL. One can implement 10BT without a PLL too.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.