Originally Posted by Luckrider (Post 1367034)

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?

Originally Posted by jamesm (Post 1367109)

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.

Originally Posted by arghx7 (Post 1367360)

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.

Originally Posted by Td-d (Post 1367882)

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.

Originally Posted by Luckrider (Post 1367953)

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 Luckrider (Post 1367953)

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.

Originally Posted by u/Josh (Post 1367524)

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.

Originally Posted by Td-d (Post 1367972)

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.

Originally Posted by Luckrider (Post 1367953)

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 (Post 1367882)

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

Originally Posted by u/Josh (Post 1367524)

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.

Originally Posted by DeliciousTuning (Post 1368397)

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

Originally Posted by arghx7 (Post 1368440)

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.

Originally Posted by arghx7 (Post 1368440)

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.

Originally Posted by Td-d (Post 1367972)

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.

Originally Posted by DeliciousTuning (Post 1368397)

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 (Post 1368440)

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.

Originally Posted by DeliciousTuning (Post 1366650)

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

Originally Posted by ztan (Post 2162636)

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?