When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
I'm not sure which table (or tables) you're talking about in that first paragraph. For speed-density, a VE table has RPM on one axis and MAP on the other, by definition. So if that's what you're talking about then we absolutely agree. For the fueling and timing tables, there's RPM on one axis but I don't think it matters whether the other axis is MAP or load.
That said, the existing spark table in my C5's OS uses RPM and load, so I want a fuel table that uses the exactly the same RPM and load axes. I think that would actually be a very simple change, and there would be need for power enrichment or boost enrichment after that. However, there would be a need for a coolant-temperature-based fueling compensation, and I haven't looked into how to achieve that yet. I suspect there's a way to make the PE table for coolant compensation active at all times, though.
Before looking up the value in the timing table (or any other table that uses the same load axis) the OS does some math to rescale the raw load value into something that can be used for the table lookup. The simplest way to create a 3-bar version of my OS would be to change that scaling. Then the load axis for every table that uses the same input would range from 0.8-to-3.6 rather than the current 0.8-to-1.2. After that, the contents of all tables that use the modified load axis would of course need to be rescaled. There are a bunch...
All of these table names came from the XDF that cmaje (from pcmhacking.net) created for 12593358, and all non-alphabetic characters in the table names got converted to underscores:
And probably also these:
SurfaceTable_13x29_Base_Spark_Adv__Vs__Load_Vs__RP M__Closed_Throt__In_P_N
SurfaceTable_13x29_Base_Spark_Adv__Vs__Load_Vs__RP M__Closed_Throt__In_Drive
SurfaceTable_13x29_EGR_Spark_Advance_Correction_Vs __Load_Vs__RPM
And another 13x29 RPM-and-Load table that I'm not sure what it's for, but all the cells are zero anyway.
Edit: I just went down a rabbit-hole about P1514 and predicted airflow, and found this in the HPT forum:
"If you are over 2.32 g/cyl you will get a 1514 no matter what you do to the 1514 table. "
So that would need to be fixed as well, and it's probably a hint that there are other details that will get in the way.
I still think this is do-able though.
Sorry just getting back to this.
The VE table load is MAP based (MAP vs RPM). The Spark tables are not load (MAP) based but cylinder airmass (g/cylinder) based. Thus the airflow calculated from the VE table directly affect the cylinder airmass. More airflow, more air each engine cycle meaning the cylinder airmass increases.
I assume you are wanting to rescale the spark table so that it has MAP as reference for load rather than cylinder airmass? You may also be interested in looking at the COS files from EFILive that have a timing modifier table based on MAP. So it will add/subtract timing vs MAP to the main spark advance tables.
Regarding the P1514 and 1516 errors, there are some electronic throttle limit values/parameters we do not currently have access to. I am pretty sure most all of those tables/parameters/switches are available in TunerCAT software.
The VE table load is MAP based (MAP vs RPM). The Spark tables are not load (MAP) based but cylinder airmass (g/cylinder) based. Thus the airflow calculated from the VE table directly affect the cylinder airmass. More airflow, more air each engine cycle meaning the cylinder airmass increases.
Correct.
I assume you are wanting to rescale the spark table so that it has MAP as reference for load rather than cylinder airmass?
No.
Originally Posted by NSFW
...the existing spark table in my C5's OS uses RPM and load, so I want a fuel table that uses the exactly the same RPM and load axes.
But, regarding this...
You may also be interested in looking at the COS files from EFILive that have a timing modifier table based on MAP. So it will add/subtract timing vs MAP to the main spark advance tables.
Any idea under what driving conditions that tables becomes useful?
I'm having a hard time guessing why it would be needed. I mean, if you're at X load and Y RPM, then you get Z timing... this table seems to be saying that if MAP is higher or lower than usual, then you'd want more or less than Z timing... but if MAP is higher or lower, then you'd be at a different cell in the timing table anyway... so why not just bake that MAP compensation into the shape of the timing table in the first place?
Regarding the P1514 and 1516 errors, there are some electronic throttle limit values/parameters we do not currently have access to. I am pretty sure most all of those tables/parameters/switches are available in TunerCAT software.
I am just guessing here, but I imagine they broke it out into a separate table/modifier because it was easier than scaling the table. I imagine there could be a number of reasons why this would be difficult. There may be a maximum limit somewhere in the code that will overflow a variable if you increase the range of the table.
Other than that I see no reason why they would do it the way they did.
Yeah, basically there are still tons of easily obtainable options, even for the DBC P59s. Also I guess I've never seen a 12582605, since I thought all 2003 P59s had IAC chips. And I guess I haven't ran across a 12576106 yet either, or at least haven't tried flashing anything it didn't like on there. Good to know to look out for them. One other funny thing I and others have noticed is IAC chipped P59s have an orange rubber seal and the ones without IAC chips have a gray seal. Might just be a coincidence, but most of the P59s i've dealt with for IAC chips were from 03/04 so maybe they were just switching over to the gray ones and all PCMs ended up with the gray seals after that. I don't see why they'd do that, but it would be a quick way to identify them without taking them apart or looking up the numbers if it held true.
Originally Posted by PeteS160
The 99-02 Pcm's are completely interchangeable as long as the server number ends in 896 or 0411.
03-07 will interchange for the most part, not all of them will work with drive by cable so you need to check that.
The FWD car stuff will not interchange even though they look the same, they are not compatible.
This isn't a 100% complete table but its got most of the server numbers and applications covered.It should have Trail blazers added for 2003/2004 that used the LM4 V8.
The 2003 12576106 is the only 1mb PCM that's going to be VERY picky about what file you flash it with. It uses a different flash chip then all the other 1mb pcm's, for what ever reason this pcm used an Intel flash chip while every other 1mb pcm used an AMD flash chip.
I have a year 2004 122586243 PCM with hardware number 12583659 that has both the IAC stepper driver and a grey cover seal. Go figure...
Guess it was just a switchover thing and one run of the IAC ones had the orange then they switched it up. Guess I need to pop apart my 2003 P59 with the label fallen off and confirm it has a IAC chip after all lol
I am just guessing here, but I imagine they broke it out into a separate table/modifier because it was easier than scaling the table. I imagine there could be a number of reasons why this would be difficult. There may be a maximum limit somewhere in the code that will overflow a variable if you increase the range of the table.
Other than that I see no reason why they would do it the way they did.
I think that's exactly it. Each value in the modifier table is a polynomial represented by an approximate number. I'd assume it's done to save from having to continuously compute all cell values.
But then again I don't really know anything about computers lol
Guess it was just a switchover thing and one run of the IAC ones had the orange then they switched it up. Guess I need to pop apart my 2003 P59 with the label fallen off and confirm it has a IAC chip after all lol
After all that I popped open the orange sealed 2003 truck p59 I have and there you go, no IAC chip lol
The only 2003 P59 PCM that I'm aware of that has the IAC driver is the service number 12576106, with hardware number 12570558. I have one here and the IAC driver chip is there on the mainboard.
The only 2003 P59 PCM that I'm aware of that has the IAC driver is the service number 12576106, with hardware number 12570558. I have one here and the IAC driver chip is there on the mainboard.
Thats the one the part number sticker fell off of. I thought all 2003s had them, petes picture above shows two different 2003 ones with IAC chips though.
I'm still using release 3 I believe of the PCM hammer, but just ran into a situation where after a few writes in the same instance of the app it started failing to upload the write kernel and was assuming the PCM was in recovery mode. I assumed I had bricked the PCM with repeated writes with no key cycles but i couldn't get it to work again until I eventually closed and reopened the app. Is this something you have run into? I can try and recreate it later and take better notes but I did a combination of a couple calibration and parameter writes.
I'm still using release 3 I believe of the PCM hammer, but just ran into a situation where after a few writes in the same instance of the app it started failing to upload the write kernel and was assuming the PCM was in recovery mode. I assumed I had bricked the PCM with repeated writes with no key cycles but i couldn't get it to work again until I eventually closed and reopened the app. Is this something you have run into? I can try and recreate it later and take better notes but I did a combination of a couple calibration and parameter writes.
Good catch on Pete's picture above! I thought I had already added that to my growing list of P01 and P59 PCM's with the IAC driver. Must have missed it...
I have not experienced the issue you mention above. It's possible because between each read or write, I always turn off the ignition power to the PCM, wait 15 seconds, then turn off battery power, wait 15 seconds, and then shut down PCM Hammer. I do this between any and all changes. I can try and recreate what you have experienced as well. I think an interesting test for the software.
maybe they were just switching over to the gray ones and all PCMs ended up with the gray seals after that. I don't see why they'd do that, but it would be a quick way to identify them without taking them apart or looking up the numbers if it held true.
If Google would ever stop screwing over developers by removing and restricting permissions that can turn a fully functional app into a paper weight over night there might have been a better way.....A screen shot really doesn't do it justice....but I had to have it zoomed in close enough to cut some personal data off the bottom of the table that I didn't want showing otherwise on a 5.1 inch screen the table was fully visible.
I'm still using release 3 I believe of the PCM hammer, but just ran into a situation where after a few writes in the same instance of the app it started failing to upload the write kernel and was assuming the PCM was in recovery mode. I assumed I had bricked the PCM with repeated writes with no key cycles but i couldn't get it to work again until I eventually closed and reopened the app. Is this something you have run into? I can try and recreate it later and take better notes but I did a combination of a couple calibration and parameter writes.
Please get the latest version, and if you see this kind of thing again, copy the contents of the debug tab into a text file, and attach it to a PM, and send it to me.
I'll do everything I can to fix bugs in the latest version. But, every release has included some reliability improvements, so I'm not inclined to spend much time hunting bugs in old versions.
Any idea under what driving conditions that tables becomes useful?
I'm having a hard time guessing why it would be needed. I mean, if you're at X load and Y RPM, then you get Z timing... this table seems to be saying that if MAP is higher or lower than usual, then you'd want more or less than Z timing... but if MAP is higher or lower, then you'd be at a different cell in the timing table anyway... so why not just bake that MAP compensation into the shape of the timing table in the first place?
Is there a maximum load parameter in TunerCAT?
I think you are missing what "load" is in the spark table. It's not manifold pressure or even relevant to manifold pressure. Its airmass. So there is no way to make the VE table and spark tables have the same axis parameters without making the spark table MAP/Load based.
The reason they added the MAP modifiier is because the 1.2g/cyl airmass limit within the table for one and two it gives the option to retard timing vs boost rather than figuring out where you are on the timing table. I personally just build the table using the airmass scale and leave the MAP referenced modifier zero'd out. But that option does get you around having to scale the tune to get table resolution.
I'm not sure on the TunerCAT parameter, I do know there are a ton of ETC limit tables however. I don't have the software, yet, so I'll come back to that when it comes in.
I think you are missing what "load" is in the spark table. It's not manifold pressure or even relevant to manifold pressure. Its airmass. So there is no way to make the VE table and spark tables have the same axis parameters without making the spark table MAP/Load based.
Nope, I'm not missing anything.
What you've missed (twice ) is that I want the spark and FUEL tables to have the same axes.
I wouldn't change the VE table
I wouldn't change the spark table.
The existing open-loop fuel table would be replaced by something with an RPM axis and a load axis (same as the spark table).
It would need a new table to modify the open-loop mixture based on coolant temperature. (Maybe IAT too.)
And then PE would no longer be necessary, or even useful, so those tables and constants would go away.
Ideally the spark and fuel load axes would go up as high as they need to, so that the MAP compensation table could go away too. Not sure if that's practical, but it would be nice.
You seem to be saying there is a MAP vs RPM table for sparks...albeit not the main table ? But still a valid table and in degrees of timing ?
So could you not just flatline the g/cyl table to a single value, so the only active table is the compensation MAP vs RPM for ignition ?
I think your missing the point, but I'm not sure NSFW ever just came right out and made it clear how things like this could be done so let me give a better overview of what NSFW is suggesting.
There have only ever been a couple of tools that could read and write the P01/P59 that were not commercialized and heavily locked down/restricted using altered file formats(not .bin).
While commercial tuning companies started out with pure intentions they have long since abandoned the ideals and promises they built multi-million dollar companies from. What they have done over the years is make people believe that they knew everything and they were doing this amazing job bringing you so many parameters to work with and even writing you completely custom operating systems doing things no one ever thought would have been possible.
Well here we are 20 years since the launch of the P01 and every one and their brother now knows everything possible about these pcm's, the avaible COS's and every parameter that can be adjusted in every OS. The issues here is that commercial tools did such a good job for so many years making it seem like they really cared and were giving you choices; the fact of the matter is people have only seen what these companies wanted them to see or to be able to adjust. The truth is they gave people just enough to keep them happy.
For commercial tools it's a matter of the cost to develop something VS what they can sell it for or how much perceived value it will add to their product.
Now there have always been free tools to "tune" files with and the limits of what could be adjusted were only limited by the parameters that could be mapped out in the pcm's operating system. The issue was once you altered a file there was really no way to get the new "tune" back into the pcm. With out tools to flash the PCM over the data bus altering the bin file on the flash chip was a time consuming and dangerous process so there was little reason to work on anything "New" for these pcm's. Well the Pcm Hammer and Ls Droid have solved the issues that's been plaguing people for the last 20 years by giving you the option to flash ANYTHING you want to the pcm. The only thing your limited by is the hardware in the PCM itself and the avaible commands in the Pcm's CPU.
The P01 and P59 are getting a second chance to prove what they are capable of, something that's very rare for a computer this old. What NSFW has been proposing are changes he would like to make to a NEW operating system. Not a rewrite of a stock OS with some setting in it slightly altered then calling it a "Custom" OS. He's suggesting totally rewriting HOW the Pcm's OS works and what tables it uses. This seems like a foreign concept to people because it's not something you see being done on American cars. It's not because it can't be done it's because there have been tuning solutions that were deemed good enough and no one has ever put in the time to undertake a task like this. If you go look at what some of the imports can do with a stock pcm it's gonna blow your mind. Things like 2 step rev limiter, boost control by gear, pcm controlled NOS activation, altered axis's on tables for air, fuel and spark....the list goes on. The only thing the PCM is limited by is the hardware it's built on.
So when you say something like "that's not how they work" what you should be saying is that's not how the tables currently being used in the Pcm work. While I can't predict what's in store for the future what I can tell you is every thing you think you know and have learned about these pcm's could be change in the blink of an eye. Now that we have ways to read and write every possible part of the flash chip the sky is the limit on what can be done.
You seem to be saying there is a MAP vs RPM table for sparks...albeit not the main table ? But still a valid table and in degrees of timing ?
So could you not just flatline the g/cyl table to a single value, so the only active table is the compensation MAP vs RPM for ignition ?
No, I don't think such a table exists in the factory OS. And I don't want one.
For my own car, which is probably going to stay naturally aspirated, I do not intend to change the spark tables at all.
I am not promising to make changes to support forced induction cars. But, I might. If I do take a shot at that, I'll try to rescale the load axis of the existing spark table so that instead of going up to 1.2 grams, it'll go up to 3 or 5 or whatever someone needs. When Subaru owners put in bigger turbos, we just rescale the spark table so it goes as high as we need it to. Subaru's OS makes that really easy. It will be harder to do that with GM's OS, but I think it can probably be done.
LsxPwrDz says that EFILive has "a timing modifier table based on MAP." I can see how that would work, but it's not the approach I'd want to take. But maybe the approach that I want to take is not practical for some reason.
02-05-2019, 01:26 AM
