I made some more progress last night on improving the performance of data logging. I spent some time going through the assembly code for the KWP2000 protocol on the ecu, and I found some loop holes in the protocol timing. By exploiting these loop holes I have been able to go from 17 reads per second to 25 reads per second. And don’t forget that I read 254 bytes each time, which results in reading many variables at once.

Another cool side effect of running the protocol this way, is it has shifted the delays in the protocol onto my PC. Which means any optimizations I make to the logging code on the PC, or running on a faster computer, means the protocol will be able to read more than 25 times a second. Currently the PC handling the read responses from the ecu is the slow point in the protocol. Assuming a PC that can handle read responses from the ecu instantly, the maximum read limit should be around 60 to 70 reads per second.

I am planning on pushing the read limit a little bit more by optimizing my software in a few more places. Hopefully I will be able to get 30 reads per second. After which I will be able to incorporate these protocol optimizations into my ecu flashing software to hopefully get a 25 second ecu flash instead of my current 47 second.

PS: APR ECU Explorer reading at 18 times a second now just seems slow. 😛

Sorry for the long time since the last update. This website is done in my free time outside of work, so sometimes it can be hard to do updates and work on software.

My house has not had a drive way for the last two weeks, and the sidewalk outside my house has also been blocked. This is all because my driveway is being replaced; yay! But this means I haven’t been able to do much in the car; boo! So I haven’t had a chance to devote any time to developing my base tuning for the larger MAF and injectors.

But, what I have had time to do is improve my KWP2000 communication system and do a lot of data logging optimization. My KWP2000 system is now much more robust and is much better at recovering from errors. Also you can now connect, disconnect, and do multiple operations without having to restart the program. Previously I had some problems with the system not cleaning everything up once and operation was complete, and this prevented you from running another operation. What this means is I can now edit maps, reflash my engine computer, and then run the data logger, and repeat endlessly, without having to restart the program. This greatly speeds up tuning iteration. 🙂

As for data logging I have found some ways to optimize the communication protocol. Currently on my 2Ghz dual core machine with 1G of RAM running Windows Vista I am able to read 17 times a second with 254 bytes for each read. In my real world tests logging things like RPM, load, boost, misfires, knock retard, knock voltages, I was able to read about 70 values a second. Since I read blocks of 254 bytes each time, when values are next to each other in RAM I can read them all out as one read. So for instance all six knock voltages get read as one read operation. APR ECU Explorer claims to read 18 samples per second, but they don’t specify if they read individual values or blocks of memory each time.

I spent a little time this morning going over the timing calculations in the KWP2000 protocol assembly code for the ME7. I have some ideas on how I can make ECU communication faster, but currently I doubt will ever be able to do more than 40 reads per second, based on what I found in the assembly code.

A nice side effect of the KWP2000 communications optimizations I did for data logging, is that they will also work for my ECU flashing and reading operations. Currently I can reflash an ECU with an updated file in 47 seconds, with my current optimizations I should be able to get that down to around 25 seconds I think.

There has been some discussion in the forums about Anti Lag Systems (ALS), No Lift Shifting, and Launch Control. The goal of the discussion is to define the best way to implement this in the ME7, and then when I have time, I can get to writing it for everyone. So if you have time, please throw in your two cents in the thread: Launch Control, Anti Lag, and No Lift Shifting with the ME7

If there is any info you want to see posted in the forum, or if you have some specific questions, just contact me and I will get the info posted.

I managed to find the time to upload some documents and original ecu files to the forums. Finding time for car tuning is harder. Getting home from work at 7pm and trying to tune your car and not annoy your wife is a hard thing to do. Not to mention there seems to be endless work to do on the house and the other cars I don’t want to tune. But, I did find time to make an exciting favicon for the website. 😛

So far there hasn’t been much activity in the forums. I’m hoping that once I am able to post some results from my initial tuning in the forums that will stimulate some interest. Once we have some interest in the forums it will be easier to discuss some of the advanced tuning features of the ME7 in an informal stream of consciousness sort of way. If you want to talk about something in particular, just start a forum thread and I will start answering questions as soon as I can.

What time I was able to spend on tuning in the last week, went to fixing some bugs in my data logger software and playing around with rescaling the MAF, fuel injectors, and injector latency correctly. My goal is to rescale the MAF and injectors to physically correct values, and not just scale them relative to each other. To achieve correct scaling I am going to remove my larger MAF housing and reinstall my stock MAF housing with known scaling and flow characteristics. Once I have done that I will be able to scale the injectors relative to my known MAF. Then once the injectors are scaled correctly, I will reinstall my larger MAF housing and begin scaling that until it behaves correctly.

The way I am testing to my changes to the fuel injector scaling, and fuel injector correction is by logging the short term and long term fuel trims. The long term fuel trims give you great feedback on what the engine computer believes the idle additive offset and part throttle multiplicative scaling are. The idle additive offset long term fuel trim is essentially the discrepancy between the injector latency values in the ecu and the actual injector latency. You can use it to determine if you need to increase or decrease the latency values in the ecu. The part throttle multiplicative scaling long term fuel trim is the discrepancy between the flow rate of the injector in the ecu, and the actual flow rate of the injector. This you can use to determine if you need to increase of decrease the scaling of your load to injection time conversion constant in the ecu.

If you want to get crazy with some spread sheets, then you can log your short term fuel trim and plot it against your injection time. Then you would need to do a best fit line through your data set. The difference between that best fit line through your logged data and the ideal line with zero correction can tell you how to adjust injector latency and scaling. If the line starts above or below the ideal line, that will tell you how to adjust your latency. The slope of the line will tell you how to adjust your injector scaling.

It all sounds simple! But when you factor in software bugs, potential vacuum leaks in the motor, problems with fuel atomization at idle, problems with injection time accuracy when using short injection duration at idle, it quickly becomes a moving target taking much longer than you expected. But in the end it will hopefully all be worth it when the tuning start to focus purely on the performance side.