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

         
|\     /|
| )   ( |
| (___) |
|  ___  |
| (   ) |
| )   ( |
|/     \|
         

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

         
         
 # ###   
 ##   #  
 #       
 #       
 #       
         

_________
\__   __/
   ) (   
   | |   
   | |   
   | |   
   | |   
   )_(   
         

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:
Currently we use a fixed Integrator Time Constant, but after thinking about this and discussing it with MembersPage/DavidBlades it has become apparent that the time constant actually needs to decrease as engine speed increases. The reason for this is that the knock window time decreases with engine speed, so we need to increase the resolution to view the events in that time period more closely. David calculated the time constant and worked out that at 500rpm the Time constant would need to be ~600uSec which is the highest time constant available with the TPIC8101, at ~8250rpm the Time constant would need to be ~40uSec (the lowest available constant with the TPIC) [Additional from dnb] The time constants I calculated are merely to make the best use of the range available in the chip. The "best fit" I could come up with has approximately 30 time constants per window. This is not certain to be optimal, but it is consistant across RPM. I suggest that a parameter be entered in the config called something like "timeconstants_per_window" In my case this is 30, but it is equally valid to use 15 or 20. Using the data from the calculations with the fixed time constants the following RPM to Time Constants(TC) ||TC Prog. Value||TC uSec||RPM|| ||31||600||555|| ||30||560||595|| ||29||520||640|| ||28||480||694|| ||27||440||757|| ||26||400||833|| ||25||360||926|| ||24||320||1042|| ||23||300||1111|| ||22||280||1190|| ||21||260||1282|| ||20||240||1388|| ||19||220||1515|| ||18||200||1666|| ||17||180||1851|| ||16||160||2083|| ||15||150||2222|| ||14||140||2380|| ||13||130||2564|| ||12||120||2777|| ||11||110||3030|| ||10||100||3333|| ||9||90||3703|| ||8||80||4166|| ||7||75||4444|| ||6||70||4761|| ||5||65||5128|| ||4||60||5555|| ||3||55||6060|| ||2||50||6666|| ||1||45||7407|| ||0||40||8135|| When the TC uSec values are plotted you'll see that there are changes in the gradient this occurs every 8 cells at the RPM values of 1111, 2222, 4444 (I dont know if this is significant). There seems little point in looking for detonation at points 25 to 31 (926rpm to 555rpm) so we need only deal with 24 values to map the RPM to the time constant. The question is... how best to code this? [dnb again] This is a very good question! I thought about the following idea, but it's not exactly efficient to code! Get RPM reading Work out exact time constant from RPM (simple equation - something like ((window_length/360)*(60/RPM))/consts_per_window ) Look up from a table the index of the closest time constant (lookup table fits in the AVR flash easily) There's no really nice compact algorithm I can see at the moment to go from Tc to index. Send SPI to chip containing new time constant Now back to normal knock stuff... Do capture etc... [more thoughts] Given the way the knock code works - by comparing the noise level outside the window to that of inside the window - the idea of changing integrator time constant with RPM is slightly less important as we are comparing like with like (as long as the windows are the same length), but it would still be VERY useful to investigate the benefits, as some of us don't have all that much "non-combustion" time to play with!
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.