Inconsistent GPS update rate on XGPS160

[gplracerx]

I have data taken simultaneously by a VBOX Sport and an XGPS160. I'll graph the plots and post them. I'll be surprised, though, if there's much difference.

[gplracerx]

Here are the course map plots (autocross) and the corresponding speed plots vs UTC. The time axes look different because the .vbo time format is different, but the times on the axes are, in fact, identical with no adjustment to get the plots to overlap. The VBOX time axis is in seconds from midnight Zulu time while the XGPS160 plot is 24 hour format (minutes and seconds only on the axis) Zulu time. The antenna for the VBOX sport was on the trunk (boot) lid while the XGPS160 was on the dash. There were 1000 data points from the VBOX sport but only 213 fixes in HLT.

[jwmelvin]

Interesting, thanks. What device was this captured with? I thought VBox Sport had the same Bluetooth issue that XGPS is having (on iOS 7.1+).

[gplracerx]

The VBOX Sport logged to its SD card. It starts logging when the car starts moving and stops when it stops. If there is no movement for too long, it turns off. I don't know how long is too long. It wasn't connected by Bluetooth at all. The XGPS160 was connected by Bluetooth to an iPhone 4 running HLT. I downloaded the HLT .csv file and copied the VBOX Sport .vbo file to a computer and plotted the data in Excel. There are tricks. The time format in .vbo is HHMMSS.00 from midnight UTC. HLT uses HH:MM:SS.00, also from midnight UTC. The latitude and longitude in .vbo are decimal minutes, so need to be divided by 60 to get decimal degrees. The speed was from the output, i.e. Doppler speed, not calculated from differentiating position fixes.

Circuit Tools just uses the position data to calculate speed and acceleration. I'm not overly fond of that approach as I think the Doppler speed is more precise. A derivative of a sampled function like position is always going to be noisy. Differentiating twice to get acceleration just makes it worse. Conversely, integrating a noisy signal, like the iPhone accelerometer data to get speed, creates a random walk so the probable error in the data gets worse as the square root of time. Double integration to get position is, of course, even worse. There are ways to mathematically combine accelerometer, rotation rate and GPS data to get position, velocity and orientation that is better than using any one signal. DIY drones, whether planes or quadcopters, use this approach for flight control and can even deal with cross winds. A quadcopter needs a 3 axis magnetometer in addition so it knows which way it's pointing when hovering.