How to read Speedo at low speed

[l_gaminde]

Is it not possible to use the factory sensor? As it's already in the gearbox, and it is what the factory auto computer uses.

Let me ask why not, two units can read the same factory sensor!!

You said you had a sensor ( never said what kind of sensor ) you need more pulses how can you use this sensor and get more pulses? what metal are you sensing on the shaft ( hall effect sensor and have magnets ) or is it a gear tooth sensor or what. You could use a hall effect sensor and mount maginets on the shaft you could use 1 or 30 magnets and get the pulses you need.
if its a gear tooth sensor pull the plug on your rear end and see if you could mount a sensor to sense the teeth on the ring gear, gear tooth sensors are about 35 bucks.

now back to the factory setup Many of the PCM's have an output that can be used by a PIC, 2000 or 4000 Pulses Per Mile would this be enough.

[Darrel Taylor]

At low speeds, the time between pulses becomes more important than the Number of pulses per second.

That value is easiest to measure with the CCP module in "Capture" mode, using Timer1.

This way, the minimum refresh time for the speed value is only limited to the time between pulses, instead of a number of pulses across a fixed time base.

The low end can be extended by counting an Upper WORD for Timer1, giving a result with a resolution proportional to the circumference of the tires.

Not easy stuff, but PULSIN or COUNT won't do it.
<br>

[l_gaminde]

Darrel
Most of this is true

At low speeds, the time between pulses becomes more important than the Number of pulses per second.
True if your measuring per second maybe not if your measuring a pulse between two teeth and there are a 100 or more per revolution.

That value is easiest to measure with the CCP module in "Capture" mode, using Timer1.
This is a great way to do this, and just what the module is made for! I have used these modules in this way for other projects (laser speed trap which included vehicle counting and direction of travel).

This way, the minimum refresh time for the speed value is only limited to the time between pulses, instead of a number of pulses across a fixed time base.
This is true for the count command not sure pulsin would affect it as much since it is measuring time between pulses again measuring time between two teeth of hundreds per Rev.

The low end can be extended by counting an Upper WORD for Timer1, giving a result with a resolution proportional to the circumference of the tires.

Not easy stuff, but PULSIN or COUNT won't do it.

I have done a number of Speedos including a calibration setup for different size tires / gear ratio changes, But it was only doing speedo and odom / trip odom and had far less time constraints on it. It could still be done using the current OEM sensor in the transmission / transfercase these are mostly freq out sinewave units which are easly adaptable. This could be done with counter module and timer, or just maybe using pulsin depending on the amount of overhead for the other stuff.

[l_gaminde]

Darrel Yes I am viewing drunk so this may be wrong

120 mph = .000125uS per pulse
60 mph = .000250uS per pulse
10 mph = .001500uS per pulse
6 mph = .002500uS per pulse

(needs to be rechecked) this is with 4000 pulses per mile
now if you use 20 MHz you have .000002uS resolution.

[Darrel Taylor]

Darrel Yes I am viewing drunk so this may be wrong

At least we're on the same page ... but my numbers look a little different.

If the distance traveled between pulses is 61cm, and there are 100000 cm per kilometer.
Then there will be 1639 pulses per kilometer (100000 / 61).
At 120 mph (193 kph) you will recieve ~316327 pulses per hour (1639 * 193)
That's ~5272 per minute. (316327 / 60)
Or ~87 per second. (5272 / 60)

Which leaves each pulse period at 0.011494 Seconds per pulse.

Hmmm lets see ... compare that against .... 125 pico seconds at 120mph. uuuhhhh, must be Pabst Blue Ribbon.

120 mph = .000125uS per pulse
60 mph = .000250uS per pulse
10 mph = .001500uS per pulse
6 mph = .002500uS per pulse

[l_gaminde]

Darrel
look if your drinking Pabst Blue Ribbon, then you need to redo you calcs in MPH !

[Darrel Taylor]

I thought you were drinking the PBR.

Cause there's no way you'll get pulse periods of 125 pico seconds (.000125uS). And you wouldn't be able to read them if you did.

With 4000 pulses per Mile ...

At 120 MPH, you'll get 480000 pulses per hour (4000 * 120)
8000 per minute. (480000 / 60)
133.3 per second (8000 / 60)
which is a pulse period of .0075 Seconds (1 / 133.3)

That's 7.5 mS per pulse.<hr>
However, let's go back and take a look at davewanna's question.

It's giving 1639 pulses per kilometer.
Moving at 5 KPH, you'll get 2.28 pulses per second (1639*5/60/60)
That's a pulse period of 0.439 seconds.

Now with Pulsin at 20mhz, the resolution is 0.000002 (2 uS).
The maximum count for Pulsin is 65535 for a total time of 0.131 seconds.

The Pulsin will have timed out long before it could measure the pulse.

If we take the longest pulse that Pulsin can read 0.131 sec.
It would be 7.6 pulses per second (1 / 0.131)
457 pulses per minute (7.6 * 60)
27466 pulses per hour (457 * 60)

Divide that by the pulses/km (27466 / 1639 = 16.75 kph).
Anything slower than that, and you cannot read it with Pulsin @ 20Mhz.

Whew,
I think that deserves a Corona. <hr>

ADDED:

But, since davewanna is running at 4 Mhz, the Pulsin resolution is .000010 (10 uS)
A "full count" for Pulsin would be 0.65535 sec. (65535 * .000010)
Or 1.5 pulses per second (1 / 0.65535)
91.5 per minute
5493 per hour
For a slowest speed reading of 3.35 KPH.

At this point, I have to think that the "61cm of travel per tailshaft revolution" may not be correct if you can't read anything below 21kph.
<br>