О цифровой моде JS8Call по-русски и подробно.

Самые популярные товары с Али по лучшей цене здесь

Беспроводная геймерская 2000 dpi мышь 248 руб.
Качественная «Банка Силы» на 20 Ач. 1100 руб.
UV LED фонарь, питание 1 АА, длина волны 395 nm 204 руб.

15 августа 2020, 14:00

О цифровой моде JS8Call по-русски и подробно.

О цифровой моде JS8Call по-русски и подробно.

Что-то завыло,
Аж страшно выйти за дверь.
Катану ищу...

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

Можно поколениями гордиться автоматом имени Калашникова, выставляя его чуть ли не венцом технологий. Да бога ради. Но нет греха и в познании более полезных для жизни штуковин, каковые, тем не менее, всё-таки сопряжены с мыслями о калаше, ибо здесь вам не тут.®

Не возбраняется хотеть странного. Так что изучим возможность организации направленной КВ связи на базе QRP цифрового модема 80 м диапазона (или чего-то ему аналогичного), с выходом на концепцию mesh-сети ячеистой топологии. Это самое лакомое.

О пользе mesh сетей.

При необходимости организации связи на условные 100 км (а по факту ближе к 200-300) есть возможность сделать это на базе весьма простой самодельной конструкции, при стоимости комплектующих в пределах $10. Ничего там хитрого нет, любитель вполне справляется, с толком и весело проводя свободное время.

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

В этом месте мы понимаем, что железный кирпич многогранен, и относится к продукции двойного назначения. Через него можно морзянку гонять в две стороны, как во времена Штирлица, либо современную «цифру», причём десятками разных видов. Или даже развернуть сеть на базе какого-то из продвинутых цифровых режимов.

Для чего нам такая сеть?

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

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

Ну а как если нету лишних людей, причём категорически?
Тогда только придерживаться сеансов связи, по времени.
Однако, тут страдает оперативность.

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

В простейшем случае в сети могут быть всего две станции. Но мы понимаем, что лучше бы сети быть изначально масштабируемой, дабы не пришлось потом решать проблемы роста, что традиционно делается вкривь и вкось.

История развития софта для КВ mesh сетей.

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

В итоге должного распространения такие решения не получили.
По поводу чего не возникает никакого удивления.

Заметным шагом вперёд стала разработка протокола JS8Call. По дизайну всё очень смахивает на FT8, да и транспорт почти тот же самый. Но софт очень продуман, и прекрасно решает все стоящие перед нами задачи. Ещё и весьма специфичные.

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

Модель mesh сети на протоколе JS8Call.

На русском языке информации о программе крайне мало, так что с этого момента начинается эксклюзивный контент.

Гуглим JS8Call, находим её оффсайт, качаем себе виндовую версию. На момент написания обзора программа была доступна в версиях до 2.2.0, запускаясь на любой винде, от XP до 10. Что достойно подражания.

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

"C:\Program Files\js8call\bin\js8call.exe" --rig-name=1

Все ярлыки отличаются лишь цифрой в значении ключа rig-name.
Пусть таких ярлыков будет три, с циферками 1, 2, 3.
Тогда в фолдере

C:/Documents and Settings/User/Local Settings/Application Data/

создадутся три папки с именами JS8Call - 1, JS8Call - 2, JS8Call - 3.
Там-то и будут храниться настройки и информация для каждого экземпляра.

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

Давайте присвоим трём клонам позывные и QTH локатор по такой системе:

Позывной: Локатор: Город:
UA9XXX LP51 Сыктывкар
UA9YYY NO13 Барнаул
UA9ZZZ NO40 Кош-Агач

«Большой» квадрат локатора из 4 символов (1° по широте и 2° по долготе, очень грубо 80*100 км) используется программой для расчёта дальности до корреспондента. В табличке выше локаторы правдоподобно соответствуют позывным, согласно принятой в Стране системы.

Стоит заметить, что большее хождение имеет 6-значная запись локатора, так называемые «малые» квадраты, размером около 5*5 км. Это позиционирует станцию на местности с куда большей точностью, что весьма важно на УКВ.

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

Так, «UA9XXX: @ALLCALL CQ CQ CQ LP51» вмещается в один таймслот.
А вот «UA9XXX: @ALLCALL CQ LP51AA» уже нет, хотя букв меньше.

Данные настройки переносятся вот на эту вкладку:

Персональные настройки программы JS8Call.

Так как все экземпляры клиента запускаются на одной машине, с общими системными часами, синхронизация времени пока не требуется. Но приём и передача ведутся в таймслотах, стандартно по 15 секунд. «Медленный» режим практикуется в слоте 30 секунд. Однако при выставлении настройки «Enable Simultaneous Decoding of All Speeds (AUTO)» декодируются любые режимы, чем все и пользуются.

Вот правильные настройки (кликабельно для лучшего обзора):

Настройки режимов сетевой активности программы JS8Call.

Время для отсчёта в таймслотах вовсе не обязано быть синхронизировано с мировым, и, как видно по меню водопада «Timing», может быть назначено четырьмя способами (сверху вниз):

  • По передачам других станций, с усреднением по нескольким.
  • По любым имеющимся часам.
    Как пишет автор в хэлпе, «хоть по крику петуха».
  • По окончанию передачи другой станции.
  • По началу передачи другой станции.
  • Последняя кнопка сбрасывает то, что сотворено предыдущими.

Теперь каждому экземпляру следует назначить собственную частоту. Совсем не обязательно сгонять все узлы сети на общую частоту, как в телеграфе или телефоне. Наоборот, это делать категорически не следует.

По умолчанию на моду JS8Call самим её создателем выделено всего 500 Гц спектра, но сообщество этого ограничения не придерживается от слова совсем. Настройки следует изменить так, первый крыжик (да и остальные тоже расставьте как на картинке):

Настройка автоответа и рабочего диапазона частот программы JS8Call.

Если этого не сделать, передача на звуковых частотах ниже 500 Гц и выше 1000 Гц не будет возможна.

Также придётся отрегулировать уровни чувствительности микрофонного входа и линейного выхода. Левый индикатор на скрине лучше подвести к 40-60 dB, а правый убрать в ноль (только на время эксперимента, на самом деле ноль соответствует уровню -45 dB). Для правдоподобности местный автор включил на всю катушку софтовый генератор белого шума (0 dB), чтобы станции проходили с эфирным уровнем порядка +10 dB.

Если звуковая карта простенькая, придётся её вход и выход соединить шнуром. Полнодуплексная должна разрешать трём экземпляром связного софта общаться между собой без всяких дополнительных внешних шнуров. Надо только правильно расставить крыжики в панелях регуляторов записи и воспроизведения.

На древнем ноутбуке (местный автор ставил эксперименты на двухядерном процессоре 1.66 GHz 1GB) вполне запускаются пять экземпляров клиента JS8Call, хотя для моделирования и понимания работы сети достаточно трёх. Вот тремя и ограничимся, иначе сложность превысит предел понимания.

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

Настройки режимов сетевой активности программы JS8Call.

Этот скрин заодно демонстрирует наличие фильтра. Частоты всех станций своей сети можно поставить бок о бок, настроить на этот кусок спектра фильтр, и всё, что поёт и кричит за пределами частот фильтра, нас больше не волнует.

В настройках лучше выставить Custom Interval, поместив в него простое число из ряда 5, 7, 11, 13, 17, 19. Для каждой станции сети лучше ставить собственное, не повторяющееся значение. Тогда пингование сети со стороны её участников будет регулярным и не одновременным.

Какая-то из станций сформирует сигнал @HB первой.
Или это можно вызвать через «Control→Send Heartbet→Send Heartbet Now»
Пусть проявит нетерпение станция с позывным UA9YYY.
Тогда наблюдаемая нами станция UA9XXX зафиксирует такое:

Проверка сетевой активности сети JS8.

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

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

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

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

Если ткнуть мышом в любую из доступных станций, неактивная кнопка «Directed» активируется, и откроет доступ к таким действиям:

Все возможные действия в сети JS8.

То же, на великом и могучем, с объяснениями от автора программы:

Команда: Значение команды и примеры:
SNR? Какой у меня SNR?
GRID? Какой у вас локатор?
INFO? Какая информация о вашей станции?
STATUS? Какое сообщение о статусе вашей станции?
HEARING? Какие станции вы слышите?
> [MESSAGE] Пожалуйста, перешлите это сообщение по назначению.

При получении сообщения полностью станция назначения отправит ответ ACK.

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

  • KN4CRD>HELLO! (отправит сообщение на KN4CRD)
  • KN4CRD>DR4CNK>HELLO!
    (отправит сообщение на DR4CNK через KN4CRD)
  • KN4CRD>DR4CNK>J0Y>HELLO!
    (отправит сообщение J0Y через DR4CNK через KN4CRD)

Станции будут отвечать на подмножество команд, переданных через переадресованные сообщения (SNR, INFO, GRID, MSG, MSG TO: и т.д.), и будут отвечать, используя предоставленный путь ретрансляции.

MSG [MESSAGE] Пожалуйста, сохраните и отобразите это сообщение в вашем почтовом ящике.
MSG TO:[CALLSIGN] [MESSAGE] Сохраните это сообщение на вашей станции.
  • Сохраняет сообщение в постоянном хранилище (на диске) для последующего извлечения с помощью команды «QUERY MSGS»
  • [CALLSIGN] является первым словом после символа «:» и является конечным получателем сообщения.
QUERY CALL [CALLSIGN]? Можете ли вы общаться напрямую с CALLSIGN?
  • Если станция может услышать позывной, она отправит обратно «YES», а затем ACK на этот позывной с отчетом SNR.
QUERY MSG [ID] Доставьте сообщение, идентифицированное по ID
QUERY MSGS Назовите ID сообщения, сохранённого для меня.
  • Каждый ответ будет содержать идентификатор самого старого сообщения, которое должно быть доставлено.
  • Чтобы получить текст сообщения, введите команду QUERY MSG с идентификатором.
AGN? Станция повторяет свое последнее сообщение.
SNR Отправить отчет о сигнале.
INFO Отправить информацию о станции.
GRID Отправить длинный локатор сетки (чтобы его можно было найти на карте через PSKReporter & JS8NET
QSL? Вы получили мою последнюю передачу?
QSL Я получил вашу последнюю передачу.
YES Я подтверждаю ваш последний запрос.
NO Я не подтверждаю ваш последний запрос.
HW CPY? Сообщение принято?
RR Роджер. Получено.
FB Дела идут отлично.
TU Спасибо.
73 Я посылаю свои наилучшие пожелания.
SK Конец связи.
DIT DIT Конец контакта / два бита.

Среди прочего наблюдается пара опций, весьма нам интересных.

Ретрансляция сообщений.

Это главное свойство Mesh-сетей, когда доступные элементы топологии обеспечивают транзитный доступ к недоступным. Например, в дневное время удалённые друг от друга станции (пусть это будут UA9XXX и UA9ZZZ) совершенно не слышат друг друга, но вполне могут общаться с UA9YYY, расположенной где-то между ними.

Если оператор UA9XXX желает послать сообщение UA9ZZZ через UA9YYY, ему хорошо бы сперва убедиться, что связь между UA9YYY и UA9ZZZ в принципе есть.

Делается это так:

    • Оператор UA9XXX тыкает в окне активности диапазона (которое самое правое) в позывной UA9YYY, и через кнопку «Directed» выбирает пункт «QUERY CALL [CALLSIGN]?»

      Если нужной станции в правом окне активности нет, её всегда туда можно поместить через контекстное меню.

    • В белом окне текущего сообщения отобразится шаблон
      «UA9YYY QUERY CALL [CALLSIGN]?»
      где вместо макроса с квадратными скобками (он будет уже выделен) надо просто начать писать позывной UA9ZZZ.

    • Нажатие «Enter» или кнопки «Send» поставит сообщение в очередь на отправку, что случится в ближайший же таймслот.

    • В эфир будет передано сообщение, дополненное позывным:
      «UA9XXX: UA9YYY QUERY CALL UA9ZZZ? 4ZI»
      Три символа в конце являются контрольной суммой.
      Это сообщение заносится в лог станции (окно повыше) красным.

    • В окне приёма станции UA9YYY сообщение отобразится как:
      «UA9XXX: UA9YYY QUERY CALL UA9ZZZ?»

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

    Действие UA9XXX: Сообщение:
    UA9YYY → команда: QUERY CALL [CALLSIGN]?
    Шаблон сообщения: UA9YYY QUERY CALL [CALLSIGN]?
    После редактирования: UA9YYY QUERY CALL UA9ZZZ?
    Передача UA9XXX: UA9XXX: UA9YYY QUERY CALL UA9ZZZ? 4ZI
  1. Теперь перенесёмся на станцию UA9YYY:

    Действие UA9YYY: Сообщение:
    Принято от UA9XXX: UA9XXX: UA9YYY QUERY CALL UA9ZZZ? 4ZI
    Получено UA9YYY: UA9XXX: UA9YYY QUERY CALL UA9ZZZ?
    Передача UA9YYY: UA9YYY: UA9XXX YES +12 (11M)
  2. Вернёмся на станцию UA9XXX:

    Действие UA9XXX: Сообщение:
    Принято от UA9YYYY: UA9YYY: UA9XXX YES +12 (11M)

    Информация из этого рапорта извлекается такая:

    • «YES» - это собственно сам ответ.
    • «+12» - уровень приёма UA9ZZZ при последней его активности.
    • «11 M» - как давно случилась эта активность, тут в минутах.

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

  1. Будем отсылать в качестве сообщения кодовую посылку «CODE 456»:

    Действие UA9XXX: Сообщение:
    UA9YYY → команда: >[MESSAGE]
    Шаблон сообщения: UA9YYY>[MESSAGE]
    После редактирования: UA9YYY>UA9ZZZ>CODE 456
    Передача UA9XXX: UA9XXX: UA9YYY> UA9ZZZ>CODE 456 2OL
  2. Действие UA9YYY: Сообщение:
    Принято от UA9XXX: UA9XXX: UA9YYY> UA9ZZZ>CODE 456 2OL
    Получено UA9YYY: UA9XXX: UA9YYY> UA9ZZZ>CODE 456
    Передача UA9YYY: UA9YYY: UA9ZZZ> CODE 456 *DE* UA9XXX ME7

    Логика при ретрансляции примерно та же (свой позывной добавлен слева, контрольная сумма справа), но структура послания поменялась. Его следует понимать как «сообщение от такого-то позывного».

  3. Действие UA9ZZZ: Сообщение:
    Принято от UA9YYY: UA9YYY: UA9ZZZ> CODE 456 *DE* UA9XXX ME7
    Получено UA9ZZZ: UA9YYY: UA9ZZZ> CODE 456 *DE* UA9XXX

    Задача решена, но отправитель пока об этом не знает.
    Получатель шлёт подтверждение по обращённой траектории:

    Действие UA9ZZZ: Сообщение:
    Передача UA9ZZZ: UA9ZZZ: UA9YYY> UA9XXX ACK C.T

    Это просьба UA9ZZZ к UA9YYY передать для UA9XXX подтверждение «ACK». Справа контрольная сумма, которая составляется из любых разрешённых символов, не исключая и точку.

  4. Действие UA9YYY: Сообщение:
    Принято от UA9ZZZ: UA9ZZZ: UA9YYY> UA9XXX ACK C.T
    Получено UA9YYY: UA9ZZZ: UA9YYY> UA9XXX ACK
    Передача UA9YYY: UA9YYY: UA9XXX> ACK *DE* UA9ZZZ 0K-

    Синтаксис сообщения вновь изменился, как мы наблюдали ранее.

  5. Действие UA9XXX: Сообщение:
    Принято от UA9YYY: UA9YYY: UA9XXX> ACK *DE* UA9ZZZ 0K-
    Получено UA9XXX: UA9YYY: UA9XXX> ACK *DE* UA9ZZZ

    Если такое подтверждение не пришло, кто-то кого-то не услышал.

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

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

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

Хранение сообщения на внешнем узле до востребования.

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

Задача пусть будет ровно та же самая. UA9XXX должен как-то доставить сообщение для UA9ZZZ, причём прямой связи между ними нет, но у обоих есть выход на UA9YYY, хоть и в разное время суток. Ретрансляция тут уже не актуальна по определению.

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

  1. Оператор станции UA9XXX, включив её, должен убедиться в активности UA9YYY. Для чего можно просто запросить SNR, то есть уровень приёма станцией UA9YYY сигнала от UA9XXX.

    Действие UA9XXX: Сообщение:
    UA9YYY → команда: SNR?
    Передача UA9XXX: UA9XXX: UA9YYY SNR?

    Это напрямую исполняемая команда, редактированию не подлежит.

    Действие UA9YYY: Сообщение:
    Принято от UA9XXX: UA9XXX: UA9YYY SNR?
    Передача UA9YYY: UA9YYY: UA9XXX SNR +15

    Действие UA9XXX: Сообщение:
    Принято от UA9YYY: UA9YYY: UA9XXX SNR +15

    Стало понятно, насколько хороша связь в обе стороны - уровень приёма запрашиваемая станция рапортует, уровень сигнала ответа тоже будет виден в левом окне интерфейса. Хотя и так понятно, если ответный рапорт получен, с каналом связи всё в порядке.

  2. Убедившись в наличии связи с UA9YYY, UA9XXX выбирает макрос:

    Действие UA9XXX: Сообщение:
    UA9YYY → команда: MSG TO:[CALLSIGN] [MESSAGE]
    Шаблон сообщения: UA9YYY MSG TO:[CALLSIGN] [MESSAGE]
    После редактирования: UA9YYY MSG TO:UA9ZZZ CODE 234
    Передача UA9XXX: UA9XXX: UA9YYY MSG TO:UA9ZZZ CODE 234 MO7

    Тут в качестве сообщения посылается кодовая посылка «CODE 234».
    Но никто не запрещает написать что-то длинное открытым текстом.

  3. Действие UA9YYY: Сообщение:
    Принято от UA9XXX: UA9XXX: UA9YYY MSG TO:UA9ZZZ CODE 234 MO7
    Получено UA9YYY: UA9XXX: UA9YYY MSG TO:UA9ZZZ CODE 234

    Одновременно в почтовом ящике у UA9YYY материализуется, будем называть это так, письмо от UA9XXX к UA9ZZZ, которое можно увидеть через пункты меню «View→Show Nessage Inbox...»

    JS8Call Обмен сообщениями через почтовый ящик.
  4. Естественно, UA9YYY рапортует отправителю:

    Действие UA9YYY: Сообщение:
    Передача UA9YYY: UA9YYY: UA9XXX ACK

    UA9XXX это видит так:

    Действие UA9XXX: Сообщение:
    Принято от UA9YYY: UA9YYY: UA9XXX ACK
    Получено UA9XXX: UA9YYY: UA9XXX ACK

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

Аналогичный квест, но в противоположном направлении должен проделать UA9ZZZ, когда появится в радиосети. Это может происходить так:

  1. Запрос от UA9ZZZ к UA9YYY наличия адресованных к UA9ZZZ писем:

    Действие UA9ZZZ: Сообщение:
    UA9YYY → команда: QUERY MSGS
    Передача UA9ZZZ: UA9ZZZ: UA9YYY QUERY MSGS
  2. Действие UA9YYY: Сообщение:
    Принято от UA9ZZZ: UA9ZZZ: UA9YYY QUERY MSGS
    Получено UA9YYY: UA9ZZZ: UA9YYY QUERY MSGS
    Передача UA9YYY: UA9YYY: UA9ZZZ YES MSG ID 12
  3. Действие UA9ZZZ: Сообщение:
    Принято от UA9YYY: UA9YYY: UA9ZZZ YES MSG ID 12
    Получено UA9ZZZ: UA9YYY: UA9ZZZ YES MSG ID 12

    Смысл рапорта такой:

    • «YES» - да, для вас есть сообщения.
    • «ID 12» - идентификатор самого старшего сообщения.
  4. Все сообщения должны считываться по очереди.
    Начинаем с идентификатора 12:

    Действие UA9ZZZ: Сообщение:
    UA9YYY → команда: QUERY MSG [ID]
    Шаблон сообщения: UA9YYY QUERY MSG [ID]
    После редактирования: UA9YYY QUERY MSG 12
    Передача UA9ZZZ: UA9ZZZ: UA9YYY QUERY MSG 12 OKQ
  5. Действие UA9YYY: Сообщение:
    Принято от UA9ZZZ: UA9ZZZ: UA9YYY QUERY MSG 12 OKQ
    Получено UA9YYY: UA9ZZZ: UA9YYY QUERY MSG 12
    Передача UA9YYY: UA9YYY: UA9ZZZ MSG CODE 234 FROM UA9XXX HPC
  6. Действие UA9ZZZ: Сообщение:
    Принято от UA9YYY: UA9YYY: UA9ZZZ MSG CODE 234 FROM UA9XXX HPC
    Получено UA9ZZZ: UA9YYY: UA9ZZZ MSG CODE 234 FROM UA9XXX

    В этот момент на экране станции UA9ZZZ возникает оповещение о получении сообщения от UA9XXX, сохранённого станцией UA9YYY, и это сообщение попадает в почтовый ящик UA9ZZZ:

    получение письма с хранением у посредника.

    Далее станция UA9ZZZ должна уведомить UA9YYY об успешности:

    Действие UA9ZZZ: Сообщение:
    Передача UA9ZZZ: UA9ZZZ: UA9YYY ACK
  7. Действие UA9YYY: Сообщение:
    Принято от UA9ZZZ: UA9ZZZ: UA9YYY ACK
    Получено UA9YYY: UA9ZZZ: UA9YYY ACK

    Получив такое подтверждение, станция UA9YYY удаляет сообщение из своего почтового ящика, так как оно затребовано адресатом, и успешно ему доставлено.

  8. Возможно, на диске у UA9YYY хранятся другие письма для UA9ZZZ, так что он должен повторить пункт 1, а в случае положительного ответа, и все дальнейшие. Ответ «NO» в пункте 2 говорит об отсутствии писем.

Другие полезные возможности.

В списке команд явным образом видна возможность помещения сообщения в почтовый ящик доступного узла, а не только передача этого сообщения «от клавиатуре к глазам». Речь про команду с макросом «MSG [MESSAGE]», которая будет полезна при отсутствии оператора у включенной станции. Возвернётся, проверит ящик, всё увидит.

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

Вот как это будет выглядеть вместе с ответными рапортами:

Действие: Сообщение:
UA9YYY → команда: UA9YYY> UA9ZZZ MSG X TO Z VIA Y
Передача UA9XXX: UA9XXX: UA9YYY> UA9ZZZ MSG X TO Z VIA Y IQ8
Приём UA9YYY: UA9XXX: UA9YYY> UA9ZZZ MSG X TO Z VIA Y
Передача UA9YYY: UA9YYY: UA9ZZZ> MSG X TO Z VIA Y *DE* UA9XXX EZD
Приём UA9ZZZ: UA9YYY: UA9ZZZ MSG X TO Z VIA Y *DE* UA9XXX
Передача UA9ZZZ: UA9ZZZ: UA9YYY> UA9XXX ACK C.T
Приём UA9YYY: UA9ZZZ: UA9YYY> UA9XXX ACK
Передача UA9YYY: UA9YYY: UA9XXX> ACK *DE* UA9ZZZ 0K-
Приём UA9XXX: UA9YYY: UA9XXX> ACK *DE* UA9ZZZ

Тут по команде «UA9ZZZ MSG X TO Z VIA Y», вложенной в другую команду «UA9YYY>», сообщение «X TO Z VIA Y» было ретранслировано от UA9XXX к UA9ZZZ через UA9YYY, и попало в почтовый ящик UA9ZZZ. При этом подразумевается, что напрямую UA9ZZZ с позиции UA9XXX не доступен.

Транзит письма и рапорта занял 3 минуты на «нормальной» скорости.
Почтовый ящик станции UA9ZZZ пополнился новым сообщением.
Запись вполне внятно объясняет, откуда письмо взялось:

Почтовый ящик в программе JS8.

Ну а теперь самое замечательное.

Чтобы обменяться ответным письмом (с опусканием его в почтовый ящик UA9XXX), оператору станции UA9ZZZ не нужно мучительно соображать, как составляется комбинация из каких двух макросов, и какие позывные в какой последовательности туда вписываются. Оператор просто жмёт кнопку ответа «Reply»:

Действие: Сообщение:
Команда: Reply UA9YYY>UA9XXX MSG [MESSAGE]
После редактирования: UA9YYY>UA9XXX MSG OK, ping passed
Передача UA9ZZZ: UA9ZZZ: UA9YYY> UA9XXX MSG OK, PING PASSED P2Q
Приём UA9YYY: UA9ZZZ: UA9YYY> UA9XXX MSG OK, PING PASSED
Передача UA9YYY: UA9YYY: UA9XXX> MSG OK, PING PASSED *DE* UA9ZZZ YVE
Приём UA9XXX: UA9YYY: UA9XXX MSG OK, PING PASSED *DE* UA9ZZZ
Передача UA9XXX: UA9XXX: UA9YYY> UA9ZZZ ACK J5A
Приём UA9YYY: UA9XXX: UA9YYY> UA9ZZZ ACK
Передача UA9YYY: UA9YYY: UA9ZZZ> ACK *DE* UA9XXX PD5
Приём UA9ZZZ: UA9YYY: UA9ZZZ> ACK *DE* UA9XXX

Действительно, письмо материализовалось в ящике у UA9XXX:

Почтовый ящик в программе JS8.

Транспорт налажен, можно письма тупо гонять кнопкой.
С этого момента всё становится очень просто.

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

Более сложная топология сети.

В наших палестинах всё совсем скорбно и убого, но вот Европа покрыта сетью JS8Call целиком, перекидываясь на Штаты. По крайней мере, на «сороковке» жизнь точно есть.

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

Так что, покричав общим вызовом в сторону неведомого @ALLCALL, или сообщениями типа «First Time JS8Call», и так ничего и не поняв, новичок столь же скоротечно рассасывается.

Между тем, как следует из наших предыдущих изысканий, мы можем:

  • Послав «Heartbeat», выявить автоматические станции.
  • У каждой из них командой «GRID?» уточнить её QTH Locator.
  • По «HEARING?» понять, какие станции слышит запрашиваемая.
    Этот этап целесообразно периодически повторять.
    Станция рапортует только о четырёх своих последних контактах.
  • Используя эту станцию как ретранслятор, двинуться дальше.
    Рекурсивно производя дальнейший опрос по той же схеме.

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

В результате нарисуется топология сети, грубо привязанная к карте, с указанием, какой узел из какого доступен, и когда по времени.

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

Интеграция с цивилизацией.

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

Должно быть и какое-то практическое применение.
Да, такое сыскалось.

Программой JS8Call зарезервированы целых 23 специальных группы, среди которых есть и совсем специальная, под именем «@APRSIS». Обратившись к любой станции, подключенной к интернету, на которой разрешена подача спотов, мы можем попросить эту станцию поставить на общедоступной карте отметку нашего местоположения.

Если конкретнее, настройки вкладки «Reporting» должны быть такими:

Разрешение сетевой активности JS8Call (PSK Reporter, @APRSIS).

Если принимающая станция так и сконфигурирована, она промониторит все команды, посланные в группу @APRSIS, и перешлёт их сервису.

Сама команда простая. Пусть она набрана станцией UA9ZZZ:

Действие UA9ZZZ: Сообщение:
Белое поле сообщения: @APRSIS GRID NO40IA
Передача UA9ZZZ: UA9ZZZ: @APRSIS GRID NO40IA

Выделенное зелёным - QTH локатор из 4, 6, а лучше 8 или 10 знаков.

Сразу же после этого сайт aprs.fi размещает на карте отметку с позывным UA9ZZZ, совпадающую с левым нижним углом «малого» квадрата:

Отслеживание местоположения объекта через группу @APRSIS программы JS8Call.

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

Как без интернета узнать свой QTH локатор по GPS координатам?
Местному автору нравится решение, требующее только браузера.
Причём в автономном режиме (Java Script на HTML странице).
Посмотреть или скачать, 20 kB.

С мелкими квадратами (QTH из 6, 8 или 10 символов) лучше работать через специальный софт, наподобие Grid Calculator под Винду. Для мобильных платформ нечто аналогичное тоже по-любому сыщется, но это уж сами.

В самых ранних версиях JS8Call для группы @APRSIS завлялась поддержка почтового шлюза, однако теперь эти команды более не работают, да и в хэлпе к программе о почтовом шлюзе нет никакого упоминания.

Частоты режима JS8Call.

Внимание уделено всем традиционным любительским диапазонам:

Диапазон: Частота: От FT8: А так же:
160 м 1.842 МГц +2 кГц  
80 м 3.578 МГц +5 кГц  
40 м 7.078 МГц +4 кГц  
30 м 10.130 МГц -6 кГц  
20 м 14.078 МГц +4 кГц  
17 м 18.104 МГц +4 кГц  
15 м 21.078 МГц +4 кГц  
12 м 24.922 МГц +9 кГц  
11 м     27.245 МГц
10 м 28.078 МГц +4 кГц  
6 м 50.318 МГц +5 кГц 50.328 МГц
2 м 144.178 МГц +4 кГц  

Тут имеется ввиду частота настройки трансивера.
Работа происходит только в верхней боковой полосе USB.
Никакой опции реверса боковой полосы в софте не сыскалось.

Для примера возьмём интересный нам диапазон 80 метров.
SSB канал для 3.578 МГц охватывает частоты 3.5783-3.5807 МГц.
Но выше 3.58 МГц уже другая песня, там JS8Call делать нечего.

Очень удобно, что «Волынка» со своими частотами 3.5794-3.5805 попадает в официально предназначенный для JS8Call диапазон, так что ей можно пользоваться в спектре 400-1000 Гц по звуковой частоте. При выборе частот для «Волынки» это тоже имелось ввиду.

Представляет интерес, на каких диапазонах вообще есть жизнь.
Поставим эксперимент.

Выгуглим любой список WEB-SDR, и выберем из него опять-таки первый попавшийся приёмный терминал. Желательно территориально находящийся в гуще людей, но чуток на отшибе, для минимизации помех техногенного происхождения. Внесём его позывной и QTH в настройки программы JS8Call, и разрешим ей подачу спотов на сайт pskreporter.info.

Если правильно выставить частоту в программе и терминале, не забыв выбрать USB, а время в программе синхронизировать с учётом задержки, вносимой SDR приёмником (на практике до нескольких секунд), то по прошествии какого-то времени, желательно охватывающего часть дня и сумерек в месте дислокации SDR, на указанном сайте можно просмотреть споты, поданные позывным.

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

Сеть JS8Call на 80-метровом диапазоне (PSK Reporter).

Приёмная станция в Нидерландах (у неё значок побольше) днём видит английский сегмент сети, на совершенно типичных для 80 м. диапазона удалениях 400-500 км.

Ночью слышно явно лучше, на 1000 км удалении обнаруживается парочка ирландских станций. И более никого вокруг нет.

В целом картина ожидаемая. Радиолюбителям не сильно интересна местная связь, вся их деятельность регламентируется условия дипломов «работал с ХХХ странами» (зонами, квадратами). Да и антенна на этот диапазон потребуется длинная. Не у всех для неё есть достаточный по размерам земельный участок. А с натягиванием всяких непонятных проводов куда попало и как попало в Европе строго.

Вся жизнь в моде JS8Call проистекает на сороковке:

Сеть JS8Call на 40-метровом диапазоне (PSK Reporter).

Днём базовая станция слышит другие в окрестности до 700-900 км. Это то, что на рисунке скучено, и можно накрыть подушечкой большого пальца.

В сумерках (которые по карте надвигаются справа налево) зона приёма увеличивается вдвое, к сети добавляются станции Финляндии, Румынии, Испании, и даже одна Питерская.

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

На двадцатке активность тоже есть, но хиленькая:

Сеть JS8Call на 20-метровом диапазоне (PSK Reporter).

Дальность тоже вроде бы впечатляет - до Индии 7000 км, до Канар тоже не менее 3000. Но диапазон чисто дневной, с ярко выраженной мёртвой зоной. При анализе, кто кому отвечает в автоматическом режиме, становится ясно, что рядом расположенные станции слышат друг друга негромко.

Вся эта активность проистекает при мощностях от 20-25 Ватт до 50-100.
Зависимости дальности от мощности практически никакой.
Похоже, критерий только один - есть прохождение / нет его.

Если кому-то кажется, что всё это чисто радиолюбительские затеи, будет не прав. Давайте-ка вспомним про CB диапазон 27 МГц, безлицензионный в большинстве стран мира, и легко обнаружим активность режима JS8Call в диапазоне частот 27.245-27.247 МГц:

Сеть JS8Call на 11-метровом диапазоне (PSK Reporter).

Естественно, всё опять-таки ограничено Европой, причём самой развитой её частью. Но идея понятна - этот цифровой режим применяется несколько шире, чем изначально задумано. С какой уж целью, не так и важно.

Что внутри, или хитрый алфавит.

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

Это довольно интересно.
Давайте посмотрим, что в итоге получилось.

В меню программы «Log→Open Log Directory...» доступна ссылка на папку с файлами «DIRECTED.TXT» и «ALL.TXT», где копятся эфирные сообщения, если это разрешено настройками. В первом файле они идут прямым текстом, во втором разбиты на фреймы, и сопровождаются служебными записями.

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

Message in DIRECTED.TXT:
EA8CBZ: IZ1FKS OK VERY FINE STATION MY HOBBIES ARE SAILING RACE THE RALLIES AND THE RADIO OF COURSE MY PROFESSION IS MACHINIST NAVAL, I WORKED SHIP AND TANKERS, BUT I NOW I WORK IN MAINTENANCE
Message in ALL.TXT:
Frame A: B: Frame C:
R1HLTG1raLy0 1 EA8CBZ: IZ1FKS
pINy7jbgyM++ 0 OK VERY FINE STATION
tZWl7k7BE+++ 0 MY HOBBIES ARE
xpORFQSJW2++ 0 SAILING RACE THE
tVyikM4JW2++ 0 RALLIES AND THE
-qlM6BmtiUE2 0 RADIO OF COURSE MY
tpeIXht+Kj++ 0 PROFESSION IS MACHINIST
y-CH3Ktl3oBE 0 NAVAL, I WORKED SHIP
yiBtUm26l47I 0 AND TANKERS, BUT I
-fQNk1eM+N8t 0 NOW I WORK IN MAINTENANCE
+O++++++++++ 2

Легко посчитать, что полезная загрузка одного таймслота составляет от 14 до 25 символов. Конечно же, там ещё есть и служебные байты - фрейм «B» демонстрирует, что заголовок помечается единицей, продолжение нулём, последний блок двойкой. Команды всего из одного таймслота помечаются тройкой, здесь есть определённая система.

Колонка «Frame A» с 12 символами и есть ужатое эфирное сообщение.
Коэффициент сжатия для текста составляет, грубо говоря, от 1 до 2.
Как это примерно делается, можно почитать здесь.

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

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

Сравнение скоростей моды JS8Call.

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

Скорость: Таймслот: Baud: Интервал: Полоса: ΔSNR:
Slow 25.28 s 3.125 3.125 Hz 25 Hz +3 dB
Normal 12.64 s 6.25 6.25 Hz 50 Hz ==FT8
Fast 7.90 s 10 10 Hz 80 Hz -2 dB
Turbo 3.95 s 20 20 Hz 160 Hz -6 dB

В любом таймслоте передаётся 79 символов восемью тонами (8FSK).
Интервал между тонами меняется от 3.125 до 20 Гц.
Соответственно, и ширина полосы сигнала варьируется от 25 до 160 Гц.

Так как модуляция в режиме «Normal» в точности совпадает с дизайном сигнала моды FT8, полное совпадение будет и по SNR. Другие скорости чуть отличаются от такого «эталонного» SNR, правый столбец.

Очевидно, никто никаких претензий по порогу детектирования к моде FT8 не имеет, так что 15-секундный таймслот для всех и будет основным.

Удобства при дежурном приёме.

Если использовать софт JS8Call в режиме дежурного приёма, а саму моду в качестве транспорта для экстренной/аварийной/партизанской связи, такая вот вкладка уже не кажется излишеством:

Сервис оповещения (нотификаций).

Её назначение - издавать громкие звуки в случае наступления каких-то событий. Файлы со звуками назначаются самостоятельно.

Правда, не всё так просто.

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

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

Звуковой карте достаточно быть самой простой и компактной:

Внешняя звуковая карта.

Софт JS8Call через настройки вкладки «Audio» обучается слушать эфир, передавать в него, и проигрывать нотификации в разные звуковые карты, сколько бы их не было. Или в одну и ту же.

Работа с двумя звуковыми картами.

Зачем это всё?

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

Производительность компьютера для дежурного круглосуточного приёма может быть небольшой. Если ОС сама по себе не требовательна к ресурсам (например, Windows XP), то одноядерного процессора 1.5 GHz и ½ GB памяти будет вполне достаточно. Хлам с AVITO за $30 справится.

Дальнобойность моды JS8Call.

Местный автор все виды цифровой связи обязательно тестирует на макете, с зашумлением сигнала специальным софтом, по методике, изложенной в §6.2 опуса про «Волынку».

Точно так же была оттестирована и эта мода. Но поскольку клиент не умеет писать звук прямо в файл, и оттуда же его читать, пришлось возиться со шнурами и записью сигнала внешним устройством. Всё это даёт лишнюю погрешность, на глаз оцениваемую в 1-2 dB в единицах SNR.

Это, конечно, неправильно, но местный автор не увидел особой разницы между предельной чувствительностию режима «Normal» (таймслот 15 s) и «Slow» (таймслот 30 s). SNR получилось близким к -25÷26 dB, и на 6 dB отличалось от намеренной самой программой (-19÷20 dB), что типично для всех других цифровых режимов, и не является проблемой при сравнении относительных цифр.

Фактическая разница в 1 dB сильно отличается от табличной, 3 dB.

Хочется сказать, что на самом деле мода JS8Call (а с ней и FT8) не столь уж и выдающаяся, каковой она преподносится в сообществе радиолюбителей. На 600-км радиотрассе (2 Ватта, 80-метровый диапазон) уровень сигнала приближается к -20 dB, и при замираниях он уже не детектируется. Замена моды на гораздо более широкополосную «Оливию 32-125» ситуацию сразу же лечит - в тех же самых условиях связь есть.

Но, конечно, в куда более медленном темпе.
И не в столь удобном интерфейсе. Этого не отнять.

При перекличке на 200 км всё более радостно. Да, сигнал варьируется от -7 до -16 dB, но всё ещё остаётся в допустимом диапазоне, без выпадений. Тут бы вполне хватило и одного Ватта, а уж на условные 100 км и подавно.

Перспективность моды JS8Call.

Однако, если условия для связи не экстремальные, цифровая мода JS8Call вполне применима. Её софт продуман и удобен.

Особо подкупает концепция автоматического режима, с пингованием сети, и запросом рапорта о слышимости. Возможность ретрансляции сообщения, либо доставки его прямо на жёсткий диск адресата, в том числе и посредством другой станции, радует просто несказанно. На всякий случай мы подробно и пошагово рассмотрели, как это делается практически.

Столь полезный цифровой режим связи заслуживает самого пристального внимания. В Стране он как-то не сильно распространён, и напрасно. Даже пациентам 151 палаты такой софт весьма пригодится.

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

Информации на русском языке по моде JS8Call практически нет совсем.
Скорее всего, такое положение дел сохранится и в дальнейшем.
Так что надо брать и пробовать, пытаясь изыскать для себя профит.
Кто профит ищет, тот его всегда найдёт.

Другие статьи категории «Радиосвязь»

Антенна для Волынки 151 палаты.

Антенна для Волынки 151 палаты. Местный автор, чтя самурайские традиции, в рамках челленджа «1000 Yen rig» некоторое время назад сотворил вполне пристойный радиомодем для цифровых видов связи «Волынка 151 палаты». Теперь хорошо бы его оснастить эффективной антенной, также стоящей копейки, и тоже собранной из чего попало. Потому как антенна не может стоить дороже радиостанции, верно?

КВ модем цифровых видов связи с японским уклоном В151П.

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

Неплохой клиент цифровых видов связи для смартфона.

Неплохой клиент цифровых видов связи для смартфона. Только для пациентов 151 палаты, остальным будет неинтересно. Впервые на арене AndFlmsg по-русски. Как-то мы тут проектировали и собирали одноваттный SSB радиоканал на КВ. Как одно из применений, а точнее, метод повышения надёжности и дальнобойности этого радиоканала, образовалась тема использования цифровых видов связи.
25 августа 2020, 17:14

№ 1JS8Call и PSKmail

Благодарю! Как обычно читал с удовольствием!
Я тоже буквально в середине августа задумался над организацией сети на КВ. Искал почтовые клиенты, которые можно поставить на мини-компьютер RaspberryPi. Нашел PSKmail. Он использует в основном моды PSK500 и иногда THOR22. Посканировал его частоты в моей местности(Казань). Нашел проход пакетов на 10.148 МГц в вечернее время. Днём тихо и ночью тоже. На остальных частотах тихо. Судя по карте PSKmail в России он не используется никем. Хотя на форумах некоторые писали, что собирались ставить сервера в Петербурге. Так вот у PSKmail скорость достаточная, чтобы в радиусе 100-200км передавать небольшие файлы, если использовать NVIS. Только на 80 метров у них частота 3.589МГц Для шарманки 151 не подойдёт :( Только если кварц менять или использовать другой трансивер.
Благодаря вашей статье узнал про JS8Call. Она идеально подходит для обмена сообщениями по типу SMS! И у них тоже есть версия для RaspberryPi, что очень хорошо! В общем я понял, что нужно в первую очередь ориентироваться на JS8Call, а PSKmail использовать как дополнение на частоте 10.148 МГц. Можно сначала договориться о передаче файла на 80-ке, а потом передать его на 30-ти метрах через PSKmail.
P.S.
Не хочу никого пугать, но есть серьёзные основания считать, что в декабре 2020-го или в январе 2021-го интернет(и не только он)накроется медным тазом. Природные катаклизмы... натворят дел. В общем я тороплюсь успеть и хочу предупредить об этом других.
AndrewKzn
Все заметки категории «Радиосвязь»