TunerPro RT data errors
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; Aug 14, 2016 at 09:15 PM.
Last edited by -=Jeff=-; Aug 15, 2016 at 12:29 PM.
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; Aug 15, 2016 at 01:05 PM.
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.
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.










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; Aug 16, 2016 at 02:00 AM.
The Best of Corvette for Corvette Enthusiasts
Thank You
8Valve
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.





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.
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.
Thank You
8Valve
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 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; Aug 16, 2016 at 10:26 PM.


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.
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.
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 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?
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; Aug 24, 2016 at 05:47 PM.











