GPS: set the clock only from the RMC sentence that was validated

[nullrouten0]

What changes

• The GPS clock sample now comes from the text of each RMC sentence that passed its checksum: hhmmss from the time field, status A, and ddmmyy from the date field. All of them must come before the first *, so the checksum covers them, and the date must be a real calendar date. Any other sentence gives no sample.
• The RTC is set only after three consecutive samples advance in step with millis(), within 2 s, and only if the newest sample is at most 2 s old. The value written is that sample. Repeats of the same second are ignored, so receivers faster than 1 Hz still work.
• Unchanged: when syncs happen (first fix, then every 30 minutes, and on gps sync), the position path, getTimestamp(), and the other location providers.

Why

MeshCore compares timestamps per sender. A repeater or room rejects a login whose timestamp is not newer than the last one from that client, and companion nodes drop an advert that is not newer than the last one from that key. So a node's clock mostly needs to move forward. The costly failure is a clock that jumps ahead and is later corrected: peers have recorded the future value and refuse the node's correct adverts and logins until real time catches up. #3050 shows how hard that is to recover from.

Today the provider counts seconds while nmea.isValid(), a position flag, is true, then writes getTimestamp(), which reads MicroNMEA's current fields. Nothing ties those fields to the sentence that was just checked:

1. Before any date has been parsed, the date fields are 0 and the time fields 99, which DateTime turns into a date in 2043, as Do not feed an invalid GPS time into the RTC 🤖🤖 #3422 shows on hardware. Do not feed an invalid GPS time into the RTC 🤖🤖 #3422 covers this case.
2. MicroNMEA parses with fixed-width skips. When a field is missing or merged, parseDate() lands on a different field, and if that field is empty it keeps the previous sentence's date.
3. The checksum test stops at the first *. $GPRMC*4B,... passes on the five characters GPRMC, nothing is parsed, and the previous sentence's fields are written.

The new tests reproduce each of these on dev:

• One checksum-valid RMC carrying a wrong date, arriving just as the clock is about to be set, is written as is. The test uses a 2099 date, and dev sets the clock to 2099-10-17 12:00:37.
• With misaligned sentences after midnight, the 30-minute resync writes the previous day, 86,400 s behind.
• When sentences stop parsing, the resync writes the last parsed time, about 30 minutes stale.

Case 1 needs only a receiver that reports a position before it has a date. Cases 2 and 3 need a damaged sentence whose checksum still matches. The 8-bit XOR checksum always catches a single changed character, but a sentence that lost a run of bytes, for example to a UART receive overflow during a long loop stall, still matches about 1 time in 73. That figure comes from 200,000 random dropped runs of 2 to 20 bytes in a real RMC sentence.

What I checked

• pio test -e native -e native_kiss_modem -e native_gps: 77 of 77 pass, the 54 existing tests plus 23 in native_gps.
• The same tests on dev's provider: 15 of the 21 new clock tests fail. In 9 of them, dev writes a time it should not have: no date yet, a date the checksum does not cover, impossible fields, the previous day after midnight, a frozen time, the 2099 outlier, a stuck time, and stale samples at a resync, twice. 5 fail only on timing; they pin the agreement rule and say so. 1 is the deliberate change described below. The other 6 pass on both and guard against regressions, such as a clean receiver, a receiver faster than 1 Hz, and a leap day.
• Mutation check: 31 deliberate breaks of the new code all fail the suite, none by timeout. They include dropping each field check, moving each calendar bound, the field walk off by one either way, a sample count of 2 or 4, a tolerance of 0, 1 or 100 s, a sample age of 1 s or 20 s, dropping the forward-only, same-second, freshness and forced-sync rules, and writing MicroNMEA's fields instead of the sample.
• Firmware builds, dev and this branch:

Build	RAM (bytes)	Flash (bytes)
Heltec_v3_repeater	62,512 → 62,520	1,174,497 → 1,175,193
RAK_4631_repeater	37,240 → 37,248	440,924 → 441,516

Behaviour changes to know about

• Receivers that send the time without fractional seconds (hhmmss, no .ss) now set the clock. MicroNMEA skips a fixed nine characters for the time, so it misreads these sentences' position fields and isValid() stays false; on dev they never set the clock. Their position is still invalid, as before.
• Receivers that send GGA but no RMC no longer set the clock. GGA has no date, so on dev they wrote whatever date MicroNMEA held, which is 2043 until an RMC arrives.
• The first sync happens on the third agreeing RMC, about 2 s after the first. On dev it happened on the fourth one-second check.

Not checked

• No hardware run. A receiver that reports a wrong time consistently is still trusted; nothing on the node can detect that.
• Do not feed an invalid GPS time into the RTC 🤖🤖 #3422 also changes the RTC write in loop(). This PR does not touch getTimestamp(), so the overlap is a few lines and whichever merges second needs a small rebase. Do not feed an invalid GPS time into the RTC 🤖🤖 #3422's validation in getTimestamp() is still useful for any other caller.

Related

The first commit adds the native_gps test environment and is the same commit as in #3624, the guard-tail PR. The tests for this change are in their own file, test_clock.cpp, so the GPS PRs merge in any order without conflicts.

🤖 Generated with Claude Code