###  
   ##    
  #####  
   ##    
   ##    
   ##    
         

 _       
( \      
| (      
| |      
| |      
| |      
| (____/\
(_______/
         

   ##    
         
  ###    
   ##    
   ##    
   ##    
  ####   
         

  ______
 |___  /
    / / 
   / /  
  / /__ 
 /_____|
        
        

   _____ 
  / ____|
 | |     
 | |     
 | |____ 
  \_____|
         
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
Back to MembersPage/NanassyPeter ------ *Wiring complete,sensors working,i can see the gauges in Megatune,but there is no RPM signal yet (can wrong calibration (60-2 instead of 5 window) cause this?) * primary_trigger=FF (or FE if falling edge is used). The primary_trigger=01 is for multitooth (eg 60-2 missing-tooth) setup * secondary_trigger=02 must be used. But hey, this is appears on almost every pages of yours ! * TPS reads 10% after calibration,is this normal? ** of course NOT! increase tps_low ---- * 4 out of 10 startup is unsuccesful. LCD displays silly things and car runs like shit! Sometimes after succesfull starting LCD displays some kind of table data instead of realtime datas (as usually), but no keyboard is connected. ** you forgot to mention that this was after you pulled the engine and the ECM was also away for weeks. Check what could have been misconnected, or damaged. Check GND, GND5 and flyback too. Try to disconnect the LCD (maybe VCC occasionally shorts to GND in the LCD ?) * Check firmware version (a report is neglected without this information and impossible to help) * and verify firmware integrity * or reflash with a new firmware * check the config (publish mcd, mct: a report is neglected without this information and impossible to help) and compare with old known-good config * logs can also help to identify the problem ---- *Made some logs and with megalog viewer i can see some suspicious PW pikes at mindless points.(no change in tps) i will try to include the logfile [http://www.vems.hu/files/NanassyPeter/datalog200511161915_hazafele3.xls 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 [http://www.vems.hu/files/MembersPage/MattiasSandgren/BmwSevenTwentyEight/bmw_728_iat.jpg 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''' *tachometer output (weryimportant for 5 coil config) * primary trigger: VR crank 60-2 (changeable to HALL with dip switch if possible, so only the endplate needs to be removed) secondary 1 window hall camsync * High voltage flyback (2+6diode)http://www.vems.hu/wiki/index.php?action=edit&page=MembersPage%2FNanassyPeter%2FOldStatus * All 8 ignition/injector channels * EGT and Knock * 4bar MAP sensor onboard * Programmable Shift light output (a p259 channel) * baro (altitude) compensation: MAP measurement at startup. Separate baro sensor is not justified when you have WBO2: when we tune at (say) 200m above sea level, we add +10% fuel in the VE table, so ego_correction=-10% (-25 on display) that is good to appr. 5000m, and normally the WBO2 based ego correction will take away as much of the extra fuel as necessary. '''under investigation:''' * WBO2 analog output (for DVM or other ECM), eg. ** lambda=0.6 .. 1.45 => 0.6V .. 1.45V ** 1.45V .. 1.499V not used ** O2%=15..21% => 1.5V .. 2.1V (or should it be max 1.96V so the DVM can be left in 2V mode? maybe configurable) ** below < 0.55V: measurement error (eg. WBO2 sensor not heated). Alternatively this condition could be mapped to >2.5V for better margin, but when WBO2 controller is unpowered, 0V is "easier" to maintain * Warning light output: activates when any measured data (that I list here) exceeeds it's programmable warning treshold: ** CLT: engine too hot ** EGT: exhaust too hot ** MAP: boost too high (BoostController misconfigured, or pneumatic problem) ** ... Questions,PLEASE ANSWER ALL OF THEM!!!!! *For more programming room IAC settings can be simplified. 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: * http://www.vems.hu/files/MembersPage/NanassyPeter/Nanassy_mtt_files_v3_1019-1023.zip ** '''Note that global.h variables in 1.0.19 and 1.0.23 files are identical, so config.mtt files are compatible - actually, exactly identical, bit-by-bit, and MegaTune for either should work for the other too''' (so you can try mt-r027 and mt-r028 with either) ** the tables.mtt is independent of firmware version, there's never been a change there (but in MegaTune, "12x12 default" must be selected). The included tables-1.0.19.mtt and tables-1.0.23.mtt are identical The config.txt didn't seem seriously damaged at brief review, variables seemed mostly sane. * alternate=14 # means all 5 injectors are fired simultaneously during cranking * cwl=D7 # therefore this cold pulsewidth is extremely long: might appear as 21.5 msec in MegaTune but in fact 200 * 0.1 + 15*0.5 msec=27.5 msec * cwh=0B # while at warm, 1.1msec sounds a bit low (but possible) Send the config.mtt and tables.mtt files with TerminalProgram ("send file" option, or even copypaste is possible) ---- '''Readback''' *config and tables read back from 1.0.23 ** http://www.vems.hu/files/MembersPage/NanassyPeter/r023_config/mcd.txt ** http://www.vems.hu/files/MembersPage/NanassyPeter/r023_config/mct.txt *config and tables read back from 1.0.19 ** http://www.vems.hu/files/MembersPage/NanassyPeter/1019_config_kiolvasott/mcd.txt ** http://www.vems.hu/files/MembersPage/NanassyPeter/1019_config_kiolvasott/mct.txt * config and tables read back from 1.0.14 ** http://www.vems.hu/files/MembersPage/NanassyPeter/1014_config_kiolvasott_WORKING/config.txt ** http://www.vems.hu/files/MembersPage/NanassyPeter/1014_config_kiolvasott_WORKING/tables.txt 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'' <code> -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 </code> 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'' <code> --- 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 </code> 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: <code> -k[0]=14 2D 3C 50 64 78 8C A0 B4 C8 E1 FF -r[0]=07 0C 0E 14 19 1E 25 2B 32 3C 43 4A +k[0]=8C A0 B4 C8 E1 FF 1B 1C 26 4F 67 7E +r[0]=25 2B 32 3C 43 4A 14 2D 3C 50 64 78 </code> 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: * If you sent the tables.mtt via serial, maybe the data stream got through damaged ** possible solution: send 2..3 times, and verify the read back mcd and mct values (even if just manually, a few values here and there ) * maybe a bad MegaTune startup option was selected, not the "12x12 default" that matches the firmware. ** unlikely, right ? >>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 ?) * WBO2 warmup absolute limit: try to increase from 160 to 180..220) * WBO2 PID ** Heater PID integral limit: increase (even up to maximum) ** PID Heater KI: increase slightly, but take care with this, increasing too much will result in divergent (oscillating) heater (and WBO2) behaviour ----- *i need an ALS wiring sematics ** since you have internal MAP, '''EC18pin6 is a free input. Use 10k pullup to 5V and switch to GND (EC36pin26) for activation. This does not require disassembling the box.''' ** note that current ALS code MembersPage/GaborRacz/NewAlsLaunchAndOthers uses fixed digital input, that is not available on assembled controllers; minor firmware mod is needed * i need injector setting recommendations for 14ohm high Z bosch injectors (420ccm,short pencil style ,from AUDI S3) ** injpwmt=FF # activate after 25.5 msec (actually 47.5 msec) => never. This alone would be enough enough ** injpwm=FF # PWM duty=100% .. for safety ** injocfuel=.. # 900 usec ... just a guess. Depends on flyback, relatively short with your powerflyback ----- *WBO2 startup modification: 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. *Still have TPS acceleration problem: 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. * '''3000, 287''' is best (shows -2C where prev showed -16C). Added lately, better than the old 3300_270 recommendation (that showed appr. -9C at the same input). Also, the end-railing (at min and max ADC reading) was dropped in the new tables, like in default firmware because it's a dangerous practice (left over from ... guess where). ---- '''TODO: clean up history, only leave measurements that can be useful''' When * -16C (3F) is displayed, internal 43 (0x2B) value is read from adcread position 230.5 (actually, 230=>0x2C, 231=>0x2A) * however, it should read 0C (32F, internal 72=0x48, which could be read from adcread 201) 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!!). * upload your edited vems.hex (zipped) * see IssueReports for the info needed for the report so it can be investigated 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, * and MegaTune said: "Controller code does not match" ** Expected:"0X32" ** Recieved:"0X3f" 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%. ---- [http://www.vems.hu/files/MembersPage/NanassyPeter/airXfactor/Nanassy_1.0.19_airhack.zip zipfile with changed airXfactor] Marcell put the air(den and matfac) 3000_287 (with clt default) into * 1.0.30 * firmware 1.0.19 that Peter provided. Note that there was no 1.0.19 firmware release ** Please verify with MegaLoader (against in-flash firmware) that the 2006-01-15/vems_1.0.19_orig_according_to_NanassyP.hex file (from the zip: it's 262033 bytes long) is really what works (with your MegaTune setup). 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.
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.