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.

Incorrect TDR results

Part Number: DP83867CR
Other Parts Discussed in Thread: DP83869

Hi everyone,

I'm currently working on updating the DP83867 driver to incorporate TDR (Time-Domain Reflectometry) support. However, I've encountered some issues while attempting to detect short/open circuits.

For this update, I've used the following documents:

  • Application note TDR DP83867 (Link)
  • Datasheet for DP83867 (Link)

Here are the hardware details I'm working with:

  • Congatec Conga-SA7 SOM
  • Congatec Conga-Seval Carrierboard

When I connect an Ethernet cable from my carrier board to my laptop, all cable pairs return as OK. However, upon disconnecting the cable from my laptop and rerunning the test, I'm getting short circuit readings across all pairs. I anticipated open circuit readings since the cable isn't connected. Additionally, I've created a custom cable with switches to toggle short circuits. Interestingly, when I use this cable without enabling a short circuit, I observe the same behavior as with a standard Ethernet cable. Even when I do enable a short circuit while the cable is connected, all pairs continue to report as OK, despite the presence of a short circuit on one pair. When i disconnect the cable from my laptop and enable the short, all pairs return short between pair except the one that has the short enabled this returns OK. 

I've already conducted checks by printing all register values and manually analyzing the algorithm. Surprisingly, the output from this analysis aligns with the results returned by the driver. Thus, it appears that either the register data isn't accurate or I'm misinterpreting it.

Does anyone have any insights or ideas on what might be causing these issues?

Kind regards,

Mart

  • Hi Mart,

    What cable are you using? Please also share the MDI section of the schematic.

    DP83869 calculator GUI in the folder below can help simplify the process for TDR calculation:

    TDR Calculator Tool.zip

    Thank you,

    Evan

  • Hi Evan,

    Thank you for getting back to me.

    Attached, you'll find an image detailing the pinout of my RJ45 connectors on both ends. Additionally, I've included an image illustrating how I integrated the switches into the cable. The cable itself is a CAT5 UTP, approximately 1 meter in length.

    I also have a question regarding the TDR Calculator. When all values are zero except the first row with a peak sign of 1, the expected outcome should be a short circuit, correct? However, when I input my values, I'm getting an open circuit result. When i put the same values in the second row I get short circuit.

    Kind regards,

    Mart

  • Hi Mart,

    Are you seeing all values as zero except for peak sign when running TDR?

    The way the TDR algorithm is designed, it will not report an open/short fault unless the fault amplitude is above a certain threshold. Above this threshold, you are correct that peak sign = 0 indicates an open, and peak sign = 1 indicates a short.

    Thank you,

    Evan

  • Hi Evan,

    In the top row of calculator tool I put the values 50 (loc), 50(amp), and 1(sign). I expected to get Short but the tool returns Open. When i put the same values in the second row i get short. According to the application note 50 is above the thresh hold.

    Also when using the different cables do i need to calibrate this threshold for each cable or is the threshold defined in the application note a value that can be used for every cable.

    Kind regards,

    Mart

  • Hi Mart,

    Unexpected short/open behavior looks to be an edge case with shorter (<2m) cable lengths - are you able to repeat the test for a >10m cable?

    The threshold is constant and PHY-dependent, but the propagation delay noted in appnote is PHY and cable-dependent.

    The prop_dly values noted in appnote have been calculated for each PHY and CAT5/6/7 cables. If using another cable type, this prop_dly value should be calculated manually after iterating TDR and noting the offset between the reported fault and actual fault location.

    Thank you,

    Evan