Von receiver-trust gelesene Empfängerprotokolle (0,38)
Durchgehend nur lesend: Nichts hier schreibt ein Byte an einen Empfänger, und es gibt keinen Sendepfad irgendeiner Art. Beratende Software, keine typzugelassene Navigationsausrüstung (IEC 61108, IEC 61162): Der Betreiber bleibt verantwortlich.
Die eigenen Spoofing- und Jamming-Kennzeichen des Empfängers (UBX)#
| Nachricht | Feld | gelesen als |
|---|---|---|
| UBX-NAV-STATUS (0x01 0x03), 16 Bytes | Byte flags2 bei Offset 7, Bits 4..3: spoofDetState |
0 unbekannt oder deaktiviert, 1 kein Spoofing angezeigt, 2 Spoofing angezeigt, 3 mehrere Spoofing-Anzeigen (Protokoll 18 und später; Schnittstellenbeschreibung u-blox F9 HPG 1,32, Abschnitt 3.15.20) |
| UBX-SEC-SIG (0x27 0x09) Version 1, 12 Bytes | jamFlags bei 4 (Bit 0 jamDetEnabled, Bits 2..1 jammingState); spfFlags bei 8 (Bit 0 spfDetEnabled, Bits 3..1 spoofingState) |
Zustände werden nur gelesen, wo der Detektor aktiviert ist; 0 unbekannt, 1 keiner, 2 Warnung oder angezeigt, 3 kritisch oder bestätigt |
| UBX-SEC-SIG Version 2 | sigSecFlags bei 1 (Bit 0 jamDetEnabled, Bits 2..1 jammingState, Bit 3 spfDetEnabled, Bits 6..4 spoofingState); jamNumCentFreqs bei 3 und so viele 4-Byte-Gruppen (nicht verwendet) |
wie oben |
Quelle des SEC-SIG-Layouts. Die Schnittstellenbeschreibungen u-blox F9 HPG 1,32 und M10 SPG 5,10, die beim Verfassen heruntergeladen werden konnten, nennen UBX-SEC-SIG, definieren es aber nicht. Die obigen Layouts sind die der späteren u-blox-Schnittstellenbeschreibungen, wie sie in der Bibliothek pyubx2 übernommen wurden (BSD-3-Clause, SEC-SIG-V1 und SEC-SIG-V2); die Fixture-Tests in tests/receiver_trust_self_report.rs sind aus diesem Layout aufgebaut, nicht aus der Ausgabe eines echten Empfängers. Layout aus offener Übernahme, nicht gegen den aktuellen Herstellerleitfaden geprüft: Prüfen Sie es gegen die aktuelle u-blox-Schnittstellenbeschreibung, bevor Sie sich auf SEC-SIG verlassen.
Ein SEC-SIG hat keine Wochenzeit; es gehört zur aktuellen Navigationsepoche. Ein bereits in einer Epoche gelesener Zustand bleibt erhalten, außer ein späterer ist schlechter.
Der Vergleich receiver-self-report#
Wo ein Log diese Kennzeichen enthält, hat jede Epoche des Ergebnisses self_report (die beiden Zustände, ob der Empfänger kennzeichnet, ob ein Kshana-Monitor Alarm ausgelöst hat, und agreement: both, receiver-only, kshana-only, neither oder calibrating), und das Ergebnis hat receiver_self_report mit den Zählungen und der ersten Epoche von jeder. Der Empfänger „kennzeichnet“ ab einem Zustand von 2 oder mehr. Es löst keinen Alarm aus und ändert keine Bewertung, und keine der beiden Seiten ist die Grundwahrheit: Übereinstimmung ist keine Validierung, und eine Abweichung besagt, dass ein Detektor etwas gesehen hat, das der andere nicht sah, nichts darüber, welcher recht hatte. Der Streifen in Studio liest epochs[].self_report.
Septentrio SBF (format = "sbf")#
receiver_trust::ingest::read_sbf dekodiert mit dem Crate sbf-tools (0,4, MIT; seine einzige Abhängigkeit ist thiserror; eine permissive Lizenz, die deny.toml zulässt). Gelesene Blöcke: PVTGeodetic (4007) für die Lösung, MeasEpoch (4027) für C/N0 je Satellit und Signal (band ist der Name des Signals, etwa L1CA) und RFStatus (4092) für die Zahl der HF-Bänder, deren Byte Info ungleich null ist (rf_bands_reported, übernommen und nicht interpretiert: es zählt nie als Kennzeichen). Epochen werden nach Wochenzeit und Wochennummer geschlüsselt und in GPS-Zeit beschriftet (2024-09-05T00:00:00.000 GPST). Ein Block, dessen CRC oder Parsing fehlschlägt, zählt als übersprungener Datensatz. Dieser Leser liest weder AGC noch einen Jamming-Indikator, daher laufen die Monitore für C/N0-Abfall und Lock-Verlust, die Monitore für AGC und Jamming-Indikator jedoch nicht.
Quelle der Layouts. Der Referenzleitfaden von Septentrio konnte beim Verfassen nicht heruntergeladen werden (der Server hat die Anfrage abgelehnt), daher wurden die Layouts aus dem Quelltext von sbf-tools übernommen, der den Leitfaden zitiert, und die Fixtures in tests/receiver_trust_sbf.rs sind synthetische Blöcke, die nach diesem Layout und seinem CRC-16-CCITT aufgebaut sind. Es wurde kein echtes SBF-Log verwendet. Layout aus dem Open-Source-Crate, nicht gegen den aktuellen Herstellerleitfaden geprüft: Prüfen Sie es gegen den Referenzleitfaden von Septentrio, bevor Sie sich darauf verlassen.
Direkte serielle und USB-Eingabe (receiver-trust live --serial)#
kshana receiver-trust live session.toml --serial /dev/ttyUSB0 --baud 4800 [--gate ...]Nur Unix. Es öffnet das Gerät zum Lesen, setzt die lokale Leitung auf Rohmodus bei --baud (Standard 4800, die NMEA-0183-Rate) und liest NMEA-Zeilen wie jede andere Quelle. Es schreibt nie an den Empfänger. --configure wird mit einer Erklärung zurückgewiesen: Kshana konfiguriert keine Empfänger; stellen Sie den Empfänger mit dem Werkzeug des Herstellers auf NMEA-Ausgabe ein und lesen Sie ihn dann. Der Eingang ist NMEA, wie bei jeder Quelle von live (UBX und SBF werden aus Dateien gelesen). Ein Gerät, das verschwindet, beendet den Befehl als Fehler (Exit 1), damit ein Supervisor ihn neu startet; die Schicht verbindet sich nicht neu. Getestet an einer Pseudo-Terminal-Schleife (tests/receiver_trust_live_serial.rs), einschließlich dessen, dass die Master-Seite vom Befehl kein Byte erhält.