Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Busa 2004-2007 Fuel calculation algorithms revealed


Guru

Status: Offline
Posts: 2338
Date:
Busa 2004-2007 Fuel calculation algorithms revealed


Having spent a couple of evenings on locating the injector size constant I thought to share some theorethical bacground (part 1) and then reflect to the how the actual ecu code is written (part 2).

When reading the following couple of messages, please note that my assembler skills are really limitied so these may contain some errors - which I am happy to fix based on any feedback received... (and sorry about the typos, it was quite late when I wrote this, so dont mind if someone edits the text into proper english)

-- Edited by PetriK at 14:57, 2008-01-04

-- Edited by PetriK at 09:28, 2008-01-06

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:
Part 1


Part 1 - background of fuel calculations


When on IAP map the injector flow is calculated in relation to the vacuum vs rpm. Vacuum is
calculated as the difference of the ambient pressure and manifold pressure rather than just absolute vacuum. The IAP Fuel maps represent the Volymetric efficiency of the engine (for each cylinder).  When on TPS map the injector flow must is calculated in relation to the TPS opening (airflow) vs rpm. Likewise the TPS fuel maps represent the volymetric
efficiency of the engine (for each cylinder).


The result of addressing either of the maps above the VE, i.e. volymetric efficiency of the
engine. When this result is divided by the injector flow capacity then we get the basic
pulsewidth for an engine cycle.

Additionally for both maps there is a need to adjust the fuel delivery according to several other inputs, like:
- external air pressure affecting the density of the air charge
- intake air temperature affecting the density of the air charge
- pressure of air into intake (gear / speed compensation) affecting the density of the air
charge
- possible oxygen sensor
- possbile "yoshbox" compensation

These correction factors effect the amount of fuel needed for VE due to e.g. air density
change so therefore the results are usually multiplied into the VE.

Despite of all the correction factors the injector opening time needs to be compensated separately. The opening time is dependent on the voltage (an also fuel pressure but that is assumed constant). This number is usually just added to the basic injector pulsewidth based on voltage.


Mathematically the above can be calculated by the following formula:
pulsewidth = comp1*comp2*comp3*(map_VE / injflow)  + opening_time*Voltage_compensation


Obviously at any given moment the pulsewidth can not be more than it takes for the engine
to make full 720 degrees that it takes for an combustion engine to start a new cycle.

In terms of simple calculations 12000rpm is max 10ms pulsewidth. Where as 10800rpm is max 11.1ms pulsewidht. Usually it takes up to 2ms for opening time so we are effectively talking about max 8ms effective pulsewidth for a busa.

When raising the rev limiter from 10800 to 12000 the pulsewidht is at high risk to reach it maximum which turns the FI light on, so therefore we need to upgrade the fuel delivery on two fronts:
1) Increase fuel amount, eg. by raising the fuel pressure (crunch the regulator by 0.9mm
mod)
2) Increase the inj_flow variable in the busa ecu to make the ecu to understand that more
fuel is delivered.

So just updating the fuel delivery either by raising the fuel pressure or by updating the injectors alone is not enough as the ecu still thinks that it reaches the limits and turns the FI light on. This is due to the fact that when reaching close to 100% the coil reverse voltage peak that the ecu recognizes as an indication of injector coils being in good shape disappears.




-- Edited by PetriK at 15:02, 2008-01-04

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:
Part 2


Part 2 - reading the ecu code for fuel calculations


The following is using Busa code from cylinder0 as the example, other cylinders are alike.

The fuel calculation really starts in around loc_126F0 where the IAP and TPS VE values are fetched from the tables based on RPM and several other parameters.
The IAPmap is read into FFFF84B6
The TPSmap is read into FFFF84BE

There is a multiplier for each cylinder that is set depending on certain engine conditions. It returns a value to address FFFF854E and is located at sub_D994.

