Sometimes a bit more measurements are needed than usual.
The worst is the low-toothcount VR.
- With the 135 tooth audi it's only sectrig that's problematic (and we have very good recipe that works on factory systems and most tweakes systems as well).
- with subaru both the primary and secondary VR are the problematic low-toothcount VR: like MembersPage/SkassaSubaruNewtrigger
- this page was made after the shocking revelation of the extremely long (and therefore suspicious) MembersPage/SkassaSubaruNewtrigger where 30 deg gap > 90 deg !
Without finding out what is happening, there is little hope.
The following measurement is recommended, simultaneously
- soundcard record the input VR (divide by 10 to 100 should be fine)
- we want to see if the anomaly we've seen in the mde40 log can be seen in this as well
- we accept that the signal is possibly inverted (either both or none). For VR polarity, we have other measurements anyway.
- optional: scope record the output of the LM1815 (both channels)
- Manmde40 triggerlog (or with new nightly VT Tools/Triggerlog, save ) with 1.1.78 so we see the sectrig pulses too
Than start cranking. We'll syncronise the data if necessary. Take at least 8 seconds. (or 5+5 seconds)
Triggerlog scope function
- for capturing mde40 log from Tools/Record-Analyze Triggerlog
- the scope version has realtime update
- still a bit crude, but much less keystrokes needed after any HW-change (sometimes just adjusting a potentiometer variable resistor) than earlier.
- unzip, and the exe (usually vemsTune-c.exe ) can be dropped into recent, installed nightly vemstune (and make sure to run the vemsTune-c of course).
Marcell used 2010-06-11 nightly (that was actually a noon compile), and found the following:
- the numeric grid can be used to see the pulsetrain, values are in the good order
- but the scope seems to mismatch ! It has extra pulses (for sure on the secondary!)
Also, the timestamps even in the numeric grid are suspicious. Eg. in the example the camsync pulses (in the subaru group of 3) are very close:
- (763.632 - 762.452) / (1036.864 - 492.848 ) = 0.0021691
- apparently 27 times shorter gap than real. It's not just one occurence. It's very consistent in the triggerlog (1.18 msec at the beginning. and 0.95 msec at the end, because RPM climbs a bit). Difference is usually around 256. Maybe a *256 is missing somewhere from the calculations ?
- while in audacity: 0.059 of the half period, which is good
- 6% compared to the half period, (because I measured between the lonely pulses from the 1-3-1-2) is good value.
It's not "losing 262 msec" or anything like that (because pulses are more frequent than that). If it's really that close in the triggerlog, we have to know for sure !
- the timestamp scale in the upper, debug part of the output (that shows sectrig more spectacularly than the missingtooth output btw - except for the missingtooth pattern, of course) is wrong for sure. Appr ~50 times longer shown (540 msec instead of ~10 msec real).
- also, it must be checked that timestamps are interpreted as big endian (little endian is unlikely, but stupid-endian is a possibility)
After hexdump -C, highlighting 7e frames, let's see in octave:
- s=[0x1197, 0x12be, 0x13df,0x1d8c,0x27c8,0x28e8,0x3340,0x3a83,0x3ba4,0x3ccb,0x466d,0x50a2 ];
- plot(s, "*")
The 3-1-2-1-3... pattern is very visible. Let's see the camsync pulse diff relative to the half period: (5087-4798)/(13120-7564)=0.052
This suggests that the firmware and the log is good !