CANBUS – Networking so simple, even YOU can understand it!

[00:00:01]Hey, I'm Dave. Welcome to my shop.

[00:00:03]Today, we're going to look at a networking standard so simple that by the end of this episode, you will actually understand how it works. Not just the highle idea, but right down to the electrical signals on the wire.

[00:00:14]We're going to build it on the bench live with breadboards, watch the bits fight for control on an oscilloscope, and then network it live to the engine computer from my old Corvette Z06. Now, if you spent any real time around networking, you already know the OSI 7 layer model. applications at the top, physical signaling at the bottom, and several increasingly mysterious layers in between where packets get wrapped, addressed, routed, checked, and generally escorted through the system like a minor head of state. Most of us get comfortable somewhere around the transport and the network layers. So, ports, IP addresses, routing, DNS, that stuff eventually makes sense. But once you drop into the data link and physical layers, the explanations usually turn into handwaving. The network card converts the frame into electrical signals and puts them onto the wire.

[00:00:59]True and about as useful saying that an engine converts gasoline into forward motion. Modern Ethernet works so well that most of us never need to learn the ugly details. We plug a cable into a switch, the little lights begin blinking, and gigabits of data obediently race around the building. The collisions are gone, the signaling is hidden inside silicon somewhere, and the disagreeable physics have been buried under several decades of increasingly clever engineering. Just look at this early 1980s Ethernet adapter. This is two full sixtab interl boards for my PDP11 devoted largely to accomplishing the physical Ethernet signaling. You might think of Ethernet as just a cute little chipset these days, but that hides a lot of electronics under the covers. And so any notions you had about wiring up Ethernet on a breadboard with a couple of transistors and a 555 timer should probably be abandoned about now.

[00:01:46]Ethernet began with some fellows in the 1970s drilling taps into thick yellow coaxial cable, attaching entire computers to the same shared wire and hoping that everybody followed the same rules. It worked, but the path from that yellow cable to the tiny twisted pair in your wall today is long, technically fascinating, and completely unreasonable as an introductory explanation. I could therefore give you one of two explanations of Ethernet electrical signaling. I could give you the short explanation, which would be useless, or I could give you the complete explanation, which would be uselessly long. So instead, we're going to begin with a network that solves many of the same fundamental problems using dramatically less machinery. It has no switches, no routers, no MAC learning tables, and no central controller deciding who may speak. It's just a collection of computers connected to the same two wires, all listening to one another, all capable of transmitting and all somehow able to resolve the problem when several of them decide to speak at exactly the same time. And that network is known as CANBUS. And CANbus is both incredibly powerful and almost suspiciously simple. It's the kind of network that you might invent for a custom LAN party using old speaker wires where you know there will only ever be a couple of dozen machines. None of them is ever trying to contact a server in Singapore. And the most important design goal is that everybody can communicate reliably without dragging a Cisco certification into the room. That is approximately the problem that can was designed to solve. Now CAN stands for controller area network. Bosch developed it for communication among electronic controllers in vehicles, publicly introduced the protocol in 1986 and it was later standardized internationally.

[00:03:18]It subsequently spread well beyond cars into factories, forklifts, agricultural machinery, elevators, medical systems and all manner of industrial equipment.

[00:03:27]You experience CAN almost every time you climb into a modern car. The engine controller is on the CAN network. The transmission controller is on the network. So were the brakes, the airbags, the steering system, the climate control, and often several dozen other computers that you didn't know that you owned. And sitting directly in front of you is the most visible member of that network, the dashboard. The dashboard is not necessarily the master controller because CAN does not require one, but it is effectively your view into the entire operation, the task manager of your car, if you will. Engine speed, vehicle speed, cool and temperature, oil pressure, transmission state, warning lamps, traction control activity, and dozens of other values arrive there as network messages. And just like Task Manager, when your car is acting weird, the dashboard is the first place you check. What looks like a collection of gauges is really a display terminal listening to an ongoing conversation among many computers distributed throughout the car. There's an engine controller and sometimes a separate transmission controller.

