405 to 625 conversion

[`FRANK.C]

The TVP5150 has a VCR mode.
In both Hedghogs it is in automatic mode

While doing 405>625 it is forced to VCR mode. To be honest I don't think forcing it to VCR mode made any difference.
I think the problem is you cant depend that it will work as normal while it is been clocked at a frequency that it is not supposed to run at.
A place that this is clearly seen is in the analogue channel AGC. It had to be turned off while doing 405>625. If it was left on the gain would keep increasing until everything became whited out
While doing 405>625 there is very little left running apart from the ADC.

Frank

[ppppenguin]

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.

[Mike Watterson]

I didn't know that SIS had implicit timebase correction. I remember the revelation of first having a TBC (a CVS517) available in a small studio, c1976. Seemed miraculous.

Yes, it was about then. I've no idea why or how the SIS box worked (rack mounted), but I saw it working. I'm not sure I actually ever saw a TBC!

I'd guess Ampex measured a lot of doorways before finalising any Quadruplex, or were there earlier ones that needed bigger than usual doors?

[ppppenguin]

The original VR1000 (first ever quadruplex VTR, hence first ever practical VTR) deck was massive. The rest of it was only standard 19" rack cabinets.

[ppppenguin]

Francis (Spot Wobble ) came over this afternoon with some 405 line VHS recordings. The idea was to evaluate my 405 to 625 converter on more awkward signals. Glad to say that the H lock was excellent. I don't have too much control over that. The V lock was suffering because various splats on the signal were being interpreted as V sync.  I do the V sync separation myself from digitally sliced sync. I'll need to beef up the logic so that it only accepts a V sync pulse in a tight window after the previous one. Either that or invent some kind of vertical flywheel sync. One trick will be to ensure it can lock in the first place. Another trick might be to do a sort of integrator which will only flag a V sync after a few broad pulse have been identified. This might fail on a CV2000 recording which I think has a single long field pulse.

The existing V sync separator is the digital equivalent of monostables. It has no real tolerance for iffy signals.

Code:

-- VS_RUNNING is pulse less than half line
        if SEPARATED_SYNC_EDGE and not VS_RUNNING then V_SEP_COUNT <= "111111111";
            elsif V_SEP_COUNT = "0000000000"       then V_SEP_COUNT <= "000000000";
            else                                        V_SEP_COUNT <= V_SEP_COUNT -1;
        end if;
        
        if SEPARATED_SYNC_EDGE             then VS_RUNNING <= true;
            elsif V_SEP_COUNT = "000000000" then VS_RUNNING <= false;
            else                                 VS_RUNNING <= VS_RUNNING;
        end if;
        
        if       V_SEP_COUNT = "000000001" and     SEPARATED_SYNC then V_SEP <= true;
            elsif V_SEP_COUNT = "000000001" and not SEPARATED_SYNC then V_SEP <= false;
            else                                                        V_SEP <= V_SEP;
        end if;
        
        V_SEP1 <= V_SEP;
        
-- FS_RUNNING is pulse greater than half line
        if SEPARATED_SYNC_EDGE and not FS_RUNNING then F_SEP_COUNT <= "1111111111";
            elsif F_SEP_COUNT = "0000000000"       then F_SEP_COUNT <= "0000000000";
            else                                        F_SEP_COUNT <= F_SEP_COUNT -1;
        end if;
        
        if SEPARATED_SYNC_EDGE              then FS_RUNNING <= true;
            elsif F_SEP_COUNT = "0000000000" then FS_RUNNING <= false;
            else                                  FS_RUNNING <= FS_RUNNING;
        end if;
        
        if V_SEP and not V_SEP1 then F_SEP <= to_std_logic(FS_RUNNING);
            else                      F_SEP <= F_SEP;
        end if;

[`FRANK.C]

Great result Jeffrey that's looking very promising. Good to hear the H lock is working well. I know you will sort out the V lock.

