Other Parts Discussed in Thread: TCAN1044-Q1, TCAN1044A-Q1
Tool/software:
Hello,
What should be the maximum bus & stub length of CAN bus while using TCAN1043-Q1 with 2Mbps (CAN FD) data rate?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software:
Hello,
What should be the maximum bus & stub length of CAN bus while using TCAN1043-Q1 with 2Mbps (CAN FD) data rate?
Abhishek,
It will depend on the actual topology, but general rule of thumb with a CAN transceiver is recommended 25m bus length and 1.5m stub length at 1Mbps. For 2Mbps, that could be shortened, but with our TCAN1043-Q1 we have shown communication working at 40m bus length with stub length greater than 1.5m. In general, you want to make sure your CAN bits can propagate along the bus to every node in one bit time, which for 2Mbps would be 500ns. Considering delays from the cable, passive components on the bus, and the CAN transcievers themselves, this will need to be calculated by the system designer. And stubs will add impedance mismatch if they are too long, which can cause signal reflections that can distort communication. This is why it is important to keep stub length to a minimum.
This post goes into a bit more detail about this topic. Please let us know if you have any other questions.
Regards,
Eric Hackett
Thank you, Eric.
Is the same (above info) is applicable for TCAN1044ADRBRQ1?
Also, how to determine the CAN nodes / transceiver capacity for TCAN1043-Q1 & TCAN1044-Q1?
Abhishek,
Yes, this information is also applicable for TCAN1044A-Q1. The CAN node capacity is, again, relative to the answer I provided before. The limiting factors are the timing of the bit able to travel through the CAN bus reliably within enough time before the next bit is set. If the data rate is 2Mbps or higher, the longer your bus is the more time it takes for the bit to propagate through the bus and in a shorter allotted time due to the faster data rate.
Regards,
Eric Hackett