AnsweredAssumed Answered

ADV7623 Background Video Measurements

Question asked by hbv on Jul 11, 2013
Latest reply on Nov 11, 2013 by hbv

We have had generally good luck with the background measurement feature in the 7623.  We are using the sdk repeater implementation.  We have run across a couple of behaviors that warrant questions:

 

  • We have at least one HDMI extender product that will produce "garbage" video (noise on the TMDS line(s)) when the source device turns off its display.  The full input signal path is this:  laptop --> extender product --> 7623.  With this input once the display is woken up, the 7623 returns obviously bad data for all 5 elements (H and V Active and Total, and TMDS clock).  The only way I have found to get correct measurement is to physically remove the HDMI plug and reinsert (remove the +5V signal is what we believe is the actual trigger to recover). 

    We have also seen a similar behavior in the past with at least on laptop itself plugged into the active port.  Once it went to sleep and woke up again, the only way for the 7623 to recognize that video was present was to unplug/plug the cable (once again, we surmised that this was actually the +5V signal going away and returning).  This example, the background measurements were not being used but it seems as if the behavior is related.

    I have tried disable/enable of the EN_BG_PORT as well as PWR_CTRL_PRT as possible ways to trigger a "reset" of the measurement subsystem.  On rare occassions while stepping through the code, the measurements returned have been correct.  This prompted trying a delay between the measurement request and the test for ready (see bullet below for related question).  I tried 10 and 20 msec.

    The sdk debug output is very similar between the unplug/plug case which works and the failing case.

    Background Video Measurements are correct when +5V signal goes away and comes back

-MwRx0: 35:785 ADIAPI_RxHdmiGetBgTmdsFreq not available
Background Video Data: HActive=1920, VActive=0, HTotal=1, VTotal=0, PClk=15463
-ARx0: 35:842 Mute State changed to 2
-App0: 35:842 Repeater EVENT: Rx mute (1)
----------> RxInt0: Port A TMDS=1
----------> RxInt0: Port A cable Det=1
----------> RxInt0: Port A PLL=1
-ARx0: 35:859 Mute State changed to 0
-App0: 35:860 Repeater EVENT: Rx mute (0)
-ATx0: 35:866 TXAPI_InitRxVars() #1
-ATx0: 35:869 TXAPI_InitRxVars() #1
-App0: 35:871 Repeater EVENT: Rx TMDS det (8)
-ARx0: 35:873 VCO Reset
-ARx0: 35:874 Video PLL Locked Port A
-App0: 35:881 Repeater EVENT: Rx Vid PLL lock (1)
-App0: 35:887 Repeater EVENT: Rx 5V det (8)
(20:41:55:955): Channel 1: AV_SDK_EVENT_RX_5V_DETECTED-plugged
-ATx0: 35:895 TXAPI_InitRxVars() #1
-App0: 35:898 ^^^^ A/V change on chan 0, updating client ^^^^^^
-App0: 35:905 ^^^^ No signal present on chan 0, leaving update. ^^^^^^
Background Video Data: HActive=1920, VActive=1200, HTotal=2080, VTotal=617, PClk=15463

 

 

     Background Measurements are never correct
----------> RxInt0: Port A PLL=1
-ARx0: 41:025 Mute State changed to 2
-App0: 41:026 Repeater EVENT: Rx mute (1)
-ARx0: 41:033 Mute State changed to 0
-App0: 41:034 Repeater EVENT: Rx mute (0)
-ATx0: 41:041 TXAPI_InitRxVars() #1
-ATx0: 41:043 TXAPI_InitRxVars() #1
-ARx0: 41:045 VCO Reset
-ARx0: 41:046 Video PLL Locked Port A
-App0: 41:052 Repeater EVENT: Rx Vid PLL lock (1)
-ATx0: 41:054 TXAPI_InitRxVars() #1
-App0: 41:063 ^^^^ A/V change on chan 0, updating client ^^^^^^
-App0: 41:064 ^^^^ No signal present on chan 0, leaving update. ^^^^^^
Background Video Data: HActive=170, VActive=0, HTotal=8121, VTotal=0, PClk=9265
-ARx0: 41:133 Mute State changed to 2
-App0: 41:133 Repeater EVENT: Rx mute (1)
-ARx0: 41:144 Mute State changed to 0
-App0: 41:144 Repeater EVENT: Rx mute (0)
-ATx0: 41:151 TXAPI_InitRxVars() #1
-ATx0: 41:154 TXAPI_InitRxVars() #1
-ATx0: 41:156 TXAPI_InitRxVars() #1
-App0: 41:160 ^^^^ A/V change on chan 0, updating client ^^^^^^
-App0: 41:167 ^^^^ No signal present on chan 0, leaving update. ^^^^^^

 

 

<< note that the bad measurements just continue at this point forever >>

  • The sdk code does not allow any time to pass after setting the BG_MEAS_REQ prior to checking the BG_MEAS_DONE_RAW.  The pardigm of request, check for ready, then read data suggests that there is some amount of time required to execute the measurement.  Should the code be trying repetitively up to some timeout interval?  What should that interval be?

Outcomes