CAN Service Specification - 3.3 Auto conflict resolution

[mcmadhatter]

The specification says:

If a node receives a CAN frame which uses the same CANID as itself then the node should
perform auto-conflict resolution by performing self-enumeration to obtain a new, unique
CANID.

Potentially under certain circumstances there could be quite a few nodes trying to self enumerate at the same time, hammering the bus.

What about adding a random delay (e.g. 0 to 250ms) before attempting the self enumeration retry?

This would be similar to J1939 after address claim failure, which is done to spread the retries out on the network a bit, and prevent continuous locks and retries between multiple nodes.

[SvenRosvall]

This not a problem that has been observed or reported during the existence of CBUS.
Actually this wouldn't be much of a problem as there is no need for retry. Say that there are three or more nodes with the same CANID. When one of them sends a message, the other two (or more) detects duplicate CANID and starts self enumeration. They do so by sending out an RTR frame. So there may be multiple RTR frames that each node on the bus need to respond to and thus send out multiple zero-length frames. This may swamp the CAN bus but the CAN arbitration should resolve this. The nodes that are self enumerating collect these zero-length frames and build up their list of available CANIDs and pick one.
There is a risk that multiple nodes pick the same CANID but this new CANID will be chosen by less than the number of nodes that used the original CANID. These may detect duplicate CANID again and start a new self enumeration. Each time this happens there will be at least one less node with duplicate CANID.

[dpharris]

This is similar to the StreamID problem. We chose a random one from the available ones, so the chance of a repeat clash is reduced. But as you say, the problem will resolve the way it works now. David

…

On Sun, Mar 8, 2026 at 9:43 AM Sven Rosvall ***@***.***> wrote: *SvenRosvall* left a comment (Versatile-LCB/VLCB-documents#7) <#7 (comment)> This not a problem that has been observed or reported during the existence of CBUS. Actually this wouldn't be much of a problem as there is no need for retry. Say that there are three or more nodes with the same CANID. When one of them sends a message, the other two (or more) detects duplicate CANID and starts self enumeration. They do so by sending out an RTR frame. So there may be multiple RTR frames that each node on the bus need to respond to and thus send out multiple zero-length frames. This may swamp the CAN bus but the CAN arbitration should resolve this. The nodes that are self enumerating collect these zero-length frames and build up their list of available CANIDs and pick one. There is a risk that multiple nodes pick the same CANID but this new CANID will be chosen by less than the number of nodes that used the original CANID. These may detect duplicate CANID again and start a new self enumeration. Each time this happens there will be at least one less node with duplicate CANID. — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEDQSWMLAXKRZ2OD3TPO734PWPJ3AVCNFSM6AAAAACVL4ZCN6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMJZGQ4DIMZZGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>