[00:04:23]There's a controller for your radiator fans, your HVAC system, your power seat, your power windows, and everything else in the car that is driven by an electronics module. And for today's demo, I have built a simple example of that conversation right here on the bench. I have two ESP32 microcontrollers, each connected through a CAN transceiver, and sitting between them is an engine control module from a 2015 Corvette. I have the ECM powered up and bootstrapped and running outside the car on the bench, which means that this little box believes with varying degrees of optimism that the rest of the Corvette must be nearby. But it is not.

[00:04:56]The transmission is missing. The body control module is missing. The dashboard is missing. Most conspicuously, the car itself is missing. In fact, I sold the car years ago, but I still had a backup computer on hand from my car hacking adventures with it. So, it felt a lot safer than wiring my circuit live right into my daily driver. But the ECM is awake. Its CAN transceiver is active.

[00:05:16]And on these two wires, it is saying whatever a Corvette engine computer says when it wakes up alone on a workbench and discovers that everybody else has gone home without it. The ESP32 itself contains a CAN compatible controller that Expressive calls TWWAI or two-wire automotive interface. The ESP32 handles framing, arbitration, retransmission, filtering, and air management. But it still needs an external transceiver to convert its internal logic level transmit and receive signals into differential electrical signals that are used on the bus. At the physical level, we're going to begin with just two wires. These wires are normally twisted together to reduce noise, and they're called CAN high and CAN low. They're often white in cars, but on the bench, it's the purple and blue wires that I happen to grab. The signal is differential, which means the receiver does not primarily care about the absolute voltage on either wire. It cares about the voltage difference between them. And that distinction matters because cars are electrically dreadful places. You have ignition coils, injectors, electric motors, alternators, relays, switching power supplies, and several meters of wiring distributed through a steel box that moves through rain, snow, heat, cold, vibration, and the occasional shopping cart. Unlike my bench, it is not a laboratory experiment. It is like an electrical knife fight inside of a rolling steel cage with cup holders.

[00:06:32]Remember how I said the signal on our two wires was differential? Well, here's where it matters. If interference pushes both CAN wires upward by half a volt, the receiver can largely ignore that because the difference between the two wires remains the same and noise common to both wires is thus rejected as well.

[00:06:48]The information lives in the distance between the signals. When high-speed CAN transmits what it calls a dominant bit, which represents logical zero, the transceiver drives CAN high upward and CAN low downward. that creates a significant differential voltage between the two conductors. So a big difference means zero. When it receives a recessive bit representing logical one, the receiver just releases the bus and both wires settle towards the same common mode voltage, leaving very little differential voltage between them.

[00:07:17]Typical high-speed CAN transceivers bias both lines near 2.5 volts while recessive and then separate them during a dominant bit. On the oscilloscope, it's wonderfully literal. One trace rises while the other one falls like a pair of tiny electronic scissors opening and closing. And if you turn on the math function and set it to be the delta between them, you can see the actual bits. And that momentary motion is why simply describing CAN high as the one that goes high and CAN low is the one that goes low is not quite enough.

[00:07:44]During a recessive bit, both are sitting in the middle. During a dominant bit, they separate. Now, the receiver looks at that separation, decides whether the bus is dominant or recessive. And every controller attached to those two same wires sees the same thing. And since the wire runs are short enough for all intents and purposes, they all see the same thing at the same time. The engine controller can hear the transmission controller. The transmission controller can hear and talk to the dashboard. The dashboard can hear the anti-lock brake controller. There's no Ethernet switch in the middle forwarding selected traffic to selected destinations. Every frame is broadcast onto the bus and every controller receives it. The individual controllers simply decide which messages matter to them. That gives us a remarkably compact network.

