httpd
"Панорамность" SDR позволяет одновременно несколько сигналов от разных передатчиков принимать

Ну допустим... Дальше что? Можно и обычным трансивером с САТ сканировать по кругу несколько частот в ожидании вызова юзеров.
Чтобы использовать в полной мере многоканальный прием, надо уже и дуплекс использовать, значит свой передатчик нужно выносить сторонним каналом связи (УКВ к примеру) куда-то "в соседний квартал", откуда уже его сигнал не будет давить свой приемник в том же диапазоне... Эти требования уже накладывают определенные сложности.

И нет пока "сдр за 200$" - это только малосигнальная плата, к которой нужен блок полосовых фильтров, коммутации, защит, 50-100Вт усилитель мощности 3-30МГц пригодный для длительного режима передачи, ATU... В сумме выйдет уже под тыщу, как кто-то уже и сказал.

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

Точно ничего не путаете?
Точно. Только способ реализации фильтра

httpd
предлагаю показывать протоколы на модели OSI. "Протокол сети" это там какой?

По эталонной модели (которую я только что старательно нагуглил) это получается 5й-4й-3й уровни. Такое расплывчатое позиционирование формулируется по вышеупомянутым ( HF SDR transceiver + Q15X25 + DHT + гипертекствоый векторный Чеширнет - Страница 2 ) причинам: уже на этапе DHT-роутинга роутер должен влезать в более высокий уровень протокола и в соответствии с расставленными там тэгами документов чеширнет осуществлять, собственно, роутинг, и по смежным с ними.

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

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

***

*Люто-бешено затаил злобу на Altairа за "попоголика", но возразить нечего :) *

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

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

В чеширнете, насколько понимаю, всё иначе.

Он вообще-то существует только в виде описания концепта :)

Как вообще выяснять, какие данные есть в сети и как их запрашивать, по какому принципу?

Также как в обычном вебе - всё находится по ссылкам.

Тем более нет сайтов в гипотетической системе децентрализованного обмена КВ-СМСками. Как узнать, какие рассылки существуют, какие из них интересны текущему узлу, с которым мы взаимодействуем?

Настоятельно рекомендую прочитать:
https://github.com/cheshirenet/cheshirenet/wiki/Model#1-%D0%9E%D0%B1%D1%89%D0%B0%D1%8F-%D0%BA%D0%B0%D1%80%D1%82%D0%B8%D0%BD%D0%B0

Ну допустим... Дальше что? Можно и обычным трансивером с САТ сканировать по кругу несколько частот в ожидании вызова юзеров.

Обычным трансивером нельзя вести приём одновременно десятка каналов

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

Почему? Избыточное кодирование никто не отменял

Обычным трансивером нельзя вести приём одновременно десятка каналов
Можно и много каналов. Все можно. Было бы знание матчасти :-) Так например сигнал QPSK-62 (31 бит/сек чистых) занимает в эфире полосу 62 Гц. Округлим до 100 Гц (пусть это будут защитные интервалы), и тогда САМЫЙ ОБЫЧНЫЙ трансивер легко будет одновременно слушать 20 независимых каналов. И это могут быть вызывные каналы по 100 Гц каждый. При получении вызова абонент может договориться уйти на другую частоту и там в 2 кГц своей полосы при ОТЛИЧНОМ канале получить ДО 6 кбит/с канальных или 3 кбит/с - после FEC. Хотя в реальной жизни будет только 160 бит/сек. :-)
Ну а там и до SACCH, FACCH и HLR недалеко :-)

Можно и много каналов. Все можно. Было бы знание матчасти :-) Так например сигнал QPSK-62 (31 бит/сек чистых) занимает в эфире полосу 62 Гц. Округлим до 100 Гц (пусть это будут защитные интервалы), и тогда САМЫЙ ОБЫЧНЫЙ трансивер легко будет одновременно слушать 20 независимых каналов.

Это если они рядышком встанут. А если они на разных диапазонах будут? Вот.

Как планируете разойтись с тем что на каждый диапазон свою антенну надо? Видимо специальной SDR антенной?
А на передачу?

Как планируете разойтись с тем что на каждый диапазон свою антенну надо? Видимо специальной SDR антенной?
А на передачу?

Ровно так же как сейчас расходятся радиолюбители

К тому же, слушать можно много диапазонов, а передавать на одном

httpd
Обычным трансивером нельзя вести приём одновременно десятка каналов

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


Почему? Избыточное кодирование никто не отменял

Объясните, как вы его хотите применять в совокупности с многоканальным приемом?

Altair
Так например сигнал QPSK-62 (31 бит/сек чистых) занимает в эфире полосу 62 Гц.

Это только на картинках в учебнике. В реальности есть еще линейность передатчика (интермодуляция 3го и остальных порядков) для двух тонового сигнала, которая для большинства типовых SSB усилителей не лучше -30дБ. И вообще отстой этот QPSK63, FEC тот не помогает толком.

