Я пять лет разрабатываю техническую документацию. Всё это время руководящими документами были и ГОСТы групп 2, 7, 19 и 34, и разная экзотика вроде приказа Минпромторга № 4091 от 15.12.2015. Руководящие документы облегчают жизнь, сводя необходимость думать к размышлению о содержимом документа, а уж структуру и оформление диктует стандарт. Однако есть и сложности. Следуя стандартам, получишь стандартный документ, однако стандартный не значит удобный для чтения и исчерпывающе полный. Средства разработки документации — обычно это текстовые процессоры из офисных пакетов — требуют большой подготовительной работы по наруливанию стилей и организации рамок, чтобы привести результат работы к стандартному виду. Если же подготовкой пренебречь, через полсотни страниц документ станет технически неуправляемым. Наконец, прохладное отношение разработчиков к документации приводит к тому, что её разрабатывают или по остаточному принципу, или так, чтобы принял заказчик. Заказчик же в первую очередь ориентируется на критерии нормоконтроля, отнюдь не задумываясь о мере, в какой документ пригоден для чтения и понимания людьми.
Итог не обнадёживает. Значительная часть работы состоит из борьбы с условным Вордом, особенно если над документом работают несколько людей. Документы в результате получаются формально правильные, но часто не в мире читателя. У технического писателя остаётся ощущение, что он делает бесполезную работу.
Представился случай разработать технический документ на основе ценностей, противоположных перечисленным выше. Об этой работе и пойдёт речь.
Понять задачу
Задача была поставлена предельно просто: написать руководство пользователя для андроидного приложения HF Pager. Вскоре после начала переговоров решено было сделать бумажное руководство.
Руководство пользователя для андроидного приложения само по себе невероятная редкость — я сходу не смог вспомнить ни одного примера, тем более на бумаге. Затея сделать печатное руководство пользователя приложения на смартфоне нетривиальна, однако здравое зерно в этом есть. Бумажная документация не требует энергии и интернета, может быть продана как материальный предмет или предъявлена окологосударственным пользователям. Наконец, при должном подходе к печати бумажная документация солидно выглядит. Как бы ни была изготовлена документация, главная её задача — уменьшить нагрузку на хелпдеск. С этим соображением я и подошёл к делу.
Годное руководство пользователя — это ясная структура и необходимая достаточная полнота изложения.
Структуру рационально строить исходя из того, что любое содержимое руководства пользователя представляет собой либо решение задачи (таск), либо справочную информацию (референс), либо условно факультативные сведения для понимания происходящего под капотом (концепт).
Таск — отвечает на вопрос «Как сделать?». Чтобы заполнить этот раздел, нужно выписать себе список возможных задач пользователя, потом отранжировать разумным способом, а дальше при помощи чувства прекрасного оформить в пункты руководства. Список задач пользователя сложности не представляет: задачи — внешние по отношению к объекту документирования, и существуют в терминах действий пользователя. Залезть в меню — это не задача, а вот передать сообщение — задача. Ранжирование задач тоже несложно: в случаях вроде моего годится хронологический порядок возникновения задач по ходу эксплуатации.
Референс — отвечает на вопрос «Что это такое?». Подход схожий: выписать сущности, каждую пояснить, и ни слова сверх того. Порядок изложения сущностей — хронологический, от общего к частному, от очевидного к неочевидному, сверху вниз слева направо. В этой работе самое сложное — каждый раз вовремя остановиться. В моём случае референс состоит из двух уровней. На уровне оперативной справки для быстрого знакомства — картинки с основным экраном приложения с минимумом пояснений. Уровень детальной справки посвящён меню. Референс по меню написан преимущественно текстом, структура описания пунктов меню везде одинаковая: что это такое → что делает → значение по умолчанию. В отдельных местах я счёл целесообразным добавить ремарки в виде единообразно оформленных замечаний («Не трогай тут ничего») или советов («Прикрути фитиль, если по умолчанию слишком ярко»). Оформление придумал сам и вынес в раздел типографских соглашений, где ему и место.
Концепт — на вопросы не отвечает. Задача концепта — научить, показать общую картину, углубить понимание действий с объектом документирования. В моём случае этот раздел начался с малого, наполнялся постепенно, и в итоге превратился в самый объёмный по количеству текста. Сформулировать этот текст, и отбросить из него всё ненужное, тоже оказалось сложнее всего.
Информацию я решил сгруппировать по классам: после вводной информации дать решения типовых задач пользователя, потом справку по интерфейсу, а потом отдельно всё, что относится к концепту. Логика в этом решении следующая: приложение по умолчанию настроено достаточно правильно, чтобы сразу начать работать с ним, поэтому в справку по интерфейсу пользователь пойдёт только если что-то будет непонятно, а в раздел с концептами — из любопытства. Стало быть, что нужнее, то и ближе к началу.
Когда был готов проект большого руководства, внезапно оказалось, что нужно ещё одно, маленькое — quick start guide, руководство по быстрому старту, или просто РБС. Дело в том, что приложение предназначено для эксплуатации в полевых условиях без интернета, поэтому нужна шпаргалка по приложению, чтобы носить при себе. Требования к РБС те же, что и к руководству пользователя — ясная структура и полнота изложения. Из условий эксплуатации РБС следует ещё эргономические требования. На эргономике позже остановимся подробнее.
Структура РБС затруднений не вызвала: в РБС входит лишь то, что пригодится в полевых условиях. Поскольку задачи условно делятся на рабочие и служебные, оставить нужно только рабочие. Референс — на минималках, концепт не нужен. В итоге из руководства пользователя в РБС остались только три задачи, императивная справка по настройке, краткая справка по устранению неисправностей, и два чеклиста: один перед выходом на маршрут, другой — перед сеансом связи. Переиспользование контента наше всё, поэтому решения задач переехали в РБС без изменений, а вот справки и чеклисты я написал «с нуля».
Технология
Выбор средства производства «документа, содержащего в основном сплошной текст», не самоочевиден. Исходные предпосылки выбора таковы:
документ предназначен для печати, но потом может потребоваться электронная версия;
подход doc as a code по сравнению с традиционным более громоздкий, но облегчает переиспользование контента;
работать придётся с текстом и картинками, притом много и гибко;
на сказанное в ГОСТ 19 ориентироваться не надо;
Микрософт Ворд для серьёзной и тонкой работы с текстом неудобен, его аналоги тоже.
Поэтому на роль средств производства я выбрал VS Code для текста, Adobe Illustrator для картинок, и Adobe InDesign для создания непосредственно документа. Применять именно этот софт не обязательно: другие текстовый блокнот, векторный редактор и DTP-система способны решить ту же самую задачу. Текстовый блокнот, в отличие от текстового процессора, легко интегрируется с системой контроля версий — со вытекающими из этого удобствами работы с текстом. Необходимость векторного редактора для технической иллюстрации в пояснениях не нуждается. Для оформления текста в документ DTP-система лучше условного Ворда настолько же, насколько для резьбы по дереву стамеска и нож лучше чем топор-колун.
Отдельно поясню про формат текста: я выбрал обыкновенный неформатированный текст, а не маркдаун или ReST. Выбор формата в таком деле всегда компромисс: простой текст проще писать и читать, но сложнее конвертировать и переиспользовать автоматически, обратное тоже справедливо. В моём случае ключевым фактором стало взаимодействие с Индизайном: простой текст просто вставляется в текстовый фрейм прямо из буфера обмена. Это не лучший способ: можно было прилинковать текст к фрейму, и тогда бы макет автоматически обновлялся при правках текста. На больших документах лучше так и поступать, на небольших — можно обойтись и копипастой.
Индизайн прекрасен, но есть нюанс
Обратная сторона гибкости DTP — сравнительно трудоёмкое обновление документа в тот момент, когда от заказчика работ приедут серьёзные правки в текст. В этот раз правки приехали уже на этапе окончания вёрстки, и немедленно оказалось, что добавить короткий раздел в самое начало свёрстанной страницы нельзя, если не перебрать вручную вообще всё до следующего раздела. Конечно, есть прекрасные средства автоматизированной подготовки документации, умеющие в CI без участия оператора ЭВМ, но прежде уже было решено не оглядываться на ГОСТ 19, поэтому закат солнца каждый раз пришлось делать вручную.
Избежать этого не представляется возможным. Не получится сделать как в газете — волевым решением зафиксировать текст до вёрстки и потом не принимать никакие правки кроме исправлений опечаток и ошибок. В газете этот подход работает за счёт того, что тексты перед вёрсткой вычитывают сам журналист, выпускающий редактор, ответственный секретарь, корректор, и иногда ещё главный редактор. Поэтому в газетную вёрстку попадает текст заведомо вычитанный и согласованный. Для фрилансера этот путь не слишком надёжен: в переговорах с заказчиком на тему фиксации текста исполнитель явно не с той стороны ружья. Правильно воспринимать такие ситуации помогает знание о том, что покупают не текст, и даже не документ, а его полезное действие. Технически проблема решается так: можно оставлять на странице заделы под расширение, новые тезисы начинать с новой страницы, а новый раздел всегда с правой полосы. В крайнем случае помогает тонкий тюнинг текста как массива символов: в отличие от текстового процессора, нормальная DTP-система это умеет.
Инструкция по оригами
Выше я отметил, что РБС физически представляет собой лист бумаги, защищённый ламинацией или пластиковым пакетом, и свёрнутый дважды пополам так, чтобы получалось 4 маленьких страницы для информации первоочередной важности, и на обороте ещё столько же для относительно второстепенных сведений. Изобразить это в Индизайне не составило труда: фреймы с текстом легко поворачиваются на нужный угол. Чтобы разобраться с ориентацией фреймов на листе, согнул из листа бумаги макет.
Затруднения предсказуемо обнаружились сразу: первое же тестирование РБС на добровольцах показало, что они не понимают, как его правильно сложить. Неправильно сложенный лист катастрофически неудобен в использовании.
Разумеется, я с самого начала предусмотрел две линии сгиба и две стрелки с номерами, и конечно же, это не помогло. Стрелки оказались непонятны никому, а нарисованные линии сгиба не совпали с фактическими, поскольку принтеры обычно печатают немного криво.
Пришлось искать другое решение. Для этого сформулировал критерии хорошей инструкции по оригами:
настолько однозначная, насколько возможно;
визуально заметная, но не бросается в глаза при дальнейшем использовании документа;
предельно короткая;
скорее длинная, чем широкая (высокая), поскольку на линию сгиба заложено всего 10 миллиметров;
императивно обращается к пользователю так же, как остальной документ, или вовсе не обращается.
Окончательное решение придумал с четвёртой попытки, остановившись на серых надписях жирным серым моноширинным шрифтом: «линия первого сгиба этой стороной внутрь», «линия второго сгиба — на противоположной стороне листа», «линия второго сгиба этой стороной внутрь». Существительные выглядят менее навязчиво, чем глаголы; моноширинный шрифт подчёркивает специальное предназначение надписи и несколько купирует эффект близости, благодаря которому объекты, расположенные ближе друг к другу, выглядят сильнее взаимосвязанными.
Вероятно, идеальное решение — организационное: централизованно отпечатать и согнуть как надо.
Нам всем мешает знание
Техническая документация подразумевает баланс между тем, что в ней есть, и тем, чего в ней нет, и удержаться в балансе ещё нужно суметь. Если недописать нужного, документация не принесёт пользы, итогом чего станет вал однотипных вопросов к хелпдеску, а у заказчика появится справедливое недоумение по поводу уплаченных за документацию денег. Если же переписать лишнего, то можно в лучшем случае нарваться на необходимость поддержки чужих продуктов, а в худшем — хелпдеск будет отдуваться не только за софт, но и за документацию.
Описать сбалансированно таск или референс относительно несложно: таск — о том, что пользователь делает; референс — о том, что пользователь видит и нажимает. В обоих случаях абсолютно необходимый объём изложения и есть достаточный. Иначе дело обстоит с концептами: они посвящены тому, что пользователь не знает.
Это ключевой момент: когда для автора всё понятно, как автору понять, что не знает пользователь? По логике™ — спросить об этом у самого пользователя, а ещё вернее, сделать так, чтобы пользователь сам об этом рассказал. Сам пользователь рассказывает исключительно хелпдеску или тому, кто за него — например, знание о незнании я почерпнул в чате сообщества пользователей приложения.
Так в разделе концептов появились четыре темы: объёмная «Организация радиосвязи», сложная и абстрактная «Однополосная модуляция», лёгкая «Выбор скорости манипуляции», и просто справочная «Использование маяка». Написать о том, как я решил задачу изложения этих тем, мне тоже мешает знание: я их просто взял и изложил. На это, однако, было израсходовано 2 дня времени и 6,5 тысяч знаков текста в тысяче слов, основной труд состоял в постоянном отвечании на заданный самому себе вопрос «Что реально надо знать пользователю об этом?»
Ответ лежит на поверхности: пользователю необходимо и достаточно знать то, что он сам спрашивал себе в помощь. Тут мне повезло: я несколько лет участвовал в переписке по работе приложения, и уже знал, что именно пользователь часто спрашивает. Поэтому, например, раздел «Однополосная модуляция» почти полностью посвящён вычислению в уме фактической частоты поднесущей.
Для незнакомых с радиотехникой поясню: это как если рассказ о Налоговом кодексе РФ свести к пояснению, как считать сумму к начислению заработной платы по величине выплаты «на руки».
Тему «Однополосная модуляция» лучше было бы пояснить картинкой. Так и предполагалось сделать, но возникла проблема: то главное, что нужно знать об однополосной модуляции пользователю приложения, оказалось очень сложно изобразить на неподвижной картинке так, чтобы читатель точно всё понял.
Усилием воли пришлось признать самому и убедить заказчика, что популярные в радиотехнической литературе картинки со спектрами для совсем неподготовленного читателя не годятся, и ничего не поясняют. Признать общепринятую иллюстрацию негодной требует смелости и умения в рефлексию. И таки да, это тот случай, когда знание мешает.
Можно было бы потратить пару дней на творческий поиск, и картинку в итоге сделать. Однако время поиска стоит заказчику денег, а вкладывать их в явно факультативный материал не слишком разумно. Поэтому картинку отложили на период гарантийной поддержки документа: за время гарантии можно в спокойном темпе придумать и протестировать на пользователях иллюстрацию, которая будет работать как следует.
Важные мелочи
Я сдержанно отношусь к ГОСТам, посвящённым документации, но эти стандарты избавляют от размышлений о том, как писать документ. Поэтому, отказавшись от следования государственным стандартам, пришлось придумать свой частный стандарт, и следовать уже ему. Формально я стандарт записывать не стал, но в голове сформулировал, что он регулирует:
— структуру документа;
— язык и стиль;
— логику оформления;
— общий подход к подготовке иллюстраций.
То есть, в принципе, всё то же самое, что ГОСТы 19.106 и 19.505, но с человеческим лицом.
Одной структурой в техническом документе не обойтись, нужна ещё навигация. Для навигации по документу использованы колонтитулы и оглавление с нумерацией страниц, а для навигации по странице — типографика. Колонтитулы не повторяют заголовки, и названы обобщённо по тому, какого рода материалы под собой они объединяют. Перекрёстные ссылки, в том числе на рисунки, также ссылаются просто на номера страниц. Это стало возможным благодаря тому, что каждый рисунок, на который в документе есть ссылка, на странице ровно один. Остальные рисунки расположены по принципу близости к абзацам, в которых они упоминаются, поэтому удалось приемлемо обойтись без подрисуночных подписей с нумерацией рисунков. Абсолютное большинство рисунков без подписи собрано в разделе справки по интерфейсу, и ссылаться на такие рисунки не нужно.
Типографские соглашения также основаны на визуальном восприятии. Жирное начертание выделяет текст, требующий первоочередного внимания. Курсивное начертание визуально прозрачнее прямого, поэтому курсивом обозначены факультативные советы, нужные для более связного понимания написанного. Также советы и примечания обозначены буллитом, сделанным из логотипа приложения. Отдельные примечания даны сносками. Сноски выглядят совсем ненавязчиво, хотя и появились скорее потому, что добавить их в готовую вёрстку ничего не стоит — перевёрстывать страницу не нужно, а текст в сноске умещается довольно длинный. Сноски как разновидность примечаний в руководстве пользователя стилистически избыточны, однако в моём случае удалось соблюсти некоторую консистентность: в отличие от императивных советов, сноски просто что-то поясняют.
В нижний колонтитул руководства пользователя, кроме номера страницы, влезла ещё строка с номерами версий документа и приложения. Оба номера важны, поскольку документация обновляется отдельно от приложения. В РБС нумерация страниц не нужна, и строка с номерами версий расположилась там, где для неё нашлось место. Стили оформления РБС и руководства пользователя не идентичны, поскольку условия чтения РБС отличаются от условий чтения руководства пользователя.
Тестирование документации и обратная связь
Документация — такой же продукт, как и то, что она документирует, поэтому тоже подлежит тестированию. В моём случае тестирование прошло прямо на пользователях: РБС и руководство пользователя заказчик зарелизил прямо в чате поддержки приложения, и через полчаса туда посыпались отзывы. Большинство — с благодарностями, но нашлись также энтузиасты, высказавшие по существу. Один из них вовсе написал целый протокол разногласий объёмом 5 страниц. Несмотря на то, что критика почти не повлияла на содержимое документов, руководство пользователя обновилось три раза. В документах нашлись помарки: например, я неправильно настроил форматирование перекрёстных ссылок, из-за чего образовались лишние слова, и вёрстка расползлась. Ещё пришлось изменить отдельные формулировки: в одних уточнили смысл, в других улучшили читаемость.
Значительная доля замечаний коснулась достаточной полноты изложения. В чате приложения неделю кипел такой обмен мнениями в таком духе:
Почему бы не написать, какие разрешения дать приложению?
Потому что точный список необходимых разрешений меняется с каждым новым Андроидом, а перечислять и даже просто узнать конкретные разрешения нет ни смысла, ни возможности. Надо просто дать все запрошенные разрешения.
А почему не сказано, что надо включить режим VOX на радиостанции?
Потому что есть радиостанции без этого режима, а сопряжение смартфона с радиостанцией зависит от модели и смартфона, и радиостанции.
Почему нет раздела о настройке однополосной модуляции?
Потому что область определения руководства пользователя — приложение, а не сопряжённая с ним радиостанция.
А перенесите раздел «Ограничения демо-версии» в раздел «Регистрация приложения»?
Нет, потому что регистрация — обязательная операция для всех, а вот ограничения демо-версии — информация справочная, и нужна она только тем, у кого демо-версия есть, а это вообще отдельное приложение.
Добавьте, что в однополосной модуляции принято работать верхней боковой полосой в цифровых режимах?
Нет, потому что у нас не руководство по радиосвязи.
Может показаться, что пользователей послали. На самом деле это не так. Область определения документа, структура и достаточная полнота содержания — это то, что ограничивает документ в интересах пользователя. Если его запросы выходят за пределы области определения, значит, нужно просто написать ещё один документ.
Замечания к тексту разделились на два класса: замечания к структуре и содержанию, и замечания к формулировкам. Различаются эти классы тем, что замечания к формулировкам изменяют смысл сказанного, а замечания к структуре и содержанию — смысл дополняют, но не изменяют. Замечания к структуре и содержанию объясняет желание пользователей увидеть всеобъемлющее руководство по радиосвязи с помощью приложения. Такие замечания интересны для понимания того, как пользователи мыслят и читают, но переносить их в документацию надо с осторожностью, иначе в попытке объять необъятное легко получить неподдерживаемую спагетти-структуру. А вот замечания к формулировкам ценны: если пользователь формулировку не понял, или понял неправильно — это проблема документации, которую нужно выявить и исправить. Радикально исправлять формулировки мне не пришлось, но три из них по предложениям пользователей я уточнил.
Резюме
Стандарты рулят. Использовать или не использовать ГОСТ — зависит от ситуации. Если необходимости неукоснительно соблюдать ГОСТ нет, то неплохим решением будет разработать свой стандарт оформления и структуры, или использовать любой готовый понравившийся стайлгайд. Дизайнером для этого быть не обязательно: достаточно ознакомиться с фундаментальными принципами из книги «Дизайн для недизайнеров» Робин Уильямс, а для самого начала можно взять за образец даже стили по умолчанию в Ворде.
Независимо от используемого стандарта важна структура и документа, и повествования, притом единообразие структуры важнее её устройства. Утверждение это может показаться банальным, но проблемы со структурой случаются чаще, чем хотелось бы.
Техпроцесс с раздельными подготовкой и оформлением текста показал себя целесообразным и оправданным при создании печатного документа. Текст потом легко будет перенести в электронную справку, его удобно хранить на гите, и вообще разделение контента и оформления — затея правильная.
Обратная связь и тестирование документации тем важнее, чем шире круг пользователей, и чем меньше команда, силами которой можно выявить проблемы до релиза. Мой случай почти экстремальный: один разработчик, один заказчик, один писатель, и пользователи самых внезапных уровней квалификации. В идеальном случае документацию на пользователях тестировать не следует, но собирать у них отзывы о документации полезно: так можно понять, какой информации пользователям не хватает, и в каком документе её можно изложить.
Постскриптум. Цена вопроса
Исследование софта заняло 20 часов: скачать, установить, зарегистрировать, проверить все режимы работы, найти ограничения, всё непонятное — выпытать у разработчика. Картинки заняли 10 часов: скриншоты сделать, недостающее отрисовать и поправить столько раз, сколько потребуется. Буллит для выделения комментариев, например, удался с четвёртой итерации. Два осмысленных и проверенных текста общим объёмом 28 тысяч знаков заняли 40 часов. Вёрстка — 15 часов. Правки, шлифовка, полировка, и шабрение текста — в совокупности ещё 20 часов. Итого 105 часов учтённого рабочего времени, и какое-то количество неучтённого.
Работа над этим руководством не завершена окончательно: до конца 2023 года продолжается гарантийный срок, по мере обновления приложения придётся обновлять и документацию. Это будет уже другая история.
Комментарии (69)
ewgenc
26.11.2023 07:52-2Очень интересно, где и и зачем применять такое сочетание устройств как смартфон и УКВ радиостанция.
alexsavochkin Автор
26.11.2023 07:52По задумке (и практике) полезно применять в профессиональной связи, например, на диапазоне Low Band (в районе 40 МГц) в лесу. Смысл в том, что так делается цифровая надстройка над аналоговой радиостанцией, и можно не голосом докладывать, а текстовыми сообщениями. Или вообще присылать координаты, которые не надо надиктовывать и записывать. Ещё таким образом можно оценивать зоны радиовидимости по маршруту при помощи маяка.
ewgenc
26.11.2023 07:52Понятно, так и предполагал. В профессиональной радиосвязи встречал только промышленные модемы для КВ/УКВ.
alexsavochkin Автор
26.11.2023 07:52Ну это не совсем про модем. Это решение для повышения надёжности и функциональности системы связи.
uuger
26.11.2023 07:52по сути, это радиолюбительская игрушка, к которой "Радиал" пытается приклеить бОльший смысл, чем туда можно заложить
alexsavochkin Автор
26.11.2023 07:52Как раз не радиолюбительская. Задумывалось всё для туристической радиосвязи, потом разрослось до современного состояния. Многие решения спорные (потому и документация потребовалась), но уж чего в пейджере точно нет — это радиолюбительства.
uuger
26.11.2023 07:52на основании какой лицензии физ.лицо может проводить радиосвязи на КВ?
alexsavochkin Автор
26.11.2023 07:52Частоту вполне можно и купить, опыт есть. Делается это сравнительно несложно, и стоит вполне доступных денег. Другое дело, что для работы на территории всей страны частоту почти не купить — но условному оленеводческому совхозу и не надо на такой большой территории, хватит и зоны с радиусом 300-500 километров вокруг точки. Не помню, может ли именно физлицо купить частоту (надо спрашивать), но ИП точно может — а он и есть физлицо. Так что любителем быть не обязательно.
Ну и если на то пошло, для любительской связи пейджер ну прямо вот очень неудобен.
uuger
26.11.2023 07:52у вас есть опыт получения лицензии именно на КВ? На нижний диапазон, где доступны NVIS связи? Сколько это стоило, если не секрет?
alexsavochkin Автор
26.11.2023 07:52У меня лично — нет, но я знаю тех, кто получал. Стоило порядка десятков тысяч рублей. Точнее вспомнить пока не смог, но узнаю — скажу. Помню, что деньги там были какие-то не запредельные.
alexsavochkin Автор
26.11.2023 07:52Узнал. Порядка 26 тысяч разовых вложений и потом 700 рублей в год за одну частоту.
uuger
26.11.2023 07:52на какой частоте?
alexsavochkin Автор
26.11.2023 07:52А вот это надо с РКН договариваться. На нижнем КВ вполне реально договориться, примеры тому есть.
uuger
26.11.2023 07:52+1Приведите, пожалуйста, конкретный пример выделенной частоты ИП/физлицу в NVIS участке КВ диапазона
alexsavochkin Автор
26.11.2023 07:52Спросите лучше здесь. Там точно есть люди, причастные к покупке/аренде.
uuger
26.11.2023 07:52+1Интересный способ уйти от ответа. Давайте вернёмся к началу разговора - я выдвинул тезис, что, несмотря на то, что фирма "Радиал" позиционирует "КВ пейджер" как программный комплекс, которым будут пользоваться в условном лесу, по факту это будет игрушка для радиолюбителей. Очень хочется получить не ссылку на РКН или телеграмм чат, а хоть какой-то документ, который подтвердит наличие юридической возможности пользоваться этой технологией физлицами и малыми/индивидуальными предпринимателями.
alexsavochkin Автор
26.11.2023 07:52Комментарием ниже я приложил ссылку на сайт РКН, в котором описан порядок присвоения (назначения) радиочастот или радиочастотных каналов. Это — документ, он подтверждает наличие юридической возможности пользоваться любой радиосвязью физлицами на той частоте, которую они смогут себе организовать.
alexsavochkin Автор
26.11.2023 07:52Ну и кстати, ничто не препятствует работать и с любительской лицензией, просто будут известные неудобства.
SergeiPod
26.11.2023 07:52Почему уйти? Там Слодкевич (гендир Радиала) вам от первого лица ответит, сколько и каких частот он зарегистрировал в Карелии. Насколько я помню, у него несколько номиналов между 1.7 и 4.0 МГц. Но я помню неточно :-)
BurgerDnja
26.11.2023 07:52Тестовая радиосеть вне РЛ диапазона действует в Карелии, р-н Костомукша. Подробнее см. на сайте, там же можно связаться с владельцем и договориться о тестировании.
https://radio-telegraph.ru/?page_id=29
uuger
26.11.2023 07:52радиосеть вне РЛ диапазона
Я вижу по ссылке 9 шлюзов, из них 7 - РЛ диапазон (7175 и 3745 кГц) и 2 шлюза самого "радиала" (некие 38ХХ и 48ХХ)
BurgerDnja
26.11.2023 07:52да, это именно оно (и лично я не знаю набора частот в Карелии, когда-если соберусь туда, свяжусь с Е.Я.Слодкевичем и получу инструкции, как работать голосом/пейджером). Обратите внимание, что 4800+ КГц уже близко не радиолюбительский диапазон, 62+ метра.
Если Вас интересует эта тема - свяжитесь с Евгением Яковлевичем лично и задайте вопрос. Есть статьи на сайте КВП и на youtube канале Радиала есть видео об использовании этой радиосети.
alexsavochkin Автор
26.11.2023 07:52
QDeathNick
26.11.2023 07:52Странно, что минусы наставили на этот вполне резонный вопрос.
Как я себе вижу такое сочетание можно применять там, где нет сотовой связи, голос по радиосвязи уже не слышно, а передать сообщение хочется. В основном это используют на КВ, но можно и на СиБи.
alexsavochkin Автор
26.11.2023 07:52Да, на Си-Би тоже можно. Когда я писал документацию, с некоторым удивлением узнал, что довольно многие именно так и пользуются, даже в ЧМ.
checkpoint
26.11.2023 07:52Просьба к разработчикам: сделайте пожалуйста поддержку FBBS c чтением ньюсов и личной почты. Я провозился некоторое время с этой темой в поисках решения для местного МЧС и радиолюбителей и на мой взгляд FBBS это то что нужно. Вот только удобного мобильного фронтенда к ней не завезли, а пожарной бригаде в лесу топтать команды FBBS в tenet-е просто некогда.
Идея была следующая. На пожарной машине (или на машине радиолюбителя выехавшего "в лес на прогулку") устанавливается RPi4 подключенная к возимой КВ или УКВ радиостанции. На нём поднимается FBBS которая обслужает бигаду - получает от них сообщения через мобильного клиента (по WiFi, у FBBS есть фича - оно может работать и по TCP соединению) и пакетом отправляет "по маршруту". И наоборот, принимает сообщения из эфира для бригады и отдает мобильным клиентам.
alexsavochkin Автор
26.11.2023 07:52А шлюзы в почту и телеграм — не подходят? Они уже реализованы.
checkpoint
26.11.2023 07:52Какой телеграм, какая почта ? В лесу нет связи кроме КВ и УКВ.
alexsavochkin Автор
26.11.2023 07:52Если решается задача диспетчеризации ПСР, диспетчера вполне можно пересадить в то место, где связь и интернет есть. При наличии помехоустойчивого канала не обязательно тащить всю инфраструктуру в лес. Пробрасывать веб-интерфейс мобильным отрядам тоже не обязательно, если мы отталкиваемся от инфраструктуры Пейджера.
checkpoint
26.11.2023 07:52Решается задача оперативной двустронней пейджинговой связи бригады с диспетчером (и между бригадами) в условиях когда никакой связи нет вообще. Никакой инфраструктуры в лес не тащится. В лесу (на машине) устанавливается FBBS для того, чтобы пожарные не заморачивались с ожиданием отправки и получения подтверждений своим сообщениям. Более того, каждому пожарному на спину не повесишь КВ радиостанцию с антенной на 14 метров, а на машину такой сетап устанавливается без проблем. Пожарные используя свои мобильники подключаются по WiFi к этой FBBS и с помощью мобильного клиента сгружают сообщения на неё, а она далее работает пакетом (FX.25) с базой/диспетчером и/или другими бригадами по КВ/УКВ радио. Скорость передачи по FX.25 в лучшем случае 1200 бод, IP поверх такого канала возможен, но совершенно не пригоден для ипользования. FBBS сообщения агрегирует и сжимает, после чего отправляет "по маршруту". Если Вы застали эпоху Fidonet или UUCP, то вопросов быть не должно.
alexsavochkin Автор
26.11.2023 07:52В этой затее я лично места для КВПейджера вообще не вижу, если только как транспорт для FBBS — но если по FX.25 всё работает, зачем там КВПейджер?
m_a_x_i_m
26.11.2023 07:52но если по FX.25 всё работает, зачем там КВПейджер?
Рискну процитировать самый верхний комментарий:
"Связать приложения умеющие общаться по tcp/ip по радиоканалу, используя радиостанцию как радиомодем, затруднительно из-за задержек".
AX.25 со присными - транспорт для ip, вернее для tcp/ip. tcp/ip плохо работает при тех задержках которые дает радиоканал. О чем вам и пытается сказать @checkpoint
Тут дело даже не в скорости - дело в задержках.
Это именно то, почему я буду очень рад увидеть в hfpager функциональность socks proxy сервера. Ибо, возвращаясь снова к самому верхнему комментарию: "Если использовать канал между двумя рациями как модем (физический уровень модели osi), поверх которого будут гулять канальный, сетевой, транспортный ... из-за задержек нельзя, то можно подняться выше по модели osi. И ближайшее подходящее - socks proxy".
Как-то так.
alexsavochkin Автор
26.11.2023 07:52Тут дело даже не в скорости - дело в задержках.
Вот насколько я знаком с TCP/IP (а я хорошо знаком), задержки — это всегда проблема прикладного уровня. Я сам жил какое-то время с GPRS и пингами по паре секунд, и не скажу, что это прямо вот очень сильно мешало эксплуатировать TCP/IP.
"Если использовать канал между двумя рациями как модем (физический уровень модели osi), поверх которого будут гулять канальный, сетевой, транспортный ... из-за задержек нельзя, то можно подняться выше по модели osi. И ближайшее подходящее - socks proxy".
Ну если приложение готово подождать ответ от сокс-прокси минут десять, то и слава богу. Убеждать в необходимости реализации сокс-прокси меня полностью бесполезно, я разработчик документации, а не продукта.
m_a_x_i_m
26.11.2023 07:52Да я понимаю, что вы хотели про документацию поговорить, а мы вас замучили всякой ерундой.
Я не так хорошо знаком с tcp/ip, но насколько я в курсе, дело в дело в параметрах ядра линукса определяющих таймауты при установке tcp соединения. И в частности, в значениях этих таймаутов установленных в андроиде. Переключение радиостанции с приема на передачу в некоторых случаях может превышать эти значения. Во всяком случае так мне объяснили уверенные пользователи tcp/ip которые пытались поднять ip трафик на таком радиоканале, но не смогли.
alexsavochkin Автор
26.11.2023 07:52Не то что замучили ерундой, я подобные обсуждения уже несколько лет наблюдаю в предметном чатике. Однако я ожидал несколько иного направления дискуссии в комментариях. :)
Честно говоря, не вижу нужды вообще отталкиваться от реализации TCP/IP в андроиде, поскольку по этому стеку если и имеет смысл общаться, то между приложениями на общем железе. А вот "модем" я бы проектировал исключительно как источник данных вроде почтового сервера: пользовательское приложение постучалось с вопросом "Есть чё?", "модем" ответил, проглотил от приложения запрос в сеть, и в своём темпе по своему же протоколу и отправил. То есть городить заведомо асинхронный обмен данными внутри смартфона и между ними.
m_a_x_i_m
26.11.2023 07:52Я не уверен, что понял правильно вашу мысль, но по моему то, что вы написали, и есть socks proxy сервер...
m_a_x_i_m
26.11.2023 07:52Это конечно если эту вашу FBBS можно научить работать через прокси. Если нет - се ля ви - пишите для нее специальный шлюз или ковыряйте эту FBBS чтоб прикрутить к ней работу через прокси. Но есть большое число программ которые через прокси работать таки могут искаропки и для них всех это будет решением. Поскольку сами понимаете, на каждую всякую FBBS, и иже с ними, отдельный шлюз писать не вариант. А много кому эта его FBBS вот прям до зарезу нужна и у каждого она разная и все страждущие даже не знают как вам об этом сказать... Вот случайно вы на хабре засветились и к вам сразу хлынул поток с одной и той же просьбой. Это жжжж неспроста! Была бы в вашем пейджере галочка "включить socks proxy сервер" вы бы могли каждому жаждущему поюзать его архинужную FBBS ткнуть в документацию где красиво нарисовано как правильно на эту галочку тыкать чтоб стало сразу СЧАСТЬЕ.
Извините за некий сумбур, я надеюсь вы поняли что я пытался сказать. :-)
alexsavochkin Автор
26.11.2023 07:52Примерно понял, что вы пытались сказать. :)
Если в приложении нет такой функциональности, упоминания её в документации тоже не будет. Я, к сожалению, ненадлежащий собеседник для переговоров о функциональности. Словами передать могу (кстати, разработчик тут засветился тоже и вроде комментарии читает), а вот будет это кто-то руками реализовывать или нет — я не в курсе.
checkpoint
26.11.2023 07:52Нужен фронтэнд (клиент) к FBBS для Андроида. По сути это и будет "КВ Пейджер", только транспортировкой данных будет заниматься не мобильник пользователя, а FBBS, незаметно для пользователя (для нескольких десятков пользователей на самом деле). Клиенты общаются с FBBS по локальному WiFi по TCP соединению (telnet) набором текстовых команд. Пользователю же клиент представляется как набор папок с тематическими переписками + личная почта + разные другие фичи, в том числе геолокация (эдакий Телеграм). Я пробовал даже небольшие фотографии отсылать, JPEG до 50кб пролазит нормально, но много ретранзмитов и долго (FBBS все это берет на себя). Проблема в том, что общаться с FBBS телнетом могут не только лишь все и по этой причине вся затея сдулась.
И еще. В APRS по сей день используется AX.25, в котором не предусматривается коррекция ошибок. Это жуткая беда на КВ. Почему не пошло внедрение FX.25 я не понимаю. К тому же FX.25 совместим вниз с AX.25.
BurgerDnja
26.11.2023 07:52Собственно, идея КВП + шлюз (на "большой земле", с доступом в Инет) это и есть основная вкуснятина. Второй, важнейший момент - относительная простота интерфейса и незамысловатость сетапа (устройств, антенного хозйства, смартфона) для использования данного способа не упертыми радиолюбителями (которые досконально раскопают и освоят любой метод, просто по приколу), а самыми обычными людьми, имеющими необходимость организовать связь в ненаселенке, и получившими ради этого третью категорию. Ибо - закон есть закон.
uuger
26.11.2023 07:52Если хочется в такое поиграться, то winlink в помощь. Но, вообще, конечно, это всё то ещё препперство
checkpoint
26.11.2023 07:52К сожалению, winlink проприетарный продукт построенный на деньги правительста США. Для нормальной работы winlink требуется проприетарный модем. Можно конечно и через звуковую карту, но будет доступно ограниченное количество протоколов с очень низкой помехозащищенностью. Нужен свой аналог, на открытых протоколах.
BurgerDnja
26.11.2023 07:52чуть выше написал: заслуга проекта КВП (имхо) простота интерфейса и сетапов, доступная любому пожарному или леснику. Без иронии в адрес последних, и с крайним уважением к их работе.
checkpoint
26.11.2023 07:52Проблема КВП в том виде как это представляется у автора статьи состоит в том, что к мобильнику будет подключена куча проводов, будет занят аудио интерфейс радиостанцией, что делает сам мобильник непригодным к использованию для основных целей (я уже не говорю, что процесс fine tuning-а всего этого сетапа весьма не прост). Такой сетап пожарных и лесников категорически не устраивает! Моя идея состоит в том, что бы радиопередающую часть вынести и оставить в "пожарной машине", а леснику или пожарному оставить мобильник с приложением и без проводов. Т.е. у лесника есть возимая радиостанция, с хорошей антенной, установленная на автомобиле, рядом с ней смонтирована коробочка с RPi4 и всё! Он берете свой мобильник, подключается к RPi4 по WiFi, запускает андроидного клиента и шлет/принимает корреспонденцию. Он даже может находиться на некотором расстоянии от машины, в пределах видимости WiFi (150-200 метров если WiFi антенну поднять на крышу машины). Все это относится и к радиолюбителям, которые часто выезжают на природу поработать в эфире с редких мест.
alexsavochkin Автор
26.11.2023 07:52Будем объективны: автор статьи про пейджер вообще ни слова не сказал за исключением того, что писал к нему руководство пользователя. ;)
В основном сценарии использования пейджера мобильник — это просто карманная ЭВМ, поскольку в основном сценарии предполагается, что никакой сотовой связи на точке нет.
То, что вы сейчас описываете — в сущности, тот же шлюз. Как его реализовать — вопрос не ко мне, увы. С этим надо идти в чат приложения, там сидит разработчик, с ним обо всём можно договориться. Собственно, большинство кастомных шлюзов как раз самописные.
checkpoint
26.11.2023 07:52Да, прошу прощения за оффтоп, сбился с темы. Дело в том, что я совсем недавно посвятил изучению этой проблемы некоторое существенное время, я перепробовал неколько разных "пейджеров", "APRS клиентов", и несколько шлюзов, и лучшее к чему я смог прийти это FBBS на RPi + андроидный клиент.
Шлюз разрабатывать не надо, так как FBBS это шлюз, в том числе в IP. FBBS была популярна среди радиолюбителей в 90-х и начале 2000-х, когда всепроникающей сотовой связи не было. Это open source проект, есть под все платформы, даже под MS-DOS. Очень сильно напоминает по сути FTN или UUCP, но только для HAM радио (в качестве адресов используюся радиолюбительские позывные + SSID).
Тут уже упоминали еще одну классную штуку - winlink. Работает офигенно если у вас есть купленный специальный модем. В интернетах пишут, что winlink-ом повально пользуются мореходы и яхтсмены, так как КВ связь самая надежная связь в мире! :)
m_a_x_i_m
26.11.2023 07:52А вы могли бы тезисно описать что он умеет и для чего юзается?
checkpoint
26.11.2023 07:52Вы про winlink спрашиваете ? Это сеть шлюзов связанных между собой по IP. Есть удобный виндовый клиент позволяющий пересылать электронную почту как между пользователями сети, так и в глобальную сеть, можно обмениваться файлами (фотографиями). Доступ в сеть winlink осуществляеться по радио (КВ/УКВ). Для этого используются специализированные модемы, но есть и решение на базе обычной звуковой карты, которую подключают к радиостанции. Использовение передовых методов модуляции с коррекцией ошибок позволяет иметь оперативную текстовую связь почти в любой точке Земли. Сеть поддерживается радиолюбителями, но финансируется из Американского бюджета. Линк: https://en.wikipedia.org/wiki/Winlink
Mike-M
26.11.2023 07:52+1Ошибка (точнее, три ошибки: лишняя точка в конце заголовка и два подчеркивания):
Helgich
26.11.2023 07:52+1Велик ли объем руководства? Как планируете поддерживать в актуальном состоянии?
По мне так очень трудоемкий процесс получается, но если все ради "жрать кактус", то вопросов нет, идеальный набор ПО получился, каждая более-менее серьезная правка - БОЛЬ!
alexsavochkin Автор
26.11.2023 07:52Объём получился 24 страницы с обложками.
Поддерживать в актуальном состоянии технически проблемы не представляет. Продукт разрастается медленно, вставить ещё страницу в нужное место легко. Некоторые сложности представляет только референс по интерфейсу, но если вдруг выкатят версию, в которой интерфейс значительно обогатился функциями, я просто переверстаю просторнее, вплоть до функции на страницу. Это недолго.
Насчёт трудоёмкости не соглашусь: если стоит задача сделать именно печатное руководство, этот пайплайн как раз видится оптимальным. Можно быстрее — я упоминал выше gostdown-pandoc для этого — но по ГОСТу не надо ни заказчику, ни мне. Тут ещё надо понимать вот что: значительную часть затрат времени на вёрстку составила не сама вёрстка, а поиск её оптимального варианта. Нарулить непротиворечивые наследуемые стили, найти ширину колонок, размер кегля, учесть преобладающие размеры картинок — всё это отняло время. Теперь же, когда основные решения найдены, вписать в них новый контент — дело техники.
Взял бы я ворд, каждая правка была бы такой же болью: вставил новое слово → появилась новая строка → картинка уехала вниз → сжал размер, получил неконсистентный вид документа. В ворде никогда и ничего нельзя сделать хорошо.
Helgich
26.11.2023 07:52Ну смотрите, на документ из 24 страниц с картинками (допустим их не очень много, четверть) ушло 3 недели чистого рабочего времени...я бы сказал, что это уже на грани разумного, если заказчика устраивает, все в порядке, не мне считать чужое время, но для себя я бы за такое не взялся. Поддерживать в таком формате документ 100+ страниц уже невозможно, а значит сборка довольно таки нишевая и ситуативная.
В ворде можно сделать очень хорошо, если уметь им пользоваться. Это очень мощная по своим возможностям программа.
alexsavochkin Автор
26.11.2023 07:52А что значит поддерживать в таком формате документ 100+ страниц? Внести в середину ещё главу? Так это не вопрос. Перебрать порядок изложения? Да в общем тоже не сложнее чем в ворде. Добавить ещё по паре предложений в каждую формулировку? Обновить все картинки в отдельной версии документа? Ну, чуть посложнее, но не принципиально.
Обусловленные технологией затраты времени не пропорциональны объёму работы. Чуть сэкономить можно было на каждом из этапов, в совокупности до приемлемых 3 часов на страницу. И если бы не печатная форма, можно было бы вовсе чего-то не делать. Например, я не засёк, сколько времени заняла инструкция по оригами, на глаз — 2 или 3 часа с тестированием. Именно для стоящей задачи она нужна, и она не обошлась бесплатно. Никакой техпис не станет отрисовывать в иллюстраторе изображения интерфейсов, логотипы и буллиты, а это тоже время. И таких мелочей много.
Что касается ворда. Он действительно мощная штука, пользоваться которой по-настоящему мало кто умеет из тех, кто думает, что умеет. :)
Но.
По возможностям управления текстом и картинками он и рядом не стоял с DTP-системой, и нет, в ворде нельзя сделать ничего хотя бы так же хорошо, как это позволет сделать DTP-система, а тем более индизайн. Хранить текст и управлять его версиями несопоставимо удобнее в гите. Готовить иллюстрации — всё равно нужен отдельный редактор, даже если это Визио. Ну и какой смысл использовать ворд?
Helgich
26.11.2023 07:52По возможностям управления текстом и картинками он и рядом не стоял с DTP-системой
Ну тут можно и поспорить, конечно, но если честно лень, пусть будет так.
Готовить иллюстрации — всё равно нужен отдельный редактор, даже если это Визио.
Визио ни в каком виде не является редактором графики вот от слова совсем, в самом ворде больше инструментария по работе с изображениями, чем в висио (кстати интересный вопрос - почему у мелкомягких нет приличного графического редактора...).
alexsavochkin Автор
26.11.2023 07:52Ну тут можно и поспорить, конечно, но если честно лень, пусть будет так.
Навскидку ещё в одних только стилях абзаца: оптический кернинг, настройка трекинга и интерлиньяжа, настройки подчёркивания и зачёркивания, отточий в стиле параграфа, тонкую настройку переносов, сглаживание рваного края при выключке влево. И это только то, что можно напечатать, и это только про стили абзаца. Да что далеко ходить, обыкновенную рамку по ГОСТу в Индизайне сделать и проще, и лучше: на мастер-странице берёшь и рисуешь рамку, в неё нужные вертикальные надписи, и всё. Тут и правда лень спорить. :)
Визио ни в каком виде не является редактором графики
Солидарен, хотя схемы в визио рисуют только в путь. Я, впрочем, с 21 года пользовался для схем не визио, а инкскейпом.
alexsavochkin Автор
26.11.2023 07:52Однако соглашусь: сборка нишевая и ситуативная, обусловленная печатной формой документа. Писал бы по госту, взял бы гостдаун вместо индизайна. Писал бы для веба, вообще взял бы маркдаун или рест.
m_a_x_i_m
Спасибо за замечательную программу.
Можно тут попросить о функционале?
Не могли бы вы обучить hfpager работать в режиме socks proxy сервера?
Связать приложения умеющие общаться по tcp/ip по радиоканалу, используя радиостанцию как радиомодем, затруднительно из-за задержек. Если использовать канал между двумя рациями как модем (физический уровень модели osi), поверх которого будут гулять канальный, сетевой, транспортный ... из-за задержек нельзя, то можно подняться выше по модели osi. И ближайшее подходящее - socks proxy. Если бы ваша программа могла быть таким socks proxy сервером - это было бы решение...
На одном девайсе, без подключения к сети, ваша программа принимает запрос по протоколу socks, отправляет другой версии вашей программы на другом устройстве. Там уже есть выход в сеть или работающий сервер слушающий какой-то порт...
alexsavochkin Автор
Вопрос не ко мне, я разработчик документации КВПейджера, а не разработчик самого КВПейджера. Но передать вопрос по адресу не проблема, передам. :)
По существу вопроса спрошу: какую задачу это всё должно решить? Пейджер — это ведь концептуально законченный продукт, предназначенный для решения своей узкой задачи. Неужели всерьёз рассчитываете, что пробросить какой-нибудь телеграм через socks-proxy со скоростью 5,87 бод (не бит в секунду!) — это порадует?
А, ну и кстати: там же есть ещё решение — FSKChat. Его протокол открыт, и хотя гарантированной доставки на физическом уровне не предполагает, сам по себе хорош вполне, и с разработчиком можно договориться предметно.
m_a_x_i_m
Самые разнообразные задачи. Например картографическое ПО, когда нужно обмениваться информацией об объектах с привязкой к координатам.
m_a_x_i_m
hfpager изначально позиционировался как туристическое ПО.
Очень многие нужные вдали от цивилизации программы общаются с сервером по http. Ну вот XyGrib например - умеет работать через socks proxy.
m_a_x_i_m
Если подключить к какому-нибудь баофенгу, и работать в vhf допустим, то возможно там будет и 1200 бод. Уже в браузере можно будет куда-нибудь залезть через proxy.
QDeathNick
HTML слишком неоптимален для таких скоростей. Лучше передавать нужные данные более упаковано. Передавать только нужные, изменившиеся данные и уж точно без форматирования. Если это и будет HTML через SOCKS, то нужен ещё JS движок, который будет обновлять странички, если вдруг они изменились и создавать максимально компактные запросы к бэкенду.
alexsavochkin Автор
Пейджер как чистый транспорт использовать не очень рационально: по задумке он самодостаточен, а на стационарном конце радиоканала легко развёртывается шлюз в телеграм или электропочту. Как чистый транспорт он неизбежно вынужден будет тащить метаданные, в итоге скорость передачи для большинства мыслимых практических приложений будет запредельно низкой. Мы же не можем игнорировать ни ощущение времени пользователем, ни его объективные ограничения.
m_a_x_i_m
Картографическое ПО, которого куча и еще маленькая тележка, получение метеоданных из определенных сервисов (винди, зигриб) - есть куча всего помимо телеги и почты, что возможно кому-то понадобиться вдали от цивилизации. Ну невозможно для всего предусмотрительно написать шлюз. Должно быть путь менее эффективное, но универсальное решение. HFpager это не только пейджер, это еще и протокол обмена данными, причем протокол позволяющий гибко настроить параметры и скорость связи. Чем выше по диапазону - тем больше возможная скорость, а диапазон передачи определяется используемыми рациями. Где-то будет очень узко, а где-то будет возможность пропихнуть более толстый трафик. У вас не единственная программа, которая умеет пропихивать данные по радиоканалу, но уникальная своей проработанностью и гибкостью настроек. Если к ней прикрутить еще socks proxy - будет только лучше, не хуже.
m_a_x_i_m
Вы так говорите будто есть возможность переписать кучу уже готовых приложений, которые хочется использовать вне покрытия операторов связи. Есть большая разница в затруднительности использования чего-то в результате низких скоростей и невозможностью использования.
SergeiPod
КВ Пэйджер - программа для обмена короткими адресными законченными сообщениями с контролем целостности и опционально - контролем доставки.
Поэтому естественным образом сюда ложатся шлюзы в SMS/E-mail/мессенджеры, которых уже написано некоторое количество :-)
"Персональный SMS-шлюз" входит прямо в состав обсуждаемого андроидного пэйджера.
m_a_x_i_m
В отличие от таких шлюзов socks proxy сервер - универсальное решение. В этом его плюс.
QDeathNick
Когда-то socks соединение будет реализовано, если действительно потребуется подключение сторонних программ к обмену сообщениями.
Главное понимать, что сообщения должны быть очень короткими, десяток другой байт.
Например, так может быть выгодно передавать платежи в какой-то крипте, например что-то типа helium, майнинг которой основан на предоставлении доступа, но на КВ.