TD_D mod journey. From stock to the 'bastardmobile'

[Td_d]

So if I'm getting this right, and I am comfortable that the timing tables that are in place - which I am comfortable are right, given that they were initially tuned for gas and then pushed for meth - then the approach of straightforward tuning to match the target AFR as per the primary open loop tuning table, which is basically where I started, should actually work? It really is a case of leaning out the targeted AFRs compared to what a normal gas fueling map would look like.

In other words, if I've targeted 11 with meth (initially, to keep it safe in case the MAF scale was way off - which it was) - I should target 11 AFR with the meth on, until the margin is relatively low, and then raise the AFRs in the fueling table to the appropriate leaner values - your recommendation being 11.2, tuner's a maximum of 11.5. Correct?

I hope so, that's basically what I've been doing!

 

[HolyCrapItsFast]

Nope... You set your target AFR in the primary fuel tabel first... Just like you do for straight gas and then adjust your MAF while on meth till you hit target. It is that simple.

Since you are running meth you can make your targeted AFR (primary fuel tabel) leaner if you so desire. Again I never go leaner that 11.2 because of EGT but that is just me.

 

[Td_d]

Woha... just got a big scare. Having scaled the top end of the MAF scale right up to accomodate the AFR errors, I could not get the AFR down at the top (high loads, high RPMs). I kept on seeing scary numbers close to 12, thankfully I'm watching gauge like a hawk as well as logging, so I back off.

There's one thing we forgot - in scaling the injector flow, I set it at 767, has worked the best in terms of CL trims, driveability. The likely real flow is somewhere between 740-760. All good and fine, since the MAF scale is all relative to the injector, and effectively can be moved up and down with a linear effect on trims. Only one problem... on the stock rom, the parameter MAF limit (maximum) is set at 400 g/s - the sensor is basically pegged at that point. So if you go above that, it remains pegged at 400, resulting in going lean very quickly! Crikey, got a heart-attack when I realised that.

So basically I can either multiply the entire scale by a % and reduce the injector flow (which I'm not keen, since it's driving very well down low) or I can raise this number (which I have, to 600). The sensor is still physically capable of only 5v, which I'm not reaching - but without this change, it can potentially cause a very dangerous leaning out at the top. To all reading, keep this in mind.

 

[Td_d]

Nope... You set your target AFR in the primary fuel tabel first... Just like you do for straight gas and then adjust your MAF while on meth till you hit target. It is that simple.

Since you are running meth you can make your targeted AFR (primary fuel tabel) leaner if you so desire. Again I never go leaner that 11.2 because of EGT but that is just me.

So basically, set the fueling targets first (which I have now) and if I'm worried about the MAF being way out at the top, rather adjust it significantly up (say 10% if I was worried the scale was way off), and then scale the MAF accordingly.

Gotcha! See previous post though, we forgot about one very important variable, shudder...

 

[Td_d]

Jeesh, so many variables involved with this, what a learning curve (without blowing anything up!). I know I'm within the 5v, as with all the logs, the highest I've ever reached (when the scale was obviously much lower, and I feel this is likely to be really the highest is will go, with very high load and RPMs close to the limit of 7500 that the engine is capable of) was 4.77v. Which, lets face it, is pretty close to 5v, but thankfully not yet there.

 

[HolyCrapItsFast]

Raising the MAF limit is the standard and I'm just so use to do it I just take it for granted sometimes.

The other thing people do is use a stand alone ECU. On some of them like the hydra you can create more cells thereby increasing the resolution. It shouldn't be a problem though taking the MAF sensor right close to it's limit provided you scale it properly. The issuse comes when you go over and the chances of that happenning with these setups is slim. Unless you plan a build like Fugi. I think something like that would stretch the limits of any MAF. Then I would just go speed density and be done.

 

[Td_d]

Yeah, I'm comfortable that it won't go over- I just could not understand why the corrections were not taking effect! Could have been a very expensive lesson, looking at the logs now I can see exactly why the % corrections were climbing up so quickly right at the top - I've got it down to 1% or thereabouts up till 397g/s, and then (excuse the pun), boom! It climbs up massively.

Phew.

 

[Td_d]

Alrighty... finally, success - the MAF limit was indeed the problem, I'm now seeing a really clean open loop MAF scale!

With the limit lifted, I was now of course running relatively rich in a couple of places at the top, but not horrendous. A couple more runs to dial it in really nice and tight, including some serious 4th gear WOT pulls, and I should be done with this!

 

[Td_d]

Also - Holy, you might be interested in this - as a follow up to the discussion on openecu forums regarding the map switch Bill from Cobb was talking about, I specifically raised the issue that I had with a stumble that remained despite all the tweaking of the two maps. I wanted to raise it, because given this new information, the fact that the ECU 'transitioned' proportionately between the two maps, might be the cause of the stubborness of this stumble. So Nil5, who picked up on the thread initially, responded with a strategy that I think has finally nailed it. Basically, the difference between the two maps is where the AVCS timing between cruise and non-cruise differ (and hence the VE differs, resulting in different resonances). The strategy was effectively to set the cruise AVCS map to the non-cruise setting, and then log it again and filter using all the data (i.e. not just 8 - because as has been pointed out, the OL/CL switch is not the only factor determining which map is used). Of course being wary of the potential knock that fiddling with AVCS maps can bring on!

Here's where I got lucky - for whatever reason by the tuner, my cruise and non-cruise AVCS tables are already identical. So I used the non-cruise values in the cruise table (I figured I would do that since I originally used all the date to calc that table, and I would once I sorted OL out, do some more load compensation logs). Magic. Any hint of stumbling is completely gone now - so the calcs were correct - but were not being applied correctly at cruise, due to using only the 8 switch data.

 

[HolyCrapItsFast]

Thank you for putting the time into that. It is really good information to know and I would like to put that in my tuning guide if it pleases you.

So what you did was to set both cruise and non cruise AVCS to be the same and then make cruise and non cruise load comps to be the same?

I never pre-filter my data when I run the excel spread sheets for load comps. I always thought it was important to capture all driving instances. I will have to go back to the files I first did but I'm pretty sure I did not filter the logs. You are using the new spread sheet that can handle CAN logs right?

I wish it were as cut and dry for the GD. We don't have cruise/non-cruise tables. There are just one for each of the categories. Most of the time this is good because we set one table and we are done... But when the stumble is stubborn, we have no other recourse.

 

[Td_d]

Sure - you're welcome to use it in the tuning guide, I'm honoured! That's basically it - for the GR's up, where you have cruise and non-cruise AVCS and timing maps, set them identical, and then log and tune the load compensation tables using all the data, not prefiltered. In essence, it takes the differing VE effect out of the loop, excuse the pun. I must acknowledge that it was Nil5 who suggested this - his advice was:

" Set AVCS and ignition timing tables for cruise to the non-cruise values.
- Repeat the procedure as before, now that the cruise AVCS tables have the non-cruise AVCS settings, you would in theory determine the proper non-cruise MAF compensation table.

Only word of caution is that the AVCS table values determine maximum timing before knock. Arbitrarily mucking with the AVCS tables is not safe."

I think the proviso wrt the AVCS tables must be stressed - I recall when I initially thought that tweaking the AVCS tables might be the issue, I started changing values _slowly_ and you can pick up knock _very quickly_ Easy does it, and close monitoring.

 

[Td_d]

Oh - also, on the spreasheet - I'm actually using Airboy's spreadsheet again - I conceded and loaded Excel 2003 again (what a downgrade...) and the spreadsheet works perfectly with CAN logging. The only thing is that when you exceed 65000 lines, it cuts it off - so I would have to process that data 65000 lines at a time, filter, copy the filtered data elsewhere, proceed with the next batch, etc. until I had all the fltered data which could be manually plugged back into the pivot table on Airboy's spreadsheet again. Major, major mission, but worth the end results.

Alternatively, if you really feel like geeking out there are Matlab scripts that have been posted on the openecu forums that can handle any number of lines - I think Nil5 wrote these as well - apparently it is also signficantly faster than Excel (20 - 30 seconds for a long CAN log!). Like a moth drawn to a flame, I intend to test it soon, just for the hell of it :tard:

 

[HolyCrapItsFast]

I will stick with what I know :tard:

 

[HolyCrapItsFast]

I wish to effing God I had ATP

 

[Td_d]

I've noticed that in RomRaider 'developer' mode there seem to be a lot more tables than in ATR. I'm sure ATP has even more, given that the chief coder was one of the key drivers behind RomRaider.

Must say, this OL scaling can be a little hair-raising - got a bad patch of knock at 4000 rpms - see attached pic, obviously leaned out considerably more than what the target fuel was. Two questions -

1) Could this be tip-in not being sufficiently rich? Knock onset is almost straight after punching throttle to WOT - although is is richening, just not enough (scale has also now been adjusted, was slightly lean, only 1.5% or so on average though);

2) You can see as the mix richened up (and overshot) the knock disappeared - but what the hell happened at that last cell where knock went to -6.3 with letting off the throttle? And why on earth did the target fueling jump to that ridiculous figure?

I'm hitting some pretty serious engine loads with this turbo - highest load on this run was 5.13

 

[Td_d]

Matlab is a processing beast and an absolute whore to code. I hate matlab with a passion, it was part of my degree. Ugh. I'd show you a really nasty matlab algorithm if it wast FOUO. It's a section of code written by some scientists in the airforce to model laser propagation, q* (material removal), and diffraction. I spent 30 hours a week for 9 months or so plugging data through that program for my honors project. :shudder:

I need to look through the Cobb protune software at some point... The 08+ ecu has MANY more parameters and tables than is shown on ATR for stock tables.

I hate to admit it, but I started fiddling with Matlab last night, damn convoluted - plus with no instructions for the scripts, I got as far as loading the data, and that's about it. I've not done any sort of coding in absolute ages, so it was quite frustrating. You can see how it would absolutely chew through the data though, straight forward raw processing.

 

[Td_d]

Well, if you do, the trick is under 'View' menu, choose 'User Level' and choose 'Highest' or 'Debug' - with the forewarning that some of the tables are still experimental from what I gather.

 

[HolyCrapItsFast]

My thoughts on this...

I've noticed that in RomRaider 'developer' mode there seem to be a lot more tables than in ATR. I'm sure ATP has even more, given that the chief coder was one of the key drivers behind RomRaider.

Must say, this OL scaling can be a little hair-raising - got a bad patch of knock at 4000 rpms - see attached pic, obviously leaned out considerably more than what the target fuel was. Two questions -

1) Could this be tip-in not being sufficiently rich? Knock onset is almost straight after punching throttle to WOT - although is is richening, just not enough (scale has also now been adjusted, was slightly lean, only 1.5% or so on average though);

This is not tip-in. Tip-in would happen just as your throttle delta swings from low throttle to WOT. This is knocking through out the entire WOT duration from the looks of it.

2) You can see as the mix richened up (and overshot) the knock disappeared - but what the hell happened at that last cell where knock went to -6.3 with letting off the throttle? And why on earth did the target fueling jump to that ridiculous figure?

It looks like the ecu was compensating for an over rich condition. Also when you begin to coast the cylinder is still very hot from the WOT run and when the injectors shut down the sudden lean condition could cause knock. You may be able to compensate for this by adjusting your over-run delay to allow it to remain enriched longer to allow the cylinder to cool.

I'm hitting some pretty serious engine loads with this turbo - highest load on this run was 5.13

Overall I don't think it is a fueling issue per say. Your wide band is tracking commanded fuel well enough from what I can see. I feel you need to reduce timing in that load/rpm region. First the loads are very high and if your load cells are not properly defined you will inherit timing from the maximum defined load cells. Meaning if your highest defined load is 4 and your timing is 15* @ 4500rpm, any load you achieve beyond that point will still be commanding 15* which is most likely to much.

 

[Td_d]

Hmm, I think I will tone down the timing - I gather it's knocking where maximum torque and HP is being built up - and the timing table definitions only define up to 3.4 - so, yes, it is definitely inheriting timing from much lower down the load scale. Sounds like I need to alter the resolution at the top end to better account for higher loads.

Could you go me a favour and maybe email / PM me your timing tables so I can get an idea of the type of resolution I should be using up top?

 

[HolyCrapItsFast]

Yes but please keep in mind that it may be totally different for your setup. Plus mine only go up to a load of 4 and I believe there are less load cells to define on the GD versus the GR. Also it makes a difference what dynamic advance is doing. You may want to log that the next time. Essentially you want your timing table to be a smooth when represented on a graph. You don't want any peaks and valleys in the resulting graph. Then you can used the dynamic advance tables to adjust up or down if needed.