The actual fuel calculations happen in sub_F878. That returns FFFF84A6 and FFFF849E which are used for pulsewidth. The adjusted value seems to be calculated with the following  formula:
IAP: compensation * IAPmap * (multiplier +0x80) / 0x200 / 0x80 -> FFFF849E
TPS : TPSmap * (0x80 + multiplier) * compensation / 0x200 / 0x80 -> FFF84A6


Last part of the pulsewidth calculation by the ecu is taking the IAP map and TPS map and adding those two values together as weigthed by a variable FFFF84B2 that contains which map is in use in loc_FB9C.
; (FFF84A6 * FFF84B2) + (FFFF849E * (0xFF - FFFF84B2)) -> FFFF8496


The injector opening FFFF854C is then added to the result in sub_FD2A nd finally the

require pulsewidth time is transferred into timer variable h'FFFF82B2 that is used by the timer functions to set the injector.

; FFFF854C + FFFF8496 -> FFFF82B2

and finally the full opening time is transferred into timer variable h'FFFF82B2 that is

used by the timer functions to set the injector.

So part 1 formula matches with Busa ecu with an addition to Busa using both TPS and IAP maps with weighted values.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:
Part 3 - proving the discoveries


The injector sizes are located at two different locations, first holding the injector size or should we say 1/injector size for cylinders 0,1 & 3 and second for cylinder 2.

storageaddress="0x0DA42"
storageaddress="0x0DAAA"

When modifying these values by putting dec 50 for cylinders 0,1 & 3 and keeping 128 in cylinder 2 we get the following results (measured from scope display so not exact figures)

Gear6, full throttle @10000rpm, 10ms vs 7.5ms = 2.5ms difference
Gear1, full throttle @10000rpm, appr 2.4ms difference
Gear1,closed thorttle @10000rpm, 3.1ms, 4.2ms = 1.1ms difference
Gear1, closed throttle @4000rpm, 3.5ms vs 4.5ms = 1ms difference

Here you can see the pulsewidth difference:
10ms_d128vs7.5ms_d50.JPG

And here you are with Enginuity screen for respective values:
injector_sizes.JPG
injector_sizes.JPG

... and as the last item, here is the TPS fuelmap for cylinder0 giving an indication of amount of changes because of the fuelmap... (btw. these values are divided by 48 for making the reading easier.)
busa_k6_fuelmap_cylinder0.JPG

-- Edited by PetriK at 17:01, 2008-01-04

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom

Don


Veteran Member

Status: Offline
Posts: 41
Date:
Fuel calculation algorithms revealed


Were you able to find out when the ECU switched from speed density to alpha n? Is it at a certain RPM or manifold vacuum? Or perhaps some other combination of inputs?
From a tuning standpoint, are there different maps to tune for speed density and alpha n? For instance, is there one set of fuel maps (x,y - RPM, MAP) for speed density and another set of fuel maps (x,y - RPM, TPS) for alpha n?

Great work! I wish I could be more help!

__________________


Guru

Status: Offline
Posts: 2338
Date:
Some additional info


The map switching seems to simple, just TPS threshold limited. The RPM does not affect it.

Based on the above we can just look for FFFF84B2 which contans the point to move from IAP to TPS maps like done at below. But there is more into this. The idle maps are switched differently and then there is a high load byt that selects whivc fuel enricmenit it is to be used. The high load is usually considered as over 50% throttle and over 8000rpm.

There is one key parameter affecting the switching point that sets the actual variable FFFFF84B2 for which determines which map (either IAP or TPS) to use.
ROM:000294FC TPS_IAPTPS_map_switching_limit_for_FFFF84B2_unk_294FC:.data.b h'49
This parameter is now included into the latest enginuity xml for busa for setting a different switching point.

The  FFFF84B2 changes to 0xFF at around TPS 0x49 but does it gradually,
below            -> FFFF84b2 0x00
e.g. TPS 0x46 -> FFFF84B2 0x40
e.g. TPS 0x47 -> FFFF84B2 0x80
e.g. TPS 0x49 -> FFFF84B2 0xFF
In business terms we are talking about 10% throttle opening here for  map change, i.e. 28% of TPS voltage. Anyhow if the TPS is misadjusted and can be overrun it returns the FFFF84B2 to 0x00 at 110%TPS. So lets keep the tps adjustments in place to avoid runnig wrong maps at speeds over 200mph.

Saying all the above, I have a strong indication that even with WOT (Wide Open Throttle) the Intake Air Pressure is affecting the fuel delivery also on TPS maps. When simulating sudden pressure changes on IAP sensor the injector pulsewidth shortens but only for a moment.

The subroutine that sets this is located at sub_FE54
ROM:0000FE54 Set_Map_Switching_FFFF84B2_sub_FE54:    ; CODE XREF: Calculate_Limiters_Maps_and_Timers_sub_E24C+4548p
ROM:0000FE54                                         ; DATA XREF: ROM:off_128C0o



-- Edited by PetriK at 10:38, 2008-01-05

-- Edited by PetriK at 10:54, 2008-01-05

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 7
Date:
RE: Busa 2004-2007 Fuel calculation algorithms revealed


PETRIK...

First off, let me say THANK YOU for all your hard work on this project...I've been a motorcycle tech for 12 years now and have always wanted some way to tune the factory ECU's...

Up until now all we have had was DynoJet Power Commanders (and the like) and while they work ok, there's alot of things you can't do with them, such as raise rev limits, etc. etc...

I have a degree in electronics and some limited assembly language training...so I have a general idea/understanding of your posts...however, I would like to ask you a question...

What do you need to be able to develop some sort of tuning program for an end user like myself to be able to effectively tune the stock ECU? I would be more than willing to lend any of my expertise or any other help you might need in order to bring this to a reality...

Do you have any thoughts or plans for such a thing? What would it take? What would you need?

Thank you so much for your time.

Brian

-- Edited by BrianJ at 07:01, 2008-01-18

__________________


Guru

Status: Offline
Posts: 2338
Date:

Thanks for your feedback, Brian smile.gif really appreciate it. I would like to point out that also RR should be credited as he is the one that come up with the original idea.

Then about making an end user product - easy to use, dependable, good looking, cheap enough...

We have all the components to do ecu mapping by persons who understands electronics
- programming software
- map addresses and mapping software
- programming hw interface (a switch + pushbutton + rs232-ttl converter)

What we dont have to make this an end user tool are:
- a copy of the firmware on various ecus. So far I have two and there is bound to be a handfull of more. This can be achieved by offering a service to download the ecu firmware if it does not exist yet. Fast turnaround etc...
- connectors to put some additional wires to the ecu harness connector without a requirement to do soldering
- integrated environment with mapping and map loading software. One with sourcecode available exists for cars for sh7052 processor which has integrated bootloader so that could be modified.
- packaking, documentation, delivery logistics etc, ...
- time and commercial interest to do all that

Alternatively the re-mapping can be provided as a service with a fast turnaround time - raise rpm limit, remove top speed limiter, optimize ignition for shorter stacks etc...

Not more than that - really.

And yes - There is one thing which I have not yet really looked into. The original European ecu that is equipped with a lambda sensor may be able to be remapped into accepting a WBO sensor and extending the oxy sensor correction range to the top end too. This would be an ultimate consumer add on - automatic AFR correction for a mapped ecu.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 964
Date:

BrianJ wrote:

What do you need to be able to develop some sort of tuning program for an end user like myself to be able to effectively tune the stock ECU? I would be more than willing to lend any of my expertise or any other help you might need in order to bring this to a reality...

Do you have any thoughts or plans for such a thing? What would it take? What would you need?



I think you have put your finger on the next big step, moving from the theoretical to the practical.

We have all these maps with numbers. At 6000rpm and 50% throttle some map returns a value of 142. Now from a theoretical / engineering standpoint it would be nice to figure out that 142 = x amount of injector on time or grams of fuel. But from an end user viewpoint does it really matter?

