I have one emitter sending extended message and many nodes in the bus. I am working with the emitter and the last receiver (the first and the last in the diagram), other 3 nodes are not under my watch cause it is a project with two compagnies.

All nodes are sharing a common ground, two got filter for unwanted message. Messages sent are in extended mode, two nodes are listener only (ACK is not taking care of) and two nodes are extended and can managed ACK.


When my bus is composed by the emitter and my node only, messages are received perfectly (pink line) but if there is the others 3 nodes, my receiver does not receive messages (blue line).


A CAN bus message can be removed by one nodes and so be unreadable by others nodes ? If yes, what can cause this sort of problem ?


The traffic is present in both case but with all the nodes only messages from my emitter are not transmit by the node (and this node is the only one that need these messages).

In the case 2, we managed to read messages from others nodes.

Also there is a terminating resistor and the cable is about 50 cm and they are twisted.

Life cycle CANbus message (extended)

  • \$\begingroup\$ Looks like a termination resistor problem, have you got any ? \$\endgroup\$
    – Mat
    Commented Aug 24, 2022 at 11:39
  • \$\begingroup\$ Yes there is already a terminating resistor between CAN High and CAN Low. \$\endgroup\$
    – Konflex
    Commented Aug 24, 2022 at 12:08
  • \$\begingroup\$ How long is the cable and the derivations ? Do you change cables depending on the number of nodes wired. Is it a twisted pair, with shield ? Have you tried removing the faulty ones one by one to discrim to possibly one unit ? What are the "standard" ones ? They could break the transmission if they are not "extended" configured \$\endgroup\$
    – Mat
    Commented Aug 24, 2022 at 12:58
  • \$\begingroup\$ I will update the question for clarification. The traffic is present in both case but with all the nodes only messages from my emitter are not transmit by the node (and this node is the only one that need these messages) \$\endgroup\$
    – Konflex
    Commented Aug 24, 2022 at 13:02
  • \$\begingroup\$ @Mat the standard ones are listener only \$\endgroup\$
    – Konflex
    Commented Aug 24, 2022 at 13:04

2 Answers 2


I would guess that the CAN bit rate on your nodes is slightly different than that of the third party nodes. By default (usually) non-passive nodes on a CAN bus monitor every packet on the bus. When the node sees a valid packet (even if it will not be received by the node) it will ACK the packet. If the node sees a malformed packet, it will actively transmit to ensure the packet is not received by any other node.

I would start by putting an oscilloscope on the CAN lines and measure the bit rate that your nodes are transmitting at. Then, if possible, measure the bit rate at which the third party nodes transmit at. You may well find that either your nodes are not transmitting at the rate you expected, or that the third party nodes are transmitting a rate you do not expect.


Mat is on the right track, but you need two 120 ohm terminating resistors, one at each physical end of the bus. The bus should be a single set of wires not a pair as your drawing indicates. Measure the bus resistance when it is off, it should be between 55 to 65 ohms. It needs to be a bus not a star configuration. I am not use to emitters on the bus. The emitters must allow dominate and recessive modes. All messages must be acknowledged, if they are not they will eventually error and time out. They must all be operating at the same baud. You can get an inexpensive USB logic analyzer and monitor the bus to see what is happening. If you have access to a scope that would even be better. Either of these will tell you if everything is at the same baud. I have used a lot of MPC2515 modules and over time and vendors they have had different crystal values. Here is a link to some of the basics of CAN that might help: "https://grouper.ieee.org/groups/msc/upamd/communications/CAN_Primer.pdf" Mixing protocols is a receipe for a problem. I would suggest you start at a lower baud rate, maybe 125K or less and get everything to work with one type of message, 11 or 29 bit identifier. I do not understand why there are receivers only, the software can keep them from transmitting.

From Keil Slide linked above: " Any node see something wrong on the bus. Makes bus dominant. All nodes knows this is an error frame. Sender stops transmitting. Increments its Transmit Error Counter by 8. If TEC < FF, resends message else busoff. Others increment their Receive Error Counters. Note: only a node can boot itself off the bus." I thought this might help it sounds close to what is happening. Different bauds will cause errors.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.