The Can Communication Bus literally keeps you alive when you fly and drive. Now let me explain what I mean. You see, the world has become increasingly computerized to the point where self-driving cars and autopilot planes are now a reality. Now these complex electrical systems have hundreds of sensors and multiple processes and need a very reliable and robust way to communicate with each other. Now in situations like cars, trains, planes, hospitals and industrial robotics, this communication is critical and failure of this communication can be fatal to human lives. This look at the recent news about the 737 MAX-8 aircraft that has been crashing due to a faulty sensor in the nose of the plane. Now these crashes are not the fault of a faulty communication protocol which is the topic of this video, but rather because of a faulty sensor, but you can get an understanding of how important a communication protocol is between the sensors and the electronics. Now this is where the CAN bus communication protocol comes in. Just like SPI and ISQC which I've talked about before, the CAN bus is a electronics communication protocol that helps relay information between multiple electronics, may be sensors, processors etc. Now the CAN communication bus is unlimited with just automobiles, in fact a lot of industrial robotics and hospital robotics and electronics, use it where bulletproof communication is a key. In this video we're going to learn about how the CAN bus works, how it compares to alternatives such as SPI and ISQC, how the messages and CAN bus works and what makes it such a reliable and robust communication platform. Now the CAN bus stands for controller area network. Notice the word network, the word network actually gives us the first hint of how the CAN bus works, the CAN bus is actually a peer to peer network. Now you might have heard the term peer to peer network if you ever used torrent or you heard about torrents. In nutshell, a peer to peer service means that all the electronics or ECUs can transmit and receive information to all other electronics or ECUs within the network. All the electronics are connected in a web like network where the sender's message can take multiple different routes to get to the recipient, because it can take multiple different routes if one of these routes are cut off or if one of the electronics is damaged or the cables are damaged, the message can take another route to get to the destination. This is what makes it so reliable. Now diving a bit deeper into this network, we can see that each electronics or ECU in this network is actually quite smart device. Each of these electronics can either transmit or receive information. Therefore, when the message is sent within the network, each device will receive the message, it will relay the message and it will also decide if the message was relevant to it or if it wasn't relevant to it. That means should it ignore the message or should it take action based on the message that's being transmitted. This interconnected nature also allows us to add on other devices to a pre-existing network very easily. That means we can add additional sensors or additional electronics to a pre-existing network. Now all this sounds great, but you might be wondering what if two electronic devices decide to send information or a message at the very same time. Now this is where the priority ID system comes in. Well, you see each transmitted message carries with it a priority ID. That means how important is the message. If two messages clashed, that means they're transmitted at the same time, each recipient or each node in the peer-to-peer network will decide, okay, which of these messages have a higher priority tag. The one with the higher priority will be relayed, forward and the one with the lower priority will just be forgotten. For example, in a car, a fire alarm system sending a message will probably take higher priority than something like a faulty head-like message that is being sent across electronics. Moving on, now let's talk about what the actual message or the data transmitted by each electronics actually looks like. Now if you watch my iSquare-C or SPI lessons, then these messages will look very similar. And to start with the message packet, we have the start of frame that signals the message start point, followed by the can ID which contains the information on the priority of the message. This is followed by the RTR bit which allows the transmitting electronics to request for a reply back from the recipient. This is followed by the control and data bits, where the real data is transmitted, followed by a CRC bit that double checks that the message has been received properly without any miscommunication and finally the acknowledged bit just like iSquare-C make sure that the recipient has received all the information. Now as we end this video, let's quickly cover the different variations or layers of the can bus communication protocol. Firstly we have the high speed can bus communication protocol or the FD can bus. As the name suggests, this variation is great for high speed data transfer and is a future of can bus especially with increasingly automated technologies and IoT devices becoming more prevalent. This high speed can bus transmits information over two wires. Next we have the low speed can bus. Now this is the more traditional old school sort of can bus that has been around for multiple years. It too transmits information over two wires but as the name suggests it's a bit slower speed compared to your high speed or FD can bus. And lastly we have the single wire can bus which as the name suggests can transmit information with just one wire instead of two wires used by the other two variations. The one wire can bus is great for low priority electronics and that's it for this video lesson. Now you can watch my SPI and iSquare-C video lessons as well for a more holistic view on how data communication works between different electronics. Thanks for watching.