DPlus, DExtra и DCS: что это и с чем это едят...

В нашей среде многие, кто занимается или хочет заниматься D-STAR (даже на этом форуме) неоднократно спрашивают, что такое DPlus, DExtra и DCS, в чём их разница, зачем они нужны.

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

Со времен запуска первых репитеров D-STAR на ICOM RP-1C не существовало технологии рефлекторов для D-STAR.
Для покрытия этой проблемной области AA4RC разработал собственное ПО dplus, встраиваемое в ПО шлюза от ICOM.
ПО dplus как раз и является оригинальной реализацией протокола DPlus.
DPlus - это надстройка над ICOM-омовским протоколом репитеров (DSVT), передающий принятый из эфира DV-поток между шлюзами и рефлекторами. Вся надстройка предназначена для покрытия следующих задач:

• реализация логического соединения (вы можете "законнектиться" в рефлектор). Прим: протокол DSVT не имеет таких возможностей;
• примитивная аутентификация/авторизация узла, поддержание соединения (пулинг, так как соединение является логическим).

DPlus обеспечивает не только работу с рефлекторами, но и call-routing (так же доступный на DSVT).

Все это прекрасно, но DPlus немного сложноват и сильно завязан на инфраструктуру Trust Server.
Таким образом, узлы, находящиеся вне инфраструтур US Trust (K5TIT), Multi-Trust не имеют доступа к общим ресурсам рефлекторов. Ещё одной, не менее острой проблемой DPlus является закрытость кода утилиты dplus и отсутствие какой-либо документации на протокол (забегая вперёд скажу, что отсутствие спецификаций - это проблема всех трёх протоколов, да и большей части около DSTAR-овских технологий).

Имея все эти проблемы в ходе разработки своего G2-Gateway с открытым кодом KI4LKF предложил новый протокол собственной разработки: DExtra.
DExtra существенно "легче" DPlus, в нём отсутствует какая-либо завязка на Trust Server.
То есть, узлы, работающие в DExtra не обязательно должны быть где-то зарегистрированы.

Появление ircDDB лишь укрепило позиции DExtra, DExtra используется для call-routing на узлах вне X-Trust/Multi-Trust.

Кем разработан DCS у меня точной информации нет, но я предполагаю, что это сделал DL1BFF.
Не стоит питать иллюзий, DCS - это немного расширенная версия DExtra.
Отличий всего два:

1. сообщение ответа на пуллинг стало включать позывной рефлектора, что, в принципе, позволяет реализовывать несколько рефлекторов на одном сервере;
2. да новый контейнер для передачи потока. DCS больше не испольует DSVT, заголовок и данные потока передаются в каждом сообщении (каждые 20 миллисекунд).

Это позволяет начать транслировать передачу с середины без какого-либо сложного анализа (я имею ввиду разбор потока SlowData, ICOM-овские станции регулярно дублируют заголовок передачи в SlowData). Минус DCS - высокая перегруженность этого потока - на передачу фрейма из эфира в 12 байт по IP тратиться минимум 100 байт.

О практическом использовании DCS. К сожалению, в настоящий момент DCS используется только ограниченным числом программ и только для работы с рефлекторами. Это происходит потому, что:

1. в ircDDB остуствует какая-либо информация о поддерживаемых узлами протоколах (определить необходимость передачи в DPlus возможно только обратившись к Trust-серверу);
2. DCS поддерживается только рефлекторами проекта xreflector.net, чей код является закрытым и не распостраняется;
3. различия DCS и DExtra не существенны, нет значительных мотивов для перехода.

Вот так в кратце о протоколах. Если интересна тематика ircDDB - могу тут продолжить.

Цитата:

---

Сообщение от UB3ABM

Если интересна тематика ircDDB - могу тут продолжить.

---

Да, и поподробнее. Очень доходчиво получилось начало, спасибо!

Цитата:

---

Сообщение от UB3ABM

Со времен запуска первых репитеров D-STAR на ICOM RP-1C

---

наверное правильно нужно было бы обозначить так: ICOM ID-RP1C ?

Цитата:

---

Сообщение от UB3ABM

интересна тематика ircDDB - могу тут продолжить.

