You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CAN_SHIELD is misleading. It's not the shield. #174
There is a conductor (6) in the Can Physical standard that is marked as CAN_SHIELD.
The standard requires this to be connected to CAN_GND and optionally also to PWR_NEG.
It is misleading to call this conductor CAN_SHIELD. It is not the shield. The shield is a separate terminal if the board has an STP jack. Pin 6 is just another conductor, and the way we are using it is also just another conductor for GND. The purpose of this use is to minimize ground drift across the LCC cable, which makes a lot of sense.
I think that name comes from the names for the conductors in the CAN standards. Our Physical Layer TN says starting at line 60:
The signal names refer back to the signal definitions in the CAN specifications. UTP is unshielded cable, so the CAN_SHIELD conductor is being used as a second conductor for the CAN ground reference, CAN_GND.
The conductor assignments are based on industry practice for RJ45 connectors on CAN networks, c.f. Recommendation CiA 303 (2009) of the CAN in Automation e.V. group.
The 2017 version of that CiA recommendation describes the RJ45 connections on page 11. That refers to the conductor as "CAN_SHLD", although page 6 says that "CAN SHIELD" is an alternate terminology.
Although we can certainly use our own terminology, it seems useful to have that aligned with standard CAN use in case somebody wants to connect up e.g. a USB adapter or a diagnostic tool with an RJ45 CAN interface.
Activity
bobjacobsen commentedon Apr 15, 2025
I think that name comes from the names for the conductors in the CAN standards. Our Physical Layer TN says starting at line 60:
The 2017 version of that CiA recommendation describes the RJ45 connections on page 11. That refers to the conductor as "CAN_SHLD", although page 6 says that "CAN SHIELD" is an alternate terminology.
Although we can certainly use our own terminology, it seems useful to have that aligned with standard CAN use in case somebody wants to connect up e.g. a USB adapter or a diagnostic tool with an RJ45 CAN interface.