Ваш этот пейждер, удивительно сходно повторяет идеологию АПРС - то есть цифровая связь с позиционированием станций и короткими сообщениями!

Внутри он напоминает APRS ещё больше, чем снаружи :-)

Тем, что обмен производится без установления соединения.


Каждый пакет - законченное сообщение.
И подтверждающий прием пакет формируется из ID получателя, отправителя и номера пакета.

Адепты АПРС должны сами разрабатывать гейты и прочее, приспосабливая КВ пейджер под свою систему

Тут мы возвращаемся к вопросу выше - для чего они должны
натягивать сову на глобус приспосабливать пэйджер к APRS ?

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

Достаточно просто реализовать вариант софтового KISS-TNC , использующий аналогичный пэйджеру способ модуляции и продвинуть его использование :-)

Zmej, SLYFOX ,
а откуда вообще взялось утверждение, что SSID 12 обозначает трекеры?

В PDF-ке это просто "Jeep".

В общем, родилось такое решение для AprsGate

0. Транслируются только маяки, содержащие GPS-координаты.

1. Маяки без тега или с тегом, не удовлетворяющим условиям ниже, публикуются как
объекты с именем HFPGxxxxx.

2. Маяки, текст которых начинается с тега вида

[b]#;MYNAME;[/n] ,
где MYNAME - текст длиной от 6 до 9 знаков,
публикуются как объекты с именем MYNAME

3. Маяки, текст которых начинается с тега вида

[b]#;N0CAL-12;[/n] ,

где N0CAL - последовательность символов, подпадающая под правила формирования
регулярного РЛ позывного (так, как позывные ищет в потоке символов TrueTTY, и в, общем, не ошибается),
а "-12" - именно "-12",

передаются в APRS-сеть как пакет типа "/" (Position with timestamp) c позывным
N0CAL-12 в поле источника.

а откуда вообще взялось утверждение, что SSID 12 обозначает трекеры?

Сам спросил - сам отвечаю:

http://aprsisce.wikidot.com/doc:ssids

amx
Каждый пакет - законченное сообщение.
И подтверждающий прием пакет формируется из ID получателя, отправителя и номера пакета.

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

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

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

Достаточно просто реализовать вариант софтового KISS-TNC , использующий аналогичный пэйджеру способ модуляции и продвинуть его использование :-)

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

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

а откуда вообще взялось утверждение, что SSID 12 обозначает трекеры?

Там этих вариантов ссид, за всю историю - было два-три разных.
По большему счету - вам это не нужно, это имеет отношения к АПРС на ах-25 протоколе, где ссид, как вы знаете, ограничены всего 16шт, от 0 до 15, поэтому за них были тёрки...

Здесь же в вашем протоколе и в APRS-IS можно не ограничиваться сидами 0-15, мы с тов.SLYFOX предложили сиды:
-PG - для гейта
-HP - для пользователя.
(от сокращений PagerGate и HfPager.)

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


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

Маяки без координат, но с РЛ тегами, можно транслировать как пакеты статуса ">".

Как считаете, есть в этом смысл?

amx

Можно без проблем. Чтобы маяк с координатами, который, например, передается при движении станции чаще, не делать с длинным текстовым комментарием.

Текст такого маяка будет заполнятся в поле "статус станции", это отображается на апрс.фи и в терминалах тоже, как правило.

Здесь же в вашем протоколе и в APRS-IS можно не ограничиваться сидами 0-15, мы с тов.SLYFOX предложили сиды:
-PG - для гейта
-HP - для пользователя.
(от сокращений PagerGate и HfPager.)


не-не, пакеты с такими SSID источника нельзя будет ретранслировать на (У)КВ , а этого как раз SLYFOX хотел.

К тому же, при желании, AprsGate сможет выдавать пакет в COM-порт для KISS-TNC или
сразу 300- или 1200-бод AFSK посылку в звуковую карту...

