Tuning: afrBins2 table correct?

[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-Foru...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...DFI2&offset=27
http://www.ecmspy.com/cgi-bin/detail...DFI3&offset=27

[jetlee]

You really are ****ing 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 ****ing imbecile.

[jetlee]

...unless what you're trying to say through your bull**** 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 ****wad.

Go **** a goat, douchebag.

[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.

[mriulvr]

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