Rookie Frequency Divider Question

[trooper]

Hey guys,

I have a hopefully simple question for you, im working on a automotive project where I need to divide a square wave input by 1.6. Im having a hard time finding an IC on the internet that could do this process. Do you guys have any suggestions or be able to point me in the right direction? Thank you in advance for your help!

[Chris Smith]

From memory the 4077 is a divide by chip. You may need several to make the total combination.

Using two chips and 16 of the 20 legs you can get 1.6.

[Bob Scott]

I think a simple divider is limited to dividing a frequency by an integer only, no decimal point allowed.

First multiply the incoming frequency by 10 using a PLL with a 10X VC oscillator/divider. Then then divide the VCO output by 16.

I chose 10 and 16 because they are both multiples of 2. That way all the resultant divided frequencies can be 50% duty cycle square waves. Use a "biquinary" /10 counter. Biquinary counters can divide by 5 first, then 2 afterwards in order to get the 50% duty cycle.

I'm assuming your incoming frequency is somewhat stable, because a PLL won't necessarily lock to a frequency with a wide range like an automotive tachometer.

I also have to assume a lot of other things, like the frequency is somewhere in the electromagnetic spectrum.

Bob

[trooper]

First off, THNK YOU guys for all of the help. Unfortunately I don’t thing a PIC is going to be able to handle the rate of change with the signal. Basically what I am doing is putting a Japanese instrument cluster in my car and changing the vehicle speed signal to reflect MPH instead of KPH. For example the KPH Speedo will read 60 KPH but actually be 60 MPH. So far I have deduced that my V.S.S. out puts 4000 Pulses Per mile.

[haklesup]

Can we assume you mean to divide the frequency of this square wave and not its amplitude? Also can we assume the duty cycle is 50% or at least constant.

Amplitude is easy, use a non inverting or inverting op amp circuit with R1,R2 selected for the proper gain of 1.6 but frequency is a bit harder.

My first thought was multiply it by 16 then divide by 10 but multiplying a frequency is harder than it sounds.

A divider can be made in several ways. Generally it is a counter where you apply the input to the clock or D pin of a flip flop or counter IC. A counter translates this clock into a sequence of binary or BCD words on its output pins. By looking at only one output at a time you can dividind the input frequency by 2, 4, 8, 16 which makes those multiples easy. Look up ripple counter.

Since a counter is actually a series of cascaded flip flops, you can design our own counter putting logic gates in between to develop counts at other divide-by ratios (not binary or BCD but custom). Methods for doing this are generally in any logic design text book. Basically when the count reaches a certain value, the logic goes active and causes the counter to reset, preset or clear.The process starts with a truth table which is then converted into logic maps before finally being made into boolean expressions which can be used to directly design the gate level logic.

I'm still a little stuck on 1.6 though but I won't sweat it until you confirm the first question.

[haklesup]

My answer above was rendeded obsolete fairly quickly due to near simultanious postings.

I might now suggest an RC circuit to convert the original frequency to voltage followed by a op amp to scale the voltage and allow calibration then followed by a VCO to convert it back to digital. Though this dosen't sound as accurate as an all digital divider.

Try looking for C or VB code you can implement on a PIC or uController. I did a quick look and it won't be very easy finding some.

[MrAl]

Hi there,

If i understand you right your device puts out 4000 pulse per mile
and this means at 60mph it will put out 4000 pulse per minute
which is a frequency of about 67 Hz. I think a PIC would be able
to handle that without too much trouble. Use a high clock frequency
and count the pulses between input wave positive transistions and
do the math.

A PLL to multiply the frequency would have to be able to follow the
incoming frequency very well, and that frequency can vary quite
a bit. A circuit like this would include a divide by 10, a VCO, and
a phase comparator. The VCO would have to work from maybe 1
Hz to 100 Hz and the phase comparator would have to be able to
compare the phase of these frequencies too. I think this will be
hard to do, in that it might take too long to compare the phases of
the low frequencies.

I also like the frequency to voltage convert followed by the voltage
to frequency convert, with a gain of 10 in there so you can divide
the output frequency by 16. The frequency to voltage converter
would have to work with very low frequencies however, but i think
it could work. I dont think i ever had to do a simulation of this
at such low frequencies. Response might be a little slow though...
step on the gas and go faster but the reading takes a bit to catch up.
To constrast, a PIC solution would take only 1 second to update
at 1 Hz.

Perhaps there's an even better way?

[Bob Scott]

Basically what I am doing is putting a Japanese instrument cluster in my car and changing the vehicle speed signal to reflect MPH instead of KPH.

