search

barbeau / gpstest

The #1 open-source Android GNSS/GPS test program
Apache License 2.0
1.73k stars 361 forks source link

Add carrier frequency in Status view #103

Closed barbeau closed 6 years ago

barbeau commented 6 years ago

Summary:

Android devices that support multiple GNSS carrier frequencies (e.g., L1+L5) will be commercially available soon - related:

From first link:

The BCM47755 can simultaneously receive the following signals:

GPS L1 C/A GLONASS L1 BeiDou (BDS) B1 QZSS L1 Galileo (GAL) E1 GPS L5 Galileo E5a QZSS L5

Currently, the app will show records in the Status view for all observed carrier frequencies - the GnssStatus.getCarrierFrequencyHz() documentation says:

For an L1, L5 receiver tracking a satellite on L1 and L5 at the same time, two measurements will be reported for this same satellite, in one all the values related to L1 will be filled, and in the other all of the values related to L5 will be filled.

However, the carrier frequencies for each record in the Status view aren't shown. Therefore, you can't tell which is an L1 signal and which is a L5 signal.

We should add a new column "Carrier (MHz)" to the Status view that shows the carrier frequency from getCarrierFrequencyHz() in MHz. It would be nice if we could add an indicator for the user-facing label as well (e.g., 1575.45 MHz (L1)).

Steps to reproduce:

  1. Open the app to Status view on a device that supports L1 and L5 signals

Expected behavior:

Indicate which records are L1 signals and which are L5 signals

Observed behavior:

L1 signals and L5 signals aren't labeled as such

Device and Android version:

Unknown

barbeau commented 6 years ago

WIP PR at https://github.com/barbeau/gpstest/pull/104

barbeau commented 6 years ago

Info on frequencies for various systems:

