Does the AD9889B support the 1920x1200 resolution at any frame rate?
Yes, the AD9889B can support 1920x1200 - even at 60Hz - if there is reduced blanking. The key is that the pixel clock must be less than the maximum rating for the transmitter. The only limitation will be the 165MHz top end of the part.- 165MHz. It may not be able to automatically detect these modes and insert the CEA861 modes, but those can be inserted manually for transmission.
Regarding the AD9889B:
We do use the reduced blanking on the 1920x1200p60.
We use an external DE signal (we also provide VS and HS and clock externally).
The clock rate is less than 165MHz.
“It may not be able to automatically detect these modes and insert the CEA861 modes, but those can be inserted manually for transmission.”
Can you please advise? Does this apply to us in this situation?
First off, all other resolutions (less than 1920x1200p60) work fine, including 1600x1200p60 which actually uses a higher clock rate (still less than 165MHz).
Situation: Providing the 1920x1200p60 with 16 bits 4:2:2 (single clock) style 2 with external DE and others mentioned above. Sync signals are very robust. Tested by (scope) triggering on one vertical sync then looking at second vertical sync and all other synchronization signals in relation to it.
Symptom1: Visible on (some) monitors as an intermittent (measured in seconds) vertical momentary shift up of >20 pixels, always the same height (including a black bar at the bottom of the screen)
Symptom2: Vertical shift of ~1 pixel height very often (multiple per second).
Symptom3: Inputting DVI into ADV7840 (same product, different unit) and looking at the VS/Field signal with my scope. Most of the time the signal is solid with pulses at 60Hz, but intermittently there is a major corruption (signal inversion or extra pulses).
I can not be certain that symptom 1 is not due to our graphics processor, but I include it because it may ring a bell.
Symptoms 2 & 3 occur even when using a test pattern source bypassing our graphics processor.
I could seriously use some help.
I have exhausted my in-house resources and have gone through the AD9889 register map myself. I did find a couple of things, but they did not affect this problem.
If you are running 1920x1200 60Hz with reduced blanking, there will be no need to insert a video mode. As far as I know there is no CEA861 defined mode for this since it is a graphics mode (WUXGA) and the CEA861 docs only deal with video modes.
I tend to agree with you about the Symptom 1 case. There is little to indicate why the AD9889B would jump 20 lines. This is almost certainly a function of the Vsync signal.
Symptom 2: Given a shift (rapid one) of 1 line, I might suspect the clock to Vsync timing. You should be able to alter the clock to data timing in register 0xBA[7:5]. Normally (nominally?) we prefer to see this set with a value of '011'. You can invert the clock by writing this to '111'. Or you can move it by 400ps by changing a bit at a time.
Symptom 3: This could likely be explained with the clock position as well.
Can you send me a register dump for the AD9889B when you are running at WUXGA and see some of these issues?
Just to be clear, in register 0xBA the value of ‘000’ results in a special case of ‘positive edge capture for input clock 2x data’ but all other values 001 to 111 represent different phases of the clock for input clock 1x data.
I was unaware of that undocumented feature of the 0xBA register.
I assume 000 is a special case? “positive edge capture for input clock 2x data frequency”
We tried all of the settings and did not observe any change on the 1 pixel frequent vertical shift (I refer to it as the vertical quiver). There were settings that just did not work and settings that gave us ‘sparkles’ but of the settings that provided otherwise good video, the 1 pixel high quiver did not change.
Symptom 1 (the Vertical Jump) is being tracked separately and does not appear to have any relation to the AD9889B.
Do you have any other ideas?
OK, that is fairly odd, then. Can you send me a register dump so I can get an overview of all the registers?
Hopefully this is sufficient.
The following is the data dump. Each line has 16 bytes of data.
rdm 2 0x7a 0 0xff
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, E, 3C, 18, 1, 13, ; 0 – 0xf
25, 37, 0, 0, 0, 2, 35, 6A, C, 52, 8, 0, 0, 0, 19, D7, ; 0x10 – 0x1f
1C, 54, 8, 0, 1E, 89, 2, 92, 0, 0, 8, 0, E, 87, 18, BD,
16, 2, C0, 10, 5, 30, 29, F, 0, 43, 80, 1, 0, 0, 0, 0,
0, 10, 60, 7E, 78, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, C0, 0, E4, 0, 3, 2, 0, 18, 38, 61, 18, 70,
0, 0, 87, 87, 8, 4, 0, 0, 0, 0, 0, 40, 0, 0, 40, 6,
B8, 48, 9A, 5B, 99, 4, 7A, F6, B0, 0, 40, FF, 0, 0, 0, 0,
0, 0, 0, 0, 0, 10, 14, 0, 2, 3, 0, 1, 2, 0, 0, 70,
70, 70, 70, 70, 70, 70, 70, 70, 70, 70, 70, 70, 70, 70, 70, 70,
70, 70, 70, 70, 70, 70, 70, 70, 70, 70, 7D, AA, 1C, 0, B0, ; 0xf0 – 0xfe
Please try changing reg 0x98 from 0x03 to 0x07; that bit 2 is supposed to be high.
This AD9889B is an old workhorse of a HDMI Tx for ADI. This type of problem - "quiver", as you aptly call it - is not familiar except as a sync type issue (esp. with interlaced content), or possibly it has been seen with settings when they're not following factory guidelines.
The 20 line skip that you see occasionally (symptom 1) seems likely a sync issue, and it raises questions of whether the ongoing sync has a similar issue, though I do note that you described sync signals as "robust". For this quiver, symptom 2, it happens when you bypass the graphics processor - but I'm wondering about that bypass path. Essentially I'm asking if you can look at VSync and HSync, and aside from the Sync signals themselves, noting the number of HSyncs from VS to active video, and comment on how that compares from wherever it's first generated to where it gets applied to the AD9889B. I hope I'm being clear. I can give you a ring next week if not.
Also, we're wondering if some infoframes could be causing this behavior. Regardless, you might just try to put the Tx in DVI mode rather than HDMI mode - i.e. set bit 0xAF = 0 - and see if the problem persists. I'm not hopeful of this, but it seems easy to try. On the long shot side, I suppose you've tried more than one monitor, but I have to ask...
Retrieving data ...