_ _ ( ) ( ) | `\| | | , ` | | |`\ | (_) (_)
# ## # # # ###
## ## ## ## ###### ###### ## ##
_____ / ____| | (___ \___ \ ____) | |_____/
### ## ## ## ## ####
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: '''Open Issues ToDo''' Q: Has anyone experienced problems with either the kpa index or table look up that provides radically different VE returns depending upon if you approach the cell's kpa value from the high side or the low side? I can actually use a poteniameter to simulate a MAP sensor, set my rpm input on 5000 and approach a 90 KPA cell site from below and get one VE and from above and get a radically different one. Thanks, Bill Here is some more information. You can see by http://www.lolachampcar.com/images/VE%20Lookup%20Problem.pdf that VE is changing radically with but a small change in RPM. The VE table that fed the above data can be seen at http://www.lolachampcar.com/images/Ve%20lookup%20problem%20ve%20table.pdf. I believe the firmware is picking the indexs when rpm is above 5000 and thus defining the four VE cell values to use. Then it is using the below 5000 rpm number when it does the actual weighting. This would tend to weight the VE towards the higher cell (as it would finding 4999's location between 4500 and 5000) while using the VE value pulled from a 5003 rpm reading. In short, the input to the lookup function is not time aligned such that the four VE values from one point in time are being weighted by data from another point in time. When the data oscilates around a cell, bad things happen. Has anyone seen this problem before and is it something you guys are concerned about? Thanks, Bill Bill, im very intrested in this problem, is this something you also see on the pre-compiled (recent) releases ? I know we have had some issues with different avr-gcc versions in the past, make sure you are using the recommended version (see WinAVR), but anyway thanks for the report i will look into this - DB An example of how CWL, CWH, AWEV, AWEV_Temp..., and AWC affect cranking and afterstart can be found at MembersPage/BillHart/CrankingAfterStart. Recent Questions: MembersPage/BillHart/ProblemHistory for older issues that have been resolved. Projects Underway MembersPage/BillHart/WinMobileLogger Win Mobile platform to Fat32 memory card logger. Looking for SIPR examples, if any, to ease the adding V3.3 query to Win Mobile code. * [http://www.lolachampcar.com/Outside%20Pages/VR_Emulator.htm VR_Emulator] is a parallel port based Op-amp circuit that provides a plus or minus pulse about zero to emulate a VR sensor. You build the Basic routine to generate the crank (and cam)input wave form you need. Drop me a note if you need my QB code as a starter. ** we usually use stereo soundcard nowadays. It has many advantages, like processor overhead is small, amplitude can be varied, code is not hard to port between platforms, and it can even work without any executable (wav-s can be played with standard tools). MembersPage/BillHart/LoggingDongle anyone interested in a small relatively inexpensive logging dongle? *WikiAdvert: mailto:bill@lolachampcar.com 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.