---

Конечно интересно! Непременно рассказывай...

Ну хорошо. Тогда продолжим.

Селективные вызовы в D-STAR - это и преимущество и недостаток.

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

Недостаток - на репитерах D-STAR нет возможности разделять частоты (FDMA), а в рамках несущей - время (TDMA). Иными словами, при селективной передаче ресурс репитера монополизируется одним пользователем. Это, кстати, одна из причин, по которой крейне рекомендуется call-routing реализовывать на дуплексных репитерах.

Идея call-routing проста - ровно как в сотовой сети вы не знаете, к какому репитеру подключен ваш корреспондент, знаете лишь позывной ближайшего репитера. В новой станции ICOM ID-31 такая функциональность доведена до блеска - на флеш-карте станции хранится файл со списком репитеров, репитер выбирается по геопозиции, полученой со встроенного GPS-приёмника станции.

При смене позиции ваша станция инициирует передачу на репитер (ну или вы сами нажимаете PTT), таким образом она регистрируется на репитере.

Я точно не знаю, как изначально появился call-routing на ID-RP1C, но эта функция реализована в ПО RS-RP2C и ПО pdplus. В настоящий момент времени вся информация о регистрациях (в инфраструктуре ICOM) передается на Trust Server, доступ к которому жёстко модерируется.

В ранних версиях ПО (generation 1 - G1) была реализована множественная репликация данных между узлами и это приводило к тому, что информация о регистрации узлов могла реплицироваться вплоть до пары часов.

Первый и основной Trust Server был создан командой K5TIT и, как ясно из позывного, находится в штате Техас, США.

Многим радиолюбителям за пределами США не нравилось, что информация о их местоположении "сливается" в США, что привело к организации X-Trust / Multi-Trust. На самом деле краеугольным камнем тут является не то, что техническая площадка находится в Техасе, а что она удалена и при её недоступности (авария на площадке, проблемы на каналах связи) страдают все узлы D-STAR, на которых предоставляется call-routing.

В общем, в Европе появился свой независимый X-Trust, "общения" с которым у US-Trust не было.
Для решения вновь появившейся проблемы немцы из Georg Simon Ohm University of Applied Sciences (DB0FHN) предложили свою разработку - ircDDB.

Своей идеей реализации ircDDB обязан ботнетам - для передачи команд используется старая, как весь Интернет, технология IRC.

IRC - это не что иное, как чат-сервер с функцией релея, благодаря которой сервера можно масштабировать горизонтально, разнеся их географически. Одна группа серверов в США, другая в Европе - все они объеденены группой чатов.
Каждый репитер/шлюз является ботом в чате dstar. Практически при каждой новой передаче шлюз передает информацию о маршруте другим ботам через сервера IRC.
Информация передается внутри географических регионов и реплицируется на уровне опорных узлов ircDDB. Таким образом обеспечивается высокая производительность и надёжность решения. Хранение операционных данных о маршрутах производится локально на узлах. Теперь становится понятна вторая часть названия системы DDB - distributed database (распределенная база данных).

Я умеренно употребил слово "боты", потому как получателем сообщения о факте передачи (heard) является не весь чат-канал, а боты-серверы ircDDB (ircddbd).
Задачами ircddbd являются:
- кэширование таблиц маршрутизации позывных и видимости;
- обработка входящих сообщений heard;
- подготовка статистики для чат-канала статистики;
- нотификация всех узлов в канале об изменении таблиц маршрутизации и видимости.

При регистрации станций ircddbd сразу сообщает всем узлам, на каком репитере зарегистрирована станция. А при изменениях таблицы репитеров - нотифицирует все узлы о её изменении.
Задача управления и раздачи списка узлов решается штатным функционалом серверов IRC - все узлы являются пользователями IRC.

Теперь о связи Trust и ircDDB. Всем узлам, базирующимся на ПО RS-RP2C предлагается установить ircDDB Add-on, подключающий эти узлаы к ircDDB. Таким образом ircDDB покрывает маршрутные таблицы всех Trust-сетей.

Как это работает на практике?

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

Вот так вот происходит QSO.

