VSS Signal assistance?
 

Is anyone in a position to capture the vss signal on a reed switch car (metro, starion)? My scope is on the fritz.

Problem: The vss is too noisy on some cars, need to know what it looks like in order to filter it properly. Plain old debouncing won't work because it seems the vss pulse peak to peak duration is less than your typical debounce period (was seeing 8342 microseconds @53mph, typical debounce is like 20000 microseconds). I added a tiny bit of debounce (3ms) and was able to put a more normal vssPulsesPerMile figure in, but the instant reading is jumpy.

It isn't a problem for hall effect cars because that is not a noisy physical switch.

I wonder if there is noise from the electromechanical parts of the speedometer/odometer? I don't know if I can defeat this problem with software alone. But would appreciate any insights into how to fix this.

Anyone seen a metro ECU schematic? Maybe someone has an old one I can dissect?

Edit, ok I think I have a "debounce" strategy, for dealing with this. I have to change it so it looks for X number of milliseconds in a given state before deciding to increment the vss pulse counter. Only tricky bit is the timing of the pulses should be done on the leading edge, and not whenever the pulse settles down. I think it is doable with the event scheduler though, instead of just disabling the pin interrupt for a given amount of time I will schedule an "increment the counter" event that will get overridden with each junk pulse.

Disregard, I forgot there was an existing laptop .wav file recording of a metro vss, wanna see? It is kinda fugly :)
http://opengauge.org/diympggauge/vsswaveform.GIF

But it looks like the "wait for it to settle down" strategy should work. It looks like just waiting till there is 2 milliseconds of clean signal would do it. But it will start flaking out again above 75mph. 1 millisecond might be enough, but I can't remember the last time I went 75 :) Maybe I will leave changing it to 1 millisecond as an exercise for the user ;)

What about this option on some cars, a add on hall effect. Put 1-2 magnets on halfshaft close to tranny and mount a hall effect like this one. Only like $3 and would put out consistent readings. Hall Effect Switch | Low Sensitivity | Manufactured by Melexis

And all you would need to know at that point is tire size to know pulse rate.
155/80-12 927 rev/mile
1 magnet = 927/mile
8 magnets = 7416/mile
You could attach magnets to large hose style clamp and strap to inner cv joint case.

I have a 'scope - but my extension cord isn't long enough to do meaningful on-the-road testing :). I have an inverter - maybe I can make it all work that way and get some pictures for us. But before I do that, I'm going to put a small capacitor in parallel with the zener and see if I can filter the bounces...

I bet dcb's already thinking along those lines for his motorbike. (He's already got the magnet/pickup installed, in the form of a bicycle computer.)

EDIT: FYI the Audiovox cruise control I added to my car came with a magnet kit for just this purpose - for older cars that may not have a VSS signal.

Ok, I might be overthinknig the vss reed switch bit (LOL). Probably some more code changes before I'm done

But took a dive today with a SG also and mpguino vesion 0.70 and heres where it landed:

odometer: 42.5 miles
mpguino: 42.33 miles
SG: 41.7 miles

So I am liking the distance tracking pretty well, rough indications have it at 0.4% off of the odometer even with the reed switch. Still want to research it some more and retest the saturn to make sure that is still accurate. But if the trip is accurate then I have to look elsewhere for the jumpy instant mph reading.

Looks like the Mpguino is pretty accurate :thumbup:, what car was this on the Saturn?

This was on the metro, the one with the bouncy vss reed switch that has been giving a bit o'trouble (had to double the vsspulsespermile initially). I was very happy with the saturn readings, both distance and fuel consumption at last check, but I've messed with the distance code a bit since then.

Looks like the v.70 fixed the Starion VSS bounce! Pulses per mile = 8204! GREAT JOB and THANKS!

On vehicles that are having trouble with the VSS signal, does the VSS go through the ECM or VSS buffer? And if so, is the signal being tapped after that?

I know at least on mine, the signal from the VSS itself isnt very friendly. Depending on the vehicle, it goes either through the ECM or VSS buffer to clean up the signal, and then feeds the pulses per mile to the gauge cluster and cruise control module. I tapped into that and didnt have any problems once I got my wiring right.

Starions: The signal to the ECM is not pre-filtered. It's a very bouncy/noisy 0-5v signal created by a magnet/reed switch combination at the speedometer.

Just a heads up, I think I made some progress this morning after the NASA guys got me thinking :)

Basic strategy,

keep track of the number of vss pulses (already do that) and accumulate the vss pulse lengths.

every 1/2 second compute the instant mph from the accumulated pulse lengths/number of vss pulses and reset.

I did a quick road test an instant mph is looking a lot better in the metro. Will release a new version when satisfied with it and when I integrate it into instant mpg.

http://farm4.static.flickr.com/3293/...7c5db3.jpg?v=0
Here is the waveform supplied to me from DCB. Placing a filter circuit in there will clean up the extra high speed pulses (small peaks) that may trigger false signals.

There are no known false peaks being picked up though. The chip has built in a differential between ON and OFF detection and there is debouncing to boot. As well as the pulse count seems accurate over large distances, so what are you trying to fix? The extra hardware won't buy you anything at this point.

I would add that as evidence that the fully processed signal is about as good as it is going to get is evidenced by the fact that when you average the readings over 1/2 second it now seems to be spot on and pretty smooth.

