Reading a wheel speed sensor.

sccoupe

I'm working on reading a wheel speed sensor on a car. I have tested a couple of different ways to read this and tested with a frequency generator(because this is easier until it needs tested on the car) but I get results that bounce around a lot. I havent tested the pulsin function yet because the object warns of cog lockups(not sure why, but i cannot have this). Why is this? Is this supposed to work as well as the BS2 pulsin command? I have used a BS2 and its pulsin command to read a crank angle sensor to accurately read rpm, but never really checked to see what happens if there is no signal. Will I have problems when the car is stopped and there is no signal? I'd like to be able to read the time between pulses to very quickly calculate speed and distance from this. Will the Prop pulsin work, or should I use a bs2 to read the signal and send the results to the prop serially for the TV output? Thoughts on the issue?

Thanks

·

Jonathan

Try a Schmitt trigger to clean up the input. There are frequency counting objects in the exchange, just use one of those.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Jim Fouch

There are two ways to read a speed sensor.
·
One is to count the pulse changes over a period of time and calculate the speed and over a long period of time and moderate speeds·it works pretty good. But at low speed and at shorter reporting periods it will bounce around a lot like you are seeing.
·
Another way is to simply count the time between each pulse. This will remove the bouncing your seeing but will give slower updates at very slow speeds it will take a lot of time for updates.
·
The approach I have taken is to have a counter watch for sensor changing from high to low or low to high and advance the counter. Then I read the counter and use that to know how many rotations I have had. This will make your code much easier because you don't have to dedicate a cog or even worry how fast you scan code works, because the counter is way faster than any speed sensor is. The other side effect is you get the odometer reading because no pulses are missed.
·
I've also used the counters to measure fuel injector pulses to determine fuel usage.
·
·
I may have some sample code, let me know if you would like to see it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch

FOUCH SOFTWARE

Erik Friesen

Here is some code I have used with a schmidt triggered input and an npn. For newer chevys you will have to pass a number larger than 1 for the divide input. They apparently use the abs wheel sensor as the speed sensor. This code will not hang when the vehicle stops but will send back a zero so that the zero shows.

' VSS input sensor
' Version 1.01  w 0 fix
CON
  _clkmode      = xtal1 + pll16x
  _xinfreq      = 5_000_000


Var
long stack[noparse][[/noparse]16]
PUB Start (Pulsecount,Pulselength,divide) 
cognew(VSS(Pulsecount,Pulselength,divide),@stack)
 
pub VSS(Pulsecount,Pulselength,divide)|PW,MPHdivide,counter,cntin
 ctra:=%0_00001_000_00000000_000000_000_000000
 frqa:=1
  repeat
    repeat long[noparse][[/noparse]divide]
      phsa:=0
      cntin:=cnt
      repeat until ina[noparse][[/noparse]17]==1 
         if phsa>80_000_000 
            long[noparse][[/noparse]pulselength]:=0
            phsa:=0
            counter:=cnt-8_000_000
      phsa:=0
      repeat until ina[noparse][[/noparse]17]==0
         if phsa>80_000_000 
            long[noparse][[/noparse]pulselength]:=0
            phsa:=0
            counter:=cnt-8_000_000
    phsa:=0  
    long[noparse][[/noparse]pulsecount]:=long[noparse][[/noparse]pulsecount]+1
    mphdivide++
    if mphdivide>3       'MPH
           PW:=cnt-counter
           PW:=PW/8000         'change to 1/10 ms
           counter:=cnt
           mphdivide:=0    
           long[noparse][[/noparse]pulselength]:=PW
      

The problem with the frequency counters and misc is that you cannot control them and they are so fast that any noise is a problem. I actually coded the above in assembly but found that it worked better in spin because of the nature of the signal.

Erik Friesen

Just curious Jim Fouch. It sounds like we have done about the same thing. I have a trip computer that can measure fuel consumption with about an accuracy of about 1/4-1/2 gallon per tank. I am not using counters however because there is no decent way to compensate for the fuel curve. Or is there?

Jim Fouch

Erik,

I haven't done much with the projects that read the Speed Sensor or Fuel Injector Pulses. But, back when I did they seemed pretty accurate. I don't know what you mean by fuel curve. I simply figured that if the fuel rail pressure stays constant, then the only variable is time. Flow should remain constant with pressure.

On the one motorcycle that I was interfacing to had a two stage fuel injection system. The second injector would only activate when RPM was over 7500 or so. In this system I monitored both injectors. I only did this on one cylinder (there were 4). My basic idea was that the stock ECM would not allow the cylinders to be unbalanced in the amount of fuel supplied.

I may have an oversimplified view of fuel injection, but I was simply looking to create a approximation of remaining fuel. Most motorcycles don't have ANY gauge and some only have an idiot light that comes on when you have .9 gallons of fuel left.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch

FOUCH SOFTWARE

Erik Friesen

A typical injector is open 3 ms at idle on a car. It takes about 1.5ms for the flow to get up to speed because of the weight of the fuel in the injector.

Jimmy W.

Jim Fouch said...

I may have some sample code, let me know if you would like to see it.

If you have that code around still I would love to see it Jim. I am looking to do a similar setup on my beemer htat you have previously done but I am doing to be interfacing it out to some slightly modified standard gauges and a 7 inch vga display.

Would this method would be fast enough for crotch rocket rpm counters as well? 19k rpm?

Thanks,
Jimmy