Speed Drop and Spike in Video Overlay

[rmeroda]

Hi Harry,

When videos are overlayed using the iPhone 5 GPS data, typically mid-corner, the indicated speed in the video sometimes declines and then sharply increases. I thought this was a GPS accuracy issue and that a faster external GPS would resolve the problem.

I recently bought a SkyPro XGPS 160 thinking it would help improve speed accuracy but I am still having the same issue. After talking with a SkyPro XGPS 150 user, who doesn't have the same issue, we thought that the way I had my SkyPro mounted it might be slightly sliding in the corners and causing the speed inaccuracy. But I got the same results after remounting the GPS in a way I was sure it wouldn't slide. The SkyPro app shows the XGPS 160 is connecting to 21 satellites and the accuracy indicators show "excellent" so I'm not sure what the issue is.

Here's a short video using the XGPS 160 that shows the sudden speed increase. I tried to do a visual effect on the video to highlight were it happens. I included the chart in the video showing the speed increased 6.1 mph in 0.4 sec or about 0.7g of lineal acceleration, but lineal acceleration is essentially zero in the graph. The second example in the video shows the speed dropping to 34mph and then increasing to 52mph in ~0.9 sec (~ 0.8g). My car is just not capable of that kind of lineal acceleration.

http://youtu.be/F9u_3rCSZqw

The speed inconsistency makes it difficult to determine what my actual speed through a corner is.

Is it something I'm doing wrong, a setting in HLT, or should I contact SkyPro?

Thanks for the help!

[Harry]

Except for interpolated fixes (start / finish and split positions), LapTimer stores exactly the values received from the receiver. So any problem in the data (most notably what you see in the graphs) is 1:1 what is received from the sensor. There has been another thread on speed delivered by the SkyPro - not sure what the outcome has been (there has been communication with Dual too). In general, speed measurements for changing speeds seems to be a difficult topic. In addition, all GPS chipsets apply Kalman filters that to smooth data. Once they discover this filter applied wrong assumptions (typically in corners - the chips doesn't know you will go around the corner in a second ), they need to counter wrong extrapolations and will generate sudden corrections.

- Harry

[Harry]

P.S. I.e. it is a discussion to be ran with Dual

[rmeroda]

Thanks for the quick response. Is this the thread you mentioned...
viewtopic.php?f=19&t=1516
I read through it but didn't see any info on the speed calculation. I would be interested in learning more but my search skills are failing to find the thread you mentioned. Do you happen to have a link or remember the thread title? If not, don't worry about it, I plan to contact SkyPro soon anyway.

[Harry]

Yes, even when using the Google Search function (available as an extra field in the forum's Search function), it is hard to find threads... The one I thought about is this one: viewtopic.php?f=8&t=1967 It has been about "stairs" in speed development, so probably a related, but different topic.

- Harry

[gplracerx]

Altitude 343586 ft???? Something is wrong somewhere. I'd really like to see the altitude vs distance plot.

[rmeroda]

Wow, I didn't even notice that. I guess my mind was putting a decimal in the middle of those numbers. Unfortunately I had to do a factory reset on my phone and didn't save the data from those laps. I did go under an overpass at relatively slow speed before the lap started recording. Maybe that threw off the gps accuracy?

I attached some images from another example with more realistic elevation data showing the same speed drop and sudden increase. The speed jumped from 50.6mph to 75.4mph in 1.5s (~.75g) but I don't think I actually went under 70mph in the turn though. (The acceleration data is off in this lap because I didn't recalibrate after fussing with the phone in the paddock.)

Here's the video from that lap...
http://youtu.be/VQCv7gSg6AM

[gplracerx]

You can adjust the yaw angle in the acceleration data in the g-g plot after the fact and before you overlay. There are little buttons that rotate the plot counter clockwise and clockwise and one in the middle that's supposed to set the angle approximately correct. You want to adjust the angle so that the plot is more or less flat across the top. Lineal acceleration will be less than lineal deceleration. If you have hard braking in a straight line, that gives you an additional reference for orientation. IMO, that's the primary benefit of the G-G plot.

If you could export the data for that lap in .csv format and either attach it to a post or put it in a public folder on Dropbox and post a link, I could analyze the data in a spreadsheet and see what happens.

[rmeroda]

i can't remember the exact reason but I ended up "Recalculating" the acceleration data instead of adjusting yaw angle as you describe. Below is a link to the .csv file. I appreciate you looking at the data and hope I didn't make it unusable by applying the acceleration filter.

https://drive.google.com/file/d/0B8G5f9 ... sp=sharing

[gplracerx]

Recalculating the acceleration data is a last resort. It overwrites the accelerometer data. If you're going to try that, you should export the data in .hlptrl format first so it could be recovered if necessary.

I do see glitches when comparing the GPS speed to speed calculated from time and distance. I think there might be some problem with the time stamps or the distance calculation There are step changes in the calculated speed. That shouldn't happen. The latitude and longitude vs time curves are smooth as is the heading plot. I'm going to recalculate distance, speed and heading from the latitude, longitude and time data.

Do you have the latest firmware in your XGPS160?