[00:08:27]Two wires, termination at each end, a collection of transceivers, and a room full of tiny computers sharing the same electrical conversation. The termination is important because without termination, sending a signal down a wire is a little bit like shouting down a long hallway. It creates a reflection when it hits the end of the wire, and that reflection messes up the clean edges of our signals. So, a typical high-speed CANbust uses 120 ohm resistor at each physical end of the cable. And since those two resistors appear in parallel when measured across the unpowered bus, a healthy, fully terminated network measures off on approximately 60 ohms from CAN high to CAN low. Now, my wires are completely unterminated, just two colored wires laying on the bench and everybody connected to them, and it works, but the run is only about a foot long. So, once you get up to several feet or more, you're going to need to terminate that bus. But now we have arrived at the fundamental problem lurking inside of every shared communication system. What happens when two computers begin talking at the same time? Because sooner or later they will. Perhaps the engine controller wants to announce the current RPM at precisely the same instant that the climate controller wants to report the cabin temperature. There is no central coordinator issuing numbered tickets. Both controllers see an idle bus. Both decide that now is a perfectly good time to transmit and both begin placing bits onto the same wires. You've probably heard of a network collision in Ethernet, then it's pretty much what you imagine. On the original shared versions of Ethernet, if two devices transmitted onto the same cable simultaneously, the combined signal became unusable garbage.

[00:09:54]Each transmitter or monitor the cable, detected that collision, stopped transmitting, and tried again later, and the waiting period was deliberately randomized. That detail matters because if both machines simply waited the same fixed amount of time, they would wake up together, transmit again together, collide again, and spend the afternoon politely headbutting one another. So by choosing a randomized delay, the odds were that one machine would resume first and claim the cable while the other was still waiting. If they happened to choose equivalent delays and collide it again, the process repeated with a wider range of possible waiting times until chance finally separated them. And that system worked, but it resolves contention by destroying both transmissions and starting over. It also introduces tiny but real weight states.

[00:10:36]CAN does something much simpler and I think much more elegant. Every CAN message begins with a unique identifier from 0 to 247 because in standard CAN that identifier is 11 bits wide.

[00:10:48]Extended CAN uses 29 bits. The identifier describes the message rather than permanently naming the device that sent it. So for example, engine speed might have one identifier. Coolant temperature might have another. Brake status might have a third. And those first two come from the engine controller module and the third from the brake controller, but each message has its own ID. Several different controllers could theoretically transmit the same identifier, though a properly designed system must ensure they do not transmit conflicting data under that identifier at the same time. The identifier tells you what the message means and just as importantly, how urgently it gets to access the bus. And here's the key part. The lower the numerical identifier, the higher the priority of the message. An urgent brake system frame can therefore outrank a routine climate control update without asking any permission from any centraluler. But how do two controllers transmit simultaneously without one stomping on the other? And this is the part of CAN that made me fall in love with it when I first understood how it worked. There is only one unusual electrical rule to remember. If anybody writes a zero, zero wins because it's pushing those lines apart, right? zero stops all over ones which are basically do nothing on the wire which would cause it to settle. So as long as somebody's running a zero, those lines will separate their voltages and everybody will see a zero. Can call zero the dominant state and one the lines together the recessive state. If I transmit zero while you transmit one, everybody sees zero on the bus. If you transmit a zero while I transmit one, everybody still sees zero. A recessive one appears only when every controller currently transmitting allows the bus to remain recessive. Each CAN controller also listens to the bus while it is talking. So when two controllers begin transmitting at the same instance, they both start by sending the identifier of their message, beginning with the most significant bit. As long as they send two identical bits, neither knows there's any competition, and everything continues along. They may both send zero, observe zero, and continue. Or they may both send one, observe one, and continue again. But because they have different IDs, eventually they reach the first bit where their identifiers differ. One controller transmits a dominant zero. The other transmits its recessive one. The bus becomes zero. The controller that sent the zero reads back zero sees exactly what it expected and continues transmitting. But the controller that sent a one reads back zero and immediately realizes that it has lost arbitration. Another message has a lower numerical identifier and therefore a higher priority. So it's time to shut up and be quiet. The losing controller stops transmitting, becomes a receiver, and waits for its next opportunity. And that's all there is to it. No frame was corrupted. No collision recovery was required. Nobody generated a random delay. The winning frame continues as though nothing unusual ever happened. And importantly, there is no retry. The original message makes it out unscathed the first time, the first attempt. And better yet, they all come out in perfect priority order. The CAN specification calls this non-destructive bitwise arbitration. A controller loses when it transmits recessive but observes dominance during the arbitration field at which point it withdraws without corrupting the winning frame. The reason this works is wonderfully compact. At the first differing bit, the identifier containing zero must be numerically smaller than the identifier containing one because the identifier is being transmitted from its most significant end. The electrical properties of the bus therefore perform a binary comparison among all competing identifiers in real time. The network does not merely discover which message is higher priority. The wires actually calculated and that is an important distinction. The device itself did not win. The message with the identifier 101. On the next transmission, the very same device could send a lower priority status frame and lose to another controller. Priority belongs to the message, not permanently to the machine or to the device. This gives CAN an elegant form of real-time scheduling.

