square wave multiplier

Hi everyone. I need a reliable circuit to multiply a square wave's frequency - at least 8 times, but more would be better. The wave is in the low audio range (30-700Hz). I've considered a PLL, and it would work fine for higher frequencies, but at 30Hz the frequency varies for too long - I hope to achieve a time of 20msec at most before the multiplier has locked on to the frequency with reasonable accuracy. Also note that it isn't a perfect square wave - it would be best if the circuit ignored small artifacts.

I'm not sure how "locked" the new frequency needs to be. The only way you are going to achieve that fast of a lock time is to do it digitally. Either use a PIC to measure the incoming period of the square wave then output a frequency using the measured period divided by 8 or whatever. Or you could do the same thing with much higher accuracy with hardware (dedicated logic or FPGA). The problem with either approach is that it's only approximate and the output won't be exactly locked to the input square wave frequency and there will be some granularity.

Ray

You could use a simple series of XOR gates. Connect the input signal directly to one XOR input and via an RC network to the other XOR input. The output will be a pulse on the rising and falling edge of the input waveform and is therefore at twice the frequency. Do that twice more and you get x4 then x8 the input frequency. If you want a true square wave output, do it again to get x16 then use a flip-flop to restore a perfect square output. Note that you can get quad XOR gates so you can do it all in one small and inexpensive IC.

Brian.

betwixt said:

If you want a true square wave output, do it again to get x16 then use a flip-flop to restore a perfect square output.
Brian.

Click to expand...

Could you elaborate on that? When I attempted XOR doubling in a circuit simulator, I got a messed up duty cycle, which got even worse with every stage of multiplication.

Sorry but the RC / XOR gate thing will only work for a narrow input frequency range. Say 100Hz (10mS period) is coming in. You would set the first RC / XOR to get a pulse width about 1/4 the input period or 2.5mS which give you a near square wave at 200Hz. Then you do that again but set the RC to 1/4 of that 200Hz or 1.25mS and you would get near square wave at 4X the input frequency or 400Hz. Repeat again, setting the RC to 0.625mS and you get 800Hz. Doubling it again and then dividing it by 2 doesn't help square it up at all. And if the frequency varies from the 100Hz the output ceases to be square and stops functioning correctly (start missing pulses) at about 200Hz input frequency. So it won't work for the 30-700Hz desired range.

OP - what reason do you need to multiply up the frequency?



Ray

Well if the duty cycle is getting screwed up after more stages, then you could just use a toggle flip flop at the end. This could cut the final frequency in half but you should be guaranteed a 50% duty cycle.

Thats exactly what I proposed by making it x16 then dividing by 2. I accept the restrictions rhaynes warns about and confess I've never tried it in real life. I'm not sure why it shouldn't produce a square wave out after the flip-flop though, even if the input pulses were highly irregular.

Brian.

mtwieg said:

Well if the duty cycle is getting screwed up after more stages, then you could just use a toggle flip flop at the end. This could cut the final frequency in half but you should be guaranteed a 50% duty cycle.

Click to expand...

I believe you are mistaken. See drawing below. In Freq of say 100Hz, 2X has the RC set a bit short so it produces 200Hz but at an incorrect duty cycle and then double that to 4X (duty cycle does not matter) and divide by 2 and you are back to the original 200Hz bad duty cycle signal. No magic allowed.

Ray

egasimus said:

Could you elaborate on that? When I attempted XOR doubling in a circuit simulator, I got a messed up duty cycle, which got even worse with every stage of multiplication.

Click to expand...

Here is a picture of what you are seeing. This assumes a single input frequency with a 5% tolerance on each of the RCs that feed the XOR gates. The gray areas represent the time uncertainty caused by the RC tolerance. At each stage the time error is carried forward and as you can see by the time you get to x16 there are real issues with pulse width. And this is even without varying the frequency.

Ray

Ah yes - but I use three input XOR gates not normal ones !

OK, I put my tin hat on and prepare for incoming flak. The idea is good but I agree, the accumulated edge uncertainty can mess it up.

Brian.