Sample loss and gain changes when input is a video signal

[ali1234]

When input is a video signal, the number of samples produced drops to about 26.8 MSPS. The missing samples are consistently spread out, as if something systematically removes 114 samples from every video line. This effect does not happen if gain is very low. When gain is right at the threshold of triggering this behavior, the effect turns on and off approximately 50 times per second (ie about one PAL field), producing output that looks like this:

The presence of a video signal also seems to cause gain to change every few lines:

When gain is set to zero, neither effect can be seen:

When I connected an Arduino producing 100khz square wave I was not able to reproduce the effect at all, which is what leads me to believe it is caused specifically by a video signal.

[ali1234]

I've confirmed this is caused by the hardware detecting a video signal. I used pcimem https://github.com/billfarrow/pcimem to check VPRES during operation.

This tool also allows to write registers. I was able to prevent the sample loss by disabling "PLL adjust logic" (0x31016C, bit 25 = 0, datasheet page 6-73).

I have not yet figured out how to get rid of the gain changes.

[ali1234]

I managed to get rid of the gain changes by modifying values in "AGC Sync Slicer" (0x310204, page 6-82). I could not identify any single register which made the difference - all of them affected the visible banding in some way. The biggest effect was gained by setting BP_SAM_DLY to any non-zero value. I have no idea what these registers do. The ones that follow are also related to AGC. There still seems to be some skewing when video is detected but it is now fairly rare.

[happycube]

What slicer value is working for you? I can branch this and see if it works for everyone (need to make sure it doesn't affect raw capture - and if it does it needs to be switchable)

[ali1234]

Not sure what you mean - I am using raw capture mode to capture the whole video signal.

[happycube]

Sorry bout that - I meant the unlikely event the change causes side effects on LaserDisc RF capture. I'm not in a great spot to test it right now, but I'm happy to make the changes to cxadc.c.

[ali1234]

Right, I see. I'm not doing RF captures and I have no way to test that.

It seems that all the problems stem from some hardware circuit that detects video sync. Despite all the registers I changed, the VPRES register remains on. When it is off (ie because gain is too low or because I'm feeding a square wave instead of video) then nothing I changed seems to have any effect at all.

The PLL adjustment seems particularly insidious as it is actually trying to tweak the sample rate to match what it thinks is the video signal. So if your RF ever happened to trigger that circuit somehow it would do the same thing. I have no idea how likely that is, but I am pretty sure you don't want that to happen any more than I do.

The AGC registers seem to be designed so that you can have separate gain for sync and the visible image, and it will switch based on what it detects. So again I expect this to only do anything when it thinks there is a video signal. However there's a lot of registers here and it isn't clear at all what they do. One of them claims to disable sync slicing but apparently has no effect on whether sync gets detected or not.

[happycube]

Yup... I think a couple of people had glitches in the past, so the PLL adjustment is a very good thing to include.

Jumping back - which AGC Sync Slicer value's given you the best result?

(And in general, apologies if I'm being unintentionally obtuse. I definitely do want to get these changes in!)

[ali1234]

Any non-zero value in BP_SAM_DLY, and the rest unmodified. The actual value doesn't make any difference, as long as it is not 0 (which appear to be the default). I don't understand what this means at all. I'll keep experimenting to try to figure out what is going on.

Oh one other thing, I have blacklisted the cx88 drivers so that they never get loaded at all. I'm not sure if this made any difference, it is something I did to make debugging easier.

[happycube]

@atsampson can you take a look at this branch and see if it causes regressions on RF? (if you can't that's ok, I can try it later on probably)

[skunge2000]

I managed to get rid of the gain changes by modifying values in "AGC Sync Slicer" (0x310204, page 6-82). I could not identify any single register which made the difference - all of them affected the visible banding in some way. The biggest effect was gained by setting BP_SAM_DLY to any non-zero value. I have no idea what these registers do. The ones that follow are also related to AGC. There still seems to be some skewing when video is detected but it is now fairly rare.

BP_SAM_DLY is back porch sample delay. I'm guessing this is to move the point at which the back porch is sampled - potentially to set black level?

[Zcooger]

Bingo guys, use these settings:
cx_write(MO_PLL_ADJ_CTRL, (0x0<<25)|(0x0<<19)|(0x0<<14)|(0x0<<7)|(0x0<<0));

[ali1234]

(0x0<<25)|(0x0<<19)|(0x0<<14)|(0x0<<7)|(0x0<<0)

This evaluates to zero?

72537ec#diff-6826db83477166b864bfdd0431c5514d1d7cf45f4f22e0d7d80177c359cfd067R658

... and x & ~(0) evaluates to x, meaning this code just reads a value and then writes back the same value.

Am I missing something?

[ali1234]

I've finally started looking into this again.

cx_write(MO_PLL_ADJ_CTRL, (0x0<<25)|(0x0<<19)|(0x0<<14)|(0x0<<7)|(0x0<<0)); does turn off the PLL adjustment. It's the same as just writing 0 into the register. It is actually bit 25 (0<<25) that needs to be zeroed. That's PLL_ADJ_EN.

The proposed patch doesn't turn it off (it has no effect): you meant ~(1<<25) to zero only that bit.