httpd
Также как в обычном вебе - всё находится по ссылкам.
Судя по содержанию https://github.com/cheshirenet/cheshirenet/wiki/Model - деятельность пользователя в чеширнете организована всё же с большим отличием от интернета как по организации, так и по выполняемым действиям. Впрочем, пусть пока это будет отложено на потом, всё равно концепт не закончен.

Как узнать, какие рассылки существуют, какие из них интересны текущему узлу, с которым мы взаимодействуем?

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

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

The motivation for devising unique digital modes is two fold. First, hams don’t have unlimited bandwidth, especially in the high frequency (HF) bands that allow for long distance communications. Anything that takes less bandwidth is welcome. Second, HF bands have rough characteristics. Signals fade, atmospheric noise causes static and crashes, and other stations cause interference. There are other special cases too, like bouncing signals off meteors where the right digital strategy can significantly improve odds of getting messages through.

Zmej
Это только на картинках в учебнике.
Да, я в курсе. Именно поэтому я считаю что в дешевом полевом варианте это должен быть MFSK (не дураки же ALE придумывали), который в свою очередь не даст скорости более чем 20 байт/сек (чистыми).
Хотя не будем забывать, что OFDM как то все же умудряется пролазить через усилители :-)
А ПРАВИЛЬНЫЕ пацаны умудряются еще и N-первых гармоник программно давить, что бы габариты фильтров не растить. Одно смущает - цена вопроса.

GoBliNuke
обмена текстами с редким и неприоритетным прикреплением файлов - лично меня это устроит чуть менее чем полностью.
Именно так и вижу.

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

Как какой? Затем чтобы копить информацию!

Побольше молчать и получше слушать это вообще хорошее качество :)

деятельность пользователя в чеширнете организована всё же с большим отличием от интернета

Я не знаю что такое "пользователь интернета" в данном контексте, ибо сервер - тоже пользователь!

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

Опять таки, я не знаю чем отличается "текст" от "файла". Каждая нода вольна пропускать тот трафик, который ей интересен/выгоден/не трудно протащить. Ещё можно в рамках Чеширнета придумать тэг типа "пригодно для протаскивания по КВ и т.п. каналам"

Затем чтобы копить информацию!

Побольше молчать и получше слушать это вообще хорошее качество :)

Конкретнее можно с примерами работы одна станция к другой?

Вообще у нас на 14МГц для автоматических станций с полосой сигнала более 500Гц и не более 2.7кГц выделено всего то около 12кГц, фактически 4 канала, если округлить частоты настройки в USB: 14100 14103 14106 14109 кГц с учетом небольших промежутков чтобы не перехлестывались сигналы и того, что там работают уже некоторые технологии, включая винлинк, "дурацкое" АЛЕ первой версии и прочее.
Передавать "многоканалом" тоже формально нельзя, только одни сигналом до 2.7кГц.
Есть еще около 10кГц кусок спектра чуть ниже 14100, но там отведены каналы с полосой сигнала не более 500Гц.
На других диапазонах примерно так же, где-то поменьше в 2-3 раза, например на 10 и 7МГц, т.к. диапазоны узкие сами по себе.

httpd
Я не знаю что такое "пользователь интернета" в данном контексте, ибо сервер - тоже пользователь!
Тут совершенно без подвоха. Пользователь - это человек, который сидит за терминалом и кликает по ссылочкам, просматривает ньюсгруппы и т.п.

Опять таки, я не знаю чем отличается "текст" от "файла".
Кажется, кое-кто надо мной издевается :) Отличие прмиерно того же плана, что и при перекачке по ftp. В одном случае в эфире пересылаются символы варикода, в другом - бинарный файл.

Ещё можно в рамках Чеширнета придумать тэг типа "пригодно для протаскивания по КВ и т.п. каналам"
Очень дельно, сам не сообразил. Тааак. Но тут вылезает препятствие - если этот тэг будет привязан к сообщениям, включённым в структуру, которая способна содержать и другие сущности, непригодные к пересылке по узким каналам, то кто-то будет по широкому каналу получать полные подписку, а кто-то по узкому - выборочную. Или это не баг, это фича? :)

Читаю, то по диагонали, то полностью...
я понимаю что в спорах рождается истина...

кто бы описал о чём спорить? я имею ввиду блок схему...

1. модем (программный или железный) (Пактор 4, 3-Джи АЛЕ, РФСМ, ОФДМ, РС)
2. модель сети (организация или самоорганизация связей между точками)
3. передача информационных пакетов (чат, новостная рассылка, ФТП, почта,гейты)
4. интерфейс (возможность администрирования сети АСУшный интерфейс, пользовательский интерфейс)
5. САТ интерфейс

