Speed Density for DBW

Speed Density for DBW

Postby Freon » Sat May 17, 2008 2:06 pm

I want to help as many people as possible, and I cannot do this by helping people privately one at a time. So I ask that people do not send me PM's. Rather than seem rude when I ignore you, I ask you post in this thread if you have questions. You may or may not get an answer. I have limited time with my day job, tuning my car, tuning cars on the weekends, and other hobbies. I'd like to make the most of the time I can set aside sharing with the community.

Q. What is the scope of this FAQ?

A. This FAQ aims to answer common questions that new users of the SD system may present. Tuning AFR, timing, and boost will NOT be covered. Furthermore, it is assumed the reader already has a VERY solid grasp of tuning Subarus and tuning in general. There are many other FAQs and information sources for that. This FAQ will cover how the SD system may affect other aspects of tuning, but it is important the reader already understands these systems independently. This is not a system to be used by people new to tuning!


Q. Who is the intended audiene of this modification?

A. Tuners with at least a year of tuning experience Subarus from scratch (stock maps). Those who already solidly have the concept of air to fuel ratio, timing, knock correction, and boost control understood. Tuners should also have experience successfully tuning injector latency, injector flow, and MAF scaling on several cars. These aspects of tuning need to be well understood going in to avoid misinterepretation of what part of the tune is working incorrectly. Since this is a new feature, the most important thing to tuning it correctly will be understanding when the SD part needs to be tuned and when it is another part of the tune that is in need of attention.

This is not a modification for a new tuner to learn. Perhaps as more community is built around, a better information bridge and community support will grow. Perhaps using the MAF will become complete passe for Openecu users. But, for now and at the time of writing this, I will only state this is a modification for those who have MAF calibration problems, big turbos, and those who know well going in how tuning works.
I also strongly suggest that potential readers have read the following books at least twice
through:
How to Tune and Modify Engine Management Systems by Jeff Hartman
Maximum Boost by Corky Bell
Forced Induction Performance by A. Graham Bell
http://freon.shackspace.com/car/ecu%20and%20tuning/books.html

The more experience the user has in tuning MAF scaling tables the better as well, as tuning your VE is a very similar process.

If you meet all of the above requirements, you will probably have success with the Speed Density conversion. If you do not, this is throwing another wrench into learning tuning and may lead to incorrect attribution of symptoms. I suggest you stop reading NOW if you do not meet the above experience and research level.

Q. What's the purpose of this modification to the ECU? Why do this? What not use the hotwire MAF?

A. The purpose is to side step some the limitations of a MAF setup. The primary
issues are:
1. Stock and near-stock-diameter intakes will hit high voltage with moderate to large turbochargers. A stock or stock-diameter intake with a large turbo is not adequate for this reason.
2. Large diameter MAF setups are difficult to tune, and may never offer equal or acceptable idle stability (i.e. stalling issues, hesitation, long tune times, extra troubleshooting)
3. Minor changes to the intake may cause unacceptable changes to the tune. This can require retuning or at least ECU and wideband logging to confirm the changes are within acceptable limits.
4. Even minor leaks can really screw up fueling on a MAF car. While SD doesn't eliminate all problems with leaks, they're less of an issue. This is covered further later in this FAQ.

There is also the benefit of being able to run both recirculating and vent-to-atmosphere blow off valves with SD. There is no richness when the valve opens, no matter if the air is being recirculated or dumped out of the intake system. Changes in the blow off valve may still affect the tune, but they can be adequately handled.

Q. What is the gist of how this SD system actually works?

A. Simply, the MAF scaling table is replaced with a VE map. That's the bulk of it. There are certainly finer details to it, but it is important to note is everything else is exactly the same. Granted, the airflow g/s trickles down into much of the rest of the ECU, but really the *changes* are only in how the airflow g/s number is produced.

Maps are still organized by "engine load" and not manifold pressure. All the open/closed loop stuff is the same. Boost control is the same. Basically, any other question about how the ECU operates is going to be answered with, "it works exactly the same." I could spend all day answering questions with, "no, it works the same," so take special effort to realize the only thing changed is the MAF scaling table has been effectively removed and replaced by a VE map and a simple equation.

Q. How does this differ from other SD systems?

A. Some other systems would use a 3D table of RPM vs. manifold pressure that is filled in directly with injector pulse width. I am *not* using that kind of system, as it would require a more radical redesign of the ECU. Having a straight-up pulse width map would require a *major* retooling of the ECU. Things like fuel trim would be difficult to redesign in such a system.

Other more similar systems would use a VE table, but typically changes to VE would not affect timing because the load reference on timing would be MAP, not engine load. Again, since the mass airflow number is still used to calculate engine load in this system, changes to VE trickle down and affect airflow, load, and thus where on the timing tables the ECU pulls its values.

Q. Can you explain how the more scientific/technical/math stuff behind this works?

To recap, all I'm changing is how the MAF g/s value is determined.

The calculation needs to solve for "Grams per Second" unit so the MAF scaling table can be functionally replaced. This is a targetted decision on how to design the system. The calculation is based on the Ideal Gas Law which states the following:
PV = nRT
where
P = Pressure (absolute pressure, manifold, i.e. MAP)
V = Volume (swept volume of the engine, displacement)
n = moles of air, what we're trying to find (literally a count of molecules)
R = the universal gas constant
T = temperature (absolute, i.e. kelvin)

It can be transformed algebraically to
n = PV/RT
so we can solve for moles of air that the engine "holds" statically. Moles of air times its molar density (constant, ~28.9g/mol) gives us grams of air sucked in per engine revolution. Then, since we're solving for a dynamic rate of flow for a system we need to add speed (how many times the moles are gobbled up in a unit time) and volumetric efficiency (how well the engine displacement is filled). This is just basically multiplying by engine speed and VE.

The rest is just working out all the units of measure. Remember all your factor label conversions from high school chemistry? Things that need to be sorted are getting minutes (from RPM) to seconds, moles of air to grams (atmospheric air has a pretty constant mass per mole), pressure from mmHG to Pascal (ECU uses mmHG, Ideal Gas Law is typically quoted for Pascal), and soforth.

Luckily, since much of the above involves no dynamic values, a single constant can wrap all of this unit conversion, gas constant, and mole airmass nonsense into a single value. The actual code has a programmed constant for this. This, along with careful instruction ordering to keep all the CPU pipelines filled, keeps extra CPU time used to a minimum. The actual SD code is very compact. If the old MAF code was removed it would in fact take less total code to calculate in most circumstances.

The biggest fudge made is that we need a good VE map. It's impractical to calculate a VE map the tools available to the average tuner, so it needs to be found experimentally.

There are a few other assumptions that I will not spend time defending because they are also assumptions with a mass airflow sensor. Such assumptions involve how net airflow relates to actual air flow in the cylinder with regards to things like blow-through, dynamic compression, etc. I do not see how such aspects are any worse with this system than they are with a hotwire MAF.

The VE map is a 3D map of RPM vs. Manifold Pressure. I found through my own testing that VE varies not only by RPM, but also manifold pressure, so a 3D map was created. A 2D map with RPM alone was not sufficient. I've found no other significant factors in calculating a fast, accurate mass airflow number with the above model.

Once a mass airflow number is calculated, it is used in *exactly* the same manner as the number that used to come from the MAF scaling table. I cannot make this point strongly enough! There will inevitably be many questions that will effectively be answered by understanding this point.

Q. How did you come up with the VE map in the base ROMs?

A. The first map I used was created by taking previous MAF logs and back calculating for VE. This got me close, but it is hard to transform that perfectly to a 3D RPM vs. MAP array. The remainder of tweaking was found experimentally. The technique is the same as adjusting the MAF scaling table using fuel trims, stock wideband, and aftermarket wideband readings.

Q. Is the stock MAP sensor sufficiently accurate and fast? What is the failsafe?

A. I haven't found any reason to believe it is not. The ECU reads the MAP sensor voltage and converts it to manifold pressure just as often as it does for the MAF sensor. The value from MAP is used immediately after analog to digital conversion and is NOT filtered, averaged, or checked for failsafe before used in the SD system.

If your MAP sensor fails, the car will not run at all, or run very poorly. The existing check engine codes and failsafes for MAP remain untouched, but since MAP is the failsafe in the event of MAF failure a very basic SD code (with no VE, very crude) with MAP is used for fueling. With this new SD system, the opposite is NOT true. There is no backup method of fueling if the MAP sensor fails. MAP sensor failures don't seem to be a problem with Subarus, so I have not built in a failsafe for this. It is technically possible to revert back to MAF in the event of MAP failure for fueling, so this may work its way in at a later date.

Q. How do I tune the VE map?

A. Part 1 Essentially the same as you tuned your MAF scaling table, except it is a 3D table instead of 2D. The rest of this document will supply additional hints, but essentially you need to look at your fuel trims for low load/rpm and compare your WB02 to your fuel map for high load and high rpm. This should be a familiar process more or less.

