MAF (Mass Air Flow) versus Speed Density, Discussion & Debate for ALL
 

Hi All,

There is definitely a debate going on right now between the two options available and I would like to start this thread in a light that is open to all sides for debate and discussion. The goal of this thread is to keep a friendly debate between the options/tuning solutions available, benefits and drawbacks of each from whoever would like to discuss the topic.

I will be taking the responsibility of keeping the debate on as even a playing field as possible and while I can not be an official "so to speak" I do want to hear the opinions of tuners and different tuning options available for each. So I will attempt to do my best at keeping things equally balanced. Moderators are more than welcome to review the thread to keep the bad-mouthing at bay.

So as the forum rules state, NO bad-mouthing other products, but you are more than welcome to offer difference of both systems. As a caveat if you speak about how an engine management system may work you are required to have used the system prior to speaking about it features.

Topic:
- MAF (Mass Air Flow - Quantity of Air) versus Speed Density (Manifold Air Pressure - Quantity of Air based on Pressure)

Current Tuning Options Mass Air Flow:
- BRZEdit
- EcuTeK
- Open Flash Tablet

Current Tuning Options Speed Density:
- EcuTeK - RaceROM

If you as a tuner would like to debate, please let me know so we can add you to the list of people officially debating. Also non tuners (members of the forum), are more than welcome to express their opinion also. Please offer a little background of yourself when giving your opinions.

Debating Tuners:
- William @ Delicious Tuning

Regards,
William Knose

Saving space for later use.

To bad this thread was created during a time that some people aren't allowed to post :)

Well to kick off, there's a great resource here - http://oldfuelinjection.com/?p=4 gives a good summary of the four types of fueling systems (MAF, SD, Alpha-n and the antiquated vain airflow).

About me - I'm an end user who took matters into his own hands, so to speak :D I'm well acquainted with the open source implementation of SD (both the initial one based on Freon's work, and subsequent significant upscaling of the implementation by Merp), both at a code level, and having implemented it on my own vehicle (09' STI).

My personal cliff-notes:

- MAF is much more versatile at adapting to dynamic environments (IATs, altitude, etc.). That being said, SD can be adjusted through various compensations to mitigate some of these issues.
- Flowing from the above point, idle and low load driving was much easier to tune using MAF, whereas SD (where IATs are a key input into the calculation of fueling requirement) could swing very wildly given small temperature changes.
- On the con side for MAF, once you start pushing serious power (I was logging over 500g/s in terms of load) you quickly max out the capacity of the MAF sensor - and hence it's resolutions, at higher loads. In the above example, I was reaching voltage of 4.92v (out of a maximum of 5v), and that was using an 83mm intake, well above stock.
- Along with a larger intake, came a number of other headaches with respect to tuning idle and low load, due to the changed flow characteristics of the charge)
- SD, in my personal experience (mileage may vary), once thoroughly dialed in at the top, gave me more consistent AFRs - and hence a little extra up top.
- Hardware, especially the location of the IAT sensor, is important for a decent SD implementation. You want the IAT sensor as close as possible to the plenum - in other words, reflecting the actual temperature of the air charge entering the chambers as accurately as possible. This is even more critical with forced induction due to the differing temps at the intake and the throttle body.

My 2 cents.

To start the debate, a question has been asked at what point does one need to use Speed Density? Is it at a certain horsepower level, or maybe something else?

Well, from personal experience there is not one exact answer. I have used both MAF and SD (Speed Density) over the years and many scenarios, where SD was useful, otherwise MAF was just as good in all scenarios otherwise noted.

Speed Density Benefits:

Head to Head Competition, where you will be battling it out on the track or similarly where walls are involved. So rally-cross, SCCA, or similar. The benefits are when the piping or intake get damaged you can continue running, and do not need to worry about falling out of a race. Now can you run MAF in these scenario's of course but there is that chance something could occur and knock you out of the race.

