Understanding SDI video data format

[Wiljan]

Great 

Just found another power supplies discussion, here they say you can use 2 LDO's instead of 4 LDO's if you have ferrite beads separating the various power pins refer to figure 93 and 94 but I guess you wont use more time on that
https://ez.analog.com/video/f/q-a/10808/adv7391-power-supplies/28842#28842

Yes, Wiring the TVP5150 data output to the ADV7391 data input is next big step ... like a to get led flashing

I guess you still have no FPGA up running?

[Yansi]

To quote the relevant part from the link:

These sources can be generated by 2 different regulators.  Figure 94 has ferrite beads separating the various power pins to isolate AC coupling between the internal sections of the chip.  You can use 4 LDOs or regulators but 2 will suffice as long as you have the ferrite isolation.

Unfortunately their suggestion of using just 2 LDOs is pretty much incorrect, as far as my observations go. We can clearly call some  on that.

I would be glad to hear where does the difference  come from, between using extreme measures in RFI filtering (4.7uH, 1.5k bead, 220uF+10uF+100nF) and a cheap shit LDO, that has what, 20dB of rejection at 10kHz to isolate the noise? 

No, I already have both FPGA kits I have ordered! They came in few days ago. That was the motivating force behind soldering and testing the ADV7391 board.

One kit is a "full featured" one, for toying around with LEDs, the obligatory VGA and stuff with just little spare IO, the other one is just the FPGA, bunch of LDOs and a configuration FLASH.  All IOs free (except a button I am not sure what it does and a couple LEDs).

I have had a dinner, so no we move to the next quest, please standby. 

[Yansi]

I am quickly becoming confident in a few things:

a) i HATE those arduino jumper wires. Evil crap! Years ago, I have crimped those myself. Then stared buying them from china - they were good enough. Now from the last bunch, just one third of them works, yet only up to maximum of one pin insertion! Then the pin looses springiness and electrical contact (if it had any to start with).

b) without a fast enough logic analyzer, I am fuckered. And the 2 channel scope at home is not of much help either.

So, after solving a) and throwing all of the junk to the bin where it belongs and using my own crimped jumpers, I have finally managed to connect the decoder and encoder together, all signal lines.

But regarding b) I just don't know what is happening there, apart from "some bits are toggling more and some are less". 

After dicking aroung with the oscilloscope, I am quite confident that the TVP5150 works correctly and provides SAV/EAV sync. It is even that kind, that it continues to send SAV/EAV even on video loss (or no input video). This has allowed me to kind of see on the scope, what is going on. I can definitely tell, it sends 0xFF, 0x00, 0x00 and then the magic XY byte.

The XY byte contains:

Code: [Select]

MSB                 LSB
7  6  5  4  3  2  1  0
1  F  V  H  P3 P2 P1 P0
From the scope I can definitely tell, b7 is always 1 as it should be.  F gets toggled, V gets there occasionally and H bit (SAV/EAV) is correct and the whole SAV/EAV sequences seem to be places sensibly.

So the BT.656 video source works correctly, but the ADV7391 is like zero fucks given. All it does is it just keeps producing blank lines with colorburst, that are not aligned with EAV/SAV and does not generate any vertical blanking/sync.  (it does this even with just the clock present). It simply ignores the input data. WTF!

[Wiljan]

Cheap jump wires / headers and breadboard etc are often source to malfunction
I prefer to use  real header plugs and solder it to a piece of veroboard and then have normal wire soldered directly from a to b.

I did a quick look in a old TVP5154 project code and you will need to the the correct registers set to get the right data out, could you show you registers settings?

I do see I used but I recall that it was special due to I had some limitation in the TTL interface on OLED panel connected to TVP5154

0x00 <= 0x00 Video Input Source
0x03 <= 0x09 Miscellaneous Control Register, YUV output enable, Clock output enable
0x04 <= 0xC0  Autoswitch Mask, video pal, ntsc autoswitch
0x13 <= 0x80  ;-avid cropping-


I saw in another discussion on TVP5150 that one guy use
Miscellaneous Controls Register(0x03) : 0xAF
Auto-switch Mask Register(0x04) : 0xC0;
Outputs and data rates select(0x0D) : 0x40 ;
Configuration Shared Pins Register(0x0F) : 0x02 ;

