Мы все (по крайней мере, большинство) уже давно живем в XXI веке. В нашу повседневную жизнь органично вошел Интернет, мы пользуемся поисковыми сервисами, моментальным обменом сообщениями, социальными сетями, веб-сайтами и порталами, облачными хранилищами… Вот уже почти тридцать лет для переписки используем электронную почту. И, в то же время, для подтверждения состоявшихся QSO/SWL используем «бумажки». Бумажки эти надо напечатать, заполнить, отвезти и сдать для рассылки, несколько раз пересортировать «по дороге», положить «в ячейку», наконец – дождаться, когда адресат их заберет. Если он готов проделать всё перечисленное – напечатать, заполнить, отправить… наверное, есть надежда получить ответную QSL-карточку. А если нет – то нет. Отправленная «бумажка» пропадёт втуне, и все затраты окажутся бессмысленными. Не пора ли уже «жить в ногу с веком»?

1. Проблемы и предпосылки

По моим собственным наблюдениям, значительная часть радиолюбителей (и у нас в стране, и за её рубежами, поблизости и на значительном отдалении) совсем не против обмена подтверждениями радиосвязей и наблюдений (QSL) в электронном виде. Вот, к примеру – есть сервис eQSL.cc. На нем зарегистрировано более 322 тысяч позывных. Есть сервис Logbook of The World (LoTW) – зарегистрировано более 186 тысяч позывных. Подтверждения в электронном виде практикуют и самый популярный в мире радиолюбителей портал qrz.com, и hrdlog.net, clublog.org, и много других. Какие-то ресурсы имеют опубликованный интерфейс для программных обращений (ApplicationProgramInterface– API), какие-то – ещё только мечтают об этом. Но все так или иначе движутся в одном направлении – к максимально широкому распространению электронных подтверждений.

Но есть проблемы. В первую очередь то, что отправленные мной на сервер подтверждения никак не влияют на то, что мой корреспондент предпримет какие-либо ответные шаги. Он может годами не обращать внимания на свой аккаунт на eQSL.cc или LoTW – и, разумеется, не отправлять встречные подтверждения. Или даже так: зарегистрируется человек на eQSL.cc, и потом никода, ни единого раза не предпримет даже единственной попытки отправить туда свои данные QSO/SWL. Для справки: в моем справочнике 8844 позывных, с которыми у меня были QSO/SWL. Из них 4952 – зарегистрированы на eQSL.cc. Из этих зарегистрированных 370 никогда не пользовались своим аккаунтом, ничего не отправляли на сервер и не принимали от него. Почти 7,5%, однако!

Проблема получения встречных подтверждений особенно остра для наблюдателей. Поскольку они, в большинстве случаев, не могут «напомнить» лицензированным радиолюбителям даже о своём существовании, запросы с их стороны на подтверждение наблюдений просто игнорируются. В своей радиолюбительской практике я выступаю и как «человек с передатчиком», и как наблюдатель. За многие годы работы в эфире я заметил, что подтверждаемость наблюдений (SWL) в несколько раз ниже, чем для двусторонних связей (QSO). Чтобы не быть голословным: за 2019 год всего QSO – 619, подтверждено 81% (447 через eQSL.cc, 370 через LoTW, и аж 18 – «бумажками» через бюро); всего SWL – 802, подтверждено 17% (156 через eQSL.cc).

Ещё одна проблема в том, что сервис LoTW вообще не предназначается для обслуживания наблюдателей. На нём им ни зарегистрироваться, ни обмениваться данными – не удастся.

Многие радиолюбители пытаются создавать собственные «карточки», предназначенные для рассылки по электронной почте. В чем-то им могут помогать и существующие программы управления аппаратными журналами (мне известны такие возможности у Log4OM, HamLabel в составе HamOffice), реализующие функции создания изображений «карточек с надписями», использующие данные QSO/SWL.

