ФИДО через УКВ

ФИДО через УКВ

═════════════════════════════════════════════════════════════════════════

Отправлено -= Dima Bargamov =- (2:5020/570) using GoldED 1.1.5-b20110208

Area : ru.ftn.develop (ru.ftn.develop)
From : Sergey Dorozhkin, 2:5020/806 (29 авг 18 08:08)
To : Alexey Vissarionov
Subj : Re: Пользовательские флаги нодлиста
══════╧══════════════════════════════════════════════════════════════════
/// Привет, Alexey! \\\

Ответ на сообщение Alexey Vissarionov (2:5020/545) к Sergey Dorozhkin,
написанное 29 авг 18 в 07:39:



В нодлисте наблюдаю такие конструкции: '...,U,NC,NEC,CDP'

И она даже почти валидная.


Вроде тут нет ничего запрещённого, или я ошибаюсь ?



Получается такая запись имеет право на жизнь: '...,U,[что-то или
ничего],FOE,R2AKT,1,144600,KO85VT,12,A' ?

Что в данном случае обозначает флаг R2AKT и кто может его
использовать?


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

Вообще видется такая конструкция:

,U,FOE:<CALL>,<SSID>,[FREQ],[LOCATOR],[SPEED],[MODE]

Example: ...,U,FOE,R2AKT,1,144600,KO85VT,12,A


<CALL> - <CALL> up to 6 byte
<SSID> - <SSID> 1 byte
[FREQ] - <xxxxxx>kHz (default 144600kHz)
[LOCATOR] - <[a-z][a-z][0-9][0-9][a-z][a-z]> Maidenhead locator (default DONT
MATTER)
[SPEED] - (1] = 110/150, [3] = 300, [6] = 600, [12] = 1200 (default), [24] =
2400, [36] = 3600, [48] = 4800, [72] = 7200, [96] = 9600, [192] = 19200
[MODE] - [A] = AFSK (default), [B] - BPSK, [F] = FSK(G3RUH), [G] = GMSK, [M] =
Manchester, [Q] = QPSK

Всё это для работы через радиомодемы (программные или аппаратные). Hа данный
момент есть 'скелет', который умеет подгружать собственный конфиг, отправлять
транзитом поток на модем (от внешней программы), посылать сигнал присутствия
(маяк), читать нодлист (преобразуя для себя только строки с искомым флагом),
писать логи (в том числе и в SysLog).

ЗЫЖ Скорости конечно низкие, но при полном отсутствии других видов связи вполне
имеет право на жизнь.
ЗЗЫЖ Хорошая тренировка и подтягивание опыта в программировании, а то давно
ничего не программировал (до этого плотно занимался МК).

Всего доброго, Alexey. Искренне ваш, Sergey

[Team HAM] [Team Rally] [Team 4x4] [Team OffRoad]
... MyCall R2AKT, ex UB3AHT.
-+- GoldED+/W64-MSVC 1.1.5-b20170303
+ Origin: aka 2:5020/806, 2:5020/1906.908, Ex 2:5020/904.753, Ex (2:5020/806)
═════════════════════════ End of Forward ══════════════════════════════════

оПХвЕР!


Вот!

Дмитрий Баргамов. 73! Altyn CB Radio (RX3AVD)

Re: ФИДО через УКВ

Hi, Andrei!

Ответ на сообщение Andrei Kopanchuk (2:5058/108.2) к Sergey Dorozhkin,
написанное 26 ноя 18 в 14:53:


Нет, узел не сбоит, все нормально. В настройках Гидры нашел параметры
HydraTXWindow и HydraRXWindow ограничивающие передачу полного объема
данных с узла в буфер сервера по интернету. Это немного помогло но
только для скоростей от 9600 и выше. На мелких скоростях я заметил,
что буфер сервера все же заполняется какими-то запросами, которые
приводят к разрыву линка.


Выставил у себя данные переменные в 2кб (стояло 0).


Записал еще одно видео, с измененными параметрами Гидры. Сессия прошла
без разрыва в течении 45 минут, в течении которой был скачал файл на
2.8мб. Правда 4к окно для 19200 оказалось маловато, так как
чувствовалась просадка по скорости даже на 9600.