Do you have the I2C so you can read write on the fly?
You can then do some reading to see that it actually are locked to the input
Status Register #1 Address 88 like flags for:  Field rate, Lost lock, Color subcarrier lock, Vertical sync Horizontal sync

Edit: Ti writes:
The only required register change is to enable the clock and data outputs. These are disabled by default to allow bus sharing with additional devices.

[Yansi]

I will probably use proper IDC headers later, currently I do not suspect a bad connection at all. I probe all signals on the ADV7391 board, nothing is missing and the signal integrity does not seem to be bad at all.

The only thing I write to the TVP5150 is the Misc Register (0x03): 0x0D.  Should be all that is needed. It just enables the clock output, data and the aux IO pins (HSYNC, VSYNC, AVID, PALI, ...) so I can trigger from them the oscilloscope.
This simple config is straight from the datasheet example for "Output format: 8-bit ITU-RBT.656 with embedded syncs", where they want you to just write 0x09 to reg 0x03.  I write 0xD insteadd so I have available the other HW outputs for triggering.

The TVP5150 works fine, I am almost certain.

I saw in another discussion on TVP5150 that one guy use

Miscellaneous Controls Register(0x03) : 0xAF - I do not need VBLK out, hence I have just 0x0D
Auto-switch Mask Register(0x04) : 0xC0 - he just enables all video modes (PAL-NM, NTSC4.43), I do not need that, now.
Outputs and data rates select(0x0D) : 0x40 - I need BT.656 encodind, hence 0x47, the default value. (0x40 is 4:2:2 with external sync)
Configuration Shared Pins Register(0x0F) : 0x02 - some additional pin conf I do not need

All I need to change from default is just to enable clock, data.  That is to write 0x09 (or 0x0D) to Misc reg (0x03).

Can not read I2C on the fly, but that is not a problem to make happen.

Edit: Ti writes:
The only required register change is to enable the clock and data outputs. These are disabled by default to allow bus sharing with additional devices.

Sure, that is exactly what I do: Write 0x0D to Misc reg (0x03)


//EDIT: Reading the status register 0x88 now, it goes to 0x66 if I apply the B&W video from the camera - so it is okay as expected.

[Yansi]

I think we do not have much options left.

TVP5150 seems to be just fine, ADV7391 is likely the troublemaker. What options we have left how to attack the situation:

a) look at ADV7391 and search for possible status registers to debug where the problem may be

b) make better wiring in between the TVP / ADV (though I do not suspect any problem there)

c) grab an FPGA kit and start working from there. Would for example help to make a SAV/EAV decoding machine to see whether all flags in the SAV/EAV are correctly transmitted.  Should not be that hard beginner project.

d) Generate BT.656 stream within the FPGA, to test the ADV7391 with.

I can certainly make b) happen and try to look into a).

[Wiljan]

Sure, that is exactly what I do: Write 0x0D to Misc reg (0x03)
//EDIT: Reading the status register 0x88 now, it goes to 0x66 if I apply the B&W video from the camera - so it is okay as expected.

Perfect: Line alternating, 50Hz, Vertical sync is locked, Horizontal sync is locked, no color subcarrier

Does the levels (on the scope) at the data bus look nice within spec for the  ADV7391 and the VDD_IO?

[Wiljan]

I think we do not have much options left.

TVP5150 seems to be just fine, ADV7391 is likely the troublemaker. What options we have left how to attack the situation:

a) look at ADV7391 and search for possible status registers to debug where the problem may be

b) make better wiring in between the TVP / ADV (though I do not suspect any problem there)

c) grab an FPGA kit and start working from there. Would for example help to make a SAV/EAV decoding machine to see whether all flags in the SAV/EAV are correctly transmitted.  Should not be that hard beginner project.

d) Generate BT.656 stream within the FPGA, to test the ADV7391 with.

I can certainly make b) happen and try to look into a).

Sounds like you need to address all 4 items to get the full understanding / confidence
 
What FPGA board did you buy Intel or Xilinx? model?

