CAN, as you are no doubt aware, is a synchronous protocol without an explicit clock signal from the transmitter that the receiver can use. The transmitter and the receiver must use independent clocks that are not synchronized. In order for this to work the clocks must be close to each other in frequency so that over a sequence of bits the accumulating difference between the transmit clock and the receive clock does not get large enough to move the sample point in each bit cell into the next bit. One thing that makes this process more difficult is long strings of one bits or zero bits. To avoid long strings of bits with a single polarity the stuff bit is inserted to allow the receiver to determine where the bit boundaries are so that it can correct the location of the sample point.

I'd like to go deeper into the concept of bit stuffing.

To better understand, let's consider a hypothetical example of a CAN data frame being transmitted.

Identifier: 0x123
Data:      1010101111000111

How are stuff bits inserted into the data stream during transmission? Furthermore, could you explain the role of these stuff bits in maintaining synchronization and preventing long bit strings?

 

I'd like to go deeper into the concept of bit stuffing.

To better understand, let's consider a hypothetical example of a CAN data frame being transmitted.

Identifier: 0x123
Data:      1010101111000111

How are stuff bits inserted into the data stream during transmission? Furthermore, could you explain the role of these stuff bits in maintaining synchronization and preventing long bit strings?

There is not much point in going deeper and you only need to be aware of stuff bits when looking at a scope trace that does not have the capability of realizing that it is looking at a CAN frame.

Your example has no requirement for stuff bits in the identifier or data fields. Was that your intention?

Stuff bits are inserted and removed by hardware state machines in the CAN Controller. A stuff bit of 1 is inserted after 5 consecutive zeros and a stuff bit of 0 is inserted after 5 consecutive ones.

 

There is not much point in going deeper

I understand that in the CAN protocol, there are multiple types of frames such as data frame, remote frame, error frame, and overdue frame. Each serving distinct purposes.

Data frames are commonly used to transmit actual data between nodes. Error frames are used in detecting errors during message reception. remote frames, is used to request data from other nodes in the network. However, there's another frame type called the overdue frame, which also has its significance in CAN networks.


Have you utilized overdue frame and remote frames in your experience with CAN networks?
What purposes and how they are utilized in practice?

 

I understand that in the CAN protocol, there are multiple types of frames such as data frame, remote frame, error frame, and overdue frame. Each serving distinct purposes.

Data frames are commonly used to transmit actual data between nodes. Error frames are used in detecting errors during message reception. remote frames, is used to request data from other nodes in the network. However, there's another frame type called the overdue frame, which also has its significance in CAN networks.


Have you utilized overdue frame and remote frames in your experience with CAN networks?
What purposes and how they are utilized in practice?

There is no overdue frame. You may have misread whatever it was you were reading. There is an overload frame – maybe that is what you are talking about.

Refer to §3.1.4 of the CAN specifcation from Bosch, pp.17-18

This is all handled in hardware, and you can't make one happen or detect any evidence that one has happened.

This thread has migrated away from the original topic and I think you should start new threads for the questions born of insatiable curtiosity. (Kipling R., The Elephant's Child)

 

There is no overdue frame. You may have misread whatever it was you were reading. There is an overload frame – maybe that is what you are talking about.

I am sorry for my mistake, I remembered the wrong name.

This thread has migrated away from the original topic and I think you should start new threads for the questions born of insatiable curtiosity.

If you don't mind, can we continue this thread? It might be helpful for new readers as well.

Can you tell me what need to understood related to speed in the CAN protocol?

My understanding is that we can configure a node to send data at a specific speed, which we call bus speed. But I also see bitrate in documents, so does it mean how much time it takes to send one bit to transmit?

 

The basic tradeoff related to speed is maximum bit rate versus maximum cable length. The faster the bit rate, the shorter the maximum cable length. Use of isolated power for the transceivers will also affect the delay budget and shorten the maximum available cable length. As a rough guideline:

1. @125k bits/second your maximum cable distance should be less than 500 meters
2. @250k bits/second your maximum cable distance should be less than 250 meters
3. @500k bits/second your maximum cable distance should be less than 125 meters

We never planned to use data rates above 500k bits/second, e.g. 1M bits/second, because the maximum cable distance allowed using opto-isolators for the transceivers on both ends was negative 20 meters, so that won't work in this universe. That was 30 years ago and maybe there are opto-isolators with less than 40 nanoseconds of delay. That is 160 nanoseconds total for the bit in the ACK slot.

The amount of time it takes to send a maximum length random data frame is not uniform, but it is bounded. It depends on the number of stuff bits that must be added to the transmitted frame. We never bothered with looking at that analysis because the actual timing was never a big deal. Even at 125k bits/second there was more than enough time to scan 30-40 nodes in typical scan time of an Allen-Bradley scanner. Very few nodes actually used more than two bytes of the data field for their I/O data.

I strongly urge you to consider a new thread with a more appropriate title. The present one is misleading after the original question was answered. I don't think the mods would have a problem with breaking this thread into two pieces. Multimaster and General CAN questions. It is your thread so you're in the driver's seat.