Add SUPL 1.0 Alternatives (Besides rinex2assist)

[Zi7ar21]

Hello! I have been having issues getting GNSS-SDR to obtain assist data (Almanac, Ephemeris, Iono, and UTC model) through SUPL and was thinking it would be nice if there were another automated alternative such as NASA CDDIS.

For now, I have been downloading ephemeris manually and using rinex2assist but it's an annoying manual process and rinex2assist is only compiled with GNSS-SDR when using -DENABLE_SYSTEM_TESTING_EXTRA=ON, so I have to generate the XML files on my desktop, upload them to Google Drive, and then download them whenever I want assist data on my laptop (which doesn't have enough storage for the toolchain to build GNSS-SDR).

Ordinarily I wouldn't have a problem with this but front-end-cal requires SUPL, so I have to set GNSS-SDR.SUPL_read_gps_assistance_xml=true and even then it tries to use the time of the Ephemeris which is really annoying because the Ephemeris I download is usually 1-2 hours old (so that it has all the satellites) which, by then the space vehicles have already left the sky.

More info about problems when I try to use SUPL

I filled out the MCC/MNC with 311/480 (Verizon US), LAC (TAC since my phone uses LTE) with 2817, and CI (CID since my phone uses LTE) with 2872835.

;######### SUPL RRLP GPS assistance configuration #####
; Check https://www.mcc-mnc.com/
; On Android: https://play.google.com/store/apps/details?id=net.its_here.cellidinfo&hl=en
GNSS-SDR.SUPL_gps_enabled=true
GNSS-SDR.SUPL_read_gps_assistance_xml=false
GNSS-SDR.SUPL_gps_ephemeris_server=supl.google.com
GNSS-SDR.SUPL_gps_ephemeris_port=7275
GNSS-SDR.SUPL_gps_acquisition_server=supl.google.com
GNSS-SDR.SUPL_gps_acquisition_port=7275
GNSS-SDR.SUPL_MCC=311
GNSS-SDR.SUPL_MNC=480
GNSS-SDR.SUPL_LAC=2817
GNSS-SDR.SUPL_CI=2872835

The parameters above fail, saying:

ERROR: SUPL client request for ephemeris data returned -2
Please check your network connectivity and SUPL server configuration

I am not really familiar with how SUPL works, but I looked up supl.google.com and it appears port 7275 is SSL and 7276 is unencrypted. I tried both port numbers but neither works! nmap shows the ports are open though:

[jacob@jacobarch ~]$ nmap -p 7275 supl.google.com
Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-10 13:30 MDT
Nmap scan report for supl.google.com (74.125.142.192)
Host is up (0.037s latency).
Other addresses for supl.google.com (not scanned): 2607:f8b0:400e:c01::c0
rDNS record for 74.125.142.192: pv-in-f192.1e100.net

PORT     STATE SERVICE
7275/tcp open  oma-ulp

Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds
[jacob@jacobarch ~]$ nmap -p 7276 supl.google.com
Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-10 13:30 MDT
Nmap scan report for supl.google.com (74.125.142.192)
Host is up (0.036s latency).
Other addresses for supl.google.com (not scanned): 2607:f8b0:400e:c01::c0
rDNS record for 74.125.142.192: pv-in-f192.1e100.net

PORT     STATE SERVICE
7276/tcp open  oma-ilp

Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds
[jacob@jacobarch ~]$

google/supl-client

The issue may be that GNSS-SDR uses SUPL 1.0 but supl.google.com might only support something newer now, I don't know but SUPL is such a mess with so little info online about what exactly it is/does. When I search "supl.google.com" online most of the results are people on forums for custom privacy-focused Android ROMs asking why their phone has traffic going to supl.google.com.

It seems I am not the only one with this issue, see #620, #585, #427, maybe #300 (they were successfully able to use supl.vodafone.com, but this did not work for me), and #462.

Possibly related issues

I have an Android phone (because I value un-restrictedness) and there is this neat app called GPSTest which allows you to view information about your phone's GNSS status, such as the satellites it is using and whether or not it has almanac and ephemeris. It also allows you to "Inject PSDS data" which asks the Android system to download assist data, such as almanac and ephemeris.

When my phone is connected to my Wi-Fi network and the app attempts to "Inject PSDS data" (almost certainly through SUPL) none of the satellites start with Ephemeris. However, when my phone is connected through LTE, the Ephemeris flag for all healthy GPS satellites (all except 1 and 22 right now) appears.

