[nullrouten0]

What changes
gps guard gets one more check: latitude must be within ±90° and longitude within ±180°. Otherwise the fix is rejected and gps guard shows rej coord. 3 lines in GpsGuard.h, one doc line, and a small test.

Why
A garbled sentence can still pass its checksum and parse to an impossible position. Example: latitude 9999.9999, longitude 18099.0000 gives 100.67°, 181.65°. On current dev with GPS_GUARD on, the guard accepts this as ok 8sat and it becomes the node's last fix (position, adverts, telemetry). With this change it shows rej coord and no position is stored.

Found in a security review of the GPS code. Low severity: no crash, just a wrong position. You asked in #3626 to fit this into gps guard, so this replaces it.

What I checked

• Real provider on current dev, GPS_GUARD on, the sentence above: before ok 8sat, after rej coord, position not stored. A normal position still gets ok.
• New test: 5 cases (both limits accepted, 1 micro-degree past each limit rejected, guard off accepts everything). I broke the check 10 ways (moved each boundary, swapped lat and lon, dropped each side, removed the check); the test failed every time. With the check removed it fails, as expected.
• Full native suite: 55 of 55 pass.
• Built Heltec_t114_repeater with -DGPS_GUARD: builds, and the guard code is in the firmware.

Not checked

• Builds without GPS_GUARD still accept an impossible position, because the guard is not there. I followed your request and left them alone. A one-line check in isValid() would cover them if you want it.
• The test adds a 27-line RTClib.h mock so GpsGuard.h compiles in the native tests. No hardware test.

🤖 Generated with Claude Code