-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Septentrio resillience reporting #25012
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
b86cd20
72f330d
1e47499
d1c5a0d
8bdfb1f
e896905
67b544b
a491864
2005816
e3e2442
d2c5070
1a26610
b8e221e
c340690
b73dc8c
9ea56ec
71544ec
7ba494d
838b5e6
af6e9ed
487fd9f
df09e66
daeb1e8
b95da27
8da7fff
97a5a35
7dc69f0
46c9a74
8dc7fb5
499ef9b
b45902e
a73101d
7758022
2663ed1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
# Gnss quality indicators | ||
|
||
uint64 timestamp # time since system start (microseconds) | ||
uint32 device_id # unique device ID for the sensor that does not change between power cycles | ||
|
||
bool quality_available # Set to true if quality indicators are available | ||
uint8 quality_corrections # Corrections quality from 0 to 10, or 255 if not available | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are all of these fields simply 0-10 with no specific meaning? Unless the integer values are actually meaning can we publish them as a percentage in a float? That will be a bit more self explanatory from a log review standpoint. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The value represents a quality score where 0 indicates poor quality and 10 indicates excellent quality. We use an integer score instead of a percentage because a percentage could be misleading, implying something is "incomplete", this is aalso a common practice in other applications/daily life to rate smth not in percentages but based on the scale. Also such scoring keeps it consistent with the Septentrio web tool, which is familiar to most users of this receiver. But we can further discuss this |
||
uint8 quality_receiver # Overall receiver operating status from 0 to 10, or 255 if not available | ||
uint8 quality_gnss_signals # Quality of GNSS signals from 0 to 10, or 255 if not available | ||
uint8 quality_post_processing # Expected post processing quality from 0 to 10, or 255 if not available |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -30,18 +30,26 @@ float32 vdop # Vertical dilution of precision | |
int32 noise_per_ms # GPS noise per millisecond | ||
uint16 automatic_gain_control # Automatic gain control monitor | ||
|
||
uint8 JAMMING_STATE_UNKNOWN = 0 | ||
uint8 JAMMING_STATE_OK = 1 | ||
uint8 JAMMING_STATE_WARNING = 2 | ||
uint8 JAMMING_STATE_CRITICAL = 3 | ||
uint8 jamming_state # indicates whether jamming has been detected or suspected by the receivers. O: Unknown, 1: OK, 2: Warning, 3: Critical | ||
int32 jamming_indicator # indicates jamming is occurring | ||
|
||
uint8 SPOOFING_STATE_UNKNOWN = 0 | ||
uint8 SPOOFING_STATE_NONE = 1 | ||
uint8 SPOOFING_STATE_INDICATED = 2 | ||
uint8 SPOOFING_STATE_MULTIPLE = 3 | ||
uint8 spoofing_state # indicates whether spoofing has been detected or suspected by the receivers. O: Unknown, 1: OK, 2: Warning, 3: Critical | ||
uint8 JAMMING_STATE_UNKNOWN = 0 #default | ||
uint8 JAMMING_STATE_OK = 1 | ||
uint8 JAMMING_STATE_MITIGATED = 2 | ||
uint8 JAMMING_STATE_DETECTED = 3 | ||
uint8 jamming_state # indicates whether jamming has been detected or suspected by the receivers. O: Unknown, 1: OK, 2: Mitigated, 3: Detected | ||
int32 jamming_indicator # indicates jamming is occurring | ||
|
||
uint8 SPOOFING_STATE_UNKNOWN = 0 #default | ||
uint8 SPOOFING_STATE_OK = 1 | ||
uint8 SPOOFING_STATE_MITIGATED = 2 | ||
uint8 SPOOFING_STATE_DETECTED = 3 | ||
uint8 spoofing_state # indicates whether spoofing has been detected or suspected by the receivers. O: Unknown, 1: OK, 2: Mitigated, 3: Detected | ||
|
||
# Combined authentication state (e.g. Galileo OSNMA) | ||
uint8 AUTHENTICATION_STATE_UNKNOWN = 0 #default | ||
uint8 AUTHENTICATION_STATE_INITIALIZING = 1 | ||
uint8 AUTHENTICATION_STATE_ERROR = 2 | ||
uint8 AUTHENTICATION_STATE_OK = 3 | ||
uint8 AUTHENTICATION_STATE_DISABLED = 4 | ||
uint8 authentication_state # GPS signal authentication state | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not exactly sure where the line is between sensor_gps and sensor_gnss_status, but as a start can you place all of these "status" fields into sensor_gnss_status as well? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The separation of the topics was based on the original SBF messages and a logical split between critical and non-critical data. The principle is to keep sensor_gps for essential, high-frequency parameters like position, system errors, and resilience data. In contrast, sensor_gnss_status is intended for more general, informative data that is less critical and does not require such frequent updates. This design keeps the primary sensor_gps topic cleaner. It also makes sensor_gnss_status a flexible place to add more informational parameters in the future without overloading the main topic |
||
|
||
float32 vel_m_s # GPS ground speed, (metres/sec) | ||
float32 vel_n_m_s # GPS North velocity, (metres/sec) | ||
|
@@ -55,6 +63,16 @@ uint64 time_utc_usec # Timestamp (microseconds, UTC), this is the timestamp whi | |
|
||
uint8 satellites_used # Number of satellites used | ||
|
||
uint32 SYSTEM_ERROR_OK = 0 #default | ||
uint32 SYSTEM_ERROR_INCOMING_CORRECTIONS = 1 | ||
uint32 SYSTEM_ERROR_CONFIGURATION = 2 | ||
uint32 SYSTEM_ERROR_SOFTWARE = 4 | ||
uint32 SYSTEM_ERROR_ANTENNA = 8 | ||
uint32 SYSTEM_ERROR_EVENT_CONGESTION = 16 | ||
uint32 SYSTEM_ERROR_CPU_OVERLOAD = 32 | ||
uint32 SYSTEM_ERROR_OUTPUT_CONGESTION = 64 | ||
uint32 system_error # General errors with the connected GPS receiver | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Seems like a good one for gnss status as well. |
||
|
||
float32 heading # heading angle of XYZ body frame rel to NED. Set to NaN if not available and updated (used for dual antenna GPS), (rad, [-PI, PI]) | ||
float32 heading_offset # heading offset of dual antenna array in body frame. Set to NaN if not applicable. (rad, [-PI, PI]) | ||
float32 heading_accuracy # heading accuracy (rad, [0, 2PI]) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sure you populate the device_id everywhere, that's how we'll know with GNSS a particular sensor_gnss_status topic corresponds with (if there's more than 1).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The device_id for the sensor_gnss_status message is populated within the process_message() function, specifically in the case BlockID::QualityInd: block.
This is the only location where the _message_sensor_gnss_status struct is populated, and the device_id is set immediately ( line1231 ) before the message is published. So it should be fine