Объект АПРС- он не самостоятельный участник сети. У объекта есть источник- станция АПРС, которая генерирует объект.

Разумеется.

В рассматриваемом варианте станция - это держатель шлюза "пэйджер -> ARPS", идентифицируемая РЛ позывным держателя, а объекты - пэйджерные маяки, идентифицируемые по их цифровым ID, типа
HFPG04001 .

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

Тело пакета - отдельный вопрос.
Я о том, что РЛ позывной здесь вообще не используется, и таких объектов - пол карты.

А у еще у немцев увидел странные позывные:

ER-DB0VEL>RXTLM-1,TCPIP,qAR,DB0VEL::ER-DB0VEL:UNIT.RX Erlang,TX Erlang,RXcount/10m,TXcount/10m,none1,STxxxxxx,logic
ER-DB0VEL>RXTLM-1,TCPIP,qAR,DB0VEL:T#542,0.00,0.02,0,1,0.0,00000000,SimplexLogic
EL-DL4OCH>RXTLM-1,TCPIP,qAR,DL4OCH::EL-DL4OCH:UNIT.RX Erlang,TX Erlang,RXcount/10m,TXcount/10m,none1,STxxxxxx,logic
EL-DL4OCH>RXTLM-1,TCPIP,qAR,DL4OCH:T#304,0.00,0.01,0,1,0.0,00000000,SimplexLogic

Ну тут хоть РЛ позывные просматриваются..

Да это тоже косяки, ER-, EL- - это эхолинк и репитер, должен как объект быть оформлен, а источник - просто позывной.

В рассматриваемом варианте станция - это держатель шлюза "пэйджер -> ARPS",

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

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

К сожалению, все пока не так.
Но подождем, шанс есть

Если станция называется шлюз, шлюзуя, она должна посылать не объекты, а станции из эфирной сети

Можем назвать ее и не шлюзом, а как-то по другому, SWL-post , например :-)

Хотя и не вижу причин, по которому шлюз (GATE) не может передавать сообщения произвольного типа из одной сети в другую и при этом не оставаться шлюзом.


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

Ну этого уж шлюз никому не должен. В разных сетях полно односторонних шлюзов.

У тех же немцев есть односторонние шлюзы (правда, противоположного направления)
APRS->POCSAG(любительский).

Да и понятие "RX-Only IGate" прямо определено в документах.

Но подождем, шанс есть

Шансов нет :-)

Хотите использовать "серый ID" - используйте демо-версию.
Благо андроидные версии (полная и демо) могут быть установлены на один смартфон одновременно
(и даже одновременно запущены, правда, будет некоторый бардак в списке сообщений),
и триал-период - не ограничен.

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

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

amx
Хотя и не вижу причин, по которому шлюз (GATE) не может передавать сообщения произвольного типа из одной сети в другую

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

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

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

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

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

Zmej +1

Zmej,
в моём варианте в РЛ сеть со свом позывным выходит держатель гейта,
публикуя в ней принятые маяки в качестве объектов.

А объекты, как вы хорошо знаете, в APRS-сети идентифицируются 9-символьным именами,
а не РЛ позывными.

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

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

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

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

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

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

amx
Если есть возможность, погенерируйте эти HFPG... объекты сейчас. Буду отрабатывать варианты их "вылавливания" у себя в терминальной программе.
И есть смысл выбрать какой-либо нейтральный символ для них, например Red dot (Красная точка)

SLYFOX
Да вот весь вечер генерировал, борясь с глюками системы.
Выяснил, что куча серверов то-ли вообще не принимают данных по UDP:8080 , то ли глючат
А некоторые и по TCP не принимают логина и отваливаются
Как жить с такой системой ... :-)

А aprs.fi не принимает объектов с "неизвестной позицией" (ну это где-то даже логично) и не
понимает "удаления объекта".

И "неточную позицию" тоже не принимает.
Впрочем, aprs.fi всего лишь один из клиентов APRS-сети, свет на них клином не сошёлся.

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


Насчет символа тоже задумался.
Может, /; взять (Portable)?

Правда, он в виде палатки отображается ...

amx
публикуя в ней принятые маяки в качестве объектов.

Да я это понял с самого начала. Ну, это так себе.
Все-таки полноценный гейтинг и обмен смс - это логично.

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

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

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