Остались вопросы по терминологии. И я думаю не только у меня.
Позволю их озвучить:

1. Что такое DSVT ?
2. Откуда пошло слово Trast ? Что это такое? Что оно означает?
3. Что такое US Trast, Multi Trast, X-Trust, Trust Server ?
4. Что такое G2-Gateway?
5. Что такое Xreflector ? reflector (рус: рефлектор) - это что - конференция или виртуальное некое образование, др. словами - сервер, комната, группа по интересам, группа по территориальному признаку? Какой смысл вкладывают в это понятие те, кто его применяет здесь в этом контексте, т. е. именно применительно к технологии D-Star?

DSVT - это "родной" протокол ПО ICOM RS-RP2C для передачи потока DV в IP-сетях.
Он часто упоминается как "протокол RP2C" или "протокол ICOM", внутреннее название протокола в ICOM нам неизвестно. DSVT - это его сигнатура (частая практика - называть протоколы по их сигнатурам)

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

US Trust - это доверительный сервер, развернутый в США, с помощью которого обеспечивается обмен трафиком в американском сегменте D-STAR. Присутствие US Trust выражено очень явно, так как в США репитеры преимущественно основываются на оборудовании ICOM.

X-Trust - это развернутый немецкой командой альтернативный доверительный сервер в Германии

Multi-Trust - так же немецкая инициатива по развертыванию множества доверительных серверов. С 2011 года инициатива свернута в пользу ircDDB. Таким образом сейчас есть только два доверительных сервера - американский и немецкий.

G2-Gateway - это общее название второй версии ПО ICOM RS-RP2C и оборудования репитеров второго поколения. Ключевым отличием ПО от первого является механизм обмена данными по роутингу, а оборудования - модульная организация шлюза в виде компонентов для 19" стойки. Репитер первого поколения ID-RP1C был моноблочным.

Reflector - отражатель. В применении к УКВ-репитерам - групповая конференция, объединяющая несколько репитеров. Связь, как правило, производится через Интернет. D-STAR тут не исключение.

xreflector.net - немецкая площадка, на которой размещаются все сервера рефлекторов стандарта DCS и какое-то количество рефлекторов стандарта DExtra (XRF). ПО (dextra-ng) закрытое и не распостраняется.

Подобно EchoLink рефлекторы в D-STAR имеют некоторую семантику позывного, и так же как в EchoLink-е репитер можно слинковать (подключить) с тем или иным рефлектором. В настоящий момент, размещенные на xreflector.net рефлекторы разделены по географическому и языковому критериям. На некоторых рефлекторах производится авторизация по позывному шлюза.

И ещё вопрос: US Trust сервера, они поддерживают возможность работы со всеми тремя протоколами DPlus, DExtra и DCS или нет?

Trust Server-ы - это только DPlus из перечисленного. DPlus очень сильно под это заточен.
В то же время DExtra работает вне среды с доверительным сервером. Поэтому все ПО не-ICOM репитеров использует DExtra при работе с узлами, незарегистрированными в Trust.
Повторюсь, что DCS в настоящий момент используется только для рефлекторов, так как в ircDDB нет возможности определить список поддерживаемых узлом протоколов.
Таким образом, узлы, зарегистрированные в Trust обязательно обладают реализацией DPlus, а работающие с ircDDB - DPlus и DExtra.

Цитата:

---

Сообщение от UB3ABM

.......
.....
Как это работает на практике?

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

Вот так вот происходит QSO.

---

...тут есть "непонятки".
Репитер это одно, а симплексный узел это несколько другое.
Как симплексный узел (node), может информировать серверные боты, если у него нет доступа к ircDDB (скажем это мой вариант) ?
Мне кажется понятия репитер, узел, шлюз надо конкретизировать.
Какие у каждого полномочия прежде всего?

Евгений! Не совсем соглашусь с вашим доводом.
Действительно, в тексте выше понятия репитер/шлюз/узел идут вперемешку, но для общего повествования они развнозначны. Симплексный узел является частным случаем репитера (об этом я расскажу ниже). Более того, весь программно-аппаратный комплекс узла в документации ICOM называется ни больше ни меньше, чем "репитер" или "система репитера".

Давайте остановимся на этом поподробнее.

Узел (node) - это комплекс автоматической радиопередающей станции. Если рассматривать оригинальное решение от ICOM (ID-RP2 D-Star Repeater System), то узел состоит из следующих компонентов:

• модулей дуплексных репитеров (ID-RP2D, ID-RP2V - для DD и DV режимов в диаппазоне 23 см, ID-RP2L - для транка в диаппазоне 10 ГГц, ID-RP2000V и ID-RP4000V для режима DV в диаппазонах 70 см и 2 м),
• контроллера репитеров ID-RP2C
• шлюза, реализуемого на компьютере с ПО RS-RP2.

Любые компоненты в этом списке, кроме RP2C, опциональны. Транкинговых репитеров может быть подключено до двух штук.
Функционально каждый модуль репитера реализует дуплексный приём и передачу сигнала, а также модуляцию (встроенный GMSK модем).
Контроллер обеспечивает селекцию вызова и его повторение на любом из модулей, то есть маршрутизацию внутри узла.
Как мы знаем, каждый модуль имеет свой порт на контроллере:

• A - DV на 23 см
• B - DV на 70 см
• C - DV на 2 м
• D - DD на 23 см

Вы их указываете в маршруте на станции в полях REP1, REP2 - входной модуль и выходной модуль.
Также на контроллере есть зарезервированная буква для IP-транспорта - G.
Весь трафик на модуль G отправляется по IP на ПО шлюза.

Шлюз, в свою очередь, обеспечивает "шлюзование" трафика в IP-мире - взаимодействует с другими шлюзами, с Trust Server, скрывая топологию дальнейшего маршрута вашей передачи от вас.

Теперь перейдем к "нашим баранам": не ICOM-овском решении.
Наш узел состоит минимум из АФУ, радиостанции, GMSK-модема и компьютера с ПО.
Функцию модуля репитера у нас выполняет одна-две радиостанции в связке с GMSK-модемом.
Функция контроллера при этом разделяется между микроконтроллером на GMSK-модеме и ПО репитера (управление передачей, формирование IP-пакетов), ПО шлюза (маршрутизация между модулями узла в таком решении возлагается на шлюз) на компьютере.

Для начала давайте всё рассмотрим на примере ПО узлов от G4KLX и KI4LKF.
Оба комплекта ПО от G4KLX и от KI4LKF явно реализуют функции интерфейса репитера и шлюза в виде разных программ.
Вы используете ту программу репитера, которая наиболее подходит вам - одна работает с ICOM-овскими контроллерами, другая с сатошевсками GMSK-модемами, третья - с DV-RPTR, четвертая реализует репитер на звуковой карте, ну и так далее. Программа репитера отвечает только за передачу на радиоинтерфейсе. За маршрутизацию отвечает ПО шлюза.

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

Теперь давайте про симплекс поговорим.
Симплекс нисколько не отменяет факта того, что узел реализует функцию репитера.
На симплексном узле реализуется "режим попугая" (parrot repeating) - каждая передача в рамках несущей ретранслируется после её приёма.

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

На самом деле доступ к ircDDB сдерживается исскуственно, причины я огласить тут не вправе. :)

Ну что, подготовить вам ещё рассказик про SlowData и D-PRS?

(Народ, хором): Подготовить! Подготовить! :)

Раз пошла такая пьянка, продолжаем разговор!

Как вы, возможно, знаете, передача "цифрового голоса" DV в D-STAR осуществляется непрерывным потоком со скоростью 4800 бод. В начале каждой передаче станция отдаёт заголовок, содержащий данные о маршрутизации вызова и контрольную сумму заголовка. Далее следует непрерывный поток с данными аудио-кодека (DV).

Поток разбивается на фреймы по 12 байт.
9 байт занимают данные кодека AMBE.
При этом данные для коррекции ошибок FEC "встроены" в эти 9 байт и учитываются чипом кодека аппаратно.
Оставшиеся три байта отведены под синхронизацию.

Согласно базовой спецификации от JARL данные синхронизации передаются каждый 21-й фрейм. Таким образом, базовая спецификация никак не использует доступные 1142 бода из всей полосы в 4800 бод.