Non Head to Head Competitions, such as Time Attack, Rally or Hill Climbs where is a hose pops off, you will be knocked out of the race. The reason is the MAF sensor needs to see airflow and be in a contained system, which if is not, will show in-accurate readings to the vehicles's ECU and therefore will not run well if at all.

MAF Sensor Benefits:

Now on the flip side, tuning a vehicle for Pikes Peak with MAF is a LOT easier than Speed Density (though still completely possible), it does take time. When you are running Pikes Peak MAF will work rather well, in fact pretty amazing. I would even go as far as saying better than Speed Density.

So as far as say Pikes Peak, does one take MAF or Speed Density or vice versa? What are your thoughts? Think of it from a financial point of view for a race team and local Joe, because anyone can enter their vehicle to race up Pikes Peak with proper qualifications of course.

Cheers,
William Knose

I personally would be more than willing to have that person, and we all know who it is to post on this thread if the other tuner would allow it and moderators would be allowing to. So I ask the question, can we all agree to debate professionally.

Cheers,
William Knose

Ah yes, of course - forgot about that specific advantage as well - boost and vacuum leaks don't affect fueling calculation, and you can unleash the inner ricer (vent to atmosphere BOV are perfectly fine with SD).

I like all the information being shared. Everyone, the community, can benefit from non bias information. It will help me decide, with other things, if I'm going to FI my FRS.

What about piping freedom being a bonus to SD? Ive had MAF sensors act up and the tuners have told me its do to the positioning of the sensor, to close to bends or transitions. I do lots of fabrication of piping and some times its difficult to incorporate a long enough straight section to provide straight air to the MAF.

This is what it is intended for. So that you, the community, can make educated decisions based on professional opinions from tuners. Of course you have your local tuners you may be bias towards, but that is absolutely fine.

A great point. When I worked with Kraftwerks to tune their Rotrex supercharger kit they decided to work on airlfow and smooth bends versus making sure the MAF sensor was located in an ideal place. This has is benefits and drawbacks and because of this design we needed to be setup for Speed Density.

But after the initial tune was completed upgrading this kit down the road, will be a lot easier. And making big power with a Speed Density map should go quicker now, as I will not be limited by MAF resolution. Definitely a big plus for me personally on this setup.

Cheers,
William Knose

I wish I had a local tuner, I don't think they have any Subaru tuning shops in Louisiana.

to me it comes down to hardware. if i have a turbo with a 4" inlet, it would probably be a good idea to make the move to speed density and get rid of the maf. if i'm running a stock-size intake tube and haven't maxed my maf, i'd keep the maf setup.

it's not at all about which is 'better'. they are two different approaches to a problem, not a solution to one. the solution is the calibration in either case. it's just a matter of which method makes achieving that ideal calibration easier in a given situation, which i believe is all about hardware.

I would say that virtually everyone with FI(as far as I know) is running the maf as a "blow through" setup, so it really doesn't matter.
The vented air is unmetered and will not cause fueling issues.

This is only true if the leak is before the maf sensor. You could be leaking out your IM/tgv/block gasket or injectors or any of the IM ports that see vacuum / boost and it would be leaking metered air. Blow through does prevent a majority of the boost leaks you would see from boost tubes / couplers however.

Leaking metered air is always a possibility with MAFs.

There are pluses and minuses to each system. When it is an option I prefer a maf based system or a blended set up. But there are applications were the maf becomes a bigger headache to deal with then speed density. If that becomes the case speed density will be the way to go. At the end of the day I feel it comes down to what is right for the particular vehicle more then anything else. I do not feel there is a set in stone point were if you make x amount of power or plan to use your vehicle in this manner you have to choose speed density of maf based calculation.

Perhaps on the BRZ - but not necessarily on other models (e.g. the STI). And this discussion is stated in the general.