The supplied VE map will get you started as well. The lower airflow areas and idle should be very close if you are on stock intake and exhaust manifolds regardless of what turbo, intercooler, and exhaust you have. If you have big problems with idle and cruise, start by tweaking injector scaling and latency.

A. Part 2 Increasing VE adds fuel. Decreasing it lowers fueling. Instead of looking at your MAF voltage and changing that spot on the MAF scale, you need to look at your RPM and manifold pressure and adjust that spot on the 3D VE table.

Essentially the metrics and reasons you use to justify changes to MAF scaling will be the same as you use to change the VE map. Use fuel trims and your front O2 readings for low to medium load and RPM, and use a wideband for high RPM. I will not cover this extensively for now, as these should be familiar ideas by now.

Q. How do I tweak idle? How does injector latency factor in?

A. First, injector latency needs to be "correct." If you have previously set it higher or lower than actual reported latency to adjust for an aftermarket intake, you need to set it back to what it really "should" be. You will not need or want to adjust injector latency to fix idle or stall issues due to weird intake MAF response, as this is now irrelevent.

You also should not need to tweak the idle airflow and idle load maps. The core issues that would cause you to want to change these maps are negated by removing the MAF and replacing it with a speed density fuel calculation. I suggest reverting back to stock idle load and idle airflow maps.

From there, you will be modifying the VE table at the RPM and vacuum level your car idles at. RPM will certainly just be 800, and vacuum will be about -10 to -7 psiG depending. The important part to get right here is the ramp across load columns. VE should jump up pretty fast from idle vacuum to zero psi at 800 rpm, then hold steady above that. You never really will hit boost at 800 rpm, so don't worry about that. If the car wavers, again, watch the vacuum and try to identify if it is going rich or lean as vacuum goes up and down. Also keep in mind even the front O2 has a slight delay at idle.

If you do leave injector latency too high, you'll notice you have to greatly lower VE at idle to keep fuel trims in line. If you notice a massive drop in VE near idle, you probably set your injector latency too high.

Q. What if I change my AVCS settings? How does AVCS factor?

A. AVCS changes will usually change the engine's actual VE, meaning you will need to adjust your VE table. If you start by having fuel trims right and open loop fueling matching your fueling table, you can see where to tweak your VE map by looking at how your fuel trims and WB02 change readings at a given boost and RPM.

For example, if you have a car tuned well but with a stock AVCS map, and it spools at about 14.0:1 at 3200rpm at 0 to 5 psi, then change AVCS, you might see your spool suddenly go to 15.5:1 at 3200rpm at 0 to 5 psi. This means you need to increase the VE at that RPM and boost level.

This also means your AVCS changes just worked, and you're flowing more air. VE changes are pretty obvious with a VE map as you'll run leaner than before. Be careful, as you don't want to suddenly find you are running lean and running the same timing when your AVCS changes just let you flow 2-3% more air. It is best to run slightly conservative fueling and timing while tuning AVCS and make minor changes each test.

AVCS tuning itself is outside the scope of this document. But, I will briefly suggest that you test by try several maps with stock-like shape, but at 3-5 degree increments apart. As long as your Fuel Trim D doesn't move and you don't change anything else in the map, the AVCS setting that processes the leanest wideband readings is flowing the most air. I will not digress any further into AVCS tuning here, or in discussions of speed density.

Q. Where should the MAF be located for the IAT reading?

A. There are two good spots and several bad spots. Air temperature certainly does come into play given the Ideal Gas Law takes into account air temperature. Lower temperature in the manifold definitely increases airflow.

* Overall the best place would be between the intercooler and intake manifold in a blow-through location. Remember, pipe diameter doesn't matter since we are not using the actual MAF signal. There are plenty of blow-through boost tube options out there. Just get the IAT into the charge stream after the intercooler.

* The second best place is before the turbo, but with a cold air intake. While it will not measure the air temperature that is going into the manifold, the air temperature you do measure should be correlated to how well the intercooler is working. A roughly equivalent location would be to place the IAT adjacent to the intercooler in the bumper so
it gets the same airflow as your front mount intercooler. The key point to realize here is the IAT should be close to ambient temperature flowing over the intercooler. That's how the correlation is maintained. The slightly temperature gain from IAT to manifold air temp can be "absorbed" or "accounted for" by adjustments in the high load areas of the VE map.

