The baseline_locations_[train/test].csv files were generated using a
\nstandard Weighted Least Squares (WLS) approach run on the raw GNSS measurements. Similar
\nWLS implementations can be found in RTKLib and the public version of
\nAndroid GPS tools.
The baseline_locations_[train/test].csv files were generated using a
\nstandard Weighted Least Squares (WLS) approach run on the raw GNSS measurements. Similar
\nWLS implementations can be found in RTKLib and the public version of
\nAndroid GPS tools.
Is the data accurate? What if the data collection is wrong or the data is biased?
", "rawMarkdown": "Is the data accurate? What if the data collection is wrong or the data is biased?", "votes": null }, { "id": "1305196", "postDate": "05/13/2021 06:25:58", "content": "thanks for sharing details. Is it possible to get the working code for the outlined procedure as well?
", "rawMarkdown": "thanks for sharing details. Is it possible to get the working code for the outlined procedure as well?", "votes": null }, { "id": "1306176", "postDate": "05/13/2021 16:46:52", "content": "https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238583
", "rawMarkdown": "https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238583", "votes": null }, { "id": "1307920", "postDate": "05/14/2021 19:10:45", "content": "@sohier the link you provide is the link to the page we are reading right now. Is that intentional?
", "rawMarkdown": "sohier the link you provide is the link to the page we are reading right now. Is that intentional?", "votes": null }, { "id": "1308703", "postDate": "05/15/2021 11:57:05", "content": "\n", "rawMarkdown": ">Similar WLS implementations can be found in RTKLib and the public version of Android GPS tools.", "votes": null }, { "id": "1308704", "postDate": "05/15/2021 11:59:10", "content": "Similar WLS implementations can be found in RTKLib and the public version of Android GPS tools.
\n
What if the Earth is flat
", "rawMarkdown": "What if the Earth is flat", "votes": null }, { "id": "1322813", "postDate": "05/25/2021 17:41:01", "content": "Hi, @sohier, Thank you for sharing this!
\nI'm new to GNSS areas and currently I'm failed to reproduce the baseline result from \"*_derived.csv\". The reproduction code is shown at this notebook.
\nCurrently I'm confused about these following things:
\nHow to weight the dx from each signal's pseudorange. In official tools or Java version or 3rd party implementation, they use standard deviation of pseudorange to weight it. But as you mentioned here, we should use Raw::ReceivedSvTimeUncertaintyNanos
\nto weight each signal's pseudorange. Which is related to rawPrUncM in the drived version. But what does this mean, is there any mathematics for weight function?
Why we need to estimate isrbM? Does the Inter-Signal Range Bias between different signal should be a fix value? And how should we formulate the isrbM as states in weighted least squares?
Did the problem constellations in the drived version has already been filtered? Since lots of fields are related to filter the problem constellations.
Each epoch contains the signal received in 1s, but should we consider the movement of the object in this 1s in the baseline model? And should we also consider the receivedSvTimeInGpsNanos in WLS since the signal is recieved in different time?
Would you mind providing some information for these questions? Any suggestion would be super helpful to guide the new bird~
\nThanks in advance!
", "rawMarkdown": "Hi, @sohier, Thank you for sharing this!\n\nI'm new to GNSS areas and currently I'm failed to reproduce the baseline result from \"*_derived.csv\". The reproduction code is shown at [this notebook](https://www.kaggle.com/foreveryoung/least-squares-solution-from-gnss-derived-data).\n\nCurrently I'm confused about these following things:\n1. How to weight the dx from each signal's pseudorange. In [official tools](https://github.com/google/gps-measurement-tools/blob/master/opensource/WlsPvt.m#L26-L27) or [Java version](https://github.com/google/gps-measurement-tools/blob/master/GNSSLogger/pseudorange/src/main/java/com/google/location/lbs/gnss/gps/pseudorange/UserPositionVelocityWeightedLeastSquare.java#L438) or [3rd party implementation](https://github.com/commaai/laika/blob/66d1e0438fc5d490e33d1ef74ba4d763914efbe0/laika/raw_gnss.py#L311), they use standard deviation of pseudorange to weight it. But as you mentioned here, we should use `Raw::ReceivedSvTimeUncertaintyNanos`\nto weight each signal's pseudorange. Which is related to `rawPrUncM` in the drived version. But what does this mean, is there any mathematics for weight function?\n\n2. Why we need to estimate isrbM? Does the Inter-Signal Range Bias between different signal should be a fix value? And how should we formulate the isrbM as states in weighted least squares?\n\n3. Did the problem constellations in the drived version has already been filtered? Since lots of fields are related to filter the problem constellations.\n\n4. Each epoch contains the signal received in 1s, but should we consider the movement of the object in this 1s in the baseline model? And should we also consider the receivedSvTimeInGpsNanos in WLS since the signal is recieved in different time?\n\nWould you mind providing some information for these questions? Any suggestion would be super helpful to guide the new bird~\n\nThanks in advance!", "votes": null }, { "id": "1324448", "postDate": "05/27/2021 00:55:56", "content": "For question 1, it seems that the rawPrUncM equals PrSigmaM based on the calculation in here. With this information I tried to reproduce the WLS shown in official code at this notebook. But it still far away from the baseline result. Any idea about it?
", "rawMarkdown": "For question 1, it seems that the rawPrUncM equals PrSigmaM based on the calculation in [here](https://github.com/google/gps-measurement-tools/blob/master/opensource/ProcessGnssMeas.m#L98-L99). With this information I tried to reproduce the [WLS shown in official code](https://github.com/google/gps-measurement-tools/blob/master/opensource/WlsPvt.m#L62-L111) at [this notebook](https://www.kaggle.com/foreveryoung/least-squares-solution-from-gnss-derived-data). But it still far away from the baseline result. Any idea about it?", "votes": null } ], "comments": [ { "id": 1304641, "author_name": "maharsh011", "author_url": "", "post_date": "05/12/2021 18:49:14", "content": "Is the data accurate? What if the data collection is wrong or the data is biased?
", "votes": null, "replies": [ { "id": 1308704, "author_name": "avtobusbratiev", "author_url": "", "post_date": "05/15/2021 11:59:10", "content": "What if the Earth is flat
", "votes": null, "replies": [] } ] }, { "id": 1305196, "author_name": "emaerthin", "author_url": "", "post_date": "05/13/2021 06:25:58", "content": "thanks for sharing details. Is it possible to get the working code for the outlined procedure as well?
", "votes": null, "replies": [ { "id": 1306176, "author_name": "sohier", "author_url": "", "post_date": "05/13/2021 16:46:52", "content": "https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238583
", "votes": null, "replies": [] }, { "id": 1307920, "author_name": "cdeotte", "author_url": "", "post_date": "05/14/2021 19:10:45", "content": "@sohier the link you provide is the link to the page we are reading right now. Is that intentional?
", "votes": null, "replies": [] }, { "id": 1308703, "author_name": "avtobusbratiev", "author_url": "", "post_date": "05/15/2021 11:57:05", "content": "\n", "votes": null, "replies": [] } ] }, { "id": 1322813, "author_name": "foreveryoung", "author_url": "", "post_date": "05/25/2021 17:41:01", "content": "Similar WLS implementations can be found in RTKLib and the public version of Android GPS tools.
\n
Hi, @sohier, Thank you for sharing this!
\nI'm new to GNSS areas and currently I'm failed to reproduce the baseline result from \"*_derived.csv\". The reproduction code is shown at this notebook.
\nCurrently I'm confused about these following things:
\nHow to weight the dx from each signal's pseudorange. In official tools or Java version or 3rd party implementation, they use standard deviation of pseudorange to weight it. But as you mentioned here, we should use Raw::ReceivedSvTimeUncertaintyNanos
\nto weight each signal's pseudorange. Which is related to rawPrUncM in the drived version. But what does this mean, is there any mathematics for weight function?
Why we need to estimate isrbM? Does the Inter-Signal Range Bias between different signal should be a fix value? And how should we formulate the isrbM as states in weighted least squares?
Did the problem constellations in the drived version has already been filtered? Since lots of fields are related to filter the problem constellations.
Each epoch contains the signal received in 1s, but should we consider the movement of the object in this 1s in the baseline model? And should we also consider the receivedSvTimeInGpsNanos in WLS since the signal is recieved in different time?
Would you mind providing some information for these questions? Any suggestion would be super helpful to guide the new bird~
\nThanks in advance!
", "votes": null, "replies": [ { "id": 1324448, "author_name": "foreveryoung", "author_url": "", "post_date": "05/27/2021 00:55:56", "content": "For question 1, it seems that the rawPrUncM equals PrSigmaM based on the calculation in here. With this information I tried to reproduce the WLS shown in official code at this notebook. But it still far away from the baseline result. Any idea about it?
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "1304518": "The **baseline_locations_[train/test].csv** files were generated using a\nstandard Weighted Least Squares (WLS) approach run on the raw GNSS measurements. Similar\nWLS implementations can be found in [RTKLib](http://www.rtklib.com/) and the public version of\n[Android GPS tools](https://github.com/google/gps-measurement-tools).\n\n\n1. It uses measurements from all satellite constellations (GPS/GLO/BDS/GAL/QZS).\n Invalid measurements are discarded if:\n\n - the BiasUncertaintyNanos is larger or equal than 1E6\n - GnssClock values are invalid, e.g. FullBiasNanos is not a meaningful number\n - STATE_CODE_LOCK (for non-GAL E1) or STATE_GAL_E1BC_CODE_LOCK (for GAL E1) is not set\n - STATE_TOW_DECODED and STATE_TOW_KNOWN are not set for non-GLO signals\n - STATE_GLO_TOD_DECODED and STATE_GLO_TOD_KNOWN are not set for GLO signals,\n - CN0 is less than 20 dB-Hz\n - ReceivedSvTimeUncertaintyNanos is larger than 500 nanoseconds\n - Carrier frequency is out of nominal range of each band.\n\n\n2. It is based on pseudorange, which is the difference between satellite transmit time (Raw::[ReceivedSvTimeNanos](https://developer.android.com/reference/android/location/GnssMeasurement#getReceivedSvTimeNanos()) and signal arrival time Raw::[TimeNanos](https://developer.android.com/reference/android/location/GnssClock#getTimeNanos()) - Raw::[FullBiasNanos](https://developer.android.com/reference/android/location/GnssClock#getFullBiasNanos()) - Raw::[BiasNanos](https://developer.android.com/reference/android/location/GnssClock#getBiasNanos()).\n\n It doesn't utilize Raw::[AccumulatedDeltaRangeMeters](https://developer.android.com/reference/android/location/GnssMeasurement#getAccumulatedDeltaRangeMeters())\n nor Raw::[PseudorangeRateMetersPerSecond](https://developer.android.com/reference/android/location/GnssMeasurement#getPseudorangeRateMetersPerSecond()).\n\n\n a. The [Klobuchar ionosphere model](http://www.navipedia.net/index.php/Klobuchar_Ionospheric_Model)\n has been applied to correct the ionospheric delay.\n\n\n b. The [EGNOS troposphere model](http://espace.library.curtin.edu.au/cgi-bin/espace.pdf?file=/2008/11/13/file_1/18917)\n has been applied to correct the tropospheric delay.\n\n\n c. The ephemeris satellite clock model has been applied to correct the satellite clock bias and group delay.\n\n\n3. It uses Raw::[ReceivedSvTimeUncertaintyNanos](https://developer.android.com/reference/android/location/GnssMeasurement#getReceivedSvTimeUncertaintyNanos())\n to weight each signal's pseudorange.\n\n\n4. It has 4+N states, where 4 refers to the user's position in ECEF and clock offset (x, y, z, t), and N states are inter-signal biases (ISB) for the number of non-GPS-L1 signal types. For instance, if the device measures signals of GPS L1 frequency, GLO G1 frequency, GPS L5 frequency, GAL E1 frequency at the same epoch, the number of non-GPS-L1 signal types equals 3 (i.e. N=3).\n\n5. It uses the broadcast ephemeris to compute satellite positions and clock bias.\n\n