I personally feel "blow-through" systems to be a very poor solution for any vehicle. If leaving the system as a Mass Air Flow and only relocating the MAF sensor to a charge pipe is incorrectly using the sensor. Setting up a vehicle this way can cause problems as you are using a airflow sensor to determine quantity of air based on the quantity of air defined by air flow, atmospheric pressure sensor and intake temperatures near or at the air filter.

Placing this sensor in the air flow of a pipe that has a continuously changing pressure is a very bad idea. Because the MAF sensor is basing it's calculations on most importantly atmospheric pressures, the air flow values will be incorrect almost all the time because it can not adjust to the pressure changes in the pipe. Because of this, the vehicle can literally go through the same point in any Load/RPM based table (say fueling or timing) with different boost levels.

Example "Blow-Through" Problems:

Scenario 1: You are tuning for partial throttle say 10 PSI of boost and set your timing values accordingly for more torque. Now under you hit 20 PSI and set your timing values accordingly. Now in these conditions, partial throttle MAF Voltages are 3 volts (air flow) and 4 volts (air flow) respectively.

Scenario 2: Partial throttle climbing a hill under boost (20 PSI) and because of the lack or airflow from the throttle being only 50% open the MAF voltage are around 3 volts. Because of this the timing values will be far too aggressive and will cause detonation. Of course you can tune for this, but then your partial throttle becomes sluggish.

Now with if the MAF sensor would have been in the proper place it would have registered all the air flow properly in order for the FI system to maintain that boost level in those pipes. Or if Speed Density would have been enabled then the tune would have worked properly also.

So "Blow-Through" is just a bad idea and not something that needs to be discussed on this thread.

Cheers,
William Knose

i don't agree with the above at all. i always use blow-through mafs on turbo conversions and they always work fine. you may be right about the specific issues you point out, but we could do the same for any setup. they all have their particular issues.

to be honest i don't really follow your example. i also don't understand how a heated element airflow sensor is affected by pressure, but then i'm no expert on how the things work internally either. all i know is i've had lots of cars with them and they all run just as well as the cars i've had with draw-through or hybrid maf/sd setups.

It is a little hard to explain but like you stated, the MAF sensor is not affected by the pressure differences. That is the exact point, a mass air flow sensor does not know that the pressure has changed, only that the air flow has slowed or increased which translates into a final load value.

So you can have single points in the tables/maps being crossed by vastly different boost pressures because the MAF sensor (which determines load) sees the same speed of air under varying boost pressures. As you have seen, it can be made to work, but I have found it to not be ideal and something I prefer not to tune.

Cheers,
William Knose

Just to clarify, I was only speaking about a bypass/blowoff valve not vacuum leaks at the throttle body/manifold or even an idle control circuit. I've dealt with that enough to know that it can drive you absolutely mad trying to find them.

Was simply saying it depends on the platform and maf placement :)

I would have thought that the maf would "see" more air depending on the density of the charge air so that it would see more air as boost is turned up.... I've only tuned SD so my grasp on MAF tuning is limited.

Can someone explain to me why EcuTeK can do SD? Or, if nobody is willing to pierce the veil of mystery behind the platform that @EcuTek engineered, why can't OFT/BRZEdit/EcuFlash tune a BRZ/FRS with SD?

You are correct. Hence the term mass airflow meter. It does indeed read airflow mass in pressurized conditions. But one issue I've seen in blow-thru MAF applications is oil contamination from oil blow by from turbos. This is why every MAF referenced OEM turbocharged car I can think of (GT-R, Porsche Turbo, etc,.) uses draw-thru MAFs. It's also no surprised that they use bypass valves that recirculate discharged air back into their induction system (downstream of the MAF). Turns out what works for MAF accuracy also works for emissions and noise regulations. Of course, it's important to have a leak-free induction system in MAF referenced systems. But I think this is reasonably easy to ensure with quality clamps and couplers.

I don't believe there has been much of a push for open-source development of Speed Density support. But if the current development state of other Subaru ECUs is any indication, SD (and hybrid MAF/SD) will most likely be supported in the future. Ecutek is usually the first to do things like this since that is what they are very good at (and they are monetized to do so).

