10
\$\begingroup\$

Suppose I'm transmitting data through FM where 0 is 2Hz and 1 is 4Hz. The transmitter is transmitting 2Hz when there is no input. If I fed the recieved binary to a UART port of a microcontroller, how would the microcontroller differentiate between no data and 0?

This becomes relevant when transmitting ASCII characters for instance. Suppose the following string:

01000110 01101111 01101111 01100010 01100001 01110010

Because I've added spaces, we could translate this to:

Foobar

But to a machine the string would look like this:

010001100110111101101111011000100110000101110010

How would you create those "spaces" so you don't get ASCII characters messed up when you're receiving binary?

\$\endgroup\$
3
  • 5
    \$\begingroup\$ Here is how UART solves it, link. Stop and start bits, since zou feed it to an UART port zou should transmit them too. \$\endgroup\$ Commented May 13, 2015 at 9:31
  • \$\begingroup\$ I'm afraid I don't quite understand your diagram. It appears that the "Start Bit" is simply zero, which reinstantiates my problem. For example how would it know the difference between 01111000 and 00111100 if the string was 000 01111000 000? \$\endgroup\$
    – Allenph
    Commented May 13, 2015 at 9:37
  • 2
    \$\begingroup\$ @Allenph, when you're not sending the bus is idle and it is kept in a logically high state. When you're starting the transmission of a package the first bit is always logically low. This is the start bit. Then follows eight data bits and then a stop bit which is logically high. The microprocessor knows when the next bit is arriving since it knows the bus speed that you have configured. Both the microprocessor and the unit transmitting to the microprocessor needs to be configured with the same transmission speed. \$\endgroup\$ Commented May 13, 2015 at 9:47

4 Answers 4

17
\$\begingroup\$

If you feed something to a UART port of a microprocessor you must follow the UART communication protocol if you want the microprocessor to understand what you are feeding it. You need to embed each ASCI character into a UART package that contains a start bit, a stop bit and possibly a parity bit, a lot more information is available on the UART Wikipedia page.

When you're not sending the bus is idle and it is kept in a logically high state. When you're starting the transmission of a package the first bit is always logically low. This is the start bit. Then follows eight data bits and then a stop bit which is logically high. The microprocessor knows when the next bit is arriving since it knows the bus speed that you have configured. Therefore, it is possible to transmit for example two zeroes next to each other. Both the microprocessor and the unit transmitting to the microprocessor needs to be configured with the same transmission speed, parity and number of stop bits.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ A key point is that the configured number of stop bits is a minimum, not a maximum. The async serial line's idle state is an extended stop bit. So if the radio must idle at 0, then the easy answer is to invert the UART output before driving the radio with it so that it idles at 0, and 1 is a start. Then invert the received data before handling it with a UART. \$\endgroup\$
    – RBerteig
    Commented May 13, 2015 at 20:51
6
\$\begingroup\$

There are a lot of techniques for this. You may want to look at Manchester coding or NRZ codes. Or 8b/10b coding, which maps every 8 data bits to a 10-bit sequence that allows for clock recovery, error correction, and special "comma" symbols that can be used to detect the start and end of a transmission.

\$\endgroup\$
5
\$\begingroup\$

All ASCII characters are 8bit wide, you can see that in an ASCII table. HEX values of ASCII characters does not go beyond FF (1111 1111)

UART cannot receive more than one data byte (8bits) at a time, also beside that 8bit data there are STOP and START bits, PARITY and a few more, which you can see at picture shown below and which together form UART communication packet.

enter image description here

So when you sending ASCII characters to UART, you're sending them one by one, and thats how string is made. You already know that string is just an array of characters.

\$\endgroup\$
1
  • 4
    \$\begingroup\$ ascii is 7 bit, not 8, however it is common to put it in a 8 bit bite to make alignment trivial. It also allows other character sets and utf8. \$\endgroup\$
    – hildred
    Commented May 13, 2015 at 13:50
0
\$\begingroup\$

The UART protocol, as Mattias explained, is a time-based asynchronous protocol. What defines the boundaries between the bits is the time taken from the beginning of the start bit. So the microcontroller will "sample" the bit (N+half)/baudrate seconds after the start bit begins. The half bit is just to sample in the middle of the bits so it can have half a bit difference in timing between receiver and transmitter (remember that differences are cumulative and the worst case happens in the last bit of each frame, which is usually, but not always, 8-bit wide, depending on configuration). The key to make it work is having the receiver and transceiver with baudrates as near as possible.

So, the microcontroller counts time between each bit to know where each bit is inside a frame. The next character will go into the next frame. When each frame ends, the microcontroller starts to listen to the next frame automatically, so when the next start bit comes it already knows it should start a new frame. That's how the characters are separated.

Additionally, I'll add that you don't actually need two frequencies to transmit to a UART-receiving microcontroller. You can use a single frequency as OOK instead of two frequencies as FSK. It has higher spectral efficiency and the circuits are much simpler, since you only need a carrier wave switcher as transmitter and a single frequency detector as receiver, pretty much like morse code. Remember to generally use carriers with frequencies that are much higher than the baudrate, otherwise the simpler circuits won't work properly.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.