Verify that loaded almanac is valid (within a certain week number range) #470
Conversation
|
Test PASSed. |
|
/cc @henryhallam what do you think of this? |
| @@ -171,8 +183,16 @@ static void manage_calc_almanac_scores(void) | |||
| /* No almanac or position/time information, give it the benefit of the | |||
| * doubt. */ | |||
| acq_prn_param[prn].score[ACQ_HINT_ALMANAC] = 0; | |||
| } else if (almanac[prn].valid && time_quality > TIME_COARSE && | |||
| (abs(almanac[prn].week - t.wn%1024) > MAX_ALM_WEEK_DIFF)) { | |||
There was a problem hiding this comment.
Why not roll this into the previous condition, and simply not use the almanac for this PRN rather than labeling the almanac entry as invalid?
There was a problem hiding this comment.
Also we ought to make sure the week number stuff is thoroughly thought through. IIRC the policy was to use full-length, non-wrapping week numbers internally, and correct the received mod-1024 value to the full length value at the time we receive a TOW, ephemeris or almanac from the sky or the internet. So the % 1024 here, and the -1024 later, might not be appropriate here. @fnoble is that what you had in mind?
There was a problem hiding this comment.
I was thinking that we only need to check the file/memory once.
If we see that it is invalid, it is invalid for eterinity.
There was a problem hiding this comment.
The policy is definitely to correct the week number for rollover at the point of decoding, and use the full week number everywhere internally
There was a problem hiding this comment.
so does this mean that our almanac file and corresponding SBP message should be the full week number?
There was a problem hiding this comment.
yeah
On Wed, Jul 8, 2015 at 1:04 PM, denniszollo [email protected]
wrote:
In src/manage.c
#470 (comment)
:@@ -171,8 +183,16 @@ static void manage_calc_almanac_scores(void)
/* No almanac or position/time information, give it the benefit of the
* doubt. */
acq_prn_param[prn].score[ACQ_HINT_ALMANAC] = 0;
- } else if (almanac[prn].valid && time_quality > TIME_COARSE &&
(abs(almanac[prn].week - t.wn%1024) > MAX_ALM_WEEK_DIFF)) {so does this mean that our almanac file and corresponding SBP message
should be the full week number?—
Reply to this email directly or view it on GitHub
https://github.com/swift-nav/piksi_firmware/pull/470/files#r34191971.
There was a problem hiding this comment.
Comment "TODO: Fix almanac week numbers and use gpsdifftime()"
denniszollo
force-pushed
the
use_only_valid_almanac
branch
from
e23265c to
29a8199
Compare
|
Test FAILed. |
denniszollo
force-pushed
the
use_only_valid_almanac
branch
from
29a8199 to
361a2d5
Compare
|
Rebased on master, added TODOs, style fixes, and created the following issues for next steps: |
|
Test PASSed. |
|
Do we check NMCT? If not, the method described in this article may be worth implementing: https://www.ion.org/publications/abstract.cfm?articleID=1682 (I have the PDF of the entire article if it sounds like it would be useful. I'd think implementation would be pretty straightforward.) |
Invalidate almanac in memory if invalid for a particular PRN when discovered.
This is a check that is most relevant in the future when we are decoding the almanac or sending it to the device. It may affect people who haven't used Piksi for a long time but used it last when we used to send the almanac to the device through the console.