Этим самым 1142 бодам ICOM нашёл применение. Это так называемые Slow Data. Название родилось в радиолюбительской среде, офицальных публичных спецификаций на эту тему от ICOM не было, понимание того как оно работает получилось на основании обратного инжиниринга протокола.

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

Тип блока указывается неспроста. В Slow Data мультипликсируется несколько потоков ниформации:

• Повторение данных заголовка
• Free-Text
• Данные с последовательного порта станции / GPS
• Данные цифрового шумодава

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

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

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

Ну а теперь самое интересное - данные с последовательного порта станции. Изначальная задача - просто обеспечить передачу потока данных между двумя станциями. Естественно, первое, для чего это стали использовать - передача данных GPS-приёмника в формате NMEA. Имея GPS-данные было бы неплохо их и в APRS передавать. :)

Просто ретранслировать GPS-данные не интересно. В position report-ах APRS содержиться ещё масса полезной информации - SSID станции, её символ, текстовый коментарий. Всё это привело к появлению D-PRS.

D-PRS - это не самостоятельный протокол. Это расширение команд NMEA для передачи сообщений AX.25 в формате TNC-2 с контрольной суммой (для проверки целостности пакета) и без нарушения семантики NMEA. На станциях ICOM такой режим называется GPS-A. Вы настраиваете все параметры APRS на станции, она транслирует пакет по Slow Data. Шлюз, получив такой пакет проверяет его на соответствие контрольной сумме и ретранслирует в интернет-сегмент APRS. К сожалению, канал в обратную сторону на станциях ICOM пока не реализован, хотя технически проблем нет это сделать без изменения или созданий каких-либо стандартов.

Ну и в дополнение про D-PRS Calculator (aprs-is.net/DPRSCalc.aspx). Есть старые станции ICOM, на которых нет режима GPS-A. Такие станции содержат дополнительную настройку "C1 message". Эта настройка определяет суффикс, которым будет дополняться каждое отправляемое NMEA-сообщение от GPS-приёмника.

Авторы D-PRS Interface придумали некоторый синтаксис для этого сообщения, с помощью которого можно определить столь желаемые дополнительные параметры для формирования APRS Position Report - SSID, символ, комментарий.
D-PRS Calculator позволяет "рассчитать" такое сообщение, заодно добавив к нему контрольную сумму, которую D-PRS Interface проверяет.

Обращаю внимание на то, что ПО D-PRS Interface нужно только для ситуаций, если вы хотите ретранслировать позиции корреспондентов в APRS и такая функция не поддерживается штатно ПО вашего узла. То есть с последними версиями WinDV и G4KLX его использовать не нужно.

Цитата:

---

Сообщение от UB3ABM

Раз пошла такая пьянка, продолжаем разговор!

Как вы, возможно, знаете, передача "цифрового голоса" DV в D-STAR осуществляется неприрывным потоком со скоростью 4800 бод. В начале каждой передаче станция отдает заголовок, содержащий данные о маршрутизации вызова и контрольную сумму заголовка. Далее следует неприрывный поток с данными аудио-кодека (DV).

Поток разбивается на фреймы по 12 байт. 9 байт занимают данные кодека AMBE. При этом данные для коррекции ошибок FEC "встроены" в эти 9 байт и учитываются чипом кодека аппаратно.
Оставшиеся три байта отведены под синхронизацию.

Согласно базовой спецификации от JARL данные синхронизации передаются каждый 21-й фрейм. Таким образом, базовая свецификация никак не использует доступные 1142 бода из всей полосы в 4800 бод.

---

Глубоко роете :) Откуда такие познания? Интересует литература. Где взять?

Google и Yahoo Groups. :)
Помимо гугла - исходные коды G4KLX, KI4LKF, DL1BFF; переписка с G4KLX, DL3OCK, DG8NGN; трассировка всех опиcанных в этой теме протоколов, прототипирование, тестирование собственной реализации протокольного стека для D-STAR.
Литературы, если вас интересует именно реализация, целостной нет.
Задавайте вопросы - ответим. :) Не сможем сами - посоветуемся с товарищами. :)