This might mean that supl.google.com only works when you are accessing it through a mobile network, but I'm not sure. I have already tried connecting my laptop to my phone through a hotspot to see if GNSS-SDR would work, but I still got the same SUPL error so either my phone's hotspot filters requests like that or GNSS-SDR doesn't use the same SUPL version that supl.google.com supports.

[sjmurdoch]

I had similar issues to you and didn’t get further. I also tried the Vodafone server but that is now just a pointer to Google so it is not surprising that it behaves the same. One possibility is that the server no longer supports SUPL version 1. I noticed a branch attempting to implement SUPL v2 but that was last updated in 2018 and doesn’t appeared to have been merged.

I was mainly trying to use SUPL to run front-end-cal to hopefully improve performance of my RTL-SDR receiver. Did you find any other way to run this program? I am currently seeing a lot of loss of synchronisation and am not sure if this is down the the problems that front-end-cal aims to address.

[carlesfernandez]

At this point, we only support SUPL v1. Adding V2 would be an interesting feature.

[Zi7ar21]

@carlesfernandez

It seems my account does not have permissions to re-open this issue. Please don't close this as "completed", this is not just an "interesting feature", there are currently no alternatives to SUPL, and rinex2assist is insufficient (as explained above and below). See https://gnss-sdr.org/design-forces/availability/#time-to-first-fix-ttff

Can you tell me where might I find a SUPL 1.0 server? I made some progress debugging this issue, despite GNSS-SDR's ULP-PDUs having version set as 1.1, supl.google.com (the one in the config samples, and the ONLY SUPL server I know to exist) sends back version 3.0 packets,

ULP-PDU from GNSS-SDR:

ULP-PDU from supl.google.com:

The conversation looks like this (I had to disable "Allow subdissector to reassemble TCP segments" in the TCP Protocol settings in Wireshark), SYN is the start of an attempted connection, FIN is the closing of a connection (which supl.google.com sends after , and ACK is just TCP ensuring packets are delivered (they can be ignored, since it sends two ACK packets after supl.google.com sends FIN):

And here is with "Try heuristic sub-dissectors first":

This still leaves front-end-cal useless, and at all of the configs contain a SUPL configuration that does not work (even after trying different MCCs, MNCs, LACs, CIs, and even port 7256 (which is allegedly supposed to be non-SSL or something, I can't find any references to this anymore though).

;######### SUPL RRLP GPS assistance configuration #####
; Check https://www.mcc-mnc.com/
; On Android: https://play.google.com/store/apps/details?id=net.its_here.cellidinfo&hl=en
GNSS-SDR.SUPL_gps_enabled=false
GNSS-SDR.SUPL_read_gps_assistance_xml=false
GNSS-SDR.SUPL_gps_ephemeris_server=supl.google.com
GNSS-SDR.SUPL_gps_ephemeris_port=7275
GNSS-SDR.SUPL_gps_acquisition_server=supl.google.com
GNSS-SDR.SUPL_gps_acquisition_port=7275
GNSS-SDR.SUPL_MCC=244
GNSS-SDR.SUPL_MNC=5
GNSS-SDR.SUPL_LAC=0x59e2
GNSS-SDR.SUPL_CI=0x31b0

GNSS-SDR.SUPL_read_gps_assistance_xml works (I have no idea what purpose it serves with all of the GNSS-SDR.AGNSS_* parameters (which btw there is currently no way to set initial altitude), but front-end-cal is still broken because it requires the TOW (Time of Week) from SUPL, which is constantly changing, so I think we need to merge SUPL and XML, and add a new parameter to use the current system time (which on *NIX should always be UTC, perhaps also a leap seconds or time zone handler is in order, maybe a parameter for that too, until something like std::chrono::tai_clock is more widely supported by implementations (last I tried, it wasn't a part of the gcc/clang C++ headers, I got an implicit initialization isn't allowed error).

I cannot get a reliable fix and GNSS-SDR will happily search and search for satellites for hours but will never start tracking unless I have provided it with XML files (which can only be generated if GNSS-SDR gets them from the satellites, which it can't if it never tracks them because it isn't calibrated, and rinex2assist doesn't get compiled unless you specify -DENABLE_UNIT_TESTING_EXTRA=ON, -DENABLE_SYSTEM_TESTING_EXTRA=ON, or -DENABLE_FPGA=ON. GNSS-SDRLIB (not GNSS-SDR) is able to acquire and maintain a fix without any XML.