____  
 |  _ \ 
 | |_) |
 |  _ < 
 |_| \_\
        

  ____  
 |  _ \ 
 | |_) |
 |  _ < 
 | |_) |
 |____/ 
        
        

______ 
|  ___|
| |_   
|  _|  
| |    
\_|    
       
       

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

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

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:
'''VEMS uses the PS2 clock signal to receive 0/5V wheelspeed frequency signal.''' Therefore the non-PS2 firmware must be used ( my_make.16x14/vems.hex ). See GenBoard/UnderDevelopment/FirmwareChanges around and after 1.1.53 '''Sensitive pin''' PS2 clock input is a direct CPU pin. It is very sensitive. Either static electricity or 12V will damage the main processor immediately. Therefore many users request in the WebShop order note: * PS2 clock wheelspeed input on EC18/17 instead of 2nd WBO2 FET. * 4k7 pullup to +5V * 4k7 and 5V1 zener protection on the processor pin This way it is less likely to damage it, and an open-collector HALL sensor or a VR signal and a simple NPN inverter can be used to drive the signal (LM1815 is not necessary for this, although that would work too). Care is still needed of course. ---- '''Wheelspeed data usage''' * logging wheelspeed to notebook, or SDcard * sending to AfreshTiny/AimDisplay for well-visible display * boostcontrol - gear dependent boost * '''launchcontrol - wheelspeed dependent rpm-limit''' ---- '''Launchcontrol''' The good old initial launch behaviour with retard and launch-enrichment is still there. But after reaching the first entry in an '''8 entry table (array)''', no retard, no enrichment: 2x8 bytes for '''wheelspeed => RPMlimit'''. Firmware uses interpolation for smooth transitions between table-points. RPMlimit is in 100 RPM unit. wheelspeed is the unit of your choice. Usually: * km/h * or mph * or any other. It really just depends on calibration The same table is time => RPMlimit for the PS2 firmware where wheelspeed is not available. Time is in 64 msec unit. The first and last bin in the table are somewhat special: * Before the first entry is reached, the good old one-value RPMlimit set in config is used and retard and enrichment is applied * after the last bin, launch is disabled and not active any longer. Note: the '''"launch-active" flag''' in VemsTune only '''lights up when the RPM-limit is reached (not when the button is pressed - this can be confusing)'''. So if you want to test an analog input switchbutton, configure the ALS input to that pin to see that it lights up. ---- '''REST OF THE PAGE IS BRAINSTORMING''' ---- '''Freq to voltage''' - could also be used [http://www.elfa.se/pdf/73/731/07312713.pdf LM2917] frequency to voltage converter to get wheelspeed info on the LCD and for logging. The app note even has a design almost ready for use Is anyone besides me interested in this? Is there any problem with this solution that I am missing? //Emil
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.