Можно было ли с пейджера на пейджер сообщение

Назад в 90-е или как отправить сообщение на пейджер через Java

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

пейджерА

пейджеры, которые должны были среди прочих принимать наши сигналы. Соответственно, нашей (меня и моих коллег) задачей являлась их отправка.

Уже прошли те времена, когда для отправки текста на пейджер надо было сначала пообщаться с сонной девушкой с телефонного узла. Теперь достаточно дозвониться до станции и набрать номер абонента и сообщение в тоновом режиме. Арсенал при этом сильно ограничен: можно отправлять только цифры, символы * и #, иногда буквы ABCD. Но для передачи, скажем, номера комнаты или кода ошибки должно хватить. Это довольно сильно упрощает задачу и роднит её с другими — с дозвоном в общую переговорную комнату, например.

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

Шаг 1 — INVITE

Первый этап — дозвон на пейджинговую станцию — был реализован через протокол SIP и с помощью соответствующей Java-библиотеки jain-sip. Самое лучшее описание принципов работы протокола я нашла на Хабре в публикациях «Взаимодействие клиентов SIP. Часть 1» и «Взаимодействие клиентов SIP. Часть 2», а самый удобоваримый туториал по джейн — вот здесь (но коллекция примеров отсюда отказалась получше).

В качестве предпоготовки я создала класс:

public class SipNotificator implements SipListener

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

private SipProvider sipProvider; private SipFactory sipFactory; private SdpFactory sdpFactory;//пригодится позже private AddressFactory addressFactory; private erFactory erFactory; private MessageFactory messageFactory;

Как предписывают нам правила, сначала необходимо отправить INVITE-сообщение на телефон. Обратите внимание на то, что адресат в To- и Request-хедерах записывается по-разному. В первом случае заголовок просто собирается из глобального телефонного номера:

Address toNameAddress = addressFactory.createAddress( addressFactory.createTelURL(adresseenumber)); Toer toer = erFactory.createToer(toNameAddress, null);

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

URI requestURI = addressFactory.createAddress(«sip:»+adresseenumber+»@»+host+»;user=phone»).getURI();

Другим интересным элементом является, собственно, тело SDP-сообщения, представляющее собой описание того, что понадобится для успешной коммуникации. В нашем случае оно выглядело примерно так:

String sdpData = «v=0rn» + «o=4444 123456 789054 IN IP4 «+InetAddress.getLocalHost().getHostAddress() +»rn» + «s=phone callrn» + «p=»+phoneusername+»rn» + «c=IN IP4 «+InetAddress.getLocalHost().getHostAddress() +»rn» + «t=0 0rn» + «m=audio «+localUdpPort+» RTP/AVP 0 8 18 101rn» + «a=rtpmap:0 PCMU/8000rn» + «a=rtpmap:8 PCMA/8000rn» + «a=rtpmap:18 G729A/8000rn» + «a=fmtp:18 annexb=norn» + «a=rtpmap:101 telephone-event/8000rn» + «a=fmtp:101 0-16rn» + «a=p:20rn» + «a=sendrecvrn»;

Атрибуты «o» и «s» не являются особо важными, в «p» пишем свой телефон. Основная часть — «m» (), в которой прописываются используемые кодеки (в нашем случае на отправителе они могут быть не установлены) и порт для принятия ответов по теме.

Шаг 2 — аутентификация

Если нам удалось отправить правильный инвайт, то в лучшем случае сервер-получатель пришлет нам желанное OK-сообщение со статусом 200, а в худшем — решит еще немного помучить идентификацией. Во втором случае ответый статус будет 401 или 407. Вот код, с помощью которого посылается ответ. Для его поддержки понадобится одна из последних версий jain-sip (например, 1.2.228). Его надо поместить в метод processResponse(), получающий в качестве аргумента ResponseEvent responseEvt.

if (us == 401|| us == 407){ AuthenticationHelper authenticationHelper = ((SipStackExt) sipProvider.getSipStack()).getAuthenticationHelper( new AccountManagerImpl(this.phoneusername, this.password), erFactory); transaction = authenticationHelper.handleChallenge(responceEvt.getResponse(), responceEvt.getClientTransaction(), sipProvider, 15, true); dialog = transaction.getDialog(); transaction.sendRequest(); }

Обратите внимание на четверый аргумент метода handleChallenge(), без него формат сообщения изменится, станет неподходящим и ваша аутентификация провалится.

Классы AccountManagerImpl и тоже неоходимый UserCredentialsImpl должны быть дописаны вами, я их писала по модели тех, что представлены здесь.