In the case of my attempt. Using the TVP5150 each line lasts exactly exactly 864 cycles. So the field will free run at the correct frequency.
I just needed a way to detect the transition from even to odd field to reset the counters.
I did this by counting the 10uS(approx) pulses that separate the broad pulses.
At the beginning of the even field there are 7 pulses between the broad pulses. At the beginning of the odd field there are 7 pulses between the broad pulses but there is also an 8th after the last broad pulse.
So if I counted 7 pulses I knew it was an even field or if it was 8 pulses it was an odd field. Any other number of pulses were ignored and the frame would free run.

If the CV2000 has just one field pulse this would be of no use.

Frank

[ppppenguin]

Onec V and F lock is achieved it should stay that way withoug any further V sync pulses provided that the number of pixels per line and lines per field are both stable. I don't think this can be taken as true for VT replay where there are many different speed fluctuations, covering a wide spectrum.

[ppppenguin]

I'm pondering on how to do a really effective field sync separator. I'm currently using what is effectively a monostable to ignore H sync pulses. This is sensitive to impulse interference and I can see a fair bit of that on the recordings we were using yesterday. I could see the video dropping down below black level at times plus disurbances below sync tip.

I separate syncs by simple slicing. The threshold is adjustable in software so I might go a bit lower than halfway down. That will reduce some of the spurious syncs.

Traditionally TVs use an integrator of some kind to separate V sync. This will tend to reject unwanted impulses. I could do something similar in digits by starting a counter on the leading edge of sync and then only flag a V sync pulse when it reaches a high enough count. If I know the signal has correct broad pulses I can do the test multiple times in a single V sync.

Unlike in a TV, I also have to distinguish between odd and even fields. I do this fairly crudely by noting whether the first broad pulse occurs halfway through a line or not. I can probably make this more resilient by gathering evidence from multiple V syncs. If I accumulate the result from several V sync pulses then I can set a threshold for believing that my internally generated odd/even sequence is wrong.

[ppppenguin]

May I run an idea past you?

The raw digital video output from the decoder chip has sync tip at nominal 0, black at approx 60 and white at approx 200, expressed as 8 bit numbers.

When I detect what appears to be the start of a sync pulse, start a counter that will run for about 30us and then stop. This is more than a line sync pulse but less than a broad pulse. While counter is running, accumulate the total of the digital values of each pixel. In an ideal broad pulse this would be zero. If not a broad pulse it would be huge. Set a threshold at which I declare it to be a broad pulse. This would allow for odd splats of dropout etc. I'd make the threshold variable for experiments.

Implementing this in a FPGA is actually very simple. The adder/accumulator would only need to be 17 or possibly 18 bits, plus comparator and ancillary bit of logic. Maybe a dozen lines of VHDL which will synthesise a negligible amount of logic, even in the modest FPGA that I'm using.

Obviously any splat ont eh signal that gets detected as a sync edge will start the count. Unless it's a broad pulse it's unlikely that the accumulated value will stay below threshold. Also once I've successfully detected a field sync, I can then lock out the sync edge detector until I expect another V sync. This will cause a delay in locking to a new signal but should minimise the risk of a finding a spurious field pulse.

Next thing is to dream up a ruggedised odd/even field detector. Unlike a monitor which has no need to know which field is odd or even, I do need to know as each field has to be stored in the correct bit of memory.

PS: Some of the point of this is not necessarily to have the crowd tear my ideas to pieces (though that is welcome) but to force myself to explain (to me!) what I'm doing. If I can't put the idea down in print or explain it to somebody else I don't really have a hope in hell of understanding what I was trying to do.

[`FRANK.C]

Hi Jeffrey
That sounds like a good plan it should work.

Before I settled on counting the pulses between the broad pulses there was another way of detecting the field sync that I was thinking about but didn't try.
It uses an accumulator and went something like this.

Separate the syncs by slicing. If Video level > 30 then slice < = '1'.
For every cycle slice = '1' and the accumulator > 0 then take 1 away from the accumulator.
For every cycle slice = '0' then add 1 to the accumulator.

Assuming 864 cycles per line.
After line sync pulse the maximum in the accumulator should be no more than 100.
After a string of 8 broad pulses the accumulator should peak at around 2000.
To allow for any rubbish in the sync area a threshold of something like 1800 could be set for a valid field pulse at which time the accumulator would be reset to 0.

It's was just an idea I never tried it.

Frank