VEMS Home Products Documentation Wiki Webstore
WikiHome ProjectPage DocsPage UnderDevelopment MembersPage SiteIndex RecentChanges Preferences
MembersPage/NanassyPeter/OldStatus

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.

thermfactor

no coolant temp measurement data was provided so far

because looks like it works properly,i dont need/want to modify this!

matfactor / airdenfactor recalibration

LCD displays -24..-26C air temp instead of -6 .. -8C

MAT - airdenfactor - solved appr 3 days after reasonable data was provided

See EasyTherm page, the precise testing was made with airdenfactor and matfactor that closely matches your MAT setup.

At 0 Celsius the displayed MAT is -16 Celsius. Therefore the ECM enriches appr. 6% (as it should, according to the gas-law), this must be fixed.

We really do not want to hack by raping the gas-law. Instead we fix it the proper way, with proper matfactor and airdenfactor tables. See EasyTherm.

TODO: clean up history, only leave measurements that can be useful

When

This huge difference was identified, eg. appr 3000 Ohm sensor is used.

The sensor is a regular GM style airtemp sensor,like this one here:

http://www.034motorsport.com/product_info.php?cPath=23_30&products_id=58

Note that these measurements are taken in garage,not in a laboratory,i do not have a special equipment for this,80C measurement was made with boiling water.

Temp in Celsius

Real / LCD / DVM (kOhm) / DVM position / NOTE

0 / -16 / NA / NA /

5 / NA / 5.93 / @20k /

18 / 08 / 4.41 / @20k /

21 / NA / 2.92 / @20k /

35 / NA / 3.17 / @20k /My hand,real temp NA

80 *** / 77 / 0.322 / @2k /HOT water,real temp NA Real temp would be nice, but see below

100 / NA, would be nice / 0.200 / @2k /Boiling water w/ bubbles

The 100C point suggests an appr 3000 Ohm sensor: 200 / 152.75 * 2252 = 2948.60.

From this, we can have a good estimation of the 80C point: 322 Ohm * 2252/2948.6 = 245.93 Ohm for a standard 2252 Ohm sensor, which is appr 84.15 Celsius. This suggests we want +7.2C = +13F at high-temp (so 101C reading ment actual 108C which - if known - would have advantages for the coolant temp, but remember this is all for the airtemp at the moment).

2005-12-31 UPDATE:

tried bot 3000_270 and 3300_270, max MAT increase was 2C with 3300 (from -16C to -14C), but with this i was unable to use MegaTune, because it crashed, i think because firmware version problems ( i used the good one!!).

OK so here you go:

version v3.3

serialnr 312

firmware 1.0.19

Megatune R27

config,tables,vemshex zipped together(renamed,but used with normal original name!)

http://www.vems.hu/files/MembersPage/NanassyPeter/mcd_mct_hex.zip

Take care to copy-paste properly.

Messed up vems.hex version ?

Anyway the symptoms were the same,no MAT reading change after firmware change,

But when you click continue, megatune otherwise works OK ?

This suggests you likely messed up the firmware and used a different one than you intended (used earlier).

OK it looks like Im unable to make this vemsdotini hack so PLEASE do it for me and i just copy it to my firmware directory and upload it!

btw did you ever tried this method?it worked in your car????

Answer: I suspect you might have accidentally changed controller code version in the firmware. As far as I know BG_EMULATION (the var where 0x32 version is stored) never has been 0x3F (63 decimal). So be careful that nothing else was ruined in the same mistake. The mod to vemsv3.ini is simple, Line 11, signature = 50 changed to 63 will fix this warning. But again, take care not to drive with a otherwise broken firmware

Ok thanks,i really tried it hard but im not a programmer,so please do this for me!!

Ego

Today i noticed a weird ego thing:

in the lambda table there is 1.00 at idle,and the engines current lambda is approx 1.00-1.04 BUT the ego correction is at -07 - -10.

With ego=+00, lambda would be appr 0.90 .. 0.97, so the direction is right. When lambda is leaner than configured, ego slowly (speed depends on config.ego_pid_kp and ego_lag) moves toward enriching (ego++). It's not the ego correction value (you can get any by configuration) is of interest. But the direction of change: eg. if it's leaner than configured BUT ego keeps climbing down (--), that's suspicious! (shouldn't happen).

Take datalogs if you'd like to evaluate. Trashgrade injector-match (regarding injector-opening : independent of flowrate) especially with big injectors might make it impossible to keep lambda within 1%.

[zipfile with changed airXfactor] Marcell put the air(den and matfac) 3000_287 (with clt default) into

OK,thanks,i changed the firmware to 1.0.30 from 1.0.19 with the hacked airfaktor,and it looks like for first sight that it reads correct -3C insted of -20 with the wrong calibration.but not really wants to change as i started and idled the engine,anyway,more testing is needed!!I was really suprised how the new MT looks,and it even better,because i had some problems with uploading a firmware (Win+USB) i the past, but now there is no need for shorting DSUB 2 to 3 because it WORKS,great!and there is even more improvements,i uploaded my MT firm 1.0.19 megatune file and it looks like works flawless in the 1.0.30!!

after 1 hour testdrive everithing looks like functional,needs a little more fuel (because of the higher airtemp readings).

Marcell is glad that you realized now that firmware upgrade is not that much trouble after all. Good job!

If the Auditrigger is functioning i would like to order my new box with the options we decided earlier.

The auditrigger onboard-HW is stable now. Since Konyha P. didn't take his his assembled ECM after many calls, it is still available any time (ready for auditrigger). It would be good idea to interview MembersPage/MiskaPeippo/AudiSSix (get to know his final pullup value, and experience).

i tried the different RPM limiters (ignition, and fuel) but cant really feel the difference between the two.