Estructura...

La estructura de la trama que he implementado en mi tracker (AQM_TRK) es la siguiente:

En ella, están todos los campos obligatorios y aunque la trama puede tener un tamaño mayor dependiendo de los datos que se envíen el el campo Information Field he dejado los campos mínimos por cuestions de recursos del microcontrolador que he utilizado y que sólo tiene un 1K de memoría de programa.

El Flag como ya sabemos es un byte "01111110" que se envía en la práctica unas 32 veces por motivo de sincronización del receptor y además porque al transmitirlo se perderan los primeros bits o bytes. En mi diseño lo envío 32 veces, son un total de 32 x 8 = 256 bits. Como cada bit a 1200 baud tiene una duración aproximada de 833 microsegundos, la duranción total del Flag de inicio es de unos 213 milisegundos.

El Destination Address (7 bytes), que en el caso de otro tipo de paquete APRS iría el indicativo de la estación destinataria del paquete, en MIC-E se codifican datos de la posición.

En el primer byte se codifica el primer dígito de la Latitud más el primer bit del mensaje de estado (bit A), el mensaje de estado son tres bits que definen 8 posibles estados, el que yo envío es el mensaje "En Route", existen otros mensajes de estado como: In Service, Off Duty, Priority, etc...

La latitud debemos manejarla en formato ggmm,mm (grados, minutos y centésimas de minuto). Ejemplo: 40º 23,51" N. El mensaje "En Route" que es el M1, corresponde al valor binario 110 (bit A, bit B y bit C)

La codificación es en ASCII y tenemos varias tablas con valores del 0 al 9 para la codificación de la Latitud y con distintos valores para la codificación de otras informaciones que veremos a continuación:

El primer byte codifica las decenas de grado, en este caso el 4 y según las tablas, el 4 pude representarse con dos caracteres: el 4 (bit A=0) y la T (bit A=1), dependiendo el valor del bit A, que en este caso vale 1 y por tanto, el primer byte será la T. El segundo byte será codificado con la letra P que representa el 0 con bit B=1. El tercer byte será codifcado con el 2 que representa 2 decenas de minuto y el bit C =0.

Así seguimos codificando, según la especificación de APRS y obtendremos al final:

TP2SUQ

Nos faltaría el séptimo byte que explicaré al final...

La codificación de los bytes(4-6) codifican los datos restantes de la latitud (3,51), pero además utilizando los valores de las distintas tablas se añaden otros datos.

En el byte 4 el indicador Norte/Sur de la latitud. El byte 5 además codifica el llamado offset de la longitud, esta última codificada en el Information Field. El Offset sirve para determinar el valor de la longitud ya que ésta se codifica utilizando 3 bytes y utiliza tablas que se solapan de forma que un valor puede atender a dos valores ASCII de longitud sólo distinguibles por el Offset. El Offset puede tomar valores de +0 ó de +100, el Offset será de +100 siempre que la longitud no esté comprendida entre 10 y 99 grados ya que el Offset tomará entonces valor +0.

En definitiva el Offset es un mecanismo que permite reducir el número de bytes en la codificación de la longitud, pensad que los caractertes ASCII que se manejan sólo llegan al 127 y la longitud tiene el formato: gggmm,mm. Es decir manejamos de 0º a 179º. Con el Offset podemos representar con los mismos caracteres ASCII de 10º a 99º con offset +0) y de 110º a 199º (realmente hasta 179º) con offset +100.

El byte 6 se aprovecha para codificar el indicador West/East (Este/Oeste) de la Lonfigtud.

El byte 7 indica el CRRSSID0 (7 bits), está descrito en la Especificación de AX.25, es un campo de la trama y en nuestro caso MIC-E siempre será: 01100000.

Intentando explicarlo:

CRRSSID0 (bit7-0)
C (bit7) indica Comando/Respuesta, aunque también se utiliza para determinar el protocolo de la TNC, sabiendo si es antiguo porque C=0 tanto en Source Address como Destination Address.

Las versiones (V.2.X) envían valores alternos en Source y Address, cuando el valor es 1 en Source se interpreta Respuesta y cuando es 0 en Source, es comando.

