_____ 
|  ___|
| |__  
|  __| 
| |___ 
\____/ 
       
       

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

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

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

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

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:
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!) ** [http://vems.hu/files/pacsa/testVectorsForVemsTune/v3.3_n002758-2010-06-11nice_s060.zip s060 example file] 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 !
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.