Understanding SDI video data format

[Yansi]

Hi! Little bit update, something bit more positive during the 'rona thing: PCBs arrived, soldered, I2C comm tested - successfully - to my all surprise.

Well, there was a bit of an ouch! moment during the first power up. The board consumed 47mA uninitialized, just after applied power. I have noticed, most of the current has gone through one of the DAC loading resistors.  2.6V was on one of the outputs. So I have panicked a bit, started to measure all around, poke my meter everywhere I could - found nothing. Suspecting a dead IC or poor soldering of the LFCSP package, I desoldered the IC just to see the soldering was perfect, no cold solder joints on any pins.  So I have soldered another chip, while making sure wearing a poker face (look at the cost of the ADV7391. Ouch too!).

New chip soldered, same behavior. That got me curious. Grabbed an MCU kit, wired the I2C, asked for the content of the first register I came across - device responded on correct I2C address, returned the correct default value of that register. Then checked another few registers - all correct values.

I have noticed, that 47mA are still consumed even when the ADV7391 is held RESET,  the DAC1 still spews maximum output voltage. Then I have examined the content of the "0x00 power status register". Sure enough, default is 0x12, DAC1 enabled.  So I have disabled the DAC1.  Now zero volts on all outputs, little current consumption.

WTF are they smoking and why would it put full  output blast as a default, even when held reset, is beyond me.  Sure, I do not provide any PCLK to the video interface, but this is strange behavior anyway.

Once I read through all those 100 or more registers and configure the mandatory of them, I will feed in some video data and test if it actually works.

[Wiljan]

Nice work, yes the great test will be to hook it up to your decoder board and see signal loop through, and then via a FPGA 1:1 for starting 

[Yansi]

Well, sure, that would be a success! However currently it seems to be more or less a nightmare.

I have found the ADV7391 has a builtin black and colorbar generator.  So, trying the color bars - we have some major issues with signal purity. Something is injecting awful noise to the video output.

Looking at the output waveform using an osmelloscope, there are numerous places per line where quite substantial sharp edges occur during the active video.

Looking at a video monitor, looks like below. Positions of the occuring garbage is well correlated to the garbage on the screen.

Not any clue what this may be causing. Power supply should be solid and at specified voltages. I am just feeding in a 27 MHz reference clock (generated by the TVP5150 module). 

It seems there may be an issue with the PLL in the ADV7391. If I gently touch the loop filter components, I can clearly influence the garbage injected to the output.

I admit the layout is not the best and it is just a 2 layer board. Even 4layers would not help much, as the datasheet suggested layout procedure is (tl;dr) just to put  everything as close as possible to the chip. But for fucked snakes that is simply not possible, unless using 0201 components or what.  The layout with the three loop filter components circled is also below. I could not come up with any better than this.  All power supply pins are decoupled separately, using a 100n+4u7, with a ~100ohm ferrite bead in series.

//EDIT: Well, it may be a power supply issue after all? Placing a 47 mike electrolytic cap at random places has significant effects on the garbage production.

[Yansi]

I am starting to hate this piece'o'crap IC.  Looking at the EVAL board ...  I have even tighter layout in places (for example the loop filter).  I have the critical decoupling even on the same side as the IC - they have placed all decoupling on the bottom side, through vias.

Sure, I have not used the crazy capacitor combos of like "100pF 1nF 10nF 100nF 10uF" all in parallel - I've been taught that this may be even worse than a single or two in parallel.

Also, seems the board radiates like crazy somewhere above 80MHz. Likely the PLL output frequency.  Looking at the EMC filtering components deployed at the EVAL board assures me this IC in fact is pure evil to use. 

I have played a bit with the ferrite beads, even replaced them with shorts. The garbage just changed and moved around.

I better find a different IC, that doesn't require black magic to work reliably. There are many things time can be better spent on than tweaking this thing to no end.

[Scrts]

We are successfully using this encoder in automotive designs. Does the color bar generate good output on your screen using the same cables? I'd suspect an issue with impedance or cable length here as well...

[Yansi]

Although I have used a 50ohm BNC cable (was the first to reach), I seriously doubt it has any kind of an effect whatsoever, with the length of a meter (~3ft). But sure, I can swap it for 75ohm one. (Seriously doubt anything will change).

The crap comes from the board itself, not from the cable. Even probing the boards output with an osmelloscope shows the same garbage spikes throughout the video line - corresponding to what the video monitor shows.

If you could look at my board please and tell whats that much wrong in there - many thanks!  Layout is above, schematic attached below.
Currently I am either overlooking some dumb mistake, or I don't know what.

