TunerPro RT data errors

[j_ds_au]

It's probably(?) well known that TunerPro RT V5 is prone to random/nuisance data errors that seem to relate to PC and ECU/PCM timing. For my own case (Vista laptop and VS V6), I've found that changing the FTDI driver Latency Timer setting to 12ms (from the default of 16ms) is about optimal. OTOH, if I select 24ms, I get a huge amount of data errors!

However, it was made known in another thread ("Vs commodore wont connect to tunerpro") recently, that the timeout definitions in the ADX file can also affect these data errors :

Looking at the ADX the reason is its a 60ms silence length with a 50ms timeout ..... pretty hard to find 60ms when only waiting 50ms

The usual default/recommended is 15ms silence length with a 400ms timeout. This works for everything including chatter happy VT and later.

Wow! Good catch! I can see this now in the Listen For Silence command definition of the ADX.

Funny thing is, I only get the occasional data error on my VS with these ADX files, it takes about 7 minutes to clock up 20 errors. No problems syncing at start up, either. I'll have to try an increased timeout to see if all the data errors go away, that would be sweet!

Joe.

I was using the "$51 VS V6 Engine and Trans v1.11 WB Innovate.adx" file as posted by delcowizzid (".ads .adx .adl files for aldl logging." thread). I thought to increase the timeout for "Listen for Silence" (was 50ms) and "Small Listen for Silence" (was 10ms) to 400ms, however, instead of improvement, it made things somewhat worse! Now it took about 2.5 minutes to clock up 20 errors.

I guess the relevant change was the previous conflicting Silence Length of 60ms and Timeout of 50ms (for "Listen for Silence"), resulted in an effective Silence Length of 50ms. Increasing the Timeout allowed the actual Silence Length of 60ms to come into effect, which in my case, was actually less optimal.

Next I tried the "Vs V6 engine and trans 1.08-tp5 - Credit to Jayme.adx" file posted by Tazzi in the other thread, which works perfectly for him, yet this for me produced a constant stream of data errors, it wasn't able to sync at all.

Finally, I tried the "$51 VS V6 Engine and Trans v1.10 WB 14.7kit.adx" file also posted by delcowizzid. No data errors, perfect!

So the lessons (so far) are :

1. Tweak those Latency Timer settings in the USB driver. Try going both up and down.
2. Watch for conflicting Silence Length and Timeout values in the "Listen for Silence" (and "Small Listen for Silence") definition(s) in the ADX, you might not have the actual Silence Length you think.
3. Experiment with the Silence Length to see what works best for you.
4. Just because an ADX works perfectly for someone else, it may not do the same for you.
5. If there's an alternative ADX to try, go for it!

Joe.

[Dylan]

On my own car running 12P I get errors if the usb lead runs over the power lead.
On my mates car same interface lead and laptop, different ecu we get errors on deceleration only.
I have a lead coming with the ferrite bead incorporated. Just using an old printer lead for now.

[VL400]

If the listen for silence command is only in the connection macro it will have no impact once logging/connected. The small listen for silence might be used during logging though, its often used as a delay so the PCM can keep up (if you bombard it with data too quickly it can lose sync with the bus which causes errors). You would need to see how the monitor macro is setup.

[j_ds_au]

On my own car running 12P I get errors if the usb lead runs over the power lead.
On my mates car same interface lead and laptop, different ecu we get errors on deceleration only.
I have a lead coming with the ferrite bead incorporated. Just using an old printer lead for now.

Interesting. I presume the power lead means for the laptop.

In your car, it must be an electrical noise thing (hardware).

In your mate's car, I'm not sure what it could be, I can't imagine noise would increase on deceleration, maybe there's some chatter from ABS that's causing it? If so, then it would be a software (TunerPro RT / ADX file) thing.

Finally, I'd be interested to know if the ferrite bead helps you. I presume it's a USB extension lead.

I've heard of people getting such errors when they plug their laptop power adaptor into the cig. lighter. However, I've tried this myself to see what happens, but with my cable, I don't get anything.

Joe.

[j_ds_au]

If the listen for silence command is only in the connection macro it will have no impact once logging/connected. The small listen for silence might be used during logging though, its often used as a delay so the PCM can keep up (if you bombard it with data too quickly it can lose sync with the bus which causes errors). You would need to see how the monitor macro is setup.

Yes, the "Listen for Silence" command looks to be only in the "Connection Macro", yet changing this had a significantly affect on the rate of data errors, over a period of minutes, not just at the outset.

Stranger yet, I've just compared the LFS and sLFS of the three ADX files, and they're virtually the same! Yet the data error behaviour is completely different! Here are the figures (length/timeout) :

$51 VS V6 Engine and Trans v1.11 WB Innovate.adx ... LFS=60/50, sLFS=10/10 (7 mins for 20 errors)
$51 VS V6 Engine and Trans v1.11 WB Innovate.adx ... LFS=60/400, sLFS=10/400 (2.5 mins for 20 errors)
Vs V6 engine and trans 1.08-tp5 - Credit to Jayme.adx ... LFS=50/50, sLFS=10/10 (nothing but errors!)
$51 VS V6 Engine and Trans v1.10 WB 14.7kit.adx ... LFS=60/50, sLFS=10/10 (no errors, perfect!)

