EvoScan J2534 Read Error - 16
#65
Evolved Member
iTrader: (10)
Join Date: Mar 2013
Location: Chicago
Posts: 890
Likes: 0
Received 0 Likes
on
0 Posts
Lol @ of course you can. This thread isn't even about v7 so I should be more clear, maybe you didn't read the whole thread. So you are saying that you can use evoscan and a 2.0 openport to read and clear DTC's as well as activate all the actuators in the bottom right hand corner of evoscan simply by installing 1.42 instead of 1.44???
#66
Evolved Member
iTrader: (10)
Join Date: Mar 2013
Location: Chicago
Posts: 890
Likes: 0
Received 0 Likes
on
0 Posts
I wish it was that simple. If it was Hamish wouldn't be rewriting evoscan to work with the new 2.0 firmware, it isn't the driver itself. It's the firmware and the way evoscan recognizes the firmware that causes the j2534 driver to error. I don't see how using 1.42 changes the hardware's firmware, because it doesn't.
Last edited by jrainwater; Jun 9, 2014 at 10:19 PM.
#68
Evolving Member
Lol @ of course you can. This thread isn't even about v7 so I should be more clear, maybe you didn't read the whole thread. So you are saying that you can use evoscan and a 2.0 openport to read and clear DTC's as well as activate all the actuators in the bottom right hand corner of evoscan simply by installing 1.42 instead of 1.44???
The problem is with ftdi drivers. They are really hard to reinstall.
#69
Evolving Member
Join Date: Sep 2012
Location: Ottawa, Ontario, Canada
Posts: 181
Likes: 0
Received 0 Likes
on
0 Posts
The issue is with the way Evoscan 2.6 works with 1.44. ECUFlash is a constantly updated program, that's supported by it's developers, and EVOScan 2.6 was made in mid-2000...so why would someone reduce the functionality of their flashing program just to use a really old version of logging software that is buggy at best?
The OP2.0 doesn't even use FTDI drivers, only the 1.3.
The OP2.0 doesn't even use FTDI drivers, only the 1.3.
Last edited by Broke4speed; Jun 10, 2014 at 03:03 AM.
#70
Silver Sponsor
iTrader: (-1)
@Tjung the ftdi drivers are actually very simple to uninstall/reinstall. there is a program on the ftdi website called FTDIclean. which all it does is uninstall the driver from device manager and deletes the .ini file from the windows/inf folder.
@broke4speed the issue is very simple.. it has to do with the J2534 firmware 1.15.4126, it now returns code16 when there is a timeout. it used to return code9 timeout. it seems like ecuflash v1.44 because v1.44 distributes J2534 firmware 1.15.4126 to your openport 2.0 hardware automatically when you start it and plug in the openport2.0, I'm fairly sure going back to an earlier ecuflash will have no effect. Either way a timeout is a timeout, it ain't gonna help return a DTC code in any case. EvoScan v2.6 had a good DTC codebase. Since then more vehicle support has been added to the DTC, and created a bug by mistake in v2.9. I am working on a DTC op2 bug fix this week.
it must be a timing issue, because the same DTC code is used for openport 1.3U and it is fine. I know the 1.3U is faster at about 180 samples per second and the openport 2.0 about 110samples per second. it could be that. I'll find a work around. I'll keep you posted. -Hamish.
@broke4speed the issue is very simple.. it has to do with the J2534 firmware 1.15.4126, it now returns code16 when there is a timeout. it used to return code9 timeout. it seems like ecuflash v1.44 because v1.44 distributes J2534 firmware 1.15.4126 to your openport 2.0 hardware automatically when you start it and plug in the openport2.0, I'm fairly sure going back to an earlier ecuflash will have no effect. Either way a timeout is a timeout, it ain't gonna help return a DTC code in any case. EvoScan v2.6 had a good DTC codebase. Since then more vehicle support has been added to the DTC, and created a bug by mistake in v2.9. I am working on a DTC op2 bug fix this week.
it must be a timing issue, because the same DTC code is used for openport 1.3U and it is fine. I know the 1.3U is faster at about 180 samples per second and the openport 2.0 about 110samples per second. it could be that. I'll find a work around. I'll keep you posted. -Hamish.
#71
Evolving Member
@Tjung the ftdi drivers are actually very simple to uninstall/reinstall. there is a program on the ftdi website called FTDIclean. which all it does is uninstall the driver from device manager and deletes the .ini file from the windows/inf folder.
@broke4speed the issue is very simple.. it has to do with the J2534 firmware 1.15.4126, it now returns code16 when there is a timeout. it used to return code9 timeout. it seems like ecuflash v1.44 because v1.44 distributes J2534 firmware 1.15.4126 to your openport 2.0 hardware automatically when you start it and plug in the openport2.0, I'm fairly sure going back to an earlier ecuflash will have no effect. Either way a timeout is a timeout, it ain't gonna help return a DTC code in any case. EvoScan v2.6 had a good DTC codebase. Since then more vehicle support has been added to the DTC, and created a bug by mistake in v2.9. I am working on a DTC op2 bug fix this week.
it must be a timing issue, because the same DTC code is used for openport 1.3U and it is fine. I know the 1.3U is faster at about 180 samples per second and the openport 2.0 about 110samples per second. it could be that. I'll find a work around. I'll keep you posted. -Hamish.
@broke4speed the issue is very simple.. it has to do with the J2534 firmware 1.15.4126, it now returns code16 when there is a timeout. it used to return code9 timeout. it seems like ecuflash v1.44 because v1.44 distributes J2534 firmware 1.15.4126 to your openport 2.0 hardware automatically when you start it and plug in the openport2.0, I'm fairly sure going back to an earlier ecuflash will have no effect. Either way a timeout is a timeout, it ain't gonna help return a DTC code in any case. EvoScan v2.6 had a good DTC codebase. Since then more vehicle support has been added to the DTC, and created a bug by mistake in v2.9. I am working on a DTC op2 bug fix this week.
it must be a timing issue, because the same DTC code is used for openport 1.3U and it is fine. I know the 1.3U is faster at about 180 samples per second and the openport 2.0 about 110samples per second. it could be that. I'll find a work around. I'll keep you posted. -Hamish.
#72
Evolved Member
iTrader: (10)
Join Date: Mar 2013
Location: Chicago
Posts: 890
Likes: 0
Received 0 Likes
on
0 Posts
See I told you that he was working on fixing it right now thanks Hamish. There's a ton of time that goes into fixing this on his part and I am very appreciative of his efforts. I also know there are a ton of people with 2.0 cables that use evoscan with their pre-X Evo's that are going to really appreciate this update as well. Shoot, if he can make my openport 2.0 live tune as well (like the 1.3 cable does) I would even be willing to pay for evoscan again lol. "Hint Hint Hamish"
Last edited by jrainwater; Jun 10, 2014 at 12:25 PM.
#73
Evolving Member
Join Date: Sep 2012
Location: Ottawa, Ontario, Canada
Posts: 181
Likes: 0
Received 0 Likes
on
0 Posts
@Tjung the ftdi drivers are actually very simple to uninstall/reinstall. there is a program on the ftdi website called FTDIclean. which all it does is uninstall the driver from device manager and deletes the .ini file from the windows/inf folder.
@broke4speed the issue is very simple.. it has to do with the J2534 firmware 1.15.4126, it now returns code16 when there is a timeout. it used to return code9 timeout. it seems like ecuflash v1.44 because v1.44 distributes J2534 firmware 1.15.4126 to your openport 2.0 hardware automatically when you start it and plug in the openport2.0, I'm fairly sure going back to an earlier ecuflash will have no effect. Either way a timeout is a timeout, it ain't gonna help return a DTC code in any case. EvoScan v2.6 had a good DTC codebase. Since then more vehicle support has been added to the DTC, and created a bug by mistake in v2.9. I am working on a DTC op2 bug fix this week.
it must be a timing issue, because the same DTC code is used for openport 1.3U and it is fine. I know the 1.3U is faster at about 180 samples per second and the openport 2.0 about 110samples per second. it could be that. I'll find a work around. I'll keep you posted. -Hamish.
@broke4speed the issue is very simple.. it has to do with the J2534 firmware 1.15.4126, it now returns code16 when there is a timeout. it used to return code9 timeout. it seems like ecuflash v1.44 because v1.44 distributes J2534 firmware 1.15.4126 to your openport 2.0 hardware automatically when you start it and plug in the openport2.0, I'm fairly sure going back to an earlier ecuflash will have no effect. Either way a timeout is a timeout, it ain't gonna help return a DTC code in any case. EvoScan v2.6 had a good DTC codebase. Since then more vehicle support has been added to the DTC, and created a bug by mistake in v2.9. I am working on a DTC op2 bug fix this week.
it must be a timing issue, because the same DTC code is used for openport 1.3U and it is fine. I know the 1.3U is faster at about 180 samples per second and the openport 2.0 about 110samples per second. it could be that. I'll find a work around. I'll keep you posted. -Hamish.
#74
Evolved Member
iTrader: (10)
Join Date: Mar 2013
Location: Chicago
Posts: 890
Likes: 0
Received 0 Likes
on
0 Posts
I don't know if Hamish wants his personal business aired in public and if not I apologize before hand but in his defense he does have a newborn baby at home right now, someone reliable told me that little tid-bit. And he is choosing right now to finally fix this issue because of this thread that I started back up if I had to guess why its finally happening. He wants to make it work, he has the know-how and the knowledge to make it happen AND he is dealing with a newborn baby on top of everything else so let's give him some time and I feel pretty confident from the emails he has been sending me that he is going to finally fix this issue. I've even received a beta copy that fixed the j2534 timeout error but was having difficulty communicating with the ecu. I'm pretty sure he is close but since I know he is working on it I'm going to be patient for now
#75
Evolved Member
iTrader: (22)
I wish it was that simple. If it was Hamish wouldn't be rewriting evoscan to work with the new 2.0 firmware, it isn't the driver itself. It's the firmware and the way evoscan recognizes the firmware that causes the j2534 driver to error. I don't see how using 1.42 changes the hardware's firmware, because it doesn't.
Last edited by codgi; Jun 10, 2014 at 10:53 PM.