amx
Месяц назад все проходило тут под лозунгом "Сахар, мед, говно и пчелы". Вы бесконечно цитировали документацию и прибаутки про Буратину. Никто не понимал кто чего хочет, а кто что может.
Все началось с вида HFPGxxxx это все что предлагалось транслировать в АПРС это должен был быть апогей . Не начинайте все с начала и не не вырываете из контекста фразы. АПРС-станции нужны если будет обмен сообщениями двухсторонний, т. к. в адрес объекта р/ст даже не предлагает отправить сообщение. Если сообщений нет и не будет, достаточно АПРС-объектов.
Или вы до сих пор не понимаете разницу между ними? Решитесь сами уже станции или объекты, -12 или HP, но с использованием информации о позывном.

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

SLYFOX
Если посмотреть на ближайший по функциональности "пример не для подражания" (неточная цитата из вас),

то там вообще гейты публикуются как объекты *-tt ,
а конечные пользователи - как станции *-12.

И обмен там, насколько я понимаю, тоже сугубо односторонний.

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

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


Тут подумалось, что для желающих странного поэкспериментировать, можно вообще
сделать специальный тег типа #;UA9OV-12% , весь текст после которого будет
отсылаться на I-GATE сервер после ':' как есть , то есть можно будет формировать пакет произвольного типа.

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

Так кто же против?
Скачивайте пэйджер (хотя бы демо версию),
скачивайте AprsGate , включайтесь в эксперименты.

Очередную версию AprsGate, надеюсь, сегодня опубликую.

Если кто хочет поэкспериментировать с полной версией, но не хочет пока покупать -
могу сгенерировать временную лицензию со сроком действия до конца июня
(для Windows или Android NG-версии).

Пишите на указанный в "About" e-mail или найдите меня в телеграме.

amx

А мне интересно, служебные конструкции типа {start} {end} {etc...} и так далее по тексту сообщения тоже двухбайтными кодами передаются? Или прямо текстом?

amx
вообще гейты публикуются как объекты *-tt ,
а конечные пользователи - как станции *-12.
Конечно больше интересуют конечные станции.
Скачивайте пэйджер ...
Мне все это интересно со стороны АПРС, я уже говорил. Но могу взять на себя отчет о результатах "гейтования" в эфир и отображения на р/станциях Kenwood и Yaesu.

Кстати, я сделал так, что статус можно отослать не только из маяка, но и просто из сообщения,
включив в него РЛ-тег.

Наверно неплохо. Тогда логически просится какое-то текстовое поле вроде Station status text и рядом с этим кнопка send update. Смеюсь, прямо таки соц-сеть в миниатюре выходит :-)


Скорее просится несколько кнопок для предопределённых сообщений.
Ну и соответствующие им поля в настройках.
Причем с выбором в этих же настройках, как отсылать - как маяк или как простое сообщение.

Можно даже навесить отправку сообщения на внутренние датчики телефона.
Например, при резком ускорении высылать "похоже, я попал в аварию".
Кто сказал "ЭРА-ГЛОНАСС" ????

Смех смехом, а оказывается в том самом FT-8 тоже позывной кодируют по определенному псевдо-словарю, который ужимает с 6 до 4 байт

Шесть допустимых в позывном символов упаковываются в 4 байта без потерь (36*36*36*36*36*36= 2176782336 = 0x81BF1000),
но мы можем сходить дальше, в AMTOR-ARQ поле для позывного - вообще три символа,
и я что-то я не помню маршей протеста и наездов FCC и ГСН по этому поводу :-)

Могу взяться вести, не вопрос! Хотя, эта база уже есть на сайте nvis, зачем повторяться.

Я уже объяснил, почему этой базы на сайте nvis нет, не буду повторяться :-)

Сохраняется ID пэйджера, не отнимая ни байта
от и без того короткого поля комментария.

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


На случай ОРМ :-)
Если кто-то будет хулиганить под чужим позывным, то это позволит найти хоть какие-то следы...

Ну или тупо завести черный список прямо в коде AprsGate и включить этот ID туда.

vasilisk
эти последовательности - они не в эфире передаются а отображают в текстовом виде процесс передачи/приёма.

{start} - передан/принят заголовок обычного пакета,
{beacon} - маяка,
{gps} - маяка с координатами...

amx
Очередную версию AprsGate, надеюсь, сегодня опубликую.

И что как там будет сделано?
Дайте примеры raw-строк, как это уходит в aprs-сервер!

Чтобы так сказать потом опять не кричать "мед, говно, пчелы" (с) SLYFOX.