После отправки своих регистрационных данных мы можем смело ожидать искомый 200 OK, на который надо не забыть отправить ACK. Такой тип сообщения изготавливается крайне просто:

Request ackRequest = dialog.createAck( ((CSeqer) responseEvt.getResponse().geter(CSeqer.NAME)).getSeqNumber() ); //dialog — текущий диалог

Шаг 3 — SIP

Дальше начинается самое интересное — отправка DTMF-сигналов (те самые нажатия в тоновом режиме). Глобально это можно сделать через два разных протокола: через SIP и через RTP . Естественно, поначалу было решено пойти по пути наименьшего сопротивления. Для каждого символа формировался вот такой запрос, который потом нужно было отправить на сервер:

Request = dialog.createRequest(Request.); String sdpData = «al=»+digit+»rn» + «Duration=200»; byte[] contents = sdpData.getBytes(); ContentTypeer contentTypeer = erFactory.createContentTypeer(«application», «dtmf-relay»); .setContent(contents, contentTypeer); ClientTransaction transaction = sipProvider.getNewClientTransaction(); Dialog dialog = transaction.getDialog(); dialog.sendRequest(transaction);

Сама процедура отправки выглядит немного странно (кажется, построенной по модели «через Жмеринку в Париж»), но иначе у меня ничего не работало. Вообще библиотека мне показалась немного глючной: очень часто одно из нескольких решений, выглядевших по большому счету одинаково, не срабатывало.

Что я могу сказать? После реализации этого шага оказалось, что не все VoIP-сервера одинаково дружелюбны: некоторым достаточно было сигналов, передаваемых через SIP, а кому-то их не хватило, так как они не производят звукового сигнала и потому остаются незамеченными. Естественно, по закону подлости моей целью был сервер второго типа. Поэтому…

Шаг 4. формирование RTP-пакета

Вообще когда я осознала, что одним SIP-ом проблему не решить, я надеялась, что хотя бы смогу воспользоваться другой библиотекой, которая умеет ненапряжно отправлять DTMF-сигналы. Но не тут-то было. Обычно, если мы говорим «RTP через джаву», то подразумеваем JMF. Но, во-первых, она уже старенькая и не особо поддерживается. Во-вторых, она больше подходит для передачи более сложных медиа. В-третьих, туториалы, которые мне удалось найти, были не очень толковыми. Вот один из примеров из документации, в середине которого всплывает некая rtpSession, следов которой в первые сколько-то минут поиска мне найти вообще не удалось.

Другим вариантом была библиотека libjitsi, представляющая из себя целый коммуникатор. Из неё ничего позаимствовать тоже не удалось, хотя там есть милая метода sendDTMF или что-то в этом духе. Структура кода такова, что он берётся или целиком, или никак. В итоге было решено по-нормальному сделать человеческий пакет и отправить его через UDP-соккет.

Итак, вот значимый фрагмент класса RtpPacket: его основные поля и конструктор со значениями, подходящими для передачи DTMF. Что значат все эти вещи, написано много где, поэтому повторяться не буду. Отмечу только, что значение параметра ssrc в принципе роли не играет, но у всех отправляемых в одной сессии пакетов оно должно совпадать. Номер формата полезной нагрузки у DTMF-пакетов (payload type) — 101 (его мы прописали, когда инициировали SIP-коммуникацию).

private int version; private boolean padding; private boolean extension; private int csrcCount; private boolean marker; private int payloadType; private int sequenceNumber; private long stamp; private long ssrc; private long[] csrcList; private byte[] data; public RtpPacket(){ this.setVersion(2); this.setPadding(false); this.setExtension(false); this.setCsrcCount(0); long[] list = {}; this.setCsrcList(list); }

Самый важный этап создания пакета — заполнение байтового массива данных. У DTMF, естественно свой формат: первый байт — это, собственно, значение передаваемого сигнала (от 0 до 16), первая половина второго байта — различные маркеты (обычно 0), вторая половина второго байта- громкость (стандартное значение — 10), остальные два — это длительность (стандартное значение — 160).

Для каждого сигнала создается около 10 пакетов (число может варьироваться):

— первый, начальный, имеет marker = 1, остальные — 0;

— последние три — конечные, marker = 0, зато первый бит второго байта блока данных = 1. Блок данных в неконечном пакете для передачи сигнала 1 будет выглядеть так:

0000 0001 0000 1010 0000 0000 1010 0000 значение громкость длительность

А в конечном вот так:

0000 0001 1000 1010 0000 0000 1010 0000 значение end громкость длительность

Метка времени у всех DTMF-пакетов, относящихся к одному сигналу, может оставаться одинаковой (предположим, T). Зато время следующего пакета должно быть:

T+(количество DTMF-пакетов * длительность пакета)

Шаг 5. RTP-канал

Можно было создать только один соккет для отправления и принятия сообщений. Но — в любом случае — никакой отправки, естественно, не случится, если не знать хоста и порта назначения. Это уже совсем не те данные, через которые проходила SIP-коммуникация. Свои координаты телефонный сервер присылает нам в ответных SIP сообщениях во время нашего дозвона. Их можно получить, вставив в метод processResponce() вот такой код (тут можно увидеть, зачем мы ранее инициализаровали sdpFactory):

Response resp = responceEvent.getResponse(); int remoteHost; int remotePort; if (resp.getRawContent()!=null){ String sdpContent = new String(resp.getRawContent()); SessionDescription requestSDP = sdpFactory.createSessionDescription(sdpContent); remoteHost = requestSDP.getConnection().getAddress();//хост запрятан в Connection rmation Vector<Description> = requestSDP.getDescriptions(false); for (Description m:){ if (m.get()!=null ) remotePort =m.get().getPort();//порт можно найти среди данных } }

Дальше, как я наивно полагала, мне оставалось только понаделать из моих байтов DatagramPacket’ов, засунуть их в сокет и запулить в сервер. Но не тут-то было. В ответ сервер продолжал обрывать коммуникацию на полуслове, как будто ничего и не получал. А Wireshark в принципе не принимал мои сообщения за RTP, отображая из как простые UDP.

Шаг 6. RTP-коммуникация

На то, чтобы понять, в каком направлении двигаться дальше, ушло много времени. Я вложила много усилий в то, чтобы перечитать все имеющиеся в наличии спецификации и сто раз проверить свои пакеты на правильность. На седьмой же день Зоркий Глаз в моем лице заметил, что стандартная RTP-коммуникация не начинается сразу же с отправки DTMF-данных, а что ей предшествует непродолжительный обмен пакетами с сервером, которые выглядят несколько иначе.

Формат полезной нагрузки, объявленный в заголовке, равен 0, данных нет, зато есть собственно сама полезная нагрузка (payload), которая занимает 160 байт. Этот набор байтов различается во всех приходящих и уходящих сообщениях и выглядит составленным довольно случайно. Так или иначе, я не смогла найти информации о том, как именно он должен формироваться, поэтому каждый раз забивала его рандомами.

После того, как я стала отправлять эти вспомогательные пакеты перед каждым DTMF-сигналом, Wireshark наконец-то признал RTP-формат. Всё выглядело лучше, но коммуникация по-прежнему прерывалась, хотя сервер теперь от радости тоже стал меня забрасывать «пейлодными» пакетами.

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

чакры

порта:

DatagramSocket socket = new DatagramSocket(localUdpPort, InetAddress.getLocalHost()); DatagramSocket controlSocket = new DatagramSocket(localUdpPort+1, InetAddress.getLocalHost());//порт должен быть на 1 больше, чем у RTP

Это оказало решающее воздействие: абонент получил моё сообщение «305*1*66» на пейджер!

Заключение

В последних строках моей телеги хотелось бы подчеркнуть, что это мой первый пост на Хабре, так что не судите меня строго. Я совершенно не считаю себя гуру телематики или чего-либо ещё. Просто при написании исходного кода очень много времени ушло на поиск информации. Что-то я находила в спецификациях, которые от начала до конца в один присест осилить было сложновато, что-то было описано нормальным языком, но как-то неярко мелким шрифтом на полях, что-то я делала наугад. Так что в какой-то момент просто решила, что если у меня всё получится, я опишу все свои действия в одном месте и оставлю это индексироваться где-нибудь в интернете.

Так что очень надеюсь, что хоть кому-то моя статья пригодится или хотя бы покажется интересной.

Источник

Использование пейджера в XXI веке

Пейджеры были очень популярны в 90-е годы. В то время я был студентом, и пейджер для меня был чем-то вроде коммуникатора из Star Trek, частью передовых технологий. Забавно вспоминать об этом, потому что теперь я знаю, что технологически протокол пейджинга очень прост. С точки зрения кодирования, пейджер не так уж отличается от беспроводных дверных звонков, которые сейчас продаются за 5 долларов на Aliexpress.

Несмотря на то, что повсеместно пейджеры уже не используются, они всё ещё есть в доме у некоторых людей. Можно ли протестировать пейджер сейчас? Безусловно, и я покажу вам, как это сделать. Давайте начнём.

POCSAG — протокол обмена сообщениями

Допустим, мы хотим отправить сообщение «TEST» на номер «1234». В двоичной форме оно будет выглядеть примерно так:

1010101010101010101010101010101010 — Преамбула. 01111100110100100001010101011000 — Код синхронизации кадров. 0111101010100010011100000110111 — Кодовое слово простоя. 00000000000100110101111000111111 — Адрес + Функциональные биты + CRC. 10010101101000111001001111111100 — T E S (7 бит/символ). 11001010100000000000001111100011 — T . . 0111101010100010011100000110010111 — Кодовое слово простоя.

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

Биты кодируются с помощью модуляции с частотной манипуляцией (FSK), с использованием полосы пропускания 9 кГц и скорости 1200 бит в секунду, все это сообщение передается примерно за 0,5 с.

Выглядит просто, и это действительно так. Я пропущу подробности; те, кому интересно, могут прочитать спецификацию протокола. Все эти биты можно легко написать даже на бумаге — в прошлом эти протоколы были простыми, чего не скажешь о современных GSM или Wi-Fi.

В сообщениях POCSAG нет ни аутентификации, ни ключей безопасности — все сообщения для всех клиентов пейджинговой компании доступны в эфире «как есть» и, кстати, могут быть легко декодированы с помощью программного обеспечения для ПК, такого как PDW.

Как клиенты получают свои сообщения? Каждый пейджер имеет уникальный идентификатор, который называется CAP — протокол доступа к каналу, или RIC — код идентификации приёмника. Все пейджеры от пейджинг-провайдера слушают одну и ту же частоту, скажем, 164 МГц. Если код в сообщении равен коду пейджера, пейджер сохраняет сообщение и издаёт громкий звуковой сигнал. Вот и всё. Связь односторонняя, нет обратной отправки подтверждения, у пейджера есть только приёмник, а передатчика нет вообще. Логика и аппаратное обеспечение предельно просты, благодаря чему пейджер может работать более месяца от одной батарейки AAA. Интересно, что пейджеры всё ещё используются в некоторых странах даже сейчас — в больницах или службах неотложной помощи, где важно иметь портативное и лёгкое устройство с длительным временем автономной работы.

Покупка пейджера

Во многих странах по-прежнему доступны пейджинг-провайдеры, с которыми можно подписать контракт и получить новое устройство, но, скажем так, это не слишком увлекательный способ. Я говорю с точки зрения человека, который хочет протестировать пейджер из-за образовательного или ностальгического желания или, может быть, даже имеет дома старый пейджер, сделанный в 1990-х годах. У меня есть хорошая новость — с большой вероятностью он может быть протестирован ещё раз и действительно будет работать. Конечно, не в масштабах всего города, но можно запустить собственную маломощную пейджинговую сеть, по крайней мере в вашей квартире. Сейчас можно купить новый пейджер, но он стоит недёшево. Это первая ссылка, которую я нашёл в Google:

Как мы видим, купить его просто для удовольствия может быть слишком дорого, и, более того, перед использованием пейджер должен быть настроен, а инструмент программирования и ПО для него также могут стоить очень дорого. Другой вариант — купить китайский пейджер, он дешевле, с кабелем для программирования общая стоимость составляет около $ 80:

И, наконец, на eBay можно купить подержанный пейджер за 20-50 долларов. Он дешёвый, и это старая винтажная модель, что тоже весело. Но, прежде чем совершать покупку, следует иметь в виду две вещи, которые были описаны ранее в разделе POCSAG:

• Чтобы отправить сообщение на пейджер, нужно знать его частоту. У старых пейджеров она написана на обратной стороне. Если вы не знаете частоту и не можете её узнать, пейджер бесполезен.

• Чтобы отправить сообщение на пейджер, вам необходимо знать его кэп-код. Это 7-значное число, оно выглядит так: 0001234. Если вы его не знаете, вам понадобится кабель для программирования, чтобы прочитать конфигурацию пейджера.

Рассмотрим практический пример. Я видел этот пейджер Motorola Advisor Gold на eBay (имя продавца скрыто из соображений конфиденциальности):

Цена не такая большая, но стоимость доставки в ЕС составляет почти половину его цены. Ладно, давайте посмотрим на следующее фото:

Мы можем видеть частоту (462,875 МГц) и скорость передачи, но наклейка с кодом доступа была удалена владельцем, возможно, из соображений конфиденциальности, и это не очень хорошо для нас. Можно прочитать кэп-код, но для этого нам нужно купить или изготовить специальный кабель для программирования, а также найти подходящее ПО. Всё это нужно проверять перед покупкой, иначе у нас есть шанс получить «кирпич», который выглядит как пейджер, но не работает. И последняя, необязательная, но важная проверка — мы должны проверить, доступна ли желаемая частота в нашем регионе. Это можно сделать с помощью дешёвого приёмника RTL-SDR и программного обеспечения, такого как HDSDR. Если есть другой сигнал на той же частоте, пейджер также не будет работать. В моём районе частота 462,875 МГц, указанная на обратной стороне пейджера, уже занята, так что в моём случае лучше было найти на рынке другую модель.

Отправка сообщений

Чтобы отправить какие-либо данные на пейджер, мы должны передать сообщение POCSAG, используя соответствующую радиочастоту.

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

Эта статья описывает только техническую возможность, но не юридическую ее сторону, в разных странах правила могут отличаться. Например, в США в соответствии с частью 15 правил FCC, устройства с очень малой мощностью не требуют лицензирования, если излучаемая энергия не превышает 200 мкВ/м на расстоянии 3 метра. Это может обеспечить дальность действия до 30 метров, чего абсолютно достаточно для любых исследовательских или образовательных экспериментов. В других странах правила могут быть иными. Есть 3 простых способа передачи сообщений POCSAG.

Rpitx

Самый простой способ — использовать Raspberry Pi, и, что удивительно, это совершенно бесплатно: с помощью бесплатного opensource ПО rpitx сигнал может быть сгенерирован непосредственно с пина Raspberry Pi. Достаточно надеть на пин GPIO4 короткий провод:

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

echo -e «1000001:MESSAGE TEST» | sudo ./pocsag -f «465198000» -b 0

Здесь 1000001 — это кэп-код, 465198000 — частота, а 0 — тип сообщения (сообщение может быть одного из 4 типов, например, 0 — только числовое, 3 — буквенно-цифровое). Другие параметры, такие как инверсия сигнала или скорость передачи, также могут быть изменены при необходимости. Выходная мощность однозначно невысокая, но её достаточно для проверки пейджера в квартире. Приложение rpitx работает на удивление хорошо для своей (нулевой) цены, но, конечно, Raspberry Pi в целом не является точным радиочастотным генератором. Частота может быть не на 100 % правильной, и может потребоваться небольшая корректировка значения в диапазоне нескольких килогерц (также хорошо иметь RTL-SDR в качестве контрольного приёмника).

Плата MMDVM

Следующий способ — купить специальную плату MMDVM (Multi-Mode Digital Voice Modem), которую можно прикрепить к Raspberry Pi:

Эта плата содержит передатчик ADF7021 с возможным диапазоном частот 80-940 МГц и небольшую антенну. Несмотря на название, плата MMDVM может передавать не только голос, но и сообщения POCSAG. Чтобы использовать плату, нам необходимо установить приложение MMDVMHost и настроить файл MMDVM.ini (установить желаемую частоту и включить модули «POCSAG» и «Remote Control»). После этого мы можем запустить приложение MMDVMHost (его можно разместить в /etc/rc.local для автозапуска или запустить как службу при необходимости). В другом окне терминала мы можем использовать эту команду для отправки сообщения:

./RemoteCommand 7642 page 1000001 «MESSAGE TEST»

Здесь 7642 — это порт дистанционного управления, 1000001 — код доступа. Использование MMDVMHost немного сложнее и требует некоторых знаний Linux, но выходной сигнал лучше по сравнению с использованием пина Raspberry Pi в качестве вывода.

GNU Radio

Людям, у которых нет Raspberry Pi, но есть LimeSDR, HackRF, USRP или любой другой приёмопередатчик SDR, можно отправлять сообщения POCSAG с помощью GNU Radio.

Существует несколько кодировщиков POCSAG, я нашёл модуль gr-pocsag от ON1ARF самым простым в использовании: он даже не требует установки и может работать из любой папки.

Описание блоков GNU Radio выходит далеко за рамки этой статьи, желающие могут самостоятельно проверить страницу gr-pocsag. Все описанные решения маломощные. Те, кто хочет большей дальности, могут использовать специальный радиопередатчик, такой как Motorola GM-350, который может обеспечить дальность действия в несколько километров, но для этого типа передачи, очевидно, потребуется действующая лицензия.

Настройка пейджера

Если вы знаете частоту пейджера и кэп-код, то можете пропустить эту часть. С другой стороны, программирование пейджера может дать вам возможность почувствовать «вкус» того времени, и в целом более гибко изменять настройки пейджера.Увы, общей нормы настройки пейджера нет. Для некоторых моделей пейджеров, таких как Oelmann , станция программирования и ПО могут стоить больше, чем сам пейджер:

Другие модели, такие как Alphapoc, можно настроить вручную, даже без программного обеспечения, или с помощью относительно дешевого инструмента программирования через USB. Старые, выпущенные в 1990-х годах пейджеры Motorola Advisor, имеют 3 контакта последовательного порта (можно использовать USB-Serial):

Программное обеспечение для этих пейджеров требует среды MS-DOS, но может запускаться с помощью DOSBox. У более новых (около 1997 г. выпуска) пейджеров Motorola Advisor Gold есть двухконтактный интерфейс. Я нашел эту схему подключения в Интернете, но сам не проверял:

Пейджеры Motorola требуют старого программного обеспечения, написанного для MS-DOS, его можно найти в Интернете. Увы, многие страницы и ссылки, созданные 20 лет назад, сейчас недоступны — когда речь идёт о вещах, созданных 20 лет назад, возникает хорошо известная проблема «вымирания ссылок». Другая проблема, которая может возникнуть, — многие операторы пейджинга использовали пароль для предотвращения изменения конфигурации пейджера. Возможно, это было сделано из соображений безопасности: после изменения кэп-кода владелец пейджера может читать сообщения, предназначенные для другого клиента. Если конфигурация пейджера защищена паролем, при чтении настроек появится запрос:

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

Заключение

Было весело протестировать пейджинг и исследовать, как он работает.

Также интересно отметить, что винтажные устройства интересно тестировать, и они на первый взгляд выглядят дешевле. Но на самом деле это не так. Для разных тестов я купил 3 пейджера по $ 20-30 каждый. Но первый пейджер имел несовместимую частоту, второй был защищён паролем, и я не могу изменить его настройки, и только третий работает. Вместо этих трех б/у пейджеров можно было купить один новый.

Также очевидно, что нет никакой гарантии, когда вы покупаете вещи 20-летней давности — даже если продавец пишет «проверено» в описании, максимум, что он сделал, — это поставил батарею и проверил логотип на экране. Я не ожидаю, что продавцы знают о частотах или кодах доступа. Но в моём случае это было сделано для развлечения и самообразования, так что проблем с этим нет, даже если что-то не работает.

Ещё одна проблема, с которой я столкнулся при тестировании пейджеров, — это «вымирание ссылок». Раньше все думали, что «Google знает всё» и «информация в Интернете бесплатна», но на самом деле это не так. Хранение файлов и размещение сайтов стоят денег, через некоторое время веб-страницы становятся недоступными. Многие старые сообщения на форуме имеют мёртвые ссылки и содержат пустые квадраты вместо изображений. При попытке найти информацию о старых вещах всё это стало очевидным. Мне удалось найти полезное программное обеспечение на некоторых старых и заброшенных веб-страницах, но нет гарантии, что эти ссылки будут живы в течение длительного времени.

Могут быть и юридические причины, например, я не уверен, что Motorola официально разрешила кому-то публиковать программное обеспечение для программирования своих пейджеров, даже если публикация сделана 25 лет назад. Но для сохранения технического наследия может быть важно сохранить такие вещи. Наконец, пейджеры можно протестировать, и это весело.

Для тех, кто хочет провести больше тестов в более крупном масштабе, также можно использовать POCSAG на любительских радиочастотах и присоединиться к

сети

любительского радио

DAPNET

(децентрализованная любительская пейджинговая сеть). Для этого потребуется лицензия любительского радио, но для тех, кто интересуется цифровой связью, она может оказаться достойной её получения. Желаю всем читателям удачи и интересных экспериментов!

Несмотря на возраст этого вида связи, пейджерам до сих пор находится применение. Но если для технологии, 20 лет — это уже солидный возраст, то для языков программирования это еще даже не юность. Например С++, созданный Бьёрном Страуструпом аж в 1983 — до сих пор в топе самых популярных языков в мире благодаря своей чистой и красивой логике и гибкости. Если вы хотите разнообразить свой набор скилов этим языком — обратите внимание на наш курс по разработке на С++, ведь этот язык для миллионов программистов был и остаётся не менее важным, чем английский.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Другие профессии и курсы

Источник