Frequency Conversion Circuit 1

[krgoodwin]

Hello,

I am trying to design a circuit capable of dividing a 70Hz - 5.7kHz square wave signal down to a 1Hz - 1kHz square wave signal. The exact output frequency must be adjustable.

I am currently working with a PIC16F631 chip and had some luck with low frequencies <300Hz using if statements and counting the input pulse. extremely simplified the code was:

if input on, run timer
if input off, stop timer
multiply timer value by x to get y
switch output every y

I then tried using the interrupts built into the chip but the results ended up worse than with the if statements.

I am not an electronics guy and have zero experience in designing circuits. Is the PIC chip even a good architecture for me to be attempting this on? I am not stuck with the PIC, I just chose it because it looked simple and I could program it in C. Is there anything pre-built out there that can accomplish what I am trying to do? Any help would be welcome.

 

[IRstuff]

there's

http://www.ti.com/product/sn74ls294

http://www.ti.com/lsds/ti/analog/cl...locks&HQS=NotApplicable+BA+integratedclocks-p

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[krgoodwin]

Thanks for the reply,

I have looked at stuff like that before. The problem is I need to divide by weird numbers like 8.533. not just multiples of 2.

 

[IRstuff]

Is this for school?

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[BrianE22]

Maybe a frequency to voltage converter followed by a voltage to frequency converter?

 

[krgoodwin]

This is not for school. It was supposed to be a minor interface component of a product I am developing. I was thinking, perhaps mistakenly, that it would be really easy to get a micro controller to count an input pulse length, multiply it by x and output that value as a pulse length. I still think the hardware is capable of doing this. It is just my inexperience that is giving me problems.

I will look into the frequency-voltage-frequency idea.

 

[IRstuff]

The reason I ask is that the second link I posted contains at least 5 rate multiplier/dividers, which can do what you claim you want.

"The exact output frequency must be adjustable."

However, this may not be doable, depending on what resolution/accuracy you are requiring

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[krgoodwin]

If it wasn't already painfully obvious I am not overly familiar with electrical components. I will review that page and see what I can find.

Thanks for your help.

 

[VEBill]

Dividing by integers is a straightforward digital problem. One can also multiply by integers using a very common PLL technique. Combining these two methods in series, one can create a frequency ratio of any rational number (within reason).

Recently I've been playing with Arduino boards and a popular AD9850 DDS board. These things are cheap as chips, and can be tiny (Arduino Nano). If your requirements for tracking were loose, it might be possible to do this in software. Measure F(in), do the math, adjust F(out). The limitation would be the update loop rate. Using clever programming tricks, it could be better than once per second - maybe...

Another approach worth checking is to switch your thinking from the frequency domain (Hz) to the period domain (us). There may be a simple and tight algorithm of counting pulses and then interpolating the fractional part, and then transitioning the output on a calculated schedule. If you're lucky, maybe 30 lines of tight code (?).

 

[VEBill]

PS:

The Arduino includes a "tone(pin, frequency)" instruction, apparently programmable to the nearest Hz. Disclaimer - I've not used that feature yet; I'm not aware of any limitations.

I wonder if you could measure the input period (typically faster than measuring frequency), use a look up table, and update the appropriate tone output. Might be just a few lines of code inside the main loop.

If you change the division ratio, recalculate the table.

Obviously you can also recreate this using whatever board you have at hand.

 

[krgoodwin]

I do actually have an Arduino sitting on my desk. I don't think it has any advantages over the PIC I am using though. The Arduino is much more expensive than the PIC as well.

I am currently counting pulse width not frequency. I am taking the input pulse length, multiplying it by a number (this only needs to be set once but varies depending on application) and then outputting the new pulse length. It worked really well up to 300Hz then it fell on it's face.

I spent sometime yesterday looking at frequency to voltage converters and am now thinking that might be a simpler solution.

 

[Noway2]

The problem is I need to divide by weird numbers like 8.533. not just multiples of 2.

This could be problematic, especially if you are coding in a higher level language like C. Most smaller microprocessors do not have hardware resources to handle math instructions of this sort natively which means that the compiler calls (often times massively long) software emulation routines. These can be a real time suck that causes you to violate the prime directive of real time processing: that your task take less time than your interrupt rate.

Another consideration, since you mention it working at lower frequencies, is number overflow versus the counter resolution. You could be running into numbers that are simply too large when trying to count higher frequencies and this would appear as random garbage output when in fact it is the low order bits of your result.

Personally, I would suggest using a better processor for the job, such as one of the TI's mentioned as they operate at a clock rate MUCH higher than a PIC and have built in hardware for measuring input pulses as well, generating output via a PLL, and the math resources necessary to do the frequency conversion. A smaller TI DSP, eg 28x series, won't cost you anymore than a PIC either.

 

