-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rinex_nav: Incorrect time of clock #155
Comments
Hi @roberttully95 ! Thanks for taking the time to submit an issue. First to clarify the issue, I made a minimal working example in this colab notebook with this brdc0730.zip data file: https://colab.research.google.com/drive/1fcLRIkPmziE45Tvz97xcqQv7I2gguAVs?usp=sharing Currently, there's a row of NaN values for any satellite that doesn't have a rinex entry for that timestep. The behavior you'd expect is for that row of NaN's to not exist so that the length of the RinexNav class output always be equal to the number of total entries in the Rinex data file? Is that correct? That functionality could be achieved on our end by editing how we drop NaN values after the rinex file is loaded with georinex. |
Thanks for making the example! Yes, this illustrates the scenario. I think that expectation is correct. I would expect only data contained in the original rinex file to be populated in the RinexNav object. I have verified that the issue lies in how the NaN values are dropped. If the rows are dropped after the leap seconds are added to the data frame it works as expected. In the code below, all NaN rows are never dropped because the leap seconds are non-NaN. gnss_lib_py/gnss_lib_py/parsers/rinex_nav.py Lines 207 to 211 in c9457b1
I have also verified this fixes the observed issue of incorrect clock correction in the resultant satellite states. Let me know if I should submit a pull request to submit my local fix. Thanks for your assistance! |
I reordered those lines of code in #156. That change will be reflected in our 1.0.2 version of In the mean time, you can switch to the
|
@roberttully95 This fix has been published to pypi in version 1.0.2. Thanks for taking the time to post an issue and please let us know if you have any further problems |
Bug Overview:
The clock correction model is being marked as updated for all satellites of a constellation when updated for any satellite from that constellation using rinex_nav.
Bug Description:
When a message with a new timestamp is parsed from a RINEX file, all satellites in the constellation that did not have a message at that time are updated with a 'dummy' record. The time of clock is being incorrectly set when dealing with these 'dummy' records such that all satellites are being treated as having an updated clock correction model when any satellite has an updated model.
gnss_lib_py/gnss_lib_py/parsers/rinex_nav.py
Lines 213 to 214 in c9457b1
System Information:
The text was updated successfully, but these errors were encountered: