Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Simple Verilog RS232 Receiver - ETO Exclusive

Status
Not open for further replies.
I would expect the eye to diminish to 50%. RS232 is an NRZ formet, and so during a significant portion of the bit interval, you're actually sampling the surrounding data, and not the data you want. As frequencies go up, lines get longer, etc, more or the eye is the wrong data. That's why I am sure this is a bad idea. The more I look at the problem, the more I'm convinced that a small number of samples, or single one at the optimum interval is the best way to go. I would never implement a correction scheme on what the 'likely' outcome might be. Most of the systems I've seen don't even try to correct bits, despite advanced error detection and correction encoding being available. Most use CRC codes and re-transmission requests.
 
Last edited:
I would expect the eye to diminish to 50%. RS232 is an NRZ formet, and so during a significant portion of the bit interval, you're actually sampling the surrounding data, and not the data you want. As frequencies go up, lines get longer, etc, more or the eye is the wrong data. That's why I am sure this is a bad idea. The more I look at the problem, the more I'm convinced that a small number of samples, or single one at the optimum interval is the best way to go. I would never implement a correction scheme on what the 'likely' outcome might be. Most of the systems I've seen don't even try to correct bits, despite advanced error detection and correction encoding being available. Most use CRC codes and re-transmission requests.

A lot of what you are worrying about has to do with differences in frequency and synchronization. Of course none of the correction schemes even try to correct the data, there needs to be data to base the correction on. What I am proposing is effectively monitoring the line quality and using that information... information that is lost by the time it gets to the usual array of CRC and retrans request routines. The ones that do try have extensive embedded CRC and parity data that is known at both ends.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top