Note to the schematic:
Output low pass filters not soldered (L4=L5=L6 = 0ohm),  R2 is 180 ohm instead of 170. (also quite doubt it makes the difference).
Now I have even tried to solder the loop filter even tighter together - nothing has changed. So it seems, it is not a problem with it.
The 1V8 LDO is cheap garbage, sure, but I think well suited for the task. The load on it should be quite minimal. PLL VDD draws about 4mA, the logic supply VDD should draw about 33mA (one DAC enabled only).  The regulated voltage is 1.813V. Also within spec.  VDDA and VDDIO are at 2.9V, which is also within spec. Using an external supply to put stiff 3V3 there helps nothing, no change.

Or is there anything wrong with the configuration? Here are all registers I have written the value into:

Code: [Select]

register, value, comment
0x00, 0x10, DAC1 enabled, PLL on
0x01, 0x00, SD mode only
0x02, 0x20, YPrPb output mode
0x80, 0x11, SSAF luma filter, PAL
0x82, 0xCB, SSAF filter enable, CVBS output select
0x84, 0x40, Color bar output enable
0x87, 0x20, NTSC/PAL autodetect

//Cable already changed to 75ohm 1m piece, no change, as expected).//

[Yansi]

Awww! Found out the PLL does not need to be turned on. So I've switched it off (0x80 <= 0x12) and voila, we have a crystal clear color bars.

So it is the PLL after all?

[hamster_nz]

Had a look at the sample design in the data sheet - The example decoupling is 0.1uF + 0.01uF on most rails, and 0.1uF + 0.01uF + 1.0uF on the 3V3 rail.

You have mostly 4.7uF + 0.1uF - maybe that is where the issue is coming from? Is it worth trying replacing a 4.7uF with a 0.01uF on PVDD that supplies the PLL?

(Decoupling isn't my strong point... more interested in hearing the reason for parts selection)

Only thinking this because I've seen so stuff on Twitter about noise on the PLL supplies causing all sorts of weirdness.

[Yansi]

Well... as far as I know, a ceramic SMD cap can not have much inductance past its physical length.

This random internet image seems to confirm. If the inductance would be different per capacitance value, the right side of the plot above the resonant point would not agree in the steepens. Yet they all agree, so the should have about the same inductance:


I have used 4u7 because it is the largest value in 0603 I have. (I have even tried soldering another one on top to get more capacitance in there, but no luck).

I have even hacked the board, making the loop filter even tighter. Even tried adding 10nF to the PLLVDD as close as the bodge allowed. No substantial improvement. The crap just moves around, but will not disappear.

I have even moved the 2n2 "COMP" cap for the DAC to this new position, as below. No difference whatsoever. Crap still present in signal.

//EDIT: Forgot the image.

[Wiljan]

register, value, comment
0x00, 0x10, DAC1 enabled, PLL on
0x01, 0x00, SD mode only
0x02, 0x20, YPrPb output mode
0x80, 0x11, SSAF luma filter, PAL
0x82, 0xCB, SSAF filter enable, CVBS output select
0x84, 0x40, Color bar output enable
0x87, 0x20, NTSC/PAL autodetect

Awww! Found out the PLL does not need to be turned on. So I've switched it off (0x80 <= 0x12) and voila, we have a crystal clear color bars.

Great to hear you have to work 

I think you  need to be absolutely sure it's the correct registers you set in the pdf https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7390_7391_7392_7393.pdf

There are some differences to what you refer to 0x80 <= 0x12 which I guess must be 0x00<= 0x12 means DAC1 on and PLL off ( This control allows the internal PLL
circuit to be powered down and the oversampling to be switched off x16)

So I think the PLL still runs but not as 16x

In the pdf there are on page 92 and forward examples what registers should be set for what depending what you what to get out

[Yansi]

Sure,  I meant 0x00 <= 0x12, not 0x80.

I did not use these tables from the datasheet, I downloaded some software packages for the eval board and reverse engineered some configuration scripts for the board. 

So, the most relevant table for me is Table 82. So lets compare, what there is different:

Table 82 wants this:


So, first difference, is that I do not do a software reset.  Is it any different from a HW reset? But I can add it there.
Second difference is that they enable all DACs. I do not want/need that. Likely not a problem. They leave PLL running!
Third difference is register 0x82. They want 0xC3, I have 0xCB.  I have enabled the pedestal. As they do on their eval board. (But PAL should not use pedestal? Not sure, still it wouldn't produce the crap I am seeing, as the pedestal stays put even with PLL OFF, where it works just fine).
Fourth difference: I enable color bars in 0x84 register.
Fifth difference: I enable PAL/NTSC autodetect in 0x87. As observed from the eval board scripts. I still don't see a problem.
Sixth difference: I forgot to set the subcarrier frequency registers.

That of course may make some difference.
I have also just noticed, the scaler I run the video through to my monitor reports the video is NTSC, even though I should get PAL.

So lets fix the subcarrier frequency first. 

//EDIT: Subcarrier fixed, standard autodetect removed. Now it produces PAL/50Hz output.  Crap still present in the image. So we are still where we were before. Crap in image output, only  NTSC got fixed to the proper PAL.

[Yansi]

Finally I have saved a screen from the scope, as to what the signal integrity problem looks like. There are these awful spikes, mostly concentrated to the places corresponding to the crap seen on the video monitor.

[Wiljan]

Yep table 82 was the one I would go for as well ...
For only 1 DAC have 0x00 <=0x10 instead of 0x1C you see both in the table

I would do the soft reset as well

Regarding to the noise, you mention you get the 27Mhz clk from the other board, om page 5 you have INPUT CLOCK SPECIFICATIONS
It could be worth to check with a scope if you are within the spec (levels)

VDD = 1.71 V to 1.89 V, PVDD = 1.71 V to 1.89 V, VAA = 2.6 V to 3.465 V, VDD_IO = 1.71 V to 3.63 V

If you overdrive the PLL input it might do something wrong to the PLL
The TVP5150 are running from a 14.318 xtal between Xtal1 and Xtal2 pin , which pin do you have the 27Mhz out on?

[Yansi]

I use the 27MHz CLK output from the  R.BT.656 output data bus. it provides a pretty precise 27.0000 MHz according to the counter in my scope.

Not even close to sure, how the TVP5150 manages to obtain 27MHz from those 14.31818 MHz crystal.  There is 27 MHz present even if there is no video signal present to the TVP5150.

The only thing I could test is to grab a 27 MHz crystal and make a standalone clean oscillator to feed the ADV7391. To rule out the 27MHz clock from the TVP5150 decoder may be full of crap (it does not seem so, from looking at the clock on a scope).

What is interesting, is that modifying the decoupling on the 1V8 rail on the PCB has an effect on the crap spikes.  But it always just moves around, instead of being suppressed.

I will try a few more things with the 1V8 regulator and decoupling and then will look for ways to obtain a clean 27 MHz clock for something.

Also I bring to mind, that when the PLL in ADV7391 is switched OFF (no oversampling), the output video signal is crystal clear, with no glitches.

[Yansi]

Awww we are getting somewhere!

I have left the on board LDO to power just the PLL.  The VDD logic is supplied from an external lab supply. IMAGE IS CLEAR! Even with the PLL enabled. So what the hell is going on there?   

[Wiljan]

Could you post your acual schematic?

[Yansi]

Could you post your acual schematic?

I have already done that! Including the layout. See post #55 and #52 above.

I can only add, that originally I have used a ferrite beads from TDK, 1.5k @100MHz (MMZ1608Y152BTA00), now I have switched to Tayo Yuden 600R @100MHz (FBMH1608HM601), as these should be better at suppressing higher frequency crap. But the change did not help.

Now there is ferrite bead only on the PLL (the 600R Tayo Yuden) and  on IOVDD (there may be even the 1.5kR TDK? not sure).  The DAC is supplied straight from 3V, no ferrite bead. The 1V8 VDD is currently also no ferrite bead, straight from a lab PSU.   Sorry for this mess, but I have tried to trace the issue by swapping a lot of components and toying with the decoupling/filtering.

//EDIT: I think the next step will be to return the board to its original form (so it will be precisely as the schematic), remove all bodges, except the external logic VDD 1V8 supply. I am interested to see as what it will do.

[Wiljan]

Sorry miseed the schematic. 

If you look at this eval board http://media.digikey.com/PDF/Data%20Sheets/Analog%20Devices%20PDFs/ADV739x_EvalBrd_RevB.pdf

Page 32 + 36 then you will see that they have

Analog supply as 3.3V
PLL supply as 1.8V
Digital supply as 1.8V  (you have 3.3V)

So try to run the VDDIO from the 1.8v reg but you will properly need to separate it to a different regulator

btw they also have the PCB layout

[Yansi]

So the board is in its original shape, all components the value exactly as specified in the schematic, all ferrite beads TDK 1.5k @100MHz (MMZ1608Y152BTA00). All parts soldered at their respective footprints, bodges and hacks removed, except the external 1V8 supply for the VDD pins. (external suppply injected at the place of L2 on the board, L2 not used, unpopulated)

It seems to work, reliably even in this original state (except the external VDD supply).

So what the hell is wrong when both PVDD and VDD is supplied from the same LDO?  VDD consumes about 36mA which is in accordance with the datasheet. No excessive draw.

Here is the current layout and current schematic, for clarity added again.

//Why would I run VDDIO from 1V8 if I want to interface with 3V3 logic?  The recommended range for VDDIO is from 1.71 to 3.63V.  I a within spec.
To be exact, as measured on the board:
VDDIO = 2.886V
PVDD = 1.811V (from the onboard LDO)
VDD = 1.767V (from external lab PSU)
VAA = 2.867V
That is well within the spec.

[Wiljan]

Hard to tell what is wrong, but I guess when the PLL runs it makes noise on the PVDD and that's why the official eval board use 2 LDO's for the same voltage.

I haven't found any specific in the ADV7391 pdf telling it has to be separated but since there are 2 individual pins on the chip there must a reason, just add an extra LDO on the board

[Wiljan]

on page 18 it says ABSOLUTE MAXIMUM RATINGS:
VAA to AGND −0.3 V to +3.9 V
VDD to DGND −0.3 V to +2.3 V <=Here you can't have 3v3
PVDD to PGND −0.3 V to +2.3 V
VDD_IO to GND_IO −0.3 V to +3.9 V <= here it should be fine if you want to have io on 3V3

Btw your 3.3V  are pretty low 2.9V

[Yansi]

I haven't said there are 3V on VDD. That was you

Well, I power the setup from STM32 kit, that operates from a 3.0V nominally. The 2.9V is the result of the crap arduino wires, having some voltage drop across them.

Would be interested to know, why one can't do around with a single LDO. If the IC is so much noise susceptible, then I'd simply say it is a rather poor IC design.    I understand, when a multi GHz synthesizer with many tens of MHz per V tuning slope VCO may have an issue with noisy PSU, but this thing?

[Wiljan]

I take that the 3.3V was my assumption 
There is a engineer zone here https://ez.analog.com/video/f/q-a/5588/adv7391-vddio-question

One guy are discussing the VDDIO and the answer back are:

No this is not an error in the datasheet. VDD_IO can be operated at either 1V8 or 3V3. When operating at 3V3, the voltage limits are between 2.97V to 3.63V and when operating at 1V8 the voltage limits are between 1.71V to 1.89V. This is why the max/min ratings in the datasheet for this supply have the wide margin. The caveat with running the part @ 1V8 as opposed to 3V3 is that the I2C, HS and VS signalling all need to be operated at 1V8 levels. See P8 of the ADV7391 datasheet for more information regarding this.

So if you supply is 2.9V then the data level might be a little less and you might have issues with correct function... just saying
Also it might be possible to ask at that webpage to get an answer for the need of 2 LDO's

[Yansi]

That is some interesting bullshit going on then. They specify the VDDIO range from 1.71 to 3.63V and the tell you "ah, you can't use 2.5V", but it is not a datasheet error? 

But back to my problem -  the exact voltage on the VDDIO (and VAA, I have both tied to the same "3V3" input) has zero effect on the crap generated.

It seems either the IC is extremely susceptible to noise on PVDD (which, again, leads me to believe the PLL has sub-par design), or that the LDO I have used is not up to the task.

Sure, the Torex XC6206 is cheap crap, but this IC is the first one having problems with it.

What LDO should one use then? Another $5 job for a $10 IC?  For this price they could even include suitable LDO for the PLL themselves.

I am not sure if asking would get us anywhere, or what should I exactly ask for.  The datashet says quote: "Power Supplies:
It is recommended that a separate regulated supply be provided for each power domain (VAA, VDD, VDD_IO, and PVDD)." So in fact I should have used 4 separate LDO. Fück dich!

I have tried a while back to filter the VDD domain using a series connected small 4.7uH, ferrite bead, then placed a 220uF elko, 10uF MLLCC + 100nF parallel. The shit still spews crap on the output.

Now you tell me, is the IC poorly designed or what, if this is not enough, to get the crap out?

As a last measure, exhausted and defeated by a a rather poorly designed ADI product, I will try to bodge separate LDO on the board.

[Yansi]

I have bodged in second LDO (the same cheap XC6206), found a good spot for it on the board. Fortunately, this hack works a charm. I take this lesson with a grain of salt. Due to really not liking the idea of multiple LDOs and due to the fact I am not sure what was the problem - apart from knowing how to solve go around it.

Onto the next quest: Wiring the TVP5150 data output to the ADV7391 data input.