How do we enable vertical blanking pass through?
We write 0xB0 but it doesn't take it.
Thanks for the help!
I should mention this is on the ADV7802.
You wrote 0xB0 to what? Register 0xC8? Bit's 1 an 0 seem to be the ones that matter in that register but 0xB0 doesn't make sense for it since bit 7 is reserved and should be 0.
A colleague supplied more detail on the set up on Nov 2, but we haven't heard any back.
We enable Vertical Blanking passthru but it move VITC from lines 14 and 16 to 10 and 12. And it corrupts the data.
Can you helpus figure out what we are doing wrong?
Do you have SDP AV codes turned on? (SDP_SAV_EN & SDP_EAV_EN)?
You also might need to set TOGGLE_ADF depending on your setup.
I have been searching the software manual but could not find SDP_SAV_EN or SDP_EAV_EN. Could you provide the base address and sub address of these bits? We are going to try and set TOGGLE_ADF and see what happens.
We found 0x40 0xB2 (SAV EAV Controls) and SAV_EN/EAV_EN have already been set to 'Insert SAV/EAV' codes.
We have set TOGGLE_ADF (0x20 0x63 bit 7 = 1) but it has not helped. the VITC is still in the wrong lines.
Hi Thomas, Wayne
I'll get a 'known working' script for VBI data and post it for comparison. Sorry for the delay...
We have been trying to pass VBI information from the CVBS input to the SDI (525i/625i) output. So far we cannot get this to work. This is what we have done so far. Setup: NTSC VITC gen (analog)--> ADV7802 --> (digital) WFM 7100 (SDI analyzer) ** Of course, we have a serializer, cable driver/eq, etc in the setup as well. 1) We have a VITC generator on line 14 and line 16 for NTSC. 2) We are reading from 'Status Detection Register' ( base address 0x20, sub address 0x40) and see that the ADV7802 is detecting VITC data. 3) We wrote to base address 0x20 and registers 0x64 to 0x77, all 0x00 so each line would be in auto-detect. 4) We wrote to the 'Blanking Control Register' ( base address 0x40, sub address B0) a value of 0x40 to enable 'pass through decoded video data during vertical blanking interval'. With the VITC data detected and V_BLANK in pass thru mode, the WFM 7100 does see VITC. Problems: Although the WFM 7100 does see the VITC information, it only sees it intermittently. We think this is because the VITC information is corrupted by looking at the data packets. Also, the VITC information is only supposed to be on lines 14 and 16. But we see it on lines 10 and 12. Also, there seems erroneous packets in each VBI line pair. We have tried writing to BLANK C_VBI (base address 0x80 sub address 0x18) to pass trhough colour as decoded during VBI lines, but it made no difference. We have tried writing to COMB_VBI (base address 0x80 sub address 0x1A) to treat VBI as Active Video, but it made no difference.
A known working script for both ADV7802 and ADV7341 would be great.
The script I thought I had was for a different mode so it will probably just be confusing. I'm attaching a few image files of what the teletext should look like.
Yellow trace = PAL input with Teletext enabled & on lines 13/14 & 20/21.
Blue trace = 7341 encoder output (with SD_VBI_OPEN = 1’b1 to pass through VBI data)
Pink trace = digital 656 output line.
All that is required (should be) to insert the ancillary data is to set ADF_EN to 1’b1. As mentioned previously this can be duplicated across both Y/Chroma channels with the toggle_adf bit. Note how the ancillary data is inserted directly after the next EAV code for a given VBI line.
Your results are significantly different than this? I want to make sure I'm understanding what you are seeing.
We are not trying to packetize the VBI data (we are not doing Video Index). With VBI infomation like teletext, VITC, closed captioning, etc, we just want to digitize it and treat this information just like active picture. How do we do that with the ADV7802?
Ahh, ok. You do not need to set ADF_EN at all then. The part will slice and decode the expected VBI data type on a line by line basis. Look at section 11.1.1 for how to get the lines you want.
After you set the lines you want, the only thing you need to do is set bit 7 in 0xB0 to '0'
In the encoder you'd need to set 0x83 to 0x14 to set VBI to Open.
I have looked in the hardware and software manuals and could not find section 11.1.1. Could you attach the document that discusses the VBI lines for digitization?
Sorry I was looking at an older revision of the hardware manual. It's 8.1.1 in the Rev B Hardware Manual.
Found it, thanks Dave! If we set each VBI line to "0000" for "Auto Mode VDP", does that mean it will auto detect what VBI data is on each line and then pass all the VBI data through?
Nope, 0000 means it'll use the default configuration for that particular line based on the video standard.
I think this is where the problem lies. For example, by default VITC is only on line 14 (525i), but we have customers that have VITC on line 16 as well. But we dont want to set line 16 restrictly for VITC because other customers have teletext that is also on line 16. Is there a way to to blindly pass all VBI data regardless of the content in each line?
What does "Custom mode 1" and "Custom mode 2" mean?
From section 8.1.1 we set all lines to '0011' for VITC for test purposes and we set bit 7 in 0xB0 to '0'.
We then passed VITC into lines 14 and 16 (analog) into the ADV7802 but the digital output is digitizing the VITC into lines 10 and 12. Is there a configuration that we are missing that causes the VBI to be placed in the wrong lines?
Not sure on "Custom 1" and "Custom 2" but I'll find out.
Do you mean at the output of the 7802 it's shifted up 4 lines or at the output of the encode?
Is everything (including active video) shifted up 4 lines or just that VBI data? You can't arbitrarily place the VBI data in a new output line so my guess is that if you programmed it for 14 and 16-- then it thinks those are 14 and 16 at the output. I presume it's your SDI analyzer saying it's at 10 and 12, right?
I meant on the output of the 7802, just the VBI data is shifted up 4 lines. We are using a SDI analyzer and it says likes 10 and 12.
I just came across 0x80 0x1A bit6 called COMB_VBI. Later this afternoon, I will set it to '1' to treat VBI as Active Video. Do you know how COMB_VBI works? If I set COMB_VBI to '1', do I still need to set bit7 of 0xB0 to '0'?
Custom 1 and Custom 2 were intended for arbitrary VBI standards which could be programmed in. There was no real demand for this though so the feature isn't actually supported.
COMB_VBI determines if the VBI data goes through the comb filter. I think if you turn it on and treat it as active data, it'll probably corrupt your data.
Is it possible for you to look at the digital outputs of the 7802 before the serialize and see what line the VBI data is coming out on. As yet, I can see no way the part could shift the data 4 lines so I think there may be something else going on here.
Never mind-- the 4 line shift is normal. If you look at the IO map starting at 0xA0-- 4 lines is default.
It's a limitation of the decoder-- a VSYNC must be output before the incoming VSYNC has been captured. For a standard format, this doesn't work so to avoid the issue the VSYNC (and VBI) is delayed.
If you use the Frame Time Base Correction, you can remove the delay though.
So is there a way the 7802 can output the VBI on the same lines that it came from? Is there a register that I could adjust the amount of delay of the frame to match it up with the vsync?
Yes-- but you have to use the Frame TBC. It's more than just a register setting. Do you have DDR in your design for that?
Yes, we do have an external DDR SDRAM (64M x 16) connected to the 7802. Do you have any guidance to how to start the frame time base correction to correct the VBI lines? I will start by setting bit 2 of 0x80 0x12 high.
I don't think there is a script for it but I believe you just turn it on (see section 7.17 in the HW guide) and then you can adjust the delay in the IO map (A0 to AF).
We have the Frame TBC on. I am trying to correct the delay with 0xA0 to 0xA5. By default, "000100" is written into 0xA0 to 0xA5.
I then wrote "001000" to 0xA0 to 0xA5, to delay it 4 more lines. But it does not seem to have an effect to my output. I then tried writing 3F to 0xA0 to 0xA5, but again has no effect. VITC is still on lines 10 and 12. I dont fully understand how to delay 0xA0 to 0xA5.
We have fixed the delay! We have VITC on the correct lines now, by taking the 4-line delay from 0xA0 to 0xA5 (we are writing "000000"). We were writing to the wrong base address eariler.
The next problem we have to fix is the VITC noise/corruption. Instead of seeing a clean/stable VITC waveform on lines 14 and 16 on our analyzer, we see some noise on the VITC waveform. I will attach screen captures tomorrow. I think it has to do with the Y shaping filter.
We are still having a problem with VBI. We found out that it has to do with "TBC_FRZ_LLC" (Base Address: 0x40; Sub Address: 0x27)
When the TBC_FRZ_LLC is enabled ("1", fixed LLC output frequency based on DDS_FREQ_MAN[24:0] registers), our SDI output timing jitter is in specifications but we have VITC discontinuity errors around every 5 seconds due to missing and/or repeated frames for 7802.
When the TBC_FRZ_LLC is disabled ("0", Tracks LLC output generated by LLC control loop), our SDI output timing jitter is now out of specifications (~1UI) but VITC is valid with no discontinuity errors.
Is there a way to have both SDI timing jitter to be in spec and VITC not to have discontinuity errors?
Sorry for the delay...
TBC is the time base correction-- using it is the only possible way to get SDI output timing jitter in spec. I think what you want is mutually exclusive so the answer is probably no. Holding LLC constant to meet jitter spec inevitably leads to missing/repeated frames if the input is jittering.
The input would have to meet SDI timing jitter specs to meet it without TBC.
It doesn't matter what the jitter of the incoming signal is.
The problem is the way the ADV7801 generates the LLC. It's deriving it from the 28.63636 MHz osc. The ADV7802 then has periodic frequency shifts because it can never exactly match the frequency of the incoming signal so it runs at a frequency that is slightly too high for a while, then changes to a frequency that is a little too slow, then back to a higher frequency. All these frequency changes result in low frequency jitter. We can watch it - it runs in spec for a while, then jumps out of spec, then good for a few more seconds then another jump. It's very difficult to clean up!
Basicly, the ADV7802 doesn't work as advertised. Specifically, it can't support VBI data and comply to ITU-R BT.656. Can you get the development team to fix it? Who do I need to talk to?
That is close enough an explanation of the way the LLC is generated. As such, you must realize there isn't anyway to clean it up to the spec you want without a redesign. Customers who want more precise clock specs use the TBC though the dropping/repeating of frames causes problems for VBI obviously. I really don't see this changing, 7802 is already an old part thought I don't believe this aspect has been changed in any significant way on more recent parts (like ADV7842).
I'm sorry it's not exactly doing what you want but I suspect that if there had been a strong business case for making this particular application possible then it already would have happened. I think you'd need to leave TBC off and do your own frame buffer / clock generator after the ADV7842 to get the VBI AND the clock jitter spec you need.
I have a question about the ADV7341 Blanking VBI on 525i. In the encoder I am setting 0x83:
to 0x14 to set VBI to Open.
to 0x04 to set VBI to Blank.
Open works with both NTSC and PAL.
Blank only works with PAL (625i 50Hz) but does not with NTSC.
Is there some other registers that I have to write to? Or is this a known bug?
Retrieving data ...