But I think much of this MAF vs SD trade-off discussion doesn't even apply to 99% of users who don't plan on making more than 350-400whp. And I suspect even that whp range is conservative.

they've disassembled the rom in something like IDA and added new logic, i'd guess directly in assembly (if that's chinese to you, suffice to say it's a rather low-level way to make a computer do stuff, and not super readable or friendly to work with). probably using techniques along the same lines as commercial software cracking. i've never done it myself so i'm not the guy to ask about it, but i think that's general idea.

open source speed density exists for lots of other platforms, just not ours yet.

One drawback of hot wire MAF sensors is that for the first couple seconds of operation, the wire is drawing a lot of current while heating up to operating temperature, which just happens to look to the sensor as if the engine is ingesting huge amounts of air. For this reason, manufacturers often add at least a 1bar (barometric) sensor and intake air temperature sensor to handle fueling using SD or pseudo-SD during the first few seconds of operation because many folks turn the key straight from off past ACC and ON to START when they get into their car. For race application, it's not an issue since you can teach a racer to turn ignition power on and wait five seconds before cranking the engine. For street applications, the extra sensors also allow SD operation in cases where the MAF fails and also allows the ECU to potentially detect MAF failure or the use of a piggyback unit to alter the input signals.

Both SD and hot wire MAF can be made to run very well in almost all situations provided that the sensors are properly situated and calibrated and that the ECU/EMS is well implemented and expertly tuned. Even alpha-n can be made to work well on NA engines when appropriate barometric and air temperature compensations are applied.

There is another air flow system called a karman vortex MAF which also has its plusses and minuses.

A lot of the practical concerns have already been discussed here. To summarize: the MAF sensor was never designed for very high airflow, and the ECU software as we understand it was never really designed for a full speed density implementation. So you run into hardware and measurements issues with high power MAF-based builds. With speed density, you have the headache of shoe-horning in a control system the engine was never designed for in terms of software and hardware.

Neither set of problems are insurmountable; they're just the nature of pushing a car far beyond what it was originally designed to do in terms of hardware or software.

Now let me address the below question:

The short answer is, you make a set of lookup tables to bypass the MAF signal in the calculation. It's already available for older turbo Subarus. It's a code hack, but it can get the job done. Now let me give a more detailed answer.

So, here's a history lesson. The first speed density system worth noting is the Bosch D Jetronic system. D stands for "Druck," which is German for pressure. That was on the Porsche 914 back in the 1970s and just used a MAP sensor. Airflow based control, called the Bosch L Jetronic (L for "Luft" or air) system, was introduced later (Porsche 924).

Early airflow-based control used a moving door (vane/flap type) to measure volume of incoming air. A Mark III Supra nonturbo had this. A Karman vortex meter was another type of volume airflow sensor using airflow disturbances for measurement. The Mark III Supra turbo had this, and so did many Mitsubishi engines up until the Evo X era.

There are two families of mass airflow sensors. One is the hot wire type and one is the hot film type. The hot wire type, which is what's usually used on Subarus, produces a voltage. The hot film type, which you'll find on say a GM LS1 engine, produces a frequency signal. All the airflow sensors may be packaged with temperature and other sensors.

Speed Density and MAF hybrid

Since the late 90s to early 2000s though many/most control systems are actually both. They're a hybrid from the factory. Most of the widely reverse-engineered Japanese cars don't seem to work that way, but basically everything American and German is hybrid combining speed density and MAF. Do some internet searches on tuning a GM V8 and you'll read all about what's involved. With the right software settings you can basically turn the two systems on or off. Even the modern purely speed density systems are still calculating mass airflow.

Now take a look at a simplified torque model and simplified airflow model to see how this works. This is from the old Bosch Motronic 7 you'd find in something like a late 90s VW.

http://www.ft86club.com/forums/attac...1&d=1386125206

