(Old thread just learning) Im thinking chalkboard in a lab
I'd start with the tune ecu how to. Tune boy is just not the same now. If you have some of the early versions say 3.9.9 for 09 and down or the V4.o series was the early roadsters yet still hackable. After that there advance stuff is a whole new ballfield. Most use tune ecu at least you can get some midification by Alain. Like the ones the shut down the secondary throttle commands. Its just a subroutine anyway seperat from the main program.
 
I'd start with the tune ecu how to. Tune boy is just not the same now. If you have some of the early versions say 3.9.9 for 09 and down or the V4.o series was the early roadsters yet still hackable. After that there advance stuff is a whole new ballfield. Most use tune ecu at least you can get some midification by Alain. Like the ones the shut down the secondary throttle commands. Its just a subroutine anyway seperat from the main program.
Studying is over, for tonight, information has been gleened and tomorrow it will be put into use, helping tuner navigate data collected from his wego data collection ptogram into the ecu using my android tablet on tuneecu
 
I suggest that a good place to start in understanding the Triumph ECU and control programs would be to read the Adaptive Fuel Systems overview. It uses correct terminology and explains the system as it pertains to Triumphs. After that there are volumes, literally hundreds of books, written on the subject. Check one or more out from your local library.

The values in the F (fuel) and L (load) tables are NOT of air NOR milligrams of fuel; they are fuel injector "on" time in milliseconds per cylinder event.

The chart/table colors are a visual cue to high light the noted tabular data. One quick look and you can see trends. They are meaningless otherwise. For most riders, the F and L tables, and L to F switch over values are most important. These are "base" values only. The ECU uses these values and then modifies them according to sensor inputs such as barometric pressure, air temperature, coolant temperature, gear position, O2 and so on. None of those algorithms are available for modification in TuneECU (thank God.)
Gentlemen, I don't want to get in a pissing match. My statement was based on the data from "Adaptive Fuel Systems Overview" PDF found at TuneECU.org. It was written by Triumph. Tuneboy and Tune ECU may have changed the numbers to be arbitrary (but likely related to hexadecimal code, 8 bit registers and register shifts) but they represent fuel injector "on" time.

Fuel "on" time can be used with only throttle position and rpm inputs. No MAP or MAF sensor is needed. If you use larger injectors, or higher pump pressures, the numbers in those tables are reduced for the same engine power levels. See Claviger's Carp265 map with larger injectors tune for an example. If the values are indicating air weight, and you put more fuel in the cylinder due to a higher fuel delivery rate, the values in the tables would need to be adjusted larger to achieve the same AF ratio. (My statement here is incorrect. With a fixed ratio between air and fuel, reducing air number would reduce fuel flow.)

The AF ratio table is used only for closed loop control. The O2 sensor reading informs the ECU that the exhaust oxygen content doesn't match the AF table using the calculated fuel delivery base value: adjust fuel injector "on" time accordingly.

There's no danger of a pissing match here, for me at least I just want to know what unit (if any) those F and L tables' cells' values are in, wherever that leads or whoever is right. I understand it doesn't really matter what unit they are in, or if they are arbitrary unitless values, ultimately increasing them increases fuel, decreasing them decreases fuel, but I'm too curious to not want to know.
Right now, I only have the document that came with the TuneBoy kit to go on, that says milligrams of air. And some guy on the internet says milliseconds of injector on time :)

