Hi guys (again)...
I've scanned the current schematic from my lab notebook. Here it is in all its scribbly, hand-drawn, chickenscratch-written glory:
And the ETSI Teletext Specification is here:
(FYI: only pages 14 through about 20 are of any interest to this discussion)
So, to recap from the other thread (which seems to have diverged a bit):
- I want to take a Teletext-format NRZ data stream and extract the clock - Data rate is 6.9375MHz, give or take 25ppm. - Data packets are 45 bytes long: - 3 byte preamble (01010101 01010101 11100100) - even parity - 2-byte address (Hamming coded, odd parity) - 40 bytes of data (odd parity) - The PLL needs to lock by the end of the second preamble byte, ready to receive the framing byte (11100100).
- I've scrapped the 74HCT4046 PLL I was using, in favour of a Hogge phase detector and VCXO - My VCXO is based on a 74HCT04 and uses a varactor for tuning - The VCXO's frequency ranges from 6.93738MHz (0V across varactor) to
6.93758MHz (5V across varactor). Somewhat asymmetrical, but close to what's required (6.9375MHz at 2.5V is the ideal). The range on this may be a little narrow -- 25ppm is 6.937327MHz to 6.937673MHz.The problem at the moment is that while the output data and clock are valid, the PLL doesn't seem to be locking. The voltage at "VCO Vin" seems to rise and fall in a sawtooth (and a VERY slow one at that) but there doesn't seem to be a point where VCO_Vin stays at one particular value.
My theories at the moment are: - The circuit is built on breadboard. Stray track-to-track capacitance is screwing up the loop filter, VCO or both. - The VCO range just plain isn't wide enough. Thus, the loop keeps searching, but never hits the right phase/frequency. - There isn't enough current going into the varactor to make the frequency change significantly. This seems plausible -- I tested the VCXO by wiring it up to a lab power supply and varying the output voltage. The extra 30k in the loop filter circuit might be reducing the current too far, or the varactor is loading down the loop too much. - The loop filter just plain isn't fit for purpose.
#3 and #4 are my two main suspects at the moment -- #3 I can probably test for by adding an LM358 or similar opamp, but #4 is going to be difficult to sort. I haven't found any decent leads on loop filter design
-- everything I've found was either thick with math-soup, or random rules of thumb which work in one situation but not any others.
I'm tempted to scrap the analog PLL and go for a digital PLL or PJL, but that would involve either getting a TTL oscillator custom made (I guess I'd need around 8x-10x the data rate, or about 55.5 to 69.375MHz) or using an FPGA to get the internal clock-multiplier -- I haven't found any common CPLDs with onboard PLL multipliers. I'd rather not use a full- blown FPGA for this, because they are an absolute pig to solder, not to mention being bloody expensive...
Can anyone offer any help or suggestions?
Thanks,