* The two different locations (blow through and cold air) above will result in a different VE map while in boost, with the biggest differences at the highest boost and practicaly no difference under low boost, zero boost, or vacuum. The blow through will read a higher temperature under the same conditions (same actual airflow) so the VE map will need to be
set slightly higher for the SD system to end up calculating the same total airflow as the cold air intake located IAT sensor. Technically the blow-through VE map would be end up being more accurate.

* A bad spot would be in a hot air intake. The intake temperature will not really match the air temperature after it has been cooled by the intercooler, thus you lose the correlation. That is, the VE map cannot be adjusted to fix this. Adjusting the Airflow vs. IAT airflow compensation map may help, but this is an extra map to have to fix, and then the map cannot be used to adjust for other things. Idle will be difficult to handle and fuel trims will vary based on intake temperature. (As an aside, this is the same core reason I do not like hot air intakes in general, not just for speed density. The difference here is it not only affects compensation tables but also directly affects fueling calculation.)

* Another bad spot would be after the turbo, but before the intercooler. There is going to be a massive change in temperature from the IAT to the manifold. There is little way to correctly compensate your tune in general based on IAT. What happens when it is 20F outside vs when it is 50F out? Who knows... The ECU certainly won't!

* Another possibility would be to measure temperature in the intake manifold itself. You cannot actually mount the MAF in the intake manifold. You would need to buy a manifold air temperature sensor, tap a hole, mount the sensor, splice the wiring in (not necessarily straight forward), and then calibrate this new sensor by modifying the IAT sensor scaling
table (this could be difficult). I have not attempted this yet myself, so I will not pass judgement either way as to how well this would work. Technically it is optimal to measure temperature at the same location as pressure (i.e. the manifold), so it should work best. The ideal gas law assumes pressure and temperature are measured at the same location.

* As odd as it may seem, if you have a hot air intake it is best to remove the MAF and place it in a location where it will have the same air temeperature as the intercooler gets. If it were practical I would say tape the MAF onto the front of your intercooler (TMIC or FMIC). However, you will no longer be able to log "Old MAF" and get a remotely valid value since the MAF element is not in the intake path.

Q. What about the airflow vs. IAT airflow compensation map? IAT timing compensation? Other misc. IAT compensations?

A. How you tune these maps will depend greatly on where you are locating the IAT sensor. On a blow through or manifold temperature location you should not need to use this compensation to maintain consistent AFR (instead, fix your VE map). On a hot air IAT sensor location you may have to add fuel at higher IAT. It may be difficult to determine
if you should adjust your VE map or this airflow vs. IAT map. You will need more than one data point to determine this.

Q. What happens if I have a leak between the air filter and the turbo?

A. Mostly nothing. You might get some unfiltered dirty air. There are really no drawbacks or big problems with even major leaks in the intake before the turbo. Afterall, you could pull the intake complete from the turbo and leave it open, or just put chicken wire or mesh screen over it. You don't even need an intake. If you had a car that was severely limited by a poor flowing air filter, a sudden leak here may affect actual VE.

In a MAF car, a leak between the MAF and turbo can cause you to go lean, which can be dangerous depending on how bad the leak is and how it reacts at different airflow levels. A leak that only leaks a lot at high flow could cause you to go dangerously lean at high load levels AND run higher timing, causing knock. Almost a moot issue with SD!

Q. What happens if I have a leak between the turbo and intake manifold?

A. This situation in a MAF car will cause you to go rich. The bigger the leak, the richer you go. In SD, you won't. This is both a good and a bad thing. It is harder to look at a log file and see a leak. If you suddenly hit 10.2:1 AFR on your wideband when your fuel map says 11.0:1 and you have been hitting 10.9-11.1:1 previously, you just sprung a leak and it is fairly obvious. With SD, you may not notice. The air that leaks out still counts against you on the turbo's compressor map, though! You'll be further to the right, closer to the choke line by exactly the amount of air you are leaking.

I suggest using the same intake system leak test as people typically use for MAF cars, with an adapter and pumping the intake system with pressurized air. I will not cover this in detail here as it has been covered elsewhere countless times.

Q. What happens if I have a minor intake manifold vacuum leak?

A. If the leak is not bad enough to actually cause idle vacuum (manifold pressure) to change, you just potentially get some unfiltered air into the engine. Not a big deal. You will get some compressed air leaking out under boost, but as above with a post-turbo leak, if it is minor it will be a negligable problem.

If the leak is only near one cylinder, it could cause a loppy idle and would lead to the same troubleshooting steps as with a MAF. In this circumstance there isn't any distinct advantage to using SD.

