Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking GPS: Engineering next-gen location at Uber (2018)

uber.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Rethinking GPS: Engineering next-gen location at Uber (2018)

#61

Post by londons_explore »

myself248 wrote: post #54
skzv wrote: post #12

Earlier quoted context omitted.

You may be interested in knowing that Android has exposed raw GNSS measurements through public APIs [0,1] so anybody can build their own raw processing engines using techniques like the ones described in the article [0] https://developer.android.com/guide/topics/sensors/gnss [1] https://developer.android.com/reference/android/location/Gns...

Is anyone actually doing that? I see a build of RTKLIB but it's not actually using the Android GNSS API, it's just using your Android phone as a processor to handle data coming from an external Ublox receiver. Aww.

The android API exposes basically the same data that would come down the serial link from a 90's era GPS receiver plugged into a PC.

That's the position estimate, information about satellite orbits, signal strengths and pseudoranges.

The data doesn't include the raw baseband information necessary to, for example, do carrier phase locking or to do a fully software implementation of GPS decoding.

Re: Rethinking GPS: Engineering next-gen location at Uber (2018)

#62

Post by londons_explore »

ciupicri wrote: post #56
sorenjan wrote: post #52

Earlier quoted context omitted.

Is it really so few? Snapdragon got support for dual frequency in Snapdragon 855 released in 2018. Use the GPSTest app to see if your phone supports it. https://github.com/barbeau/gpstest

Here are a couple of phones that don't have dual frequency: - Samsung Galaxy A53 5G ( https://www.gsmarena.com/samsung_galaxy_a53_5g-11268.php ) - Samsung Galaxy S10 ( https://www.gsmarena.com/samsung_galaxy_s10_5g-9588.php ) - Samsung Galaxy S20 ( https://www.gsmarena.com/samsung_galaxy_s20-10081.php ) - Nokia G60 ( https://www.gsmarena.com/nokia_g60-11826.php ) - Google Pixel 5 ( https://www.gsmarena.com/google_pix…

I suspect the main barrier is patents/licensing/product differentiation rather than the actual difficulty of adding one more PLL, mixer and ADC.

Besides, nearly every phone could receive GPS L5 with the radios in the cell modem if they had a suitable firmware update.

Re: Rethinking GPS: Engineering next-gen location at Uber (2018)

#63

Post by londons_explore »

Urban canyons will be properly solved by using small phased array antennas for GPS reception. Then one can detect which signals are coming from the wrong direction and therefore must be reflections.

Phased array antennas also allow GPS-based compasses which should be far better than magnetic compasses which can be rather inaccurate.

Such phased array antennas are already coming into use for more throughput for 5G and WiFi use, and antenna sharing is feasible although not currently done commonly.

Re: Rethinking GPS: Engineering next-gen location at Uber (2018)

#64

Post by skzv »

londons_explore wrote: post #61
myself248 wrote: post #54

Earlier quoted context omitted.

Is anyone actually doing that? I see a build of RTKLIB but it's not actually using the Android GNSS API, it's just using your Android phone as a processor to handle data coming from an external Ublox receiver. Aww.

The android API exposes basically the same data that would come down the serial link from a 90's era GPS receiver plugged into a PC. That's the position estimate, information about satellite orbits, signal strengths and pseudoranges. The data doesn't include the raw baseband information necessary to, for example, do carrier phase locking or to do a fully software implementation of GPS decoding.

It actually exposes carrier information to do carrier-wave positioning as well [0, 1]

There's also an API to specify an antenna pattern [2]

[0] https://developer.android.com/reference/android/location/Gns...()

[1] https://developer.android.com/reference/android/location/Gns...()

[2] https://developer.android.com/reference/android/location/Gns...

Re: Rethinking GPS: Engineering next-gen location at Uber (2018)

#65

Post by skzv »

CamperBob2 wrote: post #32
skzv wrote: post #16

Earlier quoted context omitted.

Not just that. It's a higher frequency so the correlation peaks are more narrow and hence more easily distinguishable than L1 frequency

That's not how it works at all. L5 at 1176 MHz has a different ionospheric delay than L1 at 1575 MHz. Since the timing data is identical, you can calculate and remove the ionospheric delay if you can receive both signals at once. Correlation peak width is an SNR property (and to a lesser extent dependent on receiver LO phase noise), not something that really corresponds to the RF band in use. Whichever signal is stro…

L5 is useful in many ways, but L5 really does produce more narrow correlation peaks than L1 as well [0]

[0] https://insidegnss-com.exactdn.com/wp-content/uploads/2021/0...

Re: Rethinking GPS: Engineering next-gen location at Uber (2018)

#66

Post by Avamander »

sorenjan wrote: post #52
ciupicri wrote: post #51

Earlier quoted context omitted.

Also E5 Galileo [1]. It's such a shame that so few smartphones have support for dual frequency GPS and Galileo. [1]: https://gssc.esa.int/navipedia/index.php/Galileo_Signal_Plan

Is it really so few? Snapdragon got support for dual frequency in Snapdragon 855 released in 2018. Use the GPSTest app to see if your phone supports it. https://github.com/barbeau/gpstest

iPhones got it just very recently. So at least half of tge market couldn't have it until recently.

Re: Rethinking GPS: Engineering next-gen location at Uber (2018)

#67

Post by CamperBob2 »

skzv wrote: post #65
CamperBob2 wrote: post #32

Earlier quoted context omitted.

That's not how it works at all. L5 at 1176 MHz has a different ionospheric delay than L1 at 1575 MHz. Since the timing data is identical, you can calculate and remove the ionospheric delay if you can receive both signals at once. Correlation peak width is an SNR property (and to a lesser extent dependent on receiver LO phase noise), not something that really corresponds to the RF band in use. Whichever signal is stro…

L5 is useful in many ways, but L5 really does produce more narrow correlation peaks than L1 as well [0] [0] https://insidegnss-com.exactdn.com/wp-content/uploads/2021/0...

Yes, that's an SNR advantage due to processing gain. Works out to more or less 10 * log10(RF signal bandwidth / baseband data bandwidth) dB.

They could have done something similar at L1, but that ship has pretty much sailed.

Re: Rethinking GPS: Engineering next-gen location at Uber (2018)

#68

Post by skzv »

CamperBob2 wrote: post #67
skzv wrote: post #65

Earlier quoted context omitted.

L5 is useful in many ways, but L5 really does produce more narrow correlation peaks than L1 as well [0] [0] https://insidegnss-com.exactdn.com/wp-content/uploads/2021/0...

Yes, that's an SNR advantage due to processing gain. Works out to more or less 10 * log10(RF signal bandwidth / baseband data bandwidth) dB. They could have done something similar at L1, but that ship has pretty much sailed.

I see, thanks for explaining

Re: Rethinking GPS: Engineering next-gen location at Uber (2018)

#69

Post by capableweb »

relaxing wrote: post #60
capableweb wrote: post #47

Earlier quoted context omitted.

Parent is talking about "urban canyons" which is just fancy wording for cities, while you're talking about actual canyons.

It’s the same problem.

Except the population density being different, I guess yeah.
Post reply on HN