Существуют «отдельно стоящие» программы (QSL-card, QSLmake, программа от PA4R и т.п.), чаще всего – либо устаревшие, либо недоступные. Работают они не с журналами связей, а с выгрузками ADIF-формата. Соответственно, даже отметить успешность/неуспешность почтовой отправки они не могут. Есть и такие радиолюбители, которые «врукопашную» создают изображения карточек, используя графическую основу ранее разрабатывавшихся макетов для печати, и программы типа AdobePhotoshop, CorelDraw, MicrosoftVisio (в отдельных случаях – даже Microsoft Paint), накладывая с их помощью тексты полей – данных QSO/SWL. Времени на такие действия требуется много, до десяти минут. Размер получающихся изображений – под несколько мегабайт. Создается лишняя нагрузка и наоператора, и на почтовую систему, да и места под такие «карточки» на диске может потребоваться очень много.

К сожалению, данные QSO/SWL оказываются «зашиты» в изображение, и автоматизировать их извлечение оттуда не представляется возможным. А другой, более формализованной информации в полученных от корреспондентов письмах – просто нет.

2. Данные подтверждаемого QSO/SWL

Для того, чтобы письмо стало корректной «сопроводиловкой» для изображения mQSL-карточки, а по сути – самой этой mQSL, оно должно содержать в формализованном, машиночитаемом виде данные QSO/SWL, включающие:

собственный позывной – CALL;
позывной корреспондента – QSL;
дату QSO/SWL (желательно – и его время, в зоне UTC) – DATE, TIME;
диапазон – BAND;
модуляцию – MODE;
отправленный [и принятый] рапорты (по возможности) – RST;
текстовое сообщение для корреспондента (по желанию).
Для структурирования этих данных удобно применить ADIF-подобный формат, примерно такого вида:

<QSL:5>R2ADF<CALL:6>4U1ITU<DATE:6>140718<TIME:4>1830<BAND:3>20M<MODE:3>SSB<RST:2>59<END>
Нет необходимости применять в точности повторяющий ADIF формат строки-подтверждения, поскольку удобнее придерживаться принципа «одно QSO/SWL – одно письмо», при этом обязательный ADIF-заголовок можно в письмо не включать, зато можно немного сократить имена полей, и добавить поля, отсутствующие в стандарте ADIF. Текстовое сообщение в формализованную строку лучше не включать.

3. Отправка mQSL

Для отправки mQSL лучше всего использовать отдельный аккаунт, полностью отдав его «роботу» - как для отправки, так и для получения писем. Это позволит не забивать основной почтовый ящик фактически служебными сообщениями, число которых со временем будет только расти.

Заголовок отправляемого сообщения должен в краткой, но жестко формализованной манере включать те же данные QSO/SWL, например:

QSL from R2ADF (4U1ITU 18.07.2014 18:30 20M SSB)
На принимающей стороне извлечь нужные данные можно, используя только заголовок письма. Наличие же в теле письма формализованной ADIF-подобной строки данных ещё более облегчает обработку и интерпретацию такого письма.

В отправляемое сообщение можно «вложить» и изображение mQSL-карточки, сгенерированное специально для данного случая. Следует применять именно «вложение» изображения в текст письма, а не «прицеп» файл-аттача – это лишний раз позволяет повысить доверие ко входящим сообщениям, да и эстетически выглядит гораздо лучше. Из извлекаемых изображений mQSL впоследствии можно будет автоматически формировать большие коллекции, как это уже сделано, например, в отношении изображений карточек, получаемых через сервер eQSL.cc.

4. Приём mQSL

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

Вашему корреспонденту для подтверждения QSO/SWL по электронной почте будет достаточно послать ответ на него (Reply). Даже если не предпринимать никаких дополнительных действий, в ответе уже будет содержаться вся необходимая информация. Для экономии трафика и места на диске желательно, впрочем, до отправки удалить из ответа всё, кроме ADIF-подобной строки подтверждения.

Во время обработки полученных ответов «робот», найдя необходимую формализованную и структурированную информацию, отметит QSO/SWL как подтверждённое через E-Mail, а также установит в справочнике позывных отметку, что данный корреспондент имеет все возможности для подтверждений через электронную почту. Тем самым будет верифицирован и его почтовый адрес, и возможность его регулярного использования (не заблокирован, не удален, и т.п.)

5. Технические условия

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


За основу mQSL принимается стандартная QSL-карточка (ширина 140 мм, высота 90 мм). Качество изображения зависит от разрешения, или количества точек на единицу линейного размера (dpi – точек на дюйм). Минимально допустимое разрешение – 72 dpi:


Экспериментально установлено, что при 72 dpi размер изображения составляет 42 килобайта, но качество его оставляет желать лучшего. Приемлемое качество изображения получается при разрешении 150 dpi, размер составляет 99 килобайт. Ещё выше будет качество изображения при 300 dpi – но размер его при этом вырастает до 170 килобайт. Все примеры даны для цветности RGB 8 бит/канал (24 бит/пиксель).

Накладываемые на изображение «подложки» тексты имеют фиксированные размеры и положение. Схема макета приведена ниже:


Размеры зон размещения накладываемых текстов и QR-кодов приведены в пикселях, для разрешения 150 dpi.

Для практических целей удобнее всего использовать изображения «подложки» в формате jpeg (*.jpeg, *.jpe, *.jpg), так как в этом случае объем данных, пересылаемых в письме электронной почты, является минимальным из возможных. Излишне повторять, что каждый может сделать собственный вариант (варианты) «подложки», руководствуясь названными техническими условиями. Ну, и еще есть как минимум 25 стандартных «подложек», входящих в комплект.


Подтверждение подлинности в случае mQSL заключается в сверке:
(а) данных, присланных в теле письма (как подтверждающая ADIF-подобная строка);
(б) данных, внесенных в изображение mQSL-карточки (в нижней части, на полупрозрачных полях). К этому можно добавить и
(в) машиночитаемый QR-код, содержащий все данные QSO/SWL, в виде выписки из аппаратного журнала отправителя, в стандартном формате ADIF. Этот QR-код может быть считан как с помощью любого внешнего устройства (смартфона, планшета), и интерпретирован соответствующим образом.

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

6. Опытная эксплуатация

Реализованный в системе CheckLog плагин позволяет как отправлять, так и получать mQSL, включающие изображения карточек. Опытная эксплуатация велась в марте 2023 года, всего на момент начала было известно (по справочнику позывных, с которыми были проведены QSO/SWL) 2414 уникальных адресов; всего было послано 3847 писем. Был получен 251 ответ от 200 корреспондентов (подтверждаемость 6,5%). Много это или мало? Сравним с данными традиционного (бумажного) QSL-обмена.

В 2014 году было разослано 1535 QSL-карточек, в ответ на которые пришло 634, подтверждаемость составила 41%, но сколько времени и средств было затрачено! Кроме того, отправка бумажных QSL более всего похожа на лотерею, созданную для сбора денег – но не для выигрышей. Много ли корреспондентов, заявивших в справочниках, что пользуются услугами QSL-бюро, шлют свои карточки в ответ? Уверяю – далеко не все.

А в случае mQSL за очень короткое время, с минимальными затратами можно послать запрос и получить ответ на него. По результатам работы в эфире за три месяца 2023 года отправлено 718 писем, получено 58 подтверждений (подтверждаемость 8%). С наблюдательской работой ещё интереснее: за тот же период отправлено 69 писем, получено 13 подтверждений (18,8%). Для сравнения: тогда же отправлено 196 eQSL, получено 30 подтверждений (15,3%). Получается, что в наблюдательской работе mQSL даже более эффективно, чем eQSL. А ведь именно eQSL занимает первое место по эффективности сбора подтверждений «в общем случае».

7. Выводы

А вот выводы делайте сами. Создан инструмент, позволяющий дополнить (и, в ряде случаев – весьма эффективно и недорого) арсенал средств «охотника за DX-ами». Хотите – пользуйтесь, хотите – нет. Во всяком случае, опытная эксплуатация ещё продолжается, и те из вас, что примут в ней активное участие и на своих данных проверят удобство и полезность предлагаемых решений, могут рассчитывать на понимание и поддержку со стороны автора CheckLog.

Автор: Дмитрий Речкин (R2ADF)