Timing does NOT follow tables bug - 2010 MS3 ATR

[Lex]

Originally Posted by G26 Awesome, should this affect those with very similar to OTS timing already? As in cause KR issues etc?

If anything you will see LESS timing than what the map calls for. So you will see less KR and less performance - ie. this bug makes it safer rather than a hotter tune.

[G26]

Originally Posted by Lex If anything you will see LESS timing than what the map calls for. So you will see less KR and less performance - ie. this bug makes it safer rather than a hotter tune.

Right, but when the fix comes out whats going to happen?

[Lex]

Originally Posted by G26 Right, but when the fix comes out whats going to happen?

That depends on how your map is setup. If you increase timing in the high load areas to compensate for this then you may run into KR. I wouldn't make timing changes until COBB fixes this so that the load-timing relationship in the map matches the load-timing the car is actually running.

If you're on an OTS map I wouldn't worry about it.

[G26]

Originally Posted by Lex That depends on how your map is setup. If you increase timing in the high load areas to compensate for this then you may run into KR. I wouldn't make timing changes until COBB fixes this so that the load-timing relationship in the map matches the load-timing the car is actually running. If you're on an OTS map I wouldn't worry about it.

I am on my own map, timing at the higher loads is anywhere from .5-1.5 degress advanced over OTS.

That should be alright correct?

[rfinkle2]

Originally Posted by G26 I am on my own map, timing at the higher loads is anywhere from .5-1.5 degress advanced over OTS. That should be alright correct?

An easy thing to do would be to take an ots map (after bug fix), copy it to an excel spreadsheet (data analyzers like you are excel experts), do the same with your current table, making sure load lines match up, and subtract the two tables.

[G26]

Originally Posted by rfinkle2 An easy thing to do would be to take an ots map (after bug fix), copy it to an excel spreadsheet (data analyzers like you are excel experts), do the same with your current table, making sure load lines match up, and subtract the two tables.

Yeah, I will probably do that. Now I want this fix, running 10 degrees at 6k rpm 1.75 load is LOW, no wonder my virt dynos show my power dropping off up there.

[Cobb Tuning]

Originally Posted by G26 Awesome, should this affect those with very similar to OTS timing already? As in cause KR issues etc? Or can I just copy/paste my values over to the new table when the fix comes out?

The Tables aren't different, only how I've labeled the axes. Nothing changes in the tune.

The load axes should go from roughly .10 to 2.00 on the gen2.

-David@COBB

[G26]

Originally Posted by David@COBB The Tables aren't different, only how I've labeled the axes. Nothing changes in the tune. The load axes should go from roughly .10 to 2.00 on the gen2. -David@COBB

Right, and now they are .10 to 2.19, so having them go to 2.19 was the error?

Thats a pretty big thing to over look?

Also, I have a 2011, so I guess this is all gen 2's.

[rfinkle2]

2010's atr has .31-2.19

Edit: forget everything except there is no reason to panic.

The change of 3 load lines is not enough to cause serious issues, and as Lex stated, it will likely decrease your timing.

Originally Posted by G26 Right, and now they are .10 to 2.19, so having them go to 2.19 was the error? Thats a pretty big thing to over look? Also, I have a 2011, so I guess this is all gen 2's.

It looks to be 2010 specific.

@David@COBB, could this fix the idle issue on 2010's as well?

[Lex]

All gen2s that have their axes go to 2.19 are affected

[rfinkle2]

Originally Posted by Lex All gen2s that have their axes go to 2.19 are affected

Ok. So the thing to do is:

1) not panic
2) wait for the next atr version
3) see where your loads line up
4) trust Cobb to fix it safely (since they have fixed everything in the past for us)

5) enjoy your car in the mean time.

I get what you are saying Lex, I'm going to have some work to do myself.

[Zbrit00x]

@David@COBB any eta on the atr fix?

[Lex]

Just to update, got word from COBB and it looks like the fix will be coming in the new year.

[G26]

Originally Posted by Lex Just to update, got word from COBB and it looks like the fix will be coming in the new year.

Sounds good to me.

[G26]

Any updates on this?

@Lex

[Lex]

Originally Posted by G26 Any updates on this? @Lex

Nothing that I know of. This is unfortunately out of my hands and we all have to wait for COBB to release the fix.

[Zbrit00x]

There was an ap firmware update for the recovery fix.. I'm assuming the atr fix is coming pretty soon now

[Lex]

Originally Posted by Zbrit00x There was an ap firmware update for the recovery fix.. I'm assuming the atr fix is coming pretty soon now

Certainly hope so!

[Lex]

Just PMed COBB again on an ETA for this.

FYI:

It is becoming increasingly important to fix this because if the incorrect axis values are used and ignition map tuned as of right now, the car may run too much timing when the issue us resolved. For example, the 2.00 load values could erroneously be increased too far such that the car will knock when the 2.19 y-axis becomes accurate.

It was not dangerous to make the initial mistake, but if people tune their cars using the newest ATR version and the problem is corrected; there is a potential for the vehicle to run too much timing.

[VitViper]

Shocker, Cobb sitting on a bug for over a month. A really annoying/dangerous bug at that.

[RichieRichness]

I'm sure this isn't an easy fix. Have faith that Cobb will resolve this issue soon. Best thing to do is make all timing values vs rpm the same from 2 +.

[Lex]

Originally Posted by RichieRichness I'm sure this isn't an easy fix. Have faith that Cobb will resolve this issue soon. Best thing to do is make all timing values vs rpm the same from 2 +.

Actually I am pretty sure it is an easy fix in this case. They should have rolled back to the version of ATR before that had the axis scaled to 2.00 but was correctly done. Then they could have re-looked at extending it. Not having timing resolution above 2.00 load is much less serious than having the timing scaled incorrectly.

When I tune, I want to make sure the tune stays current - last thing I want is a tune that changes timing values after a software update.

[warlord]

I don't post much but was following this this thread because I was upping my timing tables along the load curve and noticed that they ended at 2.0 also. Low and behold i loaded a fresh map from Cobbs site 1/5/11 and this is what appeared on the new map and all my previous itterations. Not sure if the change came through the new map or the AP update a week and a half ago. All seven tables extend down to 2.19 with new values. I tried copy and pasting an older reworked table onto one of the new table and noticed that values have changed in cells that I never previously touched. Anyway I'm no tuning guru and if this isn't what the current conversation is about then disregard. Pic is of a unedited OTS table.

[rfinkle2]

That is what happens when you open a map in the new version, whether or not the old values were modified.

All load lines > 2.0 are populated with the same value as the 2.0 load line.

[Dano]

Originally Posted by Lex Actually I am pretty sure it is an easy fix in this case. They should have rolled back to the version of ATR before that had the axis scaled to 2.00 but was correctly done. Then they could have re-looked at extending it. Not having timing resolution above 2.00 load is much less serious than having the timing scaled incorrectly. When I tune, I want to make sure the tune stays current - last thing I want is a tune that changes timing values after a software update.

I believe @David changed to dynamically generated axis [in some tables] in the new ATR which is probably why the issue occurred and why it isn't a simple fix. You may remember the latest ATR was not an inline update like previous updates but the entire backend was overhauled. At least that's what I think was the case.

[rfinkle2]

Originally Posted by rfinkle2 That is what happens when you open a map in the new version, whether or not the old values were modified. All load lines > 2.0 are populated with the same value as the 2.0 load line.

The guy who posted this doesn't know what he is talking about because I just opened a map that has advanced timing in the 2.19 load line (ots). LOL.

[Lex]

It's not just the top row. The entire table is shifted wrong.

@David@COBB - an ETA please. I don't want to see cars be damaged due to this issue.

[Cobb Tuning]

Originally Posted by Lex It's not just the top row. The entire table is shifted wrong. @David@COBB - an ETA please. I don't want to see cars be damaged due to this issue.

I have made some various bug fixes, and the changes need to go to our testing department. Once it goes through that, we can update it. Best ETA is before February. Keep in mind this release will also have some new tables in it, specifically those for Load based tuning.

Just to reiterate, it is an axis error, all the table data is still the same and won't be affected.

-David@COBB

[Lex]

Originally Posted by David@COBB I have made some various bug fixes, and the changes need to go to our testing department. Once it goes through that, we can update it. Best ETA is before February. Keep in mind this release will also have some new tables in it, specifically those for Load based tuning. Just to reiterate, it is an axis error, all the table data is still the same and won't be affected. -David@COBB

@David@COBB

Thanks David,

So when the fix is made, is the table reverted back to an axis with load going to 2.00?

I just want to know how the fix is implemented so that I know how to change the table data to match the fixed axis.

[Cobb Tuning]

Originally Posted by Lex @David@COBB Thanks David, So when the fix is made, is the table reverted back to an axis with load going to 2.00? I just want to know how the fix is implemented so that I know how to change the table data to match the fixed axis.

Yes. Here's what it should be:

0.13
0.19
0.25
0.31
0.38
0.44
0.50
0.56
0.63
0.69
0.75
0.81
0.88
0.94
1.00
1.06
1.13
1.19
1.25
1.31
1.38
1.44
1.50
1.56
1.63
1.69
1.75
1.81
1.88
1.94
2.00

-David@COBB

[Lex]

Muchos gracias! This will allow me to resume the stalled 2010+ tuning