Wir analysieren das Protokoll der Pager-Nachrichten POCSAG, Teil 2

Hallo Habr!

Im ersten Teil wurde das POCSAG-Messenger-Protokoll betrachtet. Digitale Nachrichten wurden berücksichtigt, jetzt werden wir zu mehr "vollwertigen" Nachrichten im ASCII-Format übergehen. Darüber hinaus ist es interessanter, sie zu dekodieren, weil Die Ausgabe ist lesbarer Text.


Für diejenigen, die daran interessiert sind, wie dies funktioniert, weiter unter dem Schnitt.

Signalempfang

Zunächst muss das Signal empfangen werden, für das wir denselben RTL-SDR-Empfänger und dasselbe HDSDR-Programm verwenden. Wir wissen bereits aus dem ersten Teil, dass Paging-Nachrichten digital sein können (der Inhalt ist nur die Zahlen 0-9, der Buchstabe U ist "ugrent", ein Leerzeichen und ein Paar Klammern) und alphanumerisch, der Inhalt sind vollständige ASCII-Zeichen. Natürlich kennen wir den Nachrichtentyp nicht im Voraus (es ist immer noch nicht möglich, sie "nach Gehör" zu dekodieren). Daher wählen wir bei der Aufnahme einfach eine Nachricht aus, die authentischer ist.



Das Programm zum Konvertieren einer WAV-Datei in einen Bitstrom wurde bereits berücksichtigt. Zeigen Sie daher sofort das Ergebnis an - die gesamte Paging-Nachricht sieht folgendermaßen aus:



Einige Merkmale sind mit bloßem Auge sofort sichtbar - beispielsweise ist zu erkennen, dass die Startsequenz 01010101010101 zweimal wiederholt wird. Das heißt, Diese Nachricht ist nicht nur länger, sondern besteht im Wesentlichen aus zwei zusammengeklebten Nachrichten, die der Standard jedoch nicht verbietet.

Dekodierung

Erinnern Sie sich zunächst an den kurzen Inhalt des vorherigen Teils . Die Paging-Nachricht beginnt mit einem langen Header 0101010101, gefolgt von einer Folge von "Paketen", die im Bild als Batch1..N angezeigt werden:



Jedes Paket beginnt mit einer Frame Sync Code-Startsequenz (01111100 ...), gefolgt von 32-Bit-Blöcken. Jeder Block kann entweder eine Adresse oder einen Nachrichtentext speichern.

Das letzte Mal, als wir nur digitale Nachrichten betrachteten, sind wir jetzt an ASCII-Nachrichten interessiert. Zunächst müssen Sie lernen, wie Sie zwischen ihnen unterscheiden können. Dazu benötigen wir das Feld „Funktionsbits“. Wenn diese 2 Bits 00 sind, ist die Nachricht digital, wenn 11, dann Text.

Wie aus der Abbildung ersichtlich ist, werden dem Nachrichtenfeld 20 Bits zugewiesen, was perfekt in den 5 4-Bit-BCD-Code passt, wenn die Nachricht digital ist. Wenn es sich bei der Nachricht jedoch um Text handelt, kann nicht viel Text in 20 Bit eingepasst werden, und 20 kann weder durch 7 noch durch 8 geteilt werden. Es kann davon ausgegangen werden, dass die erste Version des Protokolls (und es wurde bereits 1982 erstellt) nur digitale Nachrichten unterstützt ( ja und es ist unwahrscheinlich, dass die ersten Pager dieser Jahre auf Nixie-Röhren mehr anzeigen konnten ), und erst dann wurde in der nächsten Version die Unterstützung für ASCII hinzugefügt. Aber seitdem Es war nicht mehr möglich, den Formatstandard zu verletzen, es war einfacher - der Bitstrom wird einfach so wie er ist kombiniert (20 Bits werden aus jeder Nachricht extrahiert und am Ende des Puffers hinzugefügt), und erst dann wird all dies in Zeichen decodiert.

Betrachten Sie einen Block einer empfangenen Nachricht (zur Verdeutlichung werden Leerzeichen hinzugefügt):

0 0001010011100010111111110010010 1 00010100000110110011 11100111001 1 01011010011001110100 01111011100 1 11010001110110100100 11011000100 1 11000001101000110100 10011110111 1 11100000010100011011 11101110000 1 00110010111011001101 10011011010 1 00011001011100010110 10011000010 1 10101100000010010101 10110000101 1 00010110111011001101 00000011011 1 10100101000000101000 11001010100 1 00111101010101101100 11011111010 

In der ersten Zeile zeigt "0" im ersten Bit an, dass dies ein Adressfeld ist, und "11" in den Bits 20-21 zeigt an, dass diese Nachricht symbolisch ist. Nehmen Sie als nächstes einfach 20 Bits aus jeder Zeile und addieren Sie sie.