У меня на ZModem нет вообще переменных :(


Из замечаний. Иногда бывает сталкиваются кадры, так как ответ ZModem-а
не мгновенный и он рассчитан на дуплексные линии (когда подтверждение
кадра добавляет новый в поток). Для пакета предпочтительнее был бы
полудуплексный XModem-1K.


Изучаю, спасибо за инфу.


Также заметил странную работу EMSI
хендшейка. Иногда работает, иногда - нет, причем на малых скоростях,
1200/2400, такой проблемы не было или же встречалась реже.


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

Bye, Andrei

[Team HAM] [Team Rally] [Team 4x4] [Team OffRoad]
... MyCall R2AKT, ex UB3AHT.

Re: ФИДО через УКВ

Привет, Sergey

27 ноя 18, Sergey Dorozhkin пишет к Andrei Kopanchuk:




параметры HydraTXWindow и HydraRXWindow ограничивающие передачу
полного объема данных с узла в буфер сервера по интернету. Это




Выставил у себя данные переменные в 2кб (стояло 0).


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



У меня на ZModem нет вообще переменных :(


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

; Variable Modem string, MaxBlk,StartBlk,ZTimeout,MinCPS_Rx,MinCPS_Tx
; -------------------------------------------------------------------------
Connect 300 CONNECT ;,512, 64, 25, 10, 10
Connect 1200 CONNECT 1200 ;,1024, 512, 18, 25, 25
Connect 2400 CONNECT 2400 ;,2048, 512, 15, 80, 80

Как видим, можно задавать значение ZTimeout, как я понял в секундах. Для
пакетных линков наверное можно сделать как можно больше, секунд до 600.

Также я находил такой вот параметр:

;Error_Correction V42 MNP ARQ .42 X. REL ALT PEP HST LAP COMP
; Эта переменная определяет список фрагментов ответа модема при соединении
; (строка CONNECT). При наличие хотя бы одного такого фрагмента T-Mail
; считает, что соединение произошло с коррекцией ошибок. При этом значение
; таймаута для протокола Zmodem будет увеличено в 3 раза, а также будет
; разрешена запись текста беседы в chat.log. Значение по умолчанию: "V42
; MNP ARQ .42 X. REL ALT PEP HST LAP COMP".

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



подтверждение кадра добавляет новый в поток). Для пакета
предпочтительнее был бы полудуплексный XModem-1K.




Изучаю, спасибо за инфу.


Я тут на днях в свой терминал добавил расширение YAPPC, которое как и XModem
использует дополнительную защиту блоков используя CRC8 контрольную сумму. В
итоге к AX.25 CRC16 добавляется YAPPC CRC8, что в сумме дает двойную защиту,
почти не теряя в скорости (около 0.5%).

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


Andrei Kopanchuk

Re: ФИДО через УКВ

/// Привет, Andrei! \\\

Ответ на сообщение Andrei Kopanchuk (2:5058/108.2) к Sergey Dorozhkin,
написанное 27 ноя 18 в 17:32:


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



; Variable Modem string,
MaxBlk,StartBlk,ZTimeout,MinCPS_Rx,MinCPS_Tx ;
----------------------------------------------------------------------
--- Connect 300 CONNECT ;,512, 64, 25, 10, 10
Connect 1200 CONNECT 1200 ;,1024, 512, 18, 25, 25
Connect 2400 CONNECT 2400 ;,2048, 512, 15, 80, 80


Connect_TCP CONNECT TCP/IP;,8192, 512, 10, 600, 600


Я тут на днях в свой терминал добавил расширение YAPPC, которое как и
XModem использует дополнительную защиту блоков используя CRC8
контрольную сумму. В итоге к AX.25 CRC16 добавляется YAPPC CRC8, что в
сумме дает двойную защиту, почти не теряя в скорости (около 0.5%).


А смысл, если битая CRC в HDLC отбрасывает кадр. А вероятность, что при внешней
CRC пострадала внутренняя CRC крайне мала. Или я что-то не так понимаю ?


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


У меня есть 2 варианта развития программы:
1) Программа работает в режиме Socks серевера, соотнося IP адреса с позывными,
предоставляя сервис для BinkD, T-Mail/IP, etc;
2) Программа реализует самостоятельно обмен файл-боксами между линками.

Работаю (если так можно назвать 3 строчки кода в месяц (конец года, основная
работа 'в ударе')) над 1 вариантом.

Bye, Andrei

