OBD logging/display issues in Android

[aaronc7]

For me, GPS speed lags behind OBD around 0.3s. I'm going to try OBD delay from 1.0 -> 0.7 or GPS 1.5 -> 1.2 and see if that has any effect.

I tried the acceleration -> velocity integration but it was a bit off. This was standard 30hz accelerometer rate, so maybe that had something to do with it. I did an individual calibration as well.

[gplracerx]

aaronc7,

Integrating acceleration to get velocity or yaw rate to get direction is always going to be a bit off because the acceleration data is noisy and, as a result, the error range in the integrated velocity or direction is going to increase over time. You get what's called a random walk. To minimize the error, you have to correct the offsets on the lineal and lateral acceleration and correct for error in yaw by doing a rotational transform around the vertical axis. You do that by combining the lateral and lineal acceleration using the sine and cosine function. For a rotation of x degrees, lateral g corrected = cos(x)*(lat+a) -sin(x)*(lin*b) and lineal g corrected is sin(x)*(lat+a) + cos(x)*(lin+b), where a is a constant offset for lateral acceleration, b is a constant offset for lineal acceleration and x is the rotation angle. When x=0, the data are not changed. This assumes that the vertical axis of the phone is pretty close to the vertical axis of the car. That way you don't have to do a full three axis rotational transform using a direction cosine matrix or quaternions. That's hard to do without g data from the vertical axis.

What I'm doing in my spreadsheet is to calculate yaw rate from GPS speed and corrected lateral acceleration, then integrate that to get direction data. You then have to unwrap the GPS data so that there aren't inconvenient transitions from 359 to 1 degree and calculate the sum of the squares of the difference and the sum of the square of the difference between the calculated speed using the corrected lineal acceleration and the GPS speed. Then you need to adjust three variables, a, b and x to minimize the sum of the sum of the squares. I use Solver in Excel. It seems to work if you're going fast enough at high enough g. It doesn't work so well driving around the neighborhood, probably because there are hills.

While it sounds complicated, it's not that difficult to do in a spreadsheet. You can even shift the time scale when integrating to calculate delays. Even when you don't get that great a match between the calculated speed and the GPS or wheel speed, you can still do time step offsets and minimize the sum of squares to find an error in the device delays.

[aaronc7]

Wow, this thread just got super nerdy. I love it though and thank you for posting a detailed response. The way I had the phone mounted for this, it wasn't exactly straight up and down, so I might have to reattempt anyways.

[gplracerx]

If I'm doing this in the right direction, I need to increase the XGPS160 delay by 0.1 second from 0.7 to 0.8 seconds and increase the BT1 delay by 0.5 seconds from 1 to 1.5 seconds. Now to test.

Backwards, of course. Those settings made things worse. Let's try XGPS160 delay 0.55 and OBD delay 0.65.

[fstlane]

Aaron,

I have your exact same setup although I have an LG G3 phone. I had this same issue with very spiky OBD data, until I fixed the OBD delay in expert settings. I believe the default is 1.0 seconds; my OBD delay is set at 1.8 seconds.

Using Excel, export your data, and you may find a difference in GPS vs OBD speeds. Create some formula's if you want or just 'eyeball' the data to find what rows the GPS and OBD speeds match. In my case it was .8 seconds later. I then created a formula to pull an obd speed that was 0.8 seconds later and compared to GPS speed as verification. It won't be perfect, but close. From there I added the 0.8 to the 1.0 default setting to arrive at 1.8.

After "tuning" the OBD sensor delay, my OBD data is ultra smooth. Not just speed, but RPM and throttle as well.


Ed

Ed,
By using your post's suggestion of changing the OBD delay to 1.8, my erratic OBD data behavior has been virtually eliminated. Hopefully a future update will correct the issue for all. Thank you!

Darren

Example with OBD delay changed to 1.8
[youtube]1hBxWZ51uyM[/youtube]
https://youtu.be/1hBxWZ51uyM

[aaronc7]

Was this ever figured out/implemented? Haven't seen anything in the last few release notes about it. I tried adjusting my OBD/gps delays etc., as noted in here, but haven't had any luck with getting rid of the OBD data interpolation issues.

[Harry]

Just in time. LapTimer v20.0.16 is available since yesterday evening / this morning (the release notes are from iOS):

What's New in Version 20.0.16

‣ Added a tweak for noisy OBD interpolations
‣ Added a help text to Databases hinting the Restore function.
‣ Added a legend on map type to Data Recordings
‣ Added a tweak so make LapTimer not drop OBD connection on certain DATA ERRORs positions
‣ Optimized memory usage for Heart Rate overlays, changed HR diagram to not show origin [GrandPrix]
‣ Fixed high OBD update rate without content after turning engine off and on again
‣ Added firmware and battery level information (if available) to BT LE sensor information
‣ Added some tweaks to work around crash in video deletion following a lap deletion
‣ Added a fix for sudden stops of lap recordings when OBD sensor drops connection

Thanks for any feedback on the interpolation / spikes issue discussed above. As I have not been able to reproduce the issue but have a vague idea only, I'm not sure the issue is actually fixed. Version 20.0.16 however has extensive logging included for this part, so in case it isn't fixed, we have a good chance to find the root cause for a fix in the next release.

- Harry

[aaronc7]

The Android release notes don't mention anything about it but it was included also I take it?

I just did a quick test running an errand in my wife's car and the OBD data overlay was smooth, worked perfectly. Will test in the 2003 Corvette later today.

[Harry]

Yes, the item has probably been mentioned for 20.0.15 already here, but not sure. I may have missed it as versions were not precisely in sync. Please take care to test with standard delays - not sure you used the workaround raised above... And thanks for further feedback.

- Harry

[aaronc7]

Well, it is not fixed, but I think I may have stumbled onto something.

A quick recap of my setup:

2003 Corvette Z06
Samsung Galaxy S7 (android 6.0.1)
XGPS 160 BT
OBDLink MX BT

I have found the easiest way to do a quick test for this is to video the tach and rev up the engine a little bit and compare RPM/throttle readouts.

With the XGPS160 connected, OBD data has the interpolation issue/is spiky.
With the XGPS160 NOT connected/removed from sensor list, OBD data seems to work fine.

In my mind I thought maybe it had something to do with OBD rate > GPS rate = good (GPS is 10 hz, OBD ~5 hz), so I excluded all relevant PIDs except RPM with the XGPS connected, but that did nothing to help with the spiky OBD data.

Here's the videos and I have the "laps" saved still. Let me know if I can help provide you any further info or testing... I'd be happy to log/test whatever, I have all day free tomorrow.

http://imgur.com/knVXvm0
http://imgur.com/Pe312b5
http://imgur.com/xguYJ3p

https://www.youtube.com/watch?v=X0EPuPuyMew