Цитата:

---

Сообщение от UB3ABM

......
......
Тип блока указывается не с проста. В Slow Data мультипликсируется несколько потоков ниформации:
- Повторение данных заголовка
- Free-Text
- данные с последовательного порта станции / GPS
- данные цифрового шумодава

......

Ну а теперь самое интересное - данные с последовательного порта станции. Изначальная задача - просто обеспечить передачу потока данных между двумя чтанциями. Естественно, первое, для чего это стали использовать - передача данных GPS-приемника в формате NMEA. Имея GPS-данные было бы неплохо их и в APRS передавать :)
........
D-PRS - это не самостоятельный протокол. Это расширение команд NMEA для передачи сообщений AX.25 в формате TNC-2 с контрольной суммой (для проверки целосности пакета) и без нарушения семантики NMEA. На станциях ICOM такой режим называется GPS-A. Вы настраиваете все параметры APRS на станции, она транслирвет пакет по Slow Data. Шлюз, получив такой пакет проверяет его на соответствие контрольной сумме и ретранслирует в интернет-сегмент APRS. К сожалению, канал в обратную сторону на станциях ICOM пока не реализован, хотя технически проблем нет это сделать без изменения или созданий каких-либо стандартов.

Ну и в дополнение про D-PRS Calculator ( http://www.aprs-is.net/DPRSCalc.aspx ). Есть старые станции ICOM, на которых нет режима GPS-A. Такие станции содержат дополнительную настройку "C1 message". Эта настройка определяет ссуфикс, которым будет дополняться каждое отправляемое NMEA-сообщение от GPS-приемника.
Авторы D-PRS Interface придумали некоторый синтаксис для этого сообщения, с помощью которого можно определить столь желаемые дополнительные параметры для формирования APRS Position Report - SSID, символ, коментарий. D-PRS Calculator позволяет "расчитать" такое сообщение, заодно добавив к нему контрольную сумму, которую D-PRS Interface проверяет.
Обращаю внимание на то, что ПО D-PRS Interface нужен только для ситуаций, если вы хотите ретранслировать позиции корреспондентов в APRS и такая функция не поддерживается штатно ПО вашего узла. То есть с последними версиями WinDV и G4KLX его использовать не нужно.

---

...да, инфо очень обстоятельное и полезное, как говорится "непонятно, но здорово!".

Теперь о моем (наболевшем) -вопросы:
1. В моей станции (ICOM ID-880) есть режим GPS-A, следовательно никаких С1 message, с помощью вышеупомянутого калькулятора формировать не нужно, - надо просто установить GPS-A?
2. Надо выбрать (в меню) скорость порта DATA (в DV mode, но не в PAkET mode !), - 4800, т.е. на которой работает мой модуль GPS ?
3. Чтобы ретранслировать на APRS сервер position корреспондентов, "подошедших на узел" все-таки ПО D-PRS (D-PRS интерфейс - aprs-is.net/DPRSInterface.aspx ) - нужно?
4. И последнее, если с GPS модуля на вход DATA трансивера поступают каждую секунду "стринги", но на дисплее станции координаты не отображаются, что делать-то, где копать?

Цитата:

---

Сообщение от UA5AA

1. В моей станции (880) есть режим GPS-A, следовательно никаких С1 message, с помощью вышеупомянутого калькулятора формировать не нужно, - надо просто установить GPS-A?

---

Да

Цитата:

---

Сообщение от UA5AA

2. Надо выбрать (в меню) скорость порта DATA (в DV mode, но не в PAkET mode !), - 4800,т.е. на которой работает мой модуль GPS ?

---

Да, скорось должна соответствовать той, что поддерживается модулем. Это всего лишь скорость последовательного интерфейса.
Packet Mode - это режим внешнего TNC, никак не связаного с DV. К тому же последовательный порт и гнездо пакетной передачи - разные разъемы на станции.

Цитата:

---

Сообщение от UA5AA

3. Чтобы ретранслировать на APRS сервер position корреспондентов, "подошедших на узел" все-таки ПО DPRS (DPRS интерфейс - http://www.aprs-is.net/DPRSInterface.aspx ) - нужно?

---

Если вы используете WinDV - не нужно. Настройки подключения к APRS-IS есть в самой программе.

..все понял, не понял только почему не работает...:search:


...вынул все из авто и положил на стол - еще раз попробую...

Цитата:

---

Сообщение от UB3ABM

Как мы знаем, каждый модуль имеет свой порт на контроллере:
* 'A' - DV на 23 см
* 'B' - DV на 70 см
* 'C' - DV на 2 м
* 'D' - DD на 23 см

---

А что такое модуль 'E' ?
Почему ты его не упоминаешь ?
Мне кажется что буква 'E' - это обозначение модуля ID-RP2L (10 GHz Link Repaeter).
Показываю блок-схему базового D-STAR узла каким его видел ICOM в 2006 году.
На этой картинке я отметил красным шрифтом обозначение каждого модуля.
Не у дела остаётся модуль 'E'. Вот и прошу - развей сомнения, насчёт модуля 'E', что же это?

Читаем документацию - http://www.icomamerica.com/en/downlo...x?Document=158
Я не разу не видел модуля E на репитерах! На сколько мне известно, 10 ГГц репитеры прозрачны.
Обычно обозначение E имеет виртуальный модуль эха в dplus, предназначеный для эхо-теста

Цитата:

---

Сообщение от UB3ABM

Я не разу не видел модуля E на репитерах!

---

Вот показываю на примере REF001.
См картинку.
Место под модуль Е оставлено, правда сам модуль Unlinked (не подключен).

Сергей, это модули рефлектора

Хорошо, если это модули рефлектора, то и что же они обозначают тогда ?
Показываю другой пример: репитерный узел IR3UEF.
Тут мы тоже видим модуль E.

Цитата:

---

Сообщение от UA3IRS

Хорошо, если это модули рефлектора, то и что же они обозначают тогда ?
Показываю другой пример: репитерный узел IR3UEF.
Тут мы тоже видим модуль E.

---

Я уже писал, что Е - это эхо

Добавлено через 12 минут
В общем так.

В базовая спецификация D-STAR определяет длинну позывного строго 8 знаками, неиспользующиеся знаки в конце заполняются пробелами. В самой спецификации понятие "модуль" отсуствует.
Поскольку первые репитеры выпустила ICOM, очевидно именно они воспользовались даннной ситуацией и стали использовать для обозначения модуля 8-й символ позывного.
Как уже многократно писалось, семантика обозначения модуля на репитерах ICOM строго ограничена и жестко распределена между функциями.
А далее... Далее каждый разработчик во что горазд. Где-то L и U - это подключение к рефлектору и отключение, E - это эхо и так далее. Просто общая практика, аналогично тому, как дела с SSID обстоят в APRS-е.

Стоп, стоп, стоп!
А что же тогда обозначает символ '*' ?

В продолжение темы о DPlus.

Информация далее может пригодиться разработчикам и глубоко интересующимся :)

Еще ряд измышлений и трассировки привели меня к одному забавному выводу:
контейнером для сообщений в DPlus является... ASCP. Тот самый Amateur Station Control Protocol, который применяется на DV Dongle, DVAP, RF Space...
Значит, смотрите, вот точные соответсвия:
1. Link/Unlink - соответствует сообщениям ASCP SET CTRL STATE = RUN / STOP
2. Пуллинг - ASCP ACK, аналогично тому, как сделан WatchDog на DVAP
3. Передача данных DV-потока (внутри - DSVT) осуществляется сообщениями ASCP DATA0
4. Передача сигнальных сообщений DPlus - в сообщениях ASCP DATA2.
5. Само собой, биты длины сообщения соответсвуют фактической длинне данных.

Теперь пытаюсь понять назначение некоторых полей в сигнальных сообщениях DPlus... Струкрура сообщений известна, но некоторые поля заполняются непонятными константными значениями.
Trust-сервер работает так же на ASCP/DPlus.

Еще желающие поковырять есть?

И так, спустя полгода :)

На US Trust только сервер авторизации DPlus работает на DPlus.

А еще в октябре ребята из XReflector выкатили на публику CCS.