What are comprehensive differences between J1939/Extended CAN vs. J1939/CAN FD?

How does messaging work in CAN FD? How are PGNs and SPNs defined for CAN FD?

For Extended CAN, SAE J1939-71 defines PGNs and SPNs. All the PGNs and SPNs defined in SAE J1939-71 don't apply to CAN FD? For example, in SAE J1939-71 PGN 65267 is Vehicle Position. There are two SPN's in this PGN. Each SPN is 4 bytes. This makes 8 byte data field. How to construct some message like Vehicle Position in CAN FD?

If some Electronic Control Unit (ECU) is communicating over J1939 with extended CAN, how to determine if this ECU needs capability of CAN FD?

SAE J1939-21, Transport layer protocol defines messages that have data field more than 8 bytes. Why not just use SAE J1939-21 to send large size messages? Is CAN FD faster?

Is data field size the only difference between CAN FD and extended CAN? Does 8 times larger data field makes CAN FD much faster than extended CAN?

What code changes are needed to update from J1939/extended CAN to J1939/CAN FD ? is different J1939 stack needed? Are different CAN drivers needed? If yes, please provide comparison of J1939 stack changes and CAN driver changes.

What are other significant differences between J1939/extended CAN and J1939/CAN FD ?

I can't help much with the J1939. I don't know if CAN-FD is used with J1939.

Large messages across multiple frames take a long time to send, and each frame can be contended with other traffic on the network, while a single CAN-FD frame can be 64 bytes, which allow significantly more data. CAN-FD uses one baud rate for the frame ID, and then shifts to a higher rate for the data.

One advantage is that CAN-FD frames and normal CAN frames can be on the same network, as long as they have separate frame IDs and the same baud rate for the frame IDs. That allows some modules to be updated to CAN-FD while other ones are still using normal CAN frames.

>> One advantage is that CAN-FD frames and normal CAN frames can be on the same network
How does this work? If a classical CAN frame is broadcasted, CAN FD controller and classical CAN controllers will be able to read the frame id because they will have the same baud rate for the frame ID? From the frame id, CAN FD controller will find out that this is classical CAN frame and ignore it?

On the same network, classical CAN message cannot be received by CAN FD controller? And vice versa?

jani12 said:

>> One advantage is that CAN-FD frames and normal CAN frames can be on the same network
How does this work? If a classical CAN frame is broadcasted, CAN FD controller and classical CAN controllers will be able to read the frame id because they will have the same baud rate for the frame ID? From the frame id, CAN FD controller will find out that this is classical CAN frame and ignore it?

On the same network, classical CAN message cannot be received by CAN FD controller? And vice versa?

Click to expand...

Most CAN controllers ignore most CAN frames.

If you have, for example, 10 modules on a network, and one of those module transmits something, the chances are that the most of the other modules will have no interest that bit of information. Some items of information will be of use to most or all of the modules, but many items will only be used by one other module. When some modules are for optional items on the cars, information may be transmitted that is of no interest to any other module.

A CAN database might have 100 IDs, but a module could only be interested in 20 or so of them. So when an ID arrives that a module isn't interested in, that frame won't be used by that module. It doesn't matter whether the data in that frame can be interpreted by that module or not, as the data will be ignored.

For example, you might have a signal saying that the lights are on. A seat module will ignore that.

If a new signal arrives on the CANbus with a new ID, existing modules will ignore it. New signals can be added until the network utilisation approaches 100%, and most vehicles run at much less than that.

If that new signal is CAN-FD, the ID will be understood by the existing modules, but the data will not be understood because the baud rate is wrong. The data in the CAN-FD frame, as seen by the CAN (non-FD) modules will be random. It could be anything. However, as any data with the new ID will be ignored, that won't affect the non-FD modules. They will just see it as an error, but nothing to do with them, and get on doing what they are programmed to do.

I think that CAN-FD modules are likely to be able to understand non-FD frames. They will be programmed with a list of IDs of CAN-FD frames that they need to understand, and the meanings of each of the 64 bytes of data they contain. They will also be programmed with a list of IDs of the non-FD frames and the meanings of each of the 8 bytes of data they contain. As long as the baud rate switching that happens during the reception of a CAN-FD frame can be turned on and off according to the ID, then a CAN-FD module can interpret non-FD frames, which would meant that new modules could still understand the old signals.

Diver300 said:

If that new signal is CAN-FD, the ID will be understood by the existing modules, but the data will not be understood because the baud rate is wrong. The data in the CAN-FD frame, as seen by the CAN (non-FD) modules will be random. It could be anything.

Click to expand...

It's new signal because it has been modified from classical CAN message to CAN FD message? The ID is same but data size is larger? The existing modules will think that this is classical CAN message because they are not programmed to read the bit in the ID field that says whether the message is classical CAN or CAN FD? Since existing modules will read CAN FD data with classical CAN baud rate, error will occur? This will eventually take down some module?

Diver300 said:

However, as any data with the new ID will be ignored, that won't affect the non-FD modules. They will just see it as an error, but nothing to do with them, and get on doing what they are programmed to do.

Click to expand...

I believe the new ID is not programmed in the existing modules? Since new ID isn't programmed i the existing module, CAN FD message will be ignored by classical CAN module. No error will occur?

An existing ID should never have the frame format changed without reconfiguring every module that uses the data in that frame. On cars and vans, the ID and the position of the data in the frame is usually the only thing that identifies the data.

Therefore when a new ID is added, it will be different from existing IDs, and no existing module will attempt to interpret it. As a result it makes no difference to the existing modules whether the new frame uses CAN-FD or not.

It doesn't matter how many frames a module ignores, as long as it sees the frames that it expects.

Modules won't be inspecting the data of frames with IDs that they are not programmed to read, so it doesn't make any difference that the data in the CAN-FD frames can't be read by existing modules.