{ "id": 324559, "title": "RTKlib queries", "url": "/competitions/smartphone-decimeter-2022/discussion/324559", "author_name": "", "post_date": "2022-05-12T09:21:04.255162900Z", "votes": 9, "comment_count": 9, "views": 0, "content": "

[Long post. Only relevant to anybody else who's working with RTKlib.]

\n

With many thanks to @timeverett for his great work with RTKlib, I've been trying to get to grips with it for the first time and have a few questions. Sorry if these are very basic/stupid questions, I'm completely new to this.

\n

[Edit: Questions struck through once I've fixed the problem / am happy that I understand what's going on.]

\n
    \n
  1. Is having navigation & observation data sufficient for RTKlib to use a particular constellation or are the base station observations (a) constellation-specific and (b) necessary? (I have a basic understanding of most of the file formats, but don't understand the base station observations yet.)
    2. \n
  2. Following on, is there some way for me to know which types of satellite have been used in the final solution and which ones ignored? I'm concerned that when I use rtkplot I only see G* satellites when in Residuals view. Is RTKlib able to use the GLONASS and Galileo observations as well?
    3. \n
    3. \n
    1. \n
    2. \n
    4. \n
  4. \n
  5. Comparing the RTK solutions to the provided training baselines, 13 were much worse (i.e. mostly >1km away, sometimes >10km). 3 were a little worse and the remainder were a little better. Any ideas what I need to do for the ones that are way off? (At the moment, I just say that if the two solutions differ by too much, use the baseline.)
    6. \n
  6. \n
  7. Whilst we're on field definitions…
      \n
    1. \n
    2. Why is age negative? Is that an artifact of doing a backwards pass?
    8. \n
\n

Thanks so much for any advice you can give. If there's anything that isn't clear or if it would be helpful for me to follow up with any log snippets or other information, I'm very happy to do that.

", "messages": [ { "id": "1785625", "postDate": "05/12/2022 09:21:04", "content": "

[Long post. Only relevant to anybody else who's working with RTKlib.]

\n

With many thanks to @timeverett for his great work with RTKlib, I've been trying to get to grips with it for the first time and have a few questions. Sorry if these are very basic/stupid questions, I'm completely new to this.

\n

[Edit: Questions struck through once I've fixed the problem / am happy that I understand what's going on.]

\n
    \n
  1. Is having navigation & observation data sufficient for RTKlib to use a particular constellation or are the base station observations (a) constellation-specific and (b) necessary? (I have a basic understanding of most of the file formats, but don't understand the base station observations yet.)
    2. \n
  2. Following on, is there some way for me to know which types of satellite have been used in the final solution and which ones ignored? I'm concerned that when I use rtkplot I only see G* satellites when in Residuals view. Is RTKlib able to use the GLONASS and Galileo observations as well?
    3. \n
    3. \n
    1. \n
    2. \n
    4. \n
  4. \n
  5. Comparing the RTK solutions to the provided training baselines, 13 were much worse (i.e. mostly >1km away, sometimes >10km). 3 were a little worse and the remainder were a little better. Any ideas what I need to do for the ones that are way off? (At the moment, I just say that if the two solutions differ by too much, use the baseline.)
    6. \n
  6. \n
  7. Whilst we're on field definitions…
      \n
    1. \n
    2. Why is age negative? Is that an artifact of doing a backwards pass?
    8. \n
\n

Thanks so much for any advice you can give. If there's anything that isn't clear or if it would be helpful for me to follow up with any log snippets or other information, I'm very happy to do that.

", "rawMarkdown": "\\[Long post. Only relevant to anybody else who's working with RTKlib.\\]\n\nWith many thanks to @timeverett for his great work with RTKlib, I've been trying to get to grips with it for the first time and have a few questions. Sorry if these are very basic/stupid questions, I'm completely new to this.\n\n\\[**Edit**: Questions struck through once I've fixed the problem / am happy that I understand what's going on.\\]\n\n1. Is having navigation & observation data sufficient for RTKlib to use a particular constellation or are the base station observations (a) constellation-specific and (b) necessary? (I have a basic understanding of most of the file formats, but don't understand the base station observations yet.)\n1. Following on, is there some way for me to know which types of satellite have been used in the final solution and which ones ignored? I'm concerned that when I use `rtkplot` I only see `G*` satellites when in `Residuals` view. Is RTKlib able to use the GLONASS and Galileo observations as well?\n1. ~~For the base station observations, I plan to use TRAK (rather than SLAC) for the LAX routes (because TRAK is much closer). Looking at SLAC, the antenna location coordinates in `ppk_slac.conf` differ from those reported in the SLAC observation headers (either the antenna details or the monument location) which in turn differ from those reported [here](https://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=slac&option=Coordinates14).~~\n 1. ~~How did you calculate the reference location as used in `ppk_slac.conf`?~~\n 1. ~~How would I compute equivalents for TRAK?~~\n 1. ~~Also, I notice from the link that these things are moving ~1cm per year. Is it worth trying to take account of that? (I realize that we're not at centimeter accuracy yet, but I'm not sure whether any errors are amplified through the calculations.)~~\n1. ~~For 11 of the (non-LAX) training routes, no solution is produced. (Specifically, the header lines are output, but there are no positions.) I also ran these manually with `rtkpost` (from the demo5 release) and tried to look through the trace file, but I couldn't make out what it thought the problem was from amongst all the other information. Any tips on either what the problem might be or how I can go about debugging this?~~\n1. Comparing the RTK solutions to the provided training baselines, ~~17~~ 13 were much worse (i.e. mostly >1km away, sometimes >10km). 3 were a little worse and the remainder were a little better. Any ideas what I need to do for the ones that are way off? (At the moment, I just say that if the two solutions differ by too much, use the baseline.)\n1. ~~Can you tell me anything more about the Q values? The header states `Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp`. When I look at the plots, Q=2 (most common, ~98% of locations) seems to mean good and Q=4 seems to be where things have gone a little dodgy (vehicle under a bridge, etc.). I would have thought that having a DGPS position would be a good thing, so what does this really mean?~~\n1. Whilst we're on field definitions...\n 1. ~~What are `sdn(m) sde(m) sdu(m) sdne(m) sdeu(m) sdun(m)`?~~\n 1. Why is age negative? Is that an artifact of doing a backwards pass?\n\nThanks so much for any advice you can give. If there's anything that isn't clear or if it would be helpful for me to follow up with any log snippets or other information, I'm very happy to do that.", "votes": null }, { "id": "1786086", "postDate": "05/12/2022 15:42:24", "content": "

Good questions! I'll attempt to answer them below:

\n
    \n

  1. To include a GNSS constellation in the solution, RTKLIB requires rover observations, base observations, and satellite navigation data for that constellation. The base observations are in the identical format of the rover observations, specifically pseudorange, carrier phase, doppler, and signal strength measurements by satellite and epoch.

    2. \n

  2. Looking at the plotted residuals after plotting the solution in RTKLIB is a good way to see which satellites were used in the solution. Another option if you want to get more details is to enable debug trace level 3 when generating the solutions and then review the debug trace file. The solutions in this exercise should include only GPS, GLONASS, and Galileo constellations since that is what is generally available in the CORS base station observations. If a constellation is not included in the solution, the most likely reason is that either the base observations or the navigation data did not include satellites from that constellation.

    3. \n

  3. The TRAK CORS base station would not be a good choice for the LAX data because it does not include Galileo observations. I used the VDCY CORS station for my LAX solutions. I'm not quite sure why my location for the SLAC base is slightly different from the coordinates in your link. Most likely they are for different dates since the base station is moving with the tectonic plates relative to the WGS84/ITRF 2014 coordinate system. Any error in the base location will cause an equal sized error in the solution assuming the errors are not larger than a few meters.

    4. \n

  4. I don't know why 11 of the non-LAX routes did not generate solutions for you. I would suggest setting the trace level to 2 when running the solution to reduce the amount of information in the trace file irrelevant to the failure. You can also reference my RTKLIB notebook in the code section. I was able to generate solutions for all of the training set. However some of these data sets have large numbers of hardware clock discontinuities and the RTKLIB solutions for these will be of poor quality since the carrier phase information is corrupted by the clock discontinuities. You can identify these data sets by looking at the HardwareClockDiscontinuityCount in the raw Android log files. If this number is incrementing during the log, then the carrier phase values will be very poor. One more suggestion is that there are some minor robustness improvements in the latest demo5 version (b34f) of RTKLIB relative to the version in my GDSC-2021 release package which may help. To duplicate my results exactly you will need to use the very latest version of the demo5 RTKLIB source code which is available in my Github repository but you will have to compile this yourself. I have rtklibexplorer blog posts describing how to compile the code for both Windows and linux.

    5. \n

  5. The hardware clock discontinues probably explain at least some of your poor results. In my submission for the test set, I replaced the RTKLIB solutions with the Google baseline solutions for the two data sets that had hardware clock discontinuities. The Google baseline solutions do not use the carrier phase measurements so are not affected by the clock discontinuities.

    6. \n

  6. There is a Q value for each solution point which refers to how that point was calculated. You will only see values of 2,4, or 5 in these solutions. Q=2:float indicates a differential (PPK) solution using pseudoranges and carrier phases. Q=4:dgps indicates a differential solution using only the pseudoranges and so will be of lower accuracy than the float solution. Q=5:single indicates a standard precision absolute solution and will be the lowest accuracy.

    7. \n

  7. Sdn(m), sde(m), and sdu(m) are accuracy estimates of the solution points in meters in ENU coordinates and are standard deviations. These will tend to be optimistic since they are direct outputs of the kalman filter which assumes all inputs are normally distributed and uncorrelated, neither of which is true for the GNSS inputs. These values are more useful if used as relative accuracies between solution points, rather than absolute accuracies. The last three values (sdne(m), sdeu(m), and sdun(m)) are used to recreate the full covariance matrix for each solution point and are of less interest for most users.

    8. \n
", "rawMarkdown": "Good questions! I'll attempt to answer them below:\n\n1. To include a GNSS constellation in the solution, RTKLIB requires rover observations, base observations, and satellite navigation data for that constellation. The base observations are in the identical format of the rover observations, specifically pseudorange, carrier phase, doppler, and signal strength measurements by satellite and epoch.\n\n2. Looking at the plotted residuals after plotting the solution in RTKLIB is a good way to see which satellites were used in the solution. Another option if you want to get more details is to enable debug trace level 3 when generating the solutions and then review the debug trace file. The solutions in this exercise should include only GPS, GLONASS, and Galileo constellations since that is what is generally available in the CORS base station observations. If a constellation is not included in the solution, the most likely reason is that either the base observations or the navigation data did not include satellites from that constellation.\n\n3. The TRAK CORS base station would not be a good choice for the LAX data because it does not include Galileo observations. I used the VDCY CORS station for my LAX solutions. I'm not quite sure why my location for the SLAC base is slightly different from the coordinates in your link. Most likely they are for different dates since the base station is moving with the tectonic plates relative to the WGS84/ITRF 2014 coordinate system. Any error in the base location will cause an equal sized error in the solution assuming the errors are not larger than a few meters.\n\n4. I don't know why 11 of the non-LAX routes did not generate solutions for you. I would suggest setting the trace level to 2 when running the solution to reduce the amount of information in the trace file irrelevant to the failure. You can also reference my RTKLIB notebook in the code section. I was able to generate solutions for all of the training set. However some of these data sets have large numbers of hardware clock discontinuities and the RTKLIB solutions for these will be of poor quality since the carrier phase information is corrupted by the clock discontinuities. You can identify these data sets by looking at the HardwareClockDiscontinuityCount in the raw Android log files. If this number is incrementing during the log, then the carrier phase values will be very poor. One more suggestion is that there are some minor robustness improvements in the latest demo5 version (b34f) of RTKLIB relative to the version in my GDSC-2021 release package which may help. To duplicate my results exactly you will need to use the very latest version of the demo5 RTKLIB source code which is available in my Github repository but you will have to compile this yourself. I have rtklibexplorer blog posts describing how to compile the code for both Windows and linux.\n\n5. The hardware clock discontinues probably explain at least some of your poor results. In my submission for the test set, I replaced the RTKLIB solutions with the Google baseline solutions for the two data sets that had hardware clock discontinuities. The Google baseline solutions do not use the carrier phase measurements so are not affected by the clock discontinuities.\n\n6. There is a Q value for each solution point which refers to how that point was calculated. You will only see values of 2,4, or 5 in these solutions. Q=2:float indicates a differential (PPK) solution using pseudoranges and carrier phases. Q=4:dgps indicates a differential solution using only the pseudoranges and so will be of lower accuracy than the float solution. Q=5:single indicates a standard precision absolute solution and will be the lowest accuracy.\n\n7. Sdn(m), sde(m), and sdu(m) are accuracy estimates of the solution points in meters in ENU coordinates and are standard deviations. These will tend to be optimistic since they are direct outputs of the kalman filter which assumes all inputs are normally distributed and uncorrelated, neither of which is true for the GNSS inputs. These values are more useful if used as relative accuracies between solution points, rather than absolute accuracies. The last three values (sdne(m), sdeu(m), and sdun(m)) are used to recreate the full covariance matrix for each solution point and are of less interest for most users.", "votes": null }, { "id": "1786162", "postDate": "05/12/2022 16:41:51", "content": "

Thanks for the detailed reply @timeverett. It'll take a while for me to digest it, but one immediate follow-up…

\n

What position are you using for VDCY? From here I get.

\n
       Latitude (N is +)      : +341042.83\n       Longitude (E is +)     : -1181312.00\n       Elevation (m,ellips.)  : 318.197\n
\n

From here I have 6 different possibilities (the ARP, the L1 Phase Center or the \"Monument\", whatever that is, in either of IRTF2014 or NAD_83 - where I assume I want IRTF2014). And then there are different positions again in the downloaded base files.

\n
\n

In the end I went with…

\n
ant2-pos1          =34.17856563611 # (deg|m)\nant2-pos2          =-118.22000054722 # (deg|m)\nant2-pos3          =318.246 # (m|m)\n
\n

…which is, at least, producing non-empty solutions.

", "rawMarkdown": "Thanks for the detailed reply @timeverett. It'll take a while for me to digest it, but one immediate follow-up...\n\nWhat position are you using for VDCY? From [here](https://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=vdcy&option=Logfile) I get.\n\n```\n Latitude (N is +) : +341042.83\n Longitude (E is +) : -1181312.00\n Elevation (m,ellips.) : 318.197\n```\n\nFrom [here](https://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=vdcy&option=Coordinates14) I have 6 different possibilities (the ARP, the L1 Phase Center or the \"Monument\", whatever that is, in either of IRTF2014 or NAD_83 - where I assume I want IRTF2014). And then there are different positions again in the downloaded base files.\n\n---\n\nIn the end I went with...\n\n```\nant2-pos1 =34.17856563611 # (deg|m)\nant2-pos2 =-118.22000054722 # (deg|m)\nant2-pos3 =318.246 # (m|m)\n```\n\n...which is, at least, producing non-empty solutions.", "votes": null }, { "id": "1786236", "postDate": "05/12/2022 17:54:34", "content": "

I used the ARP ITRF2014 coordinates from here. You can get to this page from the map page at the CORS user-friendly site https://www.ngs.noaa.gov/UFCORS/

", "rawMarkdown": "I used the ARP ITRF2014 coordinates from [here](https://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=vdcy&option=Coordinates14). You can get to this page from the map page at the CORS user-friendly site https://www.ngs.noaa.gov/UFCORS/", "votes": null }, { "id": "1787213", "postDate": "05/13/2022 17:03:46", "content": "

Just in case you're interested, @timeverett (and anybody else using rtklib), I got to the bottom of the 11 MTV training routes that I couldn't get a solution for at all.

\n\n
\n

Edit: Glad I checked: There are 5 training samples that go over a date boundary. 4/5 of them appear in the \"17 were much worse\" category in Q5. (The others are presumably hardware clock discontinuities as you suggested - I haven't checked yet.) Having fetched data for the next day too, these also work better. The good news is that none of the test samples have this \"feature\".

", "rawMarkdown": "Just in case you're interested, @timeverett (and anybody else using rtklib), I got to the bottom of the 11 MTV training routes that I couldn't get a solution for at all.\n\n- For 3/11 (all within `2021-07-27-US-MTV-1`), SLAC was in the middle of a 4-day outage, so base data is unavailable and the website returns an error. I've used P176 for these instead. Not sure if picking one that's 400m up a hillside was the best idea, but at least it has a solution now.\n- 8/11 of them have a directory name which implies the routes were driven on a particular date (e.g. 2020-06-24-US-MTV-1) but actually the routes were driven at some point in the early hours of the following morning. (Could be a daylight saving thing, but some are more than an hour out, so probably not.) I pulled base & nav data according to the directory name, which was therefore not useful to `rtkpost`. Having fetched the right data, these work fine. I guess I should also check whether any of the routes straddle a midnight boundary.\n\n---\n\n**Edit**: Glad I checked: There are 5 training samples that go over a date boundary. 4/5 of them appear in the \"17 were much worse\" category in Q5. (The others are presumably hardware clock discontinuities as you suggested - I haven't checked yet.) Having fetched data for the next day too, these also work better. The good news is that none of the test samples have this \"feature\".", "votes": null }, { "id": "1790120", "postDate": "05/14/2022 14:34:10", "content": "

It sounds like you mostly figured it out on your own but I will add a few comments.

\n

The observation and navigation file dates are based on UTC time which is 8 hours later than the local time so any data collected late in the afternoon will require base observation files from the following UTC day. For the rides that cross the day boundary, the NGS User Friendly CORS site makes it easy to retrieve base observations in a single file that cross the day boundary. Navigation data from the end of one day will still be useful for the beginning of the following day so it usually won't be necessary to get an additional navigation file for these rides.

\n

As you mentioned, this issue only affects rides in the training set, the rides in the test set are all contained within one UTC day.

", "rawMarkdown": "It sounds like you mostly figured it out on your own but I will add a few comments. \n\nThe observation and navigation file dates are based on UTC time which is 8 hours later than the local time so any data collected late in the afternoon will require base observation files from the following UTC day. For the rides that cross the day boundary, the [NGS User Friendly CORS site](https://www.ngs.noaa.gov/UFCORS/) makes it easy to retrieve base observations in a single file that cross the day boundary. Navigation data from the end of one day will still be useful for the beginning of the following day so it usually won't be necessary to get an additional navigation file for these rides. \n\nAs you mentioned, this issue only affects rides in the training set, the rides in the test set are all contained within one UTC day.", "votes": null }, { "id": "1799502", "postDate": "05/24/2022 02:32:43", "content": "

Experimenting with RTKLIB as well, and probably a bit stupid question, but how do you access navigation data BRDM files? Following the link https://igs.bkg.bund.de/root_ftp/IGS/BRDC/ only gives me 2022 data. How to get 2021?

", "rawMarkdown": "Experimenting with RTKLIB as well, and probably a bit stupid question, but how do you access navigation data BRDM files? Following the link https://igs.bkg.bund.de/root_ftp/IGS/BRDC/ only gives me 2022 data. How to get 2021?", "votes": null }, { "id": "1800057", "postDate": "05/24/2022 15:13:58", "content": "

The IGS navigation data has become more difficult to access since I wrote my original blog post on the 2021 data which referenced that link. For this year's data I chose to pull the navigation data from the UNAVCO website. The first block of code in my \"Getting Started With RTKLIB\" notebook will automatically pull the navigation data for all of the rides in the 2022 test data set.

", "rawMarkdown": "The IGS navigation data has become more difficult to access since I wrote my original blog post on the 2021 data which referenced that link. For this year's data I chose to pull the navigation data from the [UNAVCO website](https://data.unavco.org/archive/gnss/rinex3/nav). The first block of code in my \"[Getting Started With RTKLIB](https://www.kaggle.com/code/timeverett/getting-started-with-rtklib)\" notebook will automatically pull the navigation data for all of the rides in the 2022 test data set.", "votes": null }, { "id": "1851763", "postDate": "07/11/2022 14:06:40", "content": "

For anyone using my \"Getting Started with RTKLIB\" notebook, I have just made a few updates to the notebook that may be of interest.

\n

When I originally released this notebook a couple of months ago, the resulting score was 3.135 which was good enough to tie for first place. Since then the scores have improved significantly and this score is no longer low enough to be competitive. I have just made a couple of changes to the notebook to improve the resulting score to 2.67 which as of today is good enough to get you into 27th place out of 461 entries.

\n

The two changes I made were to update the base station locations to account for tectonic plate movement and to replace the rides with hardware clock discontinuities on a point by point basis instead of the entire data set. I also added a few sort() statements to correct an issue when the code was not run in Windows.

", "rawMarkdown": "For anyone using my \"Getting Started with RTKLIB\" notebook, I have just made a few updates to the notebook that may be of interest.\n\nWhen I originally released this notebook a couple of months ago, the resulting score was 3.135 which was good enough to tie for first place. Since then the scores have improved significantly and this score is no longer low enough to be competitive. I have just made a couple of changes to the notebook to improve the resulting score to 2.67 which as of today is good enough to get you into 27th place out of 461 entries.\n\nThe two changes I made were to update the base station locations to account for tectonic plate movement and to replace the rides with hardware clock discontinuities on a point by point basis instead of the entire data set. I also added a few sort() statements to correct an issue when the code was not run in Windows.", "votes": null }, { "id": "1862172", "postDate": "07/19/2022 13:54:32", "content": "

[This comment is identical to one I've left on the notebook.]

\n

As Tolstoy might have said, every unsuccessful coding session is unsuccesful in its own way. Nonetheless, a couple of tips from my (more extensive than I'd planned) experience with getting RTKLIB up and running might help someone reading this.

\n

Most of my problems arose from the code not liking Windows paths.

\n

My initial problem turned out to be that I'd tried to run the code from a Windows folder with a space in its name, which threw an error. I tried again in a folder with no space in the name.

\n

Secondly, the python needed to be told explicitly about Windows paths. Thus, in step4, I had to change the code to read:

\n

if 'rtklib-py/src' not in sys.path:
\n sys.path.append('rtklib-py/src')
\nif 'android_rinex/src' not in sys.path:
\n sys.path.append('android_rinex/src')
\nif r'D:\\GSDC_2022\\python' not in sys.path:
\n sys.path.append(r'D:\\GSDC_2022\\python')
\nif r'D:\\GSDC_2022\\python\\android_rinex\\src' not in sys.path:
\n sys.path.append(r'D:\\GSDC_2022\\python\\android_rinex\\src')

", "rawMarkdown": "[This comment is identical to one I've left on the notebook.]\n\nAs Tolstoy might have said, every unsuccessful coding session is unsuccesful in its own way. Nonetheless, a couple of tips from my (more extensive than I'd planned) experience with getting RTKLIB up and running might help someone reading this.\n\nMost of my problems arose from the code not liking Windows paths. \n\nMy initial problem turned out to be that I'd tried to run the code from a Windows folder with a space in its name, which threw an error. I tried again in a folder with no space in the name.\n \nSecondly, the python needed to be told explicitly about Windows paths. Thus, in step4, I had to change the code to read:\n\nif 'rtklib-py/src' not in sys.path:\n sys.path.append('rtklib-py/src')\nif 'android_rinex/src' not in sys.path:\n sys.path.append('android_rinex/src')\nif r'D:\\GSDC_2022\\python' not in sys.path:\n sys.path.append(r'D:\\GSDC_2022\\python')\nif r'D:\\GSDC_2022\\python\\android_rinex\\src' not in sys.path:\n sys.path.append(r'D:\\GSDC_2022\\python\\android_rinex\\src')", "votes": null } ], "comments": [ { "id": 1786086, "author_name": "timeverett", "author_url": "", "post_date": "05/12/2022 15:42:24", "content": "

Good questions! I'll attempt to answer them below:

\n
    \n

  1. To include a GNSS constellation in the solution, RTKLIB requires rover observations, base observations, and satellite navigation data for that constellation. The base observations are in the identical format of the rover observations, specifically pseudorange, carrier phase, doppler, and signal strength measurements by satellite and epoch.

    2. \n

  2. Looking at the plotted residuals after plotting the solution in RTKLIB is a good way to see which satellites were used in the solution. Another option if you want to get more details is to enable debug trace level 3 when generating the solutions and then review the debug trace file. The solutions in this exercise should include only GPS, GLONASS, and Galileo constellations since that is what is generally available in the CORS base station observations. If a constellation is not included in the solution, the most likely reason is that either the base observations or the navigation data did not include satellites from that constellation.

    3. \n

  3. The TRAK CORS base station would not be a good choice for the LAX data because it does not include Galileo observations. I used the VDCY CORS station for my LAX solutions. I'm not quite sure why my location for the SLAC base is slightly different from the coordinates in your link. Most likely they are for different dates since the base station is moving with the tectonic plates relative to the WGS84/ITRF 2014 coordinate system. Any error in the base location will cause an equal sized error in the solution assuming the errors are not larger than a few meters.

    4. \n

  4. I don't know why 11 of the non-LAX routes did not generate solutions for you. I would suggest setting the trace level to 2 when running the solution to reduce the amount of information in the trace file irrelevant to the failure. You can also reference my RTKLIB notebook in the code section. I was able to generate solutions for all of the training set. However some of these data sets have large numbers of hardware clock discontinuities and the RTKLIB solutions for these will be of poor quality since the carrier phase information is corrupted by the clock discontinuities. You can identify these data sets by looking at the HardwareClockDiscontinuityCount in the raw Android log files. If this number is incrementing during the log, then the carrier phase values will be very poor. One more suggestion is that there are some minor robustness improvements in the latest demo5 version (b34f) of RTKLIB relative to the version in my GDSC-2021 release package which may help. To duplicate my results exactly you will need to use the very latest version of the demo5 RTKLIB source code which is available in my Github repository but you will have to compile this yourself. I have rtklibexplorer blog posts describing how to compile the code for both Windows and linux.

    5. \n

  5. The hardware clock discontinues probably explain at least some of your poor results. In my submission for the test set, I replaced the RTKLIB solutions with the Google baseline solutions for the two data sets that had hardware clock discontinuities. The Google baseline solutions do not use the carrier phase measurements so are not affected by the clock discontinuities.

    6. \n

  6. There is a Q value for each solution point which refers to how that point was calculated. You will only see values of 2,4, or 5 in these solutions. Q=2:float indicates a differential (PPK) solution using pseudoranges and carrier phases. Q=4:dgps indicates a differential solution using only the pseudoranges and so will be of lower accuracy than the float solution. Q=5:single indicates a standard precision absolute solution and will be the lowest accuracy.

    7. \n

  7. Sdn(m), sde(m), and sdu(m) are accuracy estimates of the solution points in meters in ENU coordinates and are standard deviations. These will tend to be optimistic since they are direct outputs of the kalman filter which assumes all inputs are normally distributed and uncorrelated, neither of which is true for the GNSS inputs. These values are more useful if used as relative accuracies between solution points, rather than absolute accuracies. The last three values (sdne(m), sdeu(m), and sdun(m)) are used to recreate the full covariance matrix for each solution point and are of less interest for most users.

    8. \n
", "votes": null, "replies": [] }, { "id": 1786162, "author_name": "andrewrrose", "author_url": "", "post_date": "05/12/2022 16:41:51", "content": "

Thanks for the detailed reply @timeverett. It'll take a while for me to digest it, but one immediate follow-up…

\n

What position are you using for VDCY? From here I get.

\n
       Latitude (N is +)      : +341042.83\n       Longitude (E is +)     : -1181312.00\n       Elevation (m,ellips.)  : 318.197\n
\n

From here I have 6 different possibilities (the ARP, the L1 Phase Center or the \"Monument\", whatever that is, in either of IRTF2014 or NAD_83 - where I assume I want IRTF2014). And then there are different positions again in the downloaded base files.

\n
\n

In the end I went with…

\n
ant2-pos1          =34.17856563611 # (deg|m)\nant2-pos2          =-118.22000054722 # (deg|m)\nant2-pos3          =318.246 # (m|m)\n
\n

…which is, at least, producing non-empty solutions.

", "votes": null, "replies": [ { "id": 1851763, "author_name": "timeverett", "author_url": "", "post_date": "07/11/2022 14:06:40", "content": "

For anyone using my \"Getting Started with RTKLIB\" notebook, I have just made a few updates to the notebook that may be of interest.

\n

When I originally released this notebook a couple of months ago, the resulting score was 3.135 which was good enough to tie for first place. Since then the scores have improved significantly and this score is no longer low enough to be competitive. I have just made a couple of changes to the notebook to improve the resulting score to 2.67 which as of today is good enough to get you into 27th place out of 461 entries.

\n

The two changes I made were to update the base station locations to account for tectonic plate movement and to replace the rides with hardware clock discontinuities on a point by point basis instead of the entire data set. I also added a few sort() statements to correct an issue when the code was not run in Windows.

", "votes": null, "replies": [] } ] }, { "id": 1786236, "author_name": "timeverett", "author_url": "", "post_date": "05/12/2022 17:54:34", "content": "

I used the ARP ITRF2014 coordinates from here. You can get to this page from the map page at the CORS user-friendly site https://www.ngs.noaa.gov/UFCORS/

", "votes": null, "replies": [] }, { "id": 1787213, "author_name": "andrewrrose", "author_url": "", "post_date": "05/13/2022 17:03:46", "content": "

Just in case you're interested, @timeverett (and anybody else using rtklib), I got to the bottom of the 11 MTV training routes that I couldn't get a solution for at all.

\n\n
\n

Edit: Glad I checked: There are 5 training samples that go over a date boundary. 4/5 of them appear in the \"17 were much worse\" category in Q5. (The others are presumably hardware clock discontinuities as you suggested - I haven't checked yet.) Having fetched data for the next day too, these also work better. The good news is that none of the test samples have this \"feature\".

", "votes": null, "replies": [ { "id": 1790120, "author_name": "timeverett", "author_url": "", "post_date": "05/14/2022 14:34:10", "content": "

It sounds like you mostly figured it out on your own but I will add a few comments.

\n

The observation and navigation file dates are based on UTC time which is 8 hours later than the local time so any data collected late in the afternoon will require base observation files from the following UTC day. For the rides that cross the day boundary, the NGS User Friendly CORS site makes it easy to retrieve base observations in a single file that cross the day boundary. Navigation data from the end of one day will still be useful for the beginning of the following day so it usually won't be necessary to get an additional navigation file for these rides.

\n

As you mentioned, this issue only affects rides in the training set, the rides in the test set are all contained within one UTC day.

", "votes": null, "replies": [] } ] }, { "id": 1799502, "author_name": "rytisva88", "author_url": "", "post_date": "05/24/2022 02:32:43", "content": "

Experimenting with RTKLIB as well, and probably a bit stupid question, but how do you access navigation data BRDM files? Following the link https://igs.bkg.bund.de/root_ftp/IGS/BRDC/ only gives me 2022 data. How to get 2021?

", "votes": null, "replies": [ { "id": 1800057, "author_name": "timeverett", "author_url": "", "post_date": "05/24/2022 15:13:58", "content": "

The IGS navigation data has become more difficult to access since I wrote my original blog post on the 2021 data which referenced that link. For this year's data I chose to pull the navigation data from the UNAVCO website. The first block of code in my \"Getting Started With RTKLIB\" notebook will automatically pull the navigation data for all of the rides in the 2022 test data set.

", "votes": null, "replies": [] } ] }, { "id": 1862172, "author_name": "jbomitchell", "author_url": "", "post_date": "07/19/2022 13:54:32", "content": "

[This comment is identical to one I've left on the notebook.]

\n

As Tolstoy might have said, every unsuccessful coding session is unsuccesful in its own way. Nonetheless, a couple of tips from my (more extensive than I'd planned) experience with getting RTKLIB up and running might help someone reading this.

\n

Most of my problems arose from the code not liking Windows paths.

\n

My initial problem turned out to be that I'd tried to run the code from a Windows folder with a space in its name, which threw an error. I tried again in a folder with no space in the name.

\n

Secondly, the python needed to be told explicitly about Windows paths. Thus, in step4, I had to change the code to read:

\n

if 'rtklib-py/src' not in sys.path:
\n sys.path.append('rtklib-py/src')
\nif 'android_rinex/src' not in sys.path:
\n sys.path.append('android_rinex/src')
\nif r'D:\\GSDC_2022\\python' not in sys.path:
\n sys.path.append(r'D:\\GSDC_2022\\python')
\nif r'D:\\GSDC_2022\\python\\android_rinex\\src' not in sys.path:
\n sys.path.append(r'D:\\GSDC_2022\\python\\android_rinex\\src')

", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "1785625": "\\[Long post. Only relevant to anybody else who's working with RTKlib.\\]\n\nWith many thanks to @timeverett for his great work with RTKlib, I've been trying to get to grips with it for the first time and have a few questions. Sorry if these are very basic/stupid questions, I'm completely new to this.\n\n\\[**Edit**: Questions struck through once I've fixed the problem / am happy that I understand what's going on.\\]\n\n1. Is having navigation & observation data sufficient for RTKlib to use a particular constellation or are the base station observations (a) constellation-specific and (b) necessary? (I have a basic understanding of most of the file formats, but don't understand the base station observations yet.)\n1. Following on, is there some way for me to know which types of satellite have been used in the final solution and which ones ignored? I'm concerned that when I use `rtkplot` I only see `G*` satellites when in `Residuals` view. Is RTKlib able to use the GLONASS and Galileo observations as well?\n1. ~~For the base station observations, I plan to use TRAK (rather than SLAC) for the LAX routes (because TRAK is much closer). Looking at SLAC, the antenna location coordinates in `ppk_slac.conf` differ from those reported in the SLAC observation headers (either the antenna details or the monument location) which in turn differ from those reported [here](https://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=slac&option=Coordinates14).~~\n 1. ~~How did you calculate the reference location as used in `ppk_slac.conf`?~~\n 1. ~~How would I compute equivalents for TRAK?~~\n 1. ~~Also, I notice from the link that these things are moving ~1cm per year. Is it worth trying to take account of that? (I realize that we're not at centimeter accuracy yet, but I'm not sure whether any errors are amplified through the calculations.)~~\n1. ~~For 11 of the (non-LAX) training routes, no solution is produced. (Specifically, the header lines are output, but there are no positions.) I also ran these manually with `rtkpost` (from the demo5 release) and tried to look through the trace file, but I couldn't make out what it thought the problem was from amongst all the other information. Any tips on either what the problem might be or how I can go about debugging this?~~\n1. Comparing the RTK solutions to the provided training baselines, ~~17~~ 13 were much worse (i.e. mostly >1km away, sometimes >10km). 3 were a little worse and the remainder were a little better. Any ideas what I need to do for the ones that are way off? (At the moment, I just say that if the two solutions differ by too much, use the baseline.)\n1. ~~Can you tell me anything more about the Q values? The header states `Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp`. When I look at the plots, Q=2 (most common, ~98% of locations) seems to mean good and Q=4 seems to be where things have gone a little dodgy (vehicle under a bridge, etc.). I would have thought that having a DGPS position would be a good thing, so what does this really mean?~~\n1. Whilst we're on field definitions...\n 1. ~~What are `sdn(m) sde(m) sdu(m) sdne(m) sdeu(m) sdun(m)`?~~\n 1. Why is age negative? Is that an artifact of doing a backwards pass?\n\nThanks so much for any advice you can give. If there's anything that isn't clear or if it would be helpful for me to follow up with any log snippets or other information, I'm very happy to do that.", "1786086": "Good questions! I'll attempt to answer them below:\n\n1. To include a GNSS constellation in the solution, RTKLIB requires rover observations, base observations, and satellite navigation data for that constellation. The base observations are in the identical format of the rover observations, specifically pseudorange, carrier phase, doppler, and signal strength measurements by satellite and epoch.\n\n2. Looking at the plotted residuals after plotting the solution in RTKLIB is a good way to see which satellites were used in the solution. Another option if you want to get more details is to enable debug trace level 3 when generating the solutions and then review the debug trace file. The solutions in this exercise should include only GPS, GLONASS, and Galileo constellations since that is what is generally available in the CORS base station observations. If a constellation is not included in the solution, the most likely reason is that either the base observations or the navigation data did not include satellites from that constellation.\n\n3. The TRAK CORS base station would not be a good choice for the LAX data because it does not include Galileo observations. I used the VDCY CORS station for my LAX solutions. I'm not quite sure why my location for the SLAC base is slightly different from the coordinates in your link. Most likely they are for different dates since the base station is moving with the tectonic plates relative to the WGS84/ITRF 2014 coordinate system. Any error in the base location will cause an equal sized error in the solution assuming the errors are not larger than a few meters.\n\n4. I don't know why 11 of the non-LAX routes did not generate solutions for you. I would suggest setting the trace level to 2 when running the solution to reduce the amount of information in the trace file irrelevant to the failure. You can also reference my RTKLIB notebook in the code section. I was able to generate solutions for all of the training set. However some of these data sets have large numbers of hardware clock discontinuities and the RTKLIB solutions for these will be of poor quality since the carrier phase information is corrupted by the clock discontinuities. You can identify these data sets by looking at the HardwareClockDiscontinuityCount in the raw Android log files. If this number is incrementing during the log, then the carrier phase values will be very poor. One more suggestion is that there are some minor robustness improvements in the latest demo5 version (b34f) of RTKLIB relative to the version in my GDSC-2021 release package which may help. To duplicate my results exactly you will need to use the very latest version of the demo5 RTKLIB source code which is available in my Github repository but you will have to compile this yourself. I have rtklibexplorer blog posts describing how to compile the code for both Windows and linux.\n\n5. The hardware clock discontinues probably explain at least some of your poor results. In my submission for the test set, I replaced the RTKLIB solutions with the Google baseline solutions for the two data sets that had hardware clock discontinuities. The Google baseline solutions do not use the carrier phase measurements so are not affected by the clock discontinuities.\n\n6. There is a Q value for each solution point which refers to how that point was calculated. You will only see values of 2,4, or 5 in these solutions. Q=2:float indicates a differential (PPK) solution using pseudoranges and carrier phases. Q=4:dgps indicates a differential solution using only the pseudoranges and so will be of lower accuracy than the float solution. Q=5:single indicates a standard precision absolute solution and will be the lowest accuracy.\n\n7. Sdn(m), sde(m), and sdu(m) are accuracy estimates of the solution points in meters in ENU coordinates and are standard deviations. These will tend to be optimistic since they are direct outputs of the kalman filter which assumes all inputs are normally distributed and uncorrelated, neither of which is true for the GNSS inputs. These values are more useful if used as relative accuracies between solution points, rather than absolute accuracies. The last three values (sdne(m), sdeu(m), and sdun(m)) are used to recreate the full covariance matrix for each solution point and are of less interest for most users.", "1786162": "Thanks for the detailed reply @timeverett. It'll take a while for me to digest it, but one immediate follow-up...\n\nWhat position are you using for VDCY? From [here](https://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=vdcy&option=Logfile) I get.\n\n```\n Latitude (N is +) : +341042.83\n Longitude (E is +) : -1181312.00\n Elevation (m,ellips.) : 318.197\n```\n\nFrom [here](https://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=vdcy&option=Coordinates14) I have 6 different possibilities (the ARP, the L1 Phase Center or the \"Monument\", whatever that is, in either of IRTF2014 or NAD_83 - where I assume I want IRTF2014). And then there are different positions again in the downloaded base files.\n\n---\n\nIn the end I went with...\n\n```\nant2-pos1 =34.17856563611 # (deg|m)\nant2-pos2 =-118.22000054722 # (deg|m)\nant2-pos3 =318.246 # (m|m)\n```\n\n...which is, at least, producing non-empty solutions.", "1786236": "I used the ARP ITRF2014 coordinates from [here](https://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=vdcy&option=Coordinates14). You can get to this page from the map page at the CORS user-friendly site https://www.ngs.noaa.gov/UFCORS/", "1787213": "Just in case you're interested, @timeverett (and anybody else using rtklib), I got to the bottom of the 11 MTV training routes that I couldn't get a solution for at all.\n\n- For 3/11 (all within `2021-07-27-US-MTV-1`), SLAC was in the middle of a 4-day outage, so base data is unavailable and the website returns an error. I've used P176 for these instead. Not sure if picking one that's 400m up a hillside was the best idea, but at least it has a solution now.\n- 8/11 of them have a directory name which implies the routes were driven on a particular date (e.g. 2020-06-24-US-MTV-1) but actually the routes were driven at some point in the early hours of the following morning. (Could be a daylight saving thing, but some are more than an hour out, so probably not.) I pulled base & nav data according to the directory name, which was therefore not useful to `rtkpost`. Having fetched the right data, these work fine. I guess I should also check whether any of the routes straddle a midnight boundary.\n\n---\n\n**Edit**: Glad I checked: There are 5 training samples that go over a date boundary. 4/5 of them appear in the \"17 were much worse\" category in Q5. (The others are presumably hardware clock discontinuities as you suggested - I haven't checked yet.) Having fetched data for the next day too, these also work better. The good news is that none of the test samples have this \"feature\".", "1790120": "It sounds like you mostly figured it out on your own but I will add a few comments. \n\nThe observation and navigation file dates are based on UTC time which is 8 hours later than the local time so any data collected late in the afternoon will require base observation files from the following UTC day. For the rides that cross the day boundary, the [NGS User Friendly CORS site](https://www.ngs.noaa.gov/UFCORS/) makes it easy to retrieve base observations in a single file that cross the day boundary. Navigation data from the end of one day will still be useful for the beginning of the following day so it usually won't be necessary to get an additional navigation file for these rides. \n\nAs you mentioned, this issue only affects rides in the training set, the rides in the test set are all contained within one UTC day.", "1799502": "Experimenting with RTKLIB as well, and probably a bit stupid question, but how do you access navigation data BRDM files? Following the link https://igs.bkg.bund.de/root_ftp/IGS/BRDC/ only gives me 2022 data. How to get 2021?", "1800057": "The IGS navigation data has become more difficult to access since I wrote my original blog post on the 2021 data which referenced that link. For this year's data I chose to pull the navigation data from the [UNAVCO website](https://data.unavco.org/archive/gnss/rinex3/nav). The first block of code in my \"[Getting Started With RTKLIB](https://www.kaggle.com/code/timeverett/getting-started-with-rtklib)\" notebook will automatically pull the navigation data for all of the rides in the 2022 test data set.", "1851763": "For anyone using my \"Getting Started with RTKLIB\" notebook, I have just made a few updates to the notebook that may be of interest.\n\nWhen I originally released this notebook a couple of months ago, the resulting score was 3.135 which was good enough to tie for first place. Since then the scores have improved significantly and this score is no longer low enough to be competitive. I have just made a couple of changes to the notebook to improve the resulting score to 2.67 which as of today is good enough to get you into 27th place out of 461 entries.\n\nThe two changes I made were to update the base station locations to account for tectonic plate movement and to replace the rides with hardware clock discontinuities on a point by point basis instead of the entire data set. I also added a few sort() statements to correct an issue when the code was not run in Windows.", "1862172": "[This comment is identical to one I've left on the notebook.]\n\nAs Tolstoy might have said, every unsuccessful coding session is unsuccesful in its own way. Nonetheless, a couple of tips from my (more extensive than I'd planned) experience with getting RTKLIB up and running might help someone reading this.\n\nMost of my problems arose from the code not liking Windows paths. \n\nMy initial problem turned out to be that I'd tried to run the code from a Windows folder with a space in its name, which threw an error. I tried again in a folder with no space in the name.\n \nSecondly, the python needed to be told explicitly about Windows paths. Thus, in step4, I had to change the code to read:\n\nif 'rtklib-py/src' not in sys.path:\n sys.path.append('rtklib-py/src')\nif 'android_rinex/src' not in sys.path:\n sys.path.append('android_rinex/src')\nif r'D:\\GSDC_2022\\python' not in sys.path:\n sys.path.append(r'D:\\GSDC_2022\\python')\nif r'D:\\GSDC_2022\\python\\android_rinex\\src' not in sys.path:\n sys.path.append(r'D:\\GSDC_2022\\python\\android_rinex\\src')" }, "source": "meta" }