Wir erhalten die folgende Bitfolge:

 00010100000110110011010110100110011101001101000111011010010011000001101000 11010011100000010100011011001100101110110011010001100101110001011010101100 000010010101000101101110110011011010010100000010100000111101010101101 

Das POCSAG-Protokoll verwendet 7-Bit-ASCII. Teilen Sie die Zeile also einfach in Blöcke mit 7 Bit auf:

 0001010 0000110 1100110 1011010 0110011 1010011 ... 

Wir versuchen, Zeichencodes zu dekodieren (die ASCII-Tabelle wird im Internet leicht gegoogelt), und ... wir bekommen Müll an der Ausgabe. Öffnen Sie erneut die Dokumentation und suchen Sie den subtilen Satz "ASCII-Zeichen werden von links nach rechts platziert (MSB zu LSB). Das LSB sendet zuerst. " Das heißt, Zuerst wird das niederwertige Bit und dann das höherwertige Bit übertragen. Für die korrekte Decodierung von ASCII-Codes müssen 7-Bit-Zeichenfolgen umgedreht werden.

Um dies nicht manuell zu tun, schreiben wir Python-Code:

 def parse_msg(block): msgs = "" for cw in range(16): cws = block[32 * cw:32 * (cw + 1)] # Skip the idle word if cws.startswith("0111101010"): continue if cws[0] == "0": addr, type = cws[1:19], cws[19:21] print(" Addr:" + addr, type) else: msg = cws[1:21] print(" Msg: " + msg) msgs += msg # Split long string to 7 chars blocks bits = [msgs[i:i+7] for i in range(0, len(msgs), 7)] # Get the message msg = "" for b in bits: b1 = b[::-1] # Revert string value = int(b1, 2) msg += chr(value) print("Msg:", msg) print() 

Als Ergebnis erhalten wir die folgende Sequenz (Bits, Zeichencodes und die Zeichen selbst):

 0101000 40 ( 0110000 48 0 0110011 51 3 0101101 45 - 1100110 102 f 1100101 101 e 1100010 98 b 0101101 45 - 0110010 50 2 0110000 48 0 0110001 49 1 0111001 57 9 0100000 32 0110001 49 1 0110011 51 3 0111010 58 : 0110011 51 3 0110001 49 1 0111010 58 : 0110100 52 4 0110101 53 5 0100000 32 0101010 42 * 0110100 52 4 0110111 55 7 0110110 54 6 0101001 41 ) 0100000 32 1000001 65 A 1010111 87 W 1011010 90 Z 

Kombinieren Sie die Zeichen und erhalten Sie die Zeile: "(03-feb-2019 13:31:45 * 476) AWZ". Wie zu Beginn des Artikels versprochen, ist der Text gut lesbar.

Ein weiterer interessanter Punkt ist übrigens, dass das Protokoll, wie Sie sehen, 7-Bit-ASCII verwendet. Kyrillische Zeichen passen nicht in diesen Bereich, daher bleibt die Frage offen, wie Pager die russische Sprache blitzten. Wenn jemand weiß, schreibe in die Kommentare.

Schlussfolgerungen

Natürlich ist das Protokoll nicht vollständig verstanden, aber der interessanteste Teil wurde erledigt, und dann bleibt die Routine, die nicht mehr so ​​interessant ist. Zumindest gibt es keine Dekodierung von Empfängeradressen (Capcodes), und die Unterstützung für den Fehlerkorrekturcode (BCH Check Bits) ist nicht implementiert - dies würde die Korrektur von bis zu 2 "verdorbenen" Bits während der Übertragung ermöglichen. Das Ziel war jedoch nicht, einen vollwertigen Decoder herzustellen - es gibt bereits solche Decoder, und ein weiterer wird kaum benötigt.

Diejenigen, die versuchen möchten, Nachrichten mit rtl-sdr zu dekodieren, können dies selbst mit dem kostenlosen PDW- Programm tun. Es ist keine Installation erforderlich. Nach dem Start muss der HDSDR-Ausgang mit dem Programm Virtual Audio Cable auf den PDW-Eingang umgeleitet und in den PDW-Audioeinstellungen das entsprechende Gerät ausgewählt werden.

Das Ergebnis des Programms sieht ungefähr so ​​aus:



Zu diesem Thema können Paging-Nachrichten als geschlossen betrachtet werden. Diejenigen, die das Thema genauer untersuchen möchten, können die Quellcodes des Multimon-ng- Programms studieren, das viele Protokolle, einschließlich POCSAG und FLEX, decodieren kann.