OBD logging/display issues in Android

[Harry]

O.k., so let us go one step deeper...

Please start with reading viewtopic.php?f=39&t=1933. It describes how to create trace logs.

The trace classes to select are "Sensor Fusion" and "Raw Data".

Please use your XGPS+OBDLink setup - the one generating spikes.

The easiest way to record something is to enable "Manual Timing" in Settings. Once you have it turned on, Timer View will come with additional buttons. Press Start / Stop to start and stop a manual recording. 30 seconds will be good enough. Stop logging afterwards and send the log file to Harry@gps-laptimer.de Please verify the recording stored in Lap List too - just to make sure the log covers a section with spikes.

Thanks a lot.

- Harry

[aaronc7]

OK log sent. Video overlay/csv again

https://youtu.be/rUTJBLY3p-g

[Harry]

Thanks for sending the data. The problem occurs when OBD data needs to be extrapolated over a longer time distance (low update rate) when it came in at a high update rate before. I will tweak the extrapolation to cope with this situation for the next bug fix release, please report again once you see 20.0.17. Thanks!

- Harry


Here is the detailed (nerdy) state so far:

Code: Select all

FUSION         00 --> fusing fixes for GPS fix at ticks 842339104: {date: 16-JUL-16,23:37:52.50, pos: [30.431548,
                        -86.947765], speed: 1.2, direction: 284.5, accuracy: 2.3}
FUSION         01   --> call to Sensors::getBestAlignedCompleteFixStartingAt (type: OBD, .)
FUSION         02     --> queue from head: AGAAAGAAAGAAAGAAAGAAAGAAAGAAAGAAAGAAAGAOAGAAAGAOAAGAAAOGAAAGAAOAGAAAGAAOA...
FUSION         02     -->   startingPoint:  ^
FUSION         02     -->    nearest OBD1:                                        ^
FUSION         02     -->    nearest OBD2:                                                ^
FUSION         02     --> selected interpolated OBD fix at 0 ticks: { rpm: 10792, maf: 0.00, speed: 0.0, throttle: 0.06}
FUSION         01   --> Sensors::getBestAlignedCompleteFixStartingAt () returns
FUSION         01   --> writing fused record {GPS: {date: 16-JUL-16,23:37:52.50, pos: [30.431548, -86.947765], speed: 1.2,
                          direction: 284.5, accuracy: 2.3}, acceleration: {lateral: -0.02, lineal: -0.23}, OBD: { 
                          rpm: 10792, maf: 0.00, speed: 0.0, throttle: 0.06}}
FUSION         00 --> fusing fixes done.

What you see here is the process of fusing incoming GPS, acceleration and OBD fixes. The letters in the queue are fix types with G = GPS, A = acceleration and O = OBD. Fixes are sorted by time of origin (delay adjusted). The function performed needs to derive OBD values for the point in time of the GPS fix marked (startingPoint). The problem is, OBD has not been delivered for quite some time. The nearest found are marked with OBD1 and OBD2.

While the approach would work perfectly for the two GPS fixes between nearest 1 and nearest 2, it fails for the long distance between nearest 1 to startingPoint. It generates a spike. So if there are a lot OBD fixes and not so many GPS fixes, it will work fine, but it fails when GPS rate is high and the OBD rate is high and varying.

On a side note: OBD rate tends to varies because it is strongly influenced by the car's bus load and BT / WiFi transmission delays. The only work around is a sensor side timestamp like for GPS - which is not available for OBD adapters.

I'm not yet sure how to handle this. The best approach would be to wait for another OBD fix before the GPS aligned data is stored. This however would introduce quite some additional complexity. The other approach is to not extrapolate the OBD fix in case it is too "old". This type of limit is implemented already but obviously too high for our scenario. So an initial solution will be to further limit extrapolation (e.g. to a max of 2 times of the nearest OBD fixes found) and simply copy the latest OBD data otherwise. The later will probably introduce a "step shape" but is probably not relevant when data is coming in at 10 Hz or more...

On another side note: GPS receivers handle this situation by applying a Kalman filter. That's another option...

[Harry]

Update: I have updated LapTimer v20.0.16 to a version implementing the workaround discussed. It is still on 20.0.16 but can be recognized by it's build date July 17th. Please repeat the test and let me know about the results. A log file would be interesting too.

- Harry

[aaronc7]

Positive improvement in the latest update. I did one "lap" and everything looked good in the overlay, but I forgot to create a log file to send. So I did another quick "lap", on this one, there was at least one instance of a big spike in RPM, but otherwise pretty good. Here are the videos in that order and I am sending the log file to your email now:

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

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

[ckowalc]

Harry I just downloaded v20.0.17 and saw one of the fixes is "Fixed extrapolation spikes for OBD data (special sensor configuration)". Is that directly related to the problem in this topic? Any additional details on the fix?

I think the problem described above is the same issues as the one I posted a year back: viewtopic.php?f=20&t=2997&p=15939#p15939

I'll be doing a track day tomorrow and I'll see what my OBD data looks like when I get back.

EDIT: Whoops missed reading the last few pages..

[Harry]

Yes, that's the problem discussed in this and another thread.

Harry

[ckowalc]

I'm happy to report that my OBD data is much smoother than it was before. Here is a comparison at full throttle going through a gear.

The first two are with v20.0.17 (w/ fix) and I adjusted the OBD delay to 1.8 sec (recommended in this topic). Didn't seem to make any smoother but maybe it will match my video better. I also included RPM data from a previous track day (pre-fix) and as you can tell there is an obvious difference.

This seems to solve one of my biggest frustrations with the data I was getting. Thanks Harry!

OBD Data.png (27.69 KiB) Viewed 2875 times

[Harry]

Thanks for the feedback. Please reset the sensor delay to default again. This made LapTimer not extrapolate OBD data because it shifted data out of the valid time for extrapolation - but certainly misaligned OBD and GPS data in general. So it had a pro and cons.

- Harry

[aaronc7]

Any desciption of the new adaptive vs aggressive vs conservative setting?