amx
Символ палатки тоже не к месту, как и символ ретранслятора сейчас, но не это главное, хотя с самого начала хотелось-бы видеть "красоту". Нужен символ универсальный, на все случаи применения, та же red dot-вполне. На будущее, если оно настанет для проекта, символ превратиться в традиционный и будет узнаваем.

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

Выяснил, что куча серверов то-ли вообще не принимают данных по UDP:8080
А зачем вам куча серверов? Остановитесь на российском, он точно по 8080 порту работает.Опять же, при желании можно и с админом связаться, что-то обсудить.

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

SLYFOX
Без данных о позиции вообще нет смысла ничего отправлять в сеть.

Скорее соглашусь, но хочется оставить возможность ретранслировать сообщение об
аварийной ситуации...

Сегодня-завтра почитаю описание АПРС, подумаю, может возникнут мысли какие....

Поигрался с фильтрами на приём - обнаружил, что куча народа гоняет телеметрию вообще
обычными сообщениями самому себе. Бардак ... :-)

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

Если уж мы делаем шлюз для обмена сообщениями , то разумнее шлюзовать в систему,
которая не требует постоянного присутствия абонента в онлайн. В e-mail, в GSM SMS ...

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

Выяснил, что куча серверов то-ли вообще не принимают данных по UDP:8080
А зачем вам куча серверов?

Так они сами приходят :-)

Я, как и рекомендовано, стучусь на rotate.aprs2.net , а на какой конкретно сервер попаду - непредсказуемо.

Впрочем, попробовал через HTTP POST на 8080 отправлять - работает стабильно,
если на russia.aprs2.net не отправлять напрямую. Тот сразу даёт отлуп. :-(

Но по крайней мере, в случае POST-запроса - легче всего контролировать фатальные ошибки,
есть явный ответ сервера.

Остановитесь на российском, он точно по 8080 порту работает.

К сожалению, не работает. Хотя на странице статистики утверждает обратное.
Через POST - не работает точно.
Да и штатно по tcp:145800 работает странновато.
Там какая-то необычная версия ПО стоит, видимо.

amx
К сожалению, не работает. Хотя на странице статистики утверждает обратное.
Я не знаю тонкостей работы со стороны серверов. Тем более вам есть смысл связаться с Sys op российского сервера.

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

Если в фильтр программы (APRSIS32, AprsDriod...) включить прием определенного объекта, то он должен быть если не уникальным, то редко используемым.
Или же собирать по шаблону HFPG*. Опять же, если в комментариях к "маяку" будет проходить информация о частоте для голосового вызова, то логично, что хочется иметь возможность гейтовать ее в локальный УКВ-АПРС эфир, для себя.

Все это частные случаи применения, как видится мне...

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

Вот именно это и нужно! Пришло сообщение с меткой аварийной ситуации, открыл карту - поехал спасать.

Я беспокоюсь о случае, когда ситуация настолько аварийная, что и GPS не работает.

Когда координаты есть - тут всё понятно

Или же собирать по шаблону HFPG*

Ну по крайней мере на стороне сервера это легко фильтруется по
#filter o/HFPG*

В программах, принимающих AX25 из эфира, полагаю, тоже должны быть подобные фильтры.

amx
Ну по крайней мере на стороне сервера это легко фильтруется по
#filter o/HFPG*
Построение фильтра не вызывает трудностей, нужно посмотреть как это будет выглядеть, сейчас просто нет времени и возможности.

В программах, принимающих AX25 из эфира, полагаю, тоже должны быть подобные фильтры.
Интересует прием на АПРС- радиостанцию по эфиру. Тут все зависит от настроек гейта "Сеть-Эфир". Тоже нужно посмотреть как будет работать.

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

SLYFOX
Пожалуйста,применяйте термин "сообщение АПРС", иначе СМС воспринимается как взаимодействие с сотовыми сетями

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

amx
Поигрался с фильтрами на приём - обнаружил, что куча народа гоняет телеметрию вообще
обычными сообщениями самому себе. Бардак ... :-)

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

Но пока не понял, зачем это нужно :-)

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

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

Я, как и рекомендовано, стучусь на rotate.aprs2.net , а на какой конкретно сервер попаду - непредсказуемо.

Так проблема с tcp соединениями или вы про udp-вариант? Обычно все пользуются tcp.
Сервер шлет время от времени проверочную строку, по ней можно проверять не отпало ли соединение и если что, то пересоединяться. Так же у вас должен быть скрипт, который после соединения проверяет, если от сервака тишина - тоже отрубать и через небольшой таймаут снова соединяться. Обычное дело ведь для tcp-клиента.


Тем не менее, вопрос стоит - стоит ли пересылать маяки без позиции или нафиг их,

Давайте примеры, какие именно маяки? Разберем ситуацию.

Так проблема с tcp соединениями или вы про udp-вариант? Обычно все пользуются tcp.
Сервер шлет время от времени проверочную строку, по ней можно проверять не отпало ли соединение и если что, то пересоединяться.

С TCP проблема не в проверке наличия соединения, а в том, что сервер не выдаёт никакой реакции
на то, что он распознал и отправил пакет.

А, скажем, russia.aprs2.net я уже ловил на том, что соединение он держит, а на команды нормально не реагирует.

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

Через UDP-посылать просто, но вообще никакого контроля нет.

Через HTTP POST - похоже, самый оптимальный вариант.
По крайней мере, знаем ответ сервера. Если 2xx - значит, сервер по крайней мере распознал пакет.


Тем не менее, вопрос стоит - стоит ли пересылать маяки без позиции или нафиг их,

Давайте примеры, какие именно маяки? Разберем ситуацию.

Те, о которых мы до сих пор говорили - маяки в терминологии HF Pager.

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

Пока вижу костыльный вариант - пересылать (в виде APRS-объектов) все маяки с GPS данными и те маяки без оных, которые имеют какой-нибудь признак чрезвычайности (например, восклицательный знак в теле сообщения). Но тогда придется отдавать "неизвестную позицию" "0000.00N\00000.00W."
Такой объект в APRS-сеть уйдет, но, скажем, aprs.fi его отвергнет.


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

amx
С TCP проблема не в проверке наличия соединения, а в том, что сервер не выдаёт никакой реакции
на то, что он распознал и отправил пакет.

Да, с этим обычно никто не морочится, в tcp варианте нет подтверждения о приеме, т.к. это как бы задача самого tcp протокола... Можно отслеживать соединение по наличию какой-то активности из сервера, а если ее нет, то он каждые 20сек шлет свою строку "# aprsc..." и т.д для проверки канала.


Те, о которых мы до сих пор говорили - маяки в терминологии HF Pager.

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

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

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

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

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

Пока amx разбирается с апрс или празднует праздники, удалось по тестировать этот вин-пейджер.

Кто-нибудь с IC-7300 гонял его? WinXP падает в синий экран при попытке перейти на передачу,
пришлось корреспонденту перейти на другой аппарат с обычным интерфейсом.

Сразу из пожеланий - нужно добавить РТТ через САТ команды!
Есть такие аппараты, где через USB-интерфейс только САТ-обмен или нужно САТ или РТТ выбирать в меню аппарата, это неудобно.
(когда по умолчанию на интерфейс настроен САТ и работает без вопросов с пол десятка других цифровых программ)

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

Так же просится мода с большей скоростью, для применения, когда нет проблем десятки Ватт мощности использовать.
Что там получится по скорости и минимальному S/N, если расширить MFSK-сигнал до полосы 500Гц?
Почему предлагаю 500 - это рекомендуемая максимальная ширина сигнала цифровых видов в многих странах,
шире делать - многие не смогут легально пользоваться, соответственно, интерес-спрос будет меньше.

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

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

И вопрос остался, где вы все крутитесь в этой моде? (частоты, время)
Программа больше предназначена для практического применения а не для связи ради связи.
Я тестировал с андроида на 3.570 и на 3.775.

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

Сгенерировал несколько позиций по историческим данным шлюза в Угличе.
Из-за того, что забыл убрать отладочный код, сначала свалил их все в свой QTH :-)

https://aprs.fi/#!mt=roadmap&z=11&call=a%2FHFPG05000%2Ca%2FHFPG65440%2Ca%2FHFPG00006%2Ca%2FHFPG00047%2Ca%2FHFPG00001%2Ca%2FHFPG00028&timerange=3600&tail=3600

amx
Сгенерировал несколько позиций по историческим данным шлюза в Угличе.
Я к сожалению, никак не могу попасть активность вашу. Буду готов наблюдать 6-7 мая в течении всего дня. Сможете?