Я 14106
Оно действительно работает =)
Но, я бы использовал узкие "нестандартные" режимы....

А давайте на 10ке? 28.310

14 106
кто маячит ?? шикарно принимаю, но обрезан спектр по верхам, выключите фильтр 2,7 или перейдите в нестандартную моду

Broadcast message from 'RD8DR'. - 31.01.2015 - 15:47:22
CQ DE RD8DR K
Broadcast message from 'RD8DR'. - 31.01.2015 - 15:47:57
CQ DE RD8DR K
Broadcast message from 'RD8DR'. - 31.01.2015 - 15:48:32
CQ DE RD8DR K

14 106
Broadcast message from 'RD8DR'. - 01.02.2015 - 13:07:47
CQ DE RD8DR K
Broadcast message from 'UT5UBX'. - 01.02.2015 - 13:22:08
CQ CQ CQ DE UT5UBX PSE K
Broadcast message from 'RD8DR'. - 01.02.2015 - 13:22:32
CQ DE RD8DR K
CQ DE RD8DR K
Broadcast message from 'UT5UBX'. - 01.02.2015 - 13:52:38
CQ CQ CQ DE UT5UBX PSE K
Broadcast message from 'RD8DR'. - 01.02.2015 - 13:52:43
CQ DE RD8DR K
Broadcast message from 'RD8DR'. - 01.02.2015 - 13:54:31

Народ не знаю куда запостить, напишу сюда.

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

1. система радиосети в составе от 2 до 100 станций с возможностью самоорганизации, изолированной от интернета.
2. система должна уметь автоматически контролировать прохождение и в случае ухудшения прохождения переключаться в другой канал.
3.В случае отключения головной станции временные полномочия наделяется следующая по сетевому номеру,
пока не вернется в сеть головная станция или оператор не назначит новую головную станцию.
4.вновь появившаяся станция посылает зонд сигнал, и получает от главной станции автоматический ответ, который даст новой станции сетевой адрес,
допустим 055. если головная станция не даст в отведенное время ответ, то следующая по сетевому адресу дает ответ и присваивает сетевой адрес.
5.список сетевых адресов, список каналов, общие настройки программы и список приоритетов синхронизируется не реже одного раза в час.
6. с промежутком от 5 до 30 минут происходит зондирующий опрос всех станций которые отвечают в последовательности с сетевым номером.
7. при появлении на станции исходящего письма отправляется зондирующий сигнал предварительно проверив не занят ли канал.
если канал не занят устанавливается связь с адресатом при отсутствии связи с адресатом связь устанавливается большим по номеру
или меньшим сетевым адресом и в последствии пересылает адресату.
если канал занят и письмо не носит срочный характер то станция дожидается своей очереди опроса, и в момент опроса сообщает о наличии письма адресату,
и отправляет его, если письмо срочное то станция вклинивается в обмен и соединяется с адресатом.
если адресат не слышит станцию то письмо получает адресат большим или меньшим сетевым адресом и в последствии пересылает адресату.
8. станции должны уметь оставлять основной канал для установки связи др.станций. и уметь проверять запасные каналы.
9.головная станция может предлагать каналы связи согласно внутренней инструкции и общим настройкам программы.
10.Пргограмма должна уметь управлять трансивером(рацией) при помощи САТ интерфейса и поддерживать большинство известных трансиверов.
Управлять автоматическим антенным тюнером. Автоматическим переключателем антенн.
11.Программа должна уметь поддерживать следующие протоколы связи: MIL-STD-188-110 (с вариантами), STANAG-4285,
для зондирования прохождения использовать следующие протоколы MIL-188-141А,B а так же CODAN SELCAL,
предварительный сигнал зондирования и определения протокола связи вместо пилот тона REED-SOLOMON идентификатор
12.Предусмотреть возможность чата для операторов.

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

RD8DR

Вы сами столько придумали (похвально), или есть ссылка на источник?

Zmej

увы сам.

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

Я уже где-то писал тут, но вкратце повторюсь. Аварийное загнется от ненужности в не-аварийное время, таковы реалии. Нужно придумать так, чтобы этим можно было пользоваться ежедневно, но вопрос, как? Всех устраивает интернет из провода или оптики и ничего не надо больше, радио осталось чтобы поболтать или работать на сбор ДХ и ЩСЛ, а многие вообще отказались от эфира даже для общения и чешут на радиолюбительские темы в различных VOIP-приложениях, последний писк моды так называемая "радиошарманка" - вообще маразм полнейший...

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

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

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

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

Для начала стоит начать с уровней модели OSI, все надеюсь про них знают?

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

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

Zmej
последний писк моды так называемая "радиошарманка" - вообще маразм полнейший...

Просветите, что за приблуда?

ТАНК

о резиновых женщинах слышали?

вот то-же самое, только вместо трансивера и антенн комп и интернет

Просветите, что за приблуда?

http://tiparadio.ru/
В общем, эхолинк для "свободных". Только громко не делайте, там мат и неадекваты могут попадаться.

DVE

где можно по читать про модели OSI?

RD8DR
Например здесь: http://infocisco.ru/network_model_osi.html

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

Нечто похожее и работало в сети Fidonet лет 20 назад, но уже тогда каналы были телефонные и работали быстрее. Почитайте https://ru.wikipedia.org/wiki/Фидонет в разделе "Техническая организация сети", там все по сути как раз заточено под модемные сети.

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

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

Раньше не было хороших канальных модемов из-за отсутствия возможности реализовать их на основе ЦОС, всё чем могли довольствоваться - FSK модемы построенные на аналоговой схемотехнике. Сейчас начали появляться. Была так же надежда на этот РФСМ, но увы.

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

Посмотрите здесь:
http://hflink.com/standards/
Кое-что есть, из уже придуманного.

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

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