текстом гонять позывной постоянно нет смысла наверно,

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


Да, а цифровой ID будет всегда идентифицироваться в destination field пакета в виде
HFPxxxx , гдк xxxx - ID в 16-ричном виде

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

Кстати, как правильнее в этом случае - как ";" или как "/" ?

И какой логичнее APRS-символ применить?

amx
не-не, пакеты с такими SSID источника нельзя будет ретранслировать на (У)КВ , а этого как раз SLYFOX хотел.

А их и не транслируют в пакет прямо, для этого используется 3rd party format,
это когда через тег } передается пакет из сервера в пакетную сеть.
Например как:

UA3YYY-10>APRS: (это ax25 заголовок пакетного гейта)
}UA3XXX-HP>APRS,TCPIP:<и тут любой пэйлоад апрс-формата>

любые пакеты из сервера в ах25 передаются в таком формате.

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

Ну смотрите, при скорости в 6 бод, все-таки лишние 6 байт гонять...

На сколько там разница была после смены позывных на ID-байты, если честно?

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

Кстати, как правильнее в этом случае - как ";" или как "/" ?

Явно не ";".
Для маяка с позицией Igate подходит "!". И там какой-то коммент текстовый добавлять, вроде HFpager Igate F=xx.xxx MHz...

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

Для игейтов еще есть специальный статус-тег "<" - в него заполняются параметры игейта - число принимаемых станций "в своем эфире", число сообщений и т.д., см. спецификацию.
<IGATE,MSG_CNT=n,LOC_CNT=n

Т.о. от игейта, следуя спецификации, идут пара маяков, один с позицией и комментарием, второй вот этот <IGATE,MSG_CNT=n,LOC_CNT=n

Периодичность: позицию - достаточно раз в 20-30 минут, статус-тег - по мере обновления его контент, но где-то не чаще 5-10минут.

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

И какой логичнее APRS-символ применить?

Попробуйте иконку Gate, Igate и еще бывают оверлей-символы, можно попробовать букву P. Но, эти оверлей не все старые терминалы добавляют, апрс.фи - должен.

Ну смотрите, при скорости в 6 бод, все-таки лишние 6 байт гонять...

Ну так не в каждом же пакете, и не в заголовке ...

Ну так не в каждом же пакете, и не в заголовке ...

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

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

Zmej

Про сообщения сейчас речь не идет, только о маяках (с координатами или без).

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

(процента исправленных ошибок в принятом пакете).

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

Про сообщения сейчас речь не идет,

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

Как понимаю, пока возможны два варианта:

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

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

Второй вариант еще хорош и тем, что такой маяк звучит в эфире периодически, тем самым проводя идентификацию

Первый, вариант, разумеется.

Резюмирую.
Экономить байты не будем. Будем считать их платой за вход в РЛ APRS-сеть :-)

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

А в-главных - ведение всяких глобальных "баз" или построение такой базы гейтом на лету -
вступает в сильное противоречие с принципом KISS (где KISS-аббревиатура, а не формат пакета).

AprsGate будет пропускать в APRS-сеть только те пакеты позиции '/' , статуса '>' (и ':', то есть сообщения, если до этого дело дойдет), в которых явно указан явно РЛ позывной (вместе с SSID),
причем допускаются только SSID -10, -11, -12. 12 - как основной, 10 и 11 - резервные на случай необходимости "раздвоения".При этом позывной должен быть указан в верхнем регистре (большими буквами).

На незаданный вопрос "почему не любые SSID" отвечу - потому что эти SSIDы - дополнительный признак желания "показать мой РЛ позывной как источник пакета".

Пакеты типа ';' (объекты) публикуются под позывным гейта, при этом имя объекта либо формируется автоматически как HFPGxxxxx (когда никакой валидный тег не указан) , либо формируется из заданного тега, который валидный, но не подпадает под описанное выше определение РЛ позывного.

