GPS drift on stationary data

[seppestas]

I'm using this project to generate stationary GPS data and a HackRF One to transmit it. My goal is to test geofencing functionality.

I expect my receiver (a u-blox MAX-M8Q module) to get stationary GPS data, which seems to work most of the time, however after a while the GPS data seems to drift pretty quickly and more than 10 meters. I have yet to plot the drift, but it seems to happen in a straightish line. See gps-log.txt for a log of the drift.

Could this drift be explained by inaccuracies in the gps-sdr-sim software?

To reproduce my test:

wget -q ftp://cddis.gsfc.nasa.gov/gnss/data/daily/2018/brdc/brdc2490.18n.Z -O brdc2490.18n.Z
uncompress brdc2490.18n.Z
gps-sdr-sim -e brdc2490.18n -l 50.846717,4.362739,160 -d 900 -b 8 -t 2018/09/06,14:15:00 -i -o stationary.bin
dd if=stationary.bin | hackrf_transfer -t - -f 1575420000 -s 2600000 -a 1 -x 1

The HackRF has an external TXCO from NooElec, an RF shield over the radio part as well as an aluminium case and uses the ANT500 antenna set to 20cm. A Raspberry pi 3 was used to send the data to the HackRF.

[seppestas]

PS. I'm using dd because opening the file directly in hackrf_transfer seems to fail on the Raspberry Pi.

[IvanKor]

To reduce the drift from HackRF it is necessary to increase "-s 2600000" --> "-s 12000000" or even more I checked it use Real-time GPS signal simulator https://github.com/IvanKor/hrfGPS

[seppestas]

@IvanKor Thanks, I'll test using a higher sample rate on the HackRF. Wouldn't this also require to increase the sample rate passed to gps-sdr-sim?

[IvanKor]

sampling rates for gps-sdr-sim and HackRF should be equal

[seppestas]

@IvanKor I now tried with a higher sampling rate of 12000000 like you suggested, but this does not seem to improve the drifting. It's also very impractical since the created files for my tests are huge (> 20GB) and thus fit not on the SD card, the RPi is not fast enough to calculate the data for streaming (not even at 2.6MHz) and even reading from a memory stick seems to be too slow on the Rpi (12MHz seems to need ~24.1 MiB/s).

Yesterday I did some duration testing and it looked like some devices drifted a lot more than others. The drifting on the same device also seems dependent on the position of the transmitter. I'm starting to think the drifting is caused mainly by multipath RF reflection (my tests are being done in a fairly small room) or the GPS receiver.

[IvanKor]

I have an increase to 12000000 reduced drift to ~ 3 meters using a strong signal. The drift of GPS receivers depends on the frequency of their quartz.

[joelmatejka]

@seppestas Hi, did you manage to fix the drift you observed? I'm having similar setup (NEO M8U and HackRF) and I see usually fixed position for dozens of seconds, then drift in some direction, then Fix lost, then position more or less recovered to original position... So it looks to me quite similar to your case.

[seppestas]

@joelmatejka, I don't remember if I ever found a fix TBH, I finished this project a while ago. My guess is this is an issue with clock drift on either the HackRF or the u-blox MAX-M8Q .

The NooElec TCXO module claims 0.5PPM clock stability, but this might just be the spec of the TCXO itself, the additional parasitic of the header connectors etc. might cause more fluctuations?

A TCXO's accuracy is also typically dependent on the temperature and supply voltage. Maybe there is some noise coupled in on the TCXO power input that is not effectively decoupled or the HackRF is heating up during operation causing slightly more drift.

It might also be possible there is some ionosphere correction in the GPS messages generated by gps-sdr-sim. Since there will be no ionosphere effects (unless you have your HackRF sitting on a satellite), these corrections might have averse effects? It's not clear to me if the Broadcast ephemeris data contains any ionosphere correctional data.