The evolution of "Tach Noise Filtering" function

[tmbryhn]

I'm currently confirming a problem I experienced down the road by testing different firmware versions in my MS-ECU test bench:

My current setup:
Dual tach input with MAX9926.
36-1 crank- VR-sensor
single tooth cam, VR-sensor

When I made the jump from 3.2.5 to 3.4.0, I experienced that if I had a loss of synch, either by burning to flash or because of noise on the VR sensor lines while the noise filtering was activated in the .msq, the firmware latches into 150 RPM as shown in TS, and wont read the actual tach pulses coming from the conditioning circuit, that is untill the actual RPM drops below about 2700 RPM.

So, if the RPM while operating the vehicle is <2700, I can burn and loose as much sync as I want without the ECU firmware locks up into 150RPM, but if the RPM is >2700, the problem is always accuring.
Very frustrating!

I have now testet each firmware version from 3.1.0 and up to 3.4.1, and the problem is only found in the newer firmware versions ranging from v. 3.3.2 and upwards to todays 3.4.1.
3.3.2 is also the first version, afaik, that uses the new TS layout which I like better.

Consequently, I now have to run firmware 3.2.5 or older for noise filtering to work without making me have to let the RPM drop in order for the ECU to re-sync with the actual encoded signal.

Can someone shed some light on this problem? Am I overlooking something?

Attached is a MSQ that I use in my test bench to make this problem appear while feeding the processor with a simulated 36-1 signal of various frequency (speed) on a single channel (crank only)for keeping stuff as simple as possible.

Thank you guys!

[tmbryhn]

I just discovered that the RPM gets latched to crankng RPM threshold/2, so if it's set to 300 in the MSQ, the RPM latches at 150.

[Peter Florance]

This seems familiar. I'm not sure I had noise filtering on when I saw it.
Subscribed.
If I find anything, I'll post back.

[tmbryhn]

Is it not strange that none of the developers out there have at least made a reply on this yet?
I can't imagine that only two people are having these issues.

If I have posted in the wrong category, I would appreciate if someone could direct me to the right place.
I'm not used to posting in these forums.

Hope that we can get some input on whats going on with noise filtering on newer firmware releases of MS2-extra

[muythaibxr]

I am not immediately aware of anything having changed that would affect this.

[tmbryhn]

Well, something have without a doubt changed, since the noise filtering works like a charm on version 3.2.5 and earlier, while it quite clearly does not work on versions newer than that, eg. the latest v.3.4.1
Exactly the same setup have been used throughout the specific testing of this issue, and the results are consistent.

I'm happy to discuss solutions or being pointed in any direction that might help solving this problem.

[Peter Florance]

I think the only thing I noticed is on 60-2 wheel, if I turned on stim at high RPM, it MS2 got stuck at some low RPM.
I'll see if I can duplicate.

[tmbryhn]

Awesome!
It happens on my 36-1 signal at least. Running rising or falling edge does not matter - the characteristics are the same.
I discovered, like mentioned above, that it gets stuck at crankinRPM / 2. So if your crankingRPM is set to 300 (default setting), it should get stuck at 150.
When I changed it to say 600, it got stuck at 300. Same result every time.
It's important to keep in mind that this happens, for me at least, every single time the encoder running in firmware looses sync.
That happens normally every time you burn to flash or actually disrupt the tach pulses going to the microcontroller. For me, it happens at rpms greater than 2700 rpm, but that may alter with a different tooth count perhaps?

[Peter Florance]

I thought it was just my setup and it seemed unrealistic that a car would start that way, but I'm pretty sure it does happen.

[Peter Florance]

I've got an MS2 on the bench. I can log in the morning

[jsmcortina]

For info, 3.3.0 release came out in November 2013. It sounds like you have discovered a genuine issue, but the fact that nobody else has reported it in two years doesn't rank it as very high priority.

James

[Peter Florance]

For info, 3.3.0 release came out in November 2013. It sounds like you have discovered a genuine issue, but the fact that nobody else has reported it in two years doesn't rank it as very high priority.

James

It probably doesn't happen on cars, is my guess.

[tmbryhn]

Thanks for replying, James. Do you see any solution on top of your head?
Could some old working code be implemented in the newest version?

Yes, I think that's strange that no one have reported it. Noise filtering function is a must have for making the encoding as robust as possible imo, even if you don't have tach input problems on a regular basis.

And yes, like I said in the first post, I experienced this down the road in my car every time I burned in the new tables while cruising at the highway (rpm>2700), which made me wanna do further investigation on the issue ;-)
The firmware encoder only see transitions between 0-5V, if the ECU is in a car or on the bench is irrelevant in this case ;-)

[Peter Florance]

I captured this. Will upload shortly.

[Peter Florance]

I captured this. Will upload shortly.

Beginning is stim switched on at 1000rpm or so. Then I set rpm to zero and bring rpm back up without power down

I'll post MSQ shortly; it's a unit I'm modding for a user.
60-2 wheel with cam.

[tmbryhn]

Did you try burning to flash while in high RPM and observed what happened with the noise filtering enabled?
Did you experience the same as I did?

[Peter Florance]

Did you try burning to flash while in high RPM and observed what happened with the noise filtering enabled?
Did you experience the same as I did?

No, I had limited time to play with it. Can you post a log of that?

[tmbryhn]

There is no point of logging it. The problem is best experienced during normal usage with TS.
I thought that was pretty clear from the above posts, and also the fact that I did not bother posting any logs of the problem.
You should do this real time in TS and see what happens.

Set the RPM to say 5000, do a change and burn it to the ECU. Then check what happens with the RPM gauge.

[Peter Florance]

I won't have time to do any more with this. I'm not a dev, just experienced user.

[tmbryhn]

I know, me neither. Just needed someone else to duplicate the test and confirm that it's a legitimate problem with the firmware.
It should have been a rather quick test with no logging mandatory.
Thanks for your time