InputTrigger/TriggerLogOld

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

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.

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

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

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

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