но мы можем сходить дальше, в AMTOR-ARQ поле для позывного - вообще три символа,
и я что-то я не помню маршей протеста и наездов FCC и ГСН по этому поводу :-)

Так там это было сокращение от позывного, например, UA9OV как UAOV, по сути использовалось только для установления соединения. А потом человеки обменивались простыми фразами типа UA9OV de UA3XXX привет и т.д.
А в случае с амтор-ббс , после завершения конекта он в FEC режиме передавал полный позывной текстом.
В общем ничего нового, все тоже, что я вам говорил - структурированный ID-маяк с позывным.

И что как там будет сделано?

То, что вчера описывал - обработка тегов
$;xxxxxx;

Дайте примеры raw-строк, как это уходит в aprs-сервер!


Вот то, что принято aprs.fi:

Объекты:
UA9OV-15>PG0BB8,TCPIP*,qAC,T2QUEBEC:;UA9OV-1 *160103z5500.74NR08256.51Ea#;UA9OV-1;Proba pera
UA9OV-15>PG0BB8,TCPIP*,qAC,T2QUEBEC:;HFPG03000*160111z5500.74NR08256.52Ea#;UA9;Proba pera
UA9OV-15>PG0BB8,TCPIP*,qAC,T2SP:;My Home *160132z5500.74NR08256.54Ea#;My Home;Proba pera
UA9OV-15>PG0FA8,TCPIP*,qAC,T2KOBLENZ:;UA9OV-9 *170045z5500.77NR08256.54EaAprsGate test http://hfpager.com

Станции:
UA9OV-11>PG0FA8,TCPIP*,qAO,UA9OV-15:/170028z5500.74NR08256.54EaYa mayak Beacon test http://hfpager.com
UA9OV-11>PG0FA8,TCPIP*,qAO,UA9OV-15:>Ya mayak Beacon test http://hfpager.com
UA9OV-11>PG0FA8,TCPIP*,qAO,UA9OV-15:>Ctatus was changed by general message
UA9OV-11>PG0FA8,TCPIP*,qAO,UA9OV-15:>Status was changed by general message


UA9OV-15 здесь - позывной гейта

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

Точнее, то же, что я вам говорил - позывные передаются оператором, а не оборудованием. И не особо структурированно, а так, как сами захотят :-)

Обновил версию AprsGate, можете экспериментировать:

http://www.dxsoft.com/aprsgate.zip

Последняя виндовая версия пэйджера:

http://www.dxsoft.com/hfpagerw.zip

Андроидная демо-версия на Google Play:

https://play.google.com/store/apps/details?id=ru.radial.demo.hfpager

Последняя демо-версия , еще не опубликованная на Google Play,
содержит в себе персональный SMS-шлюз:

https://nvis.club/images/apk/HFpager301demo.apk

Формальное описание тегов AprsGate (оно же есть в файле справки):

======

Для управления видимостью станции в APRS-сетях
используются специальные последовательности символов (теги),


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


Если тег включает в себя регулярный радиолюбительский позывной с SSID -12 , -11 или -10 (в верхнем регистре, без пробелов),

такой тег имеет специальное значение (далее - РЛ-тег).


Маяки с GPS-координатами, не содержащие валидных тегов, (либо имеющие ошибку CRC в текстовой части маяка), публикуются как объекты с именами HFPGxxxxx ,

где xxxxx - цифровой ID пэйджера.


Маяк с GPS-координатами, содержащий валидный, но не РЛ-тег, публикуется как объект с именем, заданным содержимым тега.


Все объекты публикуются от имени (позывного) держателя гейта.


Маяк с GPS-координатами, содержащий валидный РЛ-тег, публикуется как APRS-пакет типа "/" (Position) от имени (позывного) станции, заданного содержимым тега.


Маяк без GPS-координат, содержащий валидный РЛ-тег, публикуется как APRS-пакет типа ">" (Status) от имени (позывного) станции, заданного содержимым тега.


Обычное сообщение (с любым ID получателя, в том числе 0) содержащее валидный РЛ-тег, публикуется как APRS-пакет типа ">" (Status) от имени (позывного) станции, заданного содержимым тега.



Маяки без GPS-координат, не содержащие РЛ-тега либо содержащие ошибку CRC в тексте, в APRS-сеть не транслируются.



Обычные сообщения, не содержащие РЛ-тега либо содержащие ошибку CRC в тексте, в APRS-сеть не транслируются.


В любом случае поле Destination UI-фрейма формируется в виде PGHHHH ,
где HHHH - цифровой ID пэйджера в шестнадцатеричном виде.


