Skip to content

CAN_SHIELD is misleading. It's not the shield. #174

Open

Description

@balazsracz

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.

Activity

  1. bobjacobsen commented on Apr 15, 2025

    @bobjacobsen
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions