Saturn Sky Forum banner

21 - 24 of 24 Posts

·
Super Moderator
Joined
·
5,886 Posts
Not a tune per se but different perameters/tables. That is a fact. .......
Isn't that what a "tune" is? ie: Changes to the lookup tables.
 

·
Super Moderator
Joined
·
11,278 Posts
Not a tune per se but different perameters/tables. That is a fact. Was also catalogued be trifecta.
Isn't that what a "tune" is? ie: Changes to the lookup tables.
Actually no. ...and yes...but no. A tune is a change to the values in the lookup tables and a tune will access different tables and apply their values under different conditions but it's not like the ECM is rewriting the values in the tables when there is an error nor would these tables that are accessed only under certain conditions be considered a "separate" or "additional" tune.

A tune doesn't add tables to the structure of the ECM, it only changes the values in the fields of those tables. Once those values are set in the tune, the ECM cannot change them. It can only modify the end result it calculates with them using other values that it has been programmed to use. These values are still a part of the same tune. So while the ECM can modify a calculated value based on conditions, it's applying the set modifier to a set value.

For example. 2+2 =4. The first 2 is the base value. The second 2 is the modifier. You could have 2+2+5-9=0 where the second 2, the 5 and the 9 are all modifiers. The base 2 stays the same but the modifiers, and the number of them, changes. The base number and each individual modifier would be from different tables (so the last example we're talking 4 different tables).

And when we receive an error code that changes how the car runs, this is information that is in the logic of the programming itself. There is a table that can turn these error codes on and off (so you could turn off error code P0107) and if you have this error with the error code turned off, if the programming is setup to ignore that code if it is not logged or set to turn on your CEL (in other words, turned off) then it my not cause the engine to run any differently when the problem occurs. I've never played with that kind of stuff and for good reason.

If you get an error code and it causes a limp mode, that is part of the ECU's programming. It's there regardless of what "tune" you put in the car. That's the logic of the programming...if X happens do Y in Z way. Now maybe you reprogram it (tune it) to if X happens do Y in W way...but it's still going to do Y even if doing it W way is no different than not doing Y at all.

For instance, it could be that "if you set P0107 (this is X) then you reduce boost (this is Y) by 100% (this is Z)" meaning all boost control is now no longer managed by the ECM, it's just going to let the spring handle it because it's not going to add any more boost than the spring will allow. You could (in theory...not sure if this is how it all works with the LNF's computer) say "if you set P0107 (still X) then you reduce boost (still Y) by 0% (Which is now W)". It's still "reducing" boost but since your value is now 0% rather than 100%, it's not really going to reduce boost. Your tune has changed the reduction percentage from 100% to 0% but the logic of the ECM's programming is still the same...only the value have changed.

The values are what a tune changes. Nothing more.

Now, I don't think this is how the logic of the LNFs limp mode works. I think it works more along the lines of "If these things happen, set the waste gate solenoid to it's fail safe setting which will release the ECM's ability to control boost to the actuator spring only." I don't think there are any values that can be changed with this other than error code reporting.

All this, also, would be a modifier. The value for Y in our cases...the amount of boost...is determined to be a certain pulse width of the solenoid as calculated by the ECM as to what is necessary to maintain a particular boost level. That's your base value in the tune. The Z or W value is a value that modifies the value of Y to achieve a desired result under a particular set of conditions. Z or W will not be applied as a modifier if X doesn't happen.

This is how Knock Retard (KR) works. It's exactly how KR works. KR is the modifier. If the knock sensor see's knock it calculates how strong it is (this is the new X) and then modifies the base spark value (the new Y) by reducing it a certain percentage expressed as KR (our Z). So KR is the percentage the base spark will be reduced when knock is detected. You can reprogram how aggressive KR kicks in and how long it takes to go away (decay) in a tune but it will always want to kick in and it will always have a decay...even though it is possible to basically 0 these out (almost no kicking in and it immediately goes away...very bad to set it up this way...just sayin'. Don't try this at home.)
 

·
Registered
Joined
·
486 Posts
Actually no. ...and yes...but no. A tune is a change to the values in the lookup tables and a tune will access different tables and apply their values under different conditions but it's not like the ECM is rewriting the values in the tables when there is an error nor would these tables that are accessed only under certain conditions be considered a "separate" or "additional" tune.

A tune doesn't add tables to the structure of the ECM, it only changes the values in the fields of those tables. Once those values are set in the tune, the ECM cannot change them. It can only modify the end result it calculates with them using other values that it has been programmed to use. These values are still a part of the same tune. So while the ECM can modify a calculated value based on conditions, it's applying the set modifier to a set value.

For example. 2+2 =4. The first 2 is the base value. The second 2 is the modifier. You could have 2+2+5-9=0 where the second 2, the 5 and the 9 are all modifiers. The base 2 stays the same but the modifiers, and the number of them, changes. The base number and each individual modifier would be from different tables (so the last example we're talking 4 different tables).

And when we receive an error code that changes how the car runs, this is information that is in the logic of the programming itself. There is a table that can turn these error codes on and off (so you could turn off error code P0107) and if you have this error with the error code turned off, if the programming is setup to ignore that code if it is not logged or set to turn on your CEL (in other words, turned off) then it my not cause the engine to run any differently when the problem occurs. I've never played with that kind of stuff and for good reason.

If you get an error code and it causes a limp mode, that is part of the ECU's programming. It's there regardless of what "tune" you put in the car. That's the logic of the programming...if X happens do Y in Z way. Now maybe you reprogram it (tune it) to if X happens do Y in W way...but it's still going to do Y even if doing it W way is no different than not doing Y at all.

For instance, it could be that "if you set P0107 (this is X) then you reduce boost (this is Y) by 100% (this is Z)" meaning all boost control is now no longer managed by the ECM, it's just going to let the spring handle it because it's not going to add any more boost than the spring will allow. You could (in theory...not sure if this is how it all works with the LNF's computer) say "if you set P0107 (still X) then you reduce boost (still Y) by 0% (Which is now W)". It's still "reducing" boost but since your value is now 0% rather than 100%, it's not really going to reduce boost. Your tune has changed the reduction percentage from 100% to 0% but the logic of the ECM's programming is still the same...only the value have changed.

The values are what a tune changes. Nothing more.

Now, I don't think this is how the logic of the LNFs limp mode works. I think it works more along the lines of "If these things happen, set the waste gate solenoid to it's fail safe setting which will release the ECM's ability to control boost to the actuator spring only." I don't think there are any values that can be changed with this other than error code reporting.

All this, also, would be a modifier. The value for Y in our cases...the amount of boost...is determined to be a certain pulse width of the solenoid as calculated by the ECM as to what is necessary to maintain a particular boost level. That's your base value in the tune. The Z or W value is a value that modifies the value of Y to achieve a desired result under a particular set of conditions. Z or W will not be applied as a modifier if X doesn't happen.

This is how Knock Retard (KR) works. It's exactly how KR works. KR is the modifier. If the knock sensor see's knock it calculates how strong it is (this is the new X) and then modifies the base spark value (the new Y) by reducing it a certain percentage expressed as KR (our Z). So KR is the percentage the base spark will be reduced when knock is detected. You can reprogram how aggressive KR kicks in and how long it takes to go away (decay) in a tune but it will always want to kick in and it will always have a decay...even though it is possible to basically 0 these out (almost no kicking in and it immediately goes away...very bad to set it up this way...just sayin'. Don't try this at home.)
This is definitely the perfect answer! It is also absolutely correct! There are hundreds of tables in the ECU. It's likely that this code throws the ECU paramaters into utilizing different tables and modifiers for how it runs. Regardless, it corrected the wierd issue I was having with my spark advance problems. Trifecta believes that this means the MAP sensor was probably malfunctioning for a while (causing the wierdness I've widely posted about) but it wasn't bad enough to throw a code. This would explain why the CEL caused it to stop hesitating above 5000 rpms at WOT.
 
21 - 24 of 24 Posts
Top