Free unrestricted maps for Rocket R GT and TFC now online

[nullpointer]

Throttle sensitivity, controlled by the ETV tables, is derestricted at the top end but unchanged at low throttle/rpm. Fuel is enriched in the mid range and slightly leaned out at the top end. The O2 sensor remains enabled. It’s unlikely to be lean no matter where you live. For a free tune, you’re getting a crapload more high end power.

I don’t know much about the rocket efi. But generally narrow band o2 sensors don’t work unless you are very close to stoichiometric. So the system is unable to detect when is missing the afr target. That’s what I was referring to

 

[dougl]

I don’t know much about the rocket efi. But generally narrow band o2 sensors don’t work unless you are very close to stoichiometric. So the system is unable to detect when is missing the afr target. That’s what I was referring to

Understand. The ecu goes into closed loop when the target value in the Rocket AFR table is 14.5, the rpm is low and throttle steady. You can see this area in the stock tune. In the later vin maps, US R model, Penner has lowered those targets to 14.1 and enriched the fuel a bit in this area of the table. I’m not sure if closed loop remains active. I think it does. Even if it doesn’t (same as disabling closed loop and relying solely on the fuel tables), Penner’s tuning is derived from the dyno. Unless you are concerned about emissions, Penner’s tune will work fine for you assuming your bike is stock.

 

[Idaho Red Rocket 3]

So has anybody actually figured out how we can use the Torque Limit screen with a meaningful advantage ?

 

[dougl]

So has anybody actually figured out how we can use the Torque Limit screen with a meaningful advantage ?

Funny you should ask. I saw a post, maybe on the Tuneecu Facebook site, that got heavily into this. The guy wanted to get more from his Street Triple or Daytona and went through this elaborate mathematical approach to derestricting the Torque Limits. basically increasing them well above what the motor was capable of. Simplistically, kind of scaling the whole thing up. He didn’t do it on his bike. He was concerned about how messing with it might affect other things like traction control. The ECU can’t know how much torque is actually being produced so this table must represent a relative restriction based on theory or what the engine actually put out on the bench.

 

[nullpointer]

If you don´t hit the speed limiter, it will make no difference. But at the quarter mile you might get close.

Would you mind helping me understand the Keihin system a little better?

I have some experience with tuning Delphi systems, which seem much simpler in comparison. On those, the VE (volumetric efficiency) table is basically a "truth" about the components of your engine and related components, and if correct, would cause the EFI to calculate the correct injector pulse to match the targets in the AFR table. So when tuning, you might (to put it simply) move the AFR targets out of the range of the narrow band sensors, effectively "turning off" closed-loop fueling, and then adjust the VE numbers to get the actual realised AFR to match the target. Then control the tuning primarily through the AFR table. When the AFR targets are within the range that the O2 sensors can help inform, the system "learns" adjustments to the VE table to cope with changes in fuel, temperature, altitude/pressure etc. to hopefully continue to match the AFR targets both in closed-loop and in open-loop by extrapolation.

Because of this background, I kind of view the F tables as a similar "truth" table. So I'm kind of intrigued as to what your changes to the F tables represent. Now, it seems that Keihin is a little more complicated, and perhaps the F tables also incorporate some kind of measure of torque delivery or something that I don't understand, which may be why they need changing as well. Or is it simply because the stock map F tables were a poor match for the bike you actually generated the tune for? Could you explain? To help me understand, perhaps you could explain how you think the maps you kindly produced for the community would behave differently on an "average" stock bike if you skipped the changes to the F table?

Also, can you tell me what range of AFR values you can expect the system to operate in closed-loop? How close to stochiometric do they need to be?

 

[Penner]

Would you mind helping me understand the Keihin system a little better?

I have some experience with tuning Delphi systems, which seem much simpler in comparison. On those, the VE (volumetric efficiency) table is basically a "truth" about the components of your engine and related components, and if correct, would cause the EFI to calculate the correct injector pulse to match the targets in the AFR table. So when tuning, you might (to put it simply) move the AFR targets out of the range of the narrow band sensors, effectively "turning off" closed-loop fueling, and then adjust the VE numbers to get the actual realised AFR to match the target. Then control the tuning primarily through the AFR table. When the AFR targets are within the range that the O2 sensors can help inform, the system "learns" adjustments to the VE table to cope with changes in fuel, temperature, altitude/pressure etc. to hopefully continue to match the AFR targets both in closed-loop and in open-loop by extrapolation.

Because of this background, I kind of view the F tables as a similar "truth" table. So I'm kind of intrigued as to what your changes to the F tables represent. Now, it seems that Keihin is a little more complicated, and perhaps the F tables also incorporate some kind of measure of torque delivery or something that I don't understand, which may be why they need changing as well. Or is it simply because the stock map F tables were a poor match for the bike you actually generated the tune for? Could you explain? To help me understand, perhaps you could explain how you think the maps you kindly produced for the community would behave differently on an "average" stock bike if you skipped the changes to the F table?

Also, can you tell me what range of AFR values you can expect the system to operate in closed-loop? How close to stochiometric do they need to be?

You´ve got me with your last question. I always wanted to check on that. My understanding so far is, that anything but 14.5 in the afr-tables means the ECU quits adjusting. But I have heard that it works up to 14.1.
The main difference between the Harley/Delphi and the similar Indian/Bosch to the Triumph Keihin is, that with the Keihin-ECU the afr-tables do not have a direct impact on the fueling. If you change just afr-target in the Delphi-ECU by 10% also the amount of injected fuel is instantly changed by 10%. Anything you do with the VE fueling tables comes on top.
The Keihin does not work that way. It is all about F and L-tables.

 

[dougl]

I’m pretty sure that closed loop operates somewhat away from the block of 14.5 values in the AFR table. So you could infer that if you change the values in that block from 14.5 to 14.1, fueling will depend to some extent on the O2 sensor input. If you disconnect the O2 sensors and suppress the error code in Tuneecu, the fueling in that area will be calculated from the AFR value of 14.5. Because. The values in the F and L tables are milligrams of air x 20 (I think). Divide this by the AFR and you get milligrams of fuel. Use the injector constant to convert to pulse width.

 

[nullpointer]

You´ve got me with your last question. I always wanted to check on that. My understanding so far is, that anything but 14.5 in the afr-tables means the ECU quits adjusting. But I have heard that it works up to 14.1.
The main difference between the Harley/Delphi and the similar Indian/Bosch to the Triumph Keihin is, that with the Keihin-ECU the afr-tables do not have a direct impact on the fueling. If you change just afr-target in the Delphi-ECU by 10% also the amount of injected fuel is instantly changed by 10%. Anything you do with the VE fueling tables comes on top.
The Keihin does not work that way. It is all about F and L-tables.

Thanks. I mean, it's difficult to understand why changing the AFR value wouldn't change the target AFR that the bike is trying to achieve. And I have heard reports from people changing the F/L tables and the bike gradually "unlearning" the change they've put in. But I don't know/remember if they were changing them naively or incorrectly. My main concern is that if the adaptations apply to the F/L tables, then naively changing them might just be pushing the range of learnable corrections to its extreme (perhaps intentionally?) and the bike is no longer able to adapt to conditions.

Do you have anything that describes how the various tables and their values are used by the system in calculating the fueling? Perhaps that would answer all my questions.

One more question: have you seen the stock Storm tables? My understanding is that the engine and related components are essentially the same as the vanilla Rocket 3 and so I'd be interested to see how your improved tune compares to what they put on the Storm.

Thanks again for taking the time to reply.

 

[nullpointer]

I’m pretty sure that closed loop operates somewhat away from the block of 14.5 values in the AFR table. So you could infer that if you change the values in that block from 14.5 to 14.1, fueling will depend to some extent on the O2 sensor input. If you disconnect the O2 sensors and suppress the error code in Tuneecu, the fueling in that area will be calculated from the AFR value of 14.5. Because. The values in the F and L tables are milligrams of air x 20 (I think). Divide this by the AFR and you get milligrams of fuel. Use the injector constant to convert to pulse width.

I assumed something like this. But Penner's reply suggests that the AFR values don't work exactly like that, which has got me confused. Assuming the narrowband O2 sensors are similar/the same as used on other bikes I've worked with, then your lower-range estimate of 14.1 sounds about right. I have had better/more reliable results with Delphi systems when trying to keep a good proportion of the table contents around 14.1 and above so the learned adaptations can be extrapolated by the system to also help hit open-loop targets more accurately under changeable conditions.

 

[nullpointer]

Ah. I've just found this: https://tuneecu.net/Tunes_in_Hex_and_dat/TuneECU/Adaptive_Fuel_Systems_EN.pdf

A quick flick through suggests that the F/L tables are used directly to calculate the fueling, and the AFR table is used (in closed loop) purely for calculating adaptations to the F table. So it assumes that the F table gets it right (without using the AFR table), and the latter is used just as part of the feedback mechanism? So you basically need to adjust them in tandem? Or have I misunderstood again?