The evolution of "Tach Noise Filtering" function

[Peter Florance]

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

So far, you haven't offered any proof. You left that up to others.

I won't get suckered into this again.

From now on, if OP doesn't post logs, I'll consider the post "not legitimate" until they do.

[tmbryhn]

Why the big frown? Is my word not good enough as a proof for you with all the detailed description of the problem?
Of course I'll leave it up to others to experience the same issue as I have done - that's the whole point, lol!

I urge you to check my similar post on facebook:
https://www.facebook.com/groups/megasquirtOC/

Took like five minutes until someone responded with exactly the same findings as I did. That was helpful to me because it sheds light on this legitimate bug that needs to be solved.

Again, thanks for your time. I'm sorry that you felt "sucked into" some tricky business. That was not the intention by writing all those long descriptions of the problem...

[Peter Florance]

Why the big frown? Is my word not good enough as a proof for you with all the detailed description of the problem?
Of course I'll leave it up to others to experience the same issue as I have done - that's the whole point, lol!

I urge you to check my similar post on facebook:
https://www.facebook.com/groups/megasquirtOC/

Took like five minutes until someone responded with exactly the same findings as I did. That was helpful to me because it sheds light on this legitimate bug that needs to be solved.

Again, thanks for your time. I'm sorry that you felt "sucked into" some tricky business. That was not the intention by writing all those long descriptions of the problem...

Post a log if you are serious.

[tmbryhn]

How will a log help you when you can read my description of the problem?
I think it's pretty serious all in itself when one would do this for the community to have such a bug fixed by using my time to write such detaled descriptions and testing all firmware version etc. It's called gathering empirical data - log or no log.
All you will see is in a log is the RPM latched to crankingrpm/2 and the error counter stepping up when the error occurs - you won't learn s*** from it!

So you my friend friend should not get sucked into the trend of feeling the need to see a d*** log for every issue out there when words are plenty full, and sometimes better, for describing the issue!

Oh, and by the way, you did not attached an MSQ with your log file, so i have no "proof" that you had noise filtering enabled on the crank channel. Talking about seriousness...

I gets pretty tedious when you don't get believed by people in a community when all you try to do is help out by doing new discoveries that can lead to improvement of the source code.

I'm done with this. I have gotten the response the community needed through facebook; the error is scheduled to be fixed.

Have a nice day

[jsmcortina]

Peter's request is entirely reasonable. Plus I already asked you NOT to cross-post between here and Facebook.

James

[tmbryhn]

Needed some more momentum it seemed ;-)
Looks like it worked. I know the log/msq-rules. But I'm sure you understand my point.

This entire post can be deleted now for all I care.

[muythaibxr]

The bug was entered into the tracker based entirely on communication on this forum. We didn't need the Facebook post. I reported status there based on what had happened in this forum.

In any case, if you're getting sync loss, regardless of how we're dealing with it, you should probably try to fix the root cause instead of band-aiding it with noise filtering.

As far as logs and msqs go, even if you describe the problem, having a log and msq makes it much easier for the developers to see exactly what is going on and duplicate it.

Ken

[tmbryhn]

I did not know of that database and that it was tracked. I did see your post and apreciated it.
I do not have sync loss issues at all in normal operation, but the fact still remains that the ECU latches up when burning to flash because of a temporarily sync loss (RPM > 2700 iaw my findings at least). That's not good. Encoding also become much more robust with it enabled, so imo. everyone should drive with noise filtering with a properly set up curve with respect to their tooth count (period between level shifts on input). Do you disagree on that last point with robust encoding of the wheel?
This discussion is interesting having with those who actually wrote the source code

[jsmcortina]

Needed some more momentum it seemed ;-)
Looks like it worked.

Actually no.

I saw your post on Sunday and made a mental note to add it to the tracker and investigate.

I'm feeling less motivated now.

James

[tmbryhn]

I'm sorry to read that. I'm also sorry that I was not aware of that database for the recorded bugs. I'll keep that in mind untill next time I need to search for errors.
Maybe this can lighten you up; I made a small change in the 3.4.1 source code, recompiled it, and it now works much better. I don't have the same issue any more with noise filtering enabled while losing sync at higher rpm. Now, it only latches for maybe 1/2 a sec at worst for every burn I perform, and it only happens from time to time. Now I can actually use the feature without worriyng

Feel as motivated to improve the code as you'd like ;-) Like I said; you're welcome to remove this thread if you wish to do so

I'm happy that you are aware now, and also that I made a temporary solution for myself. My only wish now is for the rest of the community have an upgrade with this bug removed.

Oh, and if you have not figured it out yet, I'm a VERY impatient guy, hehe! I'm sorry about that.
I guess that's why I try to solve stuff myself.

[muythaibxr]

I did not know of that database and that it was tracked. I did see your post and apreciated it.
I do not have sync loss issues at all in normal operation, but the fact still remains that the ECU latches up when burning to flash because of a temporarily sync loss (RPM > 2700 iaw my findings at least). That's not good. Encoding also become much more robust with it enabled, so imo. everyone should drive with noise filtering with a properly set up curve with respect to their tooth count (period between level shifts on input). Do you disagree on that last point with robust encoding of the wheel?
This discussion is interesting having with those who actually wrote the source code

I actually recommend not using the noise filtering if you can avoid it, especially with high tooth count wheels. It doubles the interrupt load on the CPU, which in practical terms may not cause anything noticable but it's still extra load.

Ken

[tmbryhn]

Yes, that makes sense to me.
Running 36-1 on every setup.
Is there anything I should look out for? Will eg. the injection PW resolution or ign timing suffer because of the extra runtime load on the MCU caused by the noise filtering?
Thanks for cool input. Keep it coming ;-)

Btw, I deleted the thread on facebook.

[muythaibxr]

Yes, that makes sense to me.
Running 36-1 on every setup.
Is there anything I should look out for? Will eg. the injection PW resolution or ign timing suffer because of the extra runtime load on the MCU caused by the noise filtering?
Thanks for cool input. Keep it coming ;-)

Btw, I deleted the thread on facebook.

On MS2, it could suffer yes... on MS3 I wouldn't worry about it.

On MS2 we have done a lot of work to make sure incoming interrupts don't cause a lot of jitter on the spark outputs, but doubling the number of interrupts increases the chances of jitter.

We have tried to keep it below 10 usec of jitter but more interrupts means more going on.

On MS3 the outputs are driven by the XGATE coprocessor, so it doesn't matter what we''re doing on the main CPU, the outputs should not be affected.

Ken

[tmbryhn]

Gotta love the architecture of the more modern microcontrollers.

10usec jitter means that at eg. 6000 rpm I can have a ignition timing drift of as much as 0.36 degrees?
I'm thinking this way:
6000 rpm = 100 revs/sec.
100 revs/sec = 36 000 crank degrees/sec
36 000 / 1 000 000 = 0.036 crank degrees/usec
0.036 * 10 = 0.36 degrees per every 10usec.

Am I correct?

[muythaibxr]

That is not the way I calculate it but I come up with the same answer. You are not guaranteed to have 10 usec of jitter, that is just what we tried to keep it below by keeping the interrupts fast.

Basically if spark is firing in between teeth you are unlikely to see any jitter, but if it fires near a tooth, you may see some jitter.

[jsmcortina]

I investigated this issue earlier. Basically if you lose sync at higher RPM the noise filter was then using the filter setting for zero RPM which prevented correct re synchronisation.

I have been testing a fix on MS2 and MS3 and believe I have a mitigation. If there was a processor reset, then all bets are off. However, a processor reset indicates a more serious electrical problem that must be resolved.

James

[tmbryhn]

No resets here. These tests were done on the bench with no loads only using a stim.

[Peter Florance]

I've only left one installation with noise filter enabled. Felt terrible about it, but ran out of time.
I prefer to understand the problem causing trigger issues; using noise filter just until I can.

[tmbryhn]

You should check out the MAX-circuits (single channel MAX9924, dual MAX9926). Extremely robust VR-conditioning in common mode, iow the sensor is not gnd-referenced like with the stock MS-circuit. They trigger on extremely low amplitude (bout' 20mVpp) and have adaptive threshold and 85ms watchdog timer.
MS3-pro using this if I'm not mistaken?

I'm always using them for VR, with shielded twisted pair all the way. You will probably never have trigger issues again
You should check them out.

[Peter Florance]

You should check out the MAX-circuits (single channel MAX9924, dual MAX9926). Extremely robust VR-conditioning in common mode, iow the sensor is not gnd-referenced like with the stock MS-circuit. They trigger on extremely low amplitude (bout' 20mVpp) and have adaptive threshold and 85ms watchdog timer.
MS3-pro using this if I'm not mistaken?

I'm always using them for VR, with shielded twisted pair all the way. You will probably never have trigger issues again
You should check them out.

I beta tested the MAX9926 on the MS2 Sequencer.

Loading is still important with high output VR sensors.