TMDS1204: About Receiver Sense（RSEN）

Hey Weifeng,

We have a pin called SIGDET-OUT which will act as a flag when a signal is received by the TMDS1204. Will this pin work a a receiver sense enable for your system?

SIGDET-OUT is not the RSEN ， because SIGDET-OUT detects the IN signal of TMDS1024. For TMDS1024, RSEN refers to detecting the HDMI SINK at the OUT of the TMDS1204.

Typically, HDMI transmitter ICs have RSEN functionality.

For more information on the concept of RSEN, you can refer to the following link.

HDMI Receiver Sense Logic and TMDS Capacitor Coupling - Electrical Engineering Stack Exchange

TMS320DM8168: RSEN signal importance for HDMI working - Processors forum - Processors - TI E2E support forums

Hey Weifeng,

Thanks for the support materials. The TMDS1204 does not have any RSEN function.

An external implementation will be difficult to implement as well. As you will need to design circuitry that will sense 100 ohm impedance on the TX lanes which will add loss to the signal path.

What is the system you are looking to design? Why is RSEN a key care about? 

A source application will look something like this:

In this case the HPD will serve as the flag determining if a video sink is connected as the HPD signal comes from the sink.

A sink application will look something like this:

In this case the SIGDET signal will determine is a valid signal is being received by the TMDS1204

In both these cases I'm not sure I understand why RSEN is needed.

Best,

Vishesh Pithadiya

My system is a source application. Monitors usually have multiple HDMI interfaces, and the monitor can be set to automatically select the input interface or choose a fixed input interface.

When the monitor is set to automatically select the input interface mode, the monitor will automatically switch its input interface and detect whether there is a valid video input on the current input interface.

From the perspective of the source end, as long as the HDMI cable is plugged into the monitor, HPD becomes effective immediately, and EDID can be read normally, but only when the monitor switches to the corresponding input interface does RSEN become effective, and at this time, the HDMI FRL training can be successful.

The problem I am currently facing is that the FRL link training often fails, and the reason is that the FRL training is initiated without waiting for RSEN to become effective.

Additionally, HDCP also requires RSEN to be effective before it is initiated; if HDCP is started as soon as HPD is effective, HDCP is also prone to failure. In summary, for monitors with multiple HDMI interfaces, an effective HPD does not mean that the current input is valid (it can only initiate EDID operations), only an effective RSEN allows the SOURCE to truly initiate HDCP and FRL.

Hey Weifeng,

Are you able to share the DDC log of the link training failure? 

weifeng xu said:

The problem I am currently facing is that the FRL link training often fails, and the reason is that the FRL training is initiated without waiting for RSEN to become effective.

The sink is the device that sets the FLT_ready bit to initialize the link training process. RSEN should not be needed for link training to be a success, as link training should not start unless the sink initiates it. 

I reviewed the FRL link training logs and found that the FRL training failure occurs at LTS:3 TIMEOUT. The FRL LTS:2 FLT_ready completed normally.

This is likely a design issue with the monitors, but testing two monitors showed the same phenomenon.

I observed a basic HDMI 2.1 generator that always waits for RSEN to be valid before starting to output signals and consistently completes the FRL training successfully. This basic generator is not of my design, so I cannot access its logs.

Thank you very much.