So, there's some other factor in those ADX files that isn't yet accounted for.

Joe.

[Dylan]

On my own car running 12P I get errors if the usb lead runs over the power lead.
On my mates car same interface lead and laptop, different ecu we get errors on deceleration only.
I have a lead coming with the ferrite bead incorporated. Just using an old printer lead for now.

Interesting. I presume the power lead means for the laptop.

In your car, it must be an electrical noise thing (hardware).

In your mate's car, I'm not sure what it could be, I can't imagine noise would increase on deceleration, maybe there's some chatter from ABS that's causing it? If so, then it would be a software (TunerPro RT / ADX file) thing.

Finally, I'd be interested to know if the ferrite bead helps you. I presume it's a USB extension lead.

I've heard of people getting such errors when they plug their laptop power adaptor into the cig. lighter. However, I've tried this myself to see what happens, but with my cable, I don't get anything.

Joe.

Yeah power lead is the cigarette lighter charger. Mates car is a VK so no fancy stuff.
The interface is a USB that plugs into a OBD2 port. The new lead will be interesting.
My car is easy don't crosz them over. Both cars are running a MSD ignition.
My car is a digital 6 and I have no problems. His is an old analogue 6AL. Possibly unrelated.

[Tazzi]

If the listen for silence command is only in the connection macro it will have no impact once logging/connected. The small listen for silence might be used during logging though, its often used as a delay so the PCM can keep up (if you bombard it with data too quickly it can lose sync with the bus which causes errors). You would need to see how the monitor macro is setup.

Yes, the "Listen for Silence" command looks to be only in the "Connection Macro", yet changing this had a significantly affect on the rate of data errors, over a period of minutes, not just at the outset.

Stranger yet, I've just compared the LFS and sLFS of the three ADX files, and they're virtually the same! Yet the data error behaviour is completely different! Here are the figures (length/timeout) :

$51 VS V6 Engine and Trans v1.11 WB Innovate.adx ... LFS=60/50, sLFS=10/10 (7 mins for 20 errors)
$51 VS V6 Engine and Trans v1.11 WB Innovate.adx ... LFS=60/400, sLFS=10/400 (2.5 mins for 20 errors)
Vs V6 engine and trans 1.08-tp5 - Credit to Jayme.adx ... LFS=50/50, sLFS=10/10 (nothing but errors!)
$51 VS V6 Engine and Trans v1.10 WB 14.7kit.adx ... LFS=60/50, sLFS=10/10 (no errors, perfect!)

So, there's some other factor in those ADX files that isn't yet accounted for.

Joe.

Looking at those stats for each file, then yeah there is a big difference!
I did find that tweaking that originaly edited file that I uploaded to about 45/50ms made the biggest changes for me. But if what VL said is right, then yeah tunerpro would have been timing out before it got the responses! haha.
I do find on my VY V6, that tunerpro can sometimes take a couple connects/disconnects to sync up correctly, which occurs from the way it waits for silence, waits for the heartbeat, and how it detects the response.
Whereas when I use my own application (Or even VL's OSE tool) to request custom frames, they will both get the response immediately because they will look for a minimum silence, or will request information after the heartbeat (depending on vehicle type).

Not too sure on how much of a difference tweaking the latency settings in device manager does!. The stock standard settings seem to be fine especially if you use an ALDL dedicated application like OSE which has refined routines to only detect the required response.

Im using on a Bench setup so only the VS ecu is communicating and is the only device that is is outputting chatter onto the bus constantly. I think Tunerpro macro needs to look for a silence period of ~15ms and a total timeout around ~500ms. (What VL said!). Id even be inclined to narrow that timeout parameter even lower, and add in a function to test the captured frames checksum to ensure the correct frame has been captured.

Maybe try tweaking one of the files (or even the one I uploaded) to match the above. I think there will be a massive difference. Ill try on the bench setup here.

[Tazzi]

Found another little issue, the macro only listens for silence for the engine data frame and not for the trans frame as well.

Added in a listen for silence into one of the macros, and also tweaked the small silence listen (not used?) and the normal silence listen to 30ms with a timeout of 400ms.

Connects up each time no worries, even when disconnecting the ecu and reconnecting, it just gets the right data!

[Jayme]

yeah I was waiting to get another bench pcm before giving that a go... good to see its fixed... learnt a lot since those early adx's

[VL400]

There should be no chatter constantly streaming from a VS PCM. Only on a bench will you see this if VATS is enabled with no BCM, the PCM will be sending frames every 100ms until there is a valid response from the BCM (which it never gets).

Anyway, give this one a shot. Changes are a small inter frame delay instead of a wait for silence (the inter frame delay time can be adjusted down to normally 5ms, longer using the normal wait for silence time it just slows logging WAY down). I have not tested the disable chatter response part, might need to disable it, but the idea is to search for the reply up to 5 times breaking once found. Looking for silence is hardly needed on pre VT though, only chatter is VATS burst at key on and VS V6 the low speed fan control (only a frame to turn on and frame for off).

Vs V6 engine and trans 1.10-tp5 - Credit to Jayme.adx

(102.39 KiB) Downloaded 350 times