«Верни мне мой 1996-й — часть 2»: отправляем сообщения на пейджер

Хэллоуин уже прошёл, но мистический туман пока даже не собирается развеиваться. В первой части своего повествования я рассказывал, как можно проверить и подготовить к работе этих исторических «франкенштейнов», сегодня же настал черёд их пробуждения. Этим темным-темным осенним вечером в темном-темном углу квартиры мы будем творить очень темные дела: сегодня мы установим спиритический сеанс связи с «душами» гаджетов, которые давно спят вечным сном…

Дисклеймер

Как вы помните из предыдущей части, сообщения на пейджеры доставляются с помощью радиоволн. Частоты пейджеров зачастую лежат вне безлицензионных диапазонов, поэтому повторение описанных в этой статье инструкций может привести к нарушению законодательства и созданию помех в работе различных служб. Внимательно проверьте свой пейджер и список разрешенных для безлицензионного вещания частот в вашем регионе и никогда не отправляйте сообщения вне их пределов. Наилучшим выбором для экспериментов являются синтезаторные пейджеры, частота приема у которых переведена на диапазон 433 МГц (или любой другой, разрешенный в вашем регионе).

В предыдущей части

Мы рассматривали пейджер и установили, что для его работы нам нужно знать следующие его характеристики:

• Частоту приемника
• CAP код
• Скорость передачи данных
• Режим инверсии

Сегодня мы рассмотрим, как это все связывается воедино и используется на практике. В рамках своих экспериментов я реализовал простой, но в то же время полноценно работающий и обладающий кучей возможностей аппаратно-программный комплекс для передачи сообщений на пейджеры, сделанный на базе Arduino. Исходники и инструкции доступны на GitHub и распространяются под MIT лицензией. Логически сегодняшний пост будет разбит на 2 части: первая описывает кодировку сообщений, вторая — их передачу. Для начала рассмотрим формат, в котором пейджеры принимают сообщения.

Протокол POCSAG

Появился достаточно давно и устарел практически сразу после своего выхода, однако тем не менее активно использовался в пейджинге, а где-то на местах используется до сих пор. Существовали и более продвинутые протоколы обмена, например, FLEX, но пейджеров с их поддержкой было выпущено немного, и особого распространения он не получил. На POCSAG имеется довольно подробная документация, однако официальные стандарты в некоторых местах плавают. Итак, сообщение на пейджер имеет следующий формат:

Оно представляет собой «матрёшку» из различных структур данных:

• Преамбулы длиной не менее 576 бит, представляющей собой просто последовательность нулей и единиц (101010…)
• Одного или более пакетов (батчей) длиной 544 бита каждый

Преамбула выполняет важную роль: она «будит» приемники пейджеров, которые затем по ней синхронизируются. Физическое кодирование в POCSAG осуществляется с помощью обычного RZ (Return To Zero) кода, поэтому для корректного приема сообщений очень важно совпадение таймингов приемника и передатчика.

Пакеты несут в себе полезную информацию и начинаются с особого слова FSC (Frame Synchronization Code) длиной 32 бит, которое позволяет пейджеру различать один пакет от другого и всегда имеет значение 0x7CD214D8. Далее следует тело пакета, которое несет в себе 8 фреймов длиной по 64 бита, а каждый фрейм в свою очередь состоит из двух кодовых слов по 32 бита. Кодовые слова могут быть трех видов: пустыми (idle), адресными и словами сообщения:

Idle — самый простой вариант, в таком слове просто передается константа 0x7A89C197 по аналогии FSC, сделано это, как вы догадываетесь, также для синхронизации, ибо передавать просто 32 нуля или 32 единицы в пустом кодовом слове чревато рассинхронизацией или вклиниванием помех.

Адресное слово состоит из следующих частей:

• Первый бит — всегда нулевой
• 18 бит адреса — сюда пишется «кастрированный» CAP код
• 2 функциональных бита — задают источник (0, 1, 2, 3)
• 10 бит БЧХ кода — служит для обнаружения и исправления ошибок
• Последний бит — бит контроля четности

POCSAG имеет хитрый способ кодирования адреса, который заключается в том, что у указанного CAP кода длиной 21 бит отрезаются младшие 3 бита, и их значение интерпретируется как номер фрейма (от 0 до 7), который будет в данном сообщении первым. Оставшиеся 18 бит записываются в поле Address Bits у адресного слова, которое идет первым словом в выбранном фрейме. Сделано это было для экономии батареек пейджера: зная свои CAP коды, он после получения преамбулы опять засыпает и просыпается только для прослушивания конкретных фреймов, в которых могут быть его адреса, а не слушает все сообщение до конца.

