I have almost finished working out all of the issues with the slow init connection mode. I have one more timing issue to handle, where the 2000 ECUs take too long to send the key bytes. Once that is resolved I believe everything will be ready for the first public release.

I has also found that I can flash 2000 S4 ECUs as long as I connect with slow init. When connecting with fast init, the 2000 ECU get stuck in an infiinte loop when trying to start the programming session.

So currently I have tested and support flashing of 2000/2001/2002 S4 ECUs. I believe my software will have no problems with any 2.7T ECU though.

Hopefully I will be able to release in the next few days.

I have succeeded in getting exact timing in the ECU KWP2000 connection code for fast init. I ended up using the bit bang methods in the FTDI D2XX driver to accomplish the exact timings. Logic analyzers are a great tool.

Problem is, I still can’t connect to the 2002 Audi S4 ECU. So I decided to contact some people who write professional VAG diagnostic tools. They confirmed my suspicion that KWP2000 fast init is not properly supported on all VAG ECUs. Their recommendation was to use the slow init method instead.

Alright, now I know what the problem is, and with my mad bit banging FTDI skills, I hope get the slow init method done pronto!

All of my available free time has gone into fixing the timing issue with my ECU connection code. USB latency and 1ms precision communication timing is a tricky combination. I never would have thought there was a problem with my ECU connection code, because I have used it myself for over a year. But it turns out that the 2002 S4 ECU is much pickier about the timing precision than the 2001 S4 ECU.

Hopefully a few more days of pulling my hair out while staring at the logic analyzer, and the software will be released. Too bad I can’t just use some embedded device to handle all of my communication timing issues that the USB protocol is causing me…

And that brings me to my next update. I have been thinking a lot about making my own OBD cable, and my own hand held flashing/data logging device. For the first release of my flashing software, I want to support basic dumb cables, and so I can’t rely on any fancy hardware inside the cables. But for future releases of my software I am hoping to release my own cable with additional functionality. I am hoping to do more than just use an ELM chip with some hardware support for OBD protocols. I would like to allow for additional analog inputs on the cable for data logging external sensors like wide bands, as well as support stand alone flashing and data logging without needing a PC.

I’m not sure when any of this will materialize, but I wanted to let all of you know it is something I am sorting out as a side project at the moment.