Oh, I did a similar project when I brought my Chev S-10 from the US to Canada. I changed out the whole instrument cluster with a metric one from an auto wrecker, and had the odometer reading changed by a speedo shop tor read to the correct 66,000 KM instead of 44,000 mi.

You also might search the internet for a suitable speedometer rear graphic. The only difference I could see between the US and metric is the silkscreened stick-on plastic label behind all the gage pointers. That's a lot simpler than rolling your own converter circuit. Some make and model-specific aftermarket accessory places (like for my S-10) have graphics available, like for changing a white-on-black numbered speedo to a black-on white.

Bob

[Chris Smith]

If the spedo is the only change your making I sugest the little box with the ratio built in, and "two short cables plus the box" makes up the standard length complete with conversion.

They have been making these devices for decades to reduce/ step up and match the differences.

[GoingFastTurningLeft]

But if you converted it over you'd never use half the speedo range

I'd get tired of doing all the speed limit sign conversions. I'd end up getting too many tickets.

And I don't see why an MCU wouldn't be able to handle it as simply as possible.

I would suggest an AVR, anyway. They rock!

And if it's coming from the speedo unit, I would assume you're not getting an exact 50% duty ratio wave. I want to say the signal is generated by a hall sensor on the driveshaft. If the teeth are similar to what the ABS uses, then it'd be almost 50%, but not exactly.

Reminds me... I did want to build a digital speedo once... maybe its about time I tackle that... but i'd use it with the original speedo for a long time until I wasn't leary about its accuracy anymore. Nothing worse than a project that gets you speeding tickets.

[GoingFastTurningLeft]

If the spedo is the only change your making I sugest the little box with the ratio built in, and "two short cables plus the box" makes up the standard length complete with conversion.

They have been making these devices for decades to reduce/ step up and match the differences.

If he's talking about frequencies and looking to do it electronically, i'm pretty sure his car doesn't have a cable driven speedo.

[haklesup]

To do it with a uController one would need a local real time clock input. then you could count the number of pulses over a convenient time scale (say 500ms) and then do the math for the conversion and generate a new square wave at the output based on a division of the uC clock.

The output would update to a new constant frequency every 500ms. you would loose the subtleties of variable speed if the update rate were much longer. At low variable speeds, it may seem inaccurate or jumpy. With a fast clock, you would be able to divide that update rate even faster but it will suffer at low speeds due to undersampling.

If your not looking at a 50% square wave but a chain of short pulses with variable time until the next pulse then you may be able to determine speed by measuring the time difference between as few as 3 pulses.

I think changing the graphics would be easiest if you can find one.

CS, if there is an off the shelf solution, what would it be called? No luck googling with garbage search terms.

[VIRAND]

Microcontroller:
Have a medium sized RAM memory buffer as a LOOP to sample into.
Maybe enough to hold a one-second loop. 8K perhaps.

1.0/1.6 = 5/8
so after writing 8 samples from input, read one sample to output
and then skip 5 samples on the reading pointer.
(Do not skip writing any input samples, just always write to the next byte.)
(Go back to the beginning of the buffer when a pointer gets to the end.)

Expect every 5th output pulse to "hit" every 8th input pulse. (I think)
If you could put your voice through this, it should come out a few notes deeper.
(This is a use-specific simplification of a method of voice-changing.)

Check: 8/5=1.6

[philba]

first, a minor correction. Your outgoing frequency should be 0.62138 of your incoming frequency. While that second decimal point may not seem important, it's 3.3% and errors accumulate.

I agree that a uC design would be the best. The way I would do it is to have two processes. Process A watches the incoming pulse period and does some simple filtering on it - say average over a small number of pulses, maybe 8, and saves it in a variable called Pulse_period_in. Process B uses a timer and sets the new outgoing pulse period based on Pluse_period_in (multiplying by .621 or so). There is probably a simple shift and add calculation that would be fairly accurate. I'd look into using the PWM hardware. Care must be taken to not glitch the output or your speedometer may give wierd results.

I would also add in a way to tweak the ratio with out reprogramming. This is important because tire size isn't exact.

How are you going to test this? got a frequency generator? getting the system just right will probably take a little tweaking. Also, after you get it installed, I'd go out an use mileage markers to determine the degree of accuracy and then tweak (see above comment) the results to be 100% spot on. I'd probably use a serial port to output test data so you can analyze it after a test run.

[VIRAND]

Wow, you're right, I never saw that precise a term for this metric conversion. But so it is.