Функциональные биты (Function или Source bits) адресного слова изначально служили для разграничения типов сообщений (0 — числовое, 1, 2 — тональное, 3 — алфавитно-числовое), но затем, с распространением алфавитно-числовых пейджеров, это поле «припахали» для дополнительной адресации, которая позволяла настраивать дополнительные варианты оповещения на одном и том же CAP коде. Например, можно было настроить на пейджере источник 0 в качестве важного (семья, работа) с громким оповещением, источник 1, 2, 3 — без оповещения (для всякого спама типа прогнозов погоды).

Кодовых слов сообщения может быть несколько, либо они могут отсутствовать вообще (например, у тональных сообщений есть только адресное). Отличается такое слово от адресного единицей в первом бите и 20 битным полем для символов сообщения вместо адресных и функциональных бит. Изначально POCSAG проектировался для передачи числовых сообщений, каждый символ которых кодируется 4 битами:

При таком раскладе в 20 битах кодового слова можно уместить ровно 5 символов. В случае, если сообщение длиннее, — кодовые слова сообщений продолжаются в следующем фрейме (подряд, без дублирования адресного), а если достигнут конец последнего фрейма — к сообщению добавляется новый пакет, и оставшиеся символы кодируются в его фреймах.

Но для передачи алфавитно-числовых сообщений 4 бит на символ явно недостаточно, поэтому алфавит расширили до 7 бит на символ. Это привело к тому, что на 20 бит стало приходиться нечетное число символов, поэтому они продляются в следующих кодовых словах фреймов и пакетов по аналогии с числовыми сообщениями, но информации текстом может передаваться несколько меньше. В зависимости от CAP кода (который влияет на номер стартового фрейма), в одном пакете сообщения POCSAG можно разместить от 2 до 42 символов текста. Сами спецификации протокола минимальный и максимальный размер сообщения в символах никак не ограничивают, но общепринятыми являются границы от 3х до 40 (или реже 80) символов, минимальная граница обуславливается невозможностью отличить алфавитно-числовое сообщение длиной 1-2 символа от просто числового, а максимальная чисто практическими соображениями. Реальные пейджеры могут принимать сообщения и по 512 символов, но с очень большой долей вероятности такие сообщения не будут получены полностью из-за помех.

Использование 7 бит на символ для алфавитно-числовых сообщений рождает еще одну проблему: теоретически 7 бит могут кодировать лишь 128 вариантов символов, если вычесть из них кучу служебных, всевозможные знаки препинания и скобочки, то окажется, что на символы алфавита места практически не остается. Латинский алфавит кодируется без проблем:

Кириллица, в целом, тоже, но придется пожертвовать некоторыми дополнительными символами:

Проблемы начинаются, когда пытаются «и съесть и сесть», объединив в одном алфавите и латиницу, и кириллицу. В таком случае жертвовать приходится не только дополнительными символами, но еще и регистром букв:

Ситуацию усложняет то, что некоторые производители пытались тянуть одеяло на себя, что порождало новые кодировки, несовместимые с предыдущими:

Как вы понимаете, жизнь пейджинговых операторов в СНГ была не сладкой: помимо зоопарка железок им приходилось поддерживать зоопарк различных кодировок, чтобы сообщения клиентам приходили в корректном виде.

Реализация энкодера

Энкодеров POCSAG существует множество, я решил увеличить это число на 1 и написал свой. Он состоит из файлов PocsagEncoder.h и PocsagEncoder.cpp и умеет следующее:

• Формировать сообщения всех трех типов (тональные, числовые и алфавитно-числовые)
• Поддерживает все 4 перечисленные выше варианта кодировок
• Сам конвертирует регистр латинских/кириллических символов в поддерживаемый текущей кодировкой
• Неподдерживаемые кодировкой символы заменяются на "?" или пробел (в числовых сообщениях)

Пример использования и сам скетч для заливки в Arduino — PocsagTranscoder.ino, его мы запустим и рассмотрим чуть позже. Он предназначен для Arduino Nano, но должен запуститься и на любых других совместимых контроллерах, лишь бы хватило памяти. Дефолтные настройки позволяют передавать сообщения длиной от 185 до 225 алфавитных символов.

Передающая часть

Передача POCSAG сообщений осуществляется с помощью FSK модуляции, поэтому нам понадобится специальный радиопередатчик, который эту модуляцию поддерживает. Для своих экспериментов я выбрал RF7021SE:

Это миниатюрный приемопередатчик на базе ADF7021, который поддерживает и нужную модуляцию, и возможность перестройки частоты в очень широких пределах (по умолчанию 400 — 500 МГц и 800 — 950 МГц) с максимальной мощностью излучения до 10 мВт:

Согласно даташиту на ADF7021, данный модуль можно заставить работать также на частотах 80 — 650 МГц путем добавления внешней индуктивности, которая подбирается эмпирическим путем по диаграмме (частоты ниже 200 МГц получаются делением на 2):

По ней можно предположить, что для наиболее популярных в СНГ частот пейджеров (150 — 170МГц) должна подойти катушка индуктивностью около 15 нГн. На модуле RF7021SE для нее любезно предусмотрено посадочное место типоразмера 0402:

Для работы с этим модулем я написал небольшой драйвер (Rf7021.h, Rf7021.cpp), который позволяет отправлять сообщения с FSK модуляцией на заданной частоте с заданной скоростью и девиацией. Вообще ADF7021 — это именно приемопередатчик, который позволяет также принимать сообщения, но работу с приемной частью я не реализовывал, т.к. она нас в данном случае не интересует.

У данного модуля имеется один небольшой недостаток: по умолчанию на нем установлен TCXO частотой 19.68 МГц, и для работы с пейджерами он не совсем подходит (сообщения будут приходить поврежденными или не будут доходить вовсе). Поэтому по-хорошему стоит заменить его либо на 12.288 МГц, либо на 14.7456 МГц. В наличии я нашел только первый, причем типоразмера только 5032 (родной TCXO — 3025):

Но с некоторыми ухищрениями его можно разместить на плате модуля. Первыми делом выпаиваем родной генератор:

Правые контакты нового генератора аккуратно запаиваем на площадки, при этом левые не достают до своих ответных площадок и остаются висеть на воздухе — это нормально. Из левых контактов нам требуется подключить лишь верхний (VCC), сделать это можно с помощью перемычки к ближайшему конденсатору:

Крупнее:

К выбору и установке генератора нужно подойти со всей ответственностью, ибо это одна из наиболее важных частей, из-за которой могут быть проблемы в дальнейшем.

Подготовка и подключение Arduino

ADF7021 работает от 3.3В, причем 5V-tolerance не заявлено ни для него, ни для модуля RF7021SE. Можно использовать конвертеры 5-3.3В, а можно просто понизить напряжение работы самой ардуины, сделать это достаточно легко:

Первым делом нам нужно выпаять диод, затем заменить AMS1117-5.0 на AMS1117-3.3 и кинуть пару перемычек. В зависимости от версии клона платы могут отличаться визуально, но общий принцип остается тем же. Некоторые советуют с понижением напряжения понизить и частоту Атмеги до 8 МГц, но как показывает практика, и на 16 МГц все работает стабильно.

Далее, убедившись, что Arduino работает, подключаем к ней модуль передатчика по схеме:

Выглядит страшно, но на деле получается компактная связка, которую при желании можно уместить в спичечном коробке:

Теперь можно залить скетч PocsagTranscoder.ino и проверить работоспособность передатчика, для этого нам понадобится как минимум рация, а лучше SDR приемник, пусть даже самый дешевый. Загружаем скетч в ардуину и открываем консоль, если все подключено верно — в нее должны быть выведены сведения о текущей ревизии чипа ADF7021, его текущая температура (весьма грубая) и напряжение питания:

Проверим работоспособность передатчика, для этого настраиваем рацию/SDR на частоту 433.92 МГц, аналогично поступаем с нашим передатчиком, введя в консоли f 433920000 и нажав Enter:

Теперь вводим в консоль x или X (английская раскладка), жмем Enter и слушаем рацию/смотрим на водопад SDR. Так запускается режим тестирования передатчика, при котором он в течение 10 секунд передает последовательность 10101010… на заданной частоте, девиации и скорости. Если все было сделано верно и ничего не упущено, то FSK сигнал не заставит себя ждать:

Если сигнала нет и консоль не реагирует — проверьте правильность и надежность подключения Arduino к передатчику, а также правильность установки генератора. Если консоль откликается — проверьте правильность задания частоты генератора в константе RF_TCXO, по умолчанию она указана для 12.288 МГц.

Тренируемся на кошках

Взаимодействие с ардуиной осуществляется через консоль с помощью ввода специальных команд, их полный список следующий:

Команды можно комбинировать в одну строку, например, команда:

e 3 f 434000000 c 23821 r 512 m Добро пожаловать в 2021!

Отправит сообщение «Добро пожаловать в 2021!» в кириллической кодировке Motorola Advisor на частоте 434 МГц со скоростью 512 бит/с на CAP код 23821:

