|
|
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.
DIGIRREPETIDORES
(“digis”) Conforme a las especificaciones del protocolo AX.25 puede expresarse un
camino de hasta 8 repetidores para mandar a través de el una trama “VIA”,
aceptándose los alias. En APRS, si no se ha especificado SSID en el campo de
destino, debe utilizarse el campo vía para lograr la repetición. Camino
nominal.- VIA
EA3XXX,..., EA3ZZZ La trama será repetida por únicamente por los digis de la lista, según
el orden preestablecido por el operador. Si el siguiente en la cadena no recibe
la trama, se interrumpe el camino. Cada digi, antes de reexpedirla al éter,
incorpora a la trama junto a su indicativo el byte de escuchada (representado
por un asterisco) para identificar en todo momento al repetidor. Camino
genérico.- Los
repetidores utilizan alias genéricos para que no sea preciso conocer la topología
de la red de antemano, para poder operar en ella. Una estación móvil desplazándose
a través del país no debe de preocuparse por conocer qué frecuencia se emplea
en una determinada comarca, ni las repetidoras a su alcance. Luego no tiene
necesidad de manipular su equipo, para seguir operativo. RELAY.-
Cualquier estación puede responder al alias de RELAY (Repetidor). Las otras
pueden utilizarla como digirrepetidor. Las estaciones HF emplean ECHO en vez de
RELAY. WIDE.-
Los digis situados en puntos geográficamente prominentes, destinados a cubrir
largas distancias, utilizan el alias de WIDE. También responderán a RELAY. TRACE.-
Cada digi WIDE tiene la habilidad de substituir el alias. Mediante ella se
autoidentifica en las tramas que repite substituyendo con su propio indicativo
los alias RELAY, WIDE o TRACE. Ello permite conocer quién ha repetido una trama
y el camino seguido por esta. Ejemplo de camino genérico: VIA RELAY, WIDE, WIDE Cualquier operador APRS que tenga el digi de su sistema activado o
cualquier digi de amplia cobertura, la repetirán. En un segundo salto será
repetida por el resto de digis de amplia cobertura que reciban la primera
repetición. Si los repetidores tienen activada la función de substitución de
alias (muy recomendable) cambiarán el alias por su propio indicativo junto al
bit de escuchada. Tomando la trama del ejemplo, repetida por los digis EA3XXX, EA3YYY y
EA3ZZZ, por este orden, veamos su aspecto en los distintos saltos: Primer salto: EA3XXX*, WIDE, WIDE Segundo salto: EA3XXX*,EA3YYY*,WIDE Tercer salto: EA3XXX*,EA3YYY*,EA3ZZZ* Si en vez de RELAY o WIDE se hubiese empleado TRACE, aunque los digis
no tengan activada permanentemente la substitución de alias,
TRACE ( VIA TRACE, TRACE, TRACE) lo fuerza con idéntico resultado. Camino
genérico con SSID. WIDEn-N.-
(Ver Tabla 1). Mediante este sistema cada digi sustrae al SSID N, el valor de 1
al retransmitirla. Cuando N alcanza el valor de 0, ya no es repetida de nuevo.
Ello permite a un operador indicar cuantos saltos desea que efectúen las tramas
por el emitidas. El número n sirve para conocer en todo momento el número de
saltos con que se originó la trama. Se conserva en memoria el checksum
(secuencia de comprobación de trama) de las tramas repetidas durante los últimos
28 segundos (por defecto) para no volver a repetirlas. Ejemplo:
VIA WIDE4-4.- Primer salto: VIA
WIDE4-3. Segundo salto: VIA WIDE4-2. Tercer salto:
VIA WIDE4-1. Cuarto y último salto VIA WIDE4. Podemos ordenar hasta 7 saltos (SSID entre -1 y -7). A partir del SSID
-8 y hasta el -15 la trama se enrutará de acuerdo con lo expresado en la tabla
1. TRACEn-N.-
El comportamiento es exactamente el mismo que WIDEn-N, adicionándole la función
de substitución de indicativo, por la cual cada digi añadirá su indicativo
con el byte de escuchado a la cadena de digirrepetición. Ejemplo:
VIA TRACE3-3 Primer salto: VIA
EA3XXX*,TRACE3-2 Segundo salto: VIA
EA3XXX*,EA3YYY*,TRACE3-1 Tercer y último salto: VIA EA3XXX*,EA3YYY*,EA3ZZZ*,TRACE3 La diferencia entre los diversos métodos (incluido el de SSID en el
campo de destino) radica en el ahorro de bytes en trama. El que más ahorro
comporta es el del SSID en el campo destino. Del camino genérico sin SSID ó
del método TRACEn-N, pueden resultar tramas excesivamente grandes en caminos
largos. Sin embargo, puede ser interesante para observar las rutas entre
diferentes puntos. El camino nominal puede utilizarse de forma efectiva en
algunos casos tales como mensajería, pero precisa un conocimiento explícito de
la red. Como criterio general se recomienda a los móviles utilizar el método
WIDEn-N. En cuanto a las estaciones fijas, dependerá de la topología de la red
y del número de digis “wide” a los que se tenga acceso o el interés del
operador hacia donde propagar sus tramas. La resultante puede ser una combinación
de varios métodos, atendiendo siempre a la recomendación de adecuar los lapsos
de envío de tramas y número saltos según los criterios expresados en el
apartado de tiempo de ciclo del net. CAMPO
DE INFORMACION Tiene la siguiente distribución:
Identificador
del tipo de datos.- Cada
trama APRS contiene un Identificador del tipo de datos que preceden. Este
determina el formato del resto de la información siguiente. La tabla 3 (que se
transcribe parcialmente) refleja los más comúnmente empleados.
Los
datos.- Existen
10 tipos principales: ·
Posición ·
Dirección
de localización ·
Objetos e
ítems ·
Meteorología ·
Telemetría ·
Mensajes,
boletines y anuncios ·
Interrogaciones ·
Respuestas ·
Status ·
Otros Algunos
de ellos pueden incorporar más datos en el subcampo de extensión. Extensión.-
Con una
codificación precisa, responde a estos diferentes tipos: ·
Rumbo y
velocidad del objeto o vehículo ·
Dirección
y velocidad (del viento en reportajes meteorológicos) ·
Potencia,
altura, ganancia y directividad de la antena ·
Cobertura
pre-calculada (del sistema emisor) ·
Intensidad
de la señal recibida (en radiolocalización) ·
Descripción
del área del objeto Expresión de una de estas magnitudes
Caracteres 1-3: PHG (fijo)
Carácter 4: potencia en patios
Carácter 5: Altura sobre el nivel del suelo, en pies
Carácter 6: ganancia en dB
Carácter 7 directividad Expresados según la siguiente codificación:
Ejemplo: PHG5132
Indica una potencia de 25 wats
La antena está a 20 pies del nivel del suelo, tiene una ganancia de 3 dB
y
está orientada al este (90 grados) En el caso de Intensidad de la señal recibida, para radiolocalización,
la fila correspondiente a la se permuta por la lectura del Smiter (“Santiago” del código RST), y los tres primeros caracteres se fijan a DFS, así:
Ejemplo: DFS2360
indica una débil señal (“Santiago” 2), recibida en una antena
omnidireccional de 6dB, ubicada a 80 pies. Se utilizan para cálculos de radiolocalización y cobertura. Pensemos
que es relativamente sencillo automatizar la lectura del “Smeter” del
receptor en base, por ejemplo, a un conversor analógico/digital como el que está
desarrollado para nodos TheNet X1J. Comentario.-
Se utiliza opcional y básicamente con un texto a elección del operador. En
algunos casos especiales puede incorporar además datos adicionales APRS tales
como: ·
Altura ·
Locator
Maidenhead ·
Datos de
radiolocalización ·
Grosor de
la línea del área de un objeto ·
Datos
meteorológicos ·
Otros Ejemplo: utilización en reportajes meteorológicos c
Dirección del viento en grados s
Velocidad media del viento (en el último minuto) en millas por hora g
Mayor racha de viento registrada en los últimos 5 minutos, en millas por
hora. t
Temperatura en grados Fahrenheit r
Precipitación acumulada en la última hora en centésimas de pulgada P
Precipitación acumulada el las últimas 24 horas en centésimas de
pulgada h
Humedad relativa (0 a 100%) b
Presión atmosférica en decenas de milibar L
Luminosidad (vatios por metro cuadrado) hasta 999 l
(ele minúscula) Luminosidad por encima de 999 s
Precipitación de nieve durante las ultimas 24 horas (pulgadas) #
Datos primarios de un contador de precipitación El formato utilizado es: carácter + 3 posiciones para datos (4 en la
presión). Si no se utiliza pueden substituirse por puntos o espacios. Ejemplo: g013t074P000b0120h69
representaría que la racha de viento más fuerte fue de 13 mph, 74º F, sin
precipitación acumulada las últimas 24 horas, una presión de 1200 milibares y
humedad relativa del 69%. FORMATOS
DE TIEMPO HORARIO Y POSICION Tiempo
horario.-
Puede expresarse de diferentes formas: ·
Día/Hora/Minutos.
En zulú (UTC/GMT) o local. 092345z
23 horas 45 minutos zulú del día 09 092345/
23 horas 45 minutos hora local del día 09 ·
Horas/Minutos/Segundos.
Precedido de “h” 234517h
23 horas 45 minutos 17 segundos, zulú ·
Mes/Día/Horas/Minutos 10092345
23 horas 45 minutos 17 segundos, zulú, del día 9 de Octubre Siempre en escala de 24 horas. Esta información se utiliza, entre otros menesteres, para actualizar
la recibida por cada operador y efectuar limpieza de datos antiguos u obsoletos.
Cuando una estación transmite datos sin los horarios, la receptora utiliza los
del reloj de su ordenador. Posición:
Latitud y Longitud.- La latitud se expresa con 8 caracteres fijos en grados y
minutos con dos decimales, seguido del indicador de hemisferio (N ó S). Por
tanto los segundos no se expresan como tales, sino como centésimas de minuto.
La posición incorpora el icono identificativo. Ejemplo: 4903.50N equivale a
49 grados, 3 minutos, 30 segundos, norte. La longitud se expresa en 9 caracteres (3 de ellos para los grados) e
idéntica composición para minutos y segundos, seguidos de la posición
respecto al Meridiano 0 (E ó W) Ejemplo: 00235.75E equivale
a 2 grados, 35 minutos, 45 segundos, este. Cambiando los minutos o los segundos por espacios, se entrega una
posición ambigua, aceptada por el sistema. La combinación de ambas posiciones tendría este formato: 4903.50N/00235.75E- Latitud seguida del carácter “/”
(tabla de símbolos primarios, ver tabla 2), longitud precedida del carácter
“-” (Casa VHF, según la tabla
2). Datos
NMEA.- Se
reconocen las cadenas ASCII de datos primarios conforme a la especificación
NMEA 0183, Versión 2.0, correspondientes a las siguientes sentencias: ·
GGA ·
GLL ·
RMC ·
VTG ·
WPT FORMATO
DE LAS TRAMAS Existen un amplio abanico de formatos debido a la versatilidad del
sistema, su función y origen, imposible de resumir aquí. Por ello solo se
reproducen diagramas de algunos de los más comunes. Recordemos que se utiliza el campo de información (1 a 256
bytes) de la trama UI AX.25 que tiene la siguiente disposición:
TRAFICO
A TRAVES DE TERCERAS REDES APRS dispone de un mecanismo para formatear tramas que puedan ser
transportadas a través de terceros (p.e. redes no AX.25), tales como Internet,
LAN Erhernet o conexiones alámbricas directas. Como estas redes no reconocen el
origen, el camino ni el destino, estos se deben empaquetar junto al resto de la
información como datos y reconstruirlos a la recepción. Primero se prepara la cabecera de origen:
Es recomendable emplear la el substitución de alias por indicativo,
para poder identificar exactamente el camino de origen, especialmente para casos
de mensajería. Así en la trama del ejemplo, sería: G6WVL>APRS,G9RXG*,WIDE: Cuando la trama sale “al otro lado” procedente de una tercera red,
la estación gateway receptora la
modifica insertándole el identificador de “tráfico vía terceros” :
} antes de introducirla en la red local APRS.
Acto seguido la trama es remitida a la red local APRS por la gateway
receptora, informándole un camino a su elección. Este sería el resultado: EA3RKU-3>APRS,ED3ZAG* : }G6WVL>APRS,G9RXG,TCPIP,EA3RKU*:=5329.20N/00236.20W-John.Golborne INFORMACION
COMPRIMIDA Con el fin de ahorrar la máxima cantidad de bytes posible y obtener
tramas que, aún conteniendo toda la información básica, sean cortas y ágiles,
APRS prevé unos formatos de compresión de datos. Por su complejidad debido al
uso de diversos algoritmos y tablas, merecerían un capítulo aparte. Aquí solo
vamos a dar una breve reseña de ellos. Datos
de posición comprimidos.- Mediante
este sistema, una trama de posición con campo de extensión que ocupa 26 bytes,
queda reducido a la mitad (13): 4 para latitud y 4 para longitud (descomprimidos 8 y 9 respectivamente) 2 para la extensión (descomprimidos 7) 1 para el tipo de compresión (descomprimido no se utiliza) 2 para el símbolo y su tabla (los mismos que descomprimidos) Se opera con algoritmo base 91: a partir de cifras fijas
preestablecidas a las que se les adiciona o resta respectivamente longitud y
latitud, se las reduce sucesivamente por potencias de 91, hasta que el resto es
menor de 91. Cada paso nos da una cifra que equiparamos al código ASCII, añadiéndole
previamente 33, para que el resultado sean caracteres imprimibles entre el 33 y
el 124. Para obtener el tipo de compresión, se utiliza una tabla matriz de códigos
“0” y “1” que nos proporcione un resultado binario, transformándolo
luego a decimal y añadiéndole a su vez 33, previo a su conversión ASCII.
Formato
MIC-E (Mic Encoder).-
Su nombre proviene de un desarrollo soportado en PIC que distribuye TAPR. En
reducido espacio se puede disponer de un módem más codificador APRS adaptable
a un GPS y a cualquier transceptor de mano o base. De gran aceptación entre el
colectivo, utilizan también el sistema MIC-E el PIC-Encoder (otro desarrollo
TAPR), MIM/MIC-Lite (APRS Engineering), Pico Packet (PacComm) y los conocidos
TH-D7 y TM-D700 (Kenwood), entro otros, especialmente aquellos destinados a uso
móvil. Mas complejo que el anterior y con mayor ahorro de espacio, en MIC-E
los datos comprimidos y repartidos entre los campos de destino e información.
Ello permite que una trama elemental completa ocupe solo 25 bytes (descontando
el STC y la bandera). El
campo de destino en MIC-E.-
Manteniendo su compatibilidad con las especificaciones del AX.25 (7 caracteres
ASCII imprimibles) este campo incorpora: ·
6 dígitos
para Latitud. ·
3 bits para
el identificador de mensaje. ·
Indicador
de hemisferio y Este/Oeste. ·
“Offset”
de Longitud (según esta sea superior o no a 100 grados) ·
Camino de
digirrepetición genérica.
Todo ello codificado en base a una tabla que, por brevedad, no se
reproduce. Los mensajes predefinidos de MIC-E se detallan en la Tabla 4.
puede resultar extraño que se prevean mensajes estándar. Piénsese
que este sistema está ideado para estaciones móviles con capacidad operativa
limitada. Bien sea por el equipo que utilizan, bien sea por la situación en que
se encuentran (conduciendo, etc.). Este tipo de mensajes pueden ser fácilmente
seleccionables con la acción, por ejemplo, de un conmutador sobre una matriz de
diodos. El
campo de información MIC-E.-
Contiene lo siguiente: ·
Longitud
comprimida. ·
Rumbo y
velocidad comprimidos. ·
Símbolo y
Tabla de símbolos. ·
Campos
opcionales como Telemetría, “status”, locator, altura comprimida. Codificadas
en base a sendas tablas que proporcionan resultados numéricos a los que se
adiciona 28 para obtener al correspondiente carácter ASCII y que la mayoría
sean imprimibles. La longitud se expresa en grados (G), Minutos (M) y centésimas
de minuto (cM). La altura (expresada opcionalmente en el campo “Status”) no
se codifica mediante tablas, sino en base 91.
Este
es el aspecto de una trama enviada por una estación móvil operando TM-D700: EA3FUU-12>TQ3SP3,EA3RDG-15*,WIDE4-3 <UI R Len=37>:'x]5l"B>/]"6.}-Josep/Sabadell QRV R5 Podría
prescindir aún de varios bytes: El de SSID puesto que el símbolo (turismo) ya
lo facilita el campo de información. Y el del camino y la substitución de
alias, introduciendo SSID en el campo de destino. Si manda la trama así,
probablemente sea debido a que desea diferenciarse de la estación activa al
mismo tiempo en su QTH (sin SSID) y
a que no todos los digis empleados son compatibles con el SSID en el campo de
destino, por el momento. CONCLUSION Mediante
esta ínfima trama, capaz de prosperar incluso en una red saturada y alcanzar en
pocos segundos, saltando varios digis, zonas
geográficas distantes, podemos determinar: indicativo, símbolo, situación,
estado, velocidad y dirección de la estación emisora. Nombre y población del
operador. Conocer que podemos contactar con el mediante un determinado reemisor
analógico. Nuestro sistema lo posicionará exactamente sobre el mapa, nos
indicará la distancia a que se halla respecto de nuestra estación y el rumbo
hacia donde orientar la antena. Un
sistema APRS anexo a un repetidor analógico, a parte de permitir a
sus usuarios identificarse en la red mediante una trama de cola
inaudible, ofrece la posibilidad a sus responsables de conocer en todo momento
datos tales como: estado de carga de baterías, intensidad proporcionada por los
paneles, si el suministro de la red se interrumpió, detección de presencia o
estados de abierto/cerrado. Eso
por citar dos ejemplos. ¿No les parece sencillamente
eficaz? Septiembre-2000 |
Última modificación: 16/12/2001
|