Thinking about that to see if it makes more sense that milligrams of air (which doesn't add up either imo), I had a look at TuneECU readings with the engine running.

Idle around 1000rpm running around 570hPa MAP and the injector pulse is (in milliseconds, if you hovver cursor over it) around 3.137ms or so

1591645105338.png

Screenshot_20200608-201449_Video Player.jpg


At the same time, going over to the L tables to view the live cell / cell the ECU is referencing for the idle speed and MAP value, I'm seeing 1970 to 2242, which doesn't look anything like the concurrent injector pulse time of 3.137ms.
Screenshot_20200608-204102_Video Player.jpg


Having read the adaptive fuel systems text, the reference to the numbers being in milliseconds of injector 'on' time was in relation to a "typical" map, not a Keihin/Triumph or TuneECU map, but they are all similar in appearance to my injector 'on' time as above (3.137ms), so it makes sense that this example below is indeed injector ms, but they are far from similar in appearance to the TuneECU map as above.
The TuneECU F & L table values couldn't be injector ms.

1591648273621.png





Just realised that I had written this post and never posted it. It was saved in the editing box by the site.

Anyhooo we finally have a definitive answer from The Boss of TuneECU (Meeou aka Alain):
My original post is updated with this new info.


Screenshot_20200609-192436_Chrome.jpg



^^ so there it is, mg of air....... x20.

Now to risk death by exile by asking Alain if the injector pulse is milliseconds (ms, like the screenshot of TuneECU) or microseconds (μs , as Alain posted on the forum) 😄 😄

@Journeyman28778 @Speedy
 
Last edited:
Gentlemen, I stand corrected. Thanks R-III-R Turbo for finding the correct answer. I apologize to all for the head scratching induced by my error.

Please note that the ECU transitions from L table to F table and back, interpolates between cells, and has an enrichment function for acceleration, that we cannot adjust with Tune ECU.
 
new guy, but have some knowledge so hopefully i can help here....

background: i've been an embedded systems firmware engineer for over 25 years, mostly ARM/MIPS/x86 architectures. i understand a lot of how hardware works at the lowest levels. i also love motorcycles and engine building/modifying/tuning. so much so that when i had an opportunity to get my hands on a dyno last year i went for it. right now it's a side business because it doesn't pay as much (quite yet...).

anyways, i know a lot of the local bike shop owners and one in particular (he may even be on this site and reading it later), is helping out a customer of his with tuning a Rocket III that he installed a supercharger onto. he's tuning it with TuneECU and i offered to help out a bit. i was reading this thread to get an idea of what the different tables are in TuneECU for this bike and thought i might be able to try and explain some things (as i know them), and hopefully either be told i'm right, or that i'm wrong and be better off for learning something from more knowledgeable folks that are already involved in TuneECU.....

there's been some back and forth in this thread about 'why tune here, what does this change do, why this when that? etc....' (sorry if this is repeated elsewhere, i just figured this thread was still somewhat active and wanted to put in what i know)

almost all modern engine management systems work similarly, with certain aspects specific to the type of algorithms they are implementing.... they all however, aim to calculate the correct pulse width of the fuel injectors to supply the amount of fuel to reach the desired AFR/Lambda that's been programmed. Alpha-N systems look at TPS and RPM to do most of the figuring. Speed Density systems look at MAP and RPM, MAF systems look at air mass and RPM.

they *all* need to have an idea of how much air is going into the engine at any given time, engines are just air pumps and the ecu is controlling how much fuel to add to get the right mixture that it's been told to try and hit.

in a speed density system like what is on the Rocket III, (some people may argue it's Alpha-N because it uses TPSvRPM fuel map, but you can call it a hybrid system if it makes you feel better, it does use MAP to figure the L map, and internally probably uses MAP during the F calculation as well, we just don't have it available to us), the tables that describe mostly how much air is going in are the F tables which would be (at least what most people would call) Volumetric Efficiency tables. Basically, 'How much air volume gets into the cylinder at what TPSvRPM?' a VE normalized to 1 (100% full), would be the exact displacement of the individual cylinder/combustion chamber at BDC. at low throttle openings, the engine isn't very efficient and the VE is much below 100%. at higher RPMs and throttle openings, the engine is much more efficient and can often reach over 100% VE. this is very much influenced by the engine design and the camshaft profile, intake opening/closing points, exhaust overlap, etc. at higher RPMs and WOT, VE often falls off again because the engine can't fill the cylinders 100% in the short amount of time that the intake valves are open.
so, if the ECU knows the airflow modeling of the system, then the displacement times the VE times the density of the air as measured by the MAP sensor and the Inlet Air Temperature will tell the ECU how much oxygen is in the cylinder right now. the ECU will then look up the desired AFR for the current TPS/RPM, then based on the known flow rate or injector size (which is coded in the ECU someplace, and it may also monitor fuel pressure or battery voltage to know whether the injectors will be opening at the spec the code was designed for.... low battery voltage can mean low fuel pressure for example) it knows how long to keep the injectors open. at lower AFRs it holds them open longer. with larger injectors or higher fuel pressure it holds them open less, etc.
closed loop operation with narrowband O2 sensors only works in a small range of Lambda/AFR, typically 14.5-14.7 or so, anything outside of that range and the feedback is meaningless because the sensor can't accurately measure outside of that range. So, if your AFR table isn't 14.5 (what appears to be the 'closed loop' switch for this ECU), then the system only uses the parameters i spoke of above to calculate the fueling. in closed loop, it does the same calculation, but there's an additional 'offset' added or subtracted to the fuel timing based on the O2 sensor's feedback. this is most often used to fill out long-term and short-term fuel trim tables. the O2 sensor is giving the ECU a 'trend' to update these tables and they are used in the calculation of the fuel timing. what narrowband O2 sensors won't do (which is often the misconception) is adjust your tune for changes in airflow, displacement, camshafts, etc. if it's not *too* far off it can adjust somewhat, but it's not the intention. it's mostly there for fuel economy and to adjust to slight differences in fuel quality/blends over the course of the riding season/conditions, etc.
for the R3 and TuneECU, you have the 3 F maps which are TPS/RPM VE tables. higher numbers mean higher VE and therefore more fuel will result. the L maps are VE tables, just based on MAP feedback rather than TPS. if you set the F-L switch to 0, you're essentially turning it into an Alpha-N system (presuming the MAP reading doesn't contribute too terribly much to the F map-based calculations. if you set the F-L switch to 100 (if you were able to) you would essentially disable the F map and it would be a pure speed density system using MAP vs RPM VEs that are in the L table.

to tune the VE tables properly (at least, using the typical UEGO tools available), you need to be able to correlate the AFR readings with the engine data. Narrowbands are not the best choice for this, as the range they are effective in is small as stated above..... sometimes this can be fudges somewhat by changing the voltage bias offset to the narrowbands.... while they will still think that they are reading the 14.5-14.7 range, the bias is making them actually sense a higher or lower AFR range. however, this accuracy gets worse the farther away from the normal operating (0 bias) they are designed for. if this capability isn't present in the ECU or tuner software it doesn't matter. tuning with narrowbands basically means setting the entire AFR table to the closed loop region and recording the engine data and applying the offsets calculated to the VE tables. if you are too far away from an accurate VE table, the sensors won't be able to read the AFR accurately and your data is garbage. what typically is done when you have the tools (a dyno is nice for this!), is to use WBO2s to read a range of AFRs that can be as low as 10 to as high as 18 or so. the problem with WBO2s is that their response time is *much* slower than narrowbands. you need to collect a lot more data in steady state conditions with widebands to get a good quality of data. for road testing, setting the AFR table to a fixed, safe value across the board (say 13.x) is often done, to remove the need for the ECU to do a rolling calculation of the AFR as the engine moves to different cells in the VE table while riding (it's hard to keep steady-state operations during road testing). the ECU will typically apply an algorithm to determine the VEs at each point between the cells in the VE tables, it's not simply a 'step-function'. if the cell at 10TPS for a given RPM is 5000, and the 15TPS is 6000, the ECU is will use the surrounding values to figure out what the VE is for 12.5% TPS for example..... having smooth transitions between the values in the VE table is beneficial to the ECU because it minimizes the errors in the perfect calculation (which will never be perfect in the dynamic system). smooth transitions are achieved by having good accurate data.