If I hand you a pipe your not going to be able to look at it and say "Oh, thats going to need .4mS of injector time at 6000rpm" Your going to put the pipe on the bike, dyno it, look at your data and decide what needs to be changed, reflash the ecu, repeat till you get it right. As a tuner when you look at the maps and you decide to add 10% here and 5% there. Do you care if its 5% of 142 or 2.3mS? I don't think so. What we have now is a lot of trial and error and I don't think quantifying the map values is going to change that.

What we need, what I think BrianJ is asking for is realtime map adjustment that everyone is already using with other systems. What we need is a setup where you put the bike on the dyno, and then be able to turn a knob to 'dial' it in at different loads, rpms, etc automatically recording the offsets as you work. Then you turn the bike off, use software to mod the maps using the dial settings you collected and reflash the map.

Now what would it take to do this?  Well hardware wise I think we are in luck. All the denso ECUs have a factory fuel trim (Yoshbox) interface that consists of three analog and two digital inputs that are even available from a wire harness connecter under the seat. So we have somewhere to connect the 'dials'  The rest is just software.

We insert patches into the ECU operating code so that the fuel trim analog inputs are used to add offsets to the standard map values returned. So if the dial is set to 5 and the the normal GetMapValue subroutine returns 142 our modified software returns 147 (142+5)and the ECU uses that value instead. While the bike is running you turn the dial up or down until the normal map value plus our dial value gives you the performance / AFR you want.

The second dial selects which maps your adding offsets to: Timing, VE, Alpha-n etc.

Now the tricky part. So far I've described a tool that can tell us what map value we want to have but it doesn't actually change the maps. We need to turn the bike off, add are dial settings to the existing map values and then reflash the ECU with the new adjusted map values. For this to work we need some method of recording all the various dial settings for each map data point so we can build an offset map to add to the existing map after the run.

One place would be ECU RAM but there is a limited amount of that available. A standard ignition map that is 32x20 takes up 640 bytes of memory. The 16 bit ECUs only have 4096. MAYBE you could scrounge up 1500 bytes That would only be enough for two maybe three maps. In a perfect world it would be nice to be able to dial in multiple maps in the same run but there may only be enough ram in the ECU to do one at a time. So it would be dial in the timing, stop the bike, flash it, dial in the fuel, stop the bike, flash it.  It would still be better than just shot in the dark trail and error were left with now.

The other option would be to dump it to a laptop through the serial port so that when you get it perfectly dialed for that rpm/throttle you push a button and the ecu outputs

map3 x=9 y=17 dial=4

The laptop software would know the map3 was 32x20 and show a table with all the new values you had recorded and which ones you still had to do.

Anyway there are still a lot of details to be worked out but that is the direction I'm leaning






__________________


Member

Status: Offline
Posts: 7
Date:

WOW...um, yeah, that would all be nice, but honestly...I'd settle for just a simple way to MANUALLY change the map...

For example...DYNOJET has a program for their dyno's called "tuning-link" which basically does what you mentioned...it loads the bike, reads the A/F and adjusts the map to meet your specified AFR...it takes about 20 minutes to completely re-map a bike for all load conditions...

Now, while that type of functionality would be nice...it isn't necessarily needed...for one, not everyone has a dynojet dyno...so there are alot of people out there who write maps the "old-fashioned" way...they datalog, read the data, and adjust the map where it needs it to achieve the proper result...I would be happy with this functionality alone...

I understand you guys can already do this...but I can't...I don't know where all these things are stored. Now I agree that it's not necessary to know exactly what the "142" stands for, however, I do need to what values to change as well as an understanding of their format...(hex, decimal, etc.etc.)

I would be happy with this...a graph that shows TPS vs. RPM that I can input changes into and it will write to the proper parts of the code to change what needs to be changed. Also, a simple "rev-limit" box where one could enter a rev limit and have it write the proper values to the proper places in the code...

