Speed of digital communication

Discussion in 'Wireless & RF Design' started by Yakima, Feb 16, 2015.

  1. Yakima

    Thread Starter Member

    Jan 23, 2012
    35
    2
    I just began designing a circuit for digital serial communication using two 18k452 PIC micro-controllers, using bits RB0 for receive and RB1 for send. The information is in one byte packets but with a start bit and a parity check bit and so one baud(?) of information is 10 bits long with two of the bits being throwaways as far as any transmitted or received data is concerned.

    My master clock is 4 MHz and the instruction clock is 1 MHz, and therefore one microsecond long. I am emulating what I know about RS232 protocol and thus using the first bit sent as the start bit and the 10th bit sent as the parity bit.

    When I began to think out the rate of data transmission I saw a problem I had not really been aware of before. I realized that I was converting my micro-controller's instruction clock of 1 MHz to a desired baud rate of 9600 baud per second, or 96,000 bits per second. This confused me. The instruction clock is counting such that the rising edge of each pulse is one microsecond removed from the next pulse, but my data stream is running at 96,000 bits per second and there are no highs and lows between the data stream. So how do I calculate the delay between each sample of the state of of RB0 such that I sample it in the middle of a particular pulse after the start bit has been sent?

    I have more to say on this and I have taken a different approach to the problem, but I'll save that for when I have received some intelligent replies. Also, this will be a radio in the future. There will be no modulation, just a carrier switched on and off like Marconi or Morse. On is 1 and off is 0. I realize that Morse Code also involves the duration of a pulse -- long is dash, short is dot. But with digital information I don't see how this is necessary when on can be one and off zero and the data stream is periodic and so is sampled at regular intervals. Start bit = zero is "end of transmission," and while each baud has its start bit equal to one we just continue the algorithm of receiving data.
     
    Last edited: Feb 16, 2015
  2. MrChips

    Moderator

    Oct 2, 2009
    12,415
    3,354
    How did you get from 9600 baud to 96,000 bits per second?
    9600 baud is 9600 bits per second. Hence one bit is 104μs wide.

    When receiving UART serial data, you trigger a timer from the leading edge of the serial input and sample 52μs later to get the START bit. Then you sample every 104μs to recover the remaining bits.

    If you are planning on RF communications I would seriously consider using phase encoding:

    http://en.wikipedia.org/wiki/Manchester_code
     
  3. Yakima

    Thread Starter Member

    Jan 23, 2012
    35
    2
    Thank you for replying, MrChips. Maybe you can clear up some things I am in doubt about. As I understand it, a baud rate of 9600 per second, means 9600 packets of information per second. In serial communication, and with a byte being that information (8 bits), then counting the start bit and the parity bit, that means 10 pulses makes for 1 baud of information. The start bit is thrown away, so too, the parity bit, most times. I realize I may be wrong about this. Inform me, please.

    Ok, how do you get 52 microseconds and 104 microseconds? It's funny, but I have considered the problem from first principals. I determined that even 100 microseconds of pulse duration with respect to the information respecting ones and zeros is too small given the micro controller's need to execute instructions.

    I have considered phase encoding, but it seems to me it is slow.
     
    Last edited: Feb 16, 2015
  4. MrChips

    Moderator

    Oct 2, 2009
    12,415
    3,354
    You are half correct. Baud is not the same as bits per second.
    In this context, that is, UART signalling, baud and bits per second happen to be the same.

    Phase encoding is too slow compared to what?
    I send 100,000 bits per second PE on a 1MHz PIC.
     
  5. WBahn

    Moderator

    Mar 31, 2012
    17,715
    4,788
    The baud rate refers to the number of symbols per second. In fact, 1 baud = 1 symbol/second. It is related to the transmission protocol and not the data being transmitted.

    In the case of RS-232 with 8-bit data, 1-bit parity, 1 start bit and 1 stop bit, your packet consists of 11 symbols in order to convey 8 bits of information.

    So a baud rate of 9600 baud is a data rate of

    <br />
