Post by thread:SPAM: Re: [PIC]: Frequency multiplier?

Couple Q's... - Does duty-cycle matter? - What is the range of the input freq? - Is the multiplier a fixed value? Cheers, -Neil. On Wednesday 30 April 2003 01:00, Reinaldo Alvares scribbled: {Quote hidden}> Thanks to all for your answers to my 50% stuff question. > I perhaps didn't explain myself properly or didn't understand your answer > correctly. > Let me please rephrase my question. Let's say I want to multiply the > frequency of an input square wave by some factor "F".Consider a sensor > giving pulses from a rotating shaft, if the shaft accelerates then two > consecutive periods are different. Every next period will be shorter than > the previous one. Now if I divide the first period "P" by "F" and output an > "F" amount of pulses with periods equal to "P/F" then the PIC will still be > outputting pulses while the next period is already happening. I can't loose > counts since I need this for positioning, direction and speed measurement > purposes. I have to watch both edges for any change in the direction of the > shaft.The sensor is a quadrature encoder with only A and B outputs, no Z. I > have to output two channels out of phase by ~90% to the system processing > the data.The phase difference is naturally the same as the incoming pulse. > I have managed to do it for a fixed or slow variable frequency.I > implemented it in software on an 16F84A, I know they are outdated, but I > have lots of them!. When the shaft accelerates fast then I start to miss > about 3 to 10% of the pulses depending on the acceleration, getting offsets > in > position.When the shaft is slowing down then is ok because the next period > will be longer. There will be space enough in time to accommodate the > multiplied pulses before the next ones will have to be outputted. I might > be missing something here, I don't know what a phase accumulator is but > I'll try to find out. It looks to me that this task is just not possible to > fix on a base of period by period multiplication. I appreciate very much > any advise or pointer to how to solve this. And sorry for taking this > thread, I didn't mean to. > Best regards > RA > {Original Message removed}

Okay, I'm confusing threads here, because I thought there was something about a 30% increase some days ago. But let's work with 10x ... Possible solution 1: (I can't see why this solution would cause you problems, but you will have jitter) -- monitor input, and on each rising edge, dump out 10 output pulses as fast as the circuitry connected to the output will handle it. This needs to be at least 10 khz, so that at max frequency, the output is done before the next incoming edge. That's it. Possible solution 2: Whatever you are doing now (where you're losing pulses during input acceleration), you should monitor the input and *queue* the output pulses so that none is lost. With the first incoming pulse, put the number 10 in an output queue. The output routine (cycle) will monitor this number and dump an output pulse when this number is greater than zero and then decrement this number. If it only gets to output say 8 pulses before the next input pulse comes in (because the input rate increased), then just *add* the newest number of output pulses to what's already been scheduled. IE: add 10 to the remaining 2. Again, you will have all the output pulses, but with some jitter. With some intelligent coding, you can accelerate the output a bit more than necessary to catch up to real-time. Cheers, -Neil. On Wednesday 30 April 2003 02:50, Reinaldo Alvares scribbled: > -No, the duty cycle doesn't matter as long as the outputed pulses are > evenly spaced. > -The range of the input frequency is from 0Hz(stop condition) to 1kHz(max > speed). > -Yes, the multiplier is always the same 10. > Thanks for your reply > RA > {Original Message removed}