new to GNSS, can I use NTRIP on server side of web service to correct mobile phone location while walking?

[amgando]

thanks for reading, i'm very new to this space so my question may not even make sense ...

i don't understand why I can't use an NTRIP client from a purely software service that i run in the cloud with something like gnssntripclient running on some interval, once every 30 seconds or so, to correct location information

it seems like NTRIP is always and only being used by some IoT device or similar hardware to correct GNSS position, never from purely a software service unless for testing purposes like gnssntripclient CLI utility.

i think i'm missing something pretty basic here. i'm assuming this setup is possible. can someone help set me straight?

• on mobile device
  • poll the geolocation API for(lat, lng, alt)
  • upload the location (or last N locations) to my server
• on server side
  • forward (lat, lng) to any NTRIP Caster using gnssntripclient or similar
  • receive a recommended NTRIP server as my closest available server
  • resend request to that specific server
  • receive NMEA response with location correction information
  • apply correction to location
  • send to mobile device
• on mobile device
  • update navigation visualization (map view or whatever)

i also recall reading something about the quality of location correction information degrading over time but i'm interested in 1 m, not 1 cm resolution, for the mobile phone in the pocket of a walking person

so even if i only do this round trip correction once every 30-60 seconds, it seems i should be able to correct the walker's position

given how simple my mental model seems, and yet I find no one is doing it this way (always with dedicated GNSS hardware receiving the correction information) i have to assume i'm fundamentally misunderstanding something about this entire NTRIP infrastructure

thanks in advance, any pointers would be much appreciated

again, i think the goal here is easily stated: "i want to correct mobile position on consumer hardware (iOS, Android, etc) using NTRIP"

[semuadmin]

Hi @amgando

This is beyond the scope of this PyGPSClient Discussion forum, but in essence there's nothing stopping you developing a bespoke NTRIP solution along the lines you describe. HOWEVER, It would not be a simple undertaking (probably not one for an RTK 'newbie') and I suspect it would be fairly cumbersome in operation. It might be useful to read this overview first.

Bear in mind that NTRIP is a localised RTK correction service which essentially enhances location accuracy by compensating for errors arising from local atmospheric (particularly ionospheric) distortions. The NTRIP correction data is generally only valid within a 30km radius of your location. So any cloud-based NTRIP solution you employed would need to track your mobile device's rough location and automatically select the most appropriate local NTRIP service (some third-party NTRIP service providers can do this automatically).

For the solution you describe to work, you would need to:

1. develop a bespoke app to leverage your mobile device's location API.
2. develop a cloud-based NTRIP client solution. I wouldn't necessarily recommend the gnssntripclient CLI utility for this purpose - it's really only intended to be used as a diagnostic and testing tool - but you could develop something using the underlying GNSSNTRIPClient Python class.
3. ensure you can maintain a reasonably steady and uninterrupted IP connection between your mobile device and your cloud-based NTRIP client (e.g. via 4G/5G). Bear mind that locations with poor GNSS reception may also have poor 4G/5G reception for much the same reasons.
4. develop a bespoke app capable of receiving and processing RTCM correction data from the cloud-based NTRIP client and presenting this as some kind of usable visualisation e.g. a vector on a moving map. This would require consummate knowledge of the proprietary RTCM protocol. Bear in mind that this 'heavy lifting' is normally done by an RTK-compatible GNSS receiver's proprietary firmware - the GNSS receivers built into most consumer mobile devices don't have this capability.

Note that there are plenty of proprietary NTRIP clients available for IOS or Android platforms - just do a search for 'NTRIP' on the Apple App Store or Google Play Store. However, these are generally designed to work with specialist RTK-compatible GNSS receivers that connect to the mobile device via Bluetooth or USB. They don't generally work with the device's built-in GNSS receiver.

Or you can buy a specialised portable device that is designed for high-resolution digital surveying, but these typically cost upwards of $1000.

Hope this helps

[amgando]

thanks for the super fast response, @semuadmin, very generous

i've read the linked overview a couple of times. about a third of it makes sense at this point. there's a lot going on there. 😅

The NTRIP correction data is generally only valid within a 30km radius of your location ... would need to track your mobile device's rough location and automatically select the most appropriate local NTRIP service