Например,маяк с координатами и текстом, начинающимся на
#;UA9OV-12;
уйдет в сеть как пакет позиции '/' от имени UA9OV-12,

а пакеты с тегами
#;UA9OV-PG;
#;UA9OV;
#;My Home;

уйдут в сеть с позывным гейта в качестве источника и с именами объектов UA9OV-PG, UA9OV и My Home соответственно.

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

Все остальные пакеты, содержащие ошибку CRC, в APRS-сеть не пускаются.


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


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

Если дойдет до передачи сообщений, то тег будет, возможно,

#;yyyyyyy:zzzzzzz;

где yyyyyyy и zzzzzzz - РЛ позывные отправителя и получателя соответственно.

Кстати, как правильнее в этом случае - как ";" или как "/" ?

Явно не ";".
Для маяка с позицией Igate подходит "!".

Однако те же пресловутые -tt , что я нашёл, публикуются именно как объекты:

2020-05-17 07:40:33 +07: ZL1WK-10>APDW15,TCPIP*,qAC,T2SYDNEY:;ZL1WK-tt *111111z3758.79S\17700.99E=APRStt Gateway

И одновременно IGate этой же станции публикуется как позиция:

2020-05-17 07:12:25 +07: ZL1WK-10>APDW15,TCPIP*,qAC,T2SYDNEY:!3758.80SI17700.98E#PHG4628/A=000748ZL1WK-10 DIGI with IGATE -Eastern Bay of Plenty Branch 51

Видимо, зависит от реализации.
Хотя мне самому вариант с позицией нравится больше

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

Я лично не убеждал. Можете вернуться к посту КВ пейджер - Страница 9 и перечитать начало обсуждения.

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

В радиолюбительской связи нет такого, что железка как-то себя идентифицирует отдельно. Идентифицируются (позывным) только передачи любителькой р/с.
К примеру, трансиверы свой серийный номер не передают никак...
Эту хрень с идентификацией железки/терминала отдельно от оператора кто-то из вас (основателей пейджера) пытается, выражаясь вашим же термином - "натянуть как сову на глобус" в р/л связь. Видимо, по аналогии из каких-то проф. систем связи, но нам это - как пятое колесо телеге!


А в-главных - ведение всяких глобальных "баз" или построение такой базы гейтом на лету -
вступает в сильное противоречие с принципом KISS

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

AprsGate будет пропускать в APRS-сеть только те пакеты позиции '/' , статуса '>' (и ':', то есть сообщения, если до этого дело дойдет), в которых явно указан явно РЛ позывной (вместе с SSID),
причем допускаются только SSID -10, -11, -12. 12

Ограничиваться номерными ссид - нет смысла, это ограничение было в ах25.
Можно без проблем брать для позывного пользователя пейджера ссид -HP.

Пакеты типа ';' (объекты) публикуются под позывным гейта, при этом имя объекта либо формируется автоматически как HFPGxxxxx (когда никакой валидный тег не указан) ,

Да, кто хочет шифроваться, пусть уходят как объекты HFPGxxxxx.


а пакеты с тегами
#;UA9OV-PG;
#;UA9OV;
#;My Home;

А зачем эти теги вообще?

Гейт словил пейджер-маяк с координатами - отослал в апрс объект вида ;HFPGxxxx, где XXXX - проставил номер ID.
Источник отправляемой информации в апрс - GATECALL-PG (вместо GATECALL - позывной владельца гейта)

А если человек отметил идентификация позывным в апрс, гейт словил такой маяк по тегу, в апрс уходит под позывным и как станция. SSID станции предлагается -HP, источник данных, как и в первом случае: GATECALL-PG.


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

Все остальные пакеты, содержащие ошибку CRC, в APRS-сеть не пускаются.

Считаю, что любые пакеты с неверной CRC не должны транслироваться, в апрс-сервере подразумевается, что 100% достоверная информация поступила из protocol layer.

