(obsolete)Feature Requ: Improving Baro reading reliability

[Dennis_Zx7r]

Two things which could be improved:
EDIT2: This has already been implemented without me noticing. Therefore also no longer relevant.
1) During experiments with my previous MS2(Extra), I used custom code written by Robs which essentially was a Mean64 filter. In all the data I gathered, this has worked very well, and much better compared to the currently implemented LagFactors. I therefore suggest using this filter for the baro as standard. I understood from James' comments that there wasn't an option to implement this for the MS2 due to memory limitations, but that shouldn't be the case on the MS3.
For logs, screenshots etc. have a look at this:
http://www.msextra.com/forums/viewtopic ... 10#p484920

EDIT: I no longer think of number 2 as meaningful. See post #3. Number 1 is not affected by this.
2) When a vehicle is moving at speed, there's the issue of dynamic pressure, meaning the barometric reading becomes somewhat dependent on speed.
This can be an issue especially on bikes, as finding a quiet place for the baro can be quite a challenge and speeds casually exceed 250km/h.
For vehicles where baro-corr adds fuel with a lower baro reading this may not be that bad, or maybe even desirable as it's likely that exhaust pressure will drop due to a vacuum at the end of the muffler.
But when baro-corr is set to reduce fueling with lower baro readings (most AlphaN without MultiplyMap I've seen), this results in leaning the mixture on higher speeds.
An easy workaround fix would be a threshold, adjustable by the user, above which the baro would temporarily freeze.
This could be either a speed sensor input ([km/h] or [mph]), or as an alternative for installations without speed sensors [Rpm] (no low Rpm at speed).

[whittlebeast]

How much variation are you seeing in the baro when standing still compared to high speeds?

[Dennis_Zx7r]

How much variation are you seeing in the baro when standing still compared to high speeds?

I actually just falsified my hypothesis while looking up the threshold point where I'd cut off...
Previously, I did some statistics with many logs, which I specifically took to analyse this. There was an obvious, almost linear correlation when plotting GpsSpeed vs. Baro.
All data looked more or less like this:

This specific graph is from september, taken from a single log. It's representative for the other logs.
Statistically, I would have said the baro drops about 2kpa, standstill vs. 160mph. As I just looked up some single pulls from the test, I noticed that the drop is only about .2kpa, a tenth of the value I anticipated. I then looked at several other logs, again for single pulls. 0kpa?! -1kpa?! 2kpa again? This would only fit my hypothesis when cherry-picking data points - not an option.

This is when it finally dawned on me that my method of gathering this data had a fatal flaw... my test track was/is not flat! The correlation which is seemingly obvious in the overall statistics, is due to the fact, that the fast acceleration happened in areas of slightly lower altitude, and more of the slow, or standstill datapoints where taken at elevated levels.

Let's just say, this is a nice example of a confirmation bias... I usually try to falsify my findings way more.
In short, I no longer think of the speed threshold as worthwhile.

---

However, this doesn't affect number 1. I still think using the mean-filter instead of the traditional lagFactor for the baro would be a valuable addition to the package and would be good value for the money/memory.

[jsmcortina]

1) During experiments with my previous MS2(Extra), I used custom code written by Robs which essentially was a Mean64 filter. In all the data I gathered, this has worked very well, and much better compared to the currently implemented LagFactors. I therefore suggest using this filter for the baro as standard. I understood from James' comments that there wasn't an option to implement this for the MS2 due to memory limitations, but that shouldn't be the case on the MS3.

From the 1.5 ChangeLog

Code: Select all

2016-10-23 JSM
Barometer smoothing.

James

[Dennis_Zx7r]

Wow, I did not see that. Thanks!

edit 2017-01-31:
Using Version 1.5 and TS 3.0.18, I just noticed that the setting for adcLF in TS is still described as "CLT/MAT/Battery/Baro lag factor".
In case the algorithm described in the linked thread was used, it should read "CLT/MAT/Battery lag factor" now.
I don't know if this is subject to TS or to the firmware, though.