for sure, makes sense. as an alterative, the NTRIP casters could be ours, locally installed for "neighborhood" high accuracy activation within 30km range depending on how we go to market (we could offer free service to the first 10 people willing to maintain a healthy caster, for example, like this one https://www.sparkfun.com/products/22429)

you could develop something using the underlying GNSSNTRIPClient Python class.

for sure, makes sense, i'm not tied to the CLI diagnostic tool and i do appreciate the difference.

develop a bespoke app capable of receiving and processing RTCM correction data ... this would require consummate knowledge of the proprietary RTCM protocol ... this is normally done by an RTK-compatible GNSS receiver's proprietary firmware

i had assumed i could just use your pyrtcm for parsing responses. is that not the case? if casters aren't broadcasting RTCM 3 or better we can just assume them incompatible, expand the search or depoy our own, no?

if it's about speed or memory efficiency of parsing the messages, i imagine a fork of pyrtcm written in Rust would do the trick, for example.

but this may be one big thing i'm misunderstanding here: something about the calculation of the correction vector being so computationally intensive or only partially handled by pyrtcm as to require on-device handling by firmware which is why everyone is always talking about hooking up an RTK-compatible GNSS receiver instead of doing the calculation in software

[semuadmin]

develop a bespoke app capable of receiving and processing RTCM correction data ... this would require consummate knowledge of the proprietary RTCM protocol ... this is normally done by an RTK-compatible GNSS receiver's proprietary firmware

i had assumed i could just use your pyrtcm for parsing responses. is that not the case? if casters aren't broadcasting RTCM 3 or better we can just assume them incompatible, expand the search or depoy our own, no?

No, there's a fundamental misunderstanding here. The RTCM3 data sent by an NTRIP caster contains, among other things, the observable 'phase range' and 'range rate' of the GNSS carrier signal(s). By knowing this, you can apply a mathematical algorithm to calculate a more accurate 'pseudorange' (the distance between the satellite and receiver) - in RTK terms this is described as resolving the 'integer ambiguity search problem'. Once you have this, you can then apply a standard 'multilateration' algorithm to calculate the exact receiver (or strictly antenna) position to cm level accuracy. But - to be clear - neither the NTRIP client nor my pyrtcm library does these calculations for you - they simply send the raw RTCM data to an RTK-compatible receiver and the receiver itself implements the calculations in firmware. This is why you can't just use any old cheap USB GNSS receiver (or the basic GNSS receiver built into most consumer mobile devices) to process RTK data - you need a specialised RTK-compatible receiver such as the u-blox ZED-F9P, or some other hardware, firmware or software device that implements the same RTK calculations.

pyrtcm is simply an RTCM parser - that is, it takes a binary RTCM message and parses it into its constituent data fields, in accordance with the RTCM3 protocol (or at least those bits of it that are effectively in the public domain). What you do with the data is up to you - some people may use pyrtcm purely out of academic interest (e.g. atmospheric science); others may use it to feed their own 'RTK' implementation. Note that you don't have to parse the data in order to apply the corrections - you can simply upload the raw binary RTCM3 data directly to an RTK-compatible receiver and the receiver will do the rest.

There's nothing stopping you implementing the RTK calculations in your own code (this is what libraries like RTKLIB do) but to do this you would need to have a solid understanding of the proprietary RTCM protocol and the maths pertaining to RTK calculations. This is not for the faint-hearted :-)

Hope this makes sense. The bottom line is, consumer mobile devices are not designed to provide cm level location accuracy on their own.

[gdt]

I avoid the term "RTCM correction data" when talking about RTK. The data typically in RTCM2, typically for "differential GPS", is in fact corrections: a pseudorange error and a pseudorange rate error (and time of validity). Those are used to adjust observed pseudoranges, and essentially all GPS receivers accept and process them.

RTK is different. The data you get is more properly (IMHO!) called "reference data" and is the raw phase observable from a reference station. That needs RTK processing, which is either proprietary software in a chipset (higher-end ublox) or RTKLIB. I object to calling RTK reference data "corrections" because there is no process where anything observed is adjusted by them.

(And this is all off topic for this library as I understand it.)

[semuadmin]

Understood and agree, but the distinction is probably a little academic in this conversation which - as you say - is strictly off topic for PyGPSClient. But I try wherever possible to be a little more helpful than the 'off-topic' zealots on Stack Overflow, at least while the volume of queries is relatively low ;-)

[amgando]

No, there's a fundamental misunderstanding here.

omg, thank you!

yes, clearly, way off topic, i see that now

[semuadmin]

HI @amgando Don't worry about it being 'off-topic' - have these responses helped at all? If they have, I'd be grateful if you could flag the discussion as 'Answered'. Thanks

[amgando]

marked. yes, very helpful. i'm off trying to understand why we can't have a service-based RTKLIB -- why does it have to be implemented in hardware: the decoding of RTCM and applying corrections to the (lat, lng, alt) tuple.

your responses here have made the big picture clearer, thank you

[gdt]

RTKLIB is software. This processing is all software. It's just that it's usually proprietary software running in a GNSS receiver module.

For RTK, "the decoding of RTCM and applying corrections to the (lat, lng, alt) tuple." is fundamentally confused. These are not "corrections". They are reference data that is used to find a solution to a vast number of equations. I recommend seeking out books/papers about carrier phase processing, and the process of resolving the integer abiguities. Only when you understand that for static processing (e.g. 24h of data in one place) can you move on to understanding RTK. This is why I object to calling this data "corrections".

I first learned this in a graduate class using an earlier version of this textbook:

https://onlinelibrary.wiley.com/doi/book/10.1002/9781119018612

Beware that it presumes an understanding of linear algebra.

Another book I found useful is https://math.mit.edu/~gs/books/gps.html