ARLA/CLUSTER: Memórias "DR" dos ICOM e reflectores

[Pedro Ribeiro]

Bom dia (e ano),
Caros,

Sendo recente nestas coisas, em particular no modo DSTAR, faz-me 
confusão como as memórias de origem (DR) incluídas nos equipamentos mais 
recentes, não conseguem comunicar via reflectores.
Torna-se necessária a programação dos parâmetros dos repetidores numa 
das memórias gerais para que a comunicação via reflector funcione 
devidamente.

Quando me deparei com o problema, na primeira oportunidade falei com o 
Jorge Santos (CT1JIB) que é, como sabem, quem domina estas coisas.
Genericamente este explicou-me que as memórias do fabricante não 
enviavam correctamente a parametrização e que o problema podia ser 
torneado criando as memórias no banco de memórias gerais, o que fiz e 
resultou.
No entanto, eu que sou picuinhas com estas coisas, não deixa de me fazer 
confusão a situação que leva a um desperdício de recursos (espaço de 
memória) e perda de funcionalidade já que as memórias "DR" têm a 
informação de GPS associada o que permite que muitos equipamentos 
localizem automaticamente os repetidores mais próximos, algo que não 
está disponível nas memórias gerais.

Aproveitando uns dias de férias com maior folga de tempo (não muita), 
estive a realizar testes, emitindo DSTAR nas diversas situações e 
realizando a interpretação do protocolo num receptor SDR com as 
ferramentas disponibilizadas pelo colega IT9YBG
(ver: http://hamradio.selfip.com/i6ibe/hdsdr/dstar/dstar.htm )

Usando a informação que programei numa memória geral, a emissão é 
interpretada como:

> [TRANSMISSION HEADER NOR]
>     Flags       : 40 = VOICE REPEATER NORMAL opt=[None] , 00 00
>     Destination : CQ0DBA G
>     Departure   : CQ0DBA B
>     Companion   : CQCQCQ
>     Stn.Callsign: CT7ABP   / P
>
> NSYNC - User message: Pedro Ribeiro 73!

Os quatro campos de endereço aparecem como considero correctos, 
"Stn.Callsign" (oficialmente conhecido como MY CALL) com o meu 
indicativo que programei no equipamento (ID-31E), "Companion" 
(oficialmente UR CALL) com o destinatário da chamada (que por omissão é 
CQCQCQ quando não queremos especificar ninguém em particular), o 
"Departure" (oficialmente RPT1) como o identificador atribuído à porta 
de entrada do repetidor (o indicativo e mais o "B" para identificar a 
porta/receptor dos 70cm, para quem não sabe, por convenção a "A" é usada 
nos 23cm e a "C" nos 2m, caso existam também).
Finalmente o "Destination" (oficialmente RPT2), essencial neste caso, 
que identifica que a emissão sairá através da porta "G" que liga o 
repetidor a outros através de um gateway (o reflector), por IP, 
comunicação suportada pela Internet ou meios IP de amador (feixes 
"wireless").

Usando uma memória "DR" a emissão é interpretada desta forma:

> [TRANSMISSION HEADER NOR]
>     Flags       : 40 = VOICE REPEATER NORMAL opt=[None] , 00 00
>     Destination : CQ0DBA B
>     Departure   : CQ0DBA B
>     Companion   : CQCQCQ
>     Stn.Callsign: CT7ABP   / P
>
> NSYNC - User message: Pedro Ribeiro 73!

O parâmetro que se altera aqui é o "Destination" que aparece também com 
o identificador do repetidor local (CQ0DBA B) e que por tal não 
encaminha a emissão para o reflector.
De notar que a memória "DR" usada confirmou-se ter o gateway devidamente 
configurado, apenas não é usado; imagino que este comportamento seja um 
comprometimento com a forma como os equipamentos são pensados para 
funcionar, assumindo um cenário em que todos os equipamentos e software 
envolvidos são do mesmo fabricante.

Do que pesquisei na Internet, um colega (AB4BJ) fala numa solução para 
se conseguir o encaminhamento via gateway, solução que apesar de 
resultar (parcialmente), não me agrada e tem o resultado abaixo:
( ver: 
http://ab4bj.com/wordpress/2012/01/a-little-help-with-using-dr-mode-for-repeater-gateway-access-in-the-icom-ic-9100/ 
)

> [TRANSMISSION HEADER NOR]
>     Flags       : 40 = VOICE REPEATER NORMAL opt=[None] , 00 00
>     Destination : CQ0DBA G
>     Departure   : CQ0DBA B
>     Companion   : /CQ0DBAB
>     Stn.Callsign: CT7ABP   / P
>
> NSYNC - User message: Pedro Ribeiro 73!

Neste caso, após a selecção da memória "DR", o destinatário foi 
seleccionado como o próprio repetidor (podia ser outro) na opção 
"Gateway CQ", aparecendo o "Destination" conforme pretendido e o 
"Stn.Callsign" (UR CALL) como /CQ0DBAB, algo contemplado no protocolo do 
DSTAR para as chamadas que designam de grupo ou zona, neste caso 
dirigida ao repetidor indicado.
Se o repetidor em questão for distinto do de origem, confirmei que a 
comunicação é encaminhada, se for o mesmo, infelizmente não resulta no 
comportamento que desejava (de ecoar por todos os repetidores 
interligados na "sala").

Se não o fazem já (parece que não), se esta emissão lá chegar, os 
softwares de código aberto usados actualmente para suportarem os 
reflectores, poderiam detectar este padrão (o UR CALL ser igual ao RPT1 
sem espaços e prefixado do /) e assumir ser uma transmissão CQCQCQ, 
substituindo automáticamente o UR CALL pelo tipico CQCQCQ e encaminhando 
a emissão para os repetidores ligados à "sala".

Para já é o que consegui apurar e concluir, agradecem-se 
desenvolvimentos de quem saiba mais sobre o assunto ou faça progressos 
nos testes.

Nota: Os testes "offline" como podem vertificar foram realizados com 
100mW e o repetidor de Baltar ao qual daqui não se chega, para evitar 
incómodo. Fiz outros testes "online" usando os repetidores de Lisboa, 
Leiria e Setúbal pelo que peço desculpa pelo eventual incomodo das 
"patilhadas" usadas na recolha dos dados.

73!

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Callsign: CT7ABP
QRA: Pedro Ribeiro
GRID Locator: IM58mr
QTH: São Francisco, Alcochete, Portugal
NET:http://www.qrz.com/db/CT7ABP
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=