fix(gps): clamp negative uBlox nano field before millis conversion#11642
Open
daijoubu wants to merge 1 commit into
Open
fix(gps): clamp negative uBlox nano field before millis conversion#11642daijoubu wants to merge 1 commit into
daijoubu wants to merge 1 commit into
Conversation
The nano field in UBX-NAV-TIMEUTC and UBX-NAV-PVT messages is int32_t and legitimately goes negative near second boundaries. Dividing without clamping produced a large positive uint16_t (e.g. -50ms → 65486 ms), setting the RTC ~64 seconds fast on first GPS lock. Once set, rtcHasTime() prevents correction until reboot. Clamp to zero before the division on both message handlers.
Contributor
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Test firmware build ready — commit Download firmware for PR #11642 238 targets built. Find your board's
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
nanofield in UBX-NAV-TIMEUTC and UBX-NAV-PVT messages isint32_tand legitimately goes negative near second boundaries (e.g. −50,000,000 ns). The previous code divided without clamping:A negative value such as −50,000,000 ns → −50 ms → wraps to 65,486 when assigned to
uint16_t, setting the RTC approximately 64 seconds fast on first GPS lock. OncertcHasTime()returns true the RTC cannot be corrected until reboot.Changes
src/main/io/gps_ublox.c: clampnanoto zero before the millis division in bothMSG_TIMEUTCandMSG_PVThandlersTesting
Build matrix — all targets clean, no warnings:
Hardware test with negative nano values at second boundaries not yet performed (requires a uBlox receiver and GPS lock capture near a second boundary).