Примеры валидных не РЛ-тегов, которые будут использованы как имена объектов:


#;My Home; - не содержит радиолюбительского позывного
#;RA0XXX-PG; - недопустимый SSID
#;RA0XXX; - недопустимый SSID
#;RA0XXX-9; - недопустимый SSID
#;BBS3-12; - не содержит регулярного радиолюбительского позывного (так как последний символ позывного-цифра)
#;BBSA-12; - не содержит регулярного радиолюбительского позывного (так как позывной не содержит цифр)
#;Ra0xxx-12; - не все буквы позывного набраны в верхнем регистре



Примеры валидных РЛ-тегов:

#;X0X-10;
#;XX0XX-11;
#;RA0XXX-12;



SSID -10 и -11 не рекомендуется использовать без крайне серьезных оснований,
SSID -12 является самым подходящим в данном случае.

amx
И не особо структурированно, а так, как сами захотят :-)

Тем не менее идентифицировать трафик не представляло сложности.
В случае работы оператора с амтор/пактор ббс были четко структурированные ид маяки после завершения соединения, я помню это еще. И это правильно и нормально. Всегда можно было дождавшись завершения трафика понять, "а кто же тут дудел".


Вот то, что принято aprs.fi:

Годно.
Но можно и сиды -HP и -PG опробовать, чтобы потом их под пейджерный проект застолбить, не занимая цифровые сиды, как единственно применимые для ах25-аппликаций.

Маяк с GPS-координатами, содержащий валидный, но не РЛ-тег, публикуется как объект с именем, заданным содержимым тега.

Какой в этом варианте смысл, не смог понять?
Маяк без р/л тега, вроде ранее определились - это только Object с именем HFPGxxxx и координатами.
Это и так полу-формально, зачем допускать отправку каких-то дополнительных объектов.

Обычное сообщение (с любым ID получателя, в том числе 0) содержащее валидный РЛ-тег, публикуется как APRS-пакет типа ">" (Status) от имени (позывного) станции, заданного содержимым тега.

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

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

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


Учитывая то, что я держу в уме возможность гейтования из пэйджера напррямую в (У)КВ APRS-сеть,
не используя интернет, я считаю неправильным использовать не-AX25 SSID.
Да и такие кривые SSID вообще редко используются, как я погляжу.
Теже пресловутые -tt - это не SSID , а просто часть имени объекта.

Кстати, ничего не мешает использовать позывные в имени объекта.
Пропишите тег
#;XX3XX-PG; - и он опубликуется как объект с этим именем.

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


Маяк с GPS-координатами, содержащий валидный, но не РЛ-тег, публикуется как объект с именем, заданным содержимым тега.

Какой в этом варианте смысл, не смог понять?

Прямой.
То есть именно тот, что задуман отцами-основателями.

Вот сел я на диван в автомобиль, и поехал в экспедицию.

Передаю маяк #;UA9OV-12;... - все видят на карте мою текущую (последнюю) позицию и трек до нее.

А вот захотел я для потомков отметить полезный объект - передаю маяк с тегом
#;Good WC; - и эта отметка на карте уже не связана с моими дальнейшими перемещениями

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

Мы же не APRS-терминал обсуждаем, а способ взаимодействия двух сетей - HF pager и APRS.
Поэтому пока более логичным я вижу просто реализацию набора предопределённых сообщений (в пэйджерном, не APRS-смысле). А уж в каждом из них можно прописать нужный тег, можно не прописывать...

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

Как правильно заметил SLYFOX - давайте сначала попробуем и проверим, что действительно нужно, а что нет. То есть займемся тем, что и написано в регламенте РЛ службы - проведением экспериментов.

Сейчас есть два поля ввода - текст маяка и текст сообщения.
Включаем в настройках маяка "передавать GPS-координаты",
В текст маяка - забиваем тег #;XX3XX-12; и забываем про него.

Если хотим обновить статус - передаём сообщение (например, получателю с ID 0), добавив в текст сообщения тег #;XX3XX-12;

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


А просто рассуждать, сидя на диване, какого цвета должна быть кнопка - интересно, но не продуктивно...

amx
Учитывая то, что я держу в уме возможность гейтования из пэйджера напррямую в (У)КВ APRS-сеть,
не используя интернет, я считаю неправильным использовать не-AX25 SSID.

Гейтование напрямую в АХ25 производится в 3rd-party формате, как из другой радио сети, поскольку пейджер такой является.
Там ссиды 0-15 не имеют необходимости, т.к. не входят в АХ-25 поля source/dest "гейтовальщика".

