Wie extrahiere ich die Interrogator-ID aus einer DF11-Nachricht?

Ich habe eine Klasse geschrieben, die rohe Mode-S-Nachrichten dekodiert. Als ich neulich die ICAO-Spezifikationen durchsuchte, bemerkte ich, dass die Interrogator-ID in der DF11-Nachricht zurückgesendet wurde.

Ich dachte, es wäre eine lustige Übung, festzustellen, wo in meinem Abdeckungsbereich Abfragen von bestimmten Radaranlagen zu sehen sind.

Aber es fällt mir wirklich schwer, herauszufinden, wie ich die Vernehmer-ID extrahieren kann.

Für diese DF11-Nachricht:

5D406FDB0D62DD

Ich habe folgendes:

Binary: 01011101010000000110111111011011000011010110001011011101
Integer Words:
    [0] => 93
    [1] => 64
    [2] => 111
    [3] => 219
    [4] => 13
    [5] => 98
    [6] => 221

 CA: 5
 AA: 4222939
 Address: 406FDB
 Parity: 255
 Residual: 0

Da der Restwert 0 ist, weiß ich, dass dies eine gültige DF11-Nachricht ist und die Adresse ebenfalls überprüft wird.

Aus der ICAO-Spezifikation:

„Der bei der Downlink-PI-Feldgenerierung verwendete Code muss aus einer Folge von 24 Bits (a1, a2, ..., a24) bestehen, wobei die ersten 17 Bits NULLEN sind und die nächsten drei Bits eine Kopie des Codelabels ( CL)-Feld (3.1.2.5.2.1.3) und die letzten vier Bits sind eine Kopie des Abfragecode-(IC)-Felds (3.1.2.5.2.1.2)."

In diesem Fall würde ich erwarten, dass das Ende der letzten drei ganzzahligen Wörter (4,5 und 6) hauptsächlich Nullen sind, aber das sind sie nicht.

Ich habe die Dokumentation mehrfach durchgesehen, kann aber einfach nicht sehen, wie ich die II- und SL-Codes aus dem Paritätswert herausbekomme.

Ich berechne den Paritätswert wie folgt:

$this->_pi = $this->_int[4] | $this->_int[5] | $this->_int[6];

wo | in PHP ist der ODER-Operator. Ist das mein Fehler?

Antworten (1)

Ihre Berechnung von $this->_piORs nur die drei Paritätsbytes zusammen, was sicherlich keinen Sinn ergibt. Ich bin mir nicht sicher, was Sie sich davon erhoffen. Selbst XORing zusammen scheint keinen Zweck zu erfüllen.


Adressierung und Prüfsummenbildung im Mode-S-Protokoll arbeiten auf eine abgefahrene Weise, um Bits zu sparen. Die letzten 3 Bytes einer Nachricht werden als CRC-Prüfsumme (die Anhang 10 "Parität" nennt) der ersten 4/11 Bytes konstruiert, XOR- verknüpft mit einer Adresse für die "Konversation", zu der die Nachricht gehört. Wenn Sie eine Nachricht erhalten, sollten Sie den rohen CRC selbst berechnen und ihn dann aus den Bytes XOR-verknüpfen. Was übrig bleibt, ist die Adresse, und indem Sie sie mit Adressen vergleichen, die Sie interessieren, können Sie sehen, ob die Nachricht für Sie oder alternativ entweder verstümmelt oder für jemand anderen war.

In dem grundlegenden Modus-S-Abfrageprotokoll ist diese "Adresse" nur die Flugzeugzellenadresse, und das Prüfsummen-XOR-Adressfeld heißt AP. Bei Uplink-Nachrichten wissen Transponder natürlich, was ihre eigene Adresse ist – und bei Downlink wissen Radargeräte, welche Adressen sie zuletzt abgefragt haben.

In einigen anderen Fällen ist die "Adresse" die "Abfragekennung", und das Prüfsummen-XOR-Adressfeld heißt PI.

Bei DF11 weiß der Transponder, welchen II er in seine Antworten einfügen muss, da er sie aus der All-Call-Nachricht herausholt, und das Radar weiß, welcher II seinen eigenen All-Calls entspricht, sodass es diese Antworten erkennen kann.

Beim Squitter schließlich, bei dem der Transponder eine Downlink-Nachricht sendet, ohne von einer Uplink-Nachricht aufgefordert zu werden, setzt er die "Adresse" auf 0.


Wenn Sie ADS-B-Broadcasts dekodiert haben, hören Sie auf Squitter – so können Sie sie als diejenigen identifizieren, bei denen der von Ihnen berechnete CRC dem PI-Feld in der Nachricht entspricht (weil XORing 0 in den CRC ihn nicht ändert). ). Alles mit einer anderen Adresse sieht für Ihren Code wie Prüfsummenfehler aus.

Da die von Ihnen angezeigte DF11-Nachricht mit der Prüfsumme übereinstimmt, muss es sich um DF11-Squitter handeln. Davon gibt es viele zu hören; TCAS hängt davon ab, dass jeder sie kontinuierlich sendet.

Um DF11-Nachrichten mit einer Interrogator-ID ungleich Null zu finden, sollten Sie nach Nachrichten suchen, bei denen die letzten drei Bytes nach dem XOR-Verknüpfen des CRC mit 17 Nullen beginnen, aber dann mindestens einige der verbleibenden 7 Bits ungleich Null haben.

Vielen Dank für die sehr klare Erklärung :-) Ich werde meinen Code morgen noch einmal durchgehen und zurück posten, aber ich kann genau sehen, wie es jetzt funktionieren sollte .