NRZ data separator, take two!

On 04 Jan 2011 01:50:18 GMT, Philip Pemberton wrote: ...

Valid for how long? What is the bit error you're observing when this happens?

This is not necessarily needed. There is some amount of wander at the transmitter. Your pll is supposed to track wander and filter noise. If you VCO control signal changes slowly and around a certain value, it's possible that it's doing exactly what's needed for your transmitter. The main criteria for success is the bit error rate (and long term average clock period to some degree). If you meet that, it's time to stop ;-)

The bitrate in question is 444 * 15.625 KHz so 0.111 * 62.5 MHz is a workable setup. There are plenty 62.5 MHz oscillators available (or

ock

Correct. You'll need to slew phase very quickly to phase lock in 24 bit times. A VCXO won't do that--the crystal won't let it.

-- Cheers, James Arthur

One idea to generate the bit clock is to inject locking a free running oscillator close to the desired frequency. Derive the NRZ stream and use e.g. the positive going pulses to kick the oscillator.

Since you appear to be in the UK, you should be able to get copies of Wireless World magazine from 1975/76 which ran a construction series of a teletext decoder using 80 TTL chips. You might find some useful ideas from that design. From those days, the standard has been slightly changed, e.g. allowing more lines to carry Teletext.

"Philip Pemberton" schreef in bericht news:4d227cda$0$4262$c3e8da3$ snipped-for-privacy@news.astraweb.com...

There's no need to use a VCXO with a PLL for this. If you want to use a PLL you'd better use an LC- or RC-VCO. They can lock much faster and once locked they're about as good as the TX-oscillator.

You don't even need a PLL at all. Another method for clock extraction is using an XO at a multiple of four or more times the required frequency. A divider that resets on every edge of the incoming signal will produce the required clock. To distinguish between a glitch and a real edge you only accept an edge when you find two successive high after the successive low (or the other way around when using a four times XO).

petrus bitbyter

ock

you can get a pll based oscillator programmed to what ever frequency you need from digikey (see epson sg-8003 for example)

simpler would be to use a dds to do generate the sampling clock, 50MHz/

should be doable in a cpld since it 7.25 doesn't need a big accumulator in the dds

and FPGA doesn't have to be that expensive you can get a spartan3 in tssop100 for something like 5$, soldering one of those is not too bad

what are you going to do with the data once you get it? might make sense to put everything in and fpga ...

-Lasse

Did you design the loop filter using the procedure I suggested a week or so ago? (Gory detail doesn't begin to cover it.)

Cheers

Phil Hobbs

Oscillators don't suffer the same slew restrictions as filters--the differential equation is fully local, so if you tune the resonator, the oscillator frequency responds instantly, rather than taking Q cycles or so. This is a pretty useful feature in many instances--a pal of mine from grad school used it to speed up the atomic force microscope by a factor of about 100. He ran the sensing cantilever as an oscillator rather than driving it with a CW sine wave and detecting the amplitude and phase of the response, which is what the rest of us were doing.

Of course the total tuning range is still small, which limits the maximum frequency difference--which of course is the rate of change of the relative phase of the oscillator and the input.

The OP seems to want to poke things and have them work, which probably isn't going to be a fruitful approach to a high performance clock recovery circuit.

Cheers

Phil Hobbs

I've made several _digital_ solutions, which have proven to work nicely in practice, _without_ needing a PLL.

I don't think the OP understands what I suggested, let alone how PLL's work :-( ...Jim Thompson

OK, well I've just implemented something like that on my FPGA board. I've got a 2-bit shift register which stores the last two data states at Fclk, and only reports a transition when SR[0] == SR[1], and SR[1] == !data.

The clock extractor is a 5-bit counter: - When there's a L->H edge on the TRANSITION input, the counter is reset to 0 - When there's a L->H edge on the CLK input, the counter increments - Sample output is high when the counter value is 7, otherwise it's low - The counter value is reset to 0 when it reaches 15.

Input clock to the "PLL" block is 8*13.875MHz, or 111MHz. This is 16* the data frequency of 6.9375MHz.

I did fall into one beartrap -- I forgot to add TRANSITION to the always@ clause, so the counter only reset when there was a clock pulse *and* TRANSITION was high. This introduced some pretty nasty random phase error: the sample pulse usually ended up in the middle of the data change- over, but roughly once every ten seconds it would end up offset so that it landed *right on a data transition*. Indeterminate data, ho!

After fixing that, it seems to be behaving itself... I'm using a faux-eye- diagram to assess the timing accuracy, and aside from ~14ns of +/- jitter, it's fine. This still leaves 56ns on either side of the sampling trigger pulse, out of a total data pulse width of ~145ns... I'd call that a success :)

I haven't tried feeding it a TV signal yet (no TV aerial in the kitchen), but that's next on the to-do list. It's still picking good sampling times at 6.5MHz (6.31% slow) and 7.5MHz (8.11% fast), even to the point where my scope's 6-digit frequency counter shows the sample frequency matching that on the function generator to within a few counts of the least- significant digit...

I'm willing to call this a success. Now I just need those TI clock synthesizers to turn up, then I can build up a prototype :)

For the curious, here's the Verilog HDL source:

// Data transition detector reg [1:0] last_data; wire [2:0] dtt = {last_data,data}; reg data_tran; always @(posedge dpll_ck) begin last_data

Analog in an FPGA? Do you know some little trade secret that I don't? :)

Nearest I've seen to an "analog FPGA" is Anadigm's FPAA (or possibly Lattice's old ispPAC).

-Phil.

Cypress' PSoC comes close.

):

the clock

ready

ogge

or) to

ems

citance

eps

Thanks for that Phil, The filter / oscillator distinction is... interesting (for lack of a better word). I always 'see' high Q filters and 'just' going oscillators as almost connected.

We've got this torrsional harmonic oscillator, (not designed by me so I can brag about it.) That gives beautiful data. The moment of inertia is from a ~6" diameter copper disc ~0.5" thick. Period ~1 sec. You can drop a bit of something onto the disc, and see the period change the right away!

George H.

):

the clock

ready

ogge

or) to

ems

citance

eps

By "slew" I meant the oscillator's output phase--I was sloppy. For a random-phase incoming stream, he's got 16 bit-times (not 24--I biffed that too) to slew the VCXO phase into phase lock. Without even looking at his phase detector, that requires roughly three orders of magnitude more frequency adjustment range than his VCXO's 25ppm.

Clever.

-- Cheers, James Arthur