[Yansi]

Data seem to look almost too good for the style of wire in between the boards. See below.  Blue trace is the bit 0, capturing either the SAV or EAV sequence (black video generated by the TVP5150 without video input). Yellow trace is a part of colorburst that just got in the way. Data voltage level seem absolutely fine for the supply voltage (2.9V). And if you think that is too low, I have tried overriding the 3.0V regulator with external 3.3V power supply - as expected it made no difference to the behavior.

ADV7391 still ignores input data, EAV/SAV is not correlated to whats happening on the output, the ADV7391 is just free running from the bus clock, generating black lines with color burst and no vertical sync (all lines are identical: just sync pulse + colorburst)

Regarding a) I see the ADV7391 has exactly zero status registers, that would report anything useful to debug the problem as far as I see.

Regarding b) Better wiring is under way, had to pause for a lunch. Now need to find some female pinheaders and ribbon cable.

Both kits I have are with Altera Cyclone IV, EP4CE6E22C8N (6k LE, 2 PLL, 270kbits RAM, 15  18bit multipliers) . Not bad and can be sourced from china for as low as $2 a piece - almost too good to be true. I have decided to go with Altera, because I have already in the past toyed with Altera CPLDs, especially MAX3000 and MAX II so I am a little bit used to the Quartus software. But never did anything useful past some blinkenlights.

[Wiljan]

On the connection from the TVP to the ADV do you have 2 wires for Hsync and Vsync connected further than just the data-bus and the clk?

In ADV fig 51 H & V sync are negative (on PVP they are positive) it must be possible to select this instead of the EAV/SAV so if that settings are wrong the ADV might think there are no signal coming in

Table 82 use the EAV/SAV
on page 65 you can see how to use HV sync by setting reg 0x8A [2:0]


//EDIT. I do also mostly work with Quartus 

[Wiljan]

Found another board from AD using the ADV7391
https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/EVAL-ADV7282A.html?doc=EVAL-ADV7282AEBZ-UG-1174.pdf#eb-overview

They do have a script to set all registers and they set the 0x88 <= 0x00 to enable 8 bit input ...   it should be 00 on reset but it might be worth to try
Also 0x87 <= 0x20 PAL / NTSC autodetect

56 00 1C ; Power up DACs and PLL [Encoder writes begin]
56 01 00 ; Set Encoder to SD mode
56 80 10 ; SSAF Luma filter enabled, NTSC mode
56 82 C9 ; Step control on, pixel data valid, ped on, PbPr SSAF on, YPbPr out
56 87 20 ; PAL/NTSC autodetect mode enabled
56 88 00 ; 8 bit input enabled [Encoder Writes finished]

[Yansi]

Well, I do not have HSYNC/VSYNC connected anywhere, as I think it is pointless, when using embedded sync (SAV/EAV).

But I also kind of suspect, the ADV is not configured properly for SAV/EAV. Otherwise why the fck is it ignoring the data or the SAV/EAV?

Reg 0x8A is by default 0x08 in value, meaning slave mode, timing mode 0 (which seems to be SAV/EAV), at least according to page 80 in the datasheet. That should be fine.

Quartus: Great! As will likely need a lot of help. Currently no clue how to configure it for a n FPGA and never figured out how to make a VHDL testbench plus specify/check timing constraints in that piece of software. 

Also, I have made a more tidy wiring between the two boards. A piece of ribbon cable coldered in between pinheaders. So now all bus signals are alternated with GND - should make for even better signal integrity.  Yet the thing still does not want to work.

Somehow, sometimes the ADV starts capturing the data from the bus and spitting something out.  Mostly garbage. Video still not synchronized (EAV/SAV clearly in quite different place, than the output),  still no correct vertical sync on the output.

See below.

[Wiljan]

How does the signal from the scope look on a TV screen?

[Yansi]

I unfortunately do not have any physical TV with a CRT. I have resorted to using a professional video scaler (TVone C2-2350) to convert anything to a standard PC monitor.  And with the video signal missing any Vsync, the scaler just tells me to fuck off with a "not valid" signal comment.

So it seems I have likely found out why it did not work. The IC has a dead or stuck bit2. Absolutely no clue as to why.