Да и такие кривые SSID вообще редко используются

Просто потому, что все на ах25 исторически сложилось. Не-ах25 протоколов, пригодных для апрс-маяков почти не придумали, кроме магистрали серверов и еще нескольких почти мертвых проектов. Вы тут почти первопроходцы :-)

К примеру, есть "занятый" ссид -63 -это тоже был проект типа пейджера, только использовали простую модуляцию BPSK63.

Кстати, ничего не мешает использовать позывные в имени объекта.

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

Передаю маяк #;UA9OV-12;... - все видят на карте мою текущую (последнюю) позицию и трек до нее.

А вот захотел я для потомков отметить полезный объект - передаю маяк с тегом
#;Good WC; - и эта отметка на карте уже не связана с моими дальнейшими перемещениями

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

А просто рассуждать, сидя на диване, какого цвета должна быть кнопка - интересно, но не продуктивно...

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

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

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

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

Так же не смог увидеть (понять) произошло ли соединение сервером и вообще тут на сокете сделано или на том варианте http-запросов?


И небольшое замечание по документации:

Примеры валидных РЛ-тегов:
#;X0X-10;
#;XX0XX-11;
#;RA0XXX-12;

Позывные еще есть формата ХХ0Х, если это существенно для шаблона тегов.

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

Гейт односторонний, поэтому и трафик не мониторится.

Так же не смог увидеть (понять) произошло ли соединение сервером и вообще тут на сокете сделано или на том варианте http-запросов?

POST-запросы,
результат (ответ сервера) отображается в окне лога.

Примеры валидных РЛ-тегов:
#;X0X-10;
#;XX0XX-11;
#;RA0XXX-12;

Позывные еще есть формата ХХ0Х, если это существенно для шаблона тегов.

Ну там же не сказано, что "исчерпывающие примеры".

и XX0X-12 - правильный, и X0XXX-12 - тоже правильный.

Если интересно, то правила такие (по памяти):

1. Длина - 3...6 символов.
2. Если длина <4 символов, то допускается только формат X0X (буква-цифра-буква).
3. Должна быть как минимум одна цифра.
4. Должна быть как минимум одна буква.
4. Последний символ не должен быть цифрой.
5. Если цифр меньше двух, то первый символ не должен быть цифрой.

POST-запросы,
результат (ответ сервера) отображается в окне лога.

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

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

Мы это уже обсуждали.

Продолжаю считать, что генерирование гейтом объектов от своего имени - на 100% корректная операция.

А вот в 100%й корректности генерирования пакетов позиции и статуса от имени оператора пэйджера - продолжаю сомневаться. Но раз TT-гейты так делают, и никто не возмущается - то и мы можем.

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

А смысл? Объект интересен сам по себе, а не тем, кто его опубликовал.
Но если это так уж интересно - для этого есть ID пэйджера PGxxxx в destination поле пакета,
и, кстати, aprs.fi его показывает.

Покажите пример. (текстом или скрином).

Ну так запустите и попробуйте.
Можно для начала по воздуху (через микрофон).

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


Может ничего не отображается, если не произошла корректная авторизация по паролю?

Вот так отображается результат при неверном пароле:

>>> HFPG04008 - Error! Answer Code 401


А вот так - успешная передача:

>>> HFPG04008 - OK! Answer Code 204
>>> UA9OV-12>PG0FA8,TCPIP*:/181826z5500.77NP08256.50EaAprsGate V0.92 test http://hfpager.com

amx
Продолжаю считать, что генерирование гейтом объектов от своего имени - на 100% корректная операция.

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

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

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

А вот в 100%й корректности генерирования пакетов позиции и статуса от имени оператора пэйджера - продолжаю сомневаться.

Тут нет никаких сомнений!
Оператор пейджера - это станция в р/л диапазоне (апрс-совместимая, если отмечается тегом), апрс-станции как раз и генерируют объекты, статусы и прочее. Просто эта станция находится на другом эфирном протоколе.

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

Конечно включать, а бутерброд не лишний, он несет в себе атрибуты, что апрс-объект сформировала р/л станция в своей подсети.

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


---------------

Вот так отображается результат при неверном пароле:

>>> HFPG04008 - Error! Answer Code 401


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

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

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

Zmej


А вот генерировать объекты от имени гейта, если их по факту генерирует другая станция р/л технологии - есть не нормально.