Hell, I personally would even be happy with a step by step "how-to" to go in and do this manually...I wouldn't care if I had to go into the code and change items manually, the problem is that I don't know where to go and what to change in order to get done what I need to get done...

For example, let's say I datalog a run and I'm shooting for 13.2:1 AFR across the board, but looking at the log I see that I start to go rich at 100% throttle and 8,000 RPM's and it keeps going rich till it hits 10:1 at 11,000 which happens to be redline... NOW, I can see what's wrong but how do I fix it? With the DynoJet Power Commander software, I would go to the 100% throttle column and start pulling fuel at 8,000 and on up to 11,000 till I got it where I wanted it...but with this raw code how do I know where to go and what to change? And say I want to change the rev limit...how would I do that? And would other changes need to be made to do so, such as extending the current maps which only allow for fueling instructions to the current rev-limit?

Any further insight on this would be greatly appreciated...thank you all for your hard work!

Brian



__________________


Member

Status: Offline
Posts: 7
Date:

PetriK wrote:

Then about making an end user product - easy to use, dependable, good looking, cheap enough...

We have all the components to do ecu mapping by persons who understands electronics
- programming software
- map addresses and mapping software
- programming hw interface (a switch + pushbutton + rs232-ttl converter)




Are you saying that this is all that's needed to re-write the map manually? What is this "Mapping Software" that you speak of? Will it allow me to see something like the DynoJet software, where you can go to a particular cell that corresponds to a given RPM/TPS point and make changes? Will it then put the new value into the code for you at all the places it needs to be? Will it do the same for removing/changing the speed limiter and the Rev-Limiter?

If so, what would it cost for someone like yourself to do a step-by-step tutorial on how to do everything from start to finish...get the code from the ECU, modify it, and re-flash it...all the programs needed with instructions for each, etc.etc.?  This would provide those like myself with an alternative way of tuning, outside of purchasing extra piggy-back ECU's...also, it would allow for things otherwise not possible with aftermarket units, such as raising rev-limits, etc.etc.

Please let me know...thanks!

Brian




__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes, it is just like using dynojet software. You see from dyno or from LM1 what is not right, change a cell using your computer and then download the changed map to the ECU... with one exeption, there is hundreds of maps and parameters you can change.

As the map editing software we use enginuity. Enginuity can be downloaded for free from here:
http://sourceforge.net/projects/enginuity/

The enginuity map definitions, ie map locations file can be downloaded from here.
http://www.bikeland.info/petrik/Busa/BUSAK5.xml     

The actual firmware for US K6 busa can be downloaded from here
http://www.bikeland.info/petrik/Busa/BUSAK6USA.bin 

That should get you going to see what the maps look like with enginuity. Just make the BUSAK5.xml as your active definitions file and then open the BUSAK6USA.bin in enginuity.

In addition to enginiuity and maps you need a separate interface to connect your ecu to your pc. The instructions for building the hardware interface you can find from here:
http://www.activeboard.com/forum.spark?forumID=99460&p=3&topicID=14784871

In addition to hardware interface you also need a software too to transfer your maps to the ecu. That software is called FDT which you can download for free from the ecu processor manufacturer:
http://www.renesas.com/fdt

The instructions how to install and setup FDT you can find here:
http://www.activeboard.com/forum.spark?forumID=99460&p=3&topicID=14963290

The instructions how to use FDT to reflash your ecu you can find here:
http://www.activeboard.com/forum.spark?forumID=99460&p=3&topicID=14963483

So all the elements are there.

What we will need to do is really to document better the enginuity MAPs... maybe by:
1) Start creating user level definitions for enginuity definiton file. There is maybe 20-30 maps that most of us are interested in, the rest is very confusing. In enginuity we can set user level 1 for most of the users to see only the "necessary maps" making the user experience much more easier.
2) Then we need to generate more detailed information about the most important maps. We really should describe the purposes of the each individual map and how does it link to the air/fuel path etc.  An example is e.g. the following formula where each of the map is contributing towards the basic injector pulsewidth under certain conditions. So basically it explains what happens when you change Fuel_map or injflow_parameter - but maybe it would be better to say that unless you change sensors you really need to change only the fuelmap(s) for mapping your bike for a pipe. When you change you injectors instead of changing the fuel_map its ok to change only the injflow_parameter. For those guys who are running quartermile the tps_opening_change_map may provide tools to optimize the throttle opening during the launch with engines that have airbox modified.

