{
  "id": 341226,
  "title": "6th Place Solution",
  "url": "/competitions/smartphone-decimeter-2022/writeups/rtklibexplorer-6th-place-solution",
  "author_name": "",
  "post_date": "2022-08-01T22:00:05.388648Z",
  "votes": 31,
  "comment_count": 4,
  "views": 0,
  "content": "<p>Thanks to the hosts and competitors for a great competition!  I have enjoyed participating as well as helping introduce others to RTKLIB.  I've also learned a lot, not just from working with the smartphone data, but also from reading all of the interesting discussion threads and notebooks.</p>\n<p>I had already shared much of my solution in the <a href=\"https://www.kaggle.com/code/timeverett/getting-started-with-rtklib\" target=\"_blank\">\"Getting Started With RTKLIB\" </a>notebook but I have just updated it to<br>\ninclude my best RTKLIB solution for the test data set.  This includes one of two config files I used in my final submission as well as my most recent version of the RTKLIB library code and android_rinex library code.  This will provide a score of 1.597 on the private leaderboard and 1.753 on the public leaderboard.  Note that this doesn't include any post-processing of the RTKLIB results other than replacing the data that contains hardware clock discontinuities with other publicly available solutions, so it should not be difficult to improve on these results.  Also note that the private score for this solution is lower than my final submission, since for my submission, I merged these results with a solution from a second config file.  The other solution improved scores for the training data and the public test data but unfortunately it made things worse for the private test data.</p>\n<p>I have added the resulting submission file to the notebook input data for anyone who would like to use it as an input to their post-processing algorithms and don't want to have to get RTKLIB working on their system.  I would be curious how this fares when combined with some more advanced post-processing since I focused almost entirely on the GNSS solution itself and only did minimal post-processing in my submissions.  If you do try this, please share your results in the comments below.</p>\n<p>There was approximately one meter of improvement between this solution and the previous version of the notebook.  This was the culmination of many small improvements in code, configuration, and input files, and not from any single major breakthrough.  Changes included:</p>\n<p><strong>Satellite Navigation Files</strong></p>\n<ul>\n<li>Replaced the navigation files from UNAVCO with files from CDDIS since the UNAVCO files seemed to be missing some data</li>\n</ul>\n<p><strong>Android_Rinex code - conversion from raw data to rinex</strong></p>\n<ul>\n<li>Minor cleanup for handling the hardware clock discontinuities</li>\n</ul>\n<p><strong>RTKLIB Code - PPK solutions</strong></p>\n<ul>\n<li>Changed the pseudorange outlier threshold into a config parameter, previously it was a function of the phase outlier threshold</li>\n<li>For measurement differencing, replaced the closest previous base observation with the closest base observation</li>\n<li>Adjusted the phase measurement variances by frequency as well as by constellation</li>\n<li>Tightened up the outlier threshold adjustments for the initial observation after acquire</li>\n</ul>\n<p><strong>RTKLIB Configuration parameters</strong></p>\n<ul>\n<li>Switched the raw measurement weighting from elevation based to SNR based</li>\n<li>Increased the weight of L5 measurements, and reduced the weight of L1 measurements</li>\n<li>Increased the weight of the pseudorange measurements, and reduced the weight of the phase measurements</li>\n<li>Opened up the measurement filter thresholds (min elevation, cycle slip detect, outlier thresholds) to include more measurements in the result</li>\n<li>Reduced the acceleration process noise in the kalman filter ( a little reduction is a good thing, too much is what hurt my final submission on the private test data)</li>\n<li>Set the measurement weighting adjustment for satellite clock stability to zero</li>\n<li>Disabled the interpolation of base observations</li>\n</ul>\n<p>For more details, see the code changes in the Github repositories and the config file changes in the notebook.  If you have any questions about these changes or about RTKLIB in general, please ask in the comments below, I'm always happy to share what I know about RTKLIB.  You can also visit <a href=\"https://rtklibexplorer.wordpress.com/\" target=\"_blank\">my blog</a> for more information on using RTKLIB.</p>",
  "messages": [
    {
      "id": "1880628",
      "postDate": "08/01/2022 22:00:05",
      "content": "<p>Thanks to the hosts and competitors for a great competition!  I have enjoyed participating as well as helping introduce others to RTKLIB.  I've also learned a lot, not just from working with the smartphone data, but also from reading all of the interesting discussion threads and notebooks.</p>\n<p>I had already shared much of my solution in the <a href=\"https://www.kaggle.com/code/timeverett/getting-started-with-rtklib\" target=\"_blank\">\"Getting Started With RTKLIB\" </a>notebook but I have just updated it to<br>\ninclude my best RTKLIB solution for the test data set.  This includes one of two config files I used in my final submission as well as my most recent version of the RTKLIB library code and android_rinex library code.  This will provide a score of 1.597 on the private leaderboard and 1.753 on the public leaderboard.  Note that this doesn't include any post-processing of the RTKLIB results other than replacing the data that contains hardware clock discontinuities with other publicly available solutions, so it should not be difficult to improve on these results.  Also note that the private score for this solution is lower than my final submission, since for my submission, I merged these results with a solution from a second config file.  The other solution improved scores for the training data and the public test data but unfortunately it made things worse for the private test data.</p>\n<p>I have added the resulting submission file to the notebook input data for anyone who would like to use it as an input to their post-processing algorithms and don't want to have to get RTKLIB working on their system.  I would be curious how this fares when combined with some more advanced post-processing since I focused almost entirely on the GNSS solution itself and only did minimal post-processing in my submissions.  If you do try this, please share your results in the comments below.</p>\n<p>There was approximately one meter of improvement between this solution and the previous version of the notebook.  This was the culmination of many small improvements in code, configuration, and input files, and not from any single major breakthrough.  Changes included:</p>\n<p><strong>Satellite Navigation Files</strong></p>\n<ul>\n<li>Replaced the navigation files from UNAVCO with files from CDDIS since the UNAVCO files seemed to be missing some data</li>\n</ul>\n<p><strong>Android_Rinex code - conversion from raw data to rinex</strong></p>\n<ul>\n<li>Minor cleanup for handling the hardware clock discontinuities</li>\n</ul>\n<p><strong>RTKLIB Code - PPK solutions</strong></p>\n<ul>\n<li>Changed the pseudorange outlier threshold into a config parameter, previously it was a function of the phase outlier threshold</li>\n<li>For measurement differencing, replaced the closest previous base observation with the closest base observation</li>\n<li>Adjusted the phase measurement variances by frequency as well as by constellation</li>\n<li>Tightened up the outlier threshold adjustments for the initial observation after acquire</li>\n</ul>\n<p><strong>RTKLIB Configuration parameters</strong></p>\n<ul>\n<li>Switched the raw measurement weighting from elevation based to SNR based</li>\n<li>Increased the weight of L5 measurements, and reduced the weight of L1 measurements</li>\n<li>Increased the weight of the pseudorange measurements, and reduced the weight of the phase measurements</li>\n<li>Opened up the measurement filter thresholds (min elevation, cycle slip detect, outlier thresholds) to include more measurements in the result</li>\n<li>Reduced the acceleration process noise in the kalman filter ( a little reduction is a good thing, too much is what hurt my final submission on the private test data)</li>\n<li>Set the measurement weighting adjustment for satellite clock stability to zero</li>\n<li>Disabled the interpolation of base observations</li>\n</ul>\n<p>For more details, see the code changes in the Github repositories and the config file changes in the notebook.  If you have any questions about these changes or about RTKLIB in general, please ask in the comments below, I'm always happy to share what I know about RTKLIB.  You can also visit <a href=\"https://rtklibexplorer.wordpress.com/\" target=\"_blank\">my blog</a> for more information on using RTKLIB.</p>",
      "rawMarkdown": "Thanks to the hosts and competitors for a great competition!  I have enjoyed participating as well as helping introduce others to RTKLIB.  I've also learned a lot, not just from working with the smartphone data, but also from reading all of the interesting discussion threads and notebooks.\n\nI had already shared much of my solution in the [\"Getting Started With RTKLIB\" ](https://www.kaggle.com/code/timeverett/getting-started-with-rtklib)notebook but I have just updated it to\ninclude my best RTKLIB solution for the test data set.  This includes one of two config files I used in my final submission as well as my most recent version of the RTKLIB library code and android_rinex library code.  This will provide a score of 1.597 on the private leaderboard and 1.753 on the public leaderboard.  Note that this doesn't include any post-processing of the RTKLIB results other than replacing the data that contains hardware clock discontinuities with other publicly available solutions, so it should not be difficult to improve on these results.  Also note that the private score for this solution is lower than my final submission, since for my submission, I merged these results with a solution from a second config file.  The other solution improved scores for the training data and the public test data but unfortunately it made things worse for the private test data.\n\nI have added the resulting submission file to the notebook input data for anyone who would like to use it as an input to their post-processing algorithms and don't want to have to get RTKLIB working on their system.  I would be curious how this fares when combined with some more advanced post-processing since I focused almost entirely on the GNSS solution itself and only did minimal post-processing in my submissions.  If you do try this, please share your results in the comments below.\n\nThere was approximately one meter of improvement between this solution and the previous version of the notebook.  This was the culmination of many small improvements in code, configuration, and input files, and not from any single major breakthrough.  Changes included:\n\n**Satellite Navigation Files**\n- Replaced the navigation files from UNAVCO with files from CDDIS since the UNAVCO files seemed to be missing some data\n\n**Android_Rinex code - conversion from raw data to rinex**\n- Minor cleanup for handling the hardware clock discontinuities\n\n**RTKLIB Code - PPK solutions**\n\n- Changed the pseudorange outlier threshold into a config parameter, previously it was a function of the phase outlier threshold\n- For measurement differencing, replaced the closest previous base observation with the closest base observation\n- Adjusted the phase measurement variances by frequency as well as by constellation\n- Tightened up the outlier threshold adjustments for the initial observation after acquire\n\n**RTKLIB Configuration parameters**\n- Switched the raw measurement weighting from elevation based to SNR based\n- Increased the weight of L5 measurements, and reduced the weight of L1 measurements\n- Increased the weight of the pseudorange measurements, and reduced the weight of the phase measurements\n- Opened up the measurement filter thresholds (min elevation, cycle slip detect, outlier thresholds) to include more measurements in the result\n- Reduced the acceleration process noise in the kalman filter ( a little reduction is a good thing, too much is what hurt my final submission on the private test data)\n- Set the measurement weighting adjustment for satellite clock stability to zero\n- Disabled the interpolation of base observations\n\nFor more details, see the code changes in the Github repositories and the config file changes in the notebook.  If you have any questions about these changes or about RTKLIB in general, please ask in the comments below, I'm always happy to share what I know about RTKLIB.  You can also visit [my blog](https://rtklibexplorer.wordpress.com/) for more information on using RTKLIB.",
      "votes": null
    },
    {
      "id": "1881157",
      "postDate": "08/02/2022 09:56:10",
      "content": "<p>Thanks <a href=\"https://www.kaggle.com/timeverett\" target=\"_blank\">@timeverett</a> for solution description and your notebooks!</p>\n<p>I have a question about rtklib velocity usage:<br>\nI noticed that results from estvel() function (velocity estimation by doppler)<br>\nrarely propagate to solution (only in case of big variance, udpos() logic)</p>\n<p>1) Is it true that rtklib does not actually use/need velocity estimates by doppler?<br>\n2) In ekf measurement update I see code and phase measurements only,<br>\n    is it possible to add velocity estimates to measurements too? and will there be any benefit?  <br>\n3) Do rtklib solutions have near zero acceleration? </p>",
      "rawMarkdown": "Thanks @timeverett for solution description and your notebooks!\n\nI have a question about rtklib velocity usage:\nI noticed that results from estvel() function (velocity estimation by doppler)\nrarely propagate to solution (only in case of big variance, udpos() logic)\n\n1) Is it true that rtklib does not actually use/need velocity estimates by doppler?\n2) In ekf measurement update I see code and phase measurements only,\n    is it possible to add velocity estimates to measurements too? and will there be any benefit?  \n3) Do rtklib solutions have near zero acceleration?",
      "votes": null
    },
    {
      "id": "1881187",
      "postDate": "08/02/2022 10:29:04",
      "content": "<p><a href=\"https://www.kaggle.com/timeverett\" target=\"_blank\">@timeverett</a> </p>\n<p>congrats on your good results.<br>\nthank you very much on your kindness for posting usage of RTKLIB and answering our questions about it.<br>\nI learned and enjoyed a lot from your post. :)</p>",
      "rawMarkdown": "timeverett \n\ncongrats on your good results.\nthank you very much on your kindness for posting usage of RTKLIB and answering our questions about it.\nI learned and enjoyed a lot from your post. :)",
      "votes": null
    },
    {
      "id": "1881576",
      "postDate": "08/02/2022 16:31:46",
      "content": "<p>1) RTKLIB does estimate velocity using doppler measurements but does not use the results for PPK solutions.<br>\n2) I believe that UME's 3rd place finish comes from effectively adding velocity estimation to the RTKLIB solution (in post-processing), so, yes, I do think it can help.  I suspect the benefit comes more from including the doppler measurements than it does from the velocity estimation directly, but I think that independent velocity estimation is an effective method to integrate the doppler measurements into the solution.<br>\n3) No, ideally RTKLIB solutions should accurately estimate the acceleration of the receiver making the measurements.  I suspect you are referring to the relatively low acceleration process noise configuration parameters I used in my solution.  Typically, these parameters are chosen to match the acceleration characteristics of the receiver but reducing these will effectively increase the weight of the kalman filter's estimate of receiver location and makes it a little easier to reject outlier measurements.  The cost is that the solution can lag behind the actual movement during periods of high acceleration.  I tried to find a balance between these two factors, given the very large number of outliers in these data sets.</p>",
      "rawMarkdown": "1) RTKLIB does estimate velocity using doppler measurements but does not use the results for PPK solutions.\n2) I believe that UME's 3rd place finish comes from effectively adding velocity estimation to the RTKLIB solution (in post-processing), so, yes, I do think it can help.  I suspect the benefit comes more from including the doppler measurements than it does from the velocity estimation directly, but I think that independent velocity estimation is an effective method to integrate the doppler measurements into the solution.\n3) No, ideally RTKLIB solutions should accurately estimate the acceleration of the receiver making the measurements.  I suspect you are referring to the relatively low acceleration process noise configuration parameters I used in my solution.  Typically, these parameters are chosen to match the acceleration characteristics of the receiver but reducing these will effectively increase the weight of the kalman filter's estimate of receiver location and makes it a little easier to reject outlier measurements.  The cost is that the solution can lag behind the actual movement during periods of high acceleration.  I tried to find a balance between these two factors, given the very large number of outliers in these data sets.",
      "votes": null
    },
    {
      "id": "1881975",
      "postDate": "08/03/2022 01:41:24",
      "content": "<p>Congrats on your success in the competition! Very well explained, even a beginner like myself could understand, well done</p>",
      "rawMarkdown": "Congrats on your success in the competition! Very well explained, even a beginner like myself could understand, well done",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 1881157,
      "author_name": "kruntuid",
      "author_url": "",
      "post_date": "08/02/2022 09:56:10",
      "content": "<p>Thanks <a href=\"https://www.kaggle.com/timeverett\" target=\"_blank\">@timeverett</a> for solution description and your notebooks!</p>\n<p>I have a question about rtklib velocity usage:<br>\nI noticed that results from estvel() function (velocity estimation by doppler)<br>\nrarely propagate to solution (only in case of big variance, udpos() logic)</p>\n<p>1) Is it true that rtklib does not actually use/need velocity estimates by doppler?<br>\n2) In ekf measurement update I see code and phase measurements only,<br>\n    is it possible to add velocity estimates to measurements too? and will there be any benefit?  <br>\n3) Do rtklib solutions have near zero acceleration? </p>",
      "votes": null,
      "replies": [
        {
          "id": 1881576,
          "author_name": "timeverett",
          "author_url": "",
          "post_date": "08/02/2022 16:31:46",
          "content": "<p>1) RTKLIB does estimate velocity using doppler measurements but does not use the results for PPK solutions.<br>\n2) I believe that UME's 3rd place finish comes from effectively adding velocity estimation to the RTKLIB solution (in post-processing), so, yes, I do think it can help.  I suspect the benefit comes more from including the doppler measurements than it does from the velocity estimation directly, but I think that independent velocity estimation is an effective method to integrate the doppler measurements into the solution.<br>\n3) No, ideally RTKLIB solutions should accurately estimate the acceleration of the receiver making the measurements.  I suspect you are referring to the relatively low acceleration process noise configuration parameters I used in my solution.  Typically, these parameters are chosen to match the acceleration characteristics of the receiver but reducing these will effectively increase the weight of the kalman filter's estimate of receiver location and makes it a little easier to reject outlier measurements.  The cost is that the solution can lag behind the actual movement during periods of high acceleration.  I tried to find a balance between these two factors, given the very large number of outliers in these data sets.</p>",
          "votes": null,
          "replies": []
        }
      ]
    },
    {
      "id": 1881187,
      "author_name": "hengck23",
      "author_url": "",
      "post_date": "08/02/2022 10:29:04",
      "content": "<p><a href=\"https://www.kaggle.com/timeverett\" target=\"_blank\">@timeverett</a> </p>\n<p>congrats on your good results.<br>\nthank you very much on your kindness for posting usage of RTKLIB and answering our questions about it.<br>\nI learned and enjoyed a lot from your post. :)</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1881975,
      "author_name": "willcramptonn",
      "author_url": "",
      "post_date": "08/03/2022 01:41:24",
      "content": "<p>Congrats on your success in the competition! Very well explained, even a beginner like myself could understand, well done</p>",
      "votes": null,
      "replies": []
    }
  ],
  "raw_markdown_by_id": {
    "1880628": "Thanks to the hosts and competitors for a great competition!  I have enjoyed participating as well as helping introduce others to RTKLIB.  I've also learned a lot, not just from working with the smartphone data, but also from reading all of the interesting discussion threads and notebooks.\n\nI had already shared much of my solution in the [\"Getting Started With RTKLIB\" ](https://www.kaggle.com/code/timeverett/getting-started-with-rtklib)notebook but I have just updated it to\ninclude my best RTKLIB solution for the test data set.  This includes one of two config files I used in my final submission as well as my most recent version of the RTKLIB library code and android_rinex library code.  This will provide a score of 1.597 on the private leaderboard and 1.753 on the public leaderboard.  Note that this doesn't include any post-processing of the RTKLIB results other than replacing the data that contains hardware clock discontinuities with other publicly available solutions, so it should not be difficult to improve on these results.  Also note that the private score for this solution is lower than my final submission, since for my submission, I merged these results with a solution from a second config file.  The other solution improved scores for the training data and the public test data but unfortunately it made things worse for the private test data.\n\nI have added the resulting submission file to the notebook input data for anyone who would like to use it as an input to their post-processing algorithms and don't want to have to get RTKLIB working on their system.  I would be curious how this fares when combined with some more advanced post-processing since I focused almost entirely on the GNSS solution itself and only did minimal post-processing in my submissions.  If you do try this, please share your results in the comments below.\n\nThere was approximately one meter of improvement between this solution and the previous version of the notebook.  This was the culmination of many small improvements in code, configuration, and input files, and not from any single major breakthrough.  Changes included:\n\n**Satellite Navigation Files**\n- Replaced the navigation files from UNAVCO with files from CDDIS since the UNAVCO files seemed to be missing some data\n\n**Android_Rinex code - conversion from raw data to rinex**\n- Minor cleanup for handling the hardware clock discontinuities\n\n**RTKLIB Code - PPK solutions**\n\n- Changed the pseudorange outlier threshold into a config parameter, previously it was a function of the phase outlier threshold\n- For measurement differencing, replaced the closest previous base observation with the closest base observation\n- Adjusted the phase measurement variances by frequency as well as by constellation\n- Tightened up the outlier threshold adjustments for the initial observation after acquire\n\n**RTKLIB Configuration parameters**\n- Switched the raw measurement weighting from elevation based to SNR based\n- Increased the weight of L5 measurements, and reduced the weight of L1 measurements\n- Increased the weight of the pseudorange measurements, and reduced the weight of the phase measurements\n- Opened up the measurement filter thresholds (min elevation, cycle slip detect, outlier thresholds) to include more measurements in the result\n- Reduced the acceleration process noise in the kalman filter ( a little reduction is a good thing, too much is what hurt my final submission on the private test data)\n- Set the measurement weighting adjustment for satellite clock stability to zero\n- Disabled the interpolation of base observations\n\nFor more details, see the code changes in the Github repositories and the config file changes in the notebook.  If you have any questions about these changes or about RTKLIB in general, please ask in the comments below, I'm always happy to share what I know about RTKLIB.  You can also visit [my blog](https://rtklibexplorer.wordpress.com/) for more information on using RTKLIB.",
    "1881157": "Thanks @timeverett for solution description and your notebooks!\n\nI have a question about rtklib velocity usage:\nI noticed that results from estvel() function (velocity estimation by doppler)\nrarely propagate to solution (only in case of big variance, udpos() logic)\n\n1) Is it true that rtklib does not actually use/need velocity estimates by doppler?\n2) In ekf measurement update I see code and phase measurements only,\n    is it possible to add velocity estimates to measurements too? and will there be any benefit?  \n3) Do rtklib solutions have near zero acceleration?",
    "1881187": "timeverett \n\ncongrats on your good results.\nthank you very much on your kindness for posting usage of RTKLIB and answering our questions about it.\nI learned and enjoyed a lot from your post. :)",
    "1881576": "1) RTKLIB does estimate velocity using doppler measurements but does not use the results for PPK solutions.\n2) I believe that UME's 3rd place finish comes from effectively adding velocity estimation to the RTKLIB solution (in post-processing), so, yes, I do think it can help.  I suspect the benefit comes more from including the doppler measurements than it does from the velocity estimation directly, but I think that independent velocity estimation is an effective method to integrate the doppler measurements into the solution.\n3) No, ideally RTKLIB solutions should accurately estimate the acceleration of the receiver making the measurements.  I suspect you are referring to the relatively low acceleration process noise configuration parameters I used in my solution.  Typically, these parameters are chosen to match the acceleration characteristics of the receiver but reducing these will effectively increase the weight of the kalman filter's estimate of receiver location and makes it a little easier to reject outlier measurements.  The cost is that the solution can lag behind the actual movement during periods of high acceleration.  I tried to find a balance between these two factors, given the very large number of outliers in these data sets.",
    "1881975": "Congrats on your success in the competition! Very well explained, even a beginner like myself could understand, well done"
  },
  "source": "meta"
}