Harry's GPS Suite Forum

I've also update to 17.0.7, which was released yesterday.

And another thought: Rather than extrapolating rpm, which is going to make the graph noisier, why not use GPS speed to calculate RPM based on the speed at the last good rpm reading? That would also work for wheel speed as wheel spin shouldn't be all that common. And don't extrapolate throttle position at all. Better to just keep the last good reading until you get another one.

gplracerx wrote:Eight seconds seems like forever. At an autocross, I'm frequently on and off the throttle several times over that length of time. 17.0.6 isn't doing a very good job with RPM either. See the attached plot comparing GPS speed and RPM. I'm always in second gear after 0.7 seconds. Needless to say, the throttle plot is much, much worse. I think it's interesting that the throttle never gets above 2.55 at any time. I can normalize the plot to the maximum reading, but it still only vaguely corresponds to reality. Is this problem made worse by the high data rate of the VBOX Sport?

July 21 2013 Run 4 GPS Speed and RPM.png

Throttle is not getting beyond 2.55 because it is stored in one byte... Actually it should not get above 1 = 100%. I assume it is the same extrapolation problem like the others we discussed. I will consider removing extrapolation as proposed. Nevertheless, the root cause for your issue are most probably the inbalance between many GPS fixes and a small number (and missing) OBD fixes. So keep my fingers cross it will be better with the Kiwi.

- Harry

The KIWI Wi-Fi OBDII was no better in terms of extrapolation, but it may not drop out completely as often. RPM and wheel speed graphs are too noisy and the throttle position graph is completely useless.

When I look at the lap data, why does it say "external @ 10 Hz" for the VBOX Sport? Shouldn't it be 20 Hz?

LapTimer tries to make a guess from the GPS recordings. Need to have a look into the data to understand what is going on (CSV or HLPTRL).

- Harry

I've emailed you a file for one run. Let me know if you don't get it and I'll send it as an attachment instead.

Even with capping at 100% in the latest version of HLT, the throttle position graph is ugly. Extrapolation of throttle position data with a GPS rate of 10 Hz isn't working. Wheel speed and rpm aren't as bad, but I think I'd rather just see the actual measured points with an option to interpolate off line rather than extrapolation in real time. Either that or use some sort of adaptive filter rather than a simple extrapolation. Another possibility would be to flag them as measured or calculated as you do for acceleration data in the output data file.

The latest version's extrapolation is limited to 1 second, but will not happen only in cases the OBD rate drops (assuming your car delivers e.g. 5 Hz usually). So in standard operation, extrapolation will be limited to 0.2 seconds - but typically 0.1 seconds... Maybe the issue is not around extrapolation but the data delivered by your car? You may try logging some data using Harry's GPS/OBD Buddy. Turn on logging to "Logfile" and select the "Raw Data" tracing class (turn off everything else). This will generate a log file showing raw data for all sensors. I'd be interested to see how throttle data looks here?

- Harry

I graphed the throttle data in Excel and it does look a lot better. I'm going to try a video overlay and see how that looks.

If the OBD data is 0.5 seconds ahead of the GPS data, do I decrease or increase the OBD delay?

I still don't like extrapolation for OBD rpm and wheel speed.



I may be getting some wheel spin, particularly at the start, but I don't think it's that much everywhere else.

The XGPS160 altitude data is much more accurate. I was able to calculate vertical velocity and pitch to correct the lineal acceleration data and achieve almost perfect agreement between GPS speed and integrated corrected (including calibration orientation error) lineal acceleration plus vertical velocity.