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.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 375 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

THVD1426: THVD1426

Justin Ou
Prodigy 30 points
Part Number: THVD1426
Other Parts Discussed in Thread: THVD1406

Hi Sir,

We suggest customer to design in TI RS485 transceiver THVD1426 with auto direction function.

But customer rejected , and we would like to double confirmed TI for their concern. Any solution we can provide to customer to convince they to adapt THVD1426?

In :Application Note RS-485: What is Auto-Direction and Why it is Useful in Systems? (slla574.pdf)

https://www.ti.com/lit/an/slla574/slla574.pdf?ts=1697772056213&ref_url=https%253A%252F%252Fwww.google.com%252F

THVD1426DR auto-direction control is a good solution for high baud rates (1 Mbit/s or higher).
But at low baud rates it only drives its output (“1”-Bits) for a short time (fraction of a bit time, about 1.45µs).
This is because it cannot adapt its “1” bit time to the selected baud rate.
That’s why TI recommends Bias resistors when using it at low baud rates.
I’ve attached the application notefor your convenience (Please refer to Chapter 2.2).
If we don’t implement the bias resistors then the noise margin at low baud rates will be considerably lower with THVD1426DR.
Without the Bias resistors and at low baud rates, the selftest may work if THVD1426DR talks with another THVD1426DR but may fail if a RS485 transceiver of another vendor is used. Especially if 32 bus nodes are connected together.

For RS485/RS422 communication, (near to) 100% backwards compatibility with our older products is desired.
Problem is that we don’t know if our end customers are always implementing Bias Resistors in their RS485/RS422 networks.
Especially RS422 is critical because it is expected that the transmitter is always on in that case (Bias resistors are not necessary in that case).
If our end customers are using RS485 nodes with modern transceivers (which are supporting true failsafe mode) then the Bias resistors are not required normally and might not be implemented.
=> There is a risk that THVD1426DR may cause incompatibility issues in some of our customers RS485/RS422 network installations.

BR

Justin

  • 0
    Guru 279750 points

    Auto-direction RS-485 transmitters must make assumptions about the timing, i.e., when to go from actively driving high to the idle state. There are two devices (THVD1426, THVD1406) with different timeouts; if neither one fits your application and you cannot rely on fail-safe receivers or fail-safe resistors, then you must use a transceiver with manual direction control.

    (For RS-422, you would not need an auto-direction transceiver.)

  • 0
    Prodigy 30 points

    Hi

    Thanks for your reply, but make me confusion.

    THVD1426 is our plan to design. RS485 & RS422 using the same com port DB9. If we want to use auto direction, why do we need to manual control.

    BR

    Justin

  • 0 in reply to Justin Ou
    Guru 279750 points

    Only the THVD1426 and THVD1406 have auto direction control. If these two devices do not fit your requirements, then you cannot use auto direction control.

    (And there is no connector named "DB9".)

  • 0
    TI__Mastermind 46687 points

    Hi Justin,

    Using an Auto-direction device for general purpose legacy applications is not really advisable because for the auto-direction device like THVD1426 to work at lower data rates than 12Mbps it assumes the entire bus is receiver fail-safe where VIT+(max) is less than 0V. If they want to create systems with auto-direction control - the entire system needs to support that feature. I would advise using a general purpose transceiver instead of a auto-direction if you want legacy support if the legacy devices are not receiver fail-safe. Reason being - the THVD1426 can handle data rates below 12Mbps just fine as the app note shows - as long as every device on the bus is receiver fail-safe - but depending on what devices are used in legacy system there are RS-485 compliant devices that have their VIT+(max) = 200mV - so at 0V differential inputs the state is undefined, so there could be issues working with other RS-485 devices on the line. If every device in the legacy system is fail-safe then you should be able to run the system without bias resistors - as the biasing resistors are not required - they just increase the noise margin - i.e. if the input differential is 0V on the THVD1426 you can have up to -20mV of noise across operating conditions without the state being changed - adding bias resistors would set a differential of 0V to a higher level increasing the noise margin above 20mV. The bias resistors are optional.  

    Also it must be stated that the THVD1426 is not pin to pin with other RS-485 transceivers due to how the auto-direction works - so redesign would be possible if using an auto-direction device. I.e. you can't use this in place of a general purpose RS-485 - but you may be able to communicate with other RS-485 devices.

    So In conclusion:

    1. THVD1426 is backwards compatible with other RS-485 systems - as long as every device in legacy application reads a input differential of 0V as a logic high and the data rate is 12Mbps or lower.  

    2. The bias resistors are used to increase noise margin on the bus - if every device on the bus is receiver fail-safe the bias resistors are optional. If every device is not  fail-safe then the bias resistors are required - but since the pinout is slightly different for auto-direct devices you will have to redesign that node regardless - and you only need 1 set of biasing resistors on the entire bus.

    So its possible - but there are some caveats that may make a general purpose device more favorable. 

    The main question that needs to be asked is - do they need auto-direction - if the answer is yes then they can't expect everything to support their legacy applications without some change. 

    Please let me know if you have any additional questions. 

    Best,

    Parker Dodson