MSgpio.com read only forums (Jan.15,2018)

Lance.

How do the VSS filtering work today or what is it that we really filter out?
Since Im also using MSII and MSIII I'm familiar with the filters used for the iginition triggers.
http://www.msextra.com/doc/ms3/ignition ... html#noise

These filters work really good and you can actually set the filtering by rpm as well.

For the VSS I assume (without having any back up data) that you will needa a quite aggressive filtering at lower speeds and much less on higher speeds.

Wouldit be possible to get someting similar to MSII/III ?

BR//Tobmag

Tobmag,

The filtering mechanism is described here: http://www.msgpio.com/manuals/mshift/V5tune.html#gv. The filter affects triggers that are significantly different from the average of the last 20 teeth (how different depends on the masking value used).

The VSS filtering is is speed dependent in the sense that slower speeds have wider acceptable VSS periods, and faster speeds have smaller acceptable VSS periods. But these are always in proportion to the current average period. But there is no mechanism to change this proportion with speed.

I have seen no good argument to suggest that VSS masking should change as a proportion of the current period. However, altering the proportional filtering based on the output of the proportional filtering can do some odd things to the final value because the final speed and VSS input can interact in unexpected ways in some conditions if the filtering is non-linear.

The code does let the user 'correct' the speedo at different speeds. It multiplies the raw speedo value (the averaged result of the VSS filtering) by a percentage to calculate the final speedo value. The factor can be up to ±100% (where 100% is no correction). For example, if you get a speedo value of 110kph when you know you are doing 100kph, you can put a value of 91% (= 100/110) in the 110 bin, and the raw value of 110 will be adjust to 100 kph. This can be used in addition to filtering to account for a number of things, including false triggering, etc. You can read about this here: http://www.msgpio.com/manuals/mshift/V5tune.html#te Note that this scheme doesn't alter the VSS filtering based on the speed, so there is no chance they can interact in odd ways.

Lance.

Tobmag,

Would I could do is put an option in the MShift code for the trans controller to use either of the internal GPIO VSS input or alternatively use the engine controller's VSS input, at the user's preference.

That would free up an additional input (on either MShift or the ECU), which makes some sense.

We will look at adding this to the 5.00x beta codes in an upcoming release.

Lance.

Lance.

Ok I think I understand how it works now.

Problem is that the behaviour I can see in my logs doesnt follow any logic.
In this screen we can see that Im on the break decreasing speed and when just coming to standing still I get a huge jump in speed!
This is also a odd behaviour, cant see any reason for the upshift to 3rd not even close in my shift table either....actually MAP is decreasing Here we can also see when taking off from standing still, the output speed accelerates by it self....well if the car really could do 0-50kmh in 2 sconds I would be very happy
Im not sure about picking up vss via the CAN bus, havent checked the filtering in TS for that actually.


BR//Tobmag

This is not due to noice in the VSS signal, I checked before with the scope having the car on stands....VSS is noice free.

BR//Tobmag

Here is another one, seems like the signal start sp self oscillate..... and then completlty smooth......
Hmmm make me wounder

//Tobmag

Tobamg,

I can't say why the unexpected shift happens without a full log (not a screen shot). The log contains much more information about what the controller is doing and why than any screen shot, and is much, much smaller (if you only post the relevant section(s), at least).

I also can't see whether you are accelerating or decelerating from the pics, I can only see the VSS signal (braking or not can be misleading, because some people do use the brakes when the wheels or accelerating, such as during a burn-out, etc.). So it's better if you post a short excerpt from a log and then describe exactly what is, or isn't, happen in that section of the log (ideally with references to the time stamps).

You need to post the MSQ used to make the log too, it's the only way I can test if the code/settings are the problem on my bench (and I wouldn't assume the MSQ used for this datalog is the same as any other you might have posted recently).

For the VSS going up when the speed goes down, it is likely that there is noise triggering the circuit. This may be external, or it may be internal. It doesn't really matter, as it has to be filtered. The VSS filter has a minimum speed below which the signal is ignored. This sets the minimum allowable frequency for the VSS. It also has a maximum speed to limit the upper frequency. Have you tried narrowing these (increase the minimum and decrease the maximum)? Since you are seeing too many triggers, have you tried reducing the VSS input masking setting? Have you tried triggering off the opposite edge of the signal (usually one edge of a VR signal is cleaner than the other, but it's hard to say in advance which will be better).

You could also try increasing the Max. Errors to Reset, and reducing the Reset Filter Off time. These will reduce the periods during which filtering is disabled, prevent VSS run-away.

These are all described here: http://www.msgpio.com/manuals/mshift/V41tune.html#gv

You can also try putting a 10K Ohms resistor across the VR sensor wires. This can help dampen fluctuations in the signal when the period gets long. Or you might try a diode in-line with the signal to eliminate small signals completely.

If none of that helps, you could increase the trigger threshold voltage as outlined here: http://www.msgpio.com/manuals/mshift/vss.html or some of the other tips.

Lance.

Lance.

I have tried a lot of different settings in the filters, raising and falling edge, I have a 100kohm in line with the vss, smooths things abit.
I did chanage the bias resistor to 200kohm, made things a bit smoother then I tried by adding another 100kohm in parallell but then the signal became really unstable/jumpy at lower speeds so 200kohm seems ok.

I dint try setting the minimum/maximum speeds
Didnt change anything on the Max. Errors to Reset, and reducing the Reset Filter Off time

I can post the logs but I didnt save the msq for each log so....need to do that in the future
There are no big changes, did move aound a bit with the gear shift table

BR//Tobmag

hmm seems like the log is to big.....dont know how to cut them....

BR//Tobmag

Tobmag,

I tried your MSQ (2013-09-0112.16.27.msq) on my bench, and I can find no run-away speedo instability at all between 0 and 77 kph (41 to 584 Hz on my function generator). It is very stable. That doesn't mean you aren't seeing an issue that's need to be solved, but it does mean were have to look more carefully.

All of the filter factors necessarily interact, so it's a matter of finding the right combination. For example, you might have to lower the filter factor or the lowest speed, but doing both might cause problems in some set-ups. Or other setups might need the opposite. It would be relatively easy to set the VSS code up so that it worked for any one set-up, but it has to work for many vehicles (including ones that are different from anything ever produced by an OEM), so unfortunately it is more complicated.

To cut a log down in size, you can use any text editor (notepad.exe in windows, vim in linux, or similar; I use notepad++).

Leave the header in place at the beginning of the file, it will look something like this:
Then remove as many full lines in as many places as you like. A full line will look something like this: Where 1316.381 is the time stamp added by TunerStudio, and 191 is the controller seconds, etc.

You can remove as many lines as you like, as long as you keep the remaining ones in order. Then save the file as a new name (so you don't erase the original log file).

However, if you remove lines in patches all over the place, it can be hard to follow the sequence of events in the log viewer, so it's generally better to leave just one section (and create a new file if you want to edit the original again to save another section).

Lance.