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
A guy here in Sweden has reported a similar problem but related to ignition. With a steep ignition map in the idle range he said that he got a strange spark behavior, he claimed a problem with the interpolation but never made a report that allowed us to recreate the problem. I suspect that this can be related. -Jörgen
I feel the problem is code and not compiler related. I found that the index lookup function was a good bit away from the table look up function in the main loop and am in the process of putting these two back to back in the main loop. This should fix most of the problem but it may not hurt to combine the index lookup in the table lookup so that a "one shot" capture of an operating point can be used for the lookup and weighting process. As for other revisions, I did not see anything listed in the release notes (from V28) that would indicate this issue has been looked at. That does not surprise me as you would normally only see it in a gross way if you were sitting on a cell site on the bench or dyno (like we are doing).
Running the two functions back to back did not fix the problem. I am compiling with 20050214 and will try the newest firmware release to see if that fixes the problem.
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.
- [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?