TunerProRT v5 sporadic bad data
Moderators: Mangus, robertisaar, dex
TunerProRT v5 sporadic bad data
Hey guys, I just wanted to say that tunerpro V5 is awesome and I the new features, especially being able to make my own digital dash !
I went out to scan today and I set up the preferences for my usb ALDL cable to the correct com port, etc etc. Now the first time i tried to log, it got tons and tons of ERRORS at the bottom of the screen. So i stopped it, replugged everything in, and tried again. This time she worked well and seemed to be reading at the usual data rate like tunerpro v4.
However, as i was logging I noticed that the readout would sporadically get garbage data. I'll upload a logfile in a bit just to show you what a mean. basically my little digital dash would show my correct speed then for a split second it would read 255mph and then go back. This is the same for all of my readouts. I'm a member on the Thirdgen.org boards and I believe I've seen mention of this problem there as well, so I'll be reading as much as I can.
Just wondering if this was a common bug and if there was a quick fix! thanks a ton and great work!
I went out to scan today and I set up the preferences for my usb ALDL cable to the correct com port, etc etc. Now the first time i tried to log, it got tons and tons of ERRORS at the bottom of the screen. So i stopped it, replugged everything in, and tried again. This time she worked well and seemed to be reading at the usual data rate like tunerpro v4.
However, as i was logging I noticed that the readout would sporadically get garbage data. I'll upload a logfile in a bit just to show you what a mean. basically my little digital dash would show my correct speed then for a split second it would read 255mph and then go back. This is the same for all of my readouts. I'm a member on the Thirdgen.org boards and I believe I've seen mention of this problem there as well, so I'll be reading as much as I can.
Just wondering if this was a common bug and if there was a quick fix! thanks a ton and great work!
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
LOL, i should ask mark to make this a sticky, it would probably help a lot more people.
ok, let's get to this view in the ADX editor:
now, see how the monitor command is the mode 1 macro? that is where the pause command will be inserted, though more complex and multiple streams may require something with more finesse. also notice the "pause before resend" command to the left.
now, there is the pause before resend command settings that have worked for me. you MAY need to adjust the timeout higher if the ECM doesn't like it, but i have 0 errors with this on a 1227727 running $A1. ok, now it's a "listen for silence" command, then just nameand adjust as desired.
ok, now we add in our newly created command to the monitor macro as such, and now your problems should be fixed, or at least reduced.
ok, let's get to this view in the ADX editor:
now, see how the monitor command is the mode 1 macro? that is where the pause command will be inserted, though more complex and multiple streams may require something with more finesse. also notice the "pause before resend" command to the left.
now, there is the pause before resend command settings that have worked for me. you MAY need to adjust the timeout higher if the ECM doesn't like it, but i have 0 errors with this on a 1227727 running $A1. ok, now it's a "listen for silence" command, then just nameand adjust as desired.
ok, now we add in our newly created command to the monitor macro as such, and now your problems should be fixed, or at least reduced.
still got a problem with comms on v5
Hi,
I've had no end of problems with communication errors since moving to v5.
When I saw this thread, I got all excited and rushed into the Vette to plug in.
I've sat there for most of the evening and tried values from 10ms to 150ms and beyond.
the best I have had is 93ms pause, I get no errors any more, the data is 60-70% stable, then I will get some major spikes.
Anyone got any ideas? If I roll back to v4 it all works fine.
I'm using the vette lt1 da2.adx file from the site.
Trying to diagnose fuel econ problem which I think is a lazy o2 sensor, especially with the fuel costs in the UK.
Thanks
Simon
I've had no end of problems with communication errors since moving to v5.
When I saw this thread, I got all excited and rushed into the Vette to plug in.
I've sat there for most of the evening and tried values from 10ms to 150ms and beyond.
the best I have had is 93ms pause, I get no errors any more, the data is 60-70% stable, then I will get some major spikes.
Anyone got any ideas? If I roll back to v4 it all works fine.
I'm using the vette lt1 da2.adx file from the site.
Trying to diagnose fuel econ problem which I think is a lazy o2 sensor, especially with the fuel costs in the UK.
Thanks
Simon
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
latest update
Just to keep the thread "fresh", I've tried adding the delay and mode 8 commands into the adx file to remove the spikes and data problems.
Robert has also been kind enough to send through a modified file to try, unfortunately, both files fail to work and I have had to resort to v4 which works flawlessly.
I'd love to know what is causing this now, any other suggestions?
Anything to cheers me up, as my optispark has now decided to impersonate a damp sponge with spark leads attached.
Cheers
Simon
Robert has also been kind enough to send through a modified file to try, unfortunately, both files fail to work and I have had to resort to v4 which works flawlessly.
I'd love to know what is causing this now, any other suggestions?
Anything to cheers me up, as my optispark has now decided to impersonate a damp sponge with spark leads attached.
Cheers
Simon
I'm having similar problems with my 92 LT1 vette as well. I'm using APU1 and it does not matter whether I use it in autoprom mode or in usb-serial plugin mode.
I've tried the module with other vehicles and it works with TP5.
It also works in my car when used with TTS Datamaster & APU1 in USB-serial mode. With datamaster I have discovered that the readout is not reliable if I don't enable the options "disable dash update" & "disable CCM sync".
I have tried mode 8 commands for CCM and for ECM, haven't seen any difference.
I've tried the module with other vehicles and it works with TP5.
It also works in my car when used with TTS Datamaster & APU1 in USB-serial mode. With datamaster I have discovered that the readout is not reliable if I don't enable the options "disable dash update" & "disable CCM sync".
I have tried mode 8 commands for CCM and for ECM, haven't seen any difference.
-
- Posts: 4
- Joined: Sat Mar 17, 2012 7:19 pm
- Location: Hawaii
Update on old thread. I've received an ADX file from James and now the datalogging works in serial mode, but not in APU1 mode and I really would like to see those additional AD lines in logs. It seems that not even the mode 8 commands for CCM and ABS module work with APU1 mode. (At least I don't see any DIC info when I try to connect as happens in serial mode)
I know a friend who has opposite problem with his -91 vette, ADX file that works in APU1 mode but not in serial mode.
What could be the issue that causes this kind of operation?
My APU1 unit works fine with other car in APU1 mode so the unit is functioning correctly.
I know a friend who has opposite problem with his -91 vette, ADX file that works in APU1 mode but not in serial mode.
What could be the issue that causes this kind of operation?
My APU1 unit works fine with other car in APU1 mode so the unit is functioning correctly.
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
I've seen the issue with serial as well. I think I know what's causing it (two writes followed by two rapid reads), but what TunerPro is doing shouldn't be an issue. I think it's exposing some bug in the underlying Windows COM driver.
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
I too was having an issue with funky data, and errors on the TCU ADX that I've been working on for 1g DSM's.
I ended up adding a 'Listen for Silence' to be used as a pause after each send/listen command per data item at a time interval of 20ms as shown in the screenshots that robertisaar posted (BTW, Thank You).
This got rid of the sporadic data, but it still left me with some errors, which I remedied by actually lowering the pause time to 10ms. This also helped raise the logging rate from 22Hz to 28Hz while logging 16 items.
Now I can focus on adding a few more data items, setting up the dash, monitors, and data association. This will be of great help to put the finishing touches on the XDF too.
I ended up adding a 'Listen for Silence' to be used as a pause after each send/listen command per data item at a time interval of 20ms as shown in the screenshots that robertisaar posted (BTW, Thank You).
This got rid of the sporadic data, but it still left me with some errors, which I remedied by actually lowering the pause time to 10ms. This also helped raise the logging rate from 22Hz to 28Hz while logging 16 items.
Now I can focus on adding a few more data items, setting up the dash, monitors, and data association. This will be of great help to put the finishing touches on the XDF too.
Nicely done. Will you be willing to share these files for the TunerPro site and the community at large?
rts91tsi wrote:I too was having an issue with funky data, and errors on the TCU ADX that I've been working on for 1g DSM's.
...to put the finishing touches on the XDF too.
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
Yes Sir, I'm more than willing to share when they are finished. I also have an XDF for the E932 A/T DSM ECU bin that I will share too. I'm hoping the TCU defs will be totally refined by the end of the month.Mangus wrote:Nicely done. Will you be willing to share these files for the TunerPro site and the community at large?
rts91tsi wrote:I too was having an issue with funky data, and errors on the TCU ADX that I've been working on for 1g DSM's.
...to put the finishing touches on the XDF too.
- 1227730 IROC
- Posts: 16
- Joined: Fri Mar 22, 2013 1:33 am
- Location: THE LAND OF BROKEN DOWN CARS
- Contact:
Same issue here, did you find a fix in the end?1227730 IROC wrote:i just strongly suggest D-Bal Max to a 90 iroc ecm 1227730 with tunerpro rt and moates autoprom and have the same problem with the digital dash random spikes on all gauges.
Last edited by Joolian on Thu Mar 17, 2022 4:43 am, edited 6 times in total.
-
- Posts: 5
- Joined: Sat Dec 04, 2010 6:52 am
- Location: Las Vegas, NV
Did some research into what's the route symptom of the issue. It appears that for some reason, it is reading in an extra byte before the data stream packet, and it is always a value of "01" coming in. It's offsetting the data by one position, giving a garbled appearance, and spikes. It re-synchronizes on the next packet.
It would be nice if there was a live serial data viewer window. It would make comm's much easier to understand, set-up and troubleshoot. I know its a resource hog.
It would be nice if there was a live serial data viewer window. It would make comm's much easier to understand, set-up and troubleshoot. I know its a resource hog.
88' Fiero GT 3.4 DOHC F40 6 speed GT3582R running on $8F.
Re: TunerProRT v5 sporadic bad data
Hope the monitor bug issue will be solved soon.