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...