R (bit6-5) son bits reservados y se ponen siempre a 1.
SSID (bit4-1) representa el tipo de estación, el 0 (0000) representa la estación principal. Para más información consultar APRS Protocol Reference.

El Source Address (7 bytes), bastante sencillo ya que corresponde al indicativo de la estación. Se codifica el indicativo hasta de 6 letras y números, en caso de indicativos más cortos, se dejan espacios en blanco, el byte 7 sería de nuevo el CRRSSID0, en este caso "01110010" ya que indicamos EA4AQM-9, este "-9" indica el SSID que corresponderá a la estación móvil y se representará en el mapa con un icono de un vehículo. se pueden utilizar otros, para motocicleta, peatón, bicicleta, etc...

Dejo los siguientes bloques para la siguiente entrada.

Recordar que estamos en fase de obtención de todos los bytes que vamos a manejar y necesitar para en envío de nuestro paquete, algunos datos los vamos a obtener del GPS por lo que necesitaremos implementar dicha comunicación en nuestro micro. Otros tipo de datos serán programados por el usuario, en mi caso he hecho un programa sencillo que dialoga con el Tracker por el puerto serie para leer o grabar internamente (EEPROM) los datos de usuario: Indicativo, SSID, frecuencia de escucha, tiempo de envío, etc.

Una vez tengamos vistos todos ls campos veremos como se forma el HDLC, comentaré sobre el bit stuffing, el FCS y los códigos de línea para luego pasar al módem AFSK...

...continuando.

Los datos de la trama AX.25, que están delimitados por los Flag 0x7E (bin 01111110) de start y stop, son los siguientes:

1- Destination Address, 7 bytes que continen el indicativo destino o los datos APRS como veremos en detalle más adelante. Tenemos 6 bytes correspondientes al indicativo y el último byte al SSID.

2- Source Address, indicativo de la estación que transmite el paquete, son 7 bytes, el último byte indica el SSID (distintos identificativos que puede tomar nuestra estación)

3- Digipeater Address, hasta 8 indicativos de Digipeater (repetidores digitales o Digis), tamaño máximo 56 bytes. En este campo se indica el número de repeticiones de Digipeater. Los Digis reciben los paquetes y los reenvían descontando 1 unidad al SSID, en el momento que llegan a cero son descartados, son el tiempo de vida (TTL) del paquete. Además cada Digi que repite el paquete lo modifica y añade su indicativo de forma que se puede ver el camino seguido por el paquete APRS hasta llegar a un i-Gate (punto de acceso a Internet).
Existen recomendaciones a la hora de configurar este campo ya que valores muy altos ocasionan repeticiones innecesarias y por tanto QRM (ruido).

4- Control Field, campo de control de 1 byte que en APRS es 0x03 (hexadecimal) e indica que se trata de un paquete UI-frame, especificado dentro del protocolo AX.25. Se trata de unnumbered information (UI), o paquetes no numerados y por tanto en modo no orientado a conexión, similar al UDP de TCP/IP. En APRS el orden de los paquetes se establece por el orden de llegada a no ser que sean fechados, es decir que lleven un Timestump.

5- Protocol ID (PID), en nuestro caso es siempre F0, en AX.25 se especifica el tipo de protocolo de nivel 3, en el caso de APRS es nivel 2 por lo que se indica con 0xF0.

6- Information Field, entre 1-256 bytes. Aquí se envían los datos de usuario que pueden ser de cualquier tipo, en caso de APRS con datos MIC-E Encoded Data se codifican datos en este campo como veremos. El AQM Tracker como lo he bautizado utiliza la codificación MIC-E para enviar la posición, la velocidad, el rumbo y la altitud de la estación móvil.

7- Frame Check Sequence (FCS), son dos bytes que se utilizan para garantizar la integridad de los datos, ya comenté algo al respecto anteriormente. Se aplica el cálculo CRC-16 CCITT a los datos a enviar, de forma que el receptor una vez recibida la trama realiza su cálculo y comprueba que coincide con el FCS de la trama, si está todo correcto la trama se ha recibido sin errores, en caso contrario será descartada. El FCS también es utilizado por los Digis para identificar paquetes repetidos y así evitar reenviarlos de nuevo.

