VSS resetting to 0

[gui67]

CurrentTune.msq

Hello Lance,
I redid my output shaft sensor wiring using a shielded cable as indicated in the manual to try solving the problem. but it comes again.

When I analysed the logs, I saw that the error always comes at an OS speed of 1960 RPM (approx 70km/h).
The VSS falls and Megashift shifts in 1st gear and then up again to 4th
I checked the max error to reset: I am far below that limit. I suspect something else as it occurs always at the same output shaft speed.

here are 2 pictures of logs and my msq. (between the 2, I changed the tire diameter parameter, that is why the speed is different for the samo OS speed.

[gui67]

2 more screenshots

[Bernard Fife]

Gui67,

I just tried your MSQ on my bench, and the speedo is rock-solid here at all speeds including 1970 OS rpm (which i ran for several minutes without issues).

I suspect there is some resonance happening in part of the VSS sensor/wires/circuit, which is why it happens at a particular frequency.

I would first try 4.125 code as a check.

If it is still there, you can revert to your old code if you prefer, and you might try a 10k resistor in line with the sensor.

Also, have you experimented with the VSS input mask and edge capture settings: http://www.msgpio.com/manuals/mshift/V41tune.html#gn ? You might have to try a larger mask value to allow the signal to get through (the general rule is that when the speed drops unexpectedly, the mask needs to be higher, and when the speed jumps unexpectedly the mask needs to be lower), and it may be that the opposite edge of the signal is cleaner.

Lance.

[gui67]

Thanks for your answer Lance,

I will try adding a resistor inline. That problem could be checked with an oscilloscope? I plan to buy a portable oscilloscope in order to use it in the car, would you have any advice? ( DSO Quad for example?)
and your new code too.

I will let you know of the results.

[gui67]

Lance,
I upgraded the soft to 4.125. I did not have time yet to drive it, I will make a tour tomorrow, but I just tried to idle the car and start the engine.

One thing is different then before: I use the leds to tell in which gear the transmission is, before, with the 2.202 soft, when the key is put on IGN, the gears went from 4, 3, 2, and 1
Now with 4?125, it goes from 4, 3 (twice as long as before) and 1.
I checked the led pattern for 2 and 3, they are correct.
Is that normal or not?

Guillaume

[Bernard Fife]

Guillaume,

As long as it settles on the correct gear, it's fine. There were lots of changes over time to this and other things that might affect it, so it doesn't surprise me that it acts differently. As long as it shows the right LEDs when actually in any of the gears, it will be fine.

I do see the second gear LED working properly on my set-up (I just tried it again), but if you post your MSQ, I can try that here to make sure it works for me in all gears.

Lance.

[gui67]

Hello Lance, I tested the car today.
the leds are working OK, the transmission shifts fine, the difference of led display at startup is not a problem.

for the OS speed loss, I still have it, at the same RPM. The only difference is that it only goes down to 2nd, and not to first anymore: 4, 3, 2, 3, 4.
See log below when it did it 4 times in a row. What is stange is that during 4 seconds, the RPM of OS stays at 1854RPM (only not while it drops).
THat was done with 85 % input masking. And I also tested both rising and falling edge. Can I go higher than 100% with input masking?

I will check with a 10k resistor on the sensor wiring too.

[Bernard Fife]

Can I go higher than 100% with input masking?

Gui67,

Yes, It can be from 0 to 200 (this is limited in the INI). Here are some notes from the code:

Code: Select all

	// Calculate periods for VSS/ISS input masking:
	//
    // short_period_mask = average*(100 - mask%/2)/100
    //                   = (icx_per_acc/20) * (100 - (xss_mask/2))/100
	//                   = icx_per_acc * (100 - (xss_mask/2))/2000
	//
	// long_period_mask  = average*(100 + mask%)/100
	//                   = (icx_per_acc/20) * (100 + xss_mask)/100
	//                   = icx_per_acc * (100 + xss_mask)/2000
	// 
	// For example, if you enter 33%, and the current count for 
	// the 20 periods is 1440 (=1440/20 = 72 tics/tooth), then the 
	// mask is set to accept periods from 
	// 72-(33%/2) = 72-(0.165*72) = 60 tics to 
	// 72+33% = 96 tics. 
	// So the range is not based on 100% being no filtering. 
	// Instead, low numbers mean more filtering, high numbers mean less 
	// filtering (the INI limits the range to plausible values, you can 
	// edit the INI to expand the range, of course).
	//
	// Dividing the short period mask by two makes a bigger difference as the 
	// mask increases. For example, if you put in a mask of 100%, it allows 
	// periods from 36 to 144 in the above example, instead of from 
	// 0 to 144 if the 'divide by 2' wasn't used. 0 is any input frequency, 
	// no matter how fast! Instead, the range is half as fast to twice as fast.
	// The permissible mask% is also increased from 100% to 200%. This change
	// should help to more effectively filter the very short 'noise' pulses 
	// at low speeds.

Lance.

[gui67]

HEllo Lance, the problem is still there with the 10K resistor and the new code.
It seems that is does not appear so frequently as before, but I still got it 3 times during a trip tonight. always at the same speed 64km/h, 1890 output shaft RPM, usually when decellerating
I ordered an oscilloscope to understand where the problem comes from. I think I will also try to invert the IS and OS shaft.
I don't have these spikes to 0 RPM on the IS speed.

[tobmag]

It seems I have the same problem here Ive been using the function generator on my scope to simulate the vss signal coming in to the GPIO.
What I can see is that at 500hz and at 1300hz I get a lot of "noice" in the GPIO signal.
At 500hz the siganl is very jumpy looking at the TS log even though the signal coming in is clean, as soon as I put the scope prove on VR1 at the 25pin header it sits straight, see log and also scope pic below taken at the VR1 at the 25pin header

Since the signal coming in to the processor is clean I assume that the code/software filters is self creating these oscillations??