Frequency inputs dont output 0 at 0 input

[disquek]

I setup hall effect sensors to point at the six rotor hat bolts on my front wheels (rears are coming soon).

The output in analysis is as expected when the wheels are moving. When they are stopped it outputs what looks like an arbitrary number.

See the image below for a graph of the issue. I spun the hubs by hand one at a time to get this data.

Any thoughts? 7.5.113 All frequency inputs set to frequency in DL1 config.

-Kyle

[/img]

[Support]

That is correct - at the moment the frequency channels are only updated when we get a pulse input. So if pulses suddenly disappear then you get this effect. For most applications like wheel speed this doesn't happen, so it's not generally an issue.

Support

[disquek]

Thank you for the prompt reply.

Is this something that can be fixed? It seems like a fairly straight forward bug to fix in the analysis tool.

Are you saying that when a wheel speed sensor is used with a dash, you see a random number for speed whenever you stop?

Besides the fact the it just looks rediculous, it makes detecting a locked wheel (which was the goal of my sensor install) tricky and more difficult.

Other issues I can forsee are thrown off averages, minimums and maximums.

Kyle

[midlana]

I'll venture that their sw is setup to count pulses via interrupt, meaning that only on change is it updated. Giving that, it'll always have the last value measured, so as the car slows down, it'll retain the reading last read before seeing zero input pulses.

[Support]

Hi,

Yes - it does want correcting you are absolutely right, we'll think about how to best address this.

Thanks,

Support

[Turby]

What about other channels eg from ECU, do they "suffer" from the same fate when no more samples are received by the DL1, they will also continue to report their last reported value ?

Maybe, a simple method to reset value to 0 after a suitable configurable timeout value has expired for that specific channel ? Or the timeout could be based on the configured reporting frequency...

[Rob Stevens]

I get this also and thought it was something I was doing wrong. I notice that when stationary the Hz will very slowly drop, if you zoom in on this you may see it. What's the fix as this is just silly!

[osborni]

I've never seen a car that goes from 60 to 0 in less then one rotation of a tire. Who cares that there is a residual reading from 2 mph? Six bolts means that 10 hz is some where around 5 mph? ( guessing based on my own setup.)

[disquek]

If the idea is to detect lockup, a wheel can slow VERY quickly.

So the actual deceleration of the car is not relevant.

-Kyle

[osborni]

Wheel lock will show as a transient in the data. It doesn't matter that it's not zero, just that it's much different than zero slip.

But if you are measuring wheel slip, then even six pulses per rev probably isn't enough resolution. There is a reason why most ABS systems use 40+ pulses per rev.

[disquek]

Your arguing just to argue. The feature is broken. It should be fixed.

Time will tell if six targets is enough to measure slip. I suspect that it will be. The car travels only about 10" per target. So several targets should pass the sensor for a given slip event. ABS sensors need to react in real time, hence the large number of targets.

-Kyle

[Rob Stevens]

The point is that when my car is stationary I want to see 0mph, not 2.65mph (or whatever) or is too much to ask?

[osborni]

If I'm arguing just to argue, then you guys are being WAY too picky or not flexible enough with the available tools at your disposal.

Since the only time people do less then 5mph on track is when they messed up, I'm not sure why low speed accuracy matters. If it matters THAT much to you, then use GPS speed, not wheel speed. At least then you don't have to worry about tire diameter calibrations. If it's a street car, then sure a wheel speed sensor is sometimes needed for road certification, but then absolute accuracy isn't THAT important. +/- 2 mph is good enough.

ABS will show up as a transient in the wheel speed reading. Regardless if it's zero or not, it will show up - which is all that matters. A simple way to do an ABS flag in Analysis is to divide wheel speed by GPS speed. Anything other then 1 is wheel slip.

Not all ABS applications are with a fully stopped wheel, some just have 20% slip, not ~5% at threshold or 100% slip at fully locked. To detect THAT, you really need to use a VRS sensor and pickup wheel at 40 or more pulses per rev, not a hall effect sensor.

At least on the wheel speed sensors that I'm using (Cherry), the rise/fall times of the sensor will get saturated about about 130 mph, with more then about 6-8 bolt heads (according to their spec sheet). Obviously, this depends on the size of the bolt head and the radius of the sensor from the axle center line.

So regardless of the intention of the sensor, it's probably close to saturation, which makes details like the original complaint pretty academic (in addition to the other basic issues and available alternatives of the OP's premise).

Additionally, using a pressure sensor (recorded at high enough frequency) can also pick up ABS applications. A decent dual purpose application of a sensor.

Could probably also look at picking up the voltage to the ABS pump or solenoids. Bot that solution doesn't serve a dual purpose.

So there are alternatives.

[disquek]

You're right ... let's forget DAQ altogether. After all, per your post, we can just look out the window instead.

-Kyle

[osborni]

Oh please.

Every DAQ system has it's inherent issues.

Read my post, and not the mutual attitude. I worked through the same issue a couple of years ago and came to the conclusion that 100% accuracy of all signals 100% of the time isn't the point. There is almost *always* an acceptable work around.

I just edited it to explain more. Check the post/rev times.