Communication Protocols

From Idea Shop Wiki

This page will give the reader a fundamental foundation of different widely used digital communication protocols. There is are many difference with analog and digital signals, but fundamentally are the same. The introduction talks about both types through the analogy given so understanding they are the same in this context will be very helpful.


Transmitting information has been around longer than humankind can recall. Transmitting information can be done in an infinite number of ways. But with any kind of transmission of information, there are some fundamental building blocks. These building blocks can be seen in the diagram.


This is extremely basic and more systems can have more complex designs in the communication process. Furthermore, in the case of two Indian speaking humans communicating verbally, this diagram stands. When one individual wants to speak, the data needs to be converted. This way of conversion matters on two factors, the data median and the common language. The communication data must first be converted in the common language (Hindi) and then transmitted (verbally). The data median is air so this is why it must be verbally transmitted. Then the receiver must receive the data then decode it, then interpret what the data means. Now then data being transmitted verbally is in an analog pattern. This analog pattern is extremely complex and this is why large amounts of data can be transmitted human to human in just a single word. The picture below shows the pressure wave of a human saying a word. communication2.png

In digital, the signal is either on or off. Or in vocal communication, it is either the person is yelling at the top of their lungs, or they are not. The communication graph would look like this.


From all of these on and off states, a system can begin decoding the data. A common encoding and decoding protocol to use is the ASCII protocol. This protocol represents english letters as a 7 digit string of 1s and 0s. This can be the same as just writing a regular number but with binary, it must be as 1s(on) and 0s(off). These ones and zeros are called bits. The letter ‘B’ would be represented as 1000001. Once this concept is fully understood, learning any communication protocol will be much easier.


USART ( universal synchronous and asynchronous receiver):

A common way for this type of signal to be transmitted would involve a clock, some kind of pulse that would tell the receiver to write down the state of the signal (1 or 0). The picture below shows the type of connection between the microcontroller and another microcontroller, neglecting the slave signal. USART doesn’t need to be both microcontrollers, it can honestly be any device with this supported transmission type.


The TX stands for transmission (data that is being sent from the device), RX stands for receive (data being sent to the device), and a common clock. This clock is going to basically put both devices on the same talking speed (baud rate or equivalently bits per second). First, a start bit is sent, this will tell the receiver it is sending. The diagram below shows a data packet (or frame) below the receiver to know that data is being sent.


The next 8 bits will be the actual data, once all the data bits are sent, a parity bit and a stop bit will be sent. The parity bit is to tell if the data was corrupted or not. The stop bit is to tell when the signal is finished being sent. The parity and stop bit are both there to see if the data has been corrupted or not. This is just one variation of USART, USART can be customized in many different ways. For instance, the amount of data packets being sent in one packet can be changed from 5 to 9 bits. There can also be 2 stop bits to make sure that the whole frame was sent properly. Say one device wants to send “Hello” in ascii format; then, the controller would have to send individual letters in each packet: that sounds like it would take a long time; however, in actuality, the microcontrollers are doing this in insanes speeds. A common baud rate is 9600b/s (bits per second), so say the packet was the one in the picture. The amount of bits per packet is 11 and we have 5 letters to send which would be 5 packets. This would take 55 bits of data to send “Hello”. To send this, it would take 55b / 9600(b/s) = 5.7ms. Furthermore, these speeds can be increased even higher but this is dependent on the speeds of both devices. USART can also operate without a clock, this method works the same way but the signals must be both programmed at a set baud rate beforehand. The pro of this approach is that there is only a need of two wires, but the con is that the baud rates are a lot lower than with the clock. Using without the clock is also commonly called UART.

Examples with using UART with the arduino to arduino:

Serial Peripheral Interface (SPI):

One of the down sides of using USART is that you can only talk to one device at a time, with SPI all devices can be hooked on the same lines while one main device controls them all. This kind of communication involves a master and slaves. Where the master tells which slave to speak and gather data. But how does this work? The picture below represents the SS signal which basically tells the device when to listen and talk. All the other pins work the same a USART, just named differently. However, the data frames/packets can be used to send anything, there is no universal standard. The frame needs to be completely set up in software. There are libraries out there that have the most basic set up but everything is basically customizable. For instance, when using multiple devices on one SS line, a way of specifying which device to talk must be made. This is done by once enabling the SS line, the first 8 bits that are sent will be the address to specify which slave is being spoken to. The picture below shows that frame in action.

Example of using SPI between arduinos:

communication7.png communication8.png communication9.png communication10.png

Inter-Integrated Circuit (I2C):

I2C works similarly with SPI but it only uses two wires and both wires are pulled up to a voltage. I2C can work with extremely simple devices at low frequencies. Like EEPROM, ADC, microcontrollers, etc. The systems protocol is well defined, meaning there is a universal way for transmission. Because all devices are on the same bus, there must be a well defined way to contact each device. Everytime a device talks, it will be in a bit frame, as shown below. How the conversation goes is the master sends the address of the device it wants to talk to. Within that same frame, there will be a R/W bit. This bit will tell the device if it should be listening, or talking. The next frame will be, depending on the R/W bit: either the master or the addressed slave will send the next frame consisting of 7 bits of data. For each frame, the 8th bit is the acknowledgement bit. This is supposed to tell if the slave or master received the data by sending out a 1 on the last clock cycle. This is how I2C works, fairly simple but powerful. Furthermore, the only check is the acknowledgement bit and that is more for the transmitter to know if the data was sent.. Note that I2C has no data integrity, if the signal becomes corrupt, both ends wouldn’t know. Data checking would have to be done in the software side.

Example of using arduino with I2C:

100 communication12.png

Controlled Area Network (CAN bus):

CAN bus is one of the most robust and complex protocols that is used in a wide range of applications. CAN bus allows all communication to happen on only two lines. These two lines are called CAN high and CAN low. On both ends of the lines must be a 100 ohm termination resistor. This resistor basically takes out any unwanted static between the lines. Furthermore, CAN has a standard transmission process. All of the signals above must be grounded between devices, however, CAN does not. How each signal is sent is the voltage potential between each line gets put to 5V, this stands for 0, and >1V will be 1. The picture below shows this. Bit timing is done the same way as in UART, a baud rate must be set before transmission. Just like I2C, each device will get its own address. This address not only tells who gets to talk but who gets priority: now that there is no master. This selection occurs during the arbitration frame. This frame forces the devices that would like to talk to spit out their address. The address with the lowest numerical value will always win., hence, higher priority. There are four types of CAN frames: data frame, remote frame, error frame, and overload frame. Within a frame is this basic architecture, represented from the picture below. The green represents the identifier ID. This basically states the priority of this message and the address. The blue bit states if this frame is sending data (0) or requesting data (1). Simply stating if this is a data frame or a remote frame. If this is a remote frame then the red data bits will be filled with whatever node was requested. If this was a data frame then the data will be simply filled with whatever data was being sent. The yellow basically says how much data is to be sent. These yellow bits tell how many bytes of data is to be expected or sent, where each byte is 8 bits. For instance, if the yellow bits is 0011, then there will be three bytes of red data. The CRC field is the check field, to see if all the data was sent properly. If there are 6 consecutive same polarity bits in a row, this means an error has occurred and the next 8 bits will state information about that error and resend the transmission, if this fails 128 times, that transmission will be scrapped. The overflow frame occurs when an ECU is flooded with too much data and the buffer overflows. When this happens a overflow frame will be sent stating that the message wasn’t received properly and will need time to clear the buffer. This covers most of the basics of CAN but there's still much to be learned.

For more information on CAN: see this document: CAN example with arduino:

communication13.png communication14.png communication16.png