00:00 |
- Before we get into the technical details of CAN, we need to answer a question that gets asked a lot, which is what exactly is a CAN bus? CAN bus is actually two distinct terms that often get linked together but refer to different things.
|
00:15 |
We'll start with CAN which is an acronym for controller area network.
|
00:19 |
This is the name of the networking protocol which defines how two devices connected together agree to talk to one another.
|
00:27 |
You could think of it as a language, if 2 people are trying to talk to one another but one only speaks English and the other only speaks Japanese, they'll find communication quite difficult.
|
00:37 |
If we're installing 2 electronic devices in a vehicle, one of which communicates via CAN and the other via RS232 serial for example, they likewise won't be able to talk to one another.
|
00:47 |
Taking this analogy slightly further, spoken languages also have local dialects.
|
00:52 |
And although 2 people might speak the same language, if their local dialects are different enough, they still won't be able to effectively communicate with one another.
|
01:00 |
This is also possible with the CAN protocol.
|
01:03 |
2 devices can both be talking CAN but if they're not configured correctly, they still won't be able to communicate.
|
01:10 |
This is why we need to have a thorough understanding of the CAN protocol to ensure we can configure these devices to speak the same language and dialect.
|
01:18 |
The 2nd part of the CAN bus term is the bus.
|
01:22 |
This refers to the physical wiring that connects our devices together.
|
01:26 |
So it would be correct to say that 2 devices are communicating via CAN but are connected to one another via a bus.
|
01:34 |
In practice, we just say that our devices are on a CAN bus but it's important to have a good understanding of the term as later sections of the course, particularly where we discuss the bus wiring, will break the term apart again.
|
01:46 |
Another often asked question is why should I use a CAN bus? While the answer is that this is very application specific, there are a couple of advantages that are pretty universal.
|
01:57 |
The first of these is a reduction in overall wiring harness size.
|
02:01 |
Before the mid 1990s, network communication in vehicles was not common and every time a signal needed to get from one part of the vehicle to another, a new wire needed to be run.
|
02:12 |
That wire would only carry one individual signal.
|
02:16 |
By using network communications however, we can now have multiple signals carried on the same wire.
|
02:22 |
These signals, instead of being sent as analog voltage level, are now sent as digitial data packets.
|
02:29 |
A good example of where this is helpful is a simple driver instrumentation dashboard.
|
02:34 |
If we have traditional gauges for vehicle speed, engine RPM, water temperature, oil pressure, fuel level and boost, we need at least a single wire for each of these signals.
|
02:46 |
Plus power supply, power ground, signal ground, illumination level and any other warning lights that we might want.
|
02:53 |
This harness quickly becomes quite large.
|
02:55 |
If we use modern smart gauges or a display dash type and a CAN bus instead, we likely only need power supply, power ground and the 2 CAN communication wires.
|
03:07 |
This reduces cost, complexity and harness build time.
|
03:11 |
Related to this but slightly less obvious is the increased flexibility in our system.
|
03:16 |
If we have a light on our dashboard that's been representing an alternator charge failure but we now want to show an oil pressure failure, we can accomplish this by making a quick change in the software of our dashboard instead of having to physically run another wire and modify the existing wiring harness.
|
03:33 |
Once again, this is a big time and material saver.
|
03:37 |
When we're working with CAN in an automotive application, we're usually doing one of 2 very specific tasks.
|
03:43 |
Setting up CAN communications to allow multiple aftermarket electronic devices to talk to one another, or interfacing with an existing CAN bus trying to find a specific piece of data.
|
03:55 |
The key difference between these 2 tasks is that for the first, we'll likely have good documentation for how our various electronic devices communicate over CAN.
|
04:04 |
Bringing back our language analogy from earlier, we'll have a good understanding of these devices local dialects and we'll be able to program them all to understand one another.
|
04:14 |
When we're interfacing with an existing CAN bus, looking for a particular piece of data, we're unlikely to have any reliable documentation on how or even if that data is being transmitted.
|
04:24 |
This is more like trying to learn that CAN bus' particular dialect, we're unlikely to decipher every part of it but if we know what we're looking for, we can perform some experiments to learn how that piece of data is spoken in that particular dialect.
|
04:40 |
Often these tasks lead into one another.
|
04:43 |
We might decipher a piece of data within an OEM CAN bus in a factory vehicle and program an aftermarket device to log this.
|
04:50 |
Or we might remove a piece of OEM electronics that was transmitting required data for the vehicle and need to program a piece of aftermarket electronics to replace this data on the bus.
|
05:01 |
Now that we've got a very broad understanding of what CAN bus is and how we can use it, it's time to dive into the more technical details of the bus itself which is the physical implementation of the network.
|