TunerPro RT data errors
08-14-2016, 09:15 PM
#1
Drifting
Thread Starter
TunerPro RT data errors
I've been trying to datalog from TunerPro RT, and I am having no end of trouble. I have datalogged with both DataMaster and ALDLDroid in the past; it took a bit of tweaking to get both to work, but my only real problem was finding datastream definition (ADX file) that worked correctly: one modified to include a macro that silenced CCM chatter.
On TunerPro however, even connecting to my ALDL bluetooth adapter is proving a challenge. For whatever reason, sometimes TunerPro will fail to recognize the COM port the adapter is connected through, requiring a restart. But that's not such a big deal since it's simple to fix. My biggest problem is that no matter what ADX I use, the datastream turns into nothing but errors about 8 seconds in (I get "DA: datastream error" or something like that from TunerPro, and my data turns into nonsense). It's odd though, because the data I get up until that point is flawless.
I have tried using CaptainKawasaki's modified ADX which includes the CCM silence macro, found here, I have tried using TunerPro's suggested ADX, found here, and I have tried modifying the TunerPro ADX in the manner suggested here. I have also modified CaptainKawasaki's ADX to increase the repetition count of the silence macro from 10 to 20 and have changed the baud of each ADX from 8192, which worked previously, to 9600, which the maker of my ALDL adapter suggests here. Lastly, I have tried starting datalogging with each ADX (and modification thereof) with key on and engine off as well as with key on and engine running.
My car is a '90 ZF6 coupe base model, and it has the 1227727 ECM. I don't believe this is pertinent, but I am using the Moates Ostrich 2.0 for tuning. I'd be interested to know if anyone has encountered and hopefully solved similar issues, or if not, if someone who has successfully datalogged a C4 like mine could send me the ADX that worked for them.
On TunerPro however, even connecting to my ALDL bluetooth adapter is proving a challenge. For whatever reason, sometimes TunerPro will fail to recognize the COM port the adapter is connected through, requiring a restart. But that's not such a big deal since it's simple to fix. My biggest problem is that no matter what ADX I use, the datastream turns into nothing but errors about 8 seconds in (I get "DA: datastream error" or something like that from TunerPro, and my data turns into nonsense). It's odd though, because the data I get up until that point is flawless.
I have tried using CaptainKawasaki's modified ADX which includes the CCM silence macro, found here, I have tried using TunerPro's suggested ADX, found here, and I have tried modifying the TunerPro ADX in the manner suggested here. I have also modified CaptainKawasaki's ADX to increase the repetition count of the silence macro from 10 to 20 and have changed the baud of each ADX from 8192, which worked previously, to 9600, which the maker of my ALDL adapter suggests here. Lastly, I have tried starting datalogging with each ADX (and modification thereof) with key on and engine off as well as with key on and engine running.
My car is a '90 ZF6 coupe base model, and it has the 1227727 ECM. I don't believe this is pertinent, but I am using the Moates Ostrich 2.0 for tuning. I'd be interested to know if anyone has encountered and hopefully solved similar issues, or if not, if someone who has successfully datalogged a C4 like mine could send me the ADX that worked for them.
Last edited by C4ProjectCar; 08-14-2016 at 09:15 PM.
08-14-2016, 11:12 PM
#2
Advanced
I don't have any experience with those specific files or that pcm. But I would rather try changing the delay settings between the requests instead of changing the repetition count, Perhaps even drop the rep to 1. As they are, the silence routines (CCM and ABS) are running 50 times (5 each in the routine, times 10). That seems like a wild guess at what should work. The best method would be to examine the signals with a scope and determine the optimal delay/spacing settings to get at least one silence request sent in the clear.
08-15-2016, 12:29 PM
#3
Race Director
Use the ADX from ALDLDroid, if that one works without issues on ALDLDroid, it will work on TunerPro.. I have been able to get my car 1990 ZR-1 to work with ALDLDroid and I have not had the chance to try my PC and Tunerpro, but I do find that the Bluetooth can be a bit finicky with my set-up
Last edited by -=Jeff=-; 08-15-2016 at 12:29 PM.
08-15-2016, 01:03 PM
#4
Advanced
Keep in mind that ALDLdroid is meant to be used with Android, various versions and device speeds. TunerPro RT is meant to be used with a pc, again with various operating systems and certainly many computer speeds. The difficult part of dealing with time-critical operations, like the silencing requests, is in dealing with a lot of different speeds in the communication, most of which are beyond the control of the application or user. I don't think it is safe to say that one config file will always work on another type of system when timing is critical.
In my experience, it has been Android that has the faster and more efficient Bluetooth operation, not Windows. I would however expect a wired cable connection to be more compatible between systems.
In my experience, it has been Android that has the faster and more efficient Bluetooth operation, not Windows. I would however expect a wired cable connection to be more compatible between systems.
Last edited by GaryDoug; 08-15-2016 at 01:05 PM.
08-15-2016, 09:32 PM
#5
Drifting
Thread Starter
I don't have any experience with those specific files or that pcm. But I would rather try changing the delay settings between the requests instead of changing the repetition count, Perhaps even drop the rep to 1. As they are, the silence routines (CCM and ABS) are running 50 times (5 each in the routine, times 10). That seems like a wild guess at what should work. The best method would be to examine the signals with a scope and determine the optimal delay/spacing settings to get at least one silence request sent in the clear.
The weird thing is, when I try to connect with an ADX without the silence macro it fails right away. So it's like the silence macro is working but only for a little bit.
Use the ADX from ALDLDroid, if that one works without issues on ALDLDroid, it will work on TunerPro.. I have been able to get my car 1990 ZR-1 to work with ALDLDroid and I have not had the chance to try my PC and Tunerpro, but I do find that the Bluetooth can be a bit finicky with my set-up
Keep in mind that ALDLdroid is meant to be used with Android, various versions and device speeds. TunerPro RT is meant to be used with a pc, again with various operating systems and certainly many computer speeds. The difficult part of dealing with time-critical operations, like the silencing requests, is in dealing with a lot of different speeds in the communication, most of which are beyond the control of the application or user. I don't think it is safe to say that one config file will always work on another type of system when timing is critical.
In my experience, it has been Android that has the faster and more efficient Bluetooth operation, not Windows. I would however expect a wired cable connection to be more compatible between systems.
In my experience, it has been Android that has the faster and more efficient Bluetooth operation, not Windows. I would however expect a wired cable connection to be more compatible between systems.
08-16-2016, 01:52 AM
#8
Race Director
I had occasional connection issues with TunerPro using a cable purchased from ALDL.com. After a few years, I bought a 2nd-hand cable (that I THINK came from Moates). It worked OK every time.
EDIT: I have an 89 and use version 4.14. I just looked and that version uses an ADS file. I see the MAP cars (90-91) require an ADX file with software version 5. That said, a check sum error is typically an error in communication that have me looking at the cable (or bluetooth driver) being used.
I suppose it's even possible that you have a loose wire/pin in your ALDL port.
EDIT: I have an 89 and use version 4.14. I just looked and that version uses an ADS file. I see the MAP cars (90-91) require an ADX file with software version 5. That said, a check sum error is typically an error in communication that have me looking at the cable (or bluetooth driver) being used.
I suppose it's even possible that you have a loose wire/pin in your ALDL port.
Last edited by GREGGPENN; 08-16-2016 at 02:00 AM.
08-16-2016, 02:12 AM
#9
Does this have something to do with the dataloging computer losing signal? i.e. it randomly quits receiving data forcing you to restart the dataloging everytime? I hate having to datalog as the laptop randomly quits receiving data and it gets annoying having to pull over and restart the datalog say 4 times just to get a 15 minute datalog. I know others have this problem, but don't if that has anything to do with your problem.
08-16-2016, 08:35 AM
#10
Thanks for your post. I have been trying for 3 years to get Tuner Pro RT running on my 95. Probably 90% of the time, I just get DA Errors. then once in a great while I will get a solid connection and good data. I have seen it run for 2 hrs with no errors. Then go days with errors. So maybe its my cable I bought from ALDL.com or a bad connection on the ALDL port. I am not a electronics guy, so I have trouble with these issues.
Thank You
8Valve
Thank You
8Valve
I had occasional connection issues with TunerPro using a cable purchased from ALDL.com. After a few years, I bought a 2nd-hand cable (that I THINK came from Moates). It worked OK every time.
EDIT: I have an 89 and use version 4.14. I just looked and that version uses an ADS file. I see the MAP cars (90-91) require an ADX file with software version 5. That said, a check sum error is typically an error in communication that have me looking at the cable (or bluetooth driver) being used.
I suppose it's even possible that you have a loose wire/pin in your ALDL port.
EDIT: I have an 89 and use version 4.14. I just looked and that version uses an ADS file. I see the MAP cars (90-91) require an ADX file with software version 5. That said, a check sum error is typically an error in communication that have me looking at the cable (or bluetooth driver) being used.
I suppose it's even possible that you have a loose wire/pin in your ALDL port.
08-16-2016, 03:08 PM
#11
Race Director
Data is essentially transmitted in numbers. Everything is "coded" from letters to numbers....then back on the other end. So, there are multiple steps where data can be jacked up in translation/transportation. To assure it was sent correctly, a sum of bits/digits is performed after each "packet" of information is sent. When received the sent count is compared to the received count. If they don't match, you have a "checksum" error.
When that happens, the controlling software (application) throws a checksum error letting you know you had a communication error. The goal is to identify the cause before you retransmit.
In the case of datalogging, check cables and/or the ALDL port. I do remember at least one person that had issues with the port itself. Because they aren't that different than your standard "weatherpac" plugs, they are possible to fix.
08-16-2016, 03:40 PM
#12
Any time you are transferring data from one place to another (whether it be across a simple cable or miles of internet), there is a transfer protocol in place. On the internet, you're concerned about security. On anything, you are also concerned about the accuracy of data transmitted.
Data is essentially transmitted in numbers. Everything is "coded" from letters to numbers....then back on the other end. So, there are multiple steps where data can be jacked up in translation/transportation. To assure it was sent correctly, a sum of bits/digits is performed after each "packet" of information is sent. When received the sent count is compared to the received count. If they don't match, you have a "checksum" error.
When that happens, the controlling software (application) throws a checksum error letting you know you had a communication error. The goal is to identify the cause before you retransmit.
In the case of datalogging, check cables and/or the ALDL port. I do remember at least one person that had issues with the port itself. Because they aren't that different than your standard "weatherpac" plugs, they are possible to fix.
Data is essentially transmitted in numbers. Everything is "coded" from letters to numbers....then back on the other end. So, there are multiple steps where data can be jacked up in translation/transportation. To assure it was sent correctly, a sum of bits/digits is performed after each "packet" of information is sent. When received the sent count is compared to the received count. If they don't match, you have a "checksum" error.
When that happens, the controlling software (application) throws a checksum error letting you know you had a communication error. The goal is to identify the cause before you retransmit.
In the case of datalogging, check cables and/or the ALDL port. I do remember at least one person that had issues with the port itself. Because they aren't that different than your standard "weatherpac" plugs, they are possible to fix.
I've read the problem is with the computer in the car, and that they'll all do it at some point or another. i.e. random, some people have more trouble than others. Supposedly this is mostly commented on the 1227165 computer.
08-16-2016, 06:26 PM
#13
Drifting
Thread Starter
Alright, I tried to mess around with the ADX to get it to work, but without being able to find any documentation of whatever language they are programmed in I wasn't able to tweak much and wasn't able to make any progress.
I'm leaning toward a cable issue too. I've noticed a few quirks with TunerPro and bluetooth in other areas, so if I don't figure out a different solution I'll buy a USB ALDL cable and hope that works.
I suppose it could be a driver problem, but the fact that I have successfully used DataMaster with this cable in the past suggests otherwise. Also, I believe these errors are not from packet loss, but are instead from the CCM chatter. As I understand it, the silence macro runs at the beginning of the ADX to make the CCM stop communicating over the ALDL port, then it repeats the silence command every so often as the datastream is being accessed. I think the repeated silence commands are not going through for some reason.
Nope, it just throws errors within seconds of connecting. Although I think I have had it randomly disconnect like that in the past.
Interesting. Is your C4 one of the years ('90 or '91, I believe) that required the CCM silence macro in the ADX?
I think the issue is something like the ECM transmits some data to the ALDL port, but in the middle of the burst of ECM data the CCM also sends some data. So when TunerPro compares the checksum to the data, it finds they don't match because there's extra data.
I had occasional connection issues with TunerPro using a cable purchased from ALDL.com. After a few years, I bought a 2nd-hand cable (that I THINK came from Moates). It worked OK every time.
EDIT: I have an 89 and use version 4.14. I just looked and that version uses an ADS file. I see the MAP cars (90-91) require an ADX file with software version 5. That said, a check sum error is typically an error in communication that have me looking at the cable (or bluetooth driver) being used.
I suppose it's even possible that you have a loose wire/pin in your ALDL port.
EDIT: I have an 89 and use version 4.14. I just looked and that version uses an ADS file. I see the MAP cars (90-91) require an ADX file with software version 5. That said, a check sum error is typically an error in communication that have me looking at the cable (or bluetooth driver) being used.
I suppose it's even possible that you have a loose wire/pin in your ALDL port.
I suppose it could be a driver problem, but the fact that I have successfully used DataMaster with this cable in the past suggests otherwise. Also, I believe these errors are not from packet loss, but are instead from the CCM chatter. As I understand it, the silence macro runs at the beginning of the ADX to make the CCM stop communicating over the ALDL port, then it repeats the silence command every so often as the datastream is being accessed. I think the repeated silence commands are not going through for some reason.
Does this have something to do with the dataloging computer losing signal? i.e. it randomly quits receiving data forcing you to restart the dataloging everytime? I hate having to datalog as the laptop randomly quits receiving data and it gets annoying having to pull over and restart the datalog say 4 times just to get a 15 minute datalog. I know others have this problem, but don't if that has anything to do with your problem.
Thanks for your post. I have been trying for 3 years to get Tuner Pro RT running on my 95. Probably 90% of the time, I just get DA Errors. then once in a great while I will get a solid connection and good data. I have seen it run for 2 hrs with no errors. Then go days with errors. So maybe its my cable I bought from ALDL.com or a bad connection on the ALDL port. I am not a electronics guy, so I have trouble with these issues.
Thank You
8Valve
Thank You
8Valve
Any time you are transferring data from one place to another (whether it be across a simple cable or miles of internet), there is a transfer protocol in place. On the internet, you're concerned about security. On anything, you are also concerned about the accuracy of data transmitted.
Data is essentially transmitted in numbers. Everything is "coded" from letters to numbers....then back on the other end. So, there are multiple steps where data can be jacked up in translation/transportation. To assure it was sent correctly, a sum of bits/digits is performed after each "packet" of information is sent. When received the sent count is compared to the received count. If they don't match, you have a "checksum" error.
When that happens, the controlling software (application) throws a checksum error letting you know you had a communication error. The goal is to identify the cause before you retransmit.
In the case of datalogging, check cables and/or the ALDL port. I do remember at least one person that had issues with the port itself. Because they aren't that different than your standard "weatherpac" plugs, they are possible to fix.
Data is essentially transmitted in numbers. Everything is "coded" from letters to numbers....then back on the other end. So, there are multiple steps where data can be jacked up in translation/transportation. To assure it was sent correctly, a sum of bits/digits is performed after each "packet" of information is sent. When received the sent count is compared to the received count. If they don't match, you have a "checksum" error.
When that happens, the controlling software (application) throws a checksum error letting you know you had a communication error. The goal is to identify the cause before you retransmit.
In the case of datalogging, check cables and/or the ALDL port. I do remember at least one person that had issues with the port itself. Because they aren't that different than your standard "weatherpac" plugs, they are possible to fix.
08-16-2016, 10:23 PM
#14
Advanced
Alright, I tried to mess around with the ADX to get it to work, but without being able to find any documentation of whatever language they are programmed in I wasn't able to tweak much and wasn't able to make any progress.
...
I think the issue is something like the ECM transmits some data to the ALDL port, but in the middle of the burst of ECM data the CCM also sends some data. So when TunerPro compares the checksum to the data, it finds they don't match because there's extra data.
...
I think the issue is something like the ECM transmits some data to the ALDL port, but in the middle of the burst of ECM data the CCM also sends some data. So when TunerPro compares the checksum to the data, it finds they don't match because there's extra data.
The ECM and CCM are designed to work together, so there should be no conflicts in the data that either send. The more likely conflict would be in the request from the pc and the CCM or ABS. Try unplugging the ABS controller and see if you have the same issues. If possible, try unplugging the CCM also. Another test is to measure the voltage at the data pin in the DLC. It should be well over 2.5 volts dc with some slight variations as the modules transmit their "housekeeping" data. If it's lower, you may have a defective module. How long has it been since you successfully used other software? Can you still try that now?
Last edited by GaryDoug; 08-16-2016 at 10:26 PM.
08-17-2016, 01:41 PM
#16
Le Mans Master
Member Since: Oct 2002
Location: Las Vegas - Just stop perpetuating myths please.
Posts: 7,098
Received 373 Likes
on
356 Posts
Keep in mind that ALDLdroid is meant to be used with Android, various versions and device speeds. TunerPro RT is meant to be used with a pc, again with various operating systems and certainly many computer speeds. The difficult part of dealing with time-critical operations, like the silencing requests, is in dealing with a lot of different speeds in the communication, most of which are beyond the control of the application or user. I don't think it is safe to say that one config file will always work on another type of system when timing is critical.
In my experience, it has been Android that has the faster and more efficient Bluetooth operation, not Windows. I would however expect a wired cable connection to be more compatible between systems.
In my experience, it has been Android that has the faster and more efficient Bluetooth operation, not Windows. I would however expect a wired cable connection to be more compatible between systems.
Thanks for the advice. Unfortunately, I don't have an oscilloscope, but I'll see if messing around with the timing works.
The weird thing is, when I try to connect with an ADX without the silence macro it fails right away. So it's like the silence macro is working but only for a little bit.
I did; that was the one with the silence macro. It still works with ALDLDroid (haven't tried DataMaster since it's not available) but fails when using TunerPro.
That makes perfect sense. I was hoping it wouldn't come down to a hardware issue. Unfortunately, I only have a few more days to work on my car before I fly back to college, so I wouldn't be able to deal with this until Christmas break. Hopefully tweaking the ADX will get me somewhere.
The weird thing is, when I try to connect with an ADX without the silence macro it fails right away. So it's like the silence macro is working but only for a little bit.
I did; that was the one with the silence macro. It still works with ALDLDroid (haven't tried DataMaster since it's not available) but fails when using TunerPro.
That makes perfect sense. I was hoping it wouldn't come down to a hardware issue. Unfortunately, I only have a few more days to work on my car before I fly back to college, so I wouldn't be able to deal with this until Christmas break. Hopefully tweaking the ADX will get me somewhere.
Looking at the TunerPro w/s it was developed on WIN32x system though they do say it supports 64x hardware. If you want 32x equipment you have to shop for an older DELL Latitude laptop and it should have the legacy RS232 port also. Or buy Tuner CATS tuning program which I believe is 64x compatible for your car. So I went ahead w/tuner CATS and new touch screen WIN10 laptop.
But scrounge around as sometimes owners are ready to throw out their old laptops.
To bad your not nearby as I bought 2 matching Latitude's at local swap meet but found out my tuner CATS is 64x compatible. I am interested in seeing how well the older hardware work's for this and feed my tuning obsession.
The USB 2.0 to the old 12 pin ALDL connector is still available but $60 and making your own requires a serial converter.
08-24-2016, 05:41 PM
#17
Drifting
Thread Starter
I kept trying to post this before my vacation but CF wouldn't submit it. Apparently one of my links flat-out broke the submission form? No error message or anything. Anyway, I didn't have time to try to sort out the errors before vacation, and I fly back out to VA for college Friday morning. I won't be able to deal with this until Christmas break, but hopefully then I can get datalogging working.
Although I'm not a professional programmer, to me it seems clear that the ADX is written in some kind of programming language. There is certainly syntax,, there are functions, and it would seem to a certain extent objects. Regardless, I'm unable to find any documentation of ADX commands to help me understand and modify the ADX file.
I know very little about the way the car's different computers communicate, but the best I can tell from what I've read is that on '90 and '91 cars, communications from the CCM, ABS, and ECM systems are output to the ALDL port, even when only ECM data is requested. From my experience, the datastream will not even initialize without the macro to silence the other systems.
But unplugging those other computers is an interesting idea. Maybe that can get me off the ground.
I assume DLC means data link cable? Mine is a bluetooth cable, so I can't test the voltage there, but I can check it under the dash. It has been about 8 months since I last datalogged from my computer, but I successfully logged using ALDLDroid on my phone just the other day. In retrospect, though, I may have seen it was working and disconnected before the end of the period (about 10 seconds) in which it normally starts throwing errors. I'm going to be out of town most of tomorrow (/today, the 17th), but I should be able to give logging from my phone another shot in the evening.
Yeah, that would be great! Here are the two links for the ADX files that datalog successfully for a few seconds. I believe the first should download when you click the link, but you will have to right-click on the second and choose "save link as" to download it.
https://1drv.ms/u/s!Au8kgRqvOvFBg4BmG-DtFE5KlyaKGQ
http://www.tunerpro.net/download/dat...1_Corvette.adx
Well that's a pain. Hopefully it's just an issue with using bluetooth and a regular USB cable will sort things out.
The programming language doesn't matter because it's the executable file (the one you use) that matters and that's just plain binary. The ADX file is just the text that the exe file uses as input, again no lanis involved.
The ECM and CCM are designed to work together, so there should be no conflicts in the data that either send. The more likely conflict would be in the request from the pc and the CCM or ABS. Try unplugging the ABS controller and see if you have the same issues. If possible, try unplugging the CCM also. Another test is to measure the voltage at the data pin in the DLC. It should be well over 2.5 volts dc with some slight variations as the modules transmit their "housekeeping" data. If it's lower, you may have a defective module. How long has it been since you successfully used other software? Can you still try that now?
The ECM and CCM are designed to work together, so there should be no conflicts in the data that either send. The more likely conflict would be in the request from the pc and the CCM or ABS. Try unplugging the ABS controller and see if you have the same issues. If possible, try unplugging the CCM also. Another test is to measure the voltage at the data pin in the DLC. It should be well over 2.5 volts dc with some slight variations as the modules transmit their "housekeeping" data. If it's lower, you may have a defective module. How long has it been since you successfully used other software? Can you still try that now?
I know very little about the way the car's different computers communicate, but the best I can tell from what I've read is that on '90 and '91 cars, communications from the CCM, ABS, and ECM systems are output to the ALDL port, even when only ECM data is requested. From my experience, the datastream will not even initialize without the macro to silence the other systems.
But unplugging those other computers is an interesting idea. Maybe that can get me off the ground.
I assume DLC means data link cable? Mine is a bluetooth cable, so I can't test the voltage there, but I can check it under the dash. It has been about 8 months since I last datalogged from my computer, but I successfully logged using ALDLDroid on my phone just the other day. In retrospect, though, I may have seen it was working and disconnected before the end of the period (about 10 seconds) in which it normally starts throwing errors. I'm going to be out of town most of tomorrow (/today, the 17th), but I should be able to give logging from my phone another shot in the evening.
Yeah, that would be great! Here are the two links for the ADX files that datalog successfully for a few seconds. I believe the first should download when you click the link, but you will have to right-click on the second and choose "save link as" to download it.
https://1drv.ms/u/s!Au8kgRqvOvFBg4BmG-DtFE5KlyaKGQ
http://www.tunerpro.net/download/dat...1_Corvette.adx
The programming language doesn't matter because it's the executable file (the one you use) that matters and that's just plain binary. The ADX file is just the text that the exe file uses as input, again no language is involved.
The ECM and CCM are designed to work together, so there should be no conflicts in the data that either send. The more likely conflict would be in the request from the pc and the CCM or ABS. Try unplugging the ABS controller and see if you have the same issues. If possible, try unplugging the CCM also. Another test is to measure the voltage at the data pin in the DLC. It should be well over 2.5 volts dc with some slight variations as the modules transmit their "housekeeping" data. If it's lower, you may have a defective module. How long has it been since you successfully used other software? Can you still try that now?
The ECM and CCM are designed to work together, so there should be no conflicts in the data that either send. The more likely conflict would be in the request from the pc and the CCM or ABS. Try unplugging the ABS controller and see if you have the same issues. If possible, try unplugging the CCM also. Another test is to measure the voltage at the data pin in the DLC. It should be well over 2.5 volts dc with some slight variations as the modules transmit their "housekeeping" data. If it's lower, you may have a defective module. How long has it been since you successfully used other software? Can you still try that now?
Looking at the TunerPro w/s it was developed on WIN32x system though they do say it supports 64x hardware. If you want 32x equipment you have to shop for an older DELL Latitude laptop and it should have the legacy RS232 port also. Or buy Tuner CATS tuning program which I believe is 64x compatible for your car. So I went ahead w/tuner CATS and new touch screen WIN10 laptop.
But scrounge around as sometimes owners are ready to throw out their old laptops.
To bad your not nearby as I bought 2 matching Latitude's at local swap meet but found out my tuner CATS is 64x compatible. I am interested in seeing how well the older hardware work's for this and feed my tuning obsession. The USB 2.0 to the old 12 pin ALDL connector is still available but $60 and making your own requires a serial converter.
But scrounge around as sometimes owners are ready to throw out their old laptops.
To bad your not nearby as I bought 2 matching Latitude's at local swap meet but found out my tuner CATS is 64x compatible. I am interested in seeing how well the older hardware work's for this and feed my tuning obsession.
The USB 2.0 to the old 12 pin ALDL connector is still available but $60 and making your own requires a serial converter.Last edited by C4ProjectCar; 08-24-2016 at 05:47 PM.
08-24-2016, 09:50 PM
#18
Race Director
Sounds like the CCM is not going quiet. I looked at the connect command and it looks fine..
I wonder if the connect needs to run more times to silence the CCM prior to datalogging
I wonder if the connect needs to run more times to silence the CCM prior to datalogging
08-24-2016, 11:05 PM
#19
Advanced
I came across another user having comms problems with his f-car. The fault was with the ABS module having a defective 5v internal supply regulator. It was putting out over 8 volts and pulling up the data line strongly. Did you measure the voltage at the DLC (data link connector in the car) as I suggested above? No cable connection is required for this measurement.