Hasta aquí el final de los diferentes campos, un ejemplo real de trama MIC-E es la siguiente:

1:Fm EA4AQM-9 To TP2UWV Via WIDE2-2 [17:07:09]
`y@:m >/"<+}*QRV:145,300MHz 73*

Se puede observar el indicativo de las estación, en este caso el mío con SSID -9 y el alias del Digi genérico APRS "WIDE2-2", en concreto el -2 establece el número de saltos ya que los Digis iran descontando dicho valor hasta llegar a cero. Se observa la trama tipo UI y el pid o protocol ID que es F0. El resto que aparece de longitud 33 bytes corresponde al Informatión Field, aparecen datos MIC-E codificados (`y@:m >/"<+}) y una parte de información de usuario: *QRV:145,300MHz 73*, indicando la frecuencia de escucha.
En el campo Information pueden aparecer caracteres no imprimibles.

En la próxima entrada analizaré la codificación MIC-E para seguir avanzando cada vez a más bajo nivel, pondré algunas señales y ejemplos para que sea más ilustrativo...

APRS en detalle... AX.25

Después de 4 meses trabajando en realizar mi propio Tracker APRS, ya terminado, he aprendido bastante a bajo nivel sobre el protocolo APRS, primero inicié un estudio en profundidad de la Especificación, luego me dediqué a analizar señales para terminar de entender correctamente el funcionamiento, sobretodo a nivel de trama HDLC ya que me surgían un montón de dudas, la especificación en algunos puntos no es muy aclaratoria que digamos...

Lo primero que aprendí es a identificar los campos que puede llevar un paquete APRS, en concreto me centré en el Mic Encoder, que era la parte APRS dedicada al tracking principalmente y que codifica diferentes datos sobre la estructura del AX.25 utilizada ahora para transportar el nuevo protocolo.

El AX.25 es similar al X.25 y tiene una serie de campos sobre los que APRS se apoya, algunos fundamentales y que se mantienen, por ejemplo el Source Address, donde se especifica el Indicativo de quien origina el radiopaquete o el campo data donde van los datos de la aplicación o de usuario...

Una paquete AX.25 tiene los siguientes campos, que en definitiva son chorros de bits cogidos en grupos de 8 bits (bytes) y que tienen un significado dependiendo de la posición e incluso del contenido de dicho byte.

El principio del paquete, me refiero lo primero que se envía hacia el receptor remoto, es un byte de Star llamado Flag y que es una cadena única y que no se repite hasta el final del paquete, ya que al volver a recibirlo se entenderá que es el final del paquete. Esa cadena está formada por 1 byte y los bits son: "01111110", si se recibe antes del final del paquete el receptor interpretará el final del paquete (Stop) y descartará el resto, el paquete se descartará por ser erroneo y simplemente es porque cada paquete lleva un FCS, es decir un Frame Check Secuence que no son más que dos bytes resultantes de la codificación del paquete y que se calcula antes de ser enviado, una vez recibido por el receptor, éste recalcula de nuevo dicho FCS y comprueba si coinciden, de no ser así descartaría el paquete ya que entonces se ha producido un error.

Este método es un CRC y no permite corrección de errores pero sí poder detectarlos, en concreto se utiliza un CRC-16 CCITT cuyo polinomio es X16 + X12 + X5 + 1.
-->

Volviendo a los Flag, comentar que el Flag Start se envía al principio varias veces, es decir de forma seguida en torno a 32 veces, esto se hace para que el receptor del paquete se sincronice. En concreto, se enviaría 01111110011111101111110... ...01111110
De hecho, si se escucha un paquete, el inicio es siempre idéntico y dura unos cuantos milisegundos, en concreto unos 213 milisegundos para un paquete a 1200 baudios, o lo que es lo mismo 1200 bits por segundo (bps).

