GNSS pseudorange computation from raw measurements

[binghy17]

Hi all, I've a problem that is currently making me mad. Probably I lost the focus or I'm simply ignoring something stupid, at a certain point. I use a Xiaomi Mi 8 and a Huawei P10 to record the measurements, with duty cycle disabled on the Xiaomi to have correct ADR measurements recorded.

I followed all the tips suggested in the Google whitepaper to obtain the pseudorange, and, in the end, everything works fine. I have until now implemented raw measurement processing from GPS, Glonass, Beidou and Galileo on both the frequencies with Doppler-smoothing and with a WLS positioning solution. It works fine. I also generate a RINEX file at the end of the processing to be used on RTKlib with a reference station file, but most of the time I obtain RTK float as a best result.

I also used Rinex files coming from GEO++ Rinex Logger app and GNSS Logger app (even if it is not possible, most of the time, to record measurements at the same time on both the apps due to conflicts probably, and even if GNSS Logger crashes sometimes if Rinex recording is enabled).

Comparing measurements, especially the pseudorange (the phase is substantially different among the apps, the computation is quite different), I have a fixed bias, equal for all the satellites epoch by epoch, between my pseudorange measurements and those obtained with GNSS Logger app and GEO++ app. Am I missing something in the pseudorange computation? A fixed bias make me think to the receiver clock bias, but are not Rinex for recording purely raw measurements? I've noticed that, among the available parameters recorded by GNSS Logger app on the csv, there is one valorized (equal for all the sats) but never used: BiasUncertaintyNanos. Even if not mentioned in the whitepaper, do I have to take it into account in the pseudorange computation?

Moreover, I use FullBiasNanos at each epoch instead of using only the first value to avoid divergence between my pseudorange and GEO++/GNSSLogger pseudoranges. Is this to cause divergence step by step, as discussed here? (https://www.rokubun.cat/gnss-carrier-phase-nexus-9/)

Any suggestion would be very helpful

Thanks in advance

Marco

[V. Kelly Bellis]

Hello Marco,

It would help in understanding the discussion if/ when the you're talking only about the Huawei P10.

Huawei P10- Which Android Version and API Level is on this device? If we look at the GPSTest database, that single-frequency device, circa 2016, does not support carrier phase AccumulatedDeltaRangeMeters() (ADR).

It might help also, if the issues as they pertain to an individual device were clearly separated into a new thread; for example, the Xiaomi Mi 8. If we look at the GPSTest database, it seems that not every Mi 8 supports ADR. If you've shared your Mi * GPSTest reults already, please identify the date of that submission; otherwise, please consider running the test and sharing with the database.

Thank you.

Kind regards,

Kelly

[binghy17]

Hi, actually I did not load any test on the database, just found it a couple of days ago. I'll do it if necessary.

It is not a matter of device version, it's about the way pseudoranges are computed. I talked about Huawei P10 and Xiaomi Mi 8 because are the smartphones I have for tests, anyway I have the same kind of bias on the pseudorange for both comparing data with GNSSLogger pseudoranges (v3.0.0.1, on the Xiaomi) and GEO++ data (both on the Xiaomi and the Huawei), since it's a matter about its computation, I guess.

For the Huawei: Version: v2.0.0.1 Platform: 7.0 Manufacturer: HUAWEI Model: VTR-L09 (GNSSLogger app has still not been upgraded on the Huawei, so it's the old version). Anyway, you're correct in a certain wave, the Huawei P10 has ADR supported, but since an older API, it is not possible to disable duty cycle and so ADR (hence, phase) measurements are not continuous, therefore not correct.