RomRaider

REV. 2 NOW AVAILABLE

This is a spreadsheet for updating the Speed Density VE Table for the Carberry and Grp N ROMs.

It basically does all of the work and you just import a log.

The user of this assumes all associated risks!

Rev 1.1: Changed from A/F Correction #1 to A/F Learning #1 for less tuning downtime
Rev 1.3: Incorporated A/F Correction and A/F Learning
Rev 2: Incorporated adjustable RPM and MAP headers, added tolerances when running data for RPM and MAP, hit counter in progress

ryan: quick question

looks like the main input data is rpm, map, and af correction 1 (aka, stft).

does af learning 1, aka ltft, have to be disabled in order to provide the proper fueling information?

thanks
ken

It shouldn't. At least I haven't done that. Just through repetative use of this sheet my learning has gone towards 0.

Feel free to try disabling the learning and let me know how that works. That might decrease the number of necessary reflashes.

Would you suggest that I also take into account a/f learning? I think that is an easy fix

You should definitely take into account AF learning. That is the average of correction over a longer period of time.

Alright thanks for the input guys. I'll revise it.

Do you want af learning instead of af corrections? Or would you like to see both of them?

Edit: Rev 1.1 up.

Rev 1.2 incorporating both af learning and correction tonight when I get home from school

Very nice spreadsheet, you would want to include AF learning & AF correction. They should be multiplied together to get a final compensation. EX. AF Learning is 5% and AF Correction is 7%, so 1.05 * 1.07 = 1.124 which is the multiplier that needs to be applied to the VE map.

Thanks! That was the exact info I was looking for. I will amend the sheet this afternoon and post up one that takes both into account

cool, very nice. thanks for the work, ryan.

ken

Hurry up, nerd, I'm ready to use this now!

New Rev is up!

Future Revs will involve trying to consolidate my code so it doesnt take a year to run... :/ sorry about that!

note: it doesn't seem to like openoffice calc.. in particular the macros. i'm an openoffice noob tho, so maybe it's something i'm doing/not doing. i did enable all macros in the options/security/macro security, but still no go.

i'll install excel some time this morning...

I will look into it. Thanks for letting me know.

I am going to try and make the sheet filter out the 0% throttle data as well as tip in data that way there is nothing skewing the corrections.

runs fine in ms excel, btw.

did my first iteration and it seems to be working.

will know more tomorrow.

So I've done a good bit of logging over the past 2 days, and I've used the spread sheet a couple times now. Working pretty well, it seems... but I think it's a bit inconsistent, and there are some pretty big jumps (like 10% ve from one cell to the next). The weather has been basically the same over these 2 days, and IATs haven't varied much...

Yesterday I was logging to via my laptop, and I was selective about the data I recorded (no abrupt throttle changes, no OL, etc.). Today, I was logging to an SD card, and it was set to log any time coolant temp was above 170*F...thus, it recorded pretty much everything.

I was talking to Ryan, and we had already decided yesterday that filtering out data where tip-in correction was appllied would be a good idea. Today, we began to wonder if, perhaps, we should be logging OL/CL status, and discarding all OL data as well. I could be mistaken, but I thought that learned fuel corrections were applied to OL. If so, it seems to me like using that OL data would skew the results. Thoughts?

Would be good to filter out high air and coolant temp, OL and tip-in. I normally also log cloosed loop target and filter out data <14.6 and >14.8. I filter out afr <14.6 and >14.8 too.