As a last weapon of choice, I have resorted to really test all inputs to the ADV, using reg 0x13, the data bus readback. I have gone bit by bit, all responded correctly, except b2. Stuck at logic 1.

It was not a soldering issue. I have seen clearly the pin is correctly soldered to the pad.

Then I swapped to the original IC, I've had on the board the first time, as I was scared it got fried due to the strange current draw and DAC1 at  2.6V. But this behavior is normal, that the IC just wastes power after (and during) reset.

The other IC can read all bits correctly, and after enabling the data bus on TVP5150, I got results immediately. It seems to be working.

Not a clue what might have happened to the b2. Manufacturing defect? I would not say that is probable.

One thing that pisses me of with the TVone scaler, is that a) it seems not to accept B&W video, needs colorburst to work (holysmokes, what an idiot...) and b) it is not very timing tolerant. As a freaking universal scaler, which boasts the functionality to convert anything to everything, but can't accept PAL video, that is off by 0.02%or 200ppm (holysmokes...  )

It is evident, that when I feed the TVP5150 with a video from the B&W camera, the scaler just quits working, cause the camera is 0.02% out of spec, because it has garbage timebase inside.

Luckily, I have different scaler and can make a different PAL source using a second scaler. So I'll just do that in a moment to see where does that leave us.

//EDIT: From the scaler specsheet - the only thing I can find about frequency range.

CV/YC sub-carrier lock range: +/- 200Hz for NTSC Operation, +/- 250Hz for PAL Operation

The camera produces 27.0056 MHz clock,  meaning the color subcarrier is likely 921 Hz off. Fuuuuck! Thats just retarded.

[Yansi]

So I have swapped scalers around. Feeding my monitor from TVone C2-770 (an old boat anchor). Now the C2-2350 is repurposed to make me a reference video, from HDMI computer output.

I can verify, that with the encoded PAL signal bypassed from one scaler to the other, I get correct video on my monitor. So both scalers working, configured correctly for PAL/50Hz.

Now, when I plug in the video path my decoder-encoder contraption, I get video through, but...

We have some color encoding/decoding issue. Luminance seems to get through correctly, but chrominance is fuckered. I get some flashy colors.  It seems as if the Cr and Cb got swapped every other field.

Switching the ADV to generate color bars produces stable color bars. So there still must be an issue on the data bus. TVP and ADV still can't talk to each other very successfully.

But what the hell may still be wrong?

Code: [Select]

The actual exact config is this:
TVP5150
0x03 <= 0x0D
ADV7391
0x17 <= 0x02
0x00 <= 0x10
0x01 <= 0x00
0x02 <= 0x20
0x80 <= 0x11
0x82 <= 0xC3
0x8C <= 0xCB
0x8D <= 0x8A
0x8E <= 0x09
0x8F <= 0x2A

//EDIT: TVP5150 reports  status 0x6E, so color subcarrier is locked. Likely not a problem on that side.

[Wiljan]

Great, when I saw your scope image I was confident that there were some signal in it

Yeah most scalers and converters are pretty sensitive to out of timing signals

Could you post a image of the problem you see on the screen?

You said you feed a B/W camera aka no burst but still get info that burst are detected so it might send wrong color info.

Please test only with normal PAL signals with color in just to be sure it is not found as a Y/C signal

If the colors are swapped Cr Cb, can properly be coursed by by several reasons.

It can be the TVP receiving PAL but running as NTSC /Secam or a wrong PAL mode or the BT656 set to a wrong mode the same can be tre problem in the ADV

And as you say wrong subcarrier freq.

At least you have some progress, 

[Yansi]

Incorrectly understood! BW camera now back in the drawer, PAL video source is now from a scaler, that is converting HDMI to CVBS. So I have a full color PAL signal, with required timing precision.

Not sure what could cause the flashy color. Please see video of the problem below:

[Wiljan]

I would say the the decoder TVP does not lock to the bust comming in

TVP5150
0x03 <= 0x0D
0x04 <= 0xC0  Autoswitch Mask, video pal, ntsc autoswitch Try play with the values here

