Kami menganalisis protokol pesan pager POCSAG, bagian 2

Hai Habr!

Pada bagian pertama , protokol pengiriman POCSAG dipertimbangkan. Pesan digital dipertimbangkan, sekarang kita akan meneruskan ke lebih banyak "pesan lengkap" dalam format ASCII. Selain itu, lebih menarik untuk memecahkan kode mereka, karena hasilnya adalah teks yang bisa dibaca.


Bagi yang tertarik dengan cara kerjanya, lanjutkan di bawah cut.

Penerimaan sinyal

Pertama, sinyal harus diterima, untuk itu kami menggunakan penerima rtl-sdr dan program HDSDR yang sama. Kita sudah tahu dari bagian pertama bahwa pesan paging bisa digital (isinya hanya angka 0-9, huruf U adalah "jelek", spasi dan sepasang tanda kurung) dan alfanumerik, isinya penuh dengan karakter ASCII. Secara alami, kami tidak tahu sebelumnya jenis pesan (masih tidak mungkin untuk memecahkan kode "oleh telinga"), jadi ketika merekam kami hanya memilih pesan yang lebih otentik.



Program untuk mengonversi file wav ke bit stream telah dipertimbangkan, jadi segera tunjukkan hasilnya - pesan halaman secara keseluruhan terlihat seperti ini:



Beberapa fitur segera terlihat dengan mata telanjang - misalnya, dapat dilihat bahwa urutan awal 01010101010101 diulang dua kali. Yaitu Pesan ini tidak hanya lebih lama, tetapi pada dasarnya terdiri dari dua "direkatkan" bersama-sama, namun standar tidak melarangnya.

Decoding

Untuk memulai, ingat konten singkat dari bagian sebelumnya . Pesan halaman dimulai dengan header panjang 0101010101, diikuti oleh urutan "paket" yang ditunjukkan pada gambar sebagai Batch1..N:



Setiap paket dimulai dengan urutan mulai Frame Sync Code (01111100 ...) diikuti oleh blok 32-bit. Setiap blok dapat menyimpan alamat atau badan pesan.

Terakhir kali kami melihat pesan digital saja, sekarang kami tertarik pada pesan ASCII. Pertama-tama, Anda perlu belajar cara membedakannya. Untuk melakukan ini, kita perlu bidang “Function Bits” - jika 2 bit ini adalah 00, maka pesannya digital, jika 11, maka teks.

Seperti dapat dilihat dari gambar, 20 bit dialokasikan ke bidang pesan, yang hanya cocok dengan kode BCD 5-bit, jika pesannya digital. Tetapi jika pesan tersebut adalah pesan teks, maka tidak ada banyak teks yang dapat ditampung dalam 20 bit, dan 20 tidak dapat dibagi oleh 7 atau 8. Dapat diasumsikan bahwa versi protokol yang pertama (dan sudah dibuat pada tahun 1982) hanya mendukung pesan digital ( ya dan tidak mungkin bahwa pager pertama pada tahun-tahun itu pada nixie-tube dapat menampilkan lebih banyak ), dan hanya pada saat itu, dalam versi berikutnya, dukungan untuk ASCII ditambahkan. Tapi sejak itu itu tidak mungkin lagi melanggar standar format, itu lebih mudah - bitstream hanya digabungkan sebagaimana adanya (20 bit diekstraksi dari setiap pesan dan ditambahkan ke ujung buffer), dan hanya pada saat itu, semua ini diterjemahkan ke dalam karakter.

Pertimbangkan satu blok pesan yang diterima (spasi ditambahkan untuk kejelasan):

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 

Di baris pertama, "0" di bit pertama menunjukkan bahwa ini adalah bidang alamat, dan "11" dalam bit 20-21 menunjukkan bahwa pesan ini simbolis. Selanjutnya, ambil hanya 20 bit dari setiap baris dan tambahkan bersama.

Kami mendapatkan urutan bit berikut:

 00010100000110110011010110100110011101001101000111011010010011000001101000 11010011100000010100011011001100101110110011010001100101110001011010101100 000010010101000101101110110011011010010100000010100000111101010101101 

Protokol POCSAG menggunakan ASCII 7-bit, jadi bagilah garis menjadi blok-blok 7 bit:

 0001010 0000110 1100110 1011010 0110011 1010011 ... 

Kami mencoba mendekode kode karakter (tabel ASCII mudah di-Google-kan di Internet), dan ... kami mendapatkan sampah di output. Sekali lagi, buka dokumentasi dan temukan frasa halus "karakter ASCII ditempatkan dari kiri ke kanan (MSB ke LSB). LSB mentransmisikan terlebih dahulu. " Yaitu pertama, bit orde rendah ditransmisikan, dan kemudian bit orde tinggi - untuk decoding kode ASCII yang benar, string 7-bit harus dibalik.

Untuk menghindari melakukan ini secara manual, kami menulis kode Python:

 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() 

Hasilnya, kami mendapatkan urutan berikut (bit, kode karakter, dan karakter itu sendiri):

 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 

Gabungkan karakter bersama-sama dan dapatkan garis: "(03-feb-2019 13:31:45 * 476) AWZ". Seperti yang dijanjikan di awal artikel, teksnya cukup mudah dibaca.

Omong-omong, poin menarik lainnya adalah, seperti yang Anda lihat, protokol menggunakan ASCII 7-bit. Karakter Cyrillic tidak cocok dengan kisaran ini, jadi pertanyaan tentang bagaimana pager mem-flash bahasa Rusia tetap terbuka. Jika ada yang tahu, tulis di komentar.

Kesimpulan

Tentu saja, protokolnya tidak sepenuhnya dipahami, tetapi bagian yang paling menarik telah dilakukan, dan kemudian rutinitas tetap, yang tidak begitu menarik lagi. Minimal, tidak ada decoding dari alamat penerima (capcodes), dan dukungan untuk kode koreksi kesalahan (BCH Check Bits) tidak diterapkan - ini akan memungkinkan mengoreksi hingga 2 bit "rusak" selama transmisi. Namun, tujuannya bukan untuk membuat decoder lengkap - sudah ada decoder seperti itu, dan satu lagi hampir tidak diperlukan.

Mereka yang ingin mencoba mendekode pesan menggunakan rtl-sdr dapat melakukannya sendiri menggunakan program PDW gratis. Itu tidak memerlukan instalasi, setelah memulai perlu untuk mengarahkan kembali output HDSDR ke input PDW menggunakan program Kabel Audio Virtual dan memilih perangkat yang sesuai dalam pengaturan audio PDW.

Hasil program terlihat seperti ini:



Pada topik ini, pesan halaman dapat dianggap tertutup. Mereka yang ingin mempelajari topik lebih terinci dapat mempelajari kode sumber dari program multimon-ng , yang dapat men-decode banyak protokol, termasuk POCSAG dan FLEX.