wfg42438
Member level 3
- Joined
- Jun 29, 2015
- Messages
- 54
- Helped
- 0
- Reputation
- 0
- Reaction score
- 0
- Trophy points
- 6
- Location
- California
- Activity points
- 620
1250 Pulses/min = 60 MPH
This works out to 21 pulses per second.
How often do you wish to update your display? Is 3.47x per second reasonable? Seems to me your job is easier if you were to do it that way. Take the count every 0.288 second. That automatically gives you the mph (although it's divided by 10, and an integer). You'll need to do some fancy arithmetic to have a more precise reading.
This works out to 21 pulses per second.
How often do you wish to update your display? Is 3.47x per second reasonable? Seems to me your job is easier if you were to do it that way. Take the count every 0.288 second. That automatically gives you the mph (although it's divided by 10, and an integer). You'll need to do some fancy arithmetic to have a more precise reading.
If a microcontroller is completely out of the question, then it becomes much more difficult to get really good results.
At low road speeds, the pulse frequency will be so low that the PLL is going to need a very long time constant, and readings will either be painfully slow to change, or there will be annoying jittery fluctuations in the readout.
Another totally different approach to all this might be to convert the incoming pulses to a dc voltage, then use a digital voltmeter to display the speed.
Say 6.00 volts = 60.0 Mph.
20.8Hz = 6.00v
One way to convert frequency to a voltage is to use a frequency to voltage converter chip (tachometer chip) running at ultra low frequency. That is probably the simplest approach that I can see having a chance of working reasonably well.
Hello Tony,
Unfortunately the specifications state microprocessors cant be used and the MPH reading needs to be displayed on seven segment displays
I actually have dreams about some of the projects you guys have.
Anyhow, woke up with another idea, purely digital, no microprocessor, and seven segment readout. Fast update, and VERY accurate...
Brad has the right idea in post #3
Start out with a fast accurate clock that runs at exactly 512 Hz. This can be obtained from a 32,768 Hz watch crystal divided down by 64
Feed this into a twelve stage ripple counter that is reset to zero on the arrival of each of your incoming pulses. In other words time interval measurement between the arriving pulses.
At 60 Mph we have 1250 pulses per minute or 20.83 Hz
The ripple counter will count up to 512/20.83 or 24.57 counts. (it will be either 24 or 25)
At 1 MPH the pulses will be sixty times longer or at 0.347Hz. The ripple counter will count up to 512/0.347 or 1475.5 counts.
The ripple counter data even at only 1 Mph will update about every three seconds. At 60 Mph or data updates 20 times per second.
Now what we do is connect the 12 parallel outputs of our ripple counter into an EPROM. A 27C16 has twelve address lines.
We can program a lookup table in the EPROM such that the eight output bits drive two seven segment displays via an eight bit latch.
The EPROM lookup table can be programmed to give speed readout from 1 Mph to 99 Mph in 1 Mph steps.
This basic idea could be improved to force the display to 00 Mph when stationary by using ripple counter overflow.
A further embellishment could be re arranging the eight bits from the EPROM to drive three seven segment displays. The upper three bits drive the MSB which only need go up to seven. And the lower bit can drive an LSB digit that is either 0 or .5 Mph.
So we get 00.0 Mph to 79.5 Mph readout needing only eight bits from the EPROM.
All this should give a very accurate speed reading with 0.5 Mph resolution and a very fas update at any practical road speed.
Another advantage of this is that period counters always have a one count ambiguity. The last digit flickers between counts.
By using a high pulse count (25 at 60 Mph) our lookup table effectively eliminates the flicker problem, because all the values either side of 25 counts will read 60 Mph.
In fact the EPROM should be programmed to read 60 Mph anywhere between 59.5 Mph and 60.5 Mph. So the LSB digit flicker problem is gone !
Out of curiosity and time constraints do you at all think what i proposed on post 5 would work??
Out of curiosity and time constraints do you at all think what i proposed on post 5 would work??
Well at 60 Mph we have 1250 pulses per minute.
Or 20.8 Hz
If you count up for only .288 seconds (3.47Hz), at 60 Mph, the count will be randomly either 6 or 5, and I cannot see that as being very useful.
If you count up for 2.88 seconds, the count will fluctuate between 60 or 59.
Three second update is fairly slow, and the reading will jump around randomly by 1 Mph at any speed.
To get rid of the random jumping you could slow down to a 5.76 second update, and ignore the jumping LSB, which would work, but is a painfully slow update.
But you will get 1 Mph resolution that way.
My proposed system updates much faster, 20 times per second at 60 Mph, two times per second at 6 Mph, and has much better resolution (0.5 Mph), and no random jumping. It would show a rock steady reading at any speed.
Its more complicated, with more parts, but its about the best result possible without using a microprocessor.
First thing, what test equipment do you have
available ?
At the very least you are going to need something that generates some
pulses to test with, from zero up to about 28 Hz.
An oscilloscope and frequency counter would be pretty essential things
to have access to as well.
Three digit readout is specified with one decimal point accuracy (+/-
0.1 Mph) which is going to be very difficult requirement to achieve
with ANY frequency measurement method without the speed update taking
forever.
Only practical way to tackle this problem is by using period
measurement, not frequency measurement. Its also interesting that a
PROM is allowed in the rules, which solves the problem that period
measurement produces a reciprocal result.
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.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?