Variable phase shifter?

innews: snipped-for-privacy@4ax.com:

Well, as Jim T. pointed out in the first response, it's not really phase shift, it's relative time-shift of a (digital) square wave, where I want the time shift to be proportional to the "phase" control signal and also to the period of the input frequency, so for example, if you set the phase control to get two square waves in quadrature, they remain in quadrature to a reasonable degree of accuracy as you vary the frequency. However, the input will be a stable frequency during operation, so the circuit doesn't have to respond instantaneously. A millisecond settling time would be fine. You can think of the application as having two square waves which control sampling of an input waveform at two different points in time, or two different "phases" of a frequency which is synchronous with the digital square wave. Actually, for what I'm doing, I don't really need square wave outputs; it's sufficient to just have pulse outputs with reasonably accurately controlled leading edges, which will act as clocks for following divide-by-two stages (whose outputs will then, of course, be square waves).

I may have given an inaccurate description, but one way to do it that meets my needs (except perhaps for keeping phase noise low) is to generate a ramp that resets at the rising edge of the square wave input. AGC is used to keep the amplitude of the ramp constant as the input frequency is changed. In that way, a pair of comparators that sample the ramp can generate the outputs; the setpoints of the comparators are set by the "phase-control" input. It's a little bit of fun to make a clean, fairly high amplitude ramp at 120MHz input rate, but not too bad with 5GHz ft transistors. Comparators like the ADCMP580 series, or even the ADCMP551 series, can handle the speed easily and provide low jitter.

A Hilbert transform (or a pair of all-pass filters with phase offsets) doesn't really do what I want; if you phase shift each frequency component of a square wave by the same angle, you don't end up with a square wave. (I think that was all covered earlier in the thread...)

An alternate way to accomplish the goal that isn't too bad is to turn the input square wave into quadrature sine waves of nominally equal amplitude, and sum the right amount of each to get the desired phase shift; then turn the output sine back into square with a low-jitter comparator.

The reconstruction filters on DAC outputs will take care of harmonics; it doesn't matter if they aren't perfectly matched since I don't care that the phase shift remain absolutely constant over frequency. If I were going to the trouble to use DDS, I'd have at least a microcontroller running them, and into which could be programmed calibration to remove phase errors versus frequency in any event. Heck, if I cared about it, it would be pretty simple to provide an autocal path (phase comparator fed by the two outputs, back to the micro) that could cal the phase on command. I think it's safe to trust that re-programming just the phase of a DDS won't change the phase-response of the reconstruction filter. ;-) I may be wrong, but I don't think the phase noise, per se, of a DDS is degraded significantly as you ask it to output in large phase steps. Amplitude errors, which can again be corrected (sin(x)/x correction), don't matter since the output is going to be turned back into square wave anwyay. I think DDS would be a fine way to go, but it's just way more complicated (from a system point of view) than I want for this particular hack. It very well may see its way into a future version of what I'm working on, though.

Cheers, Tom

Tom Bruhns wrote in news:3824c8d2-bcb0-4c29-bb48- snipped-for-privacy@z11g2000prl.googlegroups.com:

Try this approach-- a high-bit counter circuit to measure period. Pop the period output of the counter into a simple DAC, and scale it however you need to. Use this as one input to an analog multiplier, and the other input would be your phase. Turn that voltage into a delay somehow-- a simple 555 timer charging via some constant current, for example (I haven't checked speed specs on a 555). The constant current charging means a ramp to the control voltage.

No ucontroller, no DDS, one counter, a DAC, a multiplier, and a 555 with a transistor.

Scott Seidman wrote in news:Xns9AFE99BE4158Fscottseidmanmindspri@130.133.1.4:

LMC555 can generate 3 MHz.

(Need a register between the counter and the DAC...)

Let's see--instead of a counter to get the period and a DAC to turn that into an analog voltage--why not just a ramp that's reset by the square wave, and a peak detector to monitor how big the ramp gets? The peak detector output is proportional to the waveform's period. It's kind of the analog of a frequency-to-voltage converter, but it's a period-to-voltage converter. You don't really even need a peak detector; a simple average (e.g., long time constant RC filter) will do fine, since the frequency doesn't change in use and I can in this case depend on the stability of the duty cycle of the input.

But how I turn the 555's output to a delay (on a 120MHz square wave...), I'm a bit foggy on...

On the other hand, I know how to use a voltage to control a wideband delay pretty well...so this has some possibilities. Thanks for the idea!

Cheers, Tom

Tom Bruhns wrote in news:13033ae2-80d0-41ba-b6a5- snipped-for-privacy@r15g2000prh.googlegroups.com:

You were saying you're more interested in the timing than the waveform. If the 1.2 MHz had, say, a 60% duty cycle, you could just use the 555 to generate the delay pulse, and a simple NAND with the original waveform would give you a delayed square wave, but the duty cycle of the second wave would be variable.

That's OK at 1.2MHz, but what about at 120MHz, 8 nanosecond period?? Then we're back to about the same method I was suggesting earlier, using fast comparators on a fast ramp; I think it's about the same as your 555 idea, but with the comparator as a stand-alone part. Does anyone make an "ECL 555"?? ;-) I do appreciate all the inputs--I'm coming up with something simpler than I originally would have because of them.

Cheers, Tom

Yes, that's certainly one reasonable way to go. I don't think any modern FPGA would have a problem with the speed, though--certainly not the ones we've been using around here. Actually, once you've invoked an FPGA, you also have opened the door to running an NCO with fine phase adjustment inside it...

My thanks to all who have provided inputs.

Cheers, Tom