-
Looking for HSC notes and resources? Check out our Notes & Resources page
Help :( (1 Viewer)
- Thread starter jannny
- Start date
Baud of studies (was: Help)
[Caution, I am a network engineer for AARNet, not a teacher. I've no idea what the textbook says. This is the reality.]
I so hate the term baud rate, I've no idea why a high school text book would teach it, since it immediately pulls in sophisticated communications concepts like signal encoding algorthms, DC bias and clocking. "Bits per second" is plenty adequate. Anyway, enough ranting.
The baud rate is the number of opportunities for signal transition per second. On a 300 baud link there are 300 equally-spread opportunities for the signal to change each second. The change can be 0 to 1, 1 to 0, or (and this is what "opportunity" implies) 0 to 0 or 1 to 1.
To illustrate the simplest case, let's send the ASCII character U, which has binary value 01010101. We'll use the RS-232 voltage encoding, +25V for 0 and -25V for 1. Running at 300 baud gives us an opportunity for a signal transition every 1/300th of a second. You can see that we'll send +25V for 0 for 1/300th of a second, then -25V for 1 for the next 1/300th of a second, then +25V for 0 for the next 1/300th of a second, and so on.
To illustrate the oddest case, let's send ASCII character Ctrl-@, which has binary value 00000000. You can see that we'll send +25V for 0 for 1/300th of a second, then +25V for 0 for the next 1/300th of a second, and so on. There will be no *actual* voltage transition from +25V during this 8/300 of a second, but we are still running at 300 baud.
If you know some electronics, you'll see that this encoding sucks. Firstly, we're holding down +25V for an awfully long time, a difficult thing to do when we want to signal the reciever, but not provide power to it. We would much prefer an encoding that averages out to 0V, no matter what the data pattern. Secondly, we are only getting one bit of data out of each baud, where we could be getting several (by looking at the rising and falling edges of the signal and their relationship to 0V). These two observations lead to a lot of encodings, with differing tradeoffs. Some average to 0V very quickly, but need multiple signal transitions to encode one bit. These might have 2400 baud but 1200 bits per second, as in aircraft avionics systems. Some average to 0V over a long period, but get 4 bits per signal transition. These might have 2400 baud but 9600 bits per second like 1990s telephone modems.
So there's no general relationship between baud and bits per second, you need to know the encoding. If the encoding is not given, assume it is 1 bit per baud like the RS-232 encoding.
Once we know bits per second (or "bps") do we know bytes per second (or "Bps")? No. If the link is asynchronous (ie, has no external clock signal) we might need a "start" bit to start the receiver's clock before the start of the byte (the clock is needed so we know when to measure the voltage). A protocol like asynchronous RS-232 has 1 to 2 "stop" bits to allow the reciever to use a simpler electronics. A protocol like RS-232 can optionally add a "parity" bit, to detect data corruption. So sending a 8-bit byte might use this many bits: 1 start bit, 8 data bits, 1 parity bit, 1 stop bit. Typical choices for asynchronous RS-232 are: 1 start, 8 data, no parity, 1 stop; 1 start, 7 data, 1 even parity, 1 stop; or for long links 1 start, 7 data, 1 even parity, 2 stop.
An old fashioned 9600bps asynchronous RS-232 terminal configured for 1 start, 8 data, 1 stop will only transfer 9600/(1+8+1) = 960 bytes per second. 9600bps was a popular speed as it gave a worst-case screen refresh time of 2 seconds for their 80x24 character screen.
RS-232 can also run in synchronous mode, with an external clock line. In this case, no start bits are needed. In this mode RS-232 can be truly exotic, with multiple terminals sharing the same link. Outside of satelite communications you won't see synchronous RS-232 these days.
So there we go. Baud, bits per second and bytes per second. Out of interest, how does this match with the textbook's description (I've been horrified by some of the texts I've seen).
I'd also love to know if this is required by the syllabus. Us working network engineers look at the "bits per second" rate and really don't give a stuff as to what the underlying encoding and baud rate is. Given that reality, I've no idea why a high school student should need to know anything deeper than "bits per second". But if it is in the syllabus then I hope the above helped.
[Caution, I am a network engineer for AARNet, not a teacher. I've no idea what the textbook says. This is the reality.]
I so hate the term baud rate, I've no idea why a high school text book would teach it, since it immediately pulls in sophisticated communications concepts like signal encoding algorthms, DC bias and clocking. "Bits per second" is plenty adequate. Anyway, enough ranting.
The baud rate is the number of opportunities for signal transition per second. On a 300 baud link there are 300 equally-spread opportunities for the signal to change each second. The change can be 0 to 1, 1 to 0, or (and this is what "opportunity" implies) 0 to 0 or 1 to 1.
To illustrate the simplest case, let's send the ASCII character U, which has binary value 01010101. We'll use the RS-232 voltage encoding, +25V for 0 and -25V for 1. Running at 300 baud gives us an opportunity for a signal transition every 1/300th of a second. You can see that we'll send +25V for 0 for 1/300th of a second, then -25V for 1 for the next 1/300th of a second, then +25V for 0 for the next 1/300th of a second, and so on.
To illustrate the oddest case, let's send ASCII character Ctrl-@, which has binary value 00000000. You can see that we'll send +25V for 0 for 1/300th of a second, then +25V for 0 for the next 1/300th of a second, and so on. There will be no *actual* voltage transition from +25V during this 8/300 of a second, but we are still running at 300 baud.
If you know some electronics, you'll see that this encoding sucks. Firstly, we're holding down +25V for an awfully long time, a difficult thing to do when we want to signal the reciever, but not provide power to it. We would much prefer an encoding that averages out to 0V, no matter what the data pattern. Secondly, we are only getting one bit of data out of each baud, where we could be getting several (by looking at the rising and falling edges of the signal and their relationship to 0V). These two observations lead to a lot of encodings, with differing tradeoffs. Some average to 0V very quickly, but need multiple signal transitions to encode one bit. These might have 2400 baud but 1200 bits per second, as in aircraft avionics systems. Some average to 0V over a long period, but get 4 bits per signal transition. These might have 2400 baud but 9600 bits per second like 1990s telephone modems.
So there's no general relationship between baud and bits per second, you need to know the encoding. If the encoding is not given, assume it is 1 bit per baud like the RS-232 encoding.
Once we know bits per second (or "bps") do we know bytes per second (or "Bps")? No. If the link is asynchronous (ie, has no external clock signal) we might need a "start" bit to start the receiver's clock before the start of the byte (the clock is needed so we know when to measure the voltage). A protocol like asynchronous RS-232 has 1 to 2 "stop" bits to allow the reciever to use a simpler electronics. A protocol like RS-232 can optionally add a "parity" bit, to detect data corruption. So sending a 8-bit byte might use this many bits: 1 start bit, 8 data bits, 1 parity bit, 1 stop bit. Typical choices for asynchronous RS-232 are: 1 start, 8 data, no parity, 1 stop; 1 start, 7 data, 1 even parity, 1 stop; or for long links 1 start, 7 data, 1 even parity, 2 stop.
An old fashioned 9600bps asynchronous RS-232 terminal configured for 1 start, 8 data, 1 stop will only transfer 9600/(1+8+1) = 960 bytes per second. 9600bps was a popular speed as it gave a worst-case screen refresh time of 2 seconds for their 80x24 character screen.
RS-232 can also run in synchronous mode, with an external clock line. In this case, no start bits are needed. In this mode RS-232 can be truly exotic, with multiple terminals sharing the same link. Outside of satelite communications you won't see synchronous RS-232 these days.
So there we go. Baud, bits per second and bytes per second. Out of interest, how does this match with the textbook's description (I've been horrified by some of the texts I've seen).
I'd also love to know if this is required by the syllabus. Us working network engineers look at the "bits per second" rate and really don't give a stuff as to what the underlying encoding and baud rate is. Given that reality, I've no idea why a high school student should need to know anything deeper than "bits per second". But if it is in the syllabus then I hope the above helped.
Xenmae
New Member
more or less baud rate is the amount of electrical signals per second
Forbidden.
Banned
Moreover an engineering term defined as the rate of signal change per second acocrding to my Excel HSC IPT study guide.Xenmae said: