Nistune Forums

Matt,

First, why is the boundary value set to 49 when counting the number of values for a given location ?
e.g. playing at high speed a log file, I noticed that in idle regarding the count in 800rpm / TP=7 box:
..... 47 48 49 1 2 3 4 ... 17
Absolute values per box would be more useful to achieve consistent statistics !

Second, more than the average, you should add the standard deviation calculation (with a given threshold as input parameter). It will allow us to know how many values are around the average and then a level of confidence
At the moment, average is more or less useless because when you have "free air" values spoofing the real AFR values(= AFR 32 (rounding you did) for Innovate or at least > 20.9 or 209) it corrupts the average ....

And more than that, you should also specify the AFR central value around which, the maximum number of AFR values are concentrated. Such approach removes the problem with AFR=32 values because only few of them appear in a log in the overall map.

Amount of sensors was increased in the 0.10.x versions and consumed a lot more memor. eg 50 x sensors x 50 samples currently, but before was 1000 samples stored, took 50,000 words of memory (!)

So I've pulled down the sample count to 50 and once hits 50, take the average and then use this as the base for the next bunch of sampling (50 samples). But this loses its weight over time so needs another approach... agreed

Currently in AFR logger I have trigger conditions. I need some extra 'outlier' detection to avoid poluting the average with these unnecessary values

Is it really too much memory today ?

Keep it mind the standard deviation approach.

Nistune went from something like 70,000KB to 150,000KB in task manager when allocating that much memory on the stack for the sensor data

Might increase it a bit more or dynamically allocate memory only for those sensors which need it which would reduce the total amount required. Then apply weighting to the wraparound use of average data

Please do something here, having accurate averages and counts is the top one priority.

So you need 80.000kB just for the allocation of 50k words (16 bit i presume?). In theory that should only take 100kB, which is peanuts for any computer these days. If it takes more then either you have a very bad compiler (can imagine some compilers use word-alignment on 32 or 64 bit boundaries, but that still would take less than 1MB) or there is something wrong in the coding of nistune.
Block memory allocation is the key here. Stay away from classes when trying to do efficient memory management.

Not sure but will need to look into it. Just a simple array of a structure. Will look into it

Any news ?

Havent got to this one yet. Will up the priority on it

Resolved for next build
http://www.nistune.com/mantis/view.php?id=90