.... It does NOT go through the module!!! By any means!!! BS🧐. If a module is missing, the can bus still works!!!

@ragohy it depends on the network. And in automotive it 100 percent has in and out through the module. If a module is disconnected you 100 percent lose the ability to talk to modules beyond them.

@@ginamar6218... since there is no car "module" discussed in the video, instead a can bus transceiver and a controller and a mcu, which forms a "node" : can bus will work, if a node leaving the bus (as long as there are two working nodes left!! He showed the principals and not how some manufacturer might build it: i. e. two wires in and two wires out. OK??

That's not true, if you lose one module the other will work properly without any problems. It's a must have safety feature. You are saying that if one temperature sensor is faulty in a car or some other node then airbags will not open because our can bus is down now.

​@@ginamar6218 That would depend on the bus structure, but it seems highly unlikely IMO as ISO26262 has redundancy requirements that would make it absurd to have that as a failure mode

And this is another reason it is used in the automobile industry, more important systems like air bags, sensors etc will have priority over other things like seat warmers.

It was a big point he missed. Multiple devices can read the same message and process it. A device can have a list of messages it is listening for.

Thank you!

There is an open source project aimed at reverse engineering these databases. I'm in automotive professionally and everything is going CAN-FD with encrypted buses now. This video is about legacy CAN 2.0B. In legacy CAN you can still have encrypted buses however due to the low data rate it's generally not done except for certain CAN frames like unlocking to tune an engine.

Thank you for the comment. I have to wonder how strong the encryption is since it has to be low cost. For example when WIFI came out it had no encryption (dumb really). Then they added WEP. That was cracked in a couple weeks. Then they added WPA2 etc. Its the nature of CANBUS to be very cheap in production so I am betting the encrypted standard is hacked in no time. Especially since the commands cannot change without a full software rewrite!

@@dennisfahey2379 well WiFi encryption is at the transport layer. CAN 2.0 has no encryption at transport and is all done at the application layer so the encryption can be as strong as you like really. But many CAN 2.0 devices are designed around lower end processors that usually don't have the processing capabilities to run a full cipher suite so they often just don't. With CAN-FD's higher data rates, things are changing. CAN and CAN-FD have something called ISO-TP which, fundamentally, is just a protocol on top of CAN frames and still pushes the encryption logic up into the application layer. ISO-TP is where things are interesting. You can think of the russian doll analogy or html inside a tcp payload. Like these examples, ISO-TP is just multiple CAN frames that are reassembled to make a complete & larger message. ISO-TP doesn't change the max payload size (8 bytes with CAN 2.0) but allows multiple frames of 8 bytes to be assembled as a complete message so the encryption overhead starts to make sense. It's hard to justify on a CAN bus the overhead associated with encryption for just 8 bytes and so other lesser encryption or security protocols are used which would require a dedicated video/blog post on...

Torque Pro with BLUETOOTH OBDII

This would be amazing, I find most videos are very academic.

Thanks! Not yet!

That is called a *'balanced'* audio signal, in contrast to an *'unbalanced'* audio signal. As such, a single mono audio signal needs 3 wires. And a stereo signal (effectively 2 mono signals) uses 6 wires (or 5, as you can share the 'common/ground' if you use it in the same cable... though usually in the audio industry dedicated single stereo cables are very rarely used, if at all). *But do note that it will not reduce all types of noise!!* Audio is an *analog* signal, not a *digital* signal like CAN-bus. As such it can not eliminate all types of noise. Also note: 'XLR' is just a type of plug! It has absolutely nothing to do with the type of signal! Eg: you can just as well use a 'stereo jack' for a balanced mono signal (which is indeed also used in the industry for connections to an audio mixer for example, along side 3 pin XLR plugs) So, a far better comparison would be the lighting protocol 'DMX' (to keep it in the same 'entertainment industry' as audio). Which IS a digital signal and also uses a bus topology, just like CAN-bus (and also uses XLR style plugs). Though, it does use master-slave topology, unlike CAN-bus. In the DMX protocol the High and Low (or Plus and Minus) ARE used as a differential signal to eliminate noise. And just as with CAN-bus, with DMX you need proper *termination* or you WILL have reflections on the signal which WILL screw up your signal! (although many hobbiests will tell you it doesn't matter. But they often don't use long lengths of cable so they wouldn't notice it, as for short lengths the termination doesn't matter THAT much). Either way, this video emitted even to mention the 'termination' requirements. it is an EXTREMELY CRUCIAL and HIGHLY IMPORTANT fact! He should have mentioned that at least.

@@CookieTube thanks for the precision, I was effectively talking about balanced signals. I do know the difference between connectors and signal protocols, but choose the term "XLR" for accessibility and understanding. But hey! You have great informations there, many thanks.

@@NicleT Thanks. And no worries, in practice, at the work floor, we also use just the term 'XLR' to refer to an balanced audio cable... eg: _"Do ya have a XLR 2m?"_ or _"Do you have a 2m mic cable?"_. ... instead of _"Do you have a balanced audio signal cable of 2m, with 3 pin XLR plugs?"_ . And for DMX it's: _"Do you have a DMX cable 5 pin?"_ , instead of _"Do you have a DMX cable with 5 pin XLR plug?"_ . But on the internet, I see a lot of people confusing those things... hence my 'overlong' pet peeve explanation. hehehe...

CAN has a defined packet format whereas 422/485 does not beyond a start/stop but. There is no CRC, for example, in 422/485 unless the application adds it to its data, CAN it must be there. Another difference is CAN devices arbitrate for the bus (he doesn't cover it in this video) where as 422/485, there is no bus arbitration. This allows CAN endpoints to start communicating whenever they have data to send; first arbitration and getting on the bus where in 422/485, a device must generally wait and respond to a master's request.

Do you have any good resources for reading up on J1939?

@@tyrelllaszlo6024 sorry, all my data had to stay with the project when I left.