Reply With QuoteCome on, Ich! What do you have to say now?? I hate when keyboard bitches talk **** like they're smarter and then when you prove them wrong they're nowhere to be found.
Need narrower parameters?
EZ
Come on, Ich! What do you have to say now?? I hate when keyboard bitches talk **** like they're smarter and then when you prove them wrong they're nowhere to be found.
why should i? apples and oranges. screenshot shows ddif-3 data, video shows ddfi-2 data. no tps10bit in ddfi-2 and load is calculated differently for ddfi-3 than for ddfi-2.Compare the photo below to the values in the video.
first row of spreadsheet data: tps_voltg = 0.626 volts, tps_10bit = 128, A/D range: 5 volts (ttl)
a) 10 bit resolution: 1024 * 0.626 / 5 = 128.20 ~ 128
b) 8 bit resolution: 255 * 0.626 / 5 = 32.05 ~ 32
c) 128 / 32 = 4, what a surprise ...
anyway, the data shown in the spreedsheet are erraneous:
first row:
- tpd is way too low (should be around 4 with butterfly fully closed)
- tps_voltg. is too high (should be around 0.4-0.5 volt with butterfly fully closed).
last row:
- tps_voltage exceeds default allowed tps voltage range (= tps_zero_voltg + 3.530 volts), as a rough estimation (from first row data), tps_voltage must not exceed 0.6 + 3.5 = 4.1 volts.
any discussion of any following values is completely useless now, as the input is not correct:
- tps_voltage apparently shows an offset of about 0.2 volts, which is not a problem if tpd would show correct values, which it doesn't.
- tps_zero_voltage is incorrect, as tpd shows wrong numbers
- there's also a tps voltage range problem. for reaching 4.5 v at wot, tps_zero_voltage must have been set to 1.0 volts, which would be an incorrect value, because at idle (4° open) the tps_voltage shown is only 0.6 volts.
probably the tps has been replaced by one of another make and the tps voltage range has not been adjusted to the new tps, and tps reset has been done incorrectly or tps auto-zero has been switched on and is running amok.
They're the same motorcycle; the Excel table is ECMDroid output and the video is ECMSpy.why should i? apples and oranges. screenshot shows ddif-3 data, video shows ddfi-2 data. no tps10bit in ddfi-2 and load is calculated differently for ddfi-3 than for ddfi-2.
That table is from my datalog from ECMDroid on my phone, about 1 minute after taking that video. The only reason they were logged a minute apart is because I can't have ECMSpy and ECMDroid read the data at the same time; USB vs Bluetooth and only one plug.
Now you're adding **** into the equation...you said 10bit >> 2 or 10bit/4. 85TPD*3=255(8bit) where the table shows the same 85TPD = 923(10bit).first row of spreadsheet data: tps_voltg = 0.626 volts, tps_10bit = 128, A/D range: 5 volts (ttl)
a) 10 bit resolution: 1024 * 0.626 / 5 = 128.20 ~ 128
b) 8 bit resolution: 255 * 0.626 / 5 = 32.05 ~ 32
c) 128 / 32 = 4,Â* what a surprise ...
-the butterfly is not fully closed, it's set to idle at ~950rpmanyway, the data shown in the spreedsheet are erraneous:
first row:
- tpd is way too low (should be around 4 with butterfly fully closed)
- tps_voltg. is too high (should be around 0.4-0.5 volt with butterfly fully closed).
last row:
- tps_voltage exceeds default allowed tps voltage range (= tps_zero_voltg + 3.530 volts), as a rough estimation (from first row data), tps_voltage must not exceed 0.6 + 3.5 = 4.1 volts.
-see above
-source? it's a brand new TPS
You said it was useless in your last paragraph, yet your still here talking about these values. I thought they were useless? Beyond that, every engine setup is different.any discussion of any following values is completely useless now, as the input is not correct:
- tps_voltage apparently shows an offset of about 0.2 volts, which is not a problem if tpd would show correct values, which it doesn't.
- tps_zero_voltage is incorrect, as tpd shows wrong numbers
- there's also a tps voltage range problem.Â* for reaching 4.5 v at wot, tps_zero_voltage must have been set to 1.0 volts, which would be an incorrect value, because at idle (4° open) the tps_voltage shown is only 0.6 volts.
The TPS is brand new, correct for the year/model and all values set correctly. Perhaps you don't know your motorcycles as well as you think.probably the tps has been replaced by one of another make and the tps voltage range has not been adjusted to the new tps, and tps reset has been done incorrectly or tps auto-zero has been switched on and is running amok.
You've been proven wrong and are now blaming my TPS for it. My motorcycle runs like a top.
ddfi-2 ecm do not provide tps-10bit live data values, just tps-8bit (http://www.ecmspy.com/cgi-bin/runtime.cgi), so no tps-10bit data can be logged. your screenshot is invalid.
That screenshot is straight from the ECMDroid output. ECMDroid logs 10bit values.
You don't know what the **** you're talking about.
The motorcycle that was logged is a DDFI-2 ECU, but ECMDroid logs it as 10bit values regardless, with no way to change it except after the fact through Excel.That screenshot is straight from the ECMDroid output. ECMDroid logs 10bit values.
Again...
You don't know what the **** you're talking about.
ddfi-2 ecm do not provide 10bit tps data. if ecmdroid is logging 10bit data, it's a bug. file a bug report @ ecmdroid.
that's what she said.your screenshot is invalid
You really are ****ing thick.ddfi-2 ecm do not provide 10bit tps data. if ecmdroid is logging 10bit data, it's a bug.
As I said on page one:
You still cannot argue that the TPD*3 = TPS 8Bit because it's right there in the table and video.Perhaps it's the app that recording incorrect 10bit values in the first place, which would make the calculation wrong.
Now sit down and shutup.
Posting Permissions