Q. How is "engine load" affected?

A. It is not directly affected. Again, mass airflow g/s is now calculated via speed (rpm), density (manifold pressure) rather than looking it up on the MAF scaling table. Either way, this number is later used by the ECU to come up with the engine load parameter. Understanding this is key to successfully grasping the concept of this SD system.


Q. How does logging work?

A. The standard SSM airflow g/s values are what is calculated by SD. There are new direct-log parameters available in the modified logger XML to log "Current VE" and the old MAF scaling table. There is also a new direct-log parameter called "raw airflow" which is always how much airflow the engine would flow at the current moment IF VE was 100%. It is an intermediate value needed for SD, so I put it in for those who are curious.

Q. So, really, how well does it work?

A. I've found it works extremely well. It completely negates any problems you may have had, do have, or will have with getting any number of aftermarket intakes calibrated right, or their funky behaviors due to temperature, turbulence, tidal effects of the moon, and soforth.

Still, I do not yet recommend it for small or stock turbo cars. I feel it is not really required. Stick with a stock intake and a clean filter and keep leaks out and you shouldn't have problems. Adding tuning time for an aftermarket intake or SD VE map is not worth the time and effort.

Q. Do you plan on making new versions?

A. Possibly.

Some things I would like to do include:
* I would like to create a Type B system that simply changes the load reference on most important maps (like base timing, timing advance/KC, AVCS, etc.) to manifold pressure rather than "load." This would limit the trickle down effect of changing the VE map having an effect on timing (rather than just fueling). For now, keeping load based on VE forces people to pay attention to their VE maps by making small changes and carefully adjusting their injector parameters rather than covering up for bad latency or scaling values in the VE map. There are good arguments for and against making this change.

* Failsafe. When MAP check engine light is active, fall back to MAF for fueling. Kinda like the reverse of what a MAF cars does when the the MAF goes into failsafe mode and uses a very half-assed speed density hack to keep the car running.
Last edited by Freon on Sat May 24, 2008 6:05 am, edited 1 time in total.
Freon
 
Posts: 700
Joined: Thu Nov 17, 2005 5:50 pm
Location: Indianapolis, IN

Postby Freon » Sat May 17, 2008 2:07 pm

Image
Above: My VE map as of a few days ago.


Now here's the worksheet I used to developing SD. The orange cells are intended as input.

http://freon.shackspace.com/car/ecu%20a ... 20work.xls

This was designed and used to do the following:
1) Simplify the number of steps in SD calculation to minimize number of operations in actual ASM code (solving for a "k" value)
2) Estimate my first VE map based on old MAF log file data. There is a sheet to type in MAF g/s and it outputs VE and one that you put in VE and it outputs SD g/s.

