|
|
|
|
Por
EA3DXR, Toni Planas (Digigrup-EA3) INTRODUCCIÓN
Creado
por Bob Bruninga, WB4APR y presentado en la Conferencia de Comunicaciones
Digitales de TAPR/ARRL en 1.992, APRS es un protocolo de comunicaciones basado
en el AX.25 para la difusión de datos en tiempo real, de forma libre, a través
de una red. Su característica mas vistosa es el resultado de combinar
radiopaquete con un receptor GPS (Sistema de Posicionamiento Global),
permitiendo a los radioaficionados visualizar la posición de otras estaciones y
objetos en un mapa. APRS
es una modalidad diferenciada del radiopaquete: ·
Proporciona
mapas y objetos gráficos para localización móvil / personal, así como
meteorología en tiempo real. ·
Todas las
comunicaciones se realizan bajo un protocolo de “uno para todos” por lo que,
ante un nuevo evento, cualquier
estación es informada y actualizada inmediata y automáticamente. ·
Emplea únicamente
tramas AX.25 tipo UI (de información, no numeradas). A pesar de ello, soporta
mensajería en dos sentidos y distribución de anuncios y boletines. ·
Usa
digirrepetición a través de alias genéricos preestablecidos en un único
canal común, por lo que no se precisa conocer de antemano la topología de la
red para operar en ella. El radiopaquete es efectivo para el trasvase de información voluminosa
punto a punto, pero ha acarreado tradicionalmente dificultades para ser aplicado
a las comunicaciones en tiempo real, cuando aquella se hace obsoleta rápidamente.
Por ello el APRS rehusa la complejidad, los retardos y las limitaciones de una
red en modo conectado. No es un sistema pensado para el transporte de grandes
cantidades de información. No podría manejarla. Sin embargo es más ágil que
aquel y permite a muchas estaciones intercambiar datos entre si, como si de un
net de fonía se tratase. Cualquier estación que dispone de información,
simplemente la transmite y todo el resto la recoge. Por todo ello el APRS resulta especialmente indicado para casos de
eventos especiales y emergencias. ¿Donde están la ambulancia, la policía o
los bomberos? ¿Que temperatura se registra en varios puntos del país? ¿Donde
hay tormenta? ¿Donde hubo el apagón? ¿Donde está la cabeza de la marcha? ¿Donde
un atasco de tráfico? Etc.
etc. APRS WORKING GROUP El notable auge que está adquiriendo el Automatic Position Reporting System (APRS) conocido entre nosotros
como Sistema Automático de Información de Posición, aconsejó crear un
grupo de trabajo para fijar el protocolo y sus especificaciones. Ello debía
permitir seguir con la investigación y desarrollo de nuevas capacidades,
programas y utilidades, al tiempo que se aseguraba la compatibilidad entre lo
antiguo y lo de nueva generación, al disponer de unas bases comunes. Con esta idea, y bajo la tutela de TAPR
(Tucson Amateur Packet Radio), se
creó el APRS Working Group, que
integra a los principales desarrolladores: WB4ARP Bob Bruninga (ideador del
sistema y creador de dosAPRS), K4HG
Steve Dimse (javaAPRS, APRSserve, XLM
Serve), KH2Z Brent Hildebrand (APRS+SA),
N0QBF Mike Misick (pocketAPRS), WU2Z y
KB2ICI Keith y Mark Sproul (WinAPRS,
MacAPRS, X-APRS), así como a N8UR John Ackermann (responsable
administrativo), WA1LOU Stan Horzepa (Secretario) y WD5IVD Greg Jones (por TAPR).
Con alarde de pragmatismo digno de elogio, estos “gurús” superaron sus muy
respetables intereses personales para unir esfuerzos entorno a una causa común.
El
Protocolo de Referencia. El Grupo de Trabajo se nutre de las propias experiencias al tiempo que
analiza y recoge ideas y opiniones de los radioaficionados a través de una
lista de distribución y va evaluando los nuevos productos. Toda esta labor se
plasma en un documento revisado periódicamente y publicado por TAPR: APRS
Protocol Reference. De libre distribución, puede hallarse en http://www.tapr.org/tapr/html/aprswg.html
y formato PDF. Su versión 1.0.1 (agosto 2.000) contiene 115 páginas con
textos, profusión de tablas y ejemplos, claros y concisos. A la hora de redactar este artículo la experiencia nos ha demostrado
que, existiendo un alto y generalizado nivel de compatibilidad con el estándar,
no todas la utilidades disponibles (tanto en
soft como en
hardware) son 100% compatibles y responden correctamente a todas y cada una
de las especificaciones. Citaremos, a título de ejemplo, las disparidades en la
recepción de datos de meteorología o el empleo del camino genérico en el
campo de destino. Sin embargo, paulatinamente van apareciendo nuevas versiones
que se van adaptando a lo establecido. Ello viene a corroborar la importancia de
los trabajos del APRS Working Group. Este artículo basado en la lectura del citado documento y la propia
experiencia del autor, pretende ser sólo un resumen, a vista de pájaro, de las
principales características del protocolo con la pretensión de que el usuario
pueda comprender mejor y disfrutar de esa, por estos lares,
nueva modalidad de comunicaciones digitales. A quien desee profundizar más
en el tema no le queda otro remedio que leer detenidamente el APRS
Protocol Reference. Ello requiere dominio del inglés básico a nivel
escrito, conocimiento del protocolo AX.25 y cierta experiencia en el propio
sistema. FILOSOFIA
DE DISEÑO
Es importante remarcar que se trata básicamente de una herramienta
para comunicaciones en tiempo real, pensada para eventos especiales y
emergencias. Aunque el 99% del tiempo se va a emplear rutinariamente para el
mero entretenimiento. El sistema basa su eficacia en dos factores: fiabilidad y rapidez de
comunicación. Operando en el modo desconectado de AX.25, la integridad de las
tramas está garantizada, pero no así su llegada a destino. Por ello se
transmite la información de forma reiterada y redundante. Como se ha dicho, se
opera en canales únicos (en Europa 144.800 MHz). Estos principios, a priori
contradictorios entre si, resultan complementarios trabajando sobre la base de
un correcto equilibrio. La fluidez del canal se consigue utilizando tramas que, conteniendo
información precisa, ocupen el menor número de bytes posible y empleando
sistemas que eviten repeticiones innecesarias, a pesar de utilizar alias comunes
y genéricos. Tiempo
de ciclo del net.
Un primer concepto básico: el “tiempo de ciclo del net”, que es el
lapso preciso para que una estación recién incorporada a la red pueda disponer
de un dibujo completo de la actividad de su zona. Este tiempo varía de acuerdo
con las condiciones locales: orográficas, número de estaciones activas y los
acontecimientos del momento. El objetivo “ideal” es conseguir un tiempo de ciclo de 10 minutos.
Todas las estaciones deberían balizar su posición de acuerdo con este ratio,
dependiendo del número de saltos que vayan a efectuar sus tramas. Así se dan
estos criterios generales: ·
Operación
directa (sin emplear digirrepetidores): 10 minutos. ·
Saltando un
digi: 10 minutos ·
A través
de dos digis: 20 minutos. ·
Vía tres o
más digis: 30 minutos. Asimismo
los digis deberían balizar su posición utilizando diversos caminos, ajustando
su temporización a 10 minutos para informar a los usuarios locales y 30 minutos
para saltos de tres o mas digis. Si el tiempo del ciclo se prolonga mas allá de lo razonable, ello
provoca que las estaciones empiecen a impacientarse y a enviar tramas de
interrogación para conocer el estado de la red, lo cual redunda en una saturación
o “estrés” del canal innecesario. Temporización.
Lapso entre tramas. Para optimizar el envío de tramas redundantemente, utilizamos estos
algoritmos: Algoritmo
de desvanecimiento.-
Transmite una nueva trama cana n segundos. Dobla el valor de n para cada nueva
transmisión. Cuando n alcanza el valor del tiempo de ciclo, mantiene
este valor. Ratio
fijo.-
Transmite una nueva trama cada n segundos durante x veces y para. Mensaje
en cola.- Transmite una nueva trama de acuerdo con los algoritmos antes
mencionados. Si no se ha acusado recibo y el tiempo de ciclo ha sido rebasado,
es razonable pensar que la estación destinataria no está disponible. No se
emite una nueva trama hacia el destinatario si no ha sido confirmada la
precedente. Si mas tarde se escucha al destinatario, se intenta de nuevo. Caducidad.-
Este término se refiere al período de tiempo después del cual es razonable
pensar que una estación ya no está disponible si no se han escuchado tramas
suyas. Se sugiere un período de dos horas. Se emplea para refrescar la
información de la pantalla. APRS
Y AX.25 A nivel de enlace se emplea el protocolo AX.25, tal como está definido
en el Amateur Packet-Radio Link Layer
Protocol, mediante tramas de información no numerada (UI), exclusivamente.
Ello permite trabajar en modo desconectado, sin acuse de recibo. Por tanto la
recepción no está garantizada. En un nivel superior, APRS soporta protocolo de mensajería que permite
a los usuarios enviar líneas de texto a estaciones concretas, con acuse de
recibo. La
trama AX.25
Todas las transmisiones APRS utilizan tramas AX.25 UI con nueve campos de
datos:
Bandera.-
El campo de cada extremo es el bit 0x7e que separa una trama de otra. Destino.-
Contiene el destino APRS y puede albergar parte de la información. Está
codificado de tal forma que resulte compatible con el formato de indicativo estándar
AX.25 (p.e. 6 caracteres alfanuméricos mas SSID). Si el SSID es diferente a 0,
especifica camino de repetición genérica. Origen.-
Contiene el indicativo del originador. Si no se especifica en otros campos, el
SSID utilizado aporta el símbolo o icono con el que va a ser representado el
originador en los mapas. Digirrepetidores.-
Admite entre 0 y 8 indicativos o alias que pueden omitirse por un camino de
repetición genérica si se ha especificado en el destino. Control.-
Siempre 0x03 (Trama UI) Identificación
de protocolo.-
Siempre fijo a 0xf0 (sin nivel de enlace) Información.-
Contiene el grueso de la información APRS. El primer carácter es el
Identificador del Tipo de Datos, que especifica la naturaleza de lo que sigue. Secuencia
de Comprobación de Trama.-
Una secuencia de 16 bits usada para verificar la integridad de la trama recibida. CAMPO
DE DESTINO El campo de destino puede contener diferentes seis tipos de información: ·
Una dirección
genérica ·
Una dirección
genérica con un símbolo (icono) ·
La versión
de sofware empleado ·
Datos
comprimidos en formato Mic-E ·
QTH Locator
Maidenheat (obsoleto) ·
Una dirección
de net alternativo En
todos lo casos el SSID de este campo determina un camino genérico de repetición. Dirección
genérica.-
Pueden ser: ALL, AP, BEACON, CQ, GPS, DF, DGPS, DRILL, DX, ID, JAVA, MAIL, MICE,
QST, QTH, RTCM, SKY, SPACE, SPC, SYM, TAL, TEST, TML, WX, ZIP. Admiten
extensiones hasta 6 caracteres (ejemplo WX1, WX12CD serían campos válidos). Si
incorporan un SSID diferente de 0 implica repetición genérica APRS. Dirección
genérica con símbolo.- Enviando tramas a GPSxyz,
GPSCnn ó GPSEnn, logramos ser identificados con un símbolo (icono)
determinado. Donde “xyz”, “Cnn” y “Enn” corresponden a un código
específico en una tabla de hasta 255 símbolos (Ver tabla 3). Versión
del software empleado.- Si las tramas de dirigen a AP mas cuatro caracteres, es
posible indicar qué tipo de soporte se está empleando (hasta 16 posibilidades).
Ejemplos: APWxxx WinAPRS APXxxx X-APRS APKxxx Equipos Kenwood (API para Icom y APY para Yaesu) APZxxx Experimental Donde xxx correspondería al número de versión o modelo. Datos
comprimidos en formato Mic-E.-
Véase más adelante, en el capítulo dedicado a este formato especial. QTH
Locator Maidenheat.-
Aunque ya no se
usa, excepto en meteor scatter, se
mantiene para garantizar la compatibilidad con versiones anteriores. Por ejemplo:
UNPROTO TO JN01WS. Net
alternativo.-
Pensado para emplearlo en futuros desarrollos y experimentación. El
SSID en el campo de destino.-
CAMPO
DE ORIGEN. Usando el SSID para indicar el símbolo (icono) Todas las estaciones pueden escoger, de entre una amplia gama, con que
símbolo o icono van a aparecer representadas en los mapas de sus corresponsales.
Si no se especifica concretamente en el campo de información, puede emplearse
el SSID del campo de origen para ello. Ver tabla 3. SIMBOLOS
APRS Se reproduce de forma parcial algunos de los símbolos o iconos mas
usados en APRS.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||