Converting fuel units (pulse width, duty cycle, raw fuel)

[Dr.Race]

I have noticed in AEMTuner that you cannot convert the fuel cell numbers from pulse width, to duty cycle and raw fuel.
That was a wonderful feature in AEMPro!

[SAG]

Dr.Race -

That is indeed a bug that has already been fixed and will be in the next release. A note on the fix is that the fuel map will only be viewable in Pulse Width or Duty Cycle, Raw units have been removed. In addition the "Crank Injector Time Table" is viewed in Pulse Width instead of Raw Values. Thanks -

Samy

[Blacksaleen95]

so we can't view raw at all??? Is this just for the next release, or does that apply to the final release of aemtuner as well?   That kinda defeats the purpose of microsecbit if we now have no way of knowing if the values are close to 255!!!  Is there a workaround for this?

[SAG]

BlackSaleen -

In AEMTuner the Fuel Map (and Crank Injector Timing Table) is automatically rescaled when the maximum value in the table goes above, or below, a threshold. This rescaling is done by changing the value of microsec/bit and then doing a percentage change on the values in the fuel map that is the inverse of that change to microse/bit. We feel that since raw values in and of themselves have no meaning, it simplifies things greatly (and reduces confusion for many people) if the user simply deals with Pulse Width and Duty Cycle, which are what really matter anways. The software will ensure that you always have pulse width to deal with, while giving you an optimal resolution.

Samy

[Blacksaleen95]

ahhh I see... That's pretty awesome that it'll automatically rescale everything for you!!! I like that a lot.   You guys are doing some good work over there!

[Mello]

I am not in favor of having scaling as an automatic feature.  I have had startup problems with large injector and small microbit/sec settings.  The small microbit/sec setting had nice resolution for the main fuel map tuning but I would run out of range in the crank fuel map, could not get enough fuel for good startup even when max at 255 raw value in crank fuel.  I was necessary for me to increase my microbit/sec for adequate crank fuel pulse width.

I feel that a pop up asking if I wanted to have AEMTuner do an auto scale would be nice.  I would then be able to accept or decline the scaling.  Or maybe even being asked by how much I would like to rescale.

I prefer to see the raw value stay as a choice in viewing the fuel map.  It's this value which let me obtain the best resolution for tuning and see it.  Everything is relative any.  There are to many decimal places needed to be displayed for pulse width or duty cycle.  After all, an increment of "1" in raw fuel is much easier to see than incrementing 10.1% to 10.1% (or is this actually 10.09% to 10.12%).  Graph and table can be smaller and you can still see what you are doing.

Sorry-Just my preference and opinion.

[SAG]

Mello -

I will note your preference. Here are some counterpoints to the issues you've mentioned:

The autoscale can be triggered by both the Fuel Map and the Crank Injector Time table, so the issue you've mentioned where you could not get enough fuel for good startup would not occur, because you would enter the values you need, and AEMTuner would make sure that you had enough room left in the "Raw" values, while still providing a minimum acceptable resolution over the graph for both the Fuel Map and Crank Injector Time Table.

AEMTuner does tell you when it does a rescale (though you can't cancel it), and if your engine is running will not let you make a change that forces an auto-rescale, because this could put your fuel map in a temporarily unstable state while the values are being changed.

I understand your hesitancy in allowing AEMTuner to handle all rescales, but if you view the fuel map as a means to set pulse width, AEMTuner will always allow you to enter your desired pulse width (or duty cycle), while keeping an acceptable resolution. We believe that keeping raw, and thus microsec/bit, exposed simply adds to the complexity of the system (which is a major criticism or our system we are addressing with AEMTuner) with minimal advantages. The only advantage we can see is that you could perhaps optimize the resolution of the map by a minimal percentage doing it manually, and to address this we could even add an "optimize" feature that could be applied after your map has been finallized. I see your point about it being easier to see an increment on the table if its in raw, but you can increase the significant digits on the table so you can see that a change has been made.

I hope this gives you more confidence in our approach, and if not we will still note your opinion and wait to see if other users feel the same way. Thank you -

Samy

[Mello]

Well gee.  I would like microbit/sec and LD0MPC to remain exposed so I can set it to my needs too.  Oh no?

Maybe you could add a super tuner mode: "Tuning Geeks - Tuner beware, use at your own risk!"

[SAG]

Mello -

I'll talk with the guys here about that, but no promises. The problem with adding a"Super Tuner" mode, is that everyone thinks they are super tuners, or at least need to understand what that mode does, and then we get a slew of technical support calls about that mode, when in reality most people don't really want the functionality of that "Super Tuner" mode. I understand that is not what you want to hear as someone who utlitizes all the capabilities that the EMS can expose, but as a business we need to balance the costs/benifits for each piece of functionality that we add, and at this moment we've come to the conclusion that this would cause more problems than it would solve. We will reconsider however. Thanks for the feedback -

Samy

[WadZii]

im with mello on this one... i like to keep things at aleast somewhat complicated b/c if it looks that simple then a bunch of retarded customers that have no fn clue or business messing with their ems will start and cause me more headaches than i already have.  the ems has about the easiest to use software there is.  just having the options there dont make it more complicated, especially if the user isnt required to use them.  the auto-rescale is nice, but i dont want to give up the control i have in AEM PRO

[underpsi6]

im with mello on this one...  the ems has about the easiest to use software there is.  just having the options there dont make it more complicated, especially if the user isnt required to use them.  the auto-rescale is nice, but i dont want to give up the control i have in AEM PRO

X3

[Alpha]

im with mello on this one... i like to keep things at aleast somewhat complicated b/c if it looks that simple then a bunch of retarded customers that have no fn clue or business messing with their ems will start and cause me more headaches than i already have.  the ems has about the easiest to use software there is.  just having the options there dont make it more complicated, especially if the user isnt required to use them.  the auto-rescale is nice, but i dont want to give up the control i have in AEM PRO

Well said. I agree completely

Also, I would say 95% of the time I am viewing raw in the fuel table. So it would be nice if we could keep that

[Scott Warwick]

X3

UNDERPSI6

first of all this guy is a nerd!!!! but unfortunately I agree with him.

[SAG]

Well, it seems there is some demand for it. Our stance is still that tuning in raw units is more of a "remnant" of AEMPro design since they have no real meaning in and of themselves, and they just serve confuse many people, but we will consider your requests. Thanks

Samy

[Alpha]

Well, it seems there is some demand for it. Our stance is still that tuning in raw units is more of a "remnant" of AEMPro design since they have no real meaning in and of themselves, and they just serve confuse many people, but we will consider your requests. Thanks

Samy

It's a small "remnant" of the AEMPro design Please do consider it though