goldfndr commented 6 years ago
GNSS band frequency (MHz)
GPS L1 1575.42
GPS L2 1227.6
GPS L3 1381.05
GPS L4 1379.913
GPS L5 1176.45
GLONASS L1 1598.0625 - 1605.375
GLONASS L2 1242.9375 - 1248.625
GLONASS L3 1202.025 (centered at 1207.14 according to http://www.navipedia.net/index.php/GLONASS_Future_and_Evolutions, see also https://en.wikipedia.org/wiki/GLONASS#CDMA)
GLONASS L5 1176.45 (http://www.navipedia.net/index.php/GLONASS_Future_and_Evolutions)
QZSS L1 1575.42
QZSS L2 1227.6
QZSS L5 1176.45
QZSS LEX 1278.75
Galileo E1 1575.42
Galileo E5 1191.795
Galileo E5a 1176.45
Galileo E5b 1207.14
Galileo E6 1278.75
BeiDou B1 1561.098
BeiDou B1-2 1589.742
BeiDou B2 1207.14
BeiDou B2a 1176.45
BeiDou B3 1268.52
NavIC L5 1176.45
NavIC S 2492.028
GAGAN L1 1575.42 (http://gagan.aai.aero/gagan/sites/default/files/AIPS_2013_48.pdf)
Galaxy 15 L1 1575.42 (https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System#Space_segment_upgrades)
Galaxy 15 L5 1176.45 (https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System#Space_segment_upgrades)
Anik F1R L1 1575.42 (https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System#Space_segment_upgrades)
Anik F1R L5 1176.45 (https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System#Space_segment_upgrades)

Some information taken from http://www.navipedia.net/index.php/GNSS_signal For GLONASS L3, 1202.025 from Wikipedia, 1201 from Navipedia

EDIT

For GLONASS, see also https://www.novatel.com/assets/Documents/Papers/GLONASSOverview.pdf and http://www.navipedia.net/index.php/GLONASS_Future_and_Evolutions

barbeau commented 6 years ago

Thanks @goldfndr! That saved me a lot of copying and pasting! 😁

goldfndr commented 6 years ago

No problem.

The Wikipedia article for IRNSS specifies an additional frequency (S band) and the name of the other band (L5). I've updated the table.

barbeau commented 6 years ago

PR https://github.com/barbeau/gpstest/pull/104 now supports all carrier frequencies except those of IRNSS/NAVIC, as the Indian GNSS doesn't yet have a constant defined under the Android system class GnssStatus (I previously added support the Indian SBAS system GAGAN, which shows up under the system constant CONSTELLATION_SBAS). We can add support for IRNSS/NAVIC when the Android platform adds support. I've opened separate issue for this at https://github.com/barbeau/gpstest/issues/105.

goldfndr commented 6 years ago

I know this is merged, but...

Instead of DoubleMath.fuzzyEquals, you could just convert the MHz to an integer (via rounding). Then it becomes much simpler case statements instead of if/else. Well, other than the GLONASS ranges.

barbeau commented 6 years ago

@goldfndr True, although I've been burned by floating point equality enough to prefer to use a library instead of rolling my own. I'm also being a bit conservative here in regards to testing for equality (hence the 1 MHz tolerance) as I haven't seen any real numbers coming out of the carrier frequency API method. The only Oreo device I have access to is a Samsung Galaxy S8+ w/ the 8.0 beta, and it doesn't return any valid values (just 0.0). I don't want to roll out the app claiming it supports carrier frequencies and expecting exact numbers, and then have it massively fail on real data because the numbers coming out of the API aren't exact (and judging by sensor API history on Android, I'm expecting some weird values).

We can always revise this once we see some real data coming off the API if it seems consistent and high quality. PRs are always welcome too ;).

barbeau commented 6 years ago

Based on this post, it looks like Xiaomi Mi 8 is showing this carrier frequency value in the raw measurements for a Galileo satellite svid 19 when dumping the object to log in GnssLogger: 1.17645005E9

This appears to be the Galileo E5a frequency, which we have as 1176.45 MHz. So, looks like fuzzy matching is indeed necessary, as there is an extra 0.00000005E9 in there. I included some range information in the mapping from frequency to label, but off the top of my head I don't recall if this was within the tolerance. Need to investigate further.

barbeau commented 6 years ago

Also, for anyone who was following this issue and is interested in the current state-of-the industry regarding dual-frequency availability on commercial devices, I wrote a Medium article at: https://medium.com/@sjbarbeau/dual-frequency-gnss-on-android-devices-152b8826e1c

barbeau commented 6 years ago

I recently stumbled on this PDF: https://www.rohde-schwarz-usa.com/rs/324-UVH-477/images/Wireless_po_en_A1_0758-1029-82_v1600.pdf

...which includes documentation of GNSS carrier frequencies:

image

We should double-check this against the frequencies that we identified.

barbeau commented 6 years ago

Upon further review, it looks like everything matches with the exception of some of the GLONASS frequencies. I'm not going to change anything now, but we can reference this later if we have evidence of carrier frequencies not showing up properly in real devices that have dual-frequency GLONASS support.

ndoggac commented 6 years ago

WAAS GEO update per the Wiki

New GEO now operational: Eutelsat 117 West B | 131 | 44 | 117°W (Satellite Name & Details | PRN | NMEA | Location)

Coming in 2019, PRN 133 (which recently ceased transmission prior to PRN 131 coming online) will be re-used for the next GEO, currently going through IOT (in-orbit-testing). It is meant to replace PRN 135 (Galaxy 15), but there will be an overlap period where there will be 4 operational GEOs. It's unlikely any chipset would actually track/report 4 GEOs at once, but it might be wise to prepare for the future possibility in your code.

goldfndr commented 6 years ago

@ndoggac: I'm curious why you commented on this issue rather than on #100 or created a new issue.

As of less than 1 minute ago, I received a signal from PRN 133 with SNR 41.1 and Almanac and Ephemeris. Still not seeing 131.

Edit: can you cite which wiki you're referring to? And the name of the satellite that'll become the new 133 (especially if it's already in orbit)?

goldfndr commented 4 years ago

The upper frequencies I'd posted for GLONASS L1 and L2 were incorrect; apparently I'd multiplied by the wrong number (should've been 6 instead of 13). I've updated them to the correct numbers. See also GLONASS Signal Plan at ESA's navipedia.

barbeau commented 4 years ago

@goldfndr So currently for GLONASS I have:

                if (carrierFrequencyMhz >= 1598.0000f && carrierFrequencyMhz <= 1610.000f) {
                    // Actual range is 1598.0625 MHz to 1609.3125, but allow padding for float comparisons - #103
                    return "L1";
                } else if (carrierFrequencyMhz >= 1242.0000f && carrierFrequencyMhz <= 1252.000f) {
                    // Actual range is 1242.9375 - 1251.6875, but allow padding for float comparisons - #103
                    return "L2";
                }

You're saying this should change to:

                if (carrierFrequencyMhz >= 1598.0625f && carrierFrequencyMhz <= 1605.375f) {
                    return "L1";
                } else if (carrierFrequencyMhz >= 1242.9375f && carrierFrequencyMhz <= 1248.625f) {
                    return "L2";
                }

...?

goldfndr commented 4 years ago

Approximately correct.

The tests might need to change too, but I'm confident you knew that.

barbeau commented 4 years ago

Thanks, looks correct to me. I opened a new issue to fix this at https://github.com/barbeau/gpstest/issues/356.