Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

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.

SN65HVD23: Propagation delay (SPRAC35)

Part Number: SN65HVD235

Im facing difficulties on understanding the datasheet of SN65HVD235.  I need the propagation delay of the device to use as input for the CAN Bit Timing calculatior (SPRAC35). The calculator uses:

total propagation time = 2 x (delay of the eletromagnetic propagation on the wire + delay due to transceiver / interfaces)

But im confused with the many values of delays in the datasheet and I dont know what I should use.

I'm considering that the most important ones are:

Driver
propagation delay low to high 
propagation delay high to low 

Receiver
propagation delay low to high 
propagation delay high to low 

Device
Loopback delay, driver input to receiver output 
Loopback delay, driver input to receiver output 
Loopback delay, bus input to receiver output 
Total loop delay, driver input to receiver output, recessive to dominant 
Total loop delay, driver input to receiver output, dominant to recessive 


Could someone clarify for me?

  • Henrique,

    For CAN, the parameter that is important is the total loop delay, this gives you the delay associated with the transceiver from driver input to receiver output. You'll add this to the total delay associated with the full bus cable (usually given as a parameter of the cable, 5ns/m is a typical value), and then add any delays due to other components on the bus: chokes, diodes, capacitors, etc.

    However, the device you linked is an RS-485 transceiver, did you want the equivalent parameter for an RS-485 transceiver?

    Regards,
  • Thank You.

    In fact I forgot the last digit (5) of the part number. Its SN65HVD235... a CAN transceiver. I've already corrected the question.

    Ok, so I will use the total loop delay...   but, the calculator spreadsheet is coded to multiply the delay input (cable propagation + electronic delay)  by two, to get the round trip delay. 

    So should I supply the calculator with the total loop delay of the datasheet divided by two ? It already considers the round trip ( needs to be divided by two before used) or it needs to be multiplied by 2 (then, used directly on the calculator) ?

  • Hi Henrique,

    The loop delay of the transceiver would need to be multiplied by 2 as well if you were trying to compute the full path delay back to the controller. The total delay in any given direction would consist of the transmit-direction delay for the transmitting node, the one-way cable delay, and the receive-direction delay for the receiving node (effectively one cable delay and one transceiver "loop delay"). The round-trip delay would then be double this, or two cable delays plus two transceiver loop delays.

    I hope this is clear - let me know if not.

    Regards,
    Max
  • Its clear now, Thanks !
  • Is my interpretation correct:   

    The total round-trip delay is used for configurating the bit-timing parameters because the transmitter, for every sent bit, should expect to receive a response (for arbitration) from the farthest receiver (worst case) inside the same BIT Time of that bit.

    ?

  • Henrique,

    Yes, that is correct. This limitation is critical for the arbitration function to properly determine which message has the highest priority (lowest identifier value).

    Max