Forum » CANBus Communications Decoded » What are CAN local dialects?

What are CAN local dialects?

CANBus Communications Decoded

Forum Posts

Courses

Blog

Tech Articles

Discussion and questions related to the course CAN Bus Communications Decoded

= Resolved threads

Page 1
Author
71 Views

Zac mentioned in 'What is CANbus?' module that CAN have different "local dialects". I'm curious to know the examples of those "dialects". I guess big endian and little endian is one of the "dialect". What about voltage levels? To my knowledge, OE applications use 3 classes of CANs: A, B and C with C being the fastest. And these 3 classes of CANs have different voltage levels when transmitting data. Are these different voltage levels one of the attributes considered as "dialects"?

"dialects" is not a common CANbus term.

Perhaps he was thinking of protocols that run on top of CAN bus messages (say OBD2 protocols where there is a query at one CAN ID / address, and another CAN ID / Address provides the response, or the OpenCAN or J1939 Protocols). You can learn more about those protocols from these wikipedia pages:

https://en.wikipedia.org/wiki/OBD-II_PIDs

https://en.wikipedia.org/wiki/CANopen

https://en.wikipedia.org/wiki/SAE_J1939

There are typically 4 speeds (baud rates) used with CANbus - motorsports is often 1Mbit/s, automotive high-speed is usually 500kbit/s, medium speed 250 kbit/s, and low speed 125 kbit/s. And I've recently seen references to a slower 62.5 kbit/s speed.

CAN is differential voltage bus, so generally relative voltages between the two signaling wires determine the 1/0 state of the bus.

David, can you elaborate what you meant by another protocol running on top of CAN message?

Where did your CAN A/B/C terminology come from? It sounds like you might be confusing that from the terms CAN 2.0A Vs 2.0B? The only real difference between these two is the length of the ID - 11bit Vs 29bit.

When you start talking about different voltage levels, that sounds more like you are referring to high speed CAN (ISO11898-2) Vs low speed or fault-tolerant CAN (ISO11898-3). The low speed CAN uses the same total voltage but the way it separates the recessive voltage means you get a much larger voltage change to indicate a bit so it is more resistant to noise.

However, in the motorsport and tuning world you will only be working with the high-speed version, the fault-tolerant system is mostly used for "comfort" type functions.

The term "dialects" that Zac was using in that video is referring nothing specific from what I can gather. I think the idea he was trying to get across was that just because you have two devices that speak "CAN", that doesn't mean they will be able to communicate. Every part of the CAN message structure and format will need to match and be known by all devices. That includes, endianess, bit rate, DLC, ID's, and then format the actual data itself. In OEM stuff there are also often extra tricks in the data part of the message that must match too - such as checksums and heartbeats etc.

Then in some cases (not much in motorsport) you have the extra protocol layer on top that is used to decode the ID's or message structure into some form of known data format. The Wikipedia links David posted are some good examples of different protocol layers that can be used on top of the CAN system..

Where did your CAN A/B/C terminology come from? It sounds like you might be confusing that from the terms CAN 2.0A Vs 2.0B? The only real difference between these two is the length of the ID - 11bit Vs 29bit.

I came from OE industry. And I frequently heard the CAN speed addressed in that way.

Then in some cases (not much in motorsport) you have the extra protocol layer on top that is used to decode the ID's or message structure into some form of known data format. The Wikipedia links David posted are some good examples of different protocol layers that can be used on top of the CAN system..

I'll try to wrap my mind around that

As Adam said, just because the hardware, and general description, matches, that doesn't mean they're going to always have 100% inter-operality (if that's a word?). Think of it like Win-Tel (PC) and AppleMac computers, they have many of the same parts, some directly interchangeable, but there are other parts that may fit but not have the hardware/software required to work in the other machine type. Another example is sometimes a manufacturer will drop support for some protocols with later iterations of their software, so something that did work will no longer do so *.

You may have noticed that some ECUs and Dislaps will state "compatible with", or similar terminology, to show they will work together - if both manufacturers don't specifically state they're compatible one should contact them directly, as some combinations simply won't work even if they physicall fit together and use the "same" connection.

*WIN10 dropped support for FAT12, as used for the old 'floppy discs' in the 3rd update, which meant my external drive was still recognised, and the presence of a disc was identified - even whether locked or unlocked - but absolutely no disc information could be read. If anyone reading this has a free program/app to read FAT12 in the later versions of WIN10 (64bit Pro), I would be thankful.