Не совсем понятно, как могут быть отдельно верные координаты, но не верное crc у комментария, вы что ли отдельные блоки контрольной суммы там ставите, не один на весь передаваемый блок?
Нет описания вашего протокола, все приходится интуитивно догадываться...


В любом случае, поле Destination пакета формируется как

Это неправильно, дестинейшен в общем случае - APRS.
Суть этого - просто индикатор общего назначения или подсети.

Можно свой дестинейшен ввести, обычно принято, что они все начинаются на APxxx, можно взять APHFPG - вроде не занято пока никем. Но, дейтинейшенов не должно быть разных у одной системы. Если это пейджерная система (как одна взятая единица), то у нее один общий дестинейшен. Предлагаю: APHFPG.

Я уже махнул рукой на все это, а тут такой движение...

Нужно определиться уже будет ли двухсторонний обмен сообщениями когда-нибудь. Если будет, то формировать как станции "ПОЗЫВНОЙ-12, если не будет сообщений, можно обойтись объектом "ПОЗЫВНОЙ-НР (или hp) и комментарием. Никаких резервов -10,-11 и т.д. не нужно, это все из другой оперы.
Возможность еще и самому КВ-пейджеру генерировать объекты (My home и т.д.), если я правильно понял, тоже избыточно, уж лучше эти ресурсы отдать на двухсторонний обмен сообщениями как в сети DMR.

Любая АПРС- станция имеющая подключение к мировой сети через интернет должна быть верифицирована через пароль доступа к серверу, тогда и координаты от нее буду восприниматься и генерируемые ее объекты будут легальны и сформированы по правилам. Реализовано ли это в программе aprsgate?

И еще раз мое мнение- этот пресловутый ID-APRS гейт должен быть в месте приема (...Углич и т.д.), быть АПРС-станцией с позывным вида UA9OV-? или HPGATE иметь верификацию через пароль доступа к апрс-серверу и быть источником для всех генерируемым им самим объектов. Индивидуальное декодирование ID из эфира, конвертирование в АПРС и транслирование их в сеть АПРС или Эфир- допускается, всячески приветствуется и поощряется, но остается факультативом, выполняющем функцию резервирования.


И еще, может очень революционно, но все таки- нельзя-ли в самом алгоритме присваивания ID заложить принцип использования позывного? Префиксов вида R, UA, UB, UR и так далее, не так много. Присвоить им 1-или 2 значный код соответствия, цифра в позывном- понятно, буквы в суффиксе- по позиции в алфавите... тогда UA9OV=1/9/15/22 т.е. 191522Х (Х- контрольная сумма...). Ну или еще каким "хитрым" способом.... Для HFPGxxx-ID вида 6хххх как сейчас.

Мнение не навязываю.

SLYFOX
Нужно определиться уже будет ли двухсторонний обмен сообщениями когда-нибудь. Если будет, то формировать как станции "ПОЗЫВНОЙ-12, если не будет сообщений, можно обойтись объектом "ПОЗЫВНОЙ-НР (или hp) и комментарием.

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

Любая АПРС- станция имеющая подключение к мировой сети через интернет должна быть верифицирована через пароль доступа к серверу

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

И еще раз мое мнение- этот пресловутый ID-APRS гейт должен быть в месте приема
....
Индивидуальное декодирование ID из эфира, конвертирование в АПРС и транслирование их в сеть АПРС или Эфир- допускается, всячески приветствуется и поощряется, но остается факультативом


Неправильно мыслите. У всех приемных гейтов должен быть равный приоритет, они должны покрывать какую-то эфирную
территорию, где предполагается активность станций. Если применяется диапазон 80метров, то таких гейтов нужно развивать, в идеале, где-то через каждые 200-300км, но будет неплохо, если и через 300-500км кто-то появится.
Т.о. будет достигнуто полное радио покрытие хоть при дневном, хоть при ночном прохождении радиоволн!
Кто услышал маяк - отдал его в APRS-магистраль, тут не нужно ничего придумывать, централизировать, отдавать кому-то одному приоритет и т.д.

И еще, может очень революционно, но все таки- нельзя-ли в самом алгоритме присваивания ID заложить принцип использования позывного?

У них были позывные раньше. Потом отказались.
Смотрите сами, если передавать стандартный позывной "текстом" - это 6 символов, т.е. 6 байт данных.
В их номерной ИД системе применяется 16-ричное число (1...65565, т.е. при текущем варианте может быть адресовано 65тыс. уникальных абонентов), оно кодируется всего 2 байтами данных.
Т.е. экономят 4 байта. А если идет обмен сообщениями - это уже два позывных, а передается не 12байт "адрес получатель-отправитель", а всего 4. Экономия в 3 раза, грубо говоря. В общем-то идея нормальная для малоскоростного канала, а если есть база - никакой проблемы нет по ней конвертировать ИД в позывные...

Zmej
Мы опять все по кругу начинаем...
Вроде в поле получатель сообщения нет жесткой привязки к цифровому SSID. Можете это проверить в терминалах и апрс-портативках, которыми пользуетесь.
Если есть обмен сообщениями, то он идет со станцией ,а не с объектом. Если станция то вида "ПОЗЫВНОЙ-12", если объект то вида "ПОЗЫВНОЙ-12(HP, hp) без разницы, лишь бы было уникальным, что-бы "вычленять" из сети с помощью фильтров по символу и/или типу объекта и/или шаблону. -10,-11 не в тему совершенно.

Но, каждую гейтуемую им станцию - не нужно авторизировать (логин-паролем).
Об этом никто и не говорит. Речь о об гейте ID-APRS, он умеет подключаться через пароль? Если да, то вопрос легализации того что он гейтует в сеть снят сам собой. Вопрос только в нужности или нет того что он гейтует в сеть, т.е вопрос администрирования на месте.

Неправильно мыслите
Из ходя из обеспечения работоспособности, отсутствия необходимости вести актуальные базы и давать к ним доступ и.д., мыслю как раз правильно. Пример уже был дан- сеть любительского DMR.
Признайтесь, что просто очень хочется позаморачиваться с декодированием из эфира? Эту возможность у вас никто не отбирает. Сеть приемных гейтов через 200-300 км- очень оптимистично и сами же пишите в идеале... Эта часть проекта не должна зависеть ни от прохожения и помех на КВ, ни вообще от отсутствия или наличия желающих заниматься этим декодированием из эфира. И это проще в реализации. И 100й раз пишу, что дело не в приоритете.

У них были позывные раньше. Потом отказались
Позывные были. Я же говорю о тех же цифровых ID, но сгенерированных не по порядку, а по правилу, как в том же APRS-tt в комбинации DTMF. ID в КВ эфире остаются цифровыми, уникальность их неизменна. Конвертируй в АПРС сам ID, без необходимости тегов и др. дополнительных признаков.

SLYFOX
Если есть обмен сообщениями, то он идет со станцией

Конечно со станций, а что ей запрещено иметь ссид не только 0-15, а к примеру -HP?
Это ограничение в 0-15 SSID было связано только с ах25 протоколом.

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

Речь о об гейте ID-APRS, он умеет подключаться через пароль? Если да, то вопрос легализации того что он гейтует в сеть снят сам собой.

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

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

гейтуется объект-слепыш:
UA9OV-PG>APRS,TCPIP:;HFPG0001*<тут координаты и прочее в формате Object>
Здесь: UA9OV-PG - позывной гейта, который заголинился в сервер. HFPG0001 "позывной" пейджер-партизана. Партизан будет только отображаться как Object на карте и все.

гейтуется станция пейджера, которая себя нормально разрешила показывать как апрс-совместимую станцию:
UA9OV-PG>APRS,TCPIP:UA1XXX-HP>APRS,qaO,UA9OV-PG:=<тут координаты и прочее>
Здесь: UA1XXX-HP - пользователь пейджера, который отметил настройку "нормального отображения как APRS-станция с позывным".