1. Не обсуждаем, принимаем 20 байт/сек
2. Самоорганизация, без выделенного сервера
3. Короткий текст с нежелательным и низкоприоритетным прицепом небольшого файла
4. Сеть не администрируется, пользовательский интерфейс на смартфоне, либо прямо на морде устройства
5. 17

У меня основной вопрос в самоорганизации. Нужно организовать:
1. Частоты - фиксированные на уровне выдумываемого стандарта. Можно даже не зацикливаться на РЛ диапазонах сначала. Например все "круглые" частоты 2,3,4,5,6,7,8 и т.д. МГц. Что бы любой, кто хранит "изделие" в чулане после включения сразу становился полноправным абонентом.
2. Позывные. Статические или динамические? Буквенные, цифровые или смешанные? С привязкой к геграфическим координатам или без них? Позывные имеют срок действия или нет? К чему они привязаны и как привязать к софтовому варианту "изделия"?
3. Регистрация в сети, т.е. как распределенно организовать БД абонентов. И как понять "был ли мальчик"?
4. Маршрутизация сообщения из Владивостока в Москву, например.

RD8DR
блок схему

Целиком поддерживаю Altairа. Только по п. 5 не понял, что за семнадцать такое :) А нет, понял, айкомовский стандарт.

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

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

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

суть таблица

позывной, ИД-номер (узел), координаты, какие узлы слышит за последние сутки, рапорт канал

RD8DR 03.05.01.c9 56n.47w 03.05.01.01-8-1 03.05.01.b8-9-1 03.05.11.02-7-1
R9CQ 03.05.01.b8 56n.46w 03.05.01.01-8-1 03.05.01.c9-9-1 03.05.11.02-7-1
RK3BF 03.05.11.02 65n.33w 03.05.01.01-8-1 03.05.01.b8-5-1 03.05.01.c9-5-1

CALL ID INFO ID-RPRT-CH

CH-1 7100kHz
CH-2 14105kHz
CH-2 3580 kHz
CH-3 21200kHz

Я не знаю что такое "пользователь интернета" в данном контексте, ибо сервер - тоже пользователь!
Тут совершенно без подвоха. Пользователь - это человек, который сидит за терминалом и кликает по ссылочкам, просматривает ньюсгруппы и т.п.

Ну да, более похоже на фидо это будет. Или чтение сохранённых локально ньюсов.


Опять таки, я не знаю чем отличается "текст" от "файла".
Кажется, кое-кто надо мной издевается :) Отличие прмиерно того же плана, что и при перекачке по ftp. В одном случае в эфире пересылаются символы варикода, в другом - бинарный файл.

UTF-8 уже у нас кругом - тоже, в некотором роде, варикод)
Сжатый каким-либо образом человеческий текст прекрасно ложится в бинарные файлы. Можно даже более лучший, чем варикод, алгоритм использовать.

Короче, это не проблема, это - "ранняя оптимизация")

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

Да

1. Частоты - фиксированные на уровне выдумываемого стандарта.

такую сеть слишком легко будет заглушить (случайно или намеренно)

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

Два ведь надо?

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

2. отпечаток публичного ключа в качестве "настоящего" позывного для каждого узла

"принимать только текст"

да невозможно текст от не текста отличить! есть способы как в текст бинарные данные класть (base64 etc), так и в бинарных данных текст передавать (gzip)

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

Этот вопрос с кондачка не решается. Организация mesh-сети это чисто математическая задача. Эту тему ковыряют уже давно и плотно. Есть несколько алгоритмов для всяких "интернетов вещей" (http://threadgroup.org/) и т.п. Нужно находить подходящие готовые алгоритмы.

Впрочем, повторяюсь, кажется.

примерный файл абонентов и прохождений http://www.radioscanner.ru/uploader/2015/radio_ale_net.rar

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

ПС ПС

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

значит еще в таблице нужно добавить "рейтинг"

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

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

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

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

адрес сети можно наверное сократить...

я думал АА.ВВ.СС.DD

АА - роль в сети 00 головная, 01 точка, 02 без головной
ВВ - номер сети
СС - идентификатор сети (пароль ключ)
DD - номер в сети
позывной думаю нужно указывать только в радиолюбительских сетях
в служебных сетях позывные привяжутся из рассылки где и можно узнать позывной координаты и пр.
хотя в р/л сети то-же можно будет увидеть "карту" таблицу сети
всё передается в шестнадцатеричной системе

о таблице ID.CALL.LOC.point1.CH01.PR.RS.x.point1.CH02.PR.RS.point1.CH03.PR.RS.
ID сетевой адрес
CALL позывной
LOC координаты
point1 точка(ID)
CH01 канал
PR рейтинг чем выше рейтинг тем выше станция в таблице (коррелирует с RS )
RS рапорт - разборчивость уровень
.x. разделитель

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

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

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