Are there any phase detectors out there I can use to check the phase of a crystal vs. rising edges of incoming logic signals? The rising edges don't have a fixed frequency, but I know that the edges always have the same phase wrt their clock, I want to pull or tune a local oscillator (resonator) to match that phase.
It seems all I'd need is some sort of analog sampling gate that fires only on rising edges, and some way of knowing the slope. I must not be googling with the right terms cuz so far I have no real insights on this problem. Classic PFDs as used in PLLs with VCOs all need a divider but since I don't have a fixed frequency it's a bit of a problem. I believe I need a Type IV PD, but I find practically no info on Google. (Tonight I'm heading off to the EE library). I believe this type of PD works with the same frequency on both inputs.
It's a 16MHz clock. Sure I can implement an entire sampling gate in discrete parts but who needs that if there's a chip out there that might do it?
Are you saying that rising edges of the data will, once it's locked, always correspond to the same xo clock phase? That would be the situation for, say, NRZI data that's clocked at a rate close to that of the crystal osc.
In that case, a simple d-flop will usually work. Apply the external data to the clock, connect the xo output to D, and lowpass filter Q as the vco voltage. Every rising edge of the data will deliver an early-late indication at Q. Of course, this needs a decent density of data edges to work, but that's the case for any phase detector here.
This is an infinite-gain phase detector, so loop analysis is interesting.
So, what's wrong with the usual phase detector built with two D f/f's? Actually, neither that type nor the double-balanced-mixer or xor gate type "require" there to be a divider, though the xor/mixer type do need to have a constant duty cycle (or at least a duty cycle that doesn't have jitter; it would be OK if the duty cycle were a gentle function of the frequency). But the one using two D f/fs specifically will give you feedback that lets you align two edges, since the two signals to be compared are the (edge) clocks for the two f/fs.
There's an old computer with a CGA-style video chip running at 16MHz. I'm trying to capture the video and outputting VGA. I'm using a VCO with a divider to do this now. I'm using the computer's HSYNC, a PIC in PWM mode used as a /1016 counter and a ICS genlock chip. The genlock gives me 16MHz to capture the data and 32MHz to drive the VGA.
Two problems: (Keep in mind this is a hobby thing, no production)
1) I need to delay the HSYNC edges so that the VCO creates a delayed clock to respect the setup and hold times of the scan converter, otherwise the VCO's rising edges happen at the same time as the data rising edge. I'm using gate delays right now but this is iffy. If I had more control over the clock generation, I can easily implement a consistent delay. 74LS31s are hard to find too. Also a VCO is very sensitive to power supply noise. I've got 2mV p-p of noise on my DC, which is the limit I can measure anyways. It looks like I have bimodal noise on the VCOs output.
2) The video chip is programmable, so my circuit has no way of knowing if the software has hacked the video chip into outputting some bizarre hsync frequency. If the hsync changes, my PIC is still dividing the VCO by 1016, which then forces the genlock to output a new, different pixel clock totally unrelated to the 16MHz pixel rate == bad picture. And since this clock also happens to be the PIC's clock, what am I supposed to compare to? I'd have to add a whole new slew of circuits to detect this change. I suppose I could count the number of hsyncs between vsyncs but there's no guarantee.
I suppose I could toss in another PIC on its own clock (more parts, more noise), just count the time between HSYNCs, calculate a new divider to get 16MHz, send it out via I2C to the first PIC running in PWM mode. Or find a PIC with a seperately clocked PWM section and run the main thing off its internal RC oscillator. (hmmmm...)
More problems than I know what to do with. Another problem is the app note for the genlock chip which basically boils down to "don't use this chip with that hsync rate and expect 32MHz out of it". It sucks all around.
The genlock was ideal with its 1x and 2x outputs from the same chip, with less than 1ns skew between em. Even if I build a 32MHz pullable VCXO with phase detection, I still need to get a 16MHz clock with less than 1ns skew wrt the 32MHz clock. Maybe that's not so hard, but it adds to the complexity of the design.
(Never mind. I didn't catch from your first posting--which was clear enough--that the reference signal is at a lower frequency.)
So...if you don't mind not locking the edges at exactly the same point in time (which can in any event be corrected with a little delay), as you say, use the reference edge to open a gate for a fixed time, and feed the output of that to an RC lowpass filter and whatever other loop filtering you need. You'll lock to only one edge: note that if you look at the response to the "other" edge, there's a phase inversion. You can make the gate time equal to half a cycle of your fast clock, if that clock has a 50% duty cycle. The PLL filter integrator would be referenced to 1/2 the supply voltage, if the clock drives to both rails. Then the clock edge will be driven to the mid-point of the gate window, with 1/4 cycle on either side. Note that the "gain" will be very low, if your reference is a tiny fraction of your clock, because you only open the gate for one edge out of many, and it's not a very wide gate.
If you started with a 4x clock, you could generate 90-degree-shifted versions. Use one of them for phase-locking, and pick the
90-degree-leading version for output, nominally aligned with the reference edge. You could perhaps even servo the gate duration to the clock, if it matters. Or perhaps the end application isn't all that critical anyway...
You want to synthesize a phase-locked clock to a random clocked signal, it seems.
Pulse locking can accomplish this; in simple form, make a free-running crystal oscillator and couple the crystal (through blocking capacitors) to a component with variable conductance (a diode, or a FET). Then on each transition low/high of your random signal, pulse the conductance low (by injecting some diode current, or gating the FET) for a short time. The idea is that the phase of the free-running crystal will result in low losses in the case of pulses at zero-crossing time, but higher losses (and change of the oscillator phase) if the pulses are not sync'ed to the zero crossings.
I'm not sure about other kinds of phase detectors, 'cuz there will be missing pulses in the 'random' input signal.
'Pulse locking' and 'parametric oscillator' might be good keys to search on.
Well, "synthesize" conjures up lots of M/N type stuff in my mind. I really want to phase lock a VCXO to a random clocked signal.
Yes... I like the way this is going....
Somehow "phase detector" means PFD in the overwhelming majority of cases these days.
Thanks. I've been looking at the phase lock on my ancient 1L30 spectrum analyzer. It can use a fixed frequency to phase lock the cavity oscillator. The phase detector is an analog sampling gate that samples the output of the cavity on edges of the reference, then it tries to keep the sampled voltage the same by servoing a varicap inside the cavity.
It's tricky stuff and I don't understand it analytically. It's a project on its own (again). I think what you describe is pretty much what's inside the 1L30 phase lock. It's been staring at me for a while now, maybe it's time I understand it. :)
Thanks but it doesn't help the Commodore 128 with its custom video chip with programmable sync rates... I have a scan converter working but it has issues so I'm redesinging the whole clock scheme.
I think what I need is called a "clock recovery unit". The problem is all modern parts are expected to either work in a narrowly defined frequency range for voice telecom, or multi-GHz clock rates.
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.