there's tons of other things that go into the ECU's calculations as well, IVO/IVC, EGR (from cam overlap), the 'imperfectness' of injector flow at low and high duty cycles, the possible nonlinearity of the MAP sensor(s) at different RPMs, etc. One thing i find interesting in this ECU is that they didn't use MAP for timing instead of TPS. Does the Rocket 3 only have 1 MAP sensor or are there 3 indivdual sensors per intake?

timing is a whole other thing that i can give input on as well in a separate post if someone's interested in my thoughts on it.
 
new guy, but have some knowledge so hopefully i can help here....

background: i've been an embedded systems firmware engineer for over 25 years, mostly ARM/MIPS/x86 architectures. i understand a lot of how hardware works at the lowest levels. i also love motorcycles and engine building/modifying/tuning. so much so that when i had an opportunity to get my hands on a dyno last year i went for it. right now it's a side business because it doesn't pay as much (quite yet...).

anyways, i know a lot of the local bike shop owners and one in particular (he may even be on this site and reading it later), is helping out a customer of his with tuning a Rocket III that he installed a supercharger onto. he's tuning it with TuneECU and i offered to help out a bit. i was reading this thread to get an idea of what the different tables are in TuneECU for this bike and thought i might be able to try and explain some things (as i know them), and hopefully either be told i'm right, or that i'm wrong and be better off for learning something from more knowledgeable folks that are already involved in TuneECU.....

there's been some back and forth in this thread about 'why tune here, what does this change do, why this when that? etc....' (sorry if this is repeated elsewhere, i just figured this thread was still somewhat active and wanted to put in what i know)

almost all modern engine management systems work similarly, with certain aspects specific to the type of algorithms they are implementing.... they all however, aim to calculate the correct pulse width of the fuel injectors to supply the amount of fuel to reach the desired AFR/Lambda that's been programmed. Alpha-N systems look at TPS and RPM to do most of the figuring. Speed Density systems look at MAP and RPM, MAF systems look at air mass and RPM.

they *all* need to have an idea of how much air is going into the engine at any given time, engines are just air pumps and the ecu is controlling how much fuel to add to get the right mixture that it's been told to try and hit.

in a speed density system like what is on the Rocket III, (some people may argue it's Alpha-N because it uses TPSvRPM fuel map, but you can call it a hybrid system if it makes you feel better, it does use MAP to figure the L map, and internally probably uses MAP during the F calculation as well, we just don't have it available to us), the tables that describe mostly how much air is going in are the F tables which would be (at least what most people would call) Volumetric Efficiency tables. Basically, 'How much air volume gets into the cylinder at what TPSvRPM?' a VE normalized to 1 (100% full), would be the exact displacement of the individual cylinder/combustion chamber at BDC. at low throttle openings, the engine isn't very efficient and the VE is much below 100%. at higher RPMs and throttle openings, the engine is much more efficient and can often reach over 100% VE. this is very much influenced by the engine design and the camshaft profile, intake opening/closing points, exhaust overlap, etc. at higher RPMs and WOT, VE often falls off again because the engine can't fill the cylinders 100% in the short amount of time that the intake valves are open.
so, if the ECU knows the airflow modeling of the system, then the displacement times the VE times the density of the air as measured by the MAP sensor and the Inlet Air Temperature will tell the ECU how much oxygen is in the cylinder right now. the ECU will then look up the desired AFR for the current TPS/RPM, then based on the known flow rate or injector size (which is coded in the ECU someplace, and it may also monitor fuel pressure or battery voltage to know whether the injectors will be opening at the spec the code was designed for.... low battery voltage can mean low fuel pressure for example) it knows how long to keep the injectors open. at lower AFRs it holds them open longer. with larger injectors or higher fuel pressure it holds them open less, etc.
closed loop operation with narrowband O2 sensors only works in a small range of Lambda/AFR, typically 14.5-14.7 or so, anything outside of that range and the feedback is meaningless because the sensor can't accurately measure outside of that range. So, if your AFR table isn't 14.5 (what appears to be the 'closed loop' switch for this ECU), then the system only uses the parameters i spoke of above to calculate the fueling. in closed loop, it does the same calculation, but there's an additional 'offset' added or subtracted to the fuel timing based on the O2 sensor's feedback. this is most often used to fill out long-term and short-term fuel trim tables. the O2 sensor is giving the ECU a 'trend' to update these tables and they are used in the calculation of the fuel timing. what narrowband O2 sensors won't do (which is often the misconception) is adjust your tune for changes in airflow, displacement, camshafts, etc. if it's not *too* far off it can adjust somewhat, but it's not the intention. it's mostly there for fuel economy and to adjust to slight differences in fuel quality/blends over the course of the riding season/conditions, etc.
for the R3 and TuneECU, you have the 3 F maps which are TPS/RPM VE tables. higher numbers mean higher VE and therefore more fuel will result. the L maps are VE tables, just based on MAP feedback rather than TPS. if you set the F-L switch to 0, you're essentially turning it into an Alpha-N system (presuming the MAP reading doesn't contribute too terribly much to the F map-based calculations. if you set the F-L switch to 100 (if you were able to) you would essentially disable the F map and it would be a pure speed density system using MAP vs RPM VEs that are in the L table.

