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

[Td-d]

Originally Posted by Luckrider

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?

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.

[Luckrider]

Originally Posted by jamesm

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.

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.

Originally Posted by arghx7

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.


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.

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.

Originally Posted by Td-d

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.

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.

[Td-d]

Originally Posted by Luckrider

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.

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.

Originally Posted by Luckrider

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.

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.

jsr     @r3 ; Merp_Speed_Density_Patch

[DeliciousTuning]

Originally Posted by u/Josh

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.

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

[DeliciousTuning]

Originally Posted by Td-d

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.

jsr     @r3 ; Merp_Speed_Density_Patch

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

[arghx7]

Originally Posted by Luckrider

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.

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.

Originally Posted by Td-d

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).

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.

Originally Posted by u/Josh

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 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.

[Td-d]

Originally Posted by DeliciousTuning

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

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!

Originally Posted by arghx7

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.

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.

Originally Posted by arghx7

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.

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...

[Luckrider]

Originally Posted by Td-d

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. I didn't take it as such and unfortunately, that is usually the case with any product not inherently directed at tech people.


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? I don't think we need a whole new thread, just small snippets of what is happening at the command level that affects the logic flow chart

The hook is a JSR, e.g.

jsr     @r3 ; Merp_Speed_Density_Patch

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.

Originally Posted by DeliciousTuning

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. The internet does wonderful things for helping bring people with various backgrounds together to collaborate on projects. Hopefully the diverse knowledge base of our community will continue to grow and foster amazing advances in this platform.

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? This is a lot of what I was wondering with my question as to what is going on at the ECU side. It sounds to me like the ROM can be hacked to handle different input values, or the tables can be recalibrated to account for the change in readings (similar to how people change the target AFR for e85 in the head so that it matches what the e10 calibrated sensors read).

Cheers,
William Knose

Originally Posted by arghx7

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. "SeaGreen"]Often times simple is better for custom projects. Simple allows for many more implementations of a solution, usually at little to no drop in efficiency.[/COLOR]

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. The low level we are talking about is only as a reference to how a system specifically works.



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. If this is the case, couldn't SD be done with our cars simply by converting to MAF style readings?

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.

[DeliciousTuning]

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





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

[ztan]

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?

ROM:0002B0D6 loc_2B0D6:                              ; CODE XREF: sub_2B0A2+28j
ROM:0002B0D6                 mov.l   #off_10DF8, r2  ; Sub at 2B17E in A01C
ROM:0002B0D6                                         ; MAF:
ROM:0002B0D6                                         ; r13 = 08
ROM:0002B0D6                                         ; fr4=MAF_V
ROM:0002B0D8                 shll2   r6              ; r6=2 SHLL r6=8
ROM:0002B0DA                 mov     r6, r0          ; Move Data
ROM:0002B0DC                 mov.l   @(r0,r2), r4    ; r2=10df8
ROM:0002B0DC                                         ; r0,r2=10e00
ROM:0002B0DC                                         ; r4=b86e0
ROM:0002B0DC                                         ; A01C: r4=d0560
ROM:0002B0DE                 movi20  #Q_Pull2D, r2   ; Q_Pull2D at 11388
ROM:0002B0DE                                         ; A01C: 1139C
ROM:0002B0DE                                         ; MAF_G_S value returned in fr0
ROM:0002B0E2                 jsr/n   @R2 ; Q_Pull2D  ; Jump to Subroutine with No delay slot
ROM:0002B0E4                 bra     loc_2B100       ; Branch
ROM:0002B0E6                 fmov    fr0, fr9        ; Floating-point move

[ztan]

Originally Posted by DeliciousTuning

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

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).

[Td-d]

Originally Posted by ztan

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?

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.

[ztan]

Just posted up my opensource SD solution:
http://www.ft86club.com/forums/showthread.php?t=86521

Happy for anyone to use the code and develop (at their own risk) or integrate into MerpMod.