0x28 set the video standard could be worth to try them all

0x8C tells the status for the video standard detected


https://e2e.ti.com/support/data-converters/f/73/t/118315?Need-guidance-on-Register-settings-for-TVP5150 kind of same problem

They talk about wrong clk edge and filter for the input
the sequence YCbCrYCbCr I don't see anywhere how to swap them on the TPE
but on the  ADV you have YCbCr and YCrCb
0x01 set it to YCrCb
0x88 set it to YCbCr

but it might be typo in the pdf

[Yansi]

0x8C is 0x83, which means autoswitch mode is active and that "PAL (B,D,G,H,I, N) ITU-RBT.601" is detected. Which seems okay.

0x04: If I unmask all formats (write 0xC0), the autoswitch still chooses and reports as above.

0x28: Only forcing PAL (BDGHIN) or "combination N" works, yet chromaticity is still not working.

Just an interesting observation: The colors do not flip in between fields, but it seems between lines. I managed to capture this, the color carrier amplitude is fluctuating, even when observing a still image. Wtf?

Huh, isn't the PAL colorburst supposed to reverse its polarity in between lines? Seems like a good clue where to look. Like if the decoder would ignore this and not be properly locked on the colorburst.   

Sure, no way to change YCbCr to YCrCb. I think it is a typo, the BT.601/656 shall be clear about the sequence of bytes.

//EDIT: Just found this: https://e2e.ti.com/support/data-converters/f/73/t/701610?TVP5150AM1-TVP5150AM1ZQC-problems-PAL-colors-blinking-
Will investigate into that.

//EDIT2: Crystal oscillator seems pretty stable. Only wet finger across the crystal pins can really kill it. Does not give a rats ass abotu connected probe on either pin. Even tried 100k parallel resistor - no change, still flashy colors.

[Yansi]

Image flashes like this, this one going in between blue and green. Not expert on PAL signal, but doesn't it somehow correlate to the color subcarrier phase?

[Wiljan]

Seems to be many discussion when you search for TVP5150 color flicker
eg https://e2e.ti.com/support/data-converters/f/73/p/357945/1256934

Do you use te TVP5150AM1?

Do you have a resistor on pin 27? The TVP5150AM1 needs a resistor on this pin at reset (see figure 6-1 in the tvp5150AM1 datasheet). This will stop the color shifting issue.

[Yansi]

Yes, I think I have the newer AM1 version. Will investigate into that. I have pull-up on the INTREQ/GPCL/VBLK pin, as I have intended to use the IRQ functionality. But sure enough, it is not configured now.

So let's see what it does if I configure it to IRQ.

[Yansi]

Okay, so I have modified the Misc reg 0x03 to 0x2D value to enable the IRQREQ/GPCL/VBLK pin.
Reg 0x0F then selects between the IRQ an GPCL/VBLK function, but is default at IRQ mode. So I did not modify it. Still just writing only the misc reg 0x03, now with the value above.

FUCK ME! It works now.  Now tell me, what is the retarded problem, that it does not sync to color, when this pin is not enabled? Like WTF?!!!!!! 

So many thanks to you for helping me troubleshoot these two devices and thanks for the mental support during this fight.

[Wiljan]

This is great NEWS 

From the last link

If this pin is not set correctly then the internal color PLL DTO does not function hence color shifting occurs.

The external resistor configures the internal processor to use the internal DTO for color demodulation.

Yep a couple of crazy problems, but now you can check-mark items a) and b) and start working on c) and d) and the fun part with the FPGA and then later move toward the SDI which where it all started

[Yansi]

Sure, but how does a color demodulator relate to a pin that either: Sends interrupt requests (IRQREQ), functions as a general purpose output (GPCL) or serves as vertical blanking output (VBLK)?

In all of these modes this pin is OUTPUT.

It seems to me that this is more like a bug in the TVP5150 design, or it serves other undocumented purpose (most likely... )

I have found round the web, there are quite a lot undocumented registers in the TVP5150 as well. 

Yup, now that the ADV and TVP are working, we sure can proceed to the FPGA. I need to at least try to create a new project for it in the Quartus.

Here you have the whole lovely contraption in all its parade