Source code:
Code: Select all
/*
  Speed Density algorithm path for SuperH 7055f ECU
  v0.02

    Copyright (C) 2008 Victor C Hall

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

finish_maf:
mov.w   (rpm), r1
mov.w   (dmap), r2
fmov.s   @r1, fr15         ! fr15 = rpm
mov.w   (map), r1
fmov.s   @r2, fr14         ! fr14 = delta MAP
mova   (EngDisp), r0      
fmov.s    @r1, fr13         ! fr13 = MAP
mov.w   (airtemp), r1
fmov.s   @r0, fr12         ! fr12 = engine displacement
mova   (c2k), r0
fmov.s   @r1, fr11         ! fr11 = airtemp in celsius
fmov.s   @r0, fr10
mova   (const_sd), r0
fadd   fr10, fr11         ! fr11 = airtemp in kelvin
fmov.s   @r0, fr10         ! fr10 = speed density constant (k), see spreadsheet
fmul   fr13, fr12         ! map * eng displacement
fmul   fr15, fr12         ! (map * eng displacement) * rpm
fmul   fr10, fr12         ! (map * eng displacement * rpm) * constant (fr10 free)
fdiv   fr11, fr12         ! raw airflow, (fr11 free)
mov.l   (pull3d), r9         ! @r9 = pull3d
mov.w   (sd_rawflow), r8
mova   (dyndef),r0
mov   r0, r4
jsr    @r9            ! pull dyn map
fmov   fr14, fr4         ! set fr4 map lookup to delta map
fmov    fr0, fr11         ! store dyn comp in fr11
mova   (VEdef), r0         ! set r0 = VE map definition address
mov   r0, r4            ! set r4 = VE map definition address
fmov   fr13, fr4         ! set fr4 = MAP for map pull
jsr   @r9            ! pull3d (retrieves VE)
fmov   fr15, fr5         ! set fr5 = rpm for map pull
mov.w   (ve), r0
mov.l   (maf_out), r1
fmov.s   fr0, @r0         ! store VE @ FFFFC400
fmov.s   fr12, @r8         ! store raw airflow @ FFFFC404
fmul   fr0, fr12
fmul   fr11, fr12         ! calculate in MAP dynamics map
fmov.s   fr12, @r1         ! store final SD calculated airflow in place of MAF

lds.l   @r15+, pr
rts
mov.l   @r15+, r14

map:
.word 0xA4E0      ! manifold absolute pressure, 32bit float, mmHG

.align 2

maf_ad:
.long 0xFFFF9022   ! MAF A/D value (multipled by 38A00000 = volts)

maf_adconv:
.long 0x38A00000   ! MAF voltage (16bit value) to floating point (volts) multiplier

maf_def:
.long 0x5594C      ! MAF scaling table definition reference

pull2d:
.long 0x208C      ! location of pull_2d subroutine

maf_out:
.long 0xFFFF90F4   ! Location to store output airflow Grams/Sec, 32bit float

maf_diag:
.long 0xFFFF90F8   ! Byte for storing MAF over/under volt diagnostic (#0 ok, #1 overvolt, #2 undervolt)

maf_maxvolt:
.long 0x614FE      ! 16bit value direct compare to A/D value for MAF overvolt diag

maf_minvolt:
.long 0x61500      ! 16bit value direct compare to A/D value for MAF undervolt diag

rpm:
.word 0xA78C      ! engine RPM, 32bit float

dmap:
.word 0xA4D4      ! delta MAP

ct:
.word 0xA5DC      ! coolant temp, 32bit float, degrees celsius

airtemp:
.word 0xA5E8      ! airtemp (should be manifold airtemp, but IAT will work for now)

ve:
.word 0xC400      ! free memory spot to store ve (32bit float)

sd_rawflow:
.word 0xC404      ! free memory spot to store intermediate raw airflow (32bit float)

old_airflow:
.word 0xC408      ! free memory spot to store SD calculated airflow (32bit float)

.align 2

const_sd:      
.float 0.003871098   ! constant needed to wrap up other conversion constants for Ideal Gas Law to ECU units of measure
         ! saves a lot of cycles, see spreadsheet for proof
         ! g/s = (Liter*mmHG*RPM / (Celsius+273) * k * VE
         ! then multiply by any other compensations desired

c2k:
.float 273.15      ! number to add to celsius to get kelvin (required for ideal gas law)

EngDisp:
.float 2.457      ! engine displacement (2.457 liters)

pull3d:
.long 0x2100      ! pull3d subroutine location

! ******************** MAPS BELOW ********************

VEdef:         ! volumetric efficiency map, manifold pressure col, rpm row
.word 13      ! 12 columns
.word 18      ! 18 rows
.long VEcol
.long VErow
.long VEdata
.long 0x8000000      ! 16bit data
.float 4.57763672e-5   ! gradient for 16bit to float conv
         ! 1.5/32768  (0-1.50 range, 16bit precision)
.float 0      ! offset for 16bit to float conv (+ 0)

VEcol:
.float 165,285,385,500,625,725,875,1025,1250,1400,1600,1800,2000

VErow:
.float 800,1200,1600,2000,2400,2800,3200,3600,4000,4400,4800,5200,5600,6000,6400,6800,7200,7600

VEdata:
.word 7150,7449,9958,10351,10665,10794,10943,11089,11177,11242,11307,11383,11383
.word 7398,7646,9694,10132,10499,10716,10956,11076,11190,11255,11320,11396,11396
.word 8081,8447,9658,10002,10486,10716,10813,10959,11207,11272,11346,11422,11422
.word 8456,8796,9659,10001,10497,10742,10853,10998,11229,11301,11385,11474,11474
.word 8627,8928,9659,10042,10499,10768,10917,11037,11281,11371,11474,11578,11578
.word 8749,9024,9676,10121,10512,10795,10995,11186,11468,11668,11864,12058,12058
.word 8854,9128,9793,10224,10537,10848,11152,11475,11805,12323,12580,12710,12710
.word 9073,9334,9946,10365,10653,10986,11398,11864,12388,12983,13176,13240,13240
.word 9383,9620,10233,10738,11191,11716,12322,12721,13043,13291,13410,13501,13501
.word 9576,9821,10422,10978,11481,11999,12439,12800,13095,13305,13410,13501,13501
.word 9538,9777,10396,10953,11441,11968,12369,12749,13008,13199,13305,13370,13370
.word 9488,9736,10316,10884,11359,11860,12261,12607,12875,13047,13099,13139,13139
.word 9428,9668,10238,10789,11265,11740,12115,12435,12677,12815,12854,12842,12842
.word 9374,9593,10152,10682,11157,11606,11956,12220,12414,12517,12531,12454,12454
.word 9308,9528,10061,10572,11022,11420,11733,11936,12090,12130,12080,11951,11951
.word 9242,9464,9972,10452,10853,11215,11477,11630,11706,11679,11564,11435,11435
.word 9166,9375,9856,10312,10653,10966,11149,11240,11227,11151,11035,10906,10906
.word 9078,9298,9741,10160,10461,10684,10814,10817,10752,10659,10530,10402,10402


dyndef:         ! dynamics table (enrich/impoverish fuel on Delta MAP)
.word 7         ! 7 elements
.word 0x800      ! 16 bit data
.long dyncol      
.long dyndata      
.long 0x8000000      ! 16bit data
.float 6.1037e-5   ! 2.00/32767  (0-2.00 range, 16bit precision)
.float 0      ! + 0

dyncol:
.float -150,-60,20,0,20,60,150

dyndata:
.word 11000,14000,16300,16384,16500,18000,20000


Full GPL License:
http://freon.shackspace.com/car/ecu%20a ... ty/gpl.txt

Running ROM (Beware, this is very specialized to my car):
http://freon.shackspace.com/car/ecu%20a ... BASE22.hex

Bare bones SD ROM (near stock AJ243 stock to copy your maps in, VE map is probably way off):
http://freon.shackspace.com/car/ecu%20a ... Dv0.02.hex

SD map XML data:
http://freon.shackspace.com/car/ecu%20a ... l_data.png
Last edited by Freon on Sun Jun 15, 2008 10:56 am, edited 2 times in total.
Freon
 
Posts: 700
Joined: Thu Nov 17, 2005 5:50 pm
Location: Indianapolis, IN

Postby 06rexwagon » Tue May 20, 2008 12:10 pm

Can this be implemented in other 32 bit ecus?
06rexwagon
 
Posts: 83
Joined: Thu Mar 16, 2006 4:09 pm

Postby Freon » Sat May 24, 2008 6:06 am

Yes, I will be adding 05-07 STI, 06-07 WRX. Maybe more. We'll see.
Freon
 
Posts: 700
Joined: Thu Nov 17, 2005 5:50 pm
Location: Indianapolis, IN

Postby salex » Tue May 27, 2008 1:39 pm

Excellent work Freon! And very well documented.

I am really looking forward to using the patch!

Do you think that we could use an upgraded (non stock) MAP sensor, so as to cover a larger pressure range with SD, above the stock MAP sensor range?
salex
 
Posts: 72
Joined: Wed Jun 21, 2006 2:30 pm
Location: Greece

Postby Freon » Wed May 28, 2008 2:24 pm

No reason it would not work with another properly calibrated MAP sensor.
Freon
 
Posts: 700
Joined: Thu Nov 17, 2005 5:50 pm
Location: Indianapolis, IN

Postby KillerKam12345 » Sat Jun 14, 2008 11:19 am

great work freon. i downloaed that map to take a peak but all of the parameters look the same. even the maf scaling is still in 2d?
KillerKam12345
 
Posts: 8
Joined: Wed Aug 01, 2007 12:37 pm

Postby Freon » Sat Jun 14, 2008 4:02 pm

The map definition for SD needs to be added to your XML.

For EcuEdit, paste this in the map list for the A2Z710J:
Code: Select all
<map name="VE" type="3" active="1" help="" class="Speed Density" map_struct="" level="3">
         <rows count="18" offset="#7E798" storagetype="float" func_2val="[value]" func_val2="[value]" format="%.0f" metric="rpm" caption="RPM" desc="RPM"/>
         <cols count="12" offset="#7E768" storagetype="float" func_2val="[value]/750*14.5-14.35" func_val2="([value]+14.35)*750/14.5" format="%.2f" metric="psiG" caption="Manifold Pressure" desc="MAP"/>
         <data count="1" offset="#7E7E0" storagetype="uint16" func_2val="[value]*0.00007629" func_val2="[value]/0.00007629" format="%.3f" metric="%" caption="Volumetric Efficiency" desc="VE" inc="1" incb="5" incdata="0.001" incdatab="0.005" inc_dir="1" min="0.5" max="1.1" order="cr" color_dir="1"/>
      </map>

Screenshot of how to paste it in:
Image

For RomRaider there are two parts you need to paste into your ecu_defs.xml:

First, find the 32BITBASE and paste this in:
Code: Select all
    <table type="3D" name="Speed Density VE" category="Speed Density" storagetype="uint16" endian="big" sizex="12" sizey="18" userlevel="2">
     <scaling units="Efficiency Factor" expression="x*.00007629" to_byte="x/.00007629" format="#0.00" fineincrement=".01" coarseincrement=".04" />
     <table type="X Axis" name="MAP" storagetype="float" endian="big" logparam="E32">
      <scaling units="psiG" expression="x/750*14.5-14.35" to_byte="(x+14.35)*750/14.5" format="#0.00" fineincrement="1" coarseincrement="5" />
     </table>
     <table type="Y Axis" name="Engine Speed" storagetype="float" endian="big" logparam="P8">
      <scaling units="RPM" expression="x" to_byte="x" format="#" fineincrement="50" coarseincrement="100" />
     </table>
     <description>This is Volumetric Efficiency for Speed Density conversion path by Freon. Higher values calculate a higher airflow in grams per second which directly influences both engine load and fueling. </description>
    </table>


Here's a picture of how to paste it in:
Image

Then find the A2ZJ710J and paste this in:
Code: Select all
    <table name="Speed Density VE" storageaddress="0x7E7E0">
     <table type="X Axis" storageaddress="0x7E768" />
     <table type="Y Axis" storageaddress="0x7E798" />
  </table>

Here's a screenshot of how to paste it in:
Image
Freon
 
Posts: 700
Joined: Thu Nov 17, 2005 5:50 pm
Location: Indianapolis, IN

Postby KillerKam12345 » Thu Jun 19, 2008 9:02 am

i must be an idiot. I pasted all of those codes in and i still get the same thing. no change in the map. :evil: FREON HELP lol
KillerKam12345
 
Posts: 8
Joined: Wed Aug 01, 2007 12:37 pm

Postby acamus » Tue Jul 22, 2008 10:32 pm

Hi Freon,

Good post.

In http://forums.openecu.org/viewtopic.php ... light=4g18
My Lancer 2004.hex, you can find how Mitsu does VE calculations
There are 3 maps thou, first starting at 303d, I hope it helps you with your project. If you need def file I can provide it to you.

acamus
acamus
 
Posts: 94
Joined: Tue Apr 15, 2008 3:56 am

Postby Tgui » Thu Sep 11, 2008 7:06 pm

I'm surprised this thread doesn't have more posts. Lots of good information here.

I'll be working towards this on my 04 STi. Good stuff freon ;)
Tgui
 
Posts: 6
Joined: Thu Aug 24, 2006 10:38 am

Postby unnefer » Thu Oct 23, 2008 3:42 am

Heya Freon, I posted in your original SD post, but saw this and thought I'd post again :p

Any chance of using a patching utility (like what xrex does with his LC) so your patch can be applied to other ROMS?

Also, would this work with 16bit ECUs? I'm more then happy to send you mine to tinker with :)
unnefer
 
Posts: 6
Joined: Mon Jan 29, 2007 3:55 am

Postby Freon » Thu Oct 23, 2008 4:33 pm

I have no intention of porting it to the 16bit ECU. Sorry.

Not sure about the patcher. If there is an easy to use, free command line utility that I could distribute I could probably be talked into making the difference or patch files. As long as the patch files are easy to build.

There is actual real porting work that has to happen to make it work on any other ECU besides the A2ZJ710J. That's all I have done right now. Nothing to report on right now.
Freon
 
Posts: 700
Joined: Thu Nov 17, 2005 5:50 pm
Location: Indianapolis, IN

Re: Speed Density for DBW

Postby lester » Sat May 08, 2010 6:10 am

Hey Freon, do you have the string of codes to modify the source code for the 05-07 STi yet? Or better said is this available for the above mentioned models? I'm pretty positive those strings are intended for the 04 STi
lester
 
Posts: 5
Joined: Wed May 23, 2007 1:45 am

Re: Speed Density for DBW

Postby hta68 » Sat May 15, 2010 8:53 pm

any word on 06-07 USDM wrx's?
hta68
 
Posts: 7
Joined: Sun Apr 25, 2010 5:08 pm

Next

Return to Subaru (all models)

Who is online

Users browsing this forum: No registered users and 8 guests

cron