[moved] Frequency Synthesizer using CD4046 PLL / Frequency Multiplication

[Warpspeed]

I see what you mean , what about the 5.76 second reset you suggested earlier?

That was before you posted the specification that requires three digit 0.1 Mph resolution and accuracy.
I just assumed two digits with 1Mph readout resolution.
In your first post you mentioned 60 Mph, not 60.0 Mph.
To get ten times the resolution you need to count up for ten times as long.

For 1Mph readout you need to count up for 2.88 seconds, but that produces a one count ambiguity. Doubling the time eliminates the one digit random flutter, so 5.76 seconds would be required for a stable display of 1 Mph.

To read to 0.1 Mph those figures increase ten times.
If it reads to 0.1 with last digit randomly changing, that's probably o/k.
Random change between 59.9 and 60.0 or 60.0 and 60.1 is probably not too bad.
If you want a flutter free 0.1 Mph readout, the count time doubles to 57.6 seconds.

 

[wfg42438]

That was before you posted the specification that requires three digit 0.1 Mph resolution and accuracy.
I just assumed two digits with 1Mph readout resolution.
In your first post you mentioned 60 Mph, not 60.0 Mph.
To get ten times the resolution you need to count up for ten times as long.

For 1Mph readout you need to count up for 2.88 seconds, but that produces a one count ambiguity. Doubling the time eliminates the one digit random flutter, so 5.76 seconds would be required for a stable display of 1 Mph.

To read to 0.1 Mph those figures increase ten times.
If it reads to 0.1 with last digit randomly changing, that's probably o/k.
Random change between 59.9 and 60.0 or 60.0 and 60.1 is probably not too bad.
If you want a flutter free 0.1 Mph readout, the count time doubles to 57.6 seconds.

My apologies for not posting the specs initially i just wanted to avoid tackling the entire design from the start. I wanted to make sure to concentrate purely on the display portion of the circuit

I agree that fluttering of the decimal digit would be acceptable however this is under an update time of 28.8 seconds which is quite long

I wonder if there's away for me to count at a quicker rate with this set up or something similar that's not too complex

 

[Warpspeed]

I wonder if there's away for me to count at a quicker rate with this set up or something similar that's not too complex

You need 600 counts at 60 Mph with one count accuracy to meet the specification, and there are only 20.8 coming in each second.

Only way to do it is to measure the time interval between arriving pulses.
That part is easy.
The complex part then becomes converting measured time interval back into Mph.

Unfortunately a software solution is not allowed, and while a suitable lookup table for one Mph resolution would be a quite practical size, an 0.1 Mph lookup table would need to be enormous.

 

[c_mitra]

I suspect that the original idea of frequency multiplication and using PLL is not the way to go. As others have already pointed out that measuring low frequencies accurately over a short interval is tricky and better ways exists (measuring the time accurately rather than counting the pulses: this is going to be inaccurate at high frequencies by the way). Perhaps you can use 20 reflectors so that one rotation produces 20 (or even 100) pulses.

 

[wfg42438]

Well, at 60 Mph. in order to read in tenths of an Mph resolution, we need to count up to 600 pulses (60.0 Mph)
As we are only receiving 20.83 pulses per second at 60 Mph, we need to count those pulses for 600/20.83 = 28.8 seconds.

And you will not be able to do that any other way with direct frequency measurement. To read 60.0 you need 600 counts.

A phase locked loop frequency multiplier, in order to get a stable output that is locked, will need to have a time constant of perhaps ten times that, or five minutes minimum, possibly more.
So its actually going to make things worse not better.

You need 600 counts at 60 Mph with one count accuracy to meet the specification, and there are only 20.8 coming in each second.

Only way to do it is to measure the time interval between arriving pulses.
That part is easy.
The complex part then becomes converting measured time interval back into Mph.

Unfortunately a software solution is not allowed, and while a suitable lookup table for one Mph resolution would be a quite practical size, an 0.1 Mph lookup table would need to be enormous.

So it seems we arrive again at the prom solution again

How difficult would it to implement this solution?

Do you feel it would be a lengthy process ?

 

[Warpspeed]

To be able to resolve the difference between say 99.8Mph and 99.9 Mph is about one part in a thousand.
That requires a count coming out of the period timer of perhaps a thousand counts at the fastest road speed to reach that resolution.
If the lowest speed is 1 mph, then about 100 times that count will be coming out of the timer.
So we need a lookup table that has about 100,000 data points.

Its just not possible to calculate the values with a pocket calculator and key in 100,000 data points, it would take weeks of work and you would be ripe for the insane asylum at the end of it.

So you will need to write a short computer program to generate all the data points automatically, and then program that into about a 1 Meg EPROM.
That may be dead easy for you if you have the programming skills and the equipment to do it.
If not, it involves a big learning curve, and it then becomes a project within a project.

The original suggested 1Mph resolution lookup table requires only about at most 2K data points, possibly only 1K, which is about an afternoons work with pencil, paper, calculator, and EPROM programmer.
Quite practical, I have manually calculated and entered similar lookup tables up to about 4K length many times myself.

Is it going to be a lengthy process ?
Maybe no, or maybe yes.

 

[betwixt]

It's a job for a spreadsheet. Do the calculation in the spreadsheet then export the results as CSV. Most good programmers will take CSV data as 'raw binary" input, otherwise it's fairly easy to convert it to .hex format.

Don't forget the second half of the task, the audible alarm. It isn't the best use of components but you could easily use a second EPROM (technically you can still do it in one but it gets complicated) wired with address lines in parallel with the speed look-up table to look up the audio tones.

I have not looked into it in depth but it might be feasible to divide the program so the units and tens are in one EPROM and the tenths and audio are in the other, it allows smaller EPROMs to be used.

Brian.

 

[Warpspeed]

I have not looked into it in depth but it might be feasible to divide the program so the units and tens are in one EPROM and the tenths and audio are in the other, it allows smaller EPROMs to be used.

Those are the exact same lines I have been thinking along, use two eproms with the address lines in parallel.

 

[wfg42438]

I realize A much better solution has already been proposed but i am really curios to see how this counter works before i attempt the proper solution in this thread

Would anyone be so kind to helping me with the problem described in the following thread?

https://www.edaboard.com/threads/353963/#post1514122