Dmitry_D2D

Не стану зарекаться, но наверное нескоро. Да и необходимости особой нет. Постараюсь объяснить.

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

А мне кажется, подходит вполне. Собственно, от РФСМ нужен "почти тупой модем", верней если по-умному называть 1й и 2й LAYER оси-модели, т.е. модемный и канальный уровень. Т.е. дали ему команду установить соединение с таким-то абонентом, он установил (или не установил, если не дозвался :) ) и передал "прозрачный" 8 битный поток приложению, дальше приложение согласно своего протокола производит обмен информацией (в установленном между двумя rfsm соединении) и в случае успешного завершения посылает по контрольному каналу команду на завершение связи.
И такие приложение есть, не надо изобретать и есть человек, который его разработал и поддерживает, и я уверен почти на 100%, что при наличии от вас описания протокола взаимодействия по сокетам без проблем он завяжет туда РФСМ. Детали реализации можем уточнить.

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

Zmej
А мне кажется, подходит вполне.

В чем-то вы правы, а в чем-то - нет.
Механизм установки и поддержания соединения использовать конечно можно.
А вот с передачей "прозрачного 8-битного потока" как раз и возникнут проблемы.
Сейчас программа реализована так, что двунаправленная передача пакетов данных произвольной длины (от единиц байт до нескольких килобайт) будет ЧРЕЗВЫЧАЙНО неэффективной - а именно ОЧЕНЬ медленной и с ОЧЕНЬ большими лагами. Потому что каждый пакет будет рассматриваться как отдельный файл, а в текущей реализации передача отдельного файла - процесс во-первых ОДНОНАПРАВЛЕННЫЙ, а во-вторых - сопровождается ЗНАЧИТЕЛЬНЫМИ накладными расходами, которые становятся приемлемыми только при реально больших файлах (десятки килобайт). Также, в-третьих, система кодирования/перемежения заточена под большие объемы данных. И в-четвертых - система таймингов (длина "пшиков" и время между ними) - заточена под них же. В итоге - имеем то что имеем...

А что-бы перейти к эффективной передаче "прозрачного 8-битного потока", то есть высокоскоростной и с НИЗКИМИ лагами, нужно все вышеуказанное переделать. Применить новое кодирование/перемежение, перерасчитать длины звуковых пакетов и паузы между ними, переделать вторичный протокол подтверждения доставки данных, включив в него как минимум одновременную двустороннюю передачу данных. Ну и кучу других мелочей. Поверьте опыту разработчика - работа это не малая и не быстрая. И все это только для того, что-бы обеспечить хоть сколько-то более-менее эффективную работу "1-го и 2-го LAYER-ра оси-модели".

Вот как-то так...

Dmitry_D2D
Рад, что кто-то из авторов вернулся. Может Вы ответите на мой вопрос о приобретении лицензии?

Dmitry_D2D
А вот с передачей "прозрачного 8-битного потока" как раз и возникнут проблемы.
Сейчас программа реализована так, что двунаправленная передача пакетов данных произвольной длины (от единиц байт до нескольких килобайт) будет ЧРЕЗВЫЧАЙНО неэффективной - а именно ОЧЕНЬ медленной и с ОЧЕНЬ большими лагами. Потому что каждый пакет будет рассматриваться как отдельный файл, а в текущей реализации передача отдельного файла - процесс во-первых ОДНОНАПРАВЛЕННЫЙ, а во-вторых - сопровождается ЗНАЧИТЕЛЬНЫМИ накладными расходами, которые становятся приемлемыми только при реально больших файлах (десятки килобайт).

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


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

Zmej


Ну там обычно система транспорта писем и работает с блоками в десятки килобайт. К примеру, абонент соединился, запросил свои письма, сервер ему их зарядил одним сжатым блоком (причем сжатие данных можно и на уровне приложения этого делать, а можно и не делать, пусть рфсм жмет) , который нужно передать односторонне, т.е. пока он передается, клиент ничего не шлет, только принимает, а модем высылает подтверждающие или запрашивающие повтор пакеты на своем уровне.
Потом, если есть исходящая почта - работает в обратном направлении.
Именно так в RFSM уже и сделано. Причем с возможностью привязки к реальном e-mail-серверам и передачи почты на них, правда, только по открытому протоколу.
И толку? Все равно не видел, что-бы кто-то это использовал...

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

rusmax
Рад, что кто-то из авторов вернулся. Может Вы ответите на мой вопрос о приобретении лицензии?
А зачем? Если только вам, то лицензия бета-тестера является полной (без ограничений). Пользуйтесь на здоровье.
Если кому-то еще - пишите в личку, обсудим.

Именно так в RFSM уже и сделано.
И толку?

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

Beacon text packet: CQ CQ CQ UT5UBX WWW email server and File server - 07.02.2015 - 11:21:46
Beacon callsign packet: UT5UBX - 07.02.2015 - 11:22:21 - Час назад на 14106 наблюдал.

Zmej
Суть в том, что можно будет интегрировать РФСМ в ту систему, где сейчас используют пактор-контроллеры, т.е. операторы добавят туда РФСМ, а радиоканал в т.ч. с возможностью выбора или сканирования частот уже у них есть. Соответственно расшириться сколько то и круг пользователей. А отдельное только на основе рфсм не прижилось.
Конечно, так сделать можно.
Только, чтобы оно работало, нужно обеспечить полую совместимость протоколов общения, как минимум, с пактор-контроллерами. Для этого крайне желательно иметь полную спецификацию на эти протоколы.

Увы. Спецификаций у меня нет. И возможности (да и желания) обеспечивать совместимость - тоже...

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

Копировать протокол пактор-модема не нужно. От вас достаточно сделать сокетного протокола, в котором будут команды управления (позвать такого-то абонента, разорвать связь, выдавать статус модема, передать маяк, еще может какие-то данные вроде количества данные оставшихся в буфере на передачу), а так же поток для передачи и приема данных. При наличии такого интерфейса разработчик системы добавит туда РФСМ. А может и другие тоже заинтересуются.

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

Zmej

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

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

что то я стал много думать о своей системе радиосвязи...

мысль туда прикрутить але калм мил стд станаг и рфсм .... полная глупость они рассчитаны под свои задачи.

первое что должно появиться в эфире это рида-соломона сигнал который выдаст позывной приоритет и запрос на получение сетевого имени. та станция котороя его получит тоже начнет с рида-соломона но потом будет дан сигнал в ПСК-125 в один ствол
длинной пакета скажем 10-30 сек принимающая станция должна подтверждать также кодом РС и иной раз короткими пакетами.
пакеты скорее всего должны завершаться хэш кодом сравнения дабы повторить не достающие блоки.
при малых потерях в блоках вид передач должен меняться по следующему алгоритму ПСК-125-1,пск125-2,пск125-4, пск125-6 пск125-8, пск125-12, пск 125-16 (полоса передачи где-то 2,5кГц)
зондирующие сигналы пск125-2. оценка прохождения от количества потерянной информации из переданного блока, скорее всего пакеты зондирования должны сравниваться с эталонным блоком.

если кому то покажется бредом выше изложенное, это начало описание протокола деревенским языком.

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

если кому то покажется бредом выше изложенное, это начало описание протокола деревенским языком.

http://www.arrl.org/files/file/WINMOR.pdf

Zmej
спасибо за книжку, по читаю

Dmitry_D2D
я плохой знаток теории, я чисто практик, что видел в эфире (на спектре) то и описываю.
Вопрос вот в чем, какая теоретическая скорость передачи при 16ПСК125?
и возможно ли в одном из 16 каналов скажем передавать служебную информацию хэш пакета, открытая часть ключа шифрования...
или это лучше разделять во времени внутри пакета?

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

и из протокола обмена информацией нужно предусмотреть общую (всем всем CQ) рассылку и что бы на станции отправителе было видно кто получил а кто нет. кто прочитал а кто нет.

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

Чтобы впихнуть невпихуемое...
Есть тут на форуме один товарищ, он говорит - универсальное враг хорошему. Я где-то с ним даже согласен.

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

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

Zmej

почитав книгу понял что я описываю, это "винмор" (в смысле сигнал)

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

RD8DR
Ну как вам сказать, мыслите нормально, но это снаружи так просто кажется. Простой пск125 взять, как предлагаете 16 "палок" по 125 бод, да вроде быстро, но уязвимость к помехе пропорциональная увеличению числа этих самих "палок" (каналов), т.е. нужно вводить избыточное кодирование и другие вещи, которые в OFDM применяют, соответственно, скорость уже не ого-го получается, а более приземленная. В винморе сделали два основных подтипа сигналов, 2 "палки" (~500Гц занимает) и много палок (сколько именно, забыл уже, 6 или 8, лень открывать пдф) общей шириной 1.6кГц, так вот этот широкий вариант "сливает" узкому при средне-паршивом прохождении, а на хорошем проходе конечно широкий быстрей льет, но механизм выбора у них тормознутый, он пока спустится с широкого режима на узкий прохождение может снова поменяться.

Zmej

ага!

вот может механизм понижения и повышения скорости сделать правильным (быстрым) + ступеней по больше.
может сделать алгоритм - зависимость длинны пакета от изменений в прохождении... т.е. если прохождение улучшается-ухудшается быстро то и длина пакетов меньше если прохождение более стабильное то и длина пакетов длиннее,
ну а от количества потерь уже регулируется сколько палок в сигнале, только стоит ли менять скорость внутри этих палок?
есть ли зависимость 8ПСК125 <> 4ПСК250 ?

в винморе подтверждение пакетов идет рид-соломоном?
может и наш так-же реализовать...

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

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

может сделать алгоритм - зависимость длинны пакета от изменений в прохождении...

Можно, ести ARQ протокол не синхронный.

ну а от количества потерь уже регулируется сколько палок в сигнале, только стоит ли менять скорость внутри этих палок?
есть ли зависимость 8ПСК125 <> 4ПСК250 ?

По моим наблюдениям за различными существующими протоколами и некоторым экспериментам, больше 100 бод "на палку" нет смысла делать. Для очень пробивного параллельного модема может быть даже 50бод/палка. Если нужно быстрее - увеличиваем кратность фазовой модуляции ( BPSK-QPSK-8PSK и т.д.). С последовательными модемами, кроме РФСМ можно сказать больше не знаком. Хотя вот новинка пакторной фирмы, протокол PACTOR-4 после двух долго просуществовавших версий с параллельными ("многопалочными") модемами, перешла на последовательный, хотя тут может быть из-за желание в два раза увеличить скорость от 3й версии, оставшись в той же стандартной полосе SSB трансивера.

в винморе подтверждение пакетов идет рид-соломоном?

Там супервизорные пакеты идут почти всегда в меньшей скорости, 4FSK с ридовским кодом.


я же сторонник сделать свой.

Желающие кодить есть? :)

-----


как в нем реализовать зондирование прохождения?

По разному можно. Просто вручную по выбору оператора (если это клиентская сторона), либо по расчету от индексов активности солнца, можно и проверялку сделать, которая будет пробегаться по диапазонам и "дергать ненадолго" , спрашивая соотношение S/N), но это дольше будет и не всегда подходит ко всем возможным протоколам построения канала. ALE тот только не предлагайте, по-моему убожество полное, во всяком случае первый вариант, 2Г и 3Г не видел.

вопрос по программе. адреса в сети должны быть статичными или их можно сделать частично динамичными?

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

Zmej

я наверное плохо излагаю...
главная станция нужна что бы раздать частоты, каналы диапазон частот.
являться своего рода дирижером, в подаче начала зондирующих сигналов общий опрос и прочее.
если выпадает главная станция на ее место встает следующая по сетевому адресу, если выпадает вторая, то на ее место встает третья
и т.д. в случае организации сети без головной станции, значит в программе должен быть флажок на три положения,
1 главная станция (вариант для РАС, и служб)
2 обычная станция в ранговой сети (вариант для РАС, и служб)
3 обычная станция в без ранговой сети (вариант для радиолюбителей простых)

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

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

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

Я себе слабо представляю реальную самоорганизующуюся структуру сети с учетом того, что это КВ со своими причудами прохождения.
Нужно часто "пинговаться", обновлять среди всех членов сети действующую таблицу маршрутизации и т.д.
В свое время это на УКВ не всегда получалось при скоростях 1200бод и больше, то насчет КВ у меня еще бОльшие сомнения.

вопрос- можно ли пассивно принимать информацию др.станциям?

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

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

Zmej

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


а вот с этим согласен:

одновременно больше двух станций не могут коннектиться? или это можно прописать в протоколе сигнала?
но наверное тогда эти концерты будут длинные?

какую скорость на ближней трассе (100-200км) на частоте 3,5мГц можно продавить с 16ПСК125 ?


ПС

придется переписывать тех задание и по человечески изложить протокол сигнала

пилот тон РИД-СОЛОМОН дальше посылка на первой скорости 1ПСК62,5 (до диагностики прохождения)
2я - 1ПСК125
3я - 2ПСК125
4я - 4ПСК125
5я - 8ПСК125
6я - 12ПСК125
7я - 16ПСК125

может кто подскажет может еще какие то градации вводить?
у меня туго когда ФСК ПСК КуПСК что из них приоритетьнее или остановиться на ПСК?
просто я не припомню чтобы пользовали ФСК в мульти...

ППС

Пактор 4 сложен? может от туда что по заимствовать? или низя?

одновременно больше двух станций не могут коннектиться? или это можно прописать в протоколе сигнала?
но наверное тогда эти концерты будут длинные?

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

какую скорость на ближней трассе (100-200км) на частоте 3,5мГц можно продавить с 16ПСК125 ?

С голого 16ПСК125 ничего не получится. Мы когда-то экспериментировали 2 по пск100 то еще как-то получалось, увеличение числа несущих даже до 3-5 без применения избыточного кодирования только ухудшало.

А так для примера, винмор, в полосе 500Гц (две палки-несущие) при хорошей слышимости даст до 1.5-1.8кБ в минуту.


----

пилот тон РИД-СОЛОМОН дальше посылка на первой скорости 1ПСК62,5 (до диагностики прохождения)


Для установления связи, диагностики лучше какой-то mFSK режим взять, тот же винмор с него начинает или спускается когда совсем "дрова-проход".

Пактор 4 сложен?

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

RD8DR
Ваша инициативность похвальна, но только пока Вы просто смешиваете различные слова, не понимая их смысла.
При переходе от однотонального (последовательного) модема к многотональному возникает проблема с пик-фактором сигнала. Вы ее вообще никак не рассматриваете.
Код Рида-Соломона не двоичный, и не достаточно просто сказать «Рид-Соломон» для обеспечения надежной передачи данных. Нужно решить, над каким полем будет код, параметры кода (n, k), режим декодирования (жесткое/мягкое, исправление ошибок или стираний или ошибок и стираний). Может быть, требуется каскадный код.
Почему вообще Вы считаете нужным использовать РС код, а не, допустим, сверточный или вообще кодированную модуляцию?
Ну и дальше можно продолжать в том же духе.

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

Всячески присоединяюсь к данной мысли.
Энтузиазм конечно похвален, но...
Объем кода для RFSM, который реализует гораздо меньший функционал, и то очень быстро превысил любые разумные пределы.
Поэтому, при всем моем уважении к энтузиазму RD8DR, для реализации подобных вещей требуется где-то так с два-три человеко-года труда достаточно высококвалифицированных программистов. Ну и весьма тщательное проектирование - перед этим...
Поэтому, как ни жаль, но в реализацию всего этого силами энтузиастов - НЕ ВЕРЮ. Отсюда и обсуждение - бессмысленно.
Тут нужен серьёзный коммерческий проект, который, кстати, тоже не будет делаться - уже в силу абсолютной невостребованности на текущий момент.
Как-то так...

YuriVR

по бОльшей части это мои личные измышления, основанные на моем мизерном опыте наблюдения различных сигналов на КВ.
просто нужно меня ткнуть носом в полезные книги, желательно на русском языке.
я конечно сильно амбициозно высказался по поводу создания своего типа сигнала, но в итоге получается о чем я мечтаю могут реализовать программы
Fldigi сайт
WINMOR TNC сайт


почти со схожей функцией RMS Express, но она на английском языке, и не понятно как она сама может проверять почту?

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

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

WINMOR TNC сайт


почти со схожей функцией RMS Express, но она на английском языке, и не понятно как она сама может проверять почту?

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