И образец отправки таким пользователем сообщения для другой станции на стороне апрс:
UA9OV-PG>APRS,TCPIP:UA1XXX-HP>APRS,qaO,UA9OV-PG:UA2YYY :привет Вася, приезжай с пивом в лес{001
Здесь: UA2YYY и далее текст - сообщение, которое пользователь пейждера шлет апрс-пользователю.

Если вы хотите в своем терминале фильтровать на показ всех пейджерщиков, достаточно это делать по ssid "*-PG".
Если только объекты-слепыши, то по маске "HFPG*" Есть там и другие варианты, как вы понимаете можно фильтровать по какому-то географическому региону и т.п.

Пример уже был дан- сеть любительского DMR.

У сети ДМР есть централизованная структура. Если эта структура ляжет, то дмр (и его гейт в апрс) ляжет тоже. Понимаете разницу?
АПРС сложнее положить, там десяток основных-дублирующих серверов и еще другие есть.

Как вам еще объяснить... Есть скажем УКВ апрс сеть в отдельных городах, ее эфирные гейты соединяются к серверам магистрали. При этом нет никакого обязательного "главного сервера (или гейта) для региона". Любой гейт может (по желанию сисопа) подсоединится к любому из серверов и на равных основаниях сбрасывать все, что услышал в эфире.
Там даже по спецификации они рекомендуют использовать адрес rotate.aprs.net - который фактически при каждом новом соединении перебрасывает рандомно на разный сервер.

И 100й раз пишу, что дело не в приоритете.

Так в чем тогда?
Уловите суть того, что объясняю выше.

Я же говорю о тех же цифровых ID, но сгенерированных не по порядку, а по правилу, как в том же APRS-tt

Это уже сложно будет сделать, они выдали 100+ шт номерных ID зарегистрированным пользователям. Отзывать обратно ради этой затеи - никто не будет. И тем более экономии байт в длине пакета ваши вариант не предполагает.

Zmej
У сети ДМР есть централизованная структура. Если эта структура ляжет, то дмр (и его гейт в апрс) ляжет тоже
Однако уже годами работает и сбоев не наблюдалось( в части АПРС я их точно не замечал). Если и были то все восстанавливалось банальной перезагрузкой. Все что мы тут обсуждаем это не АПРС сеть, это попытка в нее "засунуть" информацию.
Как вам еще объяснить...
Не нужно мне этого объяснять, если я сам как сисоп это делаю не первый год для себя и своего локального УКВ.
В классическом АПРС никто не решает задачи конвертации "непонятно что" в АПРС-пакет с использованием каких-то баз и тегов и т.д. А если решает (APRS-tt) то делает это гарантированно и самостоятельно, не перекладывая на пользователей, этим и достигается работоспособность. В нашем случае кто уже сегодня- завтра готов декодировать из КВ эфира и транслировать в сеть? Кто из них будет этим заниматься через месяц-два и позже?

Конечно со станций, а что ей запрещено иметь ссид не только 0-15, а к примеру -HP?
Это ограничение в 0-15 SSID было связано только с ах25 протоколом
SSID сам в составе "ПОЗЫВНОЙ"+SSID (12, HP, hp) по себе это атрибут АПРС-станции.
Если смотреть на то, что уже есть исторически, то нужно использовать SSID-12, если внести новое в АПРС и привлечь внимание (хорошо или плохо это я не знаю), то SSID -HP. У объекта нет SSID вообще, может быть имя "ПОЗЫВНОЙ-12 (HP, hp)". В обоих случаях нужно, что-то уникальное для построения фильтра на прием и (если получится трансляции в УКВ) и в обоих случаях - наличие "HP" решит задачу фильтра на прием. Или уникальный символ нужен.
К слову, чтоб два раза не вставать:
Буква R в красном ромбе,признак принадлежности к RACES- очередной р/л службе спасения в США.
ARRL or DIAMOND: #a
/a = Ambulance
Aa = ARES
Da = DARES Dutch AR Emergency Services
Ga = RSGB Radio Society of Great Brittan
Ra = RACES
Sa = SATERN Salvation Army
Wa = WinLink

и там же:
BOX SYMBOL: #A (and other system inputted symbols)
/A = Aid station
\A = numbered box
9A = Mobile DTMF user
7A = HT DTMF user
HA = House DTMF user
EA = Echolink DTMF report
IA = IRLP DTMF report
RA = RFID report
AA = AllStar DTMF report
DA = D-Star report
XA = OLPC Laptop XO

PA- не занят, это серый квадрат с буквой P внутри. На aprs.fi видно хорошо и АПРС кенвуд это воспринимает точно.

Если не будет никогда сообщений, то зачем АПРС-станции вообще и головоломка легально/нелегально? Генерируйте АПРС-объекты с информативным комментарием, а не вот это Комментарий: #;UA9;Proba pera . Если получится с гейтованием в УКВ, это все полетит в эфир, зачем?
Если же есть минимальный шанс в будущем на двухсторонний обмен сообщениями- генерируйте АПРС-станции, но не с SSID -10, -11. Нужно решаться уже хоть на что-то и идти дальше.

SLYFOX
В классическом АПРС никто не решает задачи конвертации "непонятно что" в АПРС-пакет с использованием каких-то баз и тегов

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

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

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

В нашем случае кто уже сегодня- завтра готов декодировать из КВ эфира и транслировать в сеть? Кто из них будет этим заниматься через месяц-два и позже?

Потенциально - готов каждый, у кого трансивер подключен "дудеть" в PSK, WSPR, FT-8 и т.п.
А будет и как долго - вопрос вторичный, тут обязаловки нет, все на добровольной основе и общем интересе к хобби. Вы же не спрашиваете, "вот кто бы местный апрс замутил", а сами гейт держите. Так же и тут.

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

SSID сам в составе "ПОЗЫВНОЙ"+SSID (12, HP, hp) по себе это атрибут АПРС-станции.

Да конечно. Только с той разницей, что ах25 лимитировал только до цифр 0-15 и поэтому в эти 16 вариантов пытались что-то оптимально распределить из придуманных "аппликаций".
Никто не запрещает нам для пейджерной работы в апрс "застолбить" -HP и -PG.

У объекта нет SSID вообще, может быть имя "ПОЗЫВНОЙ-12 (HP, hp)".

У объектов (тех пейджерщиков, кто отказался представляться позывным) будет "имя объекта" HFPGxxxx. Вроде это уже решил amx и в принципе логично.

PA- не занят, это серый квадрат с буквой P внутри. На aprs.fi видно хорошо и АПРС кенвуд это воспринимает точно.

Если не занят - нет возражений.

Если же есть минимальный шанс в будущем на двухсторонний обмен сообщениями- генерируйте АПРС-станции

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

зачем АПРС-станции вообще и головоломка легально/нелегально? Генерируйте АПРС-объекты с информативным комментарием

Блин, это что, просто спор ради спора?
С этого всё и началось - так вы мне месяц рассказывали, что вы то ли не можете, то ли не хотите фильтровать объекты, и хотите видеть обязательно станции.

Куда РЛ не целуй - везде жопа :-(

Или вы просто хотите видеть позывные в названии объекта, но не в качестве позывного станции?

Нет проблем - если пользователь пэйджера поставит тег
#;UA9OV-PG; - будет объект с именем UA9OV-PG и позывным гейта

Речь о об гейте ID-APRS, он умеет подключаться через пароль?

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

В любом случае, поле Destination пакета формируется как
Это неправильно, дестинейшен в общем случае - APRS.

Данунафиг, в это поле можно даже данные кодировать,
в MIC-E пакетах именно так это поле и используется.

А чаще всего оно используется как идентификатор программы и ее версии.

Так что от того, что он будет использоваться как идентификатор сети
(ну или программы AprsGate) - "PG" и
ID пэйджера - оставшиеся 4 символа, вреда не будет,
а польза - несомненная. Сохраняется ID пэйджера, не отнимая ни байта
от и без того короткого поля комментария.


Destination Address — This field can contain an APRS destination
callsign or APRS data. APRS data is encoded to ensure that the field
conforms to the standard AX.25 callsign format (i.e. 6 alphanumeric
characters plus SSID). If the SSID is non-zero, it specifies a generic
APRS digipeater path.

Не совсем понятно, как могут быть отдельно верные координаты, но не верное crc у комментария, вы что ли отдельные блоки контрольной суммы там ставите, не один на весь передаваемый блок?

Именно на блок с координатами - да, отдельная CRC, даже две.
Одна - на Lat/Lon , другая - на остальные GPS-данные (скорость,курс,высота,точность).
Чтобы самую важную информацию можно было получить, даже если
в комментарии ошибка (и ее можно из контекста мозгами исправить, в
отличие от координат).


И еще, может очень революционно, но все таки- нельзя-ли в самом алгоритме присваивания ID заложить принцип использования позывного?

Когда вы покупаете программу на Google Play, то продавец от вас вообще никакой
информации не получает. Купить программу, а потом переписываться с продавцом,
чтобы он вручную сгенерировал уникальный ID - и покупателю не интересно,
и продавцу жуткий геморрой.


А в-главных - ведение всяких глобальных "баз" или построение такой базы гейтом на лету -
вступает в сильное противоречие с принципом KISS

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

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



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

Есть база покупателей, а не их позывных.

Мало того, что она не предназначена для публичной идентификации,
а, наоборот, защищена всякими GDPR , ЗОЗПД и другими страшными словами,

но, как я уже говорил, при покупке программы через Google Play туда поступает только
уникальный ID покупателя (25 байт, завёрнутых в base64), из которого нельзя извлечь
никакой информации , и e-mail , который пользователь ввел при активации
программы (не обязательно настоящий).

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

Другой неочевидный плюс - при этом,
скажем на aprs.fi отдельно сохраняется последний комментарий (из пакета "/"),
и отдельно - последний статус (из пакета ">").

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

PA- не занят, это серый квадрат с буквой P внутри. На aprs.fi видно хорошо и АПРС кенвуд это воспринимает точно.

Попробовал - на aprs.fi выглядит отвратительно.

Тогда уж Pa (тот же красный ромб, что и сейчас, но с буквой P).

Как бы с автостоянкой не перепутали :-)

amx
Данунафиг, в это поле можно даже данные кодировать,
в MIC-E пакетах именно так это поле и используется.

Да, мик-е - исключение, это на стороне ах25.
В остальных случаях - ИД названия программы (или подсети, протокола, что по сути - тоже самое), вот сюда APHFPG и подходит идеально, чтобы было стандартно, как и у остальных APxxxx.

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

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

Именно на блок с координатами - да, отдельная CRC, даже две.

Оригинально, не встречал пока такого в р/л протоколах, надо взять на заметку.

Организуйте ведение такой базы для желающих,
закажите свою версию гейта

Могу взяться вести, не вопрос! Хотя, эта база уже есть на сайте nvis, зачем повторяться.
А что-то заказывать на платную разработку - извольте, для меня это всего лишь хобби. Да и теперь пообщавшись 100 раз подумал бы, прежде, чем у вас что-то заказывать даже на платной основе (даже не связанное с радио).

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

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

Как бы с автостоянкой не перепутали :-)

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

P.S. Смех смехом, а оказывается в том самом FT-8 тоже позывной кодируют по определенному псевдо-словарю, который ужимает с 6 до 4 байт! https://habr.com/ru/post/502374/