Dahulu kala, ketika ponsel berharga sekitar $ 2.000 dan satu menit panggilan suara adalah 50 sen, pager benar-benar populer. Kemudian telepon seluler menjadi lebih murah, panggilan dan harga SMS menjadi lebih rendah, dan akhirnya pager kebanyakan menghilang.
Bagi orang-orang, yang memiliki pager sebelumnya, dan ingin tahu cara kerjanya, artikel ini akan bermanfaat.
Info utama
Bagi orang-orang yang lupa prinsip-prinsip atau lahir setelah 2000x, saya akan segera mengingatkan ide-ide utama.
Jaringan komunikasi paging memiliki beberapa keunggulan, yang terkadang penting bahkan sekarang:
- Ini adalah komunikasi satu arah, tanpa konfirmasi apa pun, sehingga jaringan tidak dapat kelebihan beban - itu tidak tergantung dari sejumlah pengguna. Pesan mentransmisikan terus menerus "sebagaimana adanya", satu demi satu, dan pager mendapatkan pesan jika nomornya (disebut Capcode) sama dengan nomor internal perangkat.
- Penerima ini sangat ringan (baik secara harfiah dan elektronik), dan dapat bekerja hingga satu bulan dari 2 baterai AA.
Ada dua standar dasar pengiriman pesan -
POCSAG (Grup Penasihat Standardisasi Kode Kantor Pos) dan
FLEX . Kedua standar ini cukup tua, POCSAG dibuat pada tahun 1982, dapat mendukung kecepatan 512, 1200 dan 2400 bit / s. Untuk mentransmisikan metode FSK (pengalihan frekuensi) digunakan dengan pemisahan frekuensi 4,5 KHz. FLEX sedikit lebih baru (dibuat oleh Motorola di ke-90), dapat bekerja dengan kecepatan hingga 6400 bit / s dan dapat menggunakan FSK2 dan FSK4.
Kedua protokol secara umum sangat mudah, dan sekitar 20 tahun yang lalu PC-decoder dibuat, yang dapat men-decode pesan dari port serial kartu suara (tidak ada enkripsi yang didukung, sehingga semua pesan dapat dibaca oleh siapa saja).
Mari kita lihat, cara kerjanya.
Menerima sinyal
Pertama, kita membutuhkan sinyal untuk decoding. Ayo ambil laptop, penerima rtl-sdr, dan dapatkan.

Keying shift frekuensi digunakan, jadi kami akan mengatur FM. Dengan HDSDR kami akan menyimpan sinyal dalam format WAV.
Mari kita periksa, apa yang kita dapatkan. Memuat file wav sebagai array data Python:
from scipy.io import wavfile import matplotlib.pyplot as plt fs, data = wavfile.read("pocsag.wav") plt.plot(data) plt.show()
Output (bit ditambahkan secara manual):

Seperti yang dapat kita lihat, mudah, dan bahkan "dengan mata telanjang" kita dapat menggambar bit dalam Paint, mudah untuk membedakan mana "0" dan di mana "1". Tetapi akan terlalu lama untuk melakukannya secara manual, saatnya untuk mengotomatiskan proses.
Setelah memperbesar grafik, kita dapat melihat bahwa setiap bit memiliki lebar 20 sampel. Kami memiliki 24000 sampel per file bitrate wav kedua, sehingga kecepatan penguncian adalah 1200bit / s. Mari kita temukan posisi penyilangan nol - ini adalah awal dari urutan bit. Mari kita juga menambahkan spidol untuk memverifikasi bahwa semua bit ada di tempat yang tepat.
speed = 1200 fs = 24000 cnt = int(fs/speed) start = 0 for p in range(2*cnt): if data[p] < - 50 and data[p+1] > 50: start = p break
Seperti yang dapat kita lihat, ini tidak sepenuhnya cocok (pemancar dan penerima memiliki frekuensi yang sedikit berbeda), tetapi cukup untuk decoding.

