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

Before I didn't understand. Now I CAN. Thanks

Best explanation of CAN bus I have every seen/heard. Wow. Just amazing Dave! Thanks!

My background and work are in electronics. It gives me great pleasure to see that a software developer like Dave understands electronics. When I was in school more than thirty years ago, I had to learn how a microprocessor worked. I wonder if the new generation of software developers knows how a microprocessor actually works.

Dave - I love the humour in your obviously carefully crafted monologues. You have a style and a way that makes bone-dry tech subjects not just accessible but entertaining too.

now THAT is one superb overview ! - Thanks Dave !

USAF electronics background here! Dave hit the nail on the head with this explanation and broke it down perfectly.If I could add one neat analogy to what he covered: CAN bus compatibility across different manufacturers is a lot like standard telephones. Everyone uses the same physical network hardware to connect, but different brands speak their own "language" over the line that other systems can't translate without an interpreter. Compared to modern high-speed Ethernet, legacy CAN bus is pretty slow, mostly because older cars didn't need to pass massive amounts of raw data. Bosch finalized the standard back in 1986 and probably had no idea how massive it would become! On something like a modern Ford F-250, you'll actually find multiple CAN buses running simultaneously at different speeds (125k, 500k, and 2Mbps) depending on what each module needs, which ends up requiring miles of physical wiring. Tesla recently tackled that wiring mass by moving toward an internal 1Gbps Ethernet ring architecture called "Etherloop" paired with 48V power distribution. It drastically cuts down on harness weight while boosting data speeds. And credit where it's due—while Tesla holds patents on their vehicle hardware designs, they offer their tech under an open patent pledge to encourage the rest of the auto industry to adopt common standards. Awesome video, Dave! Appreciate the detailed breakdown.

I have always wanted someone to explain CAN bus. Thank you!

I've been learning more about canbus lately as its becoming a go-to feature on 3dprinters. I've really been amazing by its durability and flexibility. I wasn't sure how much you could add to this, but man what a great video. Great stuff.

This is fun to me. I work with CanBus (J1708, J1939 mostly) almost every day, not an engineer and I don't have the foggiest idea of what's really going on. But I see the results of poorly configured devices, loose connections, failed resistors, and noisy networks regularly. This was a good one, very informative and easy to follow. Thanks again, Dave!

Thank you. Keep the automotive content coming in Dave's Garage 😊

I'm so glad they have a robust security layer built into the protocol. Hold on?!?!....

I love how you are almost poetic about stuff that would normally be cold and dry. It makes learning, or even just listening in, a subconscious learning adventure. Teachers like this are the ones that set geniuses on their paths to change the world, not by the knowledge, but the hunger to learn more, apply it and then challenge it to see where its limits are. The hardest part about teachers that teach like this: focussing them on anything for more than a chapter! lol

The simple elegance of CAN is impressive. Thanks for the equally elegant explanation.

The FIRST time I watched a video on CAN and actually understood it

Super explanation, I've never understood that priority was baked in!

Dave, thank you for going off of the beaten PC path and choosing this topic! It's near and dear to me, I've been more on the embedded side than the PC side. In my budding years I had to learn the CAN protocol for automotive applications and came to a similar degree of appreciation. The things you mentioned about medium access control via the dominant fascinated me, too. There's another hidden feature - CAN is differential, but also, self clocking! The 'bit stuffing' mechanism forces a change on the bus if more than 5 bits of the same state are transmitted. In conjunction with the 'synchronization jump width', this is a powerful method to resync the CAN transceivers. About that CAN data, though, there is a sunny side up if you are still in the trench. If you are access data via the OBD port, that is 'legislated OBD' and is compliant with J1979 (layer 7, the application layer). If you are on another internal CAN bus, it uses ISO-14229, aka Unified Diagnostic Services. Both, under the hood, use ISO 15765-4 and 15765-2 as data link, transport, and session layer protocols. Sounds complicated, right? Well, it's not. Essentially, a CAN frame is either singular or part of a packed message (segmented message, in 15765 speak). 15765 defines 4 types: Single Frame, First Frame, Consecutive Frame, and either Final Frame or Flow Control Frame. These are easy-ish to reverse engineer if you have the ISO docs, and a scope that unpacks the frames. For example, they all have 8 data bytes in the payload but the first byte does two things: the upper nibble is the type of message, and the lower nibble is the serial number (1 to 16) of the frame (useful for cases where one dropped frame won't cost the bus the whole message again, just request the dropped frame again). This is great you broke out of the PC box and did this for us embedded folks. Get another Corvette so you can try this again ;)

That engineer or engineering team at Bosch is genius.

I like commenting to give the algorithm engagement when I know that the creator’s intrinsic motivation is a passion about how cool things work. Go, Dave!

Amazing breakdown of CAN. I didn't realize how beautifully simple and brilliant that system is.

Mechanic here. Love the video. You wouldn't believe how handy it is to have an Aligent scope for automotive diagnosis