\text{data rate \; = \; 9600 baud \cdot \frac{1 \frac{symbol}{sec}}{1 baud} \cdot \frac{8 bits}{11 symbols}} \; = \; 6981.2 \frac{bits}{sec}<br />

    Note that this is the max data rate and is only achievable if your packets are transmitted back-to-back without any gap between them at all.

    When you receive a packet, the ideal way to do it is to detect the start of the start bit and then wait one half of a symbol period in order to start sampling the symbols. After that, you same them at 1 symbol period per sample. A better way is to sample each symbol two or three times in order to increase the chance of detecting transmission errors.

    A symbol period is just the reciprocal of the baud rate, or 1/(9600 symbols/sec) = 104.2μs/symbol.
     
  6. Yakima

    Thread Starter Member

    Jan 23, 2012
    35
    2
    To be honest, I have always been confused about the definition of "baud rate." And I've heard it wasn't defined as bytes per second. I read that it was about a "packet" of information, so I assumed it was defined by the way the programmers defined a single issue of information according to RS232 protocol which offers the programmer a choice as to the number of bits per "packet" of information. In other words, you might choose 8 bits or 7 bits of data, but you have to have a start bit, and yet you don't really need a stop bit. You may or may not want a parity bit as a check for transmission error, and so on. And so packets of information vary as per the choice of the programmers. I chose a packet of ten bits -- 8 bits of information, one start bit, plus a parity bit. This led me to the idea that 9600 baud, with each baud being composed of 10 bits (in my case) would be 96000 bits per second.

    There was the complication of the micro-controller clock being non-continuous, in that it has a square wave pattern -- up/down, up/down -- but the signal I'm creating is continuous: there are no "down" breaks in it. I drew the relationship on a piece of paper and realized I could just define my artificially made serial pattern (with no down breaks) as something like 100 microseconds. I could then wait for a start bit, count to 50 milliseconds and then sample every 100 microseconds after that. This is more easily seen after having drawn a diagram.

    At any rate, I needed to sample 10 bits with a 100 microsecond clock and this threw me. At 1 microsecond per microprocessor clock rate (up and down), I could only sample 10 bits and this left no time for the chores the program had to pursue -- such as looking for the start bit, deciding if a sampled bit was one or zero, and so on -- all of which took time. But now I realize I need to use the micro-controller's timer, which works independently of the program, and so I'm eating humble pie.

    I'm sorry if I'm bothering you. I am absent-minded and yet I used to know this. My deductions about how to get it done were intuitive. And yet, where am I wrong? How is it 9600 baud does not translate into 96000 bits per second, given my reasoning above is incorrect?
     
  7. Yakima

    Thread Starter Member

    Jan 23, 2012
    35
    2
    I see no need for a STOP bit. Given I am writing the code to interpret the information there is no use for a STOP bit. And, if I'm right about this (I'll let you know when it happens) then there are only 10 symbols used to convey 8 bits of information.

    This confuses me. First, I don't follow your math. 8/11 * x is smaller, not larger.

    Well that's what I'm proposing, WBahn. But when you say this is the maximum data rate, are you not presupposing a 1Mhz clock? Forgive me my ignorant questions. I am brand spanking new to this. In fact my post of yesterday was really a matter of guesswork and a hope for help. I appreciate your response here. I'm still learning and I will be learning until I die.

    I realized this after I drew a diagram yesterday. Sampling twice was out of the question yesterday. But now I realize I need to use the timer, not a polling loop, and so taking multiple samples is a good idea.

    Okay. Thanks.
     
  8. WBahn

    Moderator

    Mar 31, 2012
    17,715
    4,788
    You're free to do whatever you want, but when you are unable to tell when your next packet of data starts, don't come whining here.

    Yeah... Last time I checked, 6891.2 was smaller than 9600. But then I'm using old-school math.

    No, I'm presupposing the 9600 baud that YOU stipulated.
     
Loading...