OBD data frequent freeze

[TheMMM]

Hi,

I am using an HTC M8 with either a cheap ebay obd adapter or a OBDLink LX and I see some very frequent freeze (every about ~6 seconds that last for up to ~5 seconds) on all data coming from the OBD adapter only. I don't see extreme values, just frozen values.

I have upgraded to the Grand Prix to get the "Engine" tab; and still see the issue (without the video underlay).
Note that:
-The OBDLink LX works without a hitch with the ODBLink app.
-I have seen the same issue on two different car brands with same phone and OBD adapter.
-I have reverted all expert settings.

Thank You!

[Harry]

Please read viewtopic.php?f=39&t=1500 about debugging OBD connections. A frequent issue are other OBD apps active in background. So the freeze may go away once you have killed apps like OBDLink's. Otherwise, please create a log and send it to me. I will check what is going on.

- Harry

[TheMMM]

I had no other app/Bluetooth device paired..
Sent you the log!

[Harry]

Thanks for sending the log.

As expected, the problem is the early OBD II implementation of your Audi.
The following parameters required by LapTimer to optimize update rates are not answered (NO DATA):

Code: Select all

24493219300          ---------  mode: 9 pid: 0x00 [PID01-20] (index: 15)
24493219300          Tx: "30 39 30 30 0D '0900\r'"
24493220410 + 1110ms Rx: "4E 4F 20 44 41 54 41 0D 0D 3E 'NO DATA\r\r>'" (10)
24493220410          ---------  mode: 9 pid: 0x20 [PID21-40] (index: 16)
24493220410          Tx: "30 39 32 30 0D '0920\r'"
24493221520 + 1110ms Rx: "4E 4F 20 44 41 54 41 0D 0D 3E 'NO DATA\r\r>'" (10)
24493221520          ---------  mode: 9 pid: 0x40 [PID41-60] (index: 17)
24493221520          Tx: "30 39 34 30 0D '0940\r'"
24493223700 + 2180ms Rx: "4E 4F 20 44 41 54 41 0D 0D 3E 'NO DATA\r\r>'" (10)

24493224860          ---------  mode: 9 pid: 0x02 [VIN] (index: 19)
24493224890 +   30ms Tx: "30 39 30 32 0D '0902\r'"
24493225980 + 1090ms Rx: "4E 4F 20 44 41 54 41 0D 0D 3E 'NO DATA\r\r>'" (10)

While LapTimer ignores NO DATA, these requests require 1 to 2 seconds to be answered - which produces the drop outs you are facing. The named parameters are not requested at high update rates, but regularly. The only work around is to ask LapTimer to not request these parameters at all. As a result, LapTimer will request other parameters (like RPM) usually masked by the problem parameters (see above) “blindly”. As long as they are answered, you will not face an issue, in case they are not, you will get other drop outs and need to come back again to exclude these in addition.

O.k., that’s the long story with all the background, here are the steps for the workaround:

In LapTimer ‣ Administration ‣ Settings ‣ Expert Settings ‣ OBD Tweaks / Exclude PIDs, enter

Code: Select all

	0900092009400902

The general reply time for parameters I see from the log is 120 ms. This means the Audi’s (non CAN) bus delivers 8.3 parameters per second. This means you will see roughly 2 Hz update rates for the set of LapTimer’s core parameters.

- Harald

[TheMMM]

Thanks,this fixed my problem!
For my curiosity, why not benchmark the car at init and automatically remove unanswered pid's for that session?
(Especially with non-standard/non-vital groups such as 9?)

[Harry]

This would be possible. On the other hand it is a work around for a very small segment of cars not implementing the OBD II protocol correctly. With no time constraints I'd add it.

Harry

[TheMMM]

Fair enough, thanks!!!

[tomprout]

Hi,

I also experienced some freeze issues. I just sent you the log files.

Thanks!

[tomprout]

I did a quick check to the logs and did not find any 'no data'. It is also worth to mention that freeze issues were experienced 5 months ago using a previous version of laptimer (The one up to date at this time).

[Harry]

Reply with analysis sent.

@all: retrieving OBD data using the ELM327 protocol is extremely sensible towards runtime influences from disturbing WiFis around (creating lag) and the processing capacity available on the smartphone side. This is due to the fact that OBD data does not come with a timestamp for the original data. This is different to GPS where each set of data comes with such a timestamp. A timestamp allows LapTimer to compensate any runtime effects. This is the reason a GPS update rate will show up pretty stable while OBD rates will constantly fluctuate.

- Harry