Там реализовано даже два уровня интерфейса (реализовано в виде обмена файлами со специальными именами):
1) режим "тупого" модема - чистый модулятор/демодулятор. Но весь функционал типа установления связи, гарантированной доставки и всего остального - придется делать самому.
2) режим "автоматизированного оператора" - когда можно имитировать нажатия на кнопки "connect", "send file" и т.д.

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

YuriVR

сам участвовал в этой затее, но до конца не все понял. Но это не то о чем мечтаю я...

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

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

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

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

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

головной станции
А при падении или заглушении (приёма) "головы", вся сеть умирает?

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

Для начала все это можно вообще погонять в симуляторе - если знаете С++, создайте класс "Узел", создайте сеть хотя бы из 10-100 таких узлов, пропишите их параметры (координаты, задержки, кто кого видит, какие частоты поддерживает, вероятность успешной передачи и пр), сэмулируйте некий обмен пакетами, посмотрите как они доходят.
Виртуально всю "сеть" вообще можно гонять так, не имея ни одного трансивера. Когда логика обработки пакетов будет ясна, и они будут гарантированно доходить до "адресата", тогда уже пробуйте это к реальному модему прикрутить.

Dmitry_D2D - спасибо, что появились тут!

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

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

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

Может всё-таки соберетесь мыслЁй и сделаете как-то нам такой подарок?

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

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

Но! В этом случае от RFSM будет использоваться только очень малый объем его функционала. Фактически - только демодуляция/модуляция, ну и обмен данными с собственно демодулятором/модулятором. И реализатору упоминаемого выше проекта придется "родить" такой объем кода, отвечающий за все остальное, что механизм межпрограммного обмена данными - сокеты или файлы - становится НАСТОЛЬКО мелочью, что она в принципе не стоит обсуждения. Сам принцип обмена не изменится - выдал порцию/получил порцию - а уж как и через что - абсолютно не важно...

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

Вот поэтому я и не вижу особого смысла в такой затее. В нынешнем виде RFSM плохо подходит для организации сети, а если честно - совсем не подходит. Он планировался как средство МАКСИМАЛЬНО быстрой ОДНОСТОРОННЕЙ доставки ДЛИННЫХ файлов (подчеркиваю - именно ДЛИННЫХ файлов в ОДНУ сторону, правда любую, а не коротких сетевых пакетов) между ДВУМЯ корреспондентами (опять же - ДВУМЯ). Вся его архитектура (и даже структура сигнала) были заточены именно на это. Все дополнительные сетевые возможности прикручивались потом - и были костылями... Они были совершенно не предусмотрены заранее. Исходная задача была - потестировать передачу данных по КВ большими кусками, померить достигаемые скорости - и все. Остальное - так, баловство в свободное время...

В итоге. Расширять и изменять функционал программы я уже не буду - просто некогда. А тот герой который сможет создать ГОРУ кода - сначала для организации и поддержки соединения "точка-точка", для быстрого и гарантированного двустороннего обмена сетевыми пакетами, ну и все остальные приблуды для работы СЕТЕВОЙ программы (тестирование сети, маршрутизация пакетов и прочие прелести) - так вот, такой герой сможет подключить модулятор/демодулятор и через имеющийся механизм файлового обмена. И если он это сделает - в смысле, все вышеперечисленное - я даю ЧЕСТНОЕ СЛОВО, что реализую ЛЮБОЙ удобный ему механизм межпрограммного обмена :)))

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

Честно говоря, сам до конца не выяснил. Скорее всего, проблема в том, что программа не всегда корректно опознает имеющуюся передачу на входе. Не слышит, образно говоря. Причины могут быть разные. Чаще всего - плохое качество сигнала. Еще - в случае "слабой" PC, тогда программа не успевает обрабатывать, и куски сигнала теряются.
Какие еще могут быть причины - бог весть... Я заложил в программу несколько уровней синхронизации передачи, но в том случае, если обе стороны друг друга "не слышат" - гарантированного решения нет. Так что увы. Совет только один - рвать соединение и пересоединяться...

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

Dmitry_D2D
> Исходная задача была - потестировать передачу данных по КВ большими кусками, померить достигаемые скорости - и все.

И чего кстати получилось, какой реально скорости можно добиться между двумя трансиверами, например? (если не секрет конечно)

alexcom

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

совсем уж без головы эта сеть заживет сама а потом наступит апокалипсис ))))


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

И чего кстати получилось, какой реально скорости можно добиться между двумя трансиверами, например? (если не секрет конечно)
Ну конечно не секрет. Скорость, естественно, напрямую зависела от условий прохождения сигнала.
В хороших и идеальных условиях (и еще на УКВ) скорости часто достигали заложенного максимума - 8000 бит/сек.
А вообще - после окончания передачи каждого файла программа выводила итоговую реальную скорость передачи фала (байт/сек, с учетом всех накладных расходов).
У меня логов не сохранилось, но может кто из старожилов поднимет логи - там можно посмотреть.

просто, настройки сети забирает вновь подключенная станция, можно условно считать если станция более часа не входила в контакт в сети ее можно считать чужой, хотя вдруг ей будут сообщения то где они должны храниться...? вопрос.
наверное должно быть подтверждение о получении и прочтении сообщения, (оператор уснул) а сообщения не достигли реального адресата
Кстати, происходящее обсуждение еще раз показывает, что подобную систему нужно предварительно очень тщательно СПРОЕКТИРОВАТЬ, и если подобный проект будет ДЕЙСТВИТЕЛЬНО хорошим, то он займет 80 - 100 страниц текста А4 - собственно, как и любой другой рабочий стандарт из семейства тех же MIL-STD или STANAG...

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

Dmitry_D2D

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

да и в споре рождается истина

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