(air_temp_map+0x180) * water_temp_map* ambient_pressure_map * TPS_pulsewidth_map * RPM_pulsewidth_map * TPS_opening_change_map  * (Fuel_map * injflow_parameter)  + (opening_time_map*Voltage_compensation_map)

My intention has been to start providing this additional and more specific information about maps and detailed instructions on flashing when there are more persons with the hardware interface ready. I know that at least 2-3 persons are building the hardware interface so as soon as they are ready for thesting I will write step by step instructions for Busa 2004-2007 environment.

ps. Additionally for future there is an open source software called ecuflash that combines the enginuity map editor with fdt capabilities. Programming using that would be just pushbutton excersises - and some day i bet someone will move this competence to that. Ecuflash has been used "daily" with cars to do the sames we are doing with bikes with one difference - the average user just buys the hw interface and downloads the maps without much technical knowledge.



-- Edited by PetriK at 15:59, 2008-01-13

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 7
Date:

OK...this is what I was looking for! I'll get all this stuff downloaded and ready to go...

Also, can we use the ECUFlash in place of the other two, or not yet? I wasn't quite clear on that...

It would be nice to know what maps to change for basic things...say a guy puts on a pipe and hi-flow filter...which map would you adjust? What if they added cams or a piston kit? Which maps???

Also, is it possible to just change the rev limit and nothing else...? This alone would be VERY helpful on bikes that are already setup...

Thanks again for all this information....and I look forward to your step by step write-up!

Brian

__________________


Guru

Status: Offline
Posts: 2338
Date:

Some more notes on the topic while testing on this topic...

The map switching between IAP and TPS maps is around 1.4v, gradually from 1.35 to 1.45volts.

Above that its always TPS map, below that is always IAP map. In between using the earlier mentioned formula weigthing the maps.

TPS measures the following:

Fully closed throttle, i.e. -C00 adjusted TPS = 1.13V
MAP switching point 1,4V
Fully opened Throttle = 4,31V (info based on LM1 logs from last summer)

TPS FI error limit = 4,73V, above this FI light will turn on and code C14 appear
Vcc, i.e. ECU harness pin 48 = 5.02V

-C00 = 22% of TPS variable value
Map switching point = 25% of TPS variable value
TPS FI error limit = around 94% of TPS variable value





__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

In a process of finding what the actual contents of the ECU Datalog paramater no 13 actually holds, lets write here the findings:

Parameter 13 holds high bit value for fuel calculated for cylinder 0, RAM variable FFFF848E. Based on looking a subroutine its equal to 82B2 which is used by the timer function to calculate the fuel delivery.

It is calculated as a sum of Direct add (i.e. opening delay compensation) and Compensation add based on various maps from the engine. It holds the final calculated fuel to be delivered to the engine including all possible compensations.

FFFF854C + FFFF8496 -> FFFF848E

So to have the actual injector open time / duty cycle we need to deduct the opening time compensation. The opening time is defined as taking the measured running voltage of injectors and then put that through a compensation map to result the injector opening time compensation.

The data stream does provide the injector opening time as part of the stream, but unfortunately the datastream can only send a limited amount of parameters. Therefore for analysing the data on line we need to cut some  corners. The closest value I could get is around 1024 to be subtracted from the Parameter 13 to deliver the fuel map values after compensation.

This means that the FUEL delivered that get a very close match to both TPS and IAP maps is calculated with the following formula.

((Parameter13*256) -1024)*2.56/100


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom

Page 1 of 1  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard