HF SDR transceiver + Q15X25 + DHT + гипертекствоый векторный Чеширнет
(размышления дилетанта)

Кто-то пытался построить такую автоматическую децентрализованную сеть передачи на КВ? Или это не взлетит?

SDR-трансивер потому что лучше иметь возможность приёма сразу множества каналов. Например, подходящий трансивер https://github.com/softerhardware/Hermes-Lite

Далее какой-то цифровой протокол, где бы передавались обязательные позывные (выбрал Q15X25 наугад - 2500 кбит/с обеспечивает и норм)

Далее - DHT-таблица для автоматического построения ориентированного графа роутинга между станциями
https://ru.wikipedia.org/wiki/Распределённая_хеш-таблица

А вот уже поверх этого можно запустить протокол передачи данных по принципу store-and-forward. Например:
https://github.com/cheshirenet/cheshirenet
https://github.com/cheshirenet/cheshirenet/wiki/%D0%9E%D1%84%D1%84%D0%BB%D0%B0%D0%B9%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9-Web

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

вот когда появится действительно децентрализованный (намек на router.utorrent.com например) и шифрованный протокол которой невозможно распознать (второй намек на d1:ad2:id20) и заблочить на стороне провайдера вот тогда и поговорим.

Именно децентрализованный протокол DHT и предлагается.

Никаких провайдеров не требуется - вся связь через КВ.

Цель - не шифроваться, а сохранять в неизменном виде и обмениваться информацией.
(При этом, peer2peer криптография между конкретными абонентами с помощью smime или gpg не отменяется)

А по филейной части не дадут? За криптографию-то?

httpd, бросьте в личку адрес эл.почты, на который можно вам написать.

Цель - не шифроваться
Как вариант, использовать только аутентификацию отправителя, но не сокрытие содержания сообщения.

Как вариант, использовать только аутентификацию отправителя, но не сокрытие содержания сообщения.

В Чеширнете оно так и задумано:
https://github.com/cheshirenet/cheshirenet/wiki/%D0%98%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D0%B8

выбрал Q15X25 наугад - 2500 кбит/с обеспечивает и норм
Выберите лучше что-то типа RFSM - он, по крайней мере, реально работает.

У Q15X25 слишком много недостатков, из-за которых он в течение почти двух десятков лет (разработан в 90-е) так и не "взлетел". В числе главных - не предусмотрена возможность автоматической настройки приемной станции на параметры (информационная скорость, кодирование, перемежение) передающей - эта информация не передается в преамбуле, а ручками эти параметры задаются однократно, обычно на этапе установки софта. А отсюда куча технических и эксплуатационных проблем.

А тут еще высокий пик-фактор, и как следствие, дополнительные требования по согласованию с передатчиком.

Как результат, на весь КВ диапазон реальных пользователей Q15X25 можно в буквальном смысле слова по пальцам пересчитать.

Ценное замечание, спасибо!

Выберите лучше что-то типа RFSM - он, по крайней мере, реально работает.

Не удалось найти ничего, кроме программы. Описание протокола бы, хоть обзорное.

Сигнал на основе слегка модифицированного MIL-STD-188-110B. Информационные скорости от 300 до 8000 бит/с. К сожалению, авторы от активного развития проекта отошли, но софт найти можно.

так нам не софт надо, а его исходники или описание протокола

Описание протокола 110B есть в сети, находится любым поисковиком. Вопрос в достойной реализации протокола. Именно поэтому исходники RFSM авторы Вам вряд ли отдадут.

Не уверен, но когда-то шел разговор о поддержке в RFSM какого-нибудь сетевого интерфейса.

Так или иначе, есть достаточно серьезные основания полагать, что Q15X25 в очередной раз не взлетит. А из достойных альтернатив, кроме RFSM, ничего на ум не приходит.

Вопрос в достойной реализации протокола. Именно поэтому исходники RFSM авторы Вам вряд ли отдадут.

В контексте данной задачи всё, что не в опенсорсе - не существует :)

Спасибо за наводку на протоколы.

Хороший подход :)))

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

asv
Выберите лучше что-то типа RFSM - он, по крайней мере, реально работает
Вроде как и у "Марсиан" есть похожий софт.

httpd
на КВ? Или это не взлетит?

Не взлетит. Во первых скорость мала ку15-го, во вторых он хреново работает в помехах и пик фактор большой т.к. широкий сигнал.

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

А вообще цифровые сети на КВ и УКВ уже были у радиолюбителей в 80-90е, но потом всё умерло из-за потери интереса и разраставшегося интернета, всем просто стало неинтересно что-то гонять в эфире, когда в квартиру интернет подведен "из водопровода".

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

KarapuZ
Однако же, тоже не опенсорс. И опять таки, у марса реально скоростей выше 1200 я не видел. А RFSM гоняют до 8000 включительно, сам видел.

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

Что касается WinMOR-а, то, как ни печально, некоторые врожденные недостатки протокола не способствуют его "взлету".

asvТам они пилят продолжение винмора - ардоп, вроде по шустрее: [Видео YouTube - нажмите для просмотра]

ZGmej
Прочитал, не думаю, что радикально что-то поменяется.

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

Вот разработчики 110B/110C/S4538/HDL+ эти факторы учитывают, поэтому и результат хороший.

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

Кстати,пдф-ка в сети недавно встретилась, в которой упоминаются перспективные принципы построения сетей ДКМВ с программно-определяемыми радиосредствами, в том числе и с использованием
технологии CHESS.

что он будет работать в режиме с перезапросами, и что он скорее всего будет завязан на сетевую инфраструктуру.

Так они для ARQ и делали, а структура просто мыло переслать точка-точка, дальше в интернет.

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

Я тоже не знаю, чем он помогает (не профессионал в этом), но звучит в конце интересно, когда пакет дополняется до нужной длины видимо какими-то однотипными символами ))

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

Одновременно использовать один и тот же КВ канал, без разделения по времени и частоте, можно, но трудно (пространственное, поляризационное разделение). Так что в каждый конкретный момент все равно имеет место или точка-точка или бродкаст.

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

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

Неформально - для эффективного использования канала связи сигнал должен быть как можно менее регулярным (в идеале - шумоподобным).

Zmej
Так они для ARQ и делали, а структура просто мыло переслать точка-точка, дальше в интернет.

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

Есть, например, гибридная ARQ, успешно реализованная в S4538, HDL+, и некоторых других профессионально разработанных связных стандартах.

Идея простая - берем блоковый код со скоростью 1/2 (длина информационной части равна длине проверочной части) подходящей длины. Длину информационной части кода выбираем равной длине пакета со служебными данными и CRC. Передаем информационную часть. Если прием не подтвердился - передаем проверочную часть. Нетрудно убедиться, что хорошо подобранный помехоустойчивый код со скоростью 1/2 гораздо эффективнее двукратного повторения данных.

Нужно понимать что в идеале в КВ канале скорость больше 500-1000 бит/с по факту не получить. Имеется ввиду со всеми накладными расходами - кодирование, перамбулы, таймауты, перезапросы.
Сюда же замешиваем бедность частотного ресурса. По факту - 3,5-10 МГц (а в конкретный момент времени вообще 500-800 кГц на всех желающих), с учетом того что на нужна не одна частота, а набор всяких запасных, дневных/ночных, летних/зимних частот. Ну это если нам нужна "местная" КВ - до 500 км.
Потом прикинем, что нужен выделенный управляющий канал, ибо система с совмещенным управляющим каналом гораздо быстрее затыкается от нагрузки.
В результате все размышлизмы о универсальной КВ сети связи общего пользования утыкаются в тупик, при попытке натянуть эрланги на мегагерцы и биты в секунду.

Altair
Нужно понимать что в идеале в КВ канале скорость больше 500-1000 бит/с по факту не получить. Имеется ввиду со всеми накладными расходами - кодирование, перамбулы, таймауты, перезапросы.
Получить, при достаточно высоком ОСШ и нормально реализованном коммуникационном протоколе.

А в целом, верно, фактор бедности частотного ресурса придется как-то учитывать.

asv
Получить
Очень много будет служебки. Я как не пытался простой протокол придумать - все равно почти полный GSM вылезает. :-)
В конце концов можно на всех наплевать и полосу раширить. Но тогда мы попадаем на полностью свой TRX, без возможности использовать существующий связной парк. Тоже вариант.

Altair
Смотрите отчеты разработчиков по LDL, HDL и HDL+. Там как раз чисто пользовательская пропускная способность, с учетом всех оверхэдов от служебки.

Нужно понимать что в идеале в КВ канале скорость больше 500-1000 бит/с по факту не получить. Имеется ввиду со всеми накладными расходами - кодирование, перамбулы, таймауты, перезапросы.

Не надо забывать, что каналы частично суммируются, т.к. часто передают информацию, интересную всем участникам сети (информация о маршрутизации, как минимум)

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

Особенно это справедливо если использовать SDR-приёмник.

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

Этот вопрос подробнее раскрыть можете?

Подскажите, есть ли разработки профессиональные, где несколько станций соединяются к одной

Зачем к одной? Этого надо избегать всячески, мне кажется

Кстати,пдф-ка в сети недавно встретилась, в которой упоминаются перспективные принципы построения сетей ДКМВ с программно-определяемыми радиосредствами, в том числе и с использованием
технологии CHESS.

Вот вот! И чеширнет этот как раз про то же самое! Тим Бернс Ли даже в том же контексте упомянут:
https://github.com/cheshirenet/cheshirenet/wiki/%D0%9E%D1%84%D1%84%D0%BB%D0%B0%D0%B9%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9-Web