InputTrigger/TriggerLog (2010-06-04 20:52:45)

This page lists some useful knowhow related to InputTrigger verification

The InputTrigger is the most important signal in the system. A multitooth trigger, especially the 60-2 contains an extreme amount of information that could be utilized for tuning. However, since many things can go wrong during an install, this page focuses on debugging, examining the trigger events that GenBoard sees.

Eg.

60-2 example log including secondary trigger data:

sectriglogexample_m582.jpg


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

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. \n

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 

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:

Quick checklist - takes 2 mins, so don't get scared.

Evaluation

More Notes


Examples

inverted VR trigger for a 60-2 wheel

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

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/3406,724
||467 || 535,331||\n
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

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).

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. \n

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


Determining rough position of missing tooth

cranking54.png

cranking with no fuel (TPS floored) triggerlog showing 2 compression events for every crank rotation on a 4cyl engine


See also