Untuk sinyal yang panjang kita mungkin perlu algoritma koreksi frekuensi otomatis, tetapi untuk sinyal semacam ini tidak kritis.
Langkah terakhir - kita perlu menerjemahkan file wav ke urutan bit. Ini juga mudah, kita tahu panjang setiap bit, jika jumlah data positif, kita akan menambahkan "1", jika tidak "0" (akhirnya ditemukan bahwa sinyal perlu dikembalikan, sehingga 0 dan 1 diganti) .
bits_str = "" for p in range(0, data.size - cnt, cnt): s = 0 for p1 in range(p, p+cnt): s += data[p] bits_str += "1" if s < 0 else "0" print("Bits") print(bits_str)
Output - urutan bit yang tepat (dalam format string), yang berisi pesan kami.
101010101010101010101010101010101010101010101010101010101010101010101010101
010101010101010101010101010101010101010101010100111110011010010000101001101
100001111010100010011100000110010111011110101000100111000001100101110111101
010001001110000011001011101111010100010011100000110010111011110101000100111
000001100101110111101010001001110000011001011101111010100010011100000110010
011011110101000100111000001100101110111101010001001110000011001011101111010
100010011100000110010111011110101000100111000001100101110111101010001001110
...
111101111
Mengurai kode hanya-angka
Urutan bit jauh lebih nyaman daripada file-wav, kita dapat mengekstrak data darinya. Pertama, mari kita pisahkan data menjadi blok 4 byte.
10101010101010101010101010101010
10101010101010101010101010101010
10101010101010101010101010101010
10101010101010101010101010101010
01111100110100100001010011011000
01111010100010011100000110010111
01111010100010011100000110010111
01111010100010011100000110010111
01111010100010011100000110010111
00001000011011110100010001101000
10000011010000010101010011010100
01111100110100100001010111011000
11110101010001000001000000111000
01111010100010011100000110010111
01111010100010011100000110010111
01111010100010011100000110010111
00100101101001011010010100101111
Kita pasti bisa melihat polanya. Sekarang kita perlu menemukan, apa arti setiap bagian. Manual POCSAG tersedia
dalam format PDF , mari kita periksa deskripsi struktur data.

Sekarang jauh lebih jelas. Header berisi blok panjang "10101010101", digunakan untuk "membangunkan" pager dari mode sleep. Pesan itu sendiri berisi blok Batch-1 ... Batch-N, setiap blok dimulai dari urutan unik FSC. Kemudian, seperti yang dapat kita lihat di manual, jika string dimulai dari "0", itu berisi alamat penerima. Alamat itu sendiri (capcode) disimpan adalah pager, dan jika tidak cocok, pager akan mengabaikan pesan. Jika sebuah string dimulai dari "1", itu berisi isi pesan. Dalam contoh kita, kita memiliki 2 string tipe ini.
Mari kita tidak memeriksa setiap blok. Kita juga dapat melihat kode siaga - blok kosong 01111 ... 0111, mereka tidak memiliki informasi berguna. Setelah menghapusnya, kami hanya mendapatkan ini:
01111100110100100001010011011000 - Frame Sync
00001000011011110100010001101000 - Address
10000011010000010101010011010100 - Message
01111100110100100001010111011000 - Frame Sync
11110101010001000001000000111000 - Message
00100101101001011010010100101111 - Address
Kita perlu menemukan, ada apa di dalam.
Setelah memeriksa manual, jelas bahwa ada dua jenis pesan -
hanya numerik dan
alfa-numerik . Pesan numerik saja disimpan sebagai kode BCD 4bit, sehingga 20 bit dapat berisi 5 simbol (ada juga bit CRC, kami tidak menggunakannya untuk saat ini). Jika pesan tersebut alfanumerik, digunakan pengkodean ASCII 7-bit. Pesan ini terlalu pendek sehingga hanya berupa pesan numerik saja.
Dari string 10000011010000010101010011010100 dan 11110101010001000001000000111000 kita bisa mendapatkan urutan 4-bit ini:
1 0000 0110 1000 0010 10101 0011010100 - 0h
6j 8j 2j Ah
1 1110 1010 1000 1000 00100 0000111000 - Eh Ah
8j 8j 2j
Langkah selanjutnya, adalah untuk mendapatkan tabel decoding dari manual:

Jelas bahwa pesan numerik saja dapat berisi digit 0-9, huruf U ("ugrent"), spasi, dan dua tanda kurung. Mari kita menulis metode kecil untuk memecahkan kode itu:
def parse_msg(block):
Akhirnya, kami mendapatkan pesan "0682 *) * 882".
Sulit untuk mengatakan apa maknanya, tetapi jika hanya pesan numerik yang digunakan, seseorang mungkin membutuhkannya.
Mengurai kode pesan alfa-numerik
Langkah selanjutnya, dan yang lebih menarik, adalah mendekode pesan alpha-numeric. Ini lebih menarik, karena sebagai output, kita harus mendapatkan teks yang dapat dibaca manusia.
Pertama, kita perlu merekam pesan lagi, kita akan menggunakan HDSDR. Kami tidak tahu jenis pesan sebelum decoding, jadi kami hanya akan merekam pesan terpanjang, kami bisa dapatkan, dan akan berharap bahwa itu berisi beberapa teks.

Setelah mengkonversi dari wav ke sedikit urutan (lihat kode Python di atas), kita mendapatkan ini:

