2-bar / 3-bar hacking

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

2-bar / 3-bar hacking

Post by NSFW »

Just thinking out loud about what it would take to make an open-source 2-bar or 3-bar OS for P01 and/or P59 PCMs...

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 by a script that I created to label the tables in IDA:

SurfaceTable_25x29_Spark_Advance_Vs__Load_Vs__RPM_ _Open_Throt__Low_Oct
SurfaceTable_25x29_Spark_Advance_Vs__Load_Vs__RPM_ _Open_Throt__High_Oct
SurfaceTable_37x29_Cool_Comp_Spark_Advance_Vs__Loa d_Vs__Coolant_Temp
SurfaceTable_21x29_IAT_Spark_Advance_Correction_Vs __IAT_Vs__Load
SurfaceTable_17x29_Cat_Lightoff_Spark_Correction_V s__Engine_Run_Time_Vs__Load
SurfaceTable_25x29_Spark_Advance_Vs__Load_Vs__RPM_ _Open_Throt__High_Oct
SurfaceTable_25x29_Spark_Advance_Vs__Load_Vs__RPM_ _Open_Throt__Low_Oct

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.

Also, I 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.

That might be sufficient, but I definitely haven't thought this all the way through.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
Holden202T
Posts: 10311
Joined: Sat Feb 28, 2009 9:05 pm
Location: Tenambit, NSW
Contact:

Re: 2-bar / 3-bar hacking

Post by Holden202T »

yeah im sure there is going to be other stuff you wont know about till you try it!

would certainly be nice if you can simply change one scalar to offset everything, obviously re-scaling table data is going to have to happen, but you'd have to do that for any 2/3 bar conversion normally anyways.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: 2-bar / 3-bar hacking

Post by antus »

I think there are some map scalar variables already so you can make some of the changes just in the calibration, but those changes will lead to more changes.

Specifically there is an item in the engine diagnostics table, map->paramaters->map sensor scalar and map sensor offset. But im not sure what they affect. It'd be worth looking at the code behind them and see if you can scale the map up to 200kpa for a 2 bar map... the you can code a hard fail on the maf (or just remove it and mask the DTC) but then other tables as you're pointing too would need to be extended or re-scaled too.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Whyzee
Posts: 70
Joined: Fri Sep 16, 2016 3:02 pm

Re: 2-bar / 3-bar hacking

Post by Whyzee »

Really not directly related - but I read somewhere that disconnecting the maf and altering maf dtc’s using the standard OS means that some features such as traction control are disabled. Any idea whether this is correct?
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: 2-bar / 3-bar hacking

Post by NSFW »

antus wrote:I think there are some map scalar variables already so you can make some of the changes just in the calibration, but those changes will lead to more changes.

Specifically there is an item in the engine diagnostics table, map->paramaters->map sensor scalar and map sensor offset. But im not sure what they affect. It'd be worth looking at the code behind them and see if you can scale the map up to 200kpa for a 2 bar map... the you can code a hard fail on the maf (or just remove it and mask the DTC) but then other tables as you're pointing too would need to be extended or re-scaled too.
Oh right, I forgot the most important part! That's definitely the first thing to change. With a 2- or 3-bar sensor, the output voltage range would probably still be similar to stock, but the scalar would be around 1/2 or 1/3 of stock... The stock scaling in my ROM is 4835, which leaves plenty of room for adjustment.

But then the there's the question of whether the memory location that the PCM uses to represent MAP could hold a value that's 2 or 3 times larger, without overflowing...

The code for PID 000B (MAP) looks like this:

Code: Select all

OS2:000456DE GetPid_000B_ManifoldAbsolutePressure:  
OS2:000456DE                 clr.l   d0
OS2:000456E0                 move.w  (Pid_000B_MAP).w,d0 
OS2:000456E4                 divu.w  #$33,d0 ; '3'   ; 0x33 = 51
OS2:000456E8                 rts
Pid_000B_MAP is what I named the RAM location that holds MAP.

The result is kPa absolute (ranging from 0-255). Given the divide-by-51 operation, 100 kPa would be stored as 5,100 internally. With 3 bar boost you'd have 4 bar absolute, or about 20,400. It's a 16-bit value, so the max is 65,536 which means about 11 bar of boost, which should be sufficient for most applications. :)
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: 2-bar / 3-bar hacking

Post by NSFW »

Whyzee wrote:Really not directly related - but I read somewhere that disconnecting the maf and altering maf dtc’s using the standard OS means that some features such as traction control are disabled. Any idea whether this is correct?
Not sure, but it sounds plausible. If that does happen, I bet it could be addressed by skipping over the code that sanity-checks the MAF sensor signal, so that the PCM never even notices that the MAF signal is wrong. That seems less likely to cause trouble than letting the PCM detect the problem and then asking it to ignore the problem.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: 2-bar / 3-bar hacking

Post by antus »

I checked up on that its in the later generation pcms (e38), not p01 and p59.

When vl400 extended the earlier code he created a new map value that was 16bit, and retained the old. That way you dont need to touch tables that dont care about boost and can point the tables you extend to the new value. Saves a lot of unneccessary changes.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: 2-bar / 3-bar hacking

Post by NSFW »

Creating a second MAP value is clever, that's a good strategy to keep in mind.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
ShorTuning
Posts: 55
Joined: Thu Dec 13, 2018 4:42 pm
cars: 2002 Camaro
2002 Formula
Location: On the Dyno
Contact:

Re: 2-bar / 3-bar hacking

Post by ShorTuning »

I would think just updating the scaler and offset to keep the MAP reading the way it is would work fine. The problem is moreso the VE table axis itself. Table size is another thing to look at. Extending the table and/or adding a "boost VE" table.

The load axis' being scaled differently would also be huge. It is not hard to max out 1.2g/cyl on any form of forced induction combo.
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: 2-bar / 3-bar hacking

Post by NSFW »

I don't think there's much need to change the sizes of the tables... some resolution will be lost when the top of the axis changes from 1.2 to 4.5 or whatever, but I think we'll still have plenty of resolution with the existing tables. My Subaru's tables are considerably smaller and it does fine with 20-25psi of boost.

The load axis is the biggest thing, for sure.

I also really want to revise the way fueling is done. Not because it's strictly necessary but just because the concept of "power enrichment" seems like a hack (and "boost enrichment" even more so). I want a fuel table that has the same axes as the timing table - RPM and load. And add a simple compensation table based on coolant temperature. And then get rid of all the power enrichment stuff - just shape the fuel table to enrich as necessary. That's how Subaru does it, and I'm told it's how EFI Live does it as well.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
Post Reply