На водопаде SDR отправляемые сообщения выглядят характерно (и не менее характерно звучат на слух), тон и длительность передачи сильно зависят от установленной скорости. Так выглядит сообщение «Привет» на скорости 512:

В принципе имеющаяся информация уже позволяет отправлять сообщения на пейджер, однако по различным причинам это удается не всегда. Чтобы отсеять сомнения в работоспособности самопального передатчика, можно воспользоваться программой PDW:

• Подключаем SDR приемник к смартфону, запускаем водопад и настраиваемся на нужную частоту
• Включаем WFM демодуляцию
• С помощью AUX кабеля подключаем смартфон к линейному входу компьютера
• Запускаем PDW и пытаемся слать сообщения на пейджер (любой CAP код, но кодировка строго e 0 — другие PDW не поддерживает)
• Регулировкой громкости смартфона добиваемся, чтобы индикатор сигнала в правом верхнем углу PDW стал зеленым

Если все сделано верно, и передатчик исправно работает, то в окне PDW начнут выходить получаемые сообщения. Можно поиграть как со скоростью, так и с типом сообщений:

Чаще всего в проблемах получения сообщений виноват сам пейджер, т.е. причина лежит где-то в его расстроенном приемнике. Возможность настройки частоты модуля передатчика в широких пределах позволяет частично нивелировать проблемы с приемником пейджера методом подбора частоты, на которой у пейджера наилучшая чувствительность. Для этого разносим пейджер и передатчик как можно дальше и начинаем последовательно отправлять сообщения, сдвигая каждый раз частоту на несколько КГц, с помощью небольшой модификации скетча этот процесс можно даже автоматизировать. Далее внимательно смотрим на пейджер, о неминуемо надвигающемся успехе обычно сигнализирует появление индикатора нахождения в зоне приема (или исчезновение индикатора его отсутствия — зависит от модели):

Прием сообщений на пейджер

По моим наблюдениям внешнее состояние пейджера очень хорошо коррелирует с его возможностями приема сообщений. Целые внешне и хранившиеся в домашних условиях пейджеры обычно принимают сообщения сразу без каких-либо проблем:

При наличии полученных сообщений на экране ожидания высвечиваются ярлыки в левом верхнем углу:

Последнее полученное сообщение можно открыть путем нажатия на зеленую кнопку:

По красной кнопке открывается меню доступных действий — здесь можно заблокировать сообщение, добавить в личные или удалить его:

Помимо звуковых и световых оповещений у пейджеров есть вибра, которая на порядки мощнее той, что стоит в современных смартфонах:

В комментарии к первой части скидывали видео древней рекламы пейджеров:

Понятно, что эпатажная Motorola в своем репертуаре, но вибра тут действительно мощь, в больших пейджерах типа Advisor она более низкочастотная и больше похожа на rumble в геймпадах.

Минутка осеннего обострения

Мы живем в мире, в котором сначала телефоны, а затем смартфоны вытеснили не только пейджеры, но и десятки других видов гаджетов. Никто не знает, каким был бы мир сейчас, не изобрети кучка инженеров SMS 1984 году. Предлагаю пофантазировать, каким мог бы быть современный мир, если бы человечество так и не додумалось добавить в телефон функцию обмена короткими сообщениями. Заранее предупреждаю, что представленные сообщения являются выдумкой и не имеют отношения к реальности, а все совпадения случайны и носят шуточный характер)

Первое, что приходит на ум — на наши пейджеры приходили бы уведомления из всевозможных социальных сетей:

Оповещения такси и каршерингов — почему бы и нет?

Банки, платежные системы, коды подтверждения — добро пожаловать. Единственная проблема в незащищенности передаваемых данных, но в наше время, я уверен, выкатили бы шифрованную версию POCSAG, позволяющую слать такое без опаски:

Сообщения служб доставок туда же:

Практически полная бесплатность отправки широковещательных сообщений — мечта всех отделов SMM и инфоцыган любой масти:

Легкость самостоятельной реализации доставки сообщений и сливы баз данных клиентов были бы очень на руку всевозможным спамерам:

А широковещательные локальные рассылки спама появились бы гораздо раньше:

Итог

На примере пейджеров очень четко прослеживается инфляция технологий. То, что 30 лет назад было верхом инженерной мысли, сегодня можно воспроизвести в домашних условиях на коленке с использованием недорогих компонентов. Пока не до конца ясно, повторят ли современные технологии судьбу пейджеров спустя еще 30 лет, но одно я знаю точно: изучать их в 2051 будет не менее интересно, чем пейджеры сегодня)