RFC - Improve GNSS integrity information reporting - #30
Conversation
…fing and jamming status entries + add NovAtel output evaluation
|
@peterbarker @auturgy @tridge @julianoes Your feedback needed please. Thanks @bgptiste |
|
Thanks @bgptiste - we didn't get to this in the MAV Call, but will add to next week's agenda. |
|
Thanks a lot @hamishwillee. I have just updated the RFC to address the intended message rates and overhead, and I also mentioned the perspective of DroneCAN standardization. Another point that will be very interesting to discuss is the decision to use a single multi-band |
| Additionally, all relevant fields and enumerations have been renamed by replacing the `GPS_*` prefix with `GNSS_*`, in order to better reflect support for multiple satellite constellations. | ||
|
|
||
| ## Global integrity and resilience status for a GNSS receiver | ||
|
|
There was a problem hiding this comment.
I would list the proposed message first. That's the most interesing thing. Then the summary and finally detailed changes you have here (and possibly even have these in a <details> twistice. Makes it easier for reviewers who aren't interested in the old form and just want to see the new proposal.
Or to put it another way, as designer you had to do lots of thinking to migrate from one form to the next. Some reviewers will want that detail, but someone like me just wants to see that you had reasons :-)
| ```xml | ||
| <message id="441" name="GNSS_INTEGRITY"> | ||
| <description>Global integrity and resilience status for a GNSS receiver, like jamming and spoofing summary states, signal authentication and system errors. Per-band RF diagnostics are in GNSS_BANDS.</description> | ||
| <field type="uint8_t" name="id" instance="true">GNSS receiver id. Must match instance ids of other messages from same receiver.</field> | ||
| <field type="uint32_t" name="system_errors" enum="GNSS_SYSTEM_ERROR_FLAGS">Bitmask of errors in the GPS system. Vendors set only the bits they can detect.</field> | ||
| <field type="uint8_t" name="antenna_state" enum="GNSS_ANTENNA_STATE">Status of the main antenna supervisor.</field> | ||
| <field type="uint8_t" name="antenna_power" enum="GNSS_ANTENNA_POWER">Power state of the main antenna.</field> | ||
| <field type="uint8_t" name="authentication_state" enum="GNSS_AUTHENTICATION_STATE">Signal authentication state of the GNSS system.</field> | ||
| <field type="uint8_t" name="jamming_state" enum="GNSS_JAMMING_STATE">Signal jamming state of the GNSS system.</field> | ||
| <field type="uint8_t" name="spoofing_state" enum="GNSS_SPOOFING_STATE">Signal spoofing state of the GNSS system.</field> | ||
| <field type="uint8_t" name="raim_state" enum="GNSS_RAIM_STATE">Status of the RAIM processing.</field> | ||
| <field type="uint16_t" name="raim_hfom" units="cm" invalid="UINT16_MAX">Horizontal expected accuracy using satellites successfully validated using RAIM.</field> | ||
| <field type="uint16_t" name="raim_vfom" units="cm" invalid="UINT16_MAX">Vertical expected accuracy using satellites successfully validated using RAIM.</field> | ||
| <field type="uint16_t" name="corrections_age" units="cs" invalid="UINT16_MAX">Age of the most recently applied differential corrections, in centiseconds (10ms units).</field> | ||
| <field type="uint8_t" name="cpu_load" units="%" invalid="UINT8_MAX">Receiver CPU load in percent.</field> | ||
| <field type="uint32_t" name="up_time" units="s" invalid="UINT32_MAX">Time elapsed since the startup or the last reset of the receiver.</field> | ||
| </message> |
There was a problem hiding this comment.
Haven't considered this in detail yet, but when I do I'll be looking at:
- sensible type field sizes - are the fields too big/too small. IS there sufficient resoluion?
- Ranges - unless implied by he units, can we specifiy maxValue, minValue, increments.
- Units. Sufficient resolution?
- What are the fields used for. What would be lost if they were omitted.
- Description terminology. What is RAIM for example - is it easiely searchable to find out if you don't know or can it be summarized/linked.
|
|
||
| The proposed structure stores the information for all reported bands in a single `GNSS_BANDS` message. The `band_count` field indicates the number of frequency bands contained in the arrays below. Each field is therefore defined as a static array of size `GNSS_MAX_BANDS` (not yet defined), with the same index referring to the same reported band across all arrays. This avoids the overhead of multiple small messages while keeping the message structure simple for flight controller implementations. The choice of this structure is further discussed and justified in the [Intended message overhead](#intended-message-overhead) section. | ||
|
|
||
| Minimal `GNSS_BANDS` message: |
There was a problem hiding this comment.
Move to top of section
hamishwillee
left a comment
hamishwillee
left a comment
There was a problem hiding this comment.
@bgptiste I have only scanned this, but it looks like a really good basis for the discussion. Thank you.
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
…th terminology descriptions) + document structure (after reviews)
|
Thank you for the feedback @hamishwillee. The suggestions are really helpful. I have added the proposed message at the top of each section, as recommended. However, I decided not to include the changes made in a Regarding RAIM, a second look at the receiver documentation revealed that |
|
This pull request has been mentioned on Dronecode Forum | Open Source Drone Development. There might be relevant details there: https://discuss.px4.io/t/px4-dev-call-jul-22-2026-team-sync-and-community-q-a/49236/4 |
3 participants
The current
GNSS_INTEGRITYmessage provides GNSS resilience information at the receiver level, such as jamming, spoofing, and signal authentication status. However, it does not expose information at the individual RF-band level.This RFC proposes introducing a new
GNSS_BANDSmessage to complementGNSS_INTEGRITYby reporting jamming information for each RF front-end / frequency band. Providing per-band visibility would enable operators to better understand interference events, support post-flight analysis, and facilitate decision-making.The proposal also aims to keep these two messages as vendor-agnostic as possible, allowing different GNSS receiver manufacturers to populate the same fields using equivalent information while avoiding vendor-specific abstractions. The primary GNSS receiver outputs considered in this work are those from Septentrio (Mosaic-G5 and X5) and u-blox (X20 and F9) receivers, whose formats are supported by PX4 and ArduPilot. NovAtel OEM7 receiver outputs were also studied as secondary references to support and validate this vendor-agnostic approach.
Full details are provided in the dedicated RFC.
Thanks to @dakejahl for the valuable discussions that helped shape this proposal.
I look forward to your feedback and any suggestions for improvement.