22-05-2020, 10:31 AM
The SAA7118 decoder chip I'm using should be doing all normal clock generation in 405, just as in 625. AGC is running as normal too. I'm taking digital video direct from the ADC rather than after processing and doing my own field sync separation.
I think the clock generation is quite sophisticated. In colour there's a fairly complex digital PLL to get stable subcarrier back from all sorts of iffy inputs. It must also be sufficiently good to do comb filtering where the source has correct SC-H frequnecy relationship. Actual processing will be done at a multiple of pixel rate, not directly SC locked. I don't know how it makes 27MHz clock fromt he video input. Definitely not a simple PLL. The xtal is fixed frequency and everythng must derive digitally from that. I wouldn't be surprised if the xtal was mutliplied up to over 100MHz within the chip.
Some decoder chips such as the Techwell TW2814 take an external 27MHz clock (or xtal) and the video output is locked to that. This implies that the line length isn't a fixed number of pixels. No problem if you're going into a framestore. There must be something clever going on in the digits to align the sampling grid with H sync datum. Probably one or more FIR interpolators to move the picture by fractions of a pixel.
I know that you can use an arbitrary sampling clock, not aligned to H sync, to sample a video input. Then sort out everything in digits, including reconstructing a square or rectangular sampling grid. The Techwell chip must do this. A crude approach is to sample at a sufficiently high frequency that an error of 1 pixel is not visible. Then ignore the very slightly jagged verticals. Won't work for colour but I've certainly thought of it as an approach for 405. The H sync datum would need to be extracted digitally, ideally by a correlator which is built a bit like an FIR.
I think the clock generation is quite sophisticated. In colour there's a fairly complex digital PLL to get stable subcarrier back from all sorts of iffy inputs. It must also be sufficiently good to do comb filtering where the source has correct SC-H frequnecy relationship. Actual processing will be done at a multiple of pixel rate, not directly SC locked. I don't know how it makes 27MHz clock fromt he video input. Definitely not a simple PLL. The xtal is fixed frequency and everythng must derive digitally from that. I wouldn't be surprised if the xtal was mutliplied up to over 100MHz within the chip.
Some decoder chips such as the Techwell TW2814 take an external 27MHz clock (or xtal) and the video output is locked to that. This implies that the line length isn't a fixed number of pixels. No problem if you're going into a framestore. There must be something clever going on in the digits to align the sampling grid with H sync datum. Probably one or more FIR interpolators to move the picture by fractions of a pixel.
I know that you can use an arbitrary sampling clock, not aligned to H sync, to sample a video input. Then sort out everything in digits, including reconstructing a square or rectangular sampling grid. The Techwell chip must do this. A crude approach is to sample at a sufficiently high frequency that an error of 1 pixel is not visible. Then ignore the very slightly jagged verticals. Won't work for colour but I've certainly thought of it as an approach for 405. The H sync datum would need to be extracted digitally, ideally by a correlator which is built a bit like an FIR.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv
