Weird MAP Issue, starting turbo tune

[SprungtS]

Been working on an FR-S I bought a couple months ago that's running the SBD500x turbo kit. Needed a clutch and some things, so did a lot of work and in the meantime tweaked an OFT basemap to use with boost since I can't seem to get a response from Openflash/Shiv. One of those tweaks was scaling for the Omni 3bar MAP sensor.

The car wouldn't start the first time I tried. I found that the MAP sensor was reading 8psi atmospheric pressure, so after trying to adjust the MAP offset (tried as much as 14psia) with zero change in logs, I cut all values in IPW Comp (MAP) to 15% to allow it to start. It runs, and MAP reading drops from 4.8psi to 0.0psi and basically stays there until I do anything to reduce manifold vacuum by a decent amount.

The strangest part to me is that no matter what value I use for MAP scaling (psi/v or psia offset) the logs are unchanged.

For testing, I just swapped a stock 2020 MAP sensor in. The log shows 14.69psi atmospheric, and normal idle vacuum readings with the engine running. So I don't think my MAP scale is being applied at all, and I can't figure out why.

The tune I started with is directly from OFT's website, this car's CAL ID is ZA1JB01C (2014 FR-S). The definition is the one provided from them as well. I have seen A01G somewhere as well, I think on the OFT when plugged into the OBD-II port. I know OFT uses hacked ROMs and assume that's why I see A01G somewhere, although I did think OFT used the B01C ROM as a base for others (rather than A01G) at least at some point.

Here are two logs showing what I'm seeing. First log is just cranking, before adjusting the IPW compensation table (the jump to 21psi at the end of the log is after I unplugged the sensor). The second log shows idling, and moving the car via clutch bumping the pressure high enough to read above 0.

Side note... If anyone does have a map for the GReddy turbo kit or the SBD 500x, or honestly about any small turbo tune that they're willing to send, I'm curious about AVCS and other tables. I've spent many hours researching over the last few weeks and struggled to find almost any information on what values to start with. There's more out there on the stock FA20DIT tables! Even just screenshots for AVCS maps would be crazy helpful, but a tune to pick through and compare with what I've got would be awesome.

Thanks in advance!

[tomm.brz]

what you want you won t find for free
tuners do not give away their tables like that

[SprungtS]

Originally Posted by tomm.brz

what you want you won t find for free
tuners do not give away their tables like that

Not so concerned about AVCS tables, more concerned about the MAP issue. AVCS info would just be a bonus while I start this process, but I believe you when you say I won't get it for free.

Been out for a couple test drives and the stock MAP sensor works perfectly, it just seems to max out right before full boost.

[tomm.brz]

Originally Posted by SprungtS

Not so concerned about AVCS tables, more concerned about the MAP issue. AVCS info would just be a bonus while I start this process, but I believe you when you say I won't get it for free.

Been out for a couple test drives and the stock MAP sensor works perfectly, it just seems to max out right before full boost.

you can use stock map if you don't manage boost with a ebcs
it s tunable also with stock map maxing at 1.37bar


with 3bar omni map, there is no way it gives problems if you put the correct values, if it gives you problems the map sensor is kaputt

[SprungtS]

I have two Omni 3 bar MAP sensors. Both of them exhibit the same symptom. It’s not the sensor. Again, the stock sensor works perfectly fine even when I have my MAP scaling set to the Omni 3 bar values (~9psi/v, ~.04 offset). I would think I’m mistakenly using the wrong CAL ID maps, but everything else I do affects the tune normally. Everything from fueling, to ignition, to AVCS, to load limits…. The only thing that doesn’t seem to work properly is MAP scaling.

I’m not a professional tuner, but I’m not new to it either. This will be the 4th 86 I’ve tuned. Second boosted one (and I still own the other one so I have that for troubleshooting benefit). Got numerous aftermarket FI setups under my belt. I only clarify because my instinct too would be to say “you must be doing something wrong”. I’ve never seen anything like this, a table that’s completely unresponsive.

[SprungtS]

I did check the memory address, just to be sure. 0x1000cc is where MAP scaling points. Not much info on that online but it seems to be correct. That address is straight from memory as I don’t have my tuning PC available to me atm. But I believe that’s correct.

[Sapphireho]

First thing I would do is replace the Omni map sensor. They are known to have problems.

[SprungtS]

Originally Posted by Sapphireho

First thing I would do is replace the Omni map sensor. They are known to have problems.

As I said, I have two Omni 3 bar sensors. One of them is brand new. They both do the exact same thing. And regardless, changing MAP scaling should change pressure logs even if the sensors don’t read anywhere close to what they should read. Changing MAP scaling has zero effect on my logs. That’s why I’m stumped.

ETA: even with the stock MAP sensor plugged in, no amount of changes to my MAP scaling table makes any change to the value interpreted by the ECU. It’s like I’m changing values for a RAM address that’s incorrect.

[SprungtS]

Originally Posted by tomm.brz

you can use stock map if you don't manage boost with a ebcs
it s tunable also with stock map maxing at 1.37bar


with 3bar omni map, there is no way it gives problems if you put the correct values, if it gives you problems the map sensor is kaputt

Any other suggestions? Check my responses above. I'm thinking at this point the table just isn't adjusting the right values in the ROM... This is what table properties looks like for MAP Scaling:

https://imgur.com/a/w6yH7Gh

Anything suspect? Only thing I have to compare it to is my 2020 tune, also using OFT, which has a different memory address.

I'm sure I can just use the stock MAP sensor given I don't plan to run speed density, but since it maxes out before full boost, I'd really like to have a solid MAP/boost reference for logs. I can just run an aftermarket boost gauge to feel good about it, but I had really hoped to leave the car looking 'stock' and driving like it should have from the factory (IMO).

[tomm.brz]

i m sorry but i do not have a clue about what you are talking about. I ve done plenty of roms with Rom raider
who has 3BAR omni i put values for 3bar omni and i m good to go. Can't help you here maybe steve @AussieBRZ can


you really don't want to run SD with openflashtablet, it runs like shit



oft has different addresses because probably your oft tune is a ZA1JK00G euro 2017 tune inside, hacked to look like a 2020 tune

there is also no real need about knowing the actual boost, you can' t implement fail safe anyway, so if you overboost and destroy the engine, you ll do even with 3bar map
The turbo can be tuned perfectly with stock map anyway, if the tuner knows what he s doing
but really i have no idea what your problem is

[tomm.brz]

Originally Posted by SprungtS

As I said, I have two Omni 3 bar sensors. One of them is brand new. They both do the exact same thing. And regardless, changing MAP scaling should change pressure logs even if the sensors don’t read anywhere close to what they should read. Changing MAP scaling has zero effect on my logs. That’s why I’m stumped.

ETA: even with the stock MAP sensor plugged in, no amount of changes to my MAP scaling table makes any change to the value interpreted by the ECU. It’s like I’m changing values for a RAM address that’s incorrect.

then you probably have bad definitions for the rom

[SprungtS]

Originally Posted by tomm.brz

then you probably have bad definitions for the rom

So I’ve been doing a LOT of research… and even tinkering with a hex editor on some test copies of ROMs (found I can successfully CAL ID hack OFT ROMs and use with proper definition files, so I really don't think I'm just using the wrong defs for these ROMs).

Just to be clear, my 2020 is good, all tables work correctly.

It’s the 2014 FR-S that has some issues with the OFT definition… which I found is basically a carbon copy of @Td-d ‘s RR definitions, with LC/FFS added.

What I noticed when downloading a bunch of pre-facelift definitions and a couple ROMs is that all of them that I’ve tried have some unexpected differences from my current 2020 (of course much is different for the newer architecture), and from what I remember on my 2014 BRZ I used to own.

I kind of gave up on the MAP sensor since scaling wasn’t working, and while I’m not using it for speed density, I wanted an accurate reading for logs and for compensations. I realize now the compensations really aren’t that important on OFT so I’m not going to worry about it. However that brings me to my next issue, I was about to make a new thread but it might be related since I’m still having (what I perceive as) issues with the v4.03 definition files from the OFT site, as well as the RR definitions on GitHub.

I’m maxing out load at 5g/rev. Scaling MAF like I had been was causing some unrealistically high load figures, but fuel isn’t getting any richer on my OL tests, and I started logging different values to figure it out. My load limit table is currently set to 10 - but that’s it. One load limit table. To my knowledge there should be two load limit (max) tables, an A and B, and two Engine Load Limiter (RPM) tables. Based on the def code, there are some other load limit related tables (including that A and B max table) that are given table/value structure, but not given a storage address, so all that shows up in RR is the one “Load Limit (maximum)” table.

I’m at work and making this post from my phone, I’ll post logs later. But I’m very curious in particular why it seems there are a couple of hidden load limiter (RPM) tables on ALL of the pre-facelift defs I’ve checked. @steve99 any ideas? I know you’ve done some good digging and modding of these ROMs and defs.

I was literally hoping to find the tables myself but I have to admit hex editing a compiled .bin file is way beyond my knowledge of software. @Kodename47? Don’t know how many of you guys are still active all these years later. Been a while and another account since I’ve really been up here!!

(And again, everything I’m using for this 2014 FR-S is directly from OFP’s website/download page, but I do see the exact same things with the RR defs)

ETA: got an email back from Delicious where I was asking about the MAP scaling table... Evidently their tuner Bill says even on EcuTek they have bugged ROMs sometimes that have unresponsive tables, they reach out to EcuTek to fix them of course.

[SprungtS]

OFT value for load limit max, btw, is 4 g/rev. So I don’t think that this table necessarily like the MAP scaling table isn’t being applied, because as far as I can tell I should top out at 4g/rev on my logs if that’s the case - unless there’s some offset I’m unaware of. I think it's likely enough that it's the missing Engine Load Limiter (RPM) tables. You guys definitely know better than I do.

Apologies also about the length of my replies. I have a lot of information I’m trying to get down and this is how I write. Feel free to let ChatGPT give you a tl;dr lol

[SprungtS]

Here's a log of a single WOT pull. Load maxes out early, and I didn't catch the rising AFRs. Got ignition timing scaled way back while I work out these bugs but.. man.