|\ /| | ) ( | | | | | | | | | | | | | | (___) | (_______)
____ | __ ) | _ \ | |_) | |____/
_ _ | | | | | | | | | |_| | \___/
###### ## ## ## ######
_ ( \ | ( | | | | | | | (____/\ (_______/
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: '''This page lists some useful knowhow related to InputTrigger verification''' The InputTrigger is the most important signal in the system, and many things can go wrong. Eg. * inverted VR signal * noise ( GenBoard/Manual/GroundConnections ) * InputTrigger/RunOut 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''' In some cases it might be necessary to log all trigger events. * mde40 menucommand (mde00 disables it) * start log / stop log in Terminalprogram (capture in some programs) and filename must be selected * at 9600 baud 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) * print report: ''perl bin/binary.pl < toothtimes.bin > toothtimes.txt'' (check below for toothtimes.txt examples) * 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 which data is runtime (currently 22 byte sequence) and which is 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> ---- '''See also''' * InputTrigger/RunOut 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.