1. Home
  2. Electronics Design
  3. Breadboarded 74HCT7046 PLL very unstable

Breadboarded 74HCT7046 PLL very unstable

Hi guys,

I'm trying to recover the bit clock from a 6.9375MHz NRZ bit stream. To make things easier, this stream has several encoding rules: - Thanks to the use of parity bits (each 7-bit data byte has an odd parity bit in the LSB), the longest possible sequence with no transitions is 14 bits long (the Clock Cracker: 1111 1110 0111 1111, repeated until the end of the packet). - All packets begin with a 2-byte clock run-in (CRI) and framing sequence. This sequence (including sync) is: 10101010 10101010 11100100.

By my reckoning this means: - There must be at least one transition every 14*(1/6.9375e6) = 2.02 us. - Transitions can follow one after the other, as seen in the CRI - Thus the time between two transitions can range from 144ns to 2.02us.

What I'm trying to do is put together a PLL-based clock recovery circuit, using a 74HCT7046. I need it to start capturing at the CRI, and ideally lock within 16 bits or less (or at least lock well enough to shift in and match the frame sync byte).

I've breadboarded a test circuit using a Texas Instruments CD74HCT7046A,

1% metal film resistors and ceramic disc capacitors (the round brown ones).

The component values I'm using are: R1 = 33k R2 = 10k C1 = 100pF

And for the filter: Series resistor between PC2OUT and VCOIN = 18k Capacitor from VCOIN to ground = 120pF t1 = 2.16us 1/t1 = 462962us

... but despite all my calculations (a dozen or so sheets of A4, loads of Post-it notes, and a good few pages of my lab notebook!) saying "this will work", I can't get the little swine to lock! Somehow the frequency always ends up lower than it should, and the phase detector just won't push the frequency any higher.

Given a static input voltage (VCO_in), the VCO frequency jitters quite badly. If I turn off the trigger delay, the signal looks reasonably good. Add in a 1us delay (that is, the scope starts displaying 1us after the trigger) and you can see the square-wave VCO output jumping left and right on the screen.

I do have a backup plan: a 13.875MHz crystal, in a 74HCT04 CMOS oscillator circuit (the "buffered crystal oscillator" described by Rakon in one of their application notes), with a BB419 varactor tacked on for frequency control. The catch is that this requires a 0-20V input signal for the varactor, which means I need to add an opamp (to boost the 0-5V signal from the '7046's loop filter), a 20V power supply, and a divide-by- two (DFF wired to toggle) to get from 13.875MHz to 6.9375MHz. I'm not keen on this plan, though... it adds a fair few extra chips to the board...

Does anyone have any suggestions? Are HCT7046s, HC7046s or 4046s known to be unstable when built up on breadboards?

Does anyone know of any decent PLL design software, or any good books on the subject? My usual reference (Art of Electronics 2ed) doesn't really go into much detail, and neither does the TI datasheet... which is, frankly, pretty crap.

Thanks,

--
Phil.
philpem@philpem.me.uk
http://www.philpem.me.uk/
Reply to
Philip Pemberton
Loading thread data ...

They're unstable when built with poor decoupling or loopy grounds.

Are you using one of those repulsive white nylon things, or a real breadboard with a proper ground plane? What does your supply bypassing look like?

Have you taken seriously the (very sloppy) datasheet limits for centre frequency vs R and C? You can't just use the typicals.

How did you design your loop, exactly? You're using a simple RC lag, which isn't usually good enough because the VCO itself is a perfect integrator--you almost always need a lead-lag network. Otherwise the loop will be unstable and will never lock.

Are you using the phase-frequency detector or the XOR? The PF detector will always pull in, but the XOR may not if the loop bandwidth is very narrow or there are extra feedback poles outside the loop BW.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

If that protocol is what It looks like to me or something close to it (SLIP), you aren't going to lock a PLL to that. the frame of a packet is not constant in time to start with..

You are seeing this problem with the lock because the frequency is varying too much.. You are getting more lower shifts than higher shifts in freq. If you had a 50% duty of both sides, it would lock in.. BUt this isn't the case..

I haven't done this in years but back in the hay day of Packet Radio, this was a very popular thing.. SLIP protocol.. How ever, your system could be using variable width modulation.

Either of them isn't going to lock that well since it's obvious that you are dealing with a fast signal..

I suppose if you were to pass your signal through a FF, you could even the duty cycle. THis would most likely give you a more stable PLL but it's still going to wander.

It would be nice if there was a known protocol that we could reference from ?

That's my take on it..

Jamie

Reply to
Jamie

How does the system idle between packets? Are the packets stacked immediately after one another?

John

Reply to
John Larkin

I missed the NRZ part. Besides the bypassing and loop dynamics parts, the OP will have to do something to make sure that there's a component at the fundamental to lock to. Clock recovery isn't quite as simple as this, unfortunately!

To the OP: Try googling for 'Costas loop'.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