[Team HAM] [Team Rally] [Team 4x4] [Team OffRoad]
... MyCall R2AKT, ex UB3AHT.

Re: ФИДО через УКВ

Привет, Sergey

27 ноя 18, Sergey Dorozhkin пишет к Andrei Kopanchuk:


Connect_TCP CONNECT TCP/IP;,8192, 512, 10, 600, 600


Нужно будет попробовать. Только ты установил таймаут в 10, а минимальный CPS в
600. Вот я прописал так в конфиг себе:

Connect CONNECT TCP/IP ;,4096, 512, 600, 0, 0



Я тут на днях в свой терминал добавил расширение YAPPC, которое
как и XModem использует дополнительную защиту блоков используя
CRC8 контрольную сумму. В итоге к AX.25 CRC16 добавляется YAPPC
CRC8, что в сумме дает двойную защиту, почти не теряя в скорости
(около 0.5%).




А смысл, если битая CRC в HDLC отбрасывает кадр. А вероятность, что
при внешней CRC пострадала внутренняя CRC крайне мала. Или я что-то не
так понимаю ?


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

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

Насколько я помню в ZModem используется CRC32. В случае YAPPC наверное это
сопоставимо с CRC24 (16+8). Плюс такого метода в том, что YAPPC блоки можно
задать размером до 256 байт и фрагментировать на несколько HDLC кадров.



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




У меня есть 2 варианта развития программы:
1) Программа работает в режиме Socks серевера, соотнося IP адреса с
позывными, предоставляя сервис для BinkD, T-Mail/IP, etc; 2) Программа
реализует самостоятельно обмен файл-боксами между линками.



Работаю (если так можно назвать 3 строчки кода в месяц (конец года,
основная работа 'в ударе')) над 1 вариантом.


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

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

ZFrameType ZCRCW ; Zmodem sending frame type (ZCRCG (default),
; ; ZCRCQ or ZCRCW
;
; Эта переменная определяет тип используемых фреймов протокола Zmodem. Она
; может иметь следующие значения:
;
; ZCRCG (default) - обычные фреймы, не требующие подтверждения;
; ZCRCW - фреймы, после которых ОЖИДАЕТСЯ подтверждение;
; ZCRCQ - фреймы, после которых посылается (но не ожидается
; передающим) подтверждение.

Но как я понял это должно быть установлено также на двух концах.


Andrei Kopanchuk

Re: ФИДО через УКВ

-=< Доброго времени суток, Andrei! >=-

Ответ на сообщение Andrei Kopanchuk (2:5058/108.2) к Sergey Dorozhkin,
написанное 27 ноя 18 в 23:09:


Нужно будет попробовать. Только ты установил таймаут в 10, а
минимальный CPS в 600. Вот я прописал так в конфиг себе:



Connect CONNECT TCP/IP ;,4096, 512, 600, 0, 0


Поправил:
Connect_300 CONNECT ,512, 64, 25, 10, 10
Connect_1200 CONNECT 1200 ,1024, 512, 18, 25, 25
Connect_2400 CONNECT 2400 ,2048, 512, 15, 80, 80
Connect_4800 CONNECT 4800 ,2048, 512, 10, 100, 100
Connect_7200 CONNECT 7200 ,4096, 512, 10, 200, 200
Connect_9600 CONNECT 9600 ,4096, 512, 10, 200, 200
Connect_12000 CONNECT 12000 ,8192, 512, 10, 300, 300
Connect_14400 CONNECT 14400 ,8192, 512, 10, 400, 400
Connect_16800 CONNECT 16800 ,8192, 512, 10, 500, 500
Connect_19200 CONNECT 19200 ,8192, 512, 10, 600, 600
Connect_21600 CONNECT 21600 ,8192, 512, 10, 600, 600
Connect_24000 CONNECT 24000 ,8192, 512, 10, 600, 600
Connect_26400 CONNECT 26400 ,8192, 512, 10, 600, 600
Connect_28800 CONNECT 28800 ,8192, 512, 10, 600, 600
Connect_31200 CONNECT 31200 ,8192, 512, 10, 600, 600
Connect_33600 CONNECT 33600 ,8192, 512, 10, 600, 600
Connect_38400 CONNECT 38400 ,8192, 512, 10, 600, 600
Connect_57600 CONNECT 57600 ,8192, 512, 10, 600, 600
Connect_64000 CONNECT 64000 ,8192, 512, 10, 600, 600
Connect_TCP CONNECT TCP/IP,8192, 512, 60, 10, 10

Убери у себя из строки ';', а то только имя строки будет, без назначения
параметров.



А смысл, если битая CRC в HDLC отбрасывает кадр. А вероятность,
что при внешней CRC пострадала внутренняя CRC крайне мала. Или я
что-то не так понимаю ?




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


То есть есть смысл внутри использовать CRC32 ?


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


А чем это портит жизнь, если есть некоторый шанс вернуть целостность кадра ?


Насколько я помню в ZModem используется CRC32. В случае YAPPC наверное
это сопоставимо с CRC24 (16+8). Плюс такого метода в том, что YAPPC
блоки можно задать размером до 256 байт и фрагментировать на несколько
HDLC кадров.


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



У меня есть 2 варианта развития программы:
1) Программа работает в режиме Socks серевера, соотнося IP адреса
с позывными, предоставляя сервис для BinkD, T-Mail/IP, etc; 2)
Программа реализует самостоятельно обмен файл-боксами между
линками.