Достаточно того, что их генерирует станция не APRS-технолологии. И непосредственно опубликовать
объект в APRS-сети оператор пэйджера не может. Он просит опубликовать его оператора гейта.
Что оператор гейта и делает. От своего имени, потому что именно на его узле этот объект становится
известным сети. Так что в данном вопросе у меня никаких сомнений нет.

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

И непосредственно опубликовать
объект в APRS-сети оператор пэйджера не может.

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

У нас всегда "или пусто или густо"...
amx
Оставьте только - 12 как SSID станции , не в тему там -10 и -11.
Генерация объектов кв-пейджером преждевременна если не избыточная функция вообще. Это же не терминал или АПРС- девайс ,сами сказали.

И вообще, пока все сложно, даже имея какой-то опыт в АПРС.

Нужно смотреть по факту что получается. Есть возможность включить трансляцию в сеть одной станции и одного объекта, на день-два? Интервал хотя-бы 30 минут. ЗА это время можно даже уже отработать работу гейта в УКВ и отображение на УКВ станциях.

Кстати, символ буква p в красном ромбе - не уникальный, как минимум использует пару станций, может больше. Что в итоге является отличительным признаком системы, как отфильтровывать из сети? Возможны варианты, нужно тестировать.

Оставьте только - 12 как SSID станции , не в тему там -10 и -11.

Я не виноват, это меня Zmej уговорил :-)
Оно и правильно - иметь запасной вариант лучше, чем не иметь.

Есть возможность включить трансляцию в сеть одной станции и одного объекта, на день-два?

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

Это ж я не я навязываю пэйджер для использования в APRS-сети...

Кстати, символ буква p в красном ромбе - не уникальный, как минимум использует пару станций, может больше.

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

Что в итоге является отличительным признаком системы, как отфильтровывать из сети?

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


А вообще - сейчас и технология, и терминал идентифицируются по полю "Destination" UI-фрейма -
PGxxxx .

Раз даже aprs.fi это поле показывает, значит, фильтровать по нему вполне можно.

amx
Я не виноват, это меня Zmej уговорил :-)

Э-э! Что-то путаете, я вообще предлагал не трогать 0-15 ссиды, а взять уникальный ссид -HP для станций и -PG для гейтов пейджера этого.

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

Это ж я не я навязываю пэйджер для использования в APRS-сети...

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

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

Даже нет банально поля, где указать фиксированную широту-долготу, если нет подключенного GPS.

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

Короче, работ там по user-friendly интерфейсу еще валом.

amx
КАкая же у вас отвратительная манера общения все таки! Вы серьезно думаете, что все работает и не требует отладки? Или все равно что получилось?
Это ж я не я навязываю пэйджер для использования в APRS-сети...
А кто-то навязывает такое использование?

Вместо использования дополнительно -10 и -11 лучше заложите еще 1-2 символа на выбор пользователя для большего положительного эффекта от взаимодействия "оператор-софт".

Вы серьезно думаете, что все работает и не требует отладки? Или все равно что получилось?

Откуда такой вывод ???

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

UA3AHM поставил ApsGate в Угличе, порисовал себя на карте, пока был у него интерес,
завтра обещает версию обновить.

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

Э-э! Что-то путаете, я вообще предлагал не трогать 0-15 ссиды,

Вы говорили, что одного -12 может быть мало :-)

А идея использовать не-AX25 SSID мне категорически не нравится.

amx

Вы хотите, чтобы я из своего кабинета непрерывно подудел несколько суток?
Хотя-бы завтра в течении дня, этого времени хватит сделать себе мнение думаю )))

Короче, работ там по user-friendly интерфейсу еще валом.

Ну интерфейс самого пэйджера сейчас и обсуждать нет смысла.

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

SLYFOX
лучше заложите еще 1-2 символа на выбор пользователя

На выбор оператора гейта или на выбор оператора пэйджера?

Если первое - то нет проблем, хоть тупо двухсимвольное поле для назначения
произвольного символа, если не пугает потеря "однозначного признака".

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

Ну можно сделать предопределённый набор символов , выбираемый вторым символом тега,
то есть вместо ';' после '#'.

Например,

#(UA9OV-12;
#)UA9OV-12;
#%UA9OV-12;


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

Хотя-бы завтра в течении дня

Запустил.
Шлюз UA9OV-PG ,
станция UA9OV-12

Кстати, можно было бы фильтровать по SSID шлюза, если прибить его гвоздями к -PG .

Но вот по этому признаку aprs.fi, например, не ищет.

Надо все же при ошибке соединения с rotate.aprs2.net делать пару повторных попыток через конкретные серверы, например gb.aprs2.net и finland.aprs2.net