[00:14:36]Important frames naturally move ahead of less important ones. And if the bus is lightly loaded, everybody speaks out almost immediately. As the bus becomes busy, lower priority frames experience more delay while higher priority frames remain responsive. And the cool part is that when the bus is busy, the message automatically comes through sorted in priority order just by virtue of when they are allowed to communicate. And that is extremely useful in a car where not all information is equally urgent.

[00:15:01]The fact that you press the volume up button does matter. The fact that a wheel has suddenly stopped rotating while the other three continue at highway speed probably matters more. But priority also introduces a danger. A defective or hostile controller that continuously transmits valid frames with a low ID can consume most of the bus bandwidth. Other controllers may remain electrically functional and perfectly willing to communicate yet rarely or never get the chance. Canon includes robust mechanisms for dealing with maleformed frames and electrically broken controllers, but a device transmitting valid, correctly formatted, high priority message is not necessarily violating the protocol. From CAN's perspective, it might simply have an endless supply of extremely important news. So Ken assumes a substantially more trusted environment than the public internet, which is okay because the participating devices are generally designed as components of one machine installed by its manufacturer and expected to cooperate, which is a perfectly reasonable assumption right up until somebody attaches an untrusted device to the diagnostic connector under the dash. Before we get to security, however, we need to look at what happens after arbitration. Once a message has one control of the bus, it sends its control information, data, air checking fields, acknowledgement, and end of frame markers. Classic CAN carries as many as eight, count them, eight databytes in one frame. Now, I get that eight bytes does not sound like much when your desktop computer routinely moves gigabytes around, but it's enough for the kind of compact measurements and commands that CAN was created to carry.

[00:16:27]After all, an engine speed message does not need a JPEG attachment. It may need two bytes for RPM, another bite containing flags, and perhaps a rolling counter and enough context established by the vehicle's private message definition to make sense of it.

[00:16:39]Importantly, CAN does not itself dictate what those eight bytes mean. That's up to the sender and any interested receivers. And it is one of the most important conceptual boundaries in the whole system. CAN defines how a frame gets onto the wire, how it wins arbitration, how receivers detect errors, and how the network corrects and contains faulty nodes. It does not tell you identifier 0x1 A0 contains engine speed in bytes three and four scale by one quarter of an RPM. That meeting belongs to a higher layer protocol or in many vehicles to a manufacturer's private database. And that is why attaching a CAN analyzer to a car immediately produces a beautiful stream of perfectly valid hexodimal messages with almost no useful information. You can see that the frame 0x1 A0 has arrived and you can see it's a datab.

[00:17:24]You can see that one bite changes as you press the accelerator perhaps. But CAN does not provide a tiny label saying by the way this bite represents throttle position multiplied by 392 and please ignore the upper two bits. You just have to know you have to know the language's alphabet and grammar but you don't yet have its dictionary. The ESP32 has a listenon mode that's especially useful here. A CAN controller normally participates in the protocol including acknowledging valid frames. In listenonly mode, our ESP32 can observe the network without influencing it, which is exactly what you want when first connecting test equipment to an unfamiliar vehicle network. Espresso explicitly provides this mode so the controller can receive traffic without affecting the bus. Acknowledgement is another clever little feature. After a transmitter sends a valid frame, it releases the bus during the acknowledgement slot. Any receiver that has correctly received the frame may drive that slot dominant. The transmitter does not learn which controller heard it. It simply learns that somebody got it. This is not an application level reply. The dashboard is not saying, "Yes, I have updated the tachometer." It's only a data link acknowledgement, meaning that at least one other CAN bus module out there saw your bits, got them, received them, decoded them, and they looked right. If nobody acknowledges the frame, though, the transmitter knows that it may be all alone, disconnected, configured for the wrong speed, or otherwise barking into the dark. CAN also checks its own work obsessively. Every frame carries a CRC.

