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.
We'll start with CAN which is an acronym for controller area network.
This is the name of the networking protocol which defines how two devices connected
together agree to talk to one another.
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.
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.
Taking this analogy slightly further, spoken languages also have local dialects.
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.
This is also possible with the CAN protocol.
2 devices can both be talking CAN but if they're not configured correctly, they still
won't be able to communicate.
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.
The 2nd part of the CAN bus term is the bus.
This refers to the physical wiring that connects our devices together.
So it would be correct to say that 2 devices are communicating via CAN
but are connected to one another via a bus.
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.
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.
The first of these is a reduction in overall wiring harness size.
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.
That wire would only carry one individual signal.
By using network communications however, we can now have multiple signals carried
on the same wire.
These signals, instead of being sent as analog voltage level, are now sent as digitial
data packets.
A good example of where this is helpful is a simple driver instrumentation dashboard.
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.
Plus power supply, power ground, signal ground, illumination level and any other
warning lights that we might want.
This harness quickly becomes quite large.
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.
This reduces cost, complexity and harness build time.
Related to this but slightly less obvious is the increased flexibility in our system.
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.
Once again, this is a big time and material saver.
When we're working with CAN in an automotive application, we're usually doing one of 2
very specific tasks.
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.
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.
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.
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.
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.
Often these tasks lead into one another.
We might decipher a piece of data within an OEM CAN bus in a factory vehicle and
program an aftermarket device to log this.
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.
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.
That was just one of the modules taken from our CAN bus communications course.
If you'd like to find out more about this course, click the link.
If you liked that video make sure you give it a thumbs up
and if you're not already a subscriber, make sure you're subscribed.
We release a new video every week.
And if you like free stuff, we've got a great deal for you.
Click the link in the description to claim your free spot to our next live lesson.