So it is accurate over distance, it is accurate on the 1/2 second scale, things will get progressively worse at less than 1/2 second for sure.

Likely, the downslope and upslope are causing the difficulty. They may be triggering a longer / shorter duration between pulses depending on the trigger level. If the average over a half second is good. there is not likely to be a problem in the long term. If one wanted to play with it on their own, there are a few ways to normalize the signal. But if, as you say, the 1/2 second average is good, that is the best solution.

Well, if you like, around position 1159760 in that file, the speed should be pretty steady, but I think you will find that the large verticals are not evenly spaced, likely due to mechanical "slop". The data is all there and you were the one who said it was "easy" :) You might have to look at more than one pulse though.

I just uploaded the v.72 code and the vss instant speed is awesome it is so fluid now, EXCEPT

when I get to 40 mph

then it waits until about 60 mph before it starts counting backward

1, 10, 30, 40, 40, 40, 40, 40, 39, 38, 37


CRAZY

where in the code can I tweak this to get it right?

Hmm.... Maybe

well, If the pulses are unsteady at a constant speed, then the problem is mechanical, as mentioned before. a well lubricated speedo shaft could help, or find another source for the signal.

(The only thing I had at work to see the waveform with was "Windows Media Player")

ac7, I used a way old copy of cooledit. dunno if it still exists.

forgotten, if the changing the vss enable event timing doesn't fix it then I would ask that you set it back to 2ms and then drive with the wonky speed reading and see if distance tracking is still ok at those speeds.

I just took a road test with the stock .72 codebase. Didn't have any issues at 75mph. I didn't have a spot I was comfortable going faster than that within reasonable driving distance. At some speed the pulses WILL be less than the debounce period but I expected it to at least get folks to 80mph @2ms.

Hey there,

My vss code is 32816 (8204*4) and it's very very accurate now that i changed it to 1 milisec. Much better, but at 60 mph the vss reading starts slowing down just like it used to at 40 mph. Sometimes I do go faster than 60 and it messes up, is there anyway I can go lower than 1 milisec?

Also, quick question. I tried creating a timer a while back, and it was only accurate within a half a second, is that just the nature of the clock on the board or my code? If my code, I think I can fix it.

Let me have you try one more thing, I think you are chasing noise with that 32k number.

change your vsspulsesPerMile to 4104
and change the addEvent line to
addEvent(enableVSSID,4 )

and report your findings. (how does the speed signal look, how accurate is the distance over a few miles of driving)



re:timer, please leave it out while we are troubleshooting, ensure you have a fresh copy of .72 loaded.

Didn't work, just made things more wacky

Now the speed reading is about 4 times higher than it should be up to about 25mph then it just starts counting backwards again

Did it effect the distance tracking?

You can also try:
32832 vsspulses per mile.
and
change:
addEvent(enableVSSID,2 ); //check back in a couple milli
to:
enableVSS()


but I'm flying blind here, would need to see the waveform at a given speed and get an answer to the "is distance affected?" question.

Hey now I'd be back where I started if I put that all back in!

addEvent(vssid, 1) works well (super accurate) with the 32 number except when I get past 60 mph

with 2 miliseconds it works well up to about 40 mph then counts backwards

I need to get it under 1 millisecond, but mabey that's not possible?

I do all kinds of driving, I'd really want it to be accurate up to at least 120 mph :D

Mabey mark (with the mitsubishi) will let me use his scope since we're both local
Didn't he have a battery powered one?

edit:

I didnt check if the distance tracking with those other numbers was accurate but I'll try that like you said. However, distance tracking IS VERY effective with 1 miliseconds up till 60mph

I just said how to do it :)

change:
addEvent(enableVSSID,2 ); //check back in a couple milli
to:
enableVSS()


this will call enableVSS immediately instead of 2ms later (or 1 or whatever you currently have in the second parameter).

bwaa! delete, delete

I didn't even read that part

I'm such a dummy, ok I'll try that

Yes, works good like it

but not perfect

If I got it on a scope could we get it perfect?

LOL, no promises. what are the symptoms?

It's pretty good, but I got 10 miles and it shows 9.8

and I'm sure it will get worse over time

but this mpguino keeps boogerin on me I can't keep it running long enough to get anything set up

when sleep mode kicked in, it wouldn't ever wake up, so I disabled it (though I left the screen = nil part, but I should fix that too). But my power connector had a cold sauder point and I fixed that and it runs better now, but it still won't act right sometimes it will restart after trying to play with it after getting in the car while it sits overnightalksdfjlksdaj


I dunno, I'll mess with it tomarrow

and then isolate the problems and let you know If i'm still confused

FYI, I added a setup parameter "VSS Delay ms", you can set it all the way down to zero by using the setup screen. left+right opens the setup screen. That's all I can do for ya with the information at hand.

Was there any further development on this. I am having the exact same issue, but with a hall effect sensor.

See my thread here (http://ecomodder.com/forum/showthrea...tml#post441265). It has the exact same symptoms, 120000 pulses per mile and 0ms vss delay, and it works up to 80mph, after that it starts to drop again.

Is it due to very high pulses per mile, or another issue? Would a signal divider to reduce the pulses work?

Any ideas?