Conversation
|
ⓘ 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 QodoSend SBAS scan masks to u-blox M10 and F10 receivers
AI Description
Diagram
High-Level Assessment
Files changed (5)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
|
An F10 does satisfy that gate, because it reports the u-blox 10 hardware version. The F/M distinction is not in the hardware version at all. The F10 SPG 6.00 interface description prints the hardware line of UBX-MON-VER as On the bench the emulated F10, which answers exactly what those documents specify, is detected as I have not had a physical NEO-F10N in hand, so the hardware version there comes from the documents rather than from a receiver on my desk. If anyone has one connected, a UBX-MON-VER dump would settle it for good. |
|
Pushed a follow-up that removes the hardware version from this decision entirely. What actually decides whether UBX-CFG-SBAS exists is the protocol version, and it draws the line exactly where it belongs:
So the branch is now The bench grew two cases for the receiver in the middle, the M9, which knows CFG-VALSET and still has UBX-CFG-SBAS: it must keep getting the old message. Nine cases now, all passing, and |
|
RAM / Flash usage vs. base commit
See RAM/flash optimization guide for techniques to reduce usage. |
|
Test firmware build ready — commit Download firmware for PR #11978 249 targets built. Find your board's
|
INAV picks the SBAS service with UBX-CFG-SBAS, which M10 and F10 receivers do not have: their interface descriptions list only CFG-CFG, CFG-RST and the three CFG-VAL messages. The selection never reached them, and they kept searching the PRN list they were shipped with whether EGNOS, WAAS or AUTO was chosen. On those receivers the same scan mask now goes out as CFG-SBAS-PRNSCANMASK through CFG-VALSET. The bit layout is the one scanmode1 already uses, PRN120 in bit 0, so the existing table is sent unchanged, and zero keeps meaning every PRN. M8 and M9 receivers still get UBX-CFG-SBAS as before. The key is eight bytes wide, so this adds an eight byte variant of the CFG-VALSET helpers, with a unit test that checks the frame byte for byte.
The message this replaces disappears with protocol 34, which is where the CFG class was reduced to the configuration interface. Keying on that says exactly what is meant, and does not depend on the hardware version being recognised: the M10 platform reports 34, the F10 40, while the M9 reports 32 and the F9 27, and both of those still have UBX-CFG-SBAS and keep using it.
f45c42f to
5d5675b
Compare
2 participants
What happens
gps_sbas_modepicks which SBAS service the receiver should look for, and INAV sends that choice with UBX-CFG-SBAS. On u-blox 10 and later that message does not exist. The M10 and F10 interface descriptions list, of the whole CFG class, only UBX-CFG-CFG, UBX-CFG-RST, UBX-CFG-VALDEL, UBX-CFG-VALGET and UBX-CFG-VALSET; everything else moved to the configuration interface.So on an M10 or an F10 the choice is written to a message the receiver answers NAK to, and the receiver goes on searching the PRN list it was shipped with:
0x00072bc8on the M10 platform,0x0003ab88on the F10. Selecting EGNOS, WAAS, MSAS, GAGAN or leaving it on AUTO all give the same behaviour, and picking a service does not stop the receiver from locking onto a satellite of another one. Only NONE works today, and that is because SBAS is switched off elsewhere, throughCFG-SIGNAL-SBAS_ENAin the VALSET that configures the constellations.The change
Those receivers take the same choice through
CFG-SBAS-PRNSCANMASK(0x50360006), an 8-byte bitfield where bit 0 is PRN 120, each bit up to PRN 183, and all zeroes means scan every PRN. That is the layout INAV'subloxScanMode1table is already written in, the one it passes to UBX-CFG-SBAS asscanmode1, so the table is sent as is:The branch is taken on the protocol version, because that is what says whether the old message exists, and it draws the line exactly where it belongs:
So an M8, an M9 or an F9 keeps the message it has, untouched, and nothing here depends on the hardware version being recognised.
The key is 8 bytes wide and the driver only had VALSET helpers for 1-byte and 2-byte values, so this adds
ubloxCfgFillU8()next toubloxCfgFillU1()andubloxCfgFillU2(), same shape, same RAM-only layer, same checksum path.Worth knowing before merging
On an M10 or F10, AUTO now means what it already means on an M8: search every SBAS PRN. Until now it meant the list the module happened to ship with, which is narrower. Anyone who had picked a service and was getting a satellite of a different one will now get the one they picked, and anyone on AUTO in a region the shipped mask left out will start seeing SBAS. The default is NONE, so this only reaches setups where SBAS was deliberately turned on.
maxSBAShas no equivalent key in the configuration interface, so the number of SBAS satellites is left to the receiver, which is what it already does on these platforms.Testing
Emulated receivers on SITL, reading the bytes off the wire. The emulated M10 and F10 answer NAK to UBX-CFG-SBAS, since the interface description does not list it for those platforms:
gps_sbas_mode0x00x4001004A0x4A8000x0, SBAS signal off as before0x11800x00x4001004A0x00x4001004Agps_ublox_unittestgets a case that builds the frame and compares all 24 bytes, header to checksum, against the message the interface description specifies.Not tried on hardware yet.
Notes
Independent of my other open pull request on this file: that one is in
configureGNSS10(), this one is inconfigureSBAS(). They can go in in either order; if both land, git merges them without help.