Alan B. Pearce wrote:
> I haven't looked at the links you provided, but I would be tempted to lock 
> the VCO to the line rate, and then when it needs to lock to the data it 
> "just" needs trimming slightly ... as you point out, the data rate is an 
> integer multiple of the line rate, so a small phase error should lock in 
> quickly.

The thing that's putting me off doing that is in section 1.1.3 of the 
BBC/IBA/BREMA teletext spec:

   The data timing reference point is the peak of the penultimate '1' of 
the Clock Run-In sequence (see figure 3). This point has been selected 
to reduce the effect of any transient distortions at the start of the 
Data-Line.
   The line time reference is the half-amplitude point of the leading 
edge of the line synchronising pulse.
   The data timing reference in the signal as transmitted shall be 12.0 
(+0.4/-1.0)us after the line time reference.
   The data timing may vary from Data-Line to Data-Line.

So AIUI, the start of the clock run-in on the scanline can be between 
11.6us and 13us from the leading edge of the line sync pulse. 12us is 
the length of the horizontal blanking period (frontporch, sync, and 
backporch). If that is the case, then locking a VCO to the line rate 
wouldn't help if, say:

   * The broadcaster is providing a signal that's "just a bit" fast or 
slow -- still within the (+0.4/-1.0)us spec, but not perfect.
   * Their teletext inserter is waiting for the sync, then just "brute 
forcing" it -- waiting 12us and spitting out a line of data.

Say the broadcaster's signal is 0.5us fast (that is, the Hblank is 
12.5us). Their inserter waits for the sync, waits 12us exactly, then 
inserts the clock run-in, data and so on. Problem is, if the receiver is 
locking off the line rate, then it's not going to see the clock run and 
framing sequence, or the clock is going to skew as it goes along the line.

AIUI, the receiver is *supposed* to wait for the clock run-in (101010... 
repeated to a length of 16 bits), and lock its own clock to it. Problem 
is, as I said, a PLL would need a loop time of at least 1x the line 
rate, otherwise by the end of the line (depending on the data) it'll 
have skewed off. Effectively what I want is an oscillator that can be 
pulled in sync with the clock run-in, then left to stay where it is 
until the end of the line.

In other words, it's got ((1/6.9375MHz)*16) = 2.31us to lock, then needs 
to hold its phase and frequency at where it's been set for at least 60us...

Hm.

-- 
Phil.
piclist@philpem.me.uk
http://www.philpem.me.uk/
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist