А что не понятно-то? фильтр *-12 выдаст все станции с -12, *-HP все из этой нашей темы.

И я о том же говорю, проблем с -HP (или другим буквенным ссидом) не должно быть, т.к. это более уникальный ссид, чем -12, которые уже используется в ТТ и вообще мало ли чем/кем. По символу фильтровать - тоже полу-мера, никому не запрещено любой символ(иконку) выбрать.

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

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

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

Ну почему, здесь всё штатно:


ALTNETS are uses of the AX-25 tocall to distinguish specialized
traffic that may be flowing on the APRS-IS, but that are not intended
to be part of normal APRS distribution to all normal APRS software
operating in normal (default) modes. Proper APRS software that
honors this design are supposed to IGNORE all ALTNETS unless the
particular operator has selected an ALTNET to monitor for.

An example is when testing; an author may want to transmit objects
all over his map for on-air testing, but does not want these to
clutter everyone's maps or databases. He could use the ALTNET of
"TEST" and client APRS software that respects the ALTNET concept
should ignore these packets.

An ALTNET is defined to be ANY AX.25 TOCALL that is NOT one of the
normal APRS TOCALL's. The normal TOCALL's that APRS is supposed to
process are: ALL, BEACON, CQ, QST, GPSxxx and of course APxxxx.

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

"как отфильтровать информацию от всех пэйджеров"
Так как раз это и интересно- увидеть всех кто работает через него

Так для этого unproto фильтр и служит
по DF APHFPG - замечательно фильтруется.

#filter u/APH*
#filter u/APH* active
# javAPRSSrvr 4.3.2b53 2020-05-21T14:14:09.108Z T2CAEAST 14580
# javAPRSSrvr 4.3.2b53 2020-05-21T14:14:29.108Z T2CAEAST 14580
# javAPRSSrvr 4.3.2b53 2020-05-21T14:14:49.108Z T2CAEAST 14580
PU5PBT-11>APHAX0,TCPIP*,qAC,T2BRAZIL:>SONDE - CWB/rs41
SQ5AAG-11>APHAX0,TCPIP*,qAC,T2FUKUOKA:>Radiosonda Meteo.
9A7KXP-6>APHAX0,TCPIP*,qAC,T2SWEDEN:>Test sistema praćenja WX Sonde
EA3IK-11>APHAX0,TCPIP*,qAC,T2NORWAY:>Sonda Igate
EA4JM-11>APHAX0,TCPIP*,qAC,T2HUN:>radiosonda madrid RS41
UA9OV-12>APHFPG,TCPIP*,qAO,UA9OV-PG:/211414z5500.74NP08256.54EaAprsGate 0.93 http://hfpager.com


Разве этого недостаточно?
В примере фильтр специально сделан более короткий, по трем первым символам.

amx
Разве этого недостаточно?
Нужно потестировать... Комбинация APHFPG появилась только вчера же. Это конструкция APHFPG закрепится в будущем? У меня есть сомнения, т.к это пересекается с чем-то уже, на память не помню- HAMHUD или что-то еще, в списке по ссылке есть.

amx
Ну почему, здесь всё штатно:

Имел в виду, что для апрс-приложений желательно AP*.
Потому, что остальное может как-то пересекаться с мик-е или просто быть неопознанным, чтобы не было проблем с ПО или оборудованием, ну как наткнулись уже на портативку.

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


SLYFOX
т.к это пересекается с чем-то уже

APHF*, APHP* пока свободно. http://aprs.org/aprs11/tocalls.txt

Разве этого недостаточно?
Нужно потестировать...

И главное - оно ведь для этого и предназначено (как одна из функций) - "групповой ID".

Комбинация APHFPG появилась только вчера же.

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

Идея про способ задания символа оператором пэйджера отторжения не вызывает?

Помониторил сеть - не-AX25 SSID довольно мало.

Есть однобуквенные (это какая-то левонет?),
и почему-то -16 .

Хотя пакеты от -HP aprs.fi нормально съедает.
Вот вопрос - как это потом до эфирных терминалов дойдет.
Но и всяко подводных граблей больше, чем со стандартными SSID...

amx

Идея про способ задания символа оператором пэйджера отторжения не вызывает?

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

Есть однобуквенные

Обычно это д-стар или другие ДМР (радиостанции оцифрованного голоса, у них тоже типа апрс встроенного есть).

и почему-то -16 .

Чей-то косяк или так захотели, на стороне сервера - побоку, хоть 99 задавай ссид.

Хотя пакеты от -HP aprs.fi нормально съедает.
Вот вопрос - как это потом до эфирных терминалов дойдет.

Оно все third-party пакетами должны идти.

А как пройдет форус на терминалах -выше просил slyfox погенерировать сообщения для таких позывных с буквенными ssid с его портативок, может не заметил вопрос или занят пока человек.
К примеру, UI-VIEW без проблем отправляет сообщения для позывных с буквенными ссид, смотрел на днях.

Поправьте меня, если я ошибаюсь :-)

Похоже, сегодня "нативный эфирный APRS" это не "то, что ходит в UI-фреймах",
а "то, что выдаёт и принимает данные в формате TNC2".

Те же -63, похоже, не заморачиваются с эмуляцией UI-пакета ...

К примеру, UI-VIEW без проблем отправляет сообщения для позывных с буквенными ссид, смотрел на днях.

Ну так чтож не отправить - это тупо 9-символьное поле в пайлоаде заполнить.

Вопрос - а вот примет ли она сообщение, переданное в third-party пакете...

Только настроил фильтр по u/APHFPG- наблюдаю...

amx
Есть прием и трансляция в эфир при отборе по признаку APHFPG, станция отображает корректно . Все через конструкцию APHFPG будет идти и объекты тоже? И позиции от HFPGxxx тоже? В этих APXXxx, xx-под номера версии т.е цифры должны быть, для информации.
Zmej
Сообщения в адрес позывной- HP уходят с портативки и далее.

Все через конструкцию APHFPG будет идти и объекты тоже?

Насчет объектов есть три возможных варианта:


1. DF у всех объектов - APHFPG

2. DF у всех объектов - PGyyyy

3. DF у объектов с именами HFPGxxxxx (сгенерированными из маяков без тега) - APHFPG,
у объектов с пользовательскими именами (заданными не-РЛ тегами) - PGyyyy

Что скажете, какой вариант нравится больше?

В этих APXXxx, xx-под номера версии т.е цифры должны быть, для информации.

Ну это не обязательно, в том же списке http://aprs.org/aprs11/tocalls.txt
куча и без цифр, и с фиксированными цифрами.

Для AP* - лучше уж застолбить уникальную комбинацию (APHFPG).
А для PG* - там всем всё равно (пока другая ALTNET на PG* не появится).

Сообщения в адрес позывной- HP уходят с портативки и далее.

А наоборот - приходят?
сейчас для пробы руками покидаю

amx
Все что имеет отношение к р\л через APHFPG (или варианты)
все остальное через PGxxx. Тогда будет разделение уже на уровне сети APRS-IS, что облегчит фильтрацию на гейтах и терминалах. Так будет самое верное на мой взгляд. Будут-ли "объекты для потомков" ломиться в эфир? Наверное, но они не нужны по сути в локальном эфире. Надо посмотреть на практике опять. Генерируйте еще и объект какой-либо для теста...

сгенерировал несколько раз
UA9OV-PG>PG0001,TCPIP*:;HFPG44001*300133z5501.21NP08256.92EaTest of HF Pager Gate

amx
У меня программа определяет признак APHFPG как изделие HamHud.
А вообще идея с фильтром через u/APxxxx и другой альтернативной сетью самая правильная похоже, нужно еще понаблюдать и за объектами. Оставляйте в тесте на все выходные генерирование всего, на буднях времени нет.

Все что имеет отношение к р\л через APHFPG (или варианты)
все остальное через PGxxx

Ну я тоже к такому варианту склоняюсь

Будут-ли "объекты для потомков" ломиться в эфир?

Ну если и будут, то уже из за кривой настройки гейта в эфир.

He could use the ALTNET of
"TEST" and client APRS software that respects the ALTNET concept
should ignore these packets.

С моей стороны пули в этом случае вылетают - я указал, что это левонет :-)

сгенерировал несколько раз
Ну у меня под него фильтр не готов, я его не вижу просто.... Считаю, что этой серии объектов достаточно появиться на Aprs.fi и там они будут отображены 100%.

amx
Поправьте меня, если я ошибаюсь :-)

Похоже, сегодня "нативный эфирный APRS" это не "то, что ходит в UI-фреймах",
а "то, что выдаёт и принимает данные в формате TNC2".

Те же -63, похоже, не заморачиваются с эмуляцией UI-пакета ...

Нативный апрс - это как раз УИ-пакеты ах25.

А любая апрс-технология, подключающаяся к апрс магистрали - работает в условном tnc2 формате, фактически в текстовом, без спецкодов.

А обратно в эфир с ах25 - только через third-party формат.
При не ах25 эфире - в текстовом tnc2 формате или его вариации.

Вопрос - а вот примет ли она сообщение, переданное в third-party пакете...

Должна принимать, иначе ни одно апрс текстовое сообщение не читалось бы, поступающее из гейтов в эфир и принимаемое портативками. Все гейты из апрс магистрали в сторону эфира на ах25 работают в third-party, это стандарт.

DF у объектов с именами HFPGxxxxx (сгенерированными из маяков без тега) - APHFPG,

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

SLYFOX
У меня программа определяет признак APHFPG как изделие HamHud.

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

Оставляйте в тесте на все выходные генерирование всего, на буднях времени нет.

Ну это надо или программу специально для тестирования написать,
или в онлайне одновременно вдвоем потестить...

Zmej
Обращайтесь к разработчику вашего терминала
Терминал это программа APRSIS-32 которая уже наверное первое место заняла по применению в АПРС и инфа видна будет не только у меня ,а у всех пользователей. Меня это как раз таки и не волнует совсем.

SLYFOX

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

Опубликовал AprsGate 0.94

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

V0.94
Кроме адреса основного APRS-шлюза, можно ввести два запасных.

Сам гейт теперь анонсируется в APRS-сети пакетами типа Position
(раз в 20 минут) и Status (раз в 30 минут). Используемый символ
самого гейта - "/r" (антенна).

В РЛ-тегах теперь допустим любой двухсимвольный SSID,
содержащий только символы 0...9 или A...Z

Поле "Dеstination" для всех пакетов типа "объект" (;)
формируется как PGXXXX , где XXXX - шестнадцатеричный
ID пэйджера.
V0.93
Поле "Dеstination" для всех пакетов изменено на "APHFPG".


Сейчас "на столе" тестируется гейт UA9OV-PG , через который маячит UA9OV-HP .

amx

Поле "Dеstination" для всех пакетов типа "объект" (;)
формируется как PGXXXX , где XXXX - шестнадцатеричный
ID пэйджера.

Это неправильно. По логике, должен быть у технологии один общий деcтинейшей.
ИД пейждера и так в имени объектов остается, если кому-то надо только слепышей-партизан фильтровать, это можно по маске имени объекта делать как 'HFPG*'.

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

Как проходят буквенные ссиды - будем смотреть, спасибо за включение тестовых маяков.
За одно, если не сложно генерируйте в периодическом режиме сообщение для теста, например от UA9OV-HP для UA9OV-1 , как для условного апрс-пользователя на ах25.

Сегодня- завтра есть возможность наблюдать с трансляцией в УКВ, как и ранее.
Используемый символ самого гейта - "/r" (антенна).
Если это гейт, то и используйте символ гейта- черный ромб, можно с буквой какой-то, можно G как с КВ и RX-Only. Это из разряда внешнего вида на работу не влияет, но все же. Если гейты появятся, то будут-ли они отвечать на стандартные запросы о кол-ве сообщений, дальности и т.д.? Нужно потестировать, в общем можно наблюдать какую-то динамику по пакетам, может будет полезна такая статистика. По командам всяким вида ?IGATE и т.д, могу позже расклад дать, если нужно.
В РЛ-тегах теперь допустим любой двухсимвольный SSID,
содержащий только символы 0...9 или A...Z
Опять таки лишнее, тем более все буквы. На приемной стороне, особенно по УКВ эфиру будет потеря информативности о том что принято т.к большинство SSID предполагает обмен сообщениями. -11 зонды и воздушные шары, кто-то их отфильтровывает по признаку *-11 и получит совсем не зонд или шар воздушный. Пока не обмен не реализован, вполне хватит и -12 и - HP. Вроде пришли к мнению этому уже...

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

Опять таки лишнее, тем более все буквы.
Сделал для возможности экспериментов, чтобы попробовать разное можно было.


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


В чем отличие маяка UA9OV-HP должно быть?
Ну вот это и вопрос - проходит ли UA9OV-HP в эфир или нет?


Сейчас в эфире два гейта работают:

UA3AHM-PG в Угличе и RT9K-PG в Тарко-Сале

Ну вот это и вопрос - проходит ли UA9OV-HP в эфир или нет?
В эфир проходит, на Kenwood все проходит и иконка и все остальное, на Yaesu приходит буквенный SSID как -??, остальная информация есть вроде.

Сейчас в эфире два гейта работают:
UA3AHM-PG в Угличе и RT9K-HP в Тарко-Сале
От RT9K-HP нет информации, кроме информации о нем самом. Или гейт не принимает или что-то с настройками самого гейта, не знаю как там и что, но такая строчка в комментарии > APRS Gate @ xxxxx+1.7 kHz.
От RU3ALT-12 обновляется только статус, пакет с позицией не приходит.

RT9K сменил SSID на PG для единообразия и указал частоту

От RU3ALT-12 обновляется только статус, пакет с позицией не приходит.

У него GPS не подключен.

У него GPS не подключен.
Так и подумал.
...на Yaesu приходит буквенный SSID как -??
Лишний раз доказывает, что SSID станции все таки должен быть в указанных цифровых пределах. Возможно, что даже специфический SSID - 63 и др. будет виден на Yaesu правильно, т.к. заложен в "мозгах" станции изначально.
Предлагаю остановиться на -12 для самого КВ-пейджера, это отображается везде и правильно по описанию АПРС и не придумывать ничего нового. Гейт тоже -12 или же -1, 2 и т.д. Раз отработано фильтрование через u/APHFPG, то что за SSID у гейта уже и не важно по сути.
В имени объекта может быть произвольный текст, но я уже забыл что у нас под "объектами" подразумевается...
Можно грешить на старую прошивку в Yaesu, конечно, но отображение -?? вместо букв, скорее всего будет и на других устройствах.