RomRaider

Haven't flashed onto car yet - was really just test driving it to see if the results look similar to what Airboy's spreadsheet was throwing out - and it definitely is. Instead of using the "new.map" file, I just used the excel file writing script, and copied the table across to Romraider, no issues.

Now that I'm slowly beginning to get my head around how the scripts are processing the data, I'll start having a look into the logic and if there's anything specific that I can see. I can't wait to try this out for C/L MAF scaling - that's normally very time consuming.

One thing I did discover, using Airboy's spreadsheet, and quite a significant issue is this - I recently installed bigger injectors, and in tuning the injectors, MAF scale and load comps, I found that my stumble move up by about 200 RPMs - to 3100-3200 - oddly, like the resonance moved up the RPM scale. No matter how much number crunching I was doing on the load compensations, I could not get rid of it - and I knew exactly what it was, since I could see it happening on my wideband gauge - leaning out at that point to sometimes 16 A/F or higher. The spreadsheet, however, was telling me that the load compensations were within 1/2% (and MAF scaling was also very clean - including ranges A to D). Then it struck me - the spreadsheet uses A/F learnt and A/F correction - however, once it hits open loop, these are zero - but the resonance may well still be there. So testing this theory out, I created an 'AF correction' using final fueling to my LC1's A/F reading delta, and another column within 'A/F learning' at zero (since the error accounts for the full correction). Crunching the numbers this time instantly showed a massive lean spike at that RPM range. Plugged these figures in, stumble gone. If you look at the stock compensation maps as well - they extend all the way out to 1.28absolute bar - but the spreadsheet never touches the last 3/4 columns.

I had a few minutes of free time tonight to install Octave and begin merging dschultz's compatibility changes with my own. I want to get a codebase that will run on both Matlab and Octave. Will take me a few more days. Just wanted to let you know I am working on that..

Nil5, if it's not an imposition, would it be possible for you to reversion one of these scripts to also do the closed loop scaling?

As a matter of interest, there is a cruise/accel switch that legaulois found on the AZG201G rom that lets you know when the cruise and when the non-cruise maps are being used (not always neatly closed / open loop) - I suspect that it would allow one to seperately calculate the compensations for the two maps (there is also a cruise/accel ratio which calculates the weighting of the two maps over transition that Merchgod found, but I don't think that's been found on opensource yet).

Nevermind, I managed to quite crudely craft one using the el_comp script as a base. Just changed the script to filter out all open loop, AFR above 16, AFR below 13 and 0.45 engine load, and all stft compensations above 14% and below -14%. Also left the throttle routine in, makes sense to me to exclude any tip-in data with closed loop scaling.

Data looks very similar to what the closed loop scaling spreadsheet threw out,with some variations which I think is due to excluding tip in (I'll double check by removing tip-in routine, theoretically should get exactly the same figures). Spreadsheet took 25 minutes for a 4Mb file - Matlab took 26 seconds. Unbelievable...

I've picked up what I think is an error in the way the data is being averaged / binned.

With the CNT setting at 10, all of the data is being bundled into the -10.6mrp bin (I know this is incorrect, as running Airboy's spreasheet, the spread is very wide across both the RPM and MRP range).

I've been trying to port my scripts to Octave and that's going well, but my goodness, I feel sorry for anyone using Octave. The csvread() function takes foreever.
The Octave guys screwed the pooch on the csvread() function (to parse a csv file). IT is 1000x slower than Matlab. This is a known problem without a fix. apparently they messed it up in version 3.0.1

http://octave.1599824.n4.nabble.com/csv ... 70031.html

Anyway, td-d post up your csv for me to take a look at it. WIth the matlab debugger it should be easy to find the bug.

Hi Nil5

I think I found the reason for the restriction - there are some differences in how you've filtered the data compared to airboy's spreadsheet that lead to it. Specifically:

idx_afr = find( abs(data.afr - data.cl_fueling_target) < 0.2);
data = data_filter(data,idx_afr);

I think is too restrictive when trying to fine tune - also there are values in open loop where compensation happens (transition from cruise to non-cruise - can be identified from logging the cruise / non-cruise value). Reverting to the Airboy approach of filtering AFR's between 14.2 and 15 gave me results fairly close to the spreadsheet.

I know I sound like a broken record, but I'm still blown away by how fast Mathlab is - I've adapted the el_comp script to do closed loop MAF scaling. On an Intel Atom 1.6hz netbook, it took less than a minute for a 12Mb file. Used to take over 30 minutes on a quadcore machine.

I'm now trying to adapt the script to also do open loop, still haven't gotten my head around how to incorporate the correction calculation (open loop target less AFR wideband) into the data struct, scouring the help files!