405 to 625 conversion

[Refugee]

The scope waveform looks like the jitter is at a quarter of the frequency of the waveform.

[ppppenguin]

The clock input to the decoder is being made with a DTO so there is an inherent jitter of one cycle of the master clock. In my work the master clock is 108MHz and the feed to the decoder is about 16MHz. The jitter is about 9ns. I haven't looked at the clock out of the decoder. This may or may not suffer from the same jitter but it doesn't matter on my design because of the framestore.

Actually there may well be jitter in the sampling of the 405 input but at 9ns this won't be visible. When I was doing 625 to 405 conversion I made the output lock with a DTO and this also had 9ns jitter. Again entirely invisible.

[`FRANK.C]

Hi Refugee
The waveform does have a pattern to it. When the clock frequency feeding the video decoder is changed the pattern does not appear to change.

Hi Jeffrey
In this case the clock driving the video decoder is produced by a PLL and to give it the best chance leaves the FPGA via a designated PLL output pin. so is clean. I scoped it just to check.

A clock of 9.272876 MHz which is close to 9.27818064MHz wont work. I have to go down in frequency to 9.264706 MHz to get it to work.

The jitter in the video clock as far as I can tell cant be seen on the picture. But what may be a problem is I derive the clock for the output of the converter from the video clock and the PLL may not like the jitter.

Frank

[ppppenguin]

I suppose that's where I have an advantage. Because I have a framestore the input and output clocks can be completely separate. On Frank's linestore design (and Aurora SCRF for that matter) the output clock has to be derived from the input clock. I have a 54MHz xtal which I double to 108MHz in a XIlinx DLL. For 405 out I use a DTO to provide 27*(405/625) for all the output logic. For 405 in I use a DTO to give 24.576 *(405/625) for the SAA7118 decoder chip. I haven't even looked at the clock output of the decoder to see if the SAA7118 has passed or suppressed the 9ns jitter.

[`FRANK.C]

Success of sorts.
I have used a PLL to double the video clock frequency. This is used as the oversampler clock in the output of the converter.
It works but not consistently. I may have to power cycle a few times to get it to lock. When it don't lock the oversampler clock is clearly at the wrong frequency most likely due to the PLL not locking properly to the jittery video clock.
When it does lock it works very well. No jitter and the decoder does a very good job of decoding the 405 video. I cant see any degrading of the decoded video when compared against the original.

I am using the odd/even from the LM1881 in conjunction with the SAV signal from the embedded syncs to produce the frame sync which gives a solid lock with no jitter.
The odd/even from the LM1881 on it's own probably wouldn't work so well as it would be a async reset and probably cause some jitter.

Photo below of the 405 output.

More to try.
Frank

[ppppenguin]

Got back to this today. While the H sync from the decoder is fine, the V sync is definitely not. This accounts for the bad interpolation and horrible movement judder.

I took a closer look at the sync pulses available at various pins of the SAA7118. The V sync is a strange pattern of some pulses correctly timed and others that are part way through the field. I thinkt he whole thing is repeating on a 3 or 6 field sequence. The odd/even is even stranger. It's 60ms and 60ms down as far as I can tell.

Not unexpected I suppose. The SAA7118 has nothing that knows how to handle a 405 line signal. It's a miracle it's doing as well as it is. There are 3 lines of attack:

1: Ferret through the squillions of settings in the chip to see if anything helps. Probably a fruitless search.
2: Give up on a pure solution and add a LM1881 to do the V sync sep.
3: The SAA7118 has some settings that allow the raw data from the ADCs to be passed to the output. Assuming the syncs are digitised (and they ought to be for the rest of the chip to work) I can do the sync separation in the FPGA. Simply slicing at a particular digital level may not be ideal but it's a first attempt.

This last is most promising. The SAA7118 is doing clock generation, probably the most critical part of the whole input system. Though I'm probably going to lose the benefits of oversampling in the ADC as I don't have anything like enough resource in the FPGA to do a decent decimation filter. That needs multipliers and the XC2S200 doesn't have any. Each one would have to be synthsised and they take a lot of logic.

[`FRANK.C]

Hi Jeffrey
Great stuff!
It's interesting that you can get the raw ADC data from the decoder and where that might lead.

I have started on a new path. I have another board ( the one I did the modulator experiments with) and when I made it I fitted two AL422 framestores as I had them left over from the earlier stages of Hedghog.
Initially I had discounted using this board because it has only one pin that the PLL's in the FPGA can be accessed with. A 50MHz oscillator was originally using this pin and I removed it and connected the decoders video clock to it. But now I needed the 50 MHz oscillator to derive the 9.264706 MHz clock for the decoder. Then I realised that the video clock wont be connected to a PLL so any pin will do for it.

I have refitted the 50 MHz oscillator to the development board  and connected the video clock to another pin. I have removed the 14.31818 MHz crystal and load capacitors from the decoder. Connected the decoder Osc. pin to a FPGA pin.  I have the LM1881 mounted on a bit of veroboard. Just have to start writing the VHDL.

With the AL422 I will need some dual port memory to do the interpolation. There is plenty in the FPGA.

Frank

[ppppenguin]

Frank, looks like you're doing some good work there.

I've found a few registers in the SAA7118 that vary the timing of field and frame pulses. I'll have a play with them later.

[ppppenguin]

The registers that play with vertical timing aren't any use. The fundamental V and F sync separation just doesn't work well on 405. There's a plausible looking V sync pulse. Alternate pulses are in the right place and somewhere totally wrong. I could cope with that and gate out the unwanted pulse. Except that when you disconnect and reconnect the 405 input it's random whether the good pulse is on the odd or even field. I can't see any way at present of reliably discriminating between odd and even fields by purely logical means.

That leaves passing raw ADC data to the FPGA or using a LM1881.

[ppppenguin]

I think I've cracked the tricky bit. Getting reliable syncs separated from the 405 line input.

H sync is easy enough. The SAA7118 does a good job of this. I've routed it out through an auxiliary pin directly to the FPGA. V sync and odd/even field were much harder. The SAA7118 does a lousy job of these. I couldn't find a way to utilise any pulses from the decoder. Fortunately the ADC's output can be connected directly to the digital video output pins. AGC and black level clamp has already been done in the SAA7118 so I can separate the syncs simply by slicing at a suitable threshold. Then it's pretty much routine logic to separate V sync and odd/even pulses. This now all works.

There's still detailed work to be done. The horizontal alignment has gone wrong. Not a big problem, I'll make it adjustable for now. Also the interpolator is still giving ragged edges. Don't know if it's the interpolator itself or some bad timings.

I am now certain this will work properly.