Работаю (если так можно назвать 3 строчки кода в месяц (конец
года, основная работа 'в ударе')) над 1 вариантом.




В первом варианте это будет что-то вроде пакетного прокси? Или я не
так понял?


Да, он самый. Позволит вообще любое приложение поддерживающее Socks
использовать.


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


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


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



ZFrameType ZCRCW ; Zmodem sending frame type (ZCRCG (default),
; ; ZCRCQ or ZCRCW
;
; Эта переменная определяет тип используемых фреймов протокола
Zmodem. Она ; может иметь следующие значения: ; ; ZCRCG (default)
- обычные фреймы, не требующие подтверждения; ; ZCRCW -
фреймы, после которых ОЖИДАЕТСЯ подтверждение; ; ZCRCQ -
фреймы, после которых посылается (но не ожидается ;
передающим) подтверждение.


У меня ZCRCQ стоит.


Но как я понял это должно быть установлено также на двух концах.


Можно поменять на ZCRCW

Bye, Andrei

[Team HAM] [Team Rally] [Team 4x4] [Team OffRoad]
... MyCall R2AKT, ex UB3AHT.

Re: ФИДО через УКВ

Привет, Sergey

28 ноя 18, Sergey Dorozhkin пишет к Andrei Kopanchuk:


То есть есть смысл внутри использовать CRC32 ?


Я думаю, что в дополнение к CRC16 HDLC пакетов достаточно добавить контрольную
сумму блоков внутри. Так как HDLC уже защищенные, то смысла в CRC32 думаю нет,
вполне и CRC16 хватило бы, а сами блоки сделать килобайт по 4, лишние 2 байта
на таком объеме на скорость никакого влияния не оказывают.

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



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




А чем это портит жизнь, если есть некоторый шанс вернуть целостность
кадра ?


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


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


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

На самом деле ошибки не так часто происходят, поэтому вполне достаточно блоков
размером в 4-8кб. В случае YAPPC я выбрал 250 байт, так как длина пакета все
равно ограничена 1 байтом, ну и для кратного числа 250 подходит хорошо. :)



В первом варианте это будет что-то вроде пакетного прокси? Или я
не так понял?




Да, он самый. Позволит вообще любое приложение поддерживающее Socks
использовать.


Ага, полезная штука.



Но как я понял это должно быть установлено также на двух концах.




Можно поменять на ZCRCW


Можно попробовать, но это работает только в случае ZModem, Hydra использует
свои собственные установки. Вчера пробовал все протоколы которые есть в T-Mail,
только Hydra имеет какой-то контроль потока, чтобы весь файл не улетал в буфер.
Надо будет проверить с новыми таймаутами.

PS: Вчера у тебя по бинку фрекнул файл на 240 кб, вообще без проблем прошел на
малой скорости. Но также весь файл упал сразу в буфер сервера.


Andrei Kopanchuk

Re: ФИДО через УКВ

Hi, Andrei!

Ответ на сообщение Andrei Kopanchuk (2:5058/108.2) к Sergey Dorozhkin,
написанное 28 ноя 18 в 15:12:




В первом варианте это будет что-то вроде пакетного прокси? Или я
не так понял?

Да, он самый. Позволит вообще любое приложение поддерживающее
Socks использовать.

Ага, полезная штука.


Предлагаю этот вариант и развивать совместно.

-=< До следующих встреч, Andrei. Искренне ваш, Sergey >=-

[Team HAM] [Team Rally] [Team 4x4] [Team OffRoad]
... MyCall R2AKT, ex UB3AHT.

ФИДО через УКВ

Приветствую, Andrei.

В пятницу, 23 ноября 2018 г. ты писал Sergey Dorozhkin следующее:


Попробовал фрекнуть файл с твоей ноды, используя T-MAIL + AX.25 связку
(Hydra/hdx protocol).

Гидрой-то по что? Она же дуплексная!

IMHO DirectZap нужно юзать over эфир.

73!
Андрей Кольчугин (R2DOU).

... Those who sacrifices freedom for security deserves neither

ФИДО через УКВ

Hello, Andrew!

В продолжении сабжа, кто-то юзал fido over lora?

https://www.youtube.com/watch?... 

С наилучшими пожеланиями, Sergey Anohin.

ФИДО через УКВ

оПХвЕР!

Kaк-тo нa дняx (30 июл 19) Sergey Anohin пишeт к Andrew Kolchoogin...

[ ... ]

В продолжении сабжа, кто-то юзал fido over lora?



https://www.youtube.com/watch?... 

О чем этот фильм? (c)


ФИДО через УКВ

Hello, Dima!



В продолжении сабжа, кто-то юзал fido over lora?
https://www.youtube.com/watch?... 

О чем этот фильм? (c)


Я так понял это такие радиомодемы есть,

https://habr.com/ru/post/39822... 

на УКВ вещают, маломощные. А видео просто нашел что там связка AX25+Lora+TCP/IP
если не лень читать:

https://www.hackster.io/blueti... 

С наилучшими пожеланиями, Sergey Anohin.

Re: ФИДО через УКВ

Привет, Sergey

30 июл 19, Sergey Anohin пишет к Dima Bargamov:


Hello, Dima!





В продолжении сабжа, кто-то юзал fido over lora?
https://www.youtube.com/watch?... 

О чем этот фильм? (c)




Я так понял это такие радиомодемы есть,



https://habr.com/ru/post/39822... 



на УКВ вещают, маломощные. А видео просто нашел что там связка
AX25+Lora+TCP/IP если не лень читать:



https://www.hackster.io/blueti... 



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


Andrei Kopanchuk

ФИДО через УКВ

Привет тебе, Sergey!

Kaк-тo нa дняx (30 июл 19) Sergey Anohin пишeт к Dima Bargamov...

[ ... ]



https://www.youtube.com/watch?... 

О чем этот фильм? (c)




Я так понял это такие радиомодемы есть,

IMHO это обычная телеметрия. Уличные фонари включаются, водосчетчики данные
скидывают, датчики разные на этой херне по всему УКВ трещат. Отказать!



Re: ФИДО через УКВ

Hello, Andrei!


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


Вроде как нет проблем,

https://nag.ru/news/newsline/1... 
https://itechinfo.ru/content/%... 

там тем более мощность небольшая, вот кстати еще пара полезных ссылок

https://github.com/dmahony/LoR... 
https://devlol.org/wiki/fire/L... 
https://libraries.io/github/jo... 

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

вот еще разжевано:
https://habr.com/ru/company/na... 
https://nekta.tech/technology/ 

короче если там tcp/ip гоняют то фидо можно и подавно

С наилучшими пожеланиями, Sergey Anohin.

Re: ФИДО через УКВ

Hello, Andrei!


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


Хотя вон 15 км

https://unsigned.io/15-kilomet... 

С наилучшими пожеланиями, Sergey Anohin.

ФИДО через УКВ

Hello, Dima!



Я так понял это такие радиомодемы есть,

IMHO это обычная телеметрия. Уличные фонари включаются, водосчетчики
данные скидывают, датчики разные на этой херне по всему УКВ трещат.
Отказать!


Так если там AX25 и TCP/IP гоняют, то значит и фидо можно



С наилучшими пожеланиями, Sergey Anohin.

Re: ФИДО через УКВ

Hello, Sergey!



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



Интересно про Mesh

https://nootropicdesign.com/pr... 

это уже не звезда

С наилучшими пожеланиями, Sergey Anohin.