For the foreseeable future, it runs as fast as it is going to.

I was able to getting data logging up to 26 reads per second of 254  bytes each time. My previous best was 25, so not as much of an improvement as I had hoped. This was accomplished by sending the next read request immediately upon receiving a read response. Then doing all of the parsing of data and updates while I am waiting for the ecu to respond. My profiling data seems to be pointing towards the USB latency as the limiting factor in the data logging speed, and there isn’t much I can do about that since I already have the USB latency values tuned for minimum response times.

As for flashing times, I was able to apply the optimizations for data logging to ecu flashing. Previously I was able to flash an update to the ecu in 47 seconds. Now with the timing optimizations I can do an update in 28 seconds, which is pretty sweet. Hopefully I will be able to make this a little faster, but for now it isn’t a priority.

I also did some more work on communication fault tolerance and robustness. I am now able to recover from garbage data ending up in my receive buffers, as well as messages just getting lost. This allowed me to disconnect the cable from the OBD port while data logging, and reconnect it a second later without any problems. Everything keeps running as normal, no need to reconnect or restart anything, the data logging just keeps running. It detects that there was no response to a message, or that some garbled data showed up on the communication line, and it just ignores it and keeps running. Next I am going to test this while flashing the ecu to make sure it can recover. We don’t want anyone to accidentally wiggle the cable in the OBD port during a flash and have that cause an unrecoverable error. 🙂

The next step is going to be user interface work and tuning my car. I have been working on some UI designs, and once I get to work on some of them I should be able to release some beta software to the community. I also promise to start tuning my car again this week now that my driveway is almost done.

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.