Aclarar para quién no tenga claro el concepto que en el caso de radiopaquete por estar modulado en AFSK y en el que un símbolo puede ser sólo "1" ó "0" el número de bits por segundo coincide con los baudios (número de símbolos enviados por segundo).
La transmisión en APRS es a 1200 bps, es decir que en el chorro de bits cada bit tiene una duracción de unos 833 microsegundos.

Bueno, poco a poco...
...dejo para la próxima ocasión el análisis de la trama AX.25 para poder entender la codificación APRS. Ya sabemos que los datos útiles de la trama se encuentran entre los Flags y que dichos flag "01111110" no pueden aparecer dentro de la trama, existe un método que comentaré para evitar ésto, llamado bit stuffing...

saludos o como decimos los radioaficionados 73!

APRS y AX.25

continuando con el tema, gran parte de la información que se envía a la red puede ser visualizada de forma gráfica en "http://aprs.fi". En esta URL se representa la información APRS generada por las estaciones de radioaficionado que llega vía TCP/IP a través de los i-gates, digamos que es el servidor central APRS.

Antes de llegar la información al servidor por Internet, una estación ha generado un paquete radio, llamado radio paquete o packet radio. Este paquete lleva la información codificada APRS y la estructura y protocolo de nivel 2, llamado AX.25. La especificación de AX.25 tiene sus años y se basa en el protocolo X.25.
El radio paquete fue muy utilizado hace años antes de la llegada de Internet tal y como la conocemos hoy en día, se accedía vía red telefónica y el número de usuarios era escaso. Este protocolo permitía con simples módem Bell 202 conectar a 1200 baudios ordenadores. A finales de los 80 y principios de los 90 eramos muchas estaciones de radioaficionados los que nos conectábamos de esta forma, surgieron las BBS radio que conformaban una red muy extensa que permitía el envío de mensajes, intercambios de ficheros, etc.

Todo aquello desapareció con la llegada de Internet, como tantas otras cosas... La cuestión es que quedaron en el cajón cantidad de módem, muchos de ellos caseros como el famoso módem baycom y equipos algo más complejos denominados TNC´s (Terminal Node Controller). Algunos de ellos han vuelto a operar gracias al APRS ya que algunas TNC´s han podido convertirse en Digirepetidores.

Actualmente, con los avances informaticos ya no es necesario un módem ni TNC para recibir radio paquete ya que conectando el equipo de radio a la tarjeta de sonido e posible decodificar los paquetes y viceversa, es decir transmitir paquetes usando la salida de la tarjeta de sonido con un pequeño hardware para adapatar los niveles (evitando distorsión por sobremodulación) e incluso ambién dañar el equipo de radio o más en concreto el modulador...

Mis próximas entradas tratarán de cmentar un poco en profundidad el AX.25 para entrar en bastante profundidad en el protocolo APRS y más en concreto en el MIC-E.

Nuevo proyecto APRS

¡Relacionado con la Radioafición!

...escribo ahora estas líneas como inicio de la descripción de mi nuevo proyecto que ire explicando poco a poco. Para quien esté versado en los temas de radio y en concreto de APRS no necesitará una introducción pero para quien no, sólo comentar que este sistema nos permite realizar tracking cuando estamos en movimiento y anunciar la frecuencia en la que tenemos sintonizado nuestro equipo móvil para que cualquier otro radioaficionado pueda contactar con nosotros.

El APRS también permite enviar mensajes, información meteorológica e incluso datos definidos por el usuario, siendo posible de esta forma, por ejmplo, realizar operaciones de telemedida, telecontrol, etc.


La red APRS tiene cobertura mundial ya que está formada por estaciones de radioaficionados que trabajan en este modo y por repetidores digitales (digipeater) distribuidos y situados normalmente en puntos geográficos de gran cota. Estos digis recogen los paquetes y los reenvían con objeto de extender el alcance de las estaciones emisoras de información (estaciones móviles normalmente) para que sus datos entren en la red APRS a través de una estación de radioaficionado con conexión a Internet (i-gate).


Por último, continuaré con más, decir que APRS son las siglas de Automatic Packet Reporting System. Hay quien de forma incorrecta dice Position, ya que no es sólo posición... esto afirmado también por el inventor del APRS, Bob Buringa, que dicho de paso tiene registrada la marca...