OBD Extrapolation with OBDlink MX vs Kiwi3

[Sonertial]

I recently bought a Kiwi3 OBD2 dongle to replace my OBDlink MX Wifi. The MX was having constant connection issues, primarily in the vicinity of mobile network towers. It also seems to affect the overall update rate of the XGPS160 fixes.

Problem: Although the Kiwi3 connects and communicates flawlessly, the overlayed RPM and Speed are very jerky.

I tried setting the OBD Extrapolation to Aggressive. The jerkiness got dramatically worse.
Setting to Conservative was not as bad as Aggressive, but still pretty bad. I've set it back to Adaptive for now.

I retested the OBDLink MX Wifi, and the overlayed RPM and Speed were back to being smooth.

When watching the realtime overlay while filming and driving, the RPM is (much) smoother than when it is overlaid for export.

I've been reading a few threads about this, e.g. viewtopic.php?f=8&t=3731&start=40, and have played a little bit with sensor delays, but have not been able to solve this. I read that it may be an update rate issue, but thought it had been fixed in a recent release.

I've been a bit curious about this, since I noticed similar behaviour with all the OBD outputs including Temperatures in the Lap .csv recordings.

When using the Kiwi3, transitions between values have an overshoot, the MX looks sensible.

If you look only at the Wheel speed values that are integers (since the OBD sends 1 byte, 0-255kph), you can (sort of) isolate the interpolated (or are they all only extrapolated?) values. The RPM values have all been rounded, so I can't do this for RPM:


Kiwi3 Wheel Speed vs GPS with Aggressive OBD extrapolation:


Here's an example of Coolant temp from two separate logs:


Something seems little odd in the Kiwi3 cases. The interpolation is offset from the (presumeably) measured values.
I am usually getting ~4-7 Hz with the Kiwi3, with the MX, about 7-11Hz.

Is it possible to turn off Extrapolation? I would like to try smoothing the XML data offline and reimporting the lap.

[Harry]

The different update rate is due to the BT LE interface used for the Kiwi. 4 to 7 is a good value, the bottleneck is the connection technology and the ELM protocol used. The overshot are due to extrapolation applied. As you have seen, Conservative produces less overshots, but will result in stepped values (i.e. values are repeated and jump to the next level after some time, stay here, etc). The problem cannot be solved by tweaking the current method to fuse OBD and GPS data. Instead, fusing all the GPS / OBD / IMU values needs to be done symmetrically instead of using GPS as the carrier for any fusion. As this is a big change, this is nothing I can add for a minor or bug fix release. It needs to go through a major release's beta.

- Harry

[Sonertial]

Thanks for the response Harry. Sorry to be persistent, but I just want to be sure I am understanding you. If I leading myself astray here, then feel free to ignore this.


I am using a Python script to send OBD commands to Laptimer. I am calculating everything based on time elapsed from when the VIN request comes in. I calculate all values (speed, RPM, MAF etc) based on equations which produce output as a function of elapsed time. So I am sending the same data in the two cases (GPS/ODBbuddy or Laptimer), at least with respect to time. The exact fixes times are obviously different, but the rate is about the same, I am using the XGPS 160 as the trigger.

By looking at the RPM and Wheel Speed when sending to ODB buddy trace log, and comparing to the same sequence sent to Laptimer, I can see there is something bad happening in the Laptimer data.

Edit: Took away some stuff. I realized this difference is probably due to the sensor delays.