It's the UK Teletext signal -- per the 1976 BBC/IBA/BREMA specification found at

formatting link
.

The datastream itself is likely to be a fairly random mix of 0s and 1s (it's a text stream with odd parity, and the magazine/page numbers are pseudo-Hamming coded). The Clock Cracker is simply a test to make sure a clock extractor can maintain a stable lock when faced with a worst case scenario.

As for my breadboard, it's a white nylon K&S (or something like that). Banana-plugs along the top for power, power rails along the top and bottom, and the usual fare of 6-hole strips of contacts.

Thanks, Phil.

Reply to
Philip Pemberton

Typically you get one or two packets in the VBI, then nothing for the visible video time. You'll get maybe 2 packets at a 64us interval, then nothing for (64*310)us -- 310 lines of either visible data or other VBI.

Thanks, Phil.

Reply to
Philip Pemberton

On a sunny day (27 Dec 2010 13:01:04 GMT) it happened Philip Pemberton wrote in :

May I recommend to use the SAA5246A chip, and then you could my GPL'ed Linux software to display teletext on the PC:

formatting link
screenshot:
formatting link
A two chip solution (static RAM for page memory is also needed), connected to the PC par port. It (this chip) can also be used to add BW text to any analog video signal.

It is a much better solution than using tons of discretes. The PLL is digital, and build in. The whole thing runs on a 27 MHz xtal.

Reply to
Jan Panteltje

use a cpld and a say 6.9375MHz*8 = 55.5MHz clock, reset 8x divider on edges spec say +/-25ppm so less than 8 times might do

what are you going to process the data with once you get it?

-Lasse

Reply to
langwadt

Yup. Phase detectors don't like missing transitions. I did the following 27 years ago for a floppy clock and data extractor...

formatting link

The OP's data stream is PCM, not BPSK, so I'm not sure, off the top of my head, whether a Costas Loop will work or not. ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |
             
I love to cook with wine.     Sometimes I even put it in the food.
Reply to
Jim Thompson

On a sunny day (Mon, 27 Dec 2010 08:35:17 -0700) it happened Jim Thompson wrote in :

Mine does not mind missing pulses, will stay on frequency, actually uses a 4046, and is dated 23-7-1984, makes it about 26 years ago. Still working to this day: ftp://panteltje.com/pub/fdc-2.jpg

The trick is 2 fold here, using sample and hold in the phase comparator: first only open the sample gate when there is a pulse (say signal), second the width of the pulse sets the gain, no analog ramps involved.

Reply to
Jan Panteltje

It's a clock recovery circuit, so he can't use the phase-frequency detector.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

Yes, a data-directed loop such as a Costas will work. For that matter, so should a "delay half a bit and multiply" style loop -- which is easier to do if you have a good enough signal to noise ratio.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

Bah! Explanation sought and given... :(

But I'm not feeding the data straight into the PLL's comparison-signal input. I'm feeding it through a string of six 74HCT04 gates to delay the data signal, then XORing delayed_data with original_data to get a 25ns pulse for each data line transition.

Unfortunately it seems this still isn't enough :(

Thanks, Phil.

Reply to
Philip Pemberton

If it's VBI data, a VCXO-based PLL is probably more appropriate than an RC oscillator-based one.

John

Reply to
John Larkin

You say it's a television standard -- so the carrier clock can be counted on to be dead stable, and all you should have to do is extract it, right?

I'd be inclined to do a digital loop. Use a free-running crystal oscillator, with a divider that lets you divide by N, N+1 and N-1. Then use timing errors to decide if you're going to go +1 or -1 on your steering.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

"Connection failed: the connection to the server was reset while the page was being loaded."

I get the feeling I'm going to have to model the behaviour of the HCT7046's phase comparator under a missing-pulse situation...

Reply to
Philip Pemberton

"Connection failed: the connection to the server was reset while the page was being loaded."

I get the feeling I'm going to have to model the behaviour of the HCT7046's phase comparator under a missing-pulse situation...

Reply to
Philip Pemberton

Oh, that's a crappy breadboard to use in the MHz frequencies. They're OK at audio frequencies if you're careful about grounding and don't mind troubleshooting the almost inevitable bad connection. But while it is possible* to use them at higher frequencies, dead-bugging the circuit over a ground plane will get you more joy.

  • I met a guy -- with heavy RF creds -- who claimed to have built a
10MHz receiver front end on one of them. I didn't get a chance to actually _see_ the thing, though, so I don't know how true it is. I've built circuits on them that worked up into the MHz regions, but (a) I was very anal about layout, well beyond the point of diminishing returns, and (b) I knew that any component values that I used would have to be tweaked once the design became "real". 
--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

On a sunny day (27 Dec 2010 17:39:07 GMT) it happened Philip Pemberton wrote in :

Works fine here, I see about 7 accesses that all worked in the log,.

Reply to
Jan Panteltje

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.