suggestions on reading a pulsing vehicle speed sensor?

[droptail]

Are PULSIN and COUNT the only options for reading a pulsing vehicle speed sensor input?

It seems to me COUNT could be a better choice since it has a built in smoothing function by counting a multitude of pulses over a given period, as in pulses per second.

My issue's are one of data smoothing from a noisy (motorcycle) environment.

I am using a 16F716 PIC.

Thanks

[mackrackit]

This might be helpful.
http://www.picbasic.co.uk/forum/showthread.php?p=83582

[Archangel]

Are PULSIN and COUNT the only options for reading a pulsing vehicle speed sensor input?

It seems to me COUNT could be a better choice since it has a built in smoothing function by counting a multitude of pulses over a given period, as in pulses per second.

My issue's are one of data smoothing from a noisy (motorcycle) environment.

I am using a 16F716 PIC.

Thanks

Hi James,
It strikes me as a little funny, that Dave linked you to my tach program where I took the easy road and used count. A better way might be to use a timer and count interrupts. It really depends on what you are counting, and what else you expect the PIC to do. If it is just a tach then count will likely do. If you need to use the data and do something else then timer interrupts will be more satisfactory.

Noisey motorcycle environment . . . Well let's see, basically unregulated alternator, EMI from the ignition system, lots of vibration, all this means is you will have to use all the "best practices" when you design and assemble your circuit, power regulator with filter caps and a choke, put it in a metal box and ground it to the battery {altoids tins see a lot of action as chassis boxes) a ferrite bead on any input pins are cheap suppression, snubber diodes on any outputs controlling inductors. Take sure to seal the box from moisture and oil, Some foam around the PC board is pretty good insurance against vibration, as are SMT components.

[Acetronics2]

Hi,

The counting method will mainly depend on the input pulses frequency ...

COUNT need lots of ... counts and if pulses frequency is low ...

Response time is very slow ...

One must try to make a PERIOD measurement, then. and better calculate a mean value over some cycles ...

the thing I like to do is have a big counter and fill it with sum of period samples ... so the sampling time remains quasi constant.

few long samples if engine runs slow, many short ones if engine runs fast ...

I also use a switchable 1:10 divider ( a 4017 ! ) upon the RPM range ...

This way, I had realised a model plane RPM meter ranging from 43 to 32,000 rpm ... with more than .1% accuracy and an acceptable response time ...

The interrupt way is trickier, because of false triggering to avoid ... so, a very well designed input stage has to be used ...

But it's the fastest response ( for shift Lights, i.e. when max. engine accel. is looked for ...)

Alain

[mackrackit]

I figured the COUNT example would be the easiest to get started with.

As for the low or high frequency issue, have two or three sub routines.
If COUNT is X,Y,Z goto a routine with a different COUNT PERIOD.

That's my story...

[Bruce]

Are PULSIN and COUNT the only options for reading a pulsing vehicle speed sensor input?

Do you need to count the number of pulses in a given period, or measure the width of a pulse/pulses?

[Acetronics2]

Hi, Bruce

If it is a for a speedometer, the " basic info " is pulses per km or mile ...

now , knowing how many pulses per km ( generally written on the odo dial ...) , you easily can transform period to kph ...

the question then turns into ...

" what to read ??? " ... km or kph ???

looks kph or mph was the initial request ...

Alain