[00:18:46]Transmitters monitor the bus while sending and receivers verify the frame structure as it arrives. It also uses bit stuffing to keep everybody synchronized. After five identical bits in a row, the transmitter inserts one bit of the opposite value. So, it flips the bit. Now, receivers know to discard that extra bit. But if the expected transition never appears, they know the frame is corrupt because the line should never be held that long. And when any controller detects an error, deliberately transmits an error flag that invalidates the frame for everybody. The message is discarded and retrieded. That sounds a bit dangerous because one broken controller could object to everything and hold the network hostage. CAN solves that with fault confinement. Every controller maintains air counters and repeated misbehavior progressively demoted from air active to air passive and finally bus off where it's effectively exiled from transmission. It's a tiny distributed society with arbitration, proofreading, public rejections, and eventually banishment all without a central authority. The wiring is equally approachable. On a dead CAN bus, you can begin with a meter and a scope. An unpowered, correctly terminated bus, as we said, should measure about 60 ohms across CAN high and CAN low. On the scope, the line should sit together when recessive, separate cleanly during dominant bits, and show minimal ringing or reflection. That does not make every fault easy. A loose connector in a vibrating, wet, freezing automobile can still produce a sort of intermittent failure that makes technicians question their career choices. But can let you reason all the way from the voltage on the wire to the message in the software.

[00:20:12]Which brings us back to the Corvette computer. The ECM or computer has no IP address and opens no connection to the dashboard. It simply has a connection to those two wires and broadcast messages with defined identifiers and payloads.

[00:20:25]Engine speed is published once and the dashboard, transmission, traction control system, diagnostic tool, and data logger may all consume that same frame. That loose coupling is one of CAN's greatest strengths. It's also one of its central security weaknesses.

[00:20:39]Traditional CAN does not authenticate the source of a frame. If a hostile controller knows the correct identifier in a payload format, it may impersonate a legitimate module. The other controllers see a valid identifier, a valid CRC, and a perfectly legal frame.

[00:20:53]Electrically and structurally, nothing is wrong. Now, this can also be handy.

[00:20:58]On my old BMW M3, a 2003 that used canvas, I added a feature where if you unlock the car three times in a row within 5 seconds with the key fob, it would see that and then it would inject the commands that I otherwise had recorded and seen to lower the top. So, I lowered the top manually a couple times, captured that data, figured out what I had to send to simulate a push the top down button, and I would do that when I saw three unlocks. And that's because CAN's designers were not careless. They were building a trusted physically enclosed network with 1980s processors and budgets. The danger appeared later when those closed networks gained diagnostic ports, wireless infotainment, cellular modems, aftermarket dongles, and millions of lines of externally reachable code. CAN is simple because it knows where its universe ends. Security problems begin when we quietly move that boundary. And yet, its limitations make it more impressive, not less. Because with two wires and a handful of rules, CAM provides noise rejection, deterministic priority, non-destructive arbitration, acknowledgements, retransmission, CRC checking, clock recovery, and fault confinement. Put two traces on a scope and you can see a dominant zero form right there. Trigger two controllers together and watch the lower identifier win at exactly the bit where they disagree. Remove a terminator and watch the reflections appear. Unplug the Corvette ECM and watch the entire family of identifiers just vanish from the bus.

[00:22:16]Nothing about it is magic. Now, can isn't simple because it does very little. It's simple because a few exceptionally well-chosen rules do a great deal. If you have comments or questions on today's episode, please leave them in the video comments. And then check out an episode of Shop Talk every Friday on the second channel where we answer the week's best questions and insights. If you found today's episode interesting or entertaining, remember I'm mostly in this for the subs and likes. So, I would be honored if you consider leaving me one of each before you go today. If you don't normally do that, I would appreciate it maybe on this episode because it's got this automotive tie in that is usually death for my channel, but I really wanted to do Canvas. So, if you did like it, give it a like. Thanks. And in the meantime, in between time, hope to see you next time right here in Dave's garage. Oh, I said it different today.

[00:23:01]>> Do it, Lynn. Do it. Do it.