Repository navigation
Conversation
Auto-detect picks them from hwVersion 0x89 (F9) and 0x54 (X20).
|
|
Configurator test build ready — commit Download build artifacts for PR #2813 Available platforms (scroll to the Artifacts section at the bottom of the run page):
|
|
Tested with the CI build of 6675bb4 on an IFLIGHT_BLITZ_ATF435.
Both presets can also be selected by hand and behave like the existing ones. The |
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
PR Summary by QodoAdd auto-detected GPS presets for u-blox ZED-F9P and ZED-X20P
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Code Review by Qodo
1. New GPS preset labels stay untranslated
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
| <option value="f9p">u-blox ZED-F9P</option> | ||
| <option value="x20p">u-blox ZED-X20P</option> |
There was a problem hiding this comment.
1. New gps preset labels stay untranslated 📘 Rule violation ✧ Quality
The added f9p and x20p option labels are hardcoded English text without data-i18n translation keys. Users viewing a non-English locale still see these newly introduced preset names in English whenever the GPS preset selector is displayed.
Agent Prompt
## Issue description
The new GPS preset option labels are hardcoded English strings and do not use the project's i18next `data-i18n` mechanism, so they remain untranslated in localized interfaces.
## Fix Focus Areas
- tabs/gps.html[54-55]
- locale/en/messages.json
## Recommended Fix
Add unique translation keys for the ZED-F9P and ZED-X20P labels to `locale/en/messages.json`, replace the option text with the corresponding `data-i18n` attributes, and preserve the option values used by the preset logic.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| case 0x54: return 'x20p'; | ||
| case 0x89: return 'f9p'; |
There was a problem hiding this comment.
2. New receiver detection stays hidden 🐞 Bug ☼ Reliability
The new hardware mappings depend on updateHardwareStatus(), which runs only once 500 ms after the GPS tab is initialized. When the asynchronous GPS statistics response arrives later, the new receiver code is stored but the status indicator is never refreshed, so users do not see that the F9P or X20P was detected.
Agent Prompt
Issue description
The new F9P and X20P detection mappings are only useful to the hardware-status indicator if GPS statistics arrive before the single 500 ms status check. GPS statistics are fetched asynchronously and may arrive later, leaving the detected receiver undisplayed for the rest of the tab session.
Fix Focus Areas
- tabs/gps.js[418-419]
- tabs/gps.js[472-482]
- tabs/gps.js[589-598]
Recommended Fix
Invoke `updateHardwareStatus()` after `FC.GPS_DATA.hwVersion` is populated, or retry the status check until GPS statistics are available. Keep the update idempotent so repeated GPS polling does not duplicate or regress the indicator.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
GPS presets for the u-blox ZED-F9P and ZED-X20P, picked by auto-detect.
f9p: Galileo and BeiDou on, GLONASS off, 5 Hz. With four constellations the F9P reaches 7 Hz on firmware HPG 1.51 and 9 Hz on HPG 1.32 (data sheets ZED-F9P-05B/-04B).x20p: Galileo, BeiDou and GLONASS on, 10 Hz; the receiver does up to 25 Hz. GLONASS exists from receiver firmware HPG 2.10 on; the firmware skips it when the receiver does not list it.detectGPSPreset(): 0x54 = X20 (GPS: use PROTVER from MON-VER even when the hardware string is unknown inav#12021), 0x89 = F9 (GPS: u-blox ZED-F9P and ZED-X20P as their own receiver models inav#12083).Names and descriptions follow the existing presets, which are not localized.
Depends on iNavFlight/inav#12083 for 0x89 and for skipping GLONASS on X20 firmware without it, so it should be merged after that. With older firmware the F9P keeps reporting 0x49 and gets
m9-precision, which has the same values.Testing
npm test: 290 of 291 pass. The failing MZTC test inmsp-parse-failure-recoveryfails the same way on maintenance-10.x.detectGPSPreset()returns has a preset and an<option>, and that the rates are within the input's 5..20.