Beberapa hal menarik yang dapat kita lihat segera, dengan mata telanjang - sebagai contoh, urutan awal 01010101010101 berulang dua kali. Dengan demikian, pesan ini tidak hanya lebih lama, secara harfiah mengandung dua pesan, digabung bersama (standar tidak menyangkal ini, btw).
Seperti yang telah kami temukan sebelumnya, setiap blok data dimulai dari urutan, yang disebut Frame Sync Code (01111100 ...), setelah itu blok 32-bit dikirim. Setiap blok dapat menyimpan alamat atau isi pesan.
Sebelumnya kami mendapat pesan numerik saja, sekarang kami ingin membaca pesan ASCII. Pertama, kita perlu membedakan mereka. Data ini disimpan dalam bidang "Function Bits" (bit 20-21) - jika kedua bitnya 00, itu hanya pesan numerik, jika bitnya 11, itu adalah pesan teks.
Menarik untuk disebutkan, bahwa bidang pesan memiliki panjang 20-bit, sehingga ideal untuk menempatkan lima blok 4-bit di sana dalam kasus pesan numerik saja. Tetapi jika kita memiliki pesan ASCII 7bit, kita tidak dapat membagi 20 hingga 7. Kemungkinan untuk memprediksi bahwa versi protokol pertama hanya mendukung pesan numerik saja (jangan lupa bahwa itu dibuat pada tahun 1982
dan mungkin pager nixie-tube pertama) tidak dapat menampilkan lebih banyak ), dan hanya kemudian dukungan pesan ASCII ditambahkan. Karena alasan warisan standar framing tidak berubah, dan pengembang menggunakan pendekatan yang mudah - mereka hanya menggabungkan bit "sebagaimana adanya", satu demi satu. Dari setiap pesan kita perlu mengambil 20 bit dan menggabungkannya ke pesan berikutnya, akhirnya kita bisa mendekode isi pesan.
Mari kita lihat satu blok pesan kita (spasi lebih mudah dibaca):
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
"0" bit Pada string pertama menunjukkan kepada kita bahwa itu adalah bidang alamat, dan "11" dalam 20-21 bit menunjukkan kepada kita bahwa pesan tersebut benar-benar alfa-numerik. Kemudian kita hanya mengambil 20 bit dari setiap string dan menggabungkannya.
Ini adalah urutan bit kami:
00010100000110110011010110100110011101001101000111011010010011000001101000
11010011100000010100011011001100101110110011010001100101110001011010101100
000010010101000101101110110011011010010100000010100000111101010101101
Dalam POCSAG 7-bit kode ASCII digunakan, jadi kami akan membagi string menjadi 7 blok char:
0001010 0000110 1100110 1011010 0110011 1010011 ...
Setelah mencoba men-decode-nya (tabel ASCII dapat dengan mudah ditemukan di Internet), kita mendapatkan ... tidak ada apa-apa. Memeriksa manual lagi, dan inilah frasa kecil "karakter ASCII ditempatkan dari kiri ke kanan (MSB ke LSB). LSB mentransmisikan terlebih dahulu. " Jadi, bit rendah mentransmisikan pertama - untuk decoding yang benar kita perlu membalik semua string.
Terlalu membosankan untuk melakukannya secara manual, jadi mari kita menulis kode Python:
def parse_msg(block): msgs = "" for cw in range(16): cws = block[32 * cw:32 * (cw + 1)]
Akhirnya, kita mendapatkan urutan ini (bit, kode simbol, dan simbol ASCII):
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
Setelah penggabungan kita mendapatkan string: "(03-feb-2019 13:31:45 * 476) AWZ". Seperti yang dijanjikan, itu cukup mudah dibaca manusia.
By the way, menarik untuk disebutkan, bahwa kode ASCII 7-bit digunakan. Simbol dari beberapa huruf (Jerman, Sirilik, dll) tidak dapat dikodekan dengan benar dalam 7 bit. Kenapa 7 bit? Mungkin para insinyur telah memutuskan bahwa "7 bit akan cukup untuk semua", siapa tahu ...
Kesimpulan
Sangat menarik untuk diselidiki, bagaimana POCSAG bekerja. Ini adalah salah satu protokol yang jarang, yang digunakan sampai sekarang, yang secara harfiah dapat diuraikan pada lembaran kertas (dan saya pasti tidak akan mencoba ini dengan TETRA atau GSM).
Yang pasti, protokol POCSAG tidak sepenuhnya dijelaskan di sini. Bagian yang paling penting dan menarik dilakukan, hal-hal lain tidak begitu menarik. Setidaknya, tidak ada decoding kode kode, dan tidak ada kode koreksi kesalahan (BCH Periksa Bit) - itu dapat memungkinkan untuk memperbaiki hingga 2 bit yang salah dalam pesan. Tetapi tidak ada tujuan untuk menulis decoder POCSAG lain di sini, sudah ada cukup banyak dari mereka.
Bagi mereka yang ingin menguji decoding nyata dengan rtl-sdr,
aplikasi PDW freeware dapat digunakan. Itu tidak memerlukan instalasi, hanya cukup untuk meneruskan suara dari HDSDR ke PDW melalui aplikasi Kabel Audio Virtual.
Hasilnya terlihat seperti ini:

(harap diingat bahwa decoding pesan layanan publik dapat ilegal di beberapa negara, dan tetap menghormati privasi penerima)
Jika seseorang ingin mendapatkan lebih banyak informasi tentang topik ini, sumber decoder
multimon-ng tersedia, ia dapat mendekode banyak protokol, juga POCSAG dan FLEX.
Terima kasih sudah membaca.