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

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

    #    
         
   ##    
    #    
    #    
    #    
   ###   
         

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

 _______ 
(  ____ \
| (    \/
| (__    
|  __)   
| (      
| (____/\
(_______/
         

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:
'''Subpage of InputTrigger/TriggerLog''' After firmware 1.1.80 there is a newer method, see: InputTrigger/TriggerLog In some cases it seems to work even with the above problems, but trigger signal get messed up with RPM or change in noise level. So it makes sense to verify it. There are 2 simple ways * wheel error counter (only applies for InputTrigger/MultitoothTriggerWheel) * detailed logging of all trigger events ---- '''Wheel error counter''' LCD page 01 (mlp01) has info on wheel_err. The controller keeps track of wheel error counts during normal operation (no manual action required to turn it on), it is good practice to check this from time to time (especially for a custom trigger install). As you see, in this situation (wheel error because of runout on a table-test) the '''number after W.. increases''': W39, W3B, W3D, W3F. Since it's a 2 digit hexa number, it overflows after FF. <code> RPM:0244 W39S33I00 62 -00 c0000 i0000 clt: 76C adv:10 pw:1312 iac:115 110 RPM:0244 W3BS30I00 99 -00 c0000 i0000 clt: 76C adv:10 pw:1316 iac:115 110 RPM:0252 W3DSF8I00 99 -00 c0000 i0000 clt: 76C adv:10 pw:1316 iac:115 110 RPM:0244 W3FS04I00 62 -00 c0000 i0000 clt: 76C adv:10 pw:1312 iac:115 110 </code> The above snapshot was taken with TerminalProgram after switching on continuous sending of LCD data: "mdk01" every 01 second: "mdf01" (but pressing "mll" several times also works). ---- '''Serial logging of all trigger events''' '''What can be revealed this way ?''' In some cases it might be necessary to log all trigger events to reveal: * inverted VR trigger or bad selection of HALL trigger edge (in many cases rising/falling edge is spaced evenly while the other edge is noneven due to different width of the windows) * noise on trigger input * '''detection of compression phase'''. If you rotate the engine with the starter and take a log (even without fuel and spark) you will see the engine speed increases and decreases twice (4 cyl), thrice (6 cyl) and 4 times (8cyl) in a crank rotation. You can get a rough (+-5 degrees) idea of TDC position this way (you cannot tell which pair of cyl is actually at compression). This effect, with some smart code could also be used to sync a 5-cyl engine at startup without cam-sync (or missing camsync pulses). '''Quick checklist''' - takes 2 mins, so don't get scared. * exit megatune (if it was running) * connect in TerminalProgram 9600,8n1 * issue Man command (enters text-command mode) * issue mxc command to see it responds "Menu worx..." or similar. This confirms you entered command mode, and communications works. Alternatively: ** mdV command (firmware version) ** mdv command (firmware date) ** mll (4 lines of LCD content). ** or mci command to see board serialnr * '''mde40 command''' (this instructs the v3.x to dump trigger event timestamps) * start log (select file on your disk, choose a characteristic name; terminal.log is not a good filename). This "Start log" feature is called ''capture'' in some other terminalprograms. * '''NOTE THAT YOU SEE "GARBAGE" IN THE TERMINAL that makes no sense to copypaste to wiki/irc/email'''. Just save to file as written above, zip, and upload the zip so others can help you evaluate. Or you can evaluate, see below * crank min 3..4 seconds * stop log * zip the file, eg. Kuuno_opel_2006-08-18_1.zip '''Evaluation''' * because the TerminalProgram only captures "garbage" binary data, it must be formatted first for humans to understand: * print report: ''perl bin/binary.pl < toothtimes.bin > toothtimes.txt'' (check below for toothtimes.txt examples) * if you don't feel confident evaluating, just upload the zip file (filethingy DocsPage bottom) and stick up the link to your wiki project page. We help you from this on. '''More Notes''' * before entering MegaTune ** restart v3.x (or issue mde00 command to disable the trigger-timestamp-dump) ** exit TerminalProgram or disconnect * at 9600 baud (after fw 1.1.48 use 19200) and 60-2 wheel it will lose trigger events above appr. 850 RPM (baud can be set higher of course, but VR trigger problems (eg. due to noise, bad ground) are worst at low RPM anyway. (TODO: menucommand to go higher baud) * it is currently NOT possible to log with MegaTune simultaneously. "mdec0" command instructs GenBoard to send the runtime block and the time of all trigger events, but because of limited serial communication framing it is hard to separate runtime data (currently appr 50 byte sequence) from trigger event. Recommended to do either just MegaTune log or this mde40 log at one time. ---- '''Examples''' '''inverted VR trigger''' for a 60-2 wheel * Shows 2 longer toothtime: at position 561 and 563 , than 116 bytes (58 teeth) later * sum of them is (1309+1117)/625 = '''appr 4-tooth long''' * '''instead of one nice 3-tooth long toothtime'''. * last column has the toothtimes (as you probably noticed) <code> 553 642 554 33283 555 638 556 32258 557 628 558 29699 559 625 560 28933 561 1309 # long 562 7428 563 1117 # long 564 23810 565 564 566 13315 567 564 568 13314 569 564 ... one crankrotation later, position 677 - 561 = 116 which is exactly 58 trigger events (60-2) at least that is good: 673 1219 674 49925 675 1149 676 32009 677 2243 # long 678 49927 679 1823 # long 680 7939 681 894 682 32260 683 886 684 30211 685 886 </code> Note that the RPM dropped (toothtime went up from 564 to 1149) during the crankrotation, but the same bad dual-missing tooth pattern stayed (of course). '''After fixing the VR polarity:''' Here is a * '''good sequence''' * that spans 42 crankdegrees (7 *6 degrees) * toothtimes is in 2nd column, right after the position * notice the '''fast RPM climb at cranking, when the stroke happens''' ||'''toothtime (4usec)''' || '''RPM=60000000/(4*toothtime*60)'''|| ||1429|| 174,947|| ||1314 || 190,258|| ||1069|| 233,863|| ||821 || 304,5066991|| ||614.67 = 1844/3|| 406,724|| ||614.67 = 1844/3|| 406,724|| ||614.67 = 1844/3||406,724|| ||467 || 535,331|| <code> 542 1310 543 7429 544 1371 545 23302 546 1423 547 36613 548 1425 549 37126 550 1429 551 38149 552 1314 553 8708 554 1069 555 11524 556 821 557 13575 558 1844 559 13314 560 467 561 54017 562 483 563 58114 564 461 565 52482 566 443 567 47874 568 426 569 43521 570 420 571 41986 572 412 573 39937 574 411 575 39682 576 407 </code> The wheel-err count also showed that the trigger was fixed. (1..2 wheel-err during cranking is OK, but it should not climb further after that). '''Table-testing example:''' This is captured with self-stim OutputTrigger mst63 (36-1) and msp01, therefore the 512*4 usec distance normally, and *2(=1024) for the missing tooth (would be *3 for N-2 type wheel). * first column: bytecounter * 2nd colum: difference of byteswapped times (neglect it) * 3d column: difference of times (what we need) Either the '''2nd or 3d column can be the good toothtimes, neglect the other'''. The reason for this is that samples are transmitted in 2 bytes each, but because of the lack of framing the PC does not know which byte is even and which is odd (higher, lower byte). You'll see immediately, as the other will be rather random. <code> 3919 512 3920 2 3921 512 3922 2 3923 512 3924 2 3925 512 3926 4 3927 1024 3928 2 3929 512 3930 2 3931 512 3932 2 3933 512 3934 2 3935 512 3936 2 3937 512 </code> ---- '''Determining rough position of missing tooth''' * use above steps to take a triggerlog ** take triggerlog with TerminalProgram the above "mde40" way ** make a human readable textfile (named trimmed_txt_output_from_binary_pl.txt in example below) with binary.pl. The output's first column is "byte index", so the missing tooth appears at every 116 line, which is every 58th event * trim the file beginning and end to cut trailing and leading noise * use (CVS head) ''perl bin/mtx_loganal.pl oddfilter < trimmed_txt_output_from_binary_pl.txt > '' ** if the useful data appears in 2nd column (even byte indexes)instead of 3d column (odd byte indexes), use ''evenfilter'' instead of ''oddfilter''. This is rare. * gnuplot the output * write report on your relevant wiki subpage of your project pages * summarize your findings, fill in config variables http://www.vems.hu/files/TuningSoftware/Perl/Triggerlog/cranking54.png '''cranking with no fuel (TPS floored) triggerlog showing 2 compression events for every crank rotation''' on a 4cyl engine * set xtics 127,29 was used to position marker gridlines on missing teeth. 29 means that there are 2 markers for a crank rotation of 58 teeth (60-2), thus 180 crankdegrees * in this example (from engine MembersPage/MarcellGal/EngineSwap/VrTrigger), the TDC is appr. 23 teeth after the missing tooth. This roughly matches config, trigger_tooth=0x10 is applied (decimal 16) + ign_tdcdelay=50 degrees (appr. 8 teeth). As you see, in config trigger_tooth*6 + ign_tdcdelay/2 (that was adjusted earlier by mechanical measurements with a removed sparkplug) is a few degrees bigger. I am not sure about the reason for the difference * low compression of one cyl can also be revealed * therefore if you take out a sparkplug, you will know which cylinder is which * please don't waste your time by patenting this
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.