I don't know how these systems receive data at such a high speed if common baud rates are so low. I know something is wrong with my understanding of it all. I am new to electrical engineering and I am trying to teach myself some basic ideas for my research project - with much frustration. I know that I need to have a system that can receive a pulse train at a minimum speed of 10MHz hopefully up to MHz.
I will then program it to process this data. The system that I currently have to receive the data is an Arduino certified product:. Programming in the Arduino language is not a problem, I already know how to do this. I just want to understand what I can do to receive this data stream. Do I need something faster than this?
Or will this suffice? I'm more interested in the theory than the device; it is more valuable for me to bolster my education than for me to solve my problem though it needs to be solved. With asynchronous , which is what serial as in UART and RS are, it's all down to how accurate a system's clock is. Both ends of the line have to agree on the same speed baud rate and any deviation from that causes transmission errors.
The more accurately the two ends can agree on their baud rates the faster you can transfer data. Note that on many systems Arduino included when you ask for one baud rate you actually get a slightly different baud rate. That's due to the way that the internal UART hardware works - it divides the system clock into finer and finer bits to get as close to the requested baud rate as possible.
Lower baud rates are easer to get close to, but higher ones are much harder. So it's "safer" to use a lower baud rate which gives more reliable communication to a greater variety of devices. The other kind of serial, synchronous , uses an extra wire for the transmitting or master end of the connection to send the clock to the receiving slave end. The receiver uses the incoming clock to know precisely when it should look at the data line to receive a bit of data. Speeds in the tens of megahertz are common.
Some synchronous systems such as Ethernet , instead of providing the clock as a discrete wire, encode the clock into the data stream. This keeps the number of wires to a minimum yet allows high speed data transfer. The down side is that this usually means the maximum speed you can run at is actually slightly lower since the effective size of the data being transmitted is increased.
The other answers have really good info in them, but I'd still like to expound a bit on the different types of serial protocols, and how they vary in speed. I'll also mention a few devices and show some comparisons. For synchronous vs asynchronous and what that means, see Majenko's really good answer. Your phrasing of "receive a pulse train at a minimum speed of 10MHz" is quite confusing to me. Perhaps this is because when I hear "pulse train" I think you mean you want to read pulse widths in order to obtain data, ie: like the PPM pulse train used in Radio Control communication signals.
Is what you mean simply that you want 10Mbps megabit per second transmission rates? I spent the last couple weeks working on my communication code. In my case, each packet contains 8 commands, plus error checking bytes and a couple other things, to control an RC vehicle.
Normal Arduino ex: Uno default speed is kbps; it can be increased to kbps. Some non-Arduino devices can do 1Mbps or 3. Arduino default speed is 4Mbps. Normal Arduinos can go up to 8Mbps; Galileo can do 25Mbps. This is what most people mean I think when they just use the word "serial" without specifying it further by saying "SPI," "I2C," etc. Whenever you see the term "baud" or "baudrate," this is the type of serial communication they are referring to too.
Normally, the "high-end" speed is considered bps, but I regularly use kbps on an Arduino. See Connor Wolf's answer here.
Arduino also includes a software serial library for this type of serial communication on any of the Arduino's pins, and I have used it up to kbps. I haven't yet tested it beyond that speed, but being software-based, I'd expect it to become unreliable much beyond that. Note that embedded boards and devices, microcontrollers, etc, can all do some type of serial communication, even if it's just slow bit-banged RS TTL-type or SPI-type serial.
You just need to look at your actual needs. Your needs, however may be different. Different serial communications protocols use different signal modulation methods to encode data; if you want to roll your own wire protocol, you'll want to learn about those. Back in the day, low-rate UART serial systems were mostly used with modems that had to transmit long distances over voice telephone circuits. The UARTs themselves could go faster, so if you were doing a local serial connection you could get up to kbps.
These UARTs were relatively cheap. More advanced encoding schemes plus more expensive hardware with a lower noise floor allowed connections about times faster -- 10mbps ethernet. Technology High Speed Serial. High Speed Serial. Boards and Kits. Contact Sales. Backplanes with Xilinx Transceivers. Optical Interconnects with Xilinx Transceivers. GTR Protocol Support. Wired Communications. Accelerating Productivity for High Performance Designs.
Training and Support. Featured Videos. All Videos. Default Default Title Date.
0コメント