When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
Ok, you didn't say that it was a Mirage in your PM.
Unless you are using a 2001+ lancer or 3G eclipse ECU, it won't work. Also, I've said above that I can't confirm it works with ECUFlash 1.29, but that it DOES work with EVOScan's flashing utility.
Ok. I'm getting too many PMs from people who have apparently never learned to read. Unless it's a question about getting the PROPER software and hardware to work, I'm going to delete any PM that I get. EVERYTHING you need to know is in the first post, in regards to what hardware and what software will work. DO NOT PM ME ASKING ME WHY ECUFLASH 1.44 WON'T CONNECT WITH THE VAG COM CABLE.
I have also said that I can't confirm whether or not 1.29a will work either. If some people have made it work, ask them, because I can only comment on what I've worked with: FTDI VAG COM CABLES and EVOSCAN'S FLASHING UTILITY.
Sorry, but this is getting out of hand, I may just delete all the info. It's more trouble than it's worth.
I recently bought one of these cables to test purely for logging (I have an OP 1.3U for flashing), but I can't even get it to log with Evoscan - it just tries to connect repeatedly.
The USBVIEW utility reports the correct vendor and product IDs for a FTDI serial device, and the drivers included with Evoscan do get loaded.
Even though I disassembled the unit and checked the chip markings (the main chip is marked with the FTDI logo and the FT232RL identifier), having come across recent reports of suspect FTDI chips I wouldn't be too surprised to find its a fake chip with the attendant compatibility issues
Try altering the latency settings for the COM port that the cable 'becomes'. I find that the stock 16ms setting is sometimes wayyyyyy too high for some cables.
Try altering the latency settings for the COM port that the cable 'becomes'. I find that the stock 16ms setting is sometimes wayyyyyy too high for some cables.
Thanks for the suggestion - unfortunately it hasn't seemed to help. I dropped the value first to 8ms then to 4ms with no change in behaviour .
It appears not to be getting the echoed INIT response, and is stuck in the init loop until stopped.
I did wonder about the difference between the FT232B and FT232R versions of the KKL cable, at least in terms of how Evoscan might be attempting to use them, based on the circuit differences between the early OpenPorts (1.2 & earlier) which used the FT232B chip and the later OpenPort 1.3 variants which use the FT232R chip.
Do you know specifically which FTDI chip is in your cable, or failing that, by what name the system identifies it? (eg "USB Serial" or "FTDI USB UART")
I'm not exactly sure, and my cable doesn't read right anymore due to some experimenting with FTProg, lol. It also only connects for logging and not for flashing...see previous comment about experimenting . I completely forgot to save the stock settings, sigh. I do recall that it showed up as FTDI USB UART though. I believe the only differences between the B and R chipsets is that the R is reflashable, although I can't be sure off the top of my head.
I am expecting another cable at some point, hopefully in the next week or two.
I'm not exactly sure, and my cable doesn't read right anymore due to some experimenting with FTProg, lol. It also only connects for logging and not for flashing...see previous comment about experimenting . I completely forgot to save the stock settings, sigh. I do recall that it showed up as FTDI USB UART though. I believe the only differences between the B and R chipsets is that the R is reflashable, although I can't be sure off the top of my head.
Oops on the settings... I did remember to save the info when I also had a fiddle with FT_Prog - if you like, PM me and I can arrange some screenshots of what my cable looks like (restored to original state) in FT_Prog.
FTDI USB UART indicates an R series chip, which are much more common in these cables - probably due to not requiring a separate crystal and associated components in addition to an EEPROM, thus reducing manufacturing cost.
Compared to the B chips, as well as an internal EEPROM for the identity stuff the R chips have 5 additional pins with programmable functions - several of which are used in the OpenPort 1.3 cables for controlling some behaviour (though I'm not sure to what extent this affects Mitsu usage).
Nope, since the freebie flashing utility inside evoscan is only 8/9. The communication protocols are also different in the X, so the cable won't connect.
. I completely forgot to save the stock settings, sigh. I do recall that it showed up as FTDI USB UART though. I believe the only differences between the B and R chipsets is that the R is reflashable, although I can't be sure off the top of my head.