[IRstuff]

"Dividing by integers is a straightforward digital problem. One can also multiply by integers using a very common PLL technique. Combining these two methods in series, one can create a frequency ratio of any rational number (within reason)."


That's what the rate multiplier/divider chips from the TI site do.


TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[bradrs]

Counting pulse width instead of frequency, when you want to measure frequency can give you a lot of errors in your output.

Also, the method of reading the input to determine whether or not to start the clock the way you are doing is called "polling". It can result in a good bit of jitter in the output signal, since your clock value now has an +/- error range as large as that section of code takes to execute(twice).

Have you determined a spec for how much error you can have on the output signal? In terms of jitter, duty cycle errors(does it need to reproduce the same duty cycle as the input?), error in frequency scaling, etc.

Will your electronics need to go through any sort of compliance testing, in your products?

 

[krgoodwin]

Most smaller microprocessors do not have hardware resources to handle math instructions of this sort natively which means that the compiler calls (often times massively long) software emulation routines.

I was thinking I may run into a problem like that. Indeed I encounter more problems when I try to multiply the pulses as opposed to just moving the registers from the input to the output.

You could be running into numbers that are simply too large when trying to count higher frequencies and this would appear as random garbage output when in fact it is the low order bits of your result.

The pulse widths get smaller as the frequency increases. I don't see this being a problem.

That's what the rate multiplier/divider chips from the TI site do.

I don't see anything there that will solve my issue. Although that is probably due to me not knowing exactly what I am looking for/at.

Have you determined a spec for how much error you can have on the output signal? In terms of jitter, duty cycle errors(does it need to reproduce the same duty cycle as the input?), error in frequency scaling, etc.

Will your electronics need to go through any sort of compliance testing, in your products?

I need the output to be as similar to the input as possible. There is just environmental testing the products need to go through. I am not trerribly worried about it at this point. I need this in a semi-working state before I even think about moving forward.

 

[IRstuff]

from the very first product on the page

http://www.ti.com/lit/ds/symlink/cdce949.pdf

PLL MULTIPLIER/DIVIDER DEFINITION
At a given input frequency (fIN), the output frequency (fOUT) of the CDCE949/CDCEL949 can be calculated by:
where ƒOUT = (ƒIN/Pdiv) * (N/M)

M (1 to 511) and N (1 to 4095) are the multiplier/divider values of the PLL;
Pdiv (1 to 127) is the output divider.


I suggest that you find an EE to do this.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[krgoodwin]

I suggest that you find an EE to do this.

I agree. Unfortunately I am the one who has to do this.

from the very first product on the page

http://www.ti.com/lit/ds/symlink/cdce949.pdf

PLL MULTIPLIER/DIVIDER DEFINITION
At a given input frequency (fIN), the output frequency (fOUT) of the CDCE949/CDCEL949 can be calculated by:
where ƒOUT = (ƒIN/Pdiv) * (N/M)

M (1 to 511) and N (1 to 4095) are the multiplier/divider values of the PLL;
Pdiv (1 to 127) is the output divider.

The datasheet sates that in PLL mode the minimum frequency input is 8MHz. Unless I am missing something, this will not work for me as I am working in the Hz and kHz range. Regardless I did order a couple in to play with, so if there is a work around for this I would love to know.

 

[BrianE22]

I'm curious why the PIC had troubles. I assume your PIC was driving a D/A? Any idea why it wasn't working at the higher frequencies? Did you have a debugger that could time how long it took to get through your loops?

 

[IRstuff]

That was intended to be an example, not a solution, per se. Clearly, though, a faster rate/multiplier can be divided down, and the frequency can be tweaked with a PIC.

Alternately, your original approach would still seem to be viable. The chip is single-cycle instructions at 200 ns/instruction cycle, which is 877 instructions/ period of your fastest input. You need to find out why your code is so slow. I know the answer to that, actually, which is WHY ARE YOU DOING THE SAME MULTIPLICATION AND DIVISION EVERY INPUT CYCLE? Do you really need infinite resolution? Why not use a lookup table? Even then, a simple FPGA could do pre-processing to lessen any burdens on the PIC.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[krgoodwin]

I'm curious why the PIC had troubles. I assume your PIC was driving a D/A? Any idea why it wasn't working at the higher frequencies? Did you have a debugger that could time how long it took to get through your loops?

I am not using a D/A. The output frequency is created simply by turning the output pin on and off quickly. I also do not have a debugger, which may have helped me.

WHY ARE YOU DOING THE SAME MULTIPLICATION AND DIVISION EVERY INPUT CYCLE? Do you really need infinite resolution? Why not use a lookup table?

It seemed to be the simplest solution at the time. I could probably get away with a refresh rate of about 2Hz or so. A lookup table might be something to look into. Any way to get math out of the program should help me.