to tune the VE tables properly (at least, using the typical UEGO tools available), you need to be able to correlate the AFR readings with the engine data. Narrowbands are not the best choice for this, as the range they are effective in is small as stated above..... sometimes this can be fudges somewhat by changing the voltage bias offset to the narrowbands.... while they will still think that they are reading the 14.5-14.7 range, the bias is making them actually sense a higher or lower AFR range. however, this accuracy gets worse the farther away from the normal operating (0 bias) they are designed for. if this capability isn't present in the ECU or tuner software it doesn't matter. tuning with narrowbands basically means setting the entire AFR table to the closed loop region and recording the engine data and applying the offsets calculated to the VE tables. if you are too far away from an accurate VE table, the sensors won't be able to read the AFR accurately and your data is garbage. what typically is done when you have the tools (a dyno is nice for this!), is to use WBO2s to read a range of AFRs that can be as low as 10 to as high as 18 or so. the problem with WBO2s is that their response time is *much* slower than narrowbands. you need to collect a lot more data in steady state conditions with widebands to get a good quality of data. for road testing, setting the AFR table to a fixed, safe value across the board (say 13.x) is often done, to remove the need for the ECU to do a rolling calculation of the AFR as the engine moves to different cells in the VE table while riding (it's hard to keep steady-state operations during road testing). the ECU will typically apply an algorithm to determine the VEs at each point between the cells in the VE tables, it's not simply a 'step-function'. if the cell at 10TPS for a given RPM is 5000, and the 15TPS is 6000, the ECU is will use the surrounding values to figure out what the VE is for 12.5% TPS for example..... having smooth transitions between the values in the VE table is beneficial to the ECU because it minimizes the errors in the perfect calculation (which will never be perfect in the dynamic system). smooth transitions are achieved by having good accurate data.

there's tons of other things that go into the ECU's calculations as well, IVO/IVC, EGR (from cam overlap), the 'imperfectness' of injector flow at low and high duty cycles, the possible nonlinearity of the MAP sensor(s) at different RPMs, etc. One thing i find interesting in this ECU is that they didn't use MAP for timing instead of TPS. Does the Rocket 3 only have 1 MAP sensor or are there 3 indivdual sensors per intake?

timing is a whole other thing that i can give input on as well in a separate post if someone's interested in my thoughts on it.
Oh man - Are you going to get some questions! - when I sober up a bit!. - OK a lot!.
Welcome - from another techie dinosaur. And one who loves L tables. o_O - I'm odd, I can't help it.
 
Oh man - Are you going to get some questions! - when I sober up a bit!. - OK a lot!.
Welcome - from another techie dinosaur. And one who loves L tables. o_O - I'm odd, I can't help it.

Man I can remember struggling with getting the correct jets after modifying My bikes! This is a whole new struggle! My head hurts just trying to take all that great information you just supplied! 😨
 
Man some good reading there. I have to read it again a few times! Makes me wish I didn't have to go buy a 6 pack of hand grenades just to push the lawn mower :)
 
Back
Top