VEMS Home Products Documentation Wiki Webstore
WikiHome ProjectPage DocsPage UnderDevelopment MembersPage SiteIndex RecentChanges Preferences
MembersPage/NanassyPeter/OldStatus (2006-03-16 04:43:08)

Back to MembersPage/NanassyPeter

must be used. But hey, this is appears on almost every pages of yours !
i will try to include the logfile

[Logfile]

Comments from Emil:

I never found the pikes, its a pretty long file and i haven't got too much time now, Could you provide time: entrys from those pikes?

I also suspect that you air temperature sensor catches heat from the engine bay when idling for a longer time, and after driving the sensor is reading a realistic temp (beginning of log 25degC, minimum while driving was 1.7degC), how is that sensor mounted? You can see the result of this at time: 3510

[This is a example of a pretty good budget sensor install], We had huge problems like this on Boströms BMW, IAT raised to 50+ degrees while driving slowly.. This caused a very lean situation when driving in dense traffic.

Hi Emil,

first of all thanks for your reply!

My IAT sensor is mounted at Audis stock manifold,stock place.

After throttle valve in intake manifold.

I always tought that when driving slowly (so IC not working) IAT can be 50+ celsius.But i see the problem at 3510....

But anyway i think between 7 and 37C is only 7 percent fuel enrichment,i my problem is not this....

Gve Spikes are at:

2677

2695

My other problem is that tps acc is always 100% so no enrichment,why?in MT i set some numbers there ,are the too big or out of range?

Thanks again,Peter

I tried various Acceleration Enrichment settings,nothing worked,i monitored it with realtime display and even with the crazyest numbers and fastest throttle opening there was no affect.My mixture of course leans out and car hesitates if i accel hard.

how can i find information about firmware upload??

wishes for next v3.x ECM

secondary 1 window hall camsync

under investigation:

Questions,PLEASE ANSWER ALL OF THEM!!!!!

If coolant bins are locked please extend its range from -20C to +120C

Config and tables - also generated mtt files

From your config mtt files created for 1.0.19 and 1.0.23 firmware:

The config.txt didn't seem seriously damaged at brief review, variables seemed mostly sane.

Send the config.mtt and tables.mtt files with TerminalProgram ("send file" option, or even copypaste is possible)

Readback

Looks like there ARE differences from the original!!! Are they serious differences ?

  • likely just a few values probably changed from MegaTune ?
  • or complete stupid values, maybe offsetted (values shifted to different variables). ?

Should I make mtt files for the original?

Verification

Verify 5..10 values (some from the beginning, middle and some from the end) manually.

I verify with diff -U 1 etc/config.txt readfrom1.0.19/mcd.txt\n

-rpmk[1]=60
+rpmk[1]=1E
 tpsdot_kpadot_conf=00
@@ -250,6 +250,2 @@
 tach_channel=FF
-tach_divider=FF
-shiftcut_conf=00
-shiftcut_time=01
-shiftcut_channel=FF
-
+tach_divider=FF

The rpmk[1]=1E instead of 60 is very strange, definitely bad. It results in a -2.5% (repeatable) error in RPM reading. The 3 extra variables from the end are probably left out in the read-back file.

I verify with diff -U 1 etc/config.txt readfrom1.0.23/mcd.txt\n

--- etc/config.txt      2005-11-28 16:23:23.000000000 +0100
+++ readfrom1.0.23/mcd.txt      2005-11-28 17:48:31.000000000 +0100
@@ -42,3 +42,3 @@
 rpmk[0]=09
-rpmk[1]=60
+rpmk[1]=1E
 tpsdot_kpadot_conf=00
@@ -252,4 +252,3 @@
 shiftcut_conf=00
-shiftcut_time=01
 shiftcut_channel=FF
-
+shiftcut_time=01
\ No newline at end of file

The rpmk[1] is the same, and there is no other difference (the "No newline at end of file" is harmless).

verify readback tables

diff -U 1 etc/tables.txt readfrom1.0.19/mct.txt shows only minor differences, nothing harmful. (eg. different boosttarget at very low-RPM, where it does not matter anyway)

WARNING!: diff -U 1 etc/tables.txt readfrom1.0.23/mct.txt showed big differences ! Almost everything differs, I just pick the most shocking RPM and KPA bins:\nÿ3ÿ

Eg. RPM starts from 0x25=37=3700 RPM.

Looking at the end of the readfrom1.0.23/mct.txt r[0], we see 14 2D 3C 50 64 78 which should be at the start of k[0] !!!''' This is 6 bytes offset . Similarly, 8C at the start of k[0] should be at position 6!

What you noticed in MegaTune, is exactly the same: RPM starting way to high and vector-war screen, because kpa is not monotonously increasing (but decreasing from FF to 1B at the middle)

Seems like it was left over from your ooold 1.0.15 (or 1.0.13?)

>>>i think it was 1.0.14!!

.Possible causes:

>>i always select the default 12x12

Uploaded the files you provided and upgraded to 1.0.19,looks like everything is fine now.I found some stupid numbers (nothing serious),maybe these caused my problems.

EGO-correction seems to be automatically disabled sometimes during idle, resulting in rich 0.89 lambda instead of the desired 0.95 .. 1.02. (what is VBatt during this situation? How much lower than normally? can this be spotted in your logs ?)

Is it possible to modify the firmware so i will have wbo2 after ignition on ,not after RPM is seen?

Megoldható hogy a WBO2 indítását ne a fordulat végezze hanem gyujtásra is beinduljon?Ezzel a hidegjárási állapot sokkal jobban tuningolhatóvá válna,és az afterstart paraméterek jobban láthatóvá válnánának!

Be tudod kapcsolni a szondat az mde02 parancsal! Es utana tudsz inditozni ha mar felfutott a szonda.

i the 1.0.14 firmware i was unable to get any kind of tps acceleration,even with the craziest numbers.

BUT NOW with the 1.0.19 , in the realtime display,it continously blinking!!!!!

I already tried to set the functional numbers,but nothing changed.

found this on MS site.

is this true?

"All of the embedded microprocessor code executed in MegaSquirt was hand-written directly in assembler, not compiled from a high-level language. Working directly in assembler produces the tightest and fastest-executing code possible, even compared to the most efficient C compiler available. The result is that MegaSquirt can provide real-time fuel calculations up to 16,000 RPM!"

Yes it's true. No need for exclamation marks though as the VEMS can do 100000(onehundredthousand)rpm or so with a primitive trigger like the original MS need to use to run 16k. With well written C code and a 8-16 times faster processor (can't remember exactly) we really blow the MS out of the water.