pcmhacking.net

That’s the first time I’ve had anyone ask for that. I imagine most people use manifold pressure referenced as there are only a few applications that don’t have them from the factory.

If you are upgrading the injectors you’ll likely be upgrading the entire fuel system so you might as well just make it manifold referenced.

bubba2533 wrote:That’s the first time I’ve had anyone ask for that. I imagine most people use manifold pressure referenced as there are only a few applications that don’t have them from the factory.

If you are upgrading the injectors you’ll likely be upgrading the entire fuel system so you might as well just make it manifold referenced.

I agree that there are applications where injectors and fuel system are changed to a return style system with a boost referenced regulator. There are also plenty of applications where someone simply bolts on a supercharges and only replaces the fuel pump, maintaining the factory returnless system. My 04 GTO is an example of this. I installed an LSA supercharger and upgraded the pump the a Walbro 525 with an in-tank Holley regulator that maintains a constant 58 psi (had to by=pass the factory regulator as it was not strong enough to prevent the fuel pressure from being 72 psi at idle and cruise).

I can easily tune around this by manipulating the MAF and VE tables, but I thought that it would be more accurate to have the PCM know that the injectors are essentially flowing less while in boost since the fuel pressure remains constant and does not rise with the factory in-tank regulator.

That being said, I am just ASSUMING that the PCM looks at the MAP value then uses this to reference the injector flow rate based on the data in the table and adjusts fueling accordingly.

The value being used is absolute vacuum, calculated from baro reading and map sensor. zero vacuum should be similar to atmospheric pressure at see level. Negative vacuum should be in the boost area. Getting accurate data for this conditions is not an easy tasks. interpolating from other areas is also not recommended. In boost the injectors will flow much less, so fixing that in code will be a great achievement.

bubba2533 wrote: I've changed how I am doing desired air/fuel ratio. I replaced power enrichment with 2 new "Desired Air/Fuel Ratio" 3D tables based on MAP and RPM. I added 2 of them to allow for different Air/Fuel ratios between E0 and E80 (Flex Fuel Enabled).

I really like the idea of a two-axis fuel table. And RPM definitely should be one axis... but consider using load (grams-per-cylinder) for the other axis, just to be consistent with the spark table.

Phoenix wrote: That being said, I am just ASSUMING that the PCM looks at the MAP value then uses this to reference the injector flow rate based on the data in the table and adjusts fueling accordingly.

Yes, that's exactly what it does. It's really Vacuum and not MAP, but that's just being specific.

kur4o wrote:The value being used is absolute vacuum, calculated from baro reading and map sensor. zero vacuum should be similar to atmospheric pressure at see level. Negative vacuum should be in the boost area. Getting accurate data for this conditions is not an easy tasks. interpolating from other areas is also not recommended. In boost the injectors will flow much less, so fixing that in code will be a great achievement.

All the injector cares about is a delta pressure, and most good injector manufactures capture injector data (flow rate) across a range of delta pressures. I don't agree with this practice and will likely never build anything without a MAP referenced regulator. It's definitely possible, but just not worth all the time to implement it.

NSFW wrote: I really like the idea of a two-axis fuel table. And RPM definitely should be one axis... but consider using load (grams-per-cylinder) for the other axis, just to be consistent with the spark table.

I am pushing towards variables seen in most aftermarket ECU's. So I've actually considered creating a new set of spark tables that are based on MAP and not g/cyl. This would also allow for the removal of my Boost Spark Adder table since I could just increase the size/range of the table.

Did some more testing and did an overview of the new OS features for those interested.

Testing My LS1 P59 Custom OS - Why Pay for a Holley!?!?
https://youtu.be/x6Pa52m5KTA

Well done. Good to see your progress. Looking forward to testing your new LS1 Boost OS in the RTLS1.

bubba2533 wrote:Did some more testing and did an overview of the new OS features for those interested.

Testing My LS1 P59 Custom OS - Why Pay for a Holley!?!?
https://youtu.be/x6Pa52m5KTA

Enjoyed watching and hearing about it!
Would adding a custom signature into the BIN be an issue to be able to identify the file is a custom OS?
This could help people that end up receiving a PCM with your modded OS on it, but attempt to use the standard 7603 XDF instead of using the required Custom OS XDF.

Tazzi wrote: Enjoyed watching and hearing about it!
Would adding a custom signature into the BIN be an issue to be able to identify the file is a custom OS?
This could help people that end up receiving a PCM with your modded OS on it, but attempt to use the standard 7603 XDF instead of using the required Custom OS XDF.

Yeah, my patch changes the OSID to “7603xxxx” where xxxx is the version of my patch.

bubba2533 wrote:

Tazzi wrote: Enjoyed watching and hearing about it!
Would adding a custom signature into the BIN be an issue to be able to identify the file is a custom OS?
This could help people that end up receiving a PCM with your modded OS on it, but attempt to use the standard 7603 XDF instead of using the required Custom OS XDF.

Yeah, my patch changes the OSID to “7603xxxx” where xxxx is the version of my patch.

Perfect, I will note that down as it will go into the supported OSID's list for both lsdroid and pcmhammer.