Cold snapshot GNSS / snapshot positioning without initial information

[JonasBchrt]

I received a question regarding the cold snapshot GNSS implementation in this repository, which I would like to address here.

[JonasBchrt]

The cold snapshot technique combines coarse-time Doppler navigation (CTDN) with code-phase-based coarse-time navigation (CTN). Applying CTDN first removes the requirement of CTN for a coarse initial receiver location and time. My implementation in coarse_time_navigation.py is called cold_snapshot(...) and inspired by

Fernández-Hernández, I., Borre, K. Snapshot positioning without initial information. GPS Solut 20, 605–616 (2016). https://doi.org/10.1007/s10291-016-0530-4.

Here are a few notes that might help understanding challenges when applying my code in practice:

• There was indeed a bug in the cold snapshot GNSS implementation in this repository. I think I fixed it in commit 422d679. Thanks for the heads-up.
• I wrote the cold_snapshot(...) routine before we even built our first SnapperGPS receiver and it has actually never been used for SnapperGPS. Cold snapshot GNSS is useful when you have no idea about initial values, but this is not relevant to SnapperGPS since we always have a rough user-provided initial position and a sufficiently accurate on-board real-time clock. Therefore, I did not spend time on robustifying or accelerating the cold snapshot implementation or optimising it for the use of multiple GNSS, unlike for some other algorithms. In consequence, I would not be surprised if my cold snapshot implementation is less reliable than some of the other algorithms in this repository when applied to real-world data.
• I created a GitHub repo with a working cold snapshot GNSS example. It uses a (heavily) down-sampled version of the data that Fernández-Hernández and Borre label with ID 2 in their paper.
• If you want to apply cold_snapshot(...) to a different dataset, then I would like to make you aware of the following aspect of CTDN: If the intermediate frequency (IF) of the raw signal is almost zero (or almost a multiple of the sampling frequency), then Doppler-based positioning is challenging. A standard acquisition routine cannot distinguish between a shift of -200 Hz and +200 Hz. So, you need to figure out the sign in the subsequent optimisation, too. My cold_snapshot(...) does not account for this; so, if you feed data like this into it, then it will almost certainly fail. I had to deal with the same issue in frequency_bias_estimation.py, but for a different purpose. I am robustly estimating the frequency offset of the RF front-end there, which is just one of the unknowns in the CTDN problem. The second half of Section 4.1 in our SnapperGPS paper covers this

Jonas Beuchert and Alex Rogers. 2021. SnapperGPS: Algorithms for Energy-Efficient Low-Cost Location Estimation Using GNSS Signal Snapshots. In SenSys ’21: ACM Conference on Embedded Networked Sensor Systems, November, 2021, Coimbra, Portugal. ACM, New York, NY, USA, 13 pages. https://doi.org/10.1145/3485730.3485931.

• If there are any further questions regarding this topic, feel free to ask.

[JonasBchrt]

Yeah, it was not very thoughtful to write "A standard acquisition" here. Thanks for your comments.

[JonasBchrt]

Maybe my paper would have benefited from you being on the board of reviewers ;)

[ZiglioUK]

I'm just happy about having received a mention, thanks for that! I would have had a "sentimental" conflict of interest there... But I'm following the development with curiosity!

[JonasBchrt]

Anyways, SnapperGPS deals with binary real signals, 1 bit per sample. I think it is at least mentioned in Section 2, but probably could be more prominent.

[JonasBchrt]

My code in the comments above as well as the two acquisition functions in this repo take real inputs as well as complex inputs.
If you feed a complex signal into the code stub above, then the the correlograms look different for -2 kHz and 2 kHz. If you feed an unmodified real signal into it, then they look the same.