Tuning: afrBins2 table correct?

[gbalias]

8bit

not sure about the ECM using the full 5v range for its adjustments.

youd probably have to try and get a hold of someone from innovate. i highly doubt buell will tell you. lol

 

[gbalias]

also.....the 'easy' way without spreadsheets for the front fueling is to load up the stock or race maps, then check the tick mark for "% simultaneous"

in the rear map, enter the new value for the cells that changed. it will automatically adjust the front map with the same percentage of change as you did to the rear.

 

[mriulvr]

also.....the 'easy' way without spreadsheets for the front fueling is to load up the stock or race maps, then check the tick mark for "% simultaneous"

in the rear map, enter the new value for the cells that changed.  it will automatically adjust the front map with the same percentage of change as you did to the rear.

Nice! I have a spreadsheet set up where I past the tuned rear and it generates the front. I have one where it adjusts for the difference between front and rear race maps and the percent change based on the front and rear race maps. This eliminates a step!

I will look into the ECM using the 0-5 volt and see what I find out. One other question, do the AFR tables from MLV get saved in the fuel map/EEPROM or are they just in MLV? If they are not included when flashing the new fuel map then it doesn't seem like it would matter if the 0-5volt is used in ECM.

 

[gbalias]

they are just in MLV. they are used to make the calculations on the new fueling values.


i dont think there is any benefit of using the 5v for the ecm since its only worried about the O2 switching point and not the full range of AFR.

you would still have a very shallow range of voltage to specify in the eeprom on either side of stoic

 

[theMelvster6]

Ecmspy Q&A this thread is painstakingly long, but loads of tips as well. On the note of supplying 5V to the ecm for corrections, as gbalias said, it's not necessary. The ecm can pass the 5v through it for data logging, but I honestly don't know how it would respond with 5v for corrections. Maybe just throw a CEL or maybe brick your ECM. The 0-1v is all it needs from the narrowband signal.

 

[gbalias]

man, i remember the days of tht thread. lol

 

[theMelvster6]

Yeah, it's older but still full of helpful stuff.

 

[mriulvr]

Ecmspy Q&A this thread is painstakingly long, but loads of tips as well.

Nice! The thread from there for the LC-1 was really helpful. I have read so much stuff to learn how the ECM works, ECMspy works, MLV, works, LC-1 works,... I have a stack of papers about 4 inches thick of stuff I wanted to have handy and take notes on but I hadn't come across this thread. More reading and knowledge for me. I feel like I am kind of where many of you were when these threads were being written. A little late to the party. Thanks, again!

 

[gbalias]

i pretty much summed it up for you in the PM i sent. and with the info within this thread. lol

those were the days we were still getting grips on the ecm and its functions and different methods were being tried.

now, i can have a bike all tuned up in a couple hours. (with LC1 of course. haha)

 

[mriulvr]

Next question. I am a little confused by the TPS 8Bit (TPS 10Bit/4) and the Load. When I run MLV with TPS 8Bit for the y-axis the lowest value I get, at idle, is 57. On the fuel map this is way higher than where the idle region is located, see below.

The same moment in the datalog with the y-axis set to load seems to be in the correct part of the fuel map. see below.

These are both at idle with CLT = 183 degrees while the bike has been idling for over 30 seconds at a stop light.

It appears that if I use the TPS 8Bit for the y-axis then MLV is referencing the wrong part of the fuel map but if I use the Load as the y-axis then it is in the correct part of the map. Just for reference, this datalog was during my normal commute to work, no high RPM hard acceleration and the TPS 8Bit minimum was 57 and maximum was 104 while the minimum load was 16 and the maximum load was 77.

So, while the ECM tuning guide states that the TPS 8Bit should be use for the y-axis this seems to be giving me the wrong readings in the fuel map. Am I correct? Should I use Load instead? Am I misinterpreting the data?

 

[mriulvr]

Feedback? Insight?

 

[jetlee]

If you have DDFI-2 (pre-2008), you should be using the Load column for your "Default Y-axis Field": and leave the TPS 10-bit column alone. If you have DDFI-3 (2008+), then use TPS 10-bit.

http://www.ecmspy.com/faq.shtml #18

18. Q: MLV is complaining about TPS-8bit not found in the log file. What happened to the TPS-8bit value?
The TPS-8bit value, which represents the Y-axis in all DDFI and DDFI-2 maps, has been renamed to 'Load' (rear cylinder) and 'Load1' (front cylinder, where applicable). DDFI-3 won't use the TPS input on it's own for calculating load, but is capable to add MAP sensor input to this calculation also. This is reflected in the new name and requires an adjustment of the MLV software.

10-bit to 8-bit should be as simple as divide by four, but in practice it is not with these ECM's. For proof of my claim, take your "TPS 10-bit", divide it by four, then compare it to your "Load" column. Here's some back and forth bitching with Ich (in english) about this issue:
http://www.buellxb.com/Buell-XB-Forum/Buell-Lightning-XB12S-XB12Ss-CityX-XB12Scg/ECM-DROID-help

 

[gbalias]

ill have to go back and check my laptop. im at work now and dont have it with me.

but ive never had any issue with MLV reading the 8bit tps data from teh log.


i have a DDFI2 (2007 XB12) and i use the TPS 8bit for the Y axis in MLV

 

[jetlee]

There is no TPS 8-bit column output from ECMDroid.

Read my quote above from the ECMSpy website. DDFI and DDFI-2 users need to utilize the Load column from ECMDroid outputs as their Y-Axis.

If you datalog with ECMSpy then yes, you do get a TPS 8-bit column, however ECMDroid only provides TPS 10-bit. Load column is a calculated 8-bit value based on the TPS and other factors; however in a DDFI or DDFI-2 the other factors are not present so it automatically outputs the calculated 8-bit value of the TPS, just as a different name, "Load".

If you try to do the 10-bit divided by 4, you end up with an idle value of somewhere around 30, which we all know is horribly incorrect. But if you compare your ECMSpy 8-bit values to the ECMDroid Load values, they're an exact match. Pictures and video in the link I posted.

 

[ich]

If you have DDFI-2 (pre-2008), you should be using the Load column for your "Default Y-axis Field": and leave the TPS 10-bit column alone. If you have DDFI-3 (2008+), then use TPS 10-bit.

Schwachsinn im Quadrat. DDFI-2 und DDFI-3 liefern beide Load in 8-bit Auflösung, und Load ist das, was das ECM für die Y-Achsen in den Maps auswertet.

http://www.ecmspy.com/cgi-bin/detail_ld.cgi?ecm=DDFI2&offset=27
http://www.ecmspy.com/cgi-bin/detail_ld.cgi?ecm=DDFI3&offset=27

 

[jetlee]

You really are ******* stupid.

Load column is a calculated 8-bit value

I clearly said that Load is an 8-bit value, regardless of DDFI-2 or 3. The difference is that DDFI-3's Load value takes into account other sensors that aren't present in DDFI-2 systems, so for DDFI-3 Y-Axis field you should be using the TPS 10-bit value. Since ECMDroid doesn't output a column called "TPS8-bit", then you use the "Load" column since it is 8-bit for DDFI-2-based systems.

You're a ******* imbecile.

 

[jetlee]

...unless what you're trying to say through your ******** is that DDFI-3 should be using the "Load" column for VE Analyzer as well...

Which I might agree, if you weren't such an offensive *******.

Go **** a goat, *********.

 

[ich]

Ja, schrecklich, dass Du Dir von solchen Menschen sagen lassen musst, wie alles funktioniert.

 

[user_deleted]

^^^^ how the hell this guy is allowed to remain on this fine forum just escapes me. [mad]

 

[mriulvr]

^^^^ how the hell this guy is allowed to remain on this fine forum just escapes me.

[up]