At the upper left you have the driver's request from the electronic throttle. This converts to a torque request. The torque request figures out how to make the torque using fuel AFR, spark timing, and airflow. Then the airflow model determines how much air is needed to achieve the target torque. How does the ECU know what the torque is though? It uses a torque model.

http://www.ft86club.com/forums/attac...1&d=1386125074


So when we talk about speed density and MAF, we're only talking about the cylinder charge estimation. That's one portion of the control system. Then if we break it down to some physics [ame="http://en.wikipedia.org/wiki/Ideal_gas_law"]Ideal gas law - Wikipedia, the free encyclopedia[/ame] you'll see why speed density and MAF are in some ways the same thing and can be substituted.

http://www.ft86club.com/forums/attac...1&d=1386125074

What all this above says is that if I have pressures and temperatures I can model mass airflow, and if I have mass airflow I can model temperatures and pressures. If there's enough information there in the form of accurate look-up tables or real measurements, you can do either one. It gets more tricky when the engine is in a transient condition like accelerating (rather than cruise control at 70mph on flat road). That's where the modeling has to be made to work well, or you have to have a bunch of look-up tables calibrated well enough to get the job done. When variable valve timing and lift gets involved, it's even more complicated.

When you use a speed density software hack, you're replacing a measured value from a sensor with a value from a lookup table and a bunch of correction factors applied to it. The "hybrid" speed density that's been referred to in this thread is more like flipping the software hack on and off based on some conditions. It's not fully like the more advanced modern systems--it's not combining a measured value from an airflow sensor with a modeled value in the same way that cars do from the factory.

But guess what--those OEM systems took a lab full of engine dynos and a staff of engineers and software people to be tuned properly. These aftermarket speed density conversions are a straightforward implementation.

There are a lot of hardware and software limitations to aftermarket tuning of heavily modified engines, but if you put enough time and expertise into it you can make them work well enough to get the job done. You're still going to make sacrifices though, in terms of tuning time and maybe the final driveability.

This is not true. A hot wire MAF sensor, which I believe our cars have, works by measuring the heat loss from a wire which is in the way of the air flow. It then uses this measured heat loss to calculate an air mass flow rate. The amount of heat lost is a function of incoming air temperature, pressure, and flow rate (and other things). Higher pressure (at the same temperature and velocity) would mean more heat loss which the sensor would read (correctly) as more mass air flow. I'm don't know a ton about convective heat transfer so I can't say how large an effect the changing pressure will have on the reading, but it will absolutely make a difference.

I know some of this has been answered above, but let me elaborate.

Firstly, none of this is magic ;) Basically, additional code is written (usually in C++) to undertake the fueling calculations using the speed density formula, and the required lookup tables are added to be referenced by this code. The code is then compiled and inserted into the rom, usually in free ROM space. The way it works is that the existing code calls subroutines in making the (MAF based) fueling calculations. The new SD code replaces this 'hook' into the MAF fueling calculation routine with the custom SD code, and then returns the 'answer' back into the main routine.

That's part of the cons of an SD system shoehorned into a MAF implementation - it's not ideal, since all the key calibrations are still referenced in engine load (g/s) as opposed to pressure, which they would be in a native SD implementation (for example the Subaru group N Rom).

SD has been available in open source for quite a while (16bit roms, Carberry, Freon's implementation of the 32bit version, and more recently a much more sophisticated implementation by Merp). The source code is actually readily available (see here), and once you dig out all the required hooks and addresses in the rom, would be fairly straightforward to compile. I ported some of the earlier 32bit roms, and also worked with Merp on digging out the required addresses on another rom after he set up a patch development platform in HEW that integrates the disassembly from IDA with the Renesas development environment.

I know there are developers on here who should be comfortable working in an IDE such as HEW - I'm willing to work with them to develop a patch. Unfortunately, I started learning arse about end - ASM before C++ - so it's still quite a learning curve for me until I'm comfortable in HEW.

Non of this is magic to me. I have programming experience in Java, C++, and a little bit of machine language (command and binary) as well as browser languages. I was sort of more interested in the coding differences and why the tables for MAF wouldn't work for SD.

Lots of good information here. I guess I am looking for a bit of an ECU side explanation of what is happening for MAF and SD.

The JUMP subroutine in assembly is perfect for this hook you speak of. It kinda makes me wonder if there is a way to reference both at the same time though, and to also change the load to a pressure based system if needed.

Ah, great! I wasn't trying to be facetious - as I'm sure you would know, it is often 'mystified' in the public domain, to the detriment of end users.

Merp's code does indeed reference both at the same time, needed for blending (using a state switch - i.e. pure MAF, pure SD, or blended) - but still using the engine load referenced calibrations. Technically you could create a whole new set of calibration tables for e.g. ignition, fueling that are used for SD rather than MAF. It starts getting quite tedious though, since the entire logic of the ECU is geared towards MAF, so all the compensation tables, tau / transient tables, etc. etc. are load referenced in some way.

I could take you through the code, but I fear it will start getting quite OT in this thread - maybe we can start another thread?

The hook is a JSR, e.g.

OK, I understand you logic and how you described the MAF sensor. But what I have noticed from experience higher pressures at the same temp and velocity as a lower pressure the MAF sensor can only tell the difference to a point. Being designed as a draw-through the system is based on atmospheric pressures, which do change, just not as wide and drastic as boost pressures.

Though I am more than willing to learn more about it and look into it more.

Cheers,
William Knose

The knowledge from the members on these forums always amazes me. Definitely a lot different from the year 2000 on the forums. I have some background in programming, Java, C, Assembly Language, etc..., but it has been some time since I really have used it.

Why would you need to create a whole set of calibrations if you could create a well defined MAF look up table based off the MAP sensor and RPM and other compensations? I understand there is the theory that if you create a whole new set of calibration tables it will perform better but if the MAF lookup table does the same job what would be the difference?

Cheers,
William Knose

You're right, it's not a low level ECU side explanation. I'll admit my knowledge of that is limited. But the overall model-level control is how basically every modern speed density system works: a gasflows model using the ideal gas law or saint venant flow equation, where pressure and flows are built into all the calculations. Whether there is a MAF sensor or not is to some extent just a switch to flip inside the code of modern control systems.

Based on what's been reversed engineered, Subaru appears to be very much behind the times, which isn't surprising considering how small they are. But that leads for simpler modding in some ways.

The low level stuff (what assembly commands are used and where it's stored) is important to make sure there isn't any kind of bug or hardware issue, but the high level--the big picture of the control system--is what ultimately affects the tuning. In a typical controls development process, the block diagrams and control architecture are developed first in prototype phase, and the final details of the low level code and hardware implementation are last.

I agree that speed density systems have historically used raw pressure values as the main load calculation. Standalones still do that. If you look at all the modern systems though, they are converting pressure into airflow anyway. This is through the gasflows model I referenced above.

So there's nothing inherently wrong with converting some pressure into a flow value like all the SD conversion ROMS do. You just can't possibly do an OEM level of control, especially since modern speed density systems on turbo engines use multiple pressure sensors. With the SD conversion roms, when compared to a native implementation you're giving up complexity for simplicity.

I agree that the heat transfer could be affected by changes in pressure. But these MAF sensors were never designed for blow through, so I don't think anyone can say how sensitive they are to such changes in pressure without controlled bench tests.

In the end when you're tuning it you just end up putting whatever values into the various tables to get the best results you can.

Well - exactly - that's what the current implementations do (COBB, open source, and I assume Ecutek, not having seen it). Ultimately, what you want is an accurate (or as accurate as possible) calculation of the airflow. As long as it works!

This is basically how the opensource implementation works - using the ideal gas law, i.e. engine displacement, SD constant, VE etc.

The worry with implementations on stock ECUs, as with any modification really, is what unknown compensations and logic are at play. With 250,000 lines of code plus, and only a fraction understood / disassembled, there is always more to learn. But as with most tuning, you can do a pretty good job as long as you have access to the main levers re: timing, fueling, airflow.

Exactly the point - and if you look how far after market modification for our cars has come in the past 7/8 years, it's actually quite phenomenal...

That sounds about right depending on what assembly code the ecu uses. I would suspect the whole computer is written somewhere at a level between hex and really basic languages that go slightly beyond just assembly since the code would only have to be compiled for one architecture.

EcuTeK Speed Density Custom Mapping
 

Here is a little more on EcuTeK Speed Density and photos directly from their software.

EcuTeK Custom Speed Density Tables

- Speed Density Activation MAF - ECU will use SD Mass Airflow map rather than MAF sensor above this MAF. For hysteresis, top value should be higher than lower value

- Speed Density Activation MAP - ECU will use SD Mass Airflow map rather than MAF sensor above this MAP. For hysteresis, top value should be higher than lower value

- Speed Density Activation RPM - ECU will use SD Mass Airflow map rather than MAF sensor above this RPM. For hysteresis, top value should be higher than lower value

- Speed Density Mass Airflow - Mass airflow derived from RPM and MAP

- Speed Density Temperature Compensation - SD Mass Airflow adjustment based on IAT

- Speed Density Throttle Delta Compensation - Compensate SD based on Throttle Delta and RPM

http://www.delicioustuning.com/sites..._Tables_01.png

http://www.delicioustuning.com/sites..._Tables_02.png

All tables can be enabled based on:

- Map Mode - In which map mode speed density will be active, available maps are 1,2,3,4

- Thresholds - This will offer the ability to offer a change when Speed Density is active. Active only above/below threshold maps.

Cheers,
William Knose

SD hook
 

Looking for an opensource hook into the MAF lookup subroutine to implement SD...

Using the A01G ROM, the subroutine at 2B0D6 (2B17E in A01C ROM) is the only place that I can find that sends MAF_V to get looked up

For the MAF table, 2B0D6 is called with r13=08, MAF_V in fr4. The Pull2D function is called and the return MAF value is in fr0.

As this table is is indirectly referenced and a few other sensors (ECT, IAT, OilTemp) also use this subroutine, does anyone have a good idea as to how to jump out and back in seamlessly? Looks to me that the hook on Pull2D would work, then need to jump into MerpMod or similar code based on the value at r13.
@Td-d, NSFW, Merp, dschultz: Anyone have good ideas?

To contribute to the debate and discuss "not something that needs to be discussed", I've just put a Greddy system in with MAF sensor after intercooler and right before the throttle body in blow-through fashion.

Below is a plot of MAF Voltage vs AFR error (Wideband-AFR_Command/AFR_Command) on a Bosch 4.9 PLX wideband in the rear O2 sensor position, daily driven logs. Boost up to 9psi for these logs. Parameter filters: Open Loop operation not in decceleration mode, ECT >80, Throttle >10.

Quite close to maxing my MAF here, but blow through in this position seems to work ok for me (I'm always WOT at the top end of the scale, so not much partial throttle boost variation to give the above scenarios).

Hi Ztan - that's exactly the routine, and yes, the pull2D is hijacked to jump across to the Merp SD code in other implementations. The problem with the BRZ code is that, as you've picked up, it's referenced indirectly using an offset, as opposed to a distinct subroutine, which presents the problem of how to only specify it to the MAF voltage, as opposed to the other sensors in that offset (IAT, Oil Temp, ECT). Haven't really thought about it to be honest, but perhaps the easiest would be to add in some conditional logic at the begining of the Merp SD code that is not there currently, namely check the value of r6, and if it's not the 3rd byte in the offset table, i.e. 0xC, then pass the logic back to the subroutine, else, continue with the SD code.