DOI:

https://doi.org/10.14483/2248762X.5925

Publicado:

2013-12-30

Número:

Vol. 4 Núm. 2 (2013)

Sección:

Reflexión

DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25

Autores/as

  • Ariel Ricardo Moncaleano Ospina Teleperformance
  • José De Jesús Paternina Anaya Universidad Distrital Francisco José de Caldas
  • Elvis Eduardo Gaona García Universidad Distrital Francisco José de Caldas

Cómo citar

APA

Moncaleano Ospina, A. R., Paternina Anaya, J. D. J., y Gaona García, E. E. (2013). DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25. Redes de Ingeniería, 4(2), 70–81. https://doi.org/10.14483/2248762X.5925

ACM

[1]
Moncaleano Ospina, A.R. et al. 2013. DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25. Redes de Ingeniería. 4, 2 (dic. 2013), 70–81. DOI:https://doi.org/10.14483/2248762X.5925.

ACS

(1)
Moncaleano Ospina, A. R.; Paternina Anaya, J. D. J.; Gaona García, E. E. DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25. redes ing. 2013, 4, 70-81.

ABNT

MONCALEANO OSPINA, Ariel Ricardo; PATERNINA ANAYA, José De Jesús; GAONA GARCÍA, Elvis Eduardo. DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25. Redes de Ingeniería, [S. l.], v. 4, n. 2, p. 70–81, 2013. DOI: 10.14483/2248762X.5925. Disponível em: https://revistas.udistrital.edu.co/index.php/REDES/article/view/5925. Acesso em: 29 mar. 2024.

Chicago

Moncaleano Ospina, Ariel Ricardo, José De Jesús Paternina Anaya, y Elvis Eduardo Gaona García. 2013. «DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25». Redes de Ingeniería 4 (2):70-81. https://doi.org/10.14483/2248762X.5925.

Harvard

Moncaleano Ospina, A. R., Paternina Anaya, J. D. J. y Gaona García, E. E. (2013) «DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25», Redes de Ingeniería, 4(2), pp. 70–81. doi: 10.14483/2248762X.5925.

IEEE

[1]
A. R. Moncaleano Ospina, J. D. J. Paternina Anaya, y E. E. Gaona García, «DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25», redes ing., vol. 4, n.º 2, pp. 70–81, dic. 2013.

MLA

Moncaleano Ospina, Ariel Ricardo, et al. «DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25». Redes de Ingeniería, vol. 4, n.º 2, diciembre de 2013, pp. 70-81, doi:10.14483/2248762X.5925.

Turabian

Moncaleano Ospina, Ariel Ricardo, José De Jesús Paternina Anaya, y Elvis Eduardo Gaona García. «DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25». Redes de Ingeniería 4, no. 2 (diciembre 30, 2013): 70–81. Accedido marzo 29, 2024. https://revistas.udistrital.edu.co/index.php/REDES/article/view/5925.

Vancouver

1.
Moncaleano Ospina AR, Paternina Anaya JDJ, Gaona García EE. DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25. redes ing. [Internet]. 30 de diciembre de 2013 [citado 29 de marzo de 2024];4(2):70-81. Disponible en: https://revistas.udistrital.edu.co/index.php/REDES/article/view/5925

Descargar cita

Visitas

446

Dimensions


PlumX


Descargas

Los datos de descargas todavía no están disponibles.


DISEÑO E IMPLEMENTACIÓN DE UN ANALIZADOR PARA EL PROTOCOLO AX.25

DESIGN AND IMPLEMENTATION AX.25 PROTOCOL ANALYZER

Ariel Ricardo Moncaleano Ospina 1, José De Jesús Paternina Anaya 2, Elvis Eduardo Gaona García 2

1 Teleperformance, Bogotá - Colombia, 2 Universidad Distrital Francisco José de Caldas, Bogotá - Colombia

ariel.moncaleano@teleperformance.com , jjpaterninaa@udistrital.edu.co, egaona@udistrital.edu.co

Recibido: 22/10/2013 - Aceptado: 22/12/2013


Resumen

Actualmente la Universidad Distrital Francisco José de Caldas, a través grupo de investigación GITEM, se encuentra desarrollando el proyecto Cubesat Colombia I, con la misión de enviar señales electrocardiográficas desde una estación terrena hacia un pico satélite, el envío de estos datos se hace a través del protocolo estándar denominado AX.25, ampliamente utilizado en las redes de radio aficionado y en satélites pequeños.

Es prioridad en el desarrollo de cualquier proyecto tecnológico el uso de herramientas que permitan un desarrollo ágil y seguro, en este artículo la implementación de AX.25 en el proyecto antes mencionado se logró implementar un analizador de protocolo AX.25 para la captura de los paquetes que se están intercambiando las estaciones de radio aficionados para posteriormente analizarlos, evaluarlos y almacenarlos.

Esto permite observar a través de la decodificación de las tramas, su empaquetamiento: campo de dirección destino y fuente, campo de control, la información que viaja en formato hexadecimal ASCII, el CRC y así indicar si la trama se recibe con error o no.

El analizador de protocolo desarrollado tiene la posibilidad de capturar señales NRZI moduladas en banda base con el estándar BELL 202 sobre una portadora de radio en la banda radioaficionado VHF/ UHF.

La demodulación de señales VHF / UHF se logran a través de radios Yaesu VX-3R, y la implementación del estándar BELL 202 con los circuitos integrados MX 614 para cada enlace (recepción y transmisión), que permite tomar la información en AFSK, demodularla y entregarla a la tarjeta de adquisición, y enviar la información al software analizador de protocolo para la respectiva evaluación por parte del usuario.

Palabras clave: Analizador de Protocolo, Cubesat, protocolo AX.25, Modem

Abstract

Currently the Distrital University Francisco José de Caldas through GITEM research group, has been developing the Cubesat Colombia I project, with a mission to send ECG signals from an Earth Station to a small satellite, sending this data is done through the standard protocol called AX.25, widely used in amateur radio networks and small satellites.

It is a priority in the development of any technology project using tools that enable agile development and safe, in this paper the implementing AX.25 in the above project successfully implement AX.25 protocol analyzer to capture packets are being exchanged amateur radio stations and later analyze, evaluate and store. This lets to see through the decoding of frames, their packaging: driving destination and source address, control field, data traveling in hexadecimal ASCII format and so the CRC indicate whether the frame is received in error or not.

The developed protocol analyzer has the ability to capture NRZI signal modulated based band with standard BELL 202 on a carrier and the amateur radio band VHF / UHF.

The demodulation VHF / UHF signals are achieved through radios Yaesu VX-3R, and the implementation of standard BELL 202 was done with IC MX 614 for each link (receive and transmit), which lets to take AFSK information, demodulate and deliver to the acquisition card, and send the information to the software protocol analyzer for evaluation by the respective user.

Key Words: Protocol Analyzer, Cubesat, AX.25 protocol, Modem

1. INTRODUCCIÓN

En los últimos años ha habido un creciente número de aplicaciones que utilizan la comunicación de paquetes de radio, por medio de una interfaz de usuario. Estas aplicaciones incluyen el protocolo de transmisión PACSAT [4], las transmisiones de APRS [3] y [5], protocolo de transferencia de archivos HamWeb. Todos estos comparten la ventaja de su transmisión de datos desde una fuente a varios destinatarios simultáneamente.

Se ha empezado a explotar las posibilidades de transmisión de datos en aplicaciones de radio amateur. Además, la eficiencia al momento de enviar datos de una fuente a varios destinatarios superara las limitaciones impuestas por las tasas relativamente bajas de datos en aplicaciones de radio amateur. Teniendo en cuenta que anteriormente se utilizaban velocidades inferiores a 1200Baudios y hoy se tiene la capacidad de transmitir con esta tasa de transferencia y superiores hasta 9600 Baudios en la radio difusión.

Básicamente se explicará en este artículo tanto la interfaz de usuario a crear como el dispositivo físico que permitirá la captura de información entre las estaciones terrestres y el pico satélite con el analizador de protocolo AX.25.

Se abordaran temas concernientes a software y hardware con el objetivo de cubrir los componentes que requiere este proyecto para su implementación y éxito. Por otro lado, se abarcarán temas como el diseño y funcionalidad del modem escogido, diseño y desarrollo de la tarjeta de adquisición, diseño e implementación del software analizador de protocolo AX.25.

2. ESTADO DEL ARTE

Inicialmente se indagó a cerca de avances, investigaciones y desarrollos previos, con el propósito de identificar y abstraer la información más relevante que permite construir las bases de este proyecto.

Un primer escenario se centra en la implementación de una interfaz entre el mundo digital y el paquete de radio difusión (en forma de paquetes AX.25). Este primer escenario brinda la una aproximación del uso de micro controladores para la implementación del protocolo AX.25, a su vez ofrece un acercamiento del uso de un Modem que permite modular y demodular señales en FSK, y una transmisión digital a 1200 baudios [1].

Como segundo escenario, se evidencia una mejora en la tarjeta de adquisición, por medio de una FPGA, donde se diseñó e implementó un monitor para el protocolo AX.25. Este, puede demodular una señal en AFSK 1200/2200 con transmisión digital de 1200 bps. A su vez puede decodificar las tramas y mostrarlas en una pantalla LCD y/o enviarlas por medio de un puerto serial al PC [2].

Por otro lado, un tercer escenario está dirigido hacía el desarrollo de software. Este, fue diseñado bajo lenguaje de programación Java. Además realiza la demodulación de una señal FSK basada en modulación Bell 202 [3].

3. PROTOCOLO AX.25

El protocolo AX25 es la manera como las estaciones Packet se comunican entre sí; este estándar está basado sobre el CCITT X.25 y el protocolo de Ethernet. Packet radio utiliza como método de acceso múltiple por sensado de portadora (Carrier Sense Multiple Access CSMA), para permitir acceso a múltiples usuarios al sistema. La estación espera hasta que existe un canal desocupado antes de empezar el proceso de transmisión. Cuando una estación tiene un paquete por transmitir y el canal está desocupado se inicia un algoritmo de tiempo aleatorio; si el tiempo expira antes de que otra estación utilice el canal, el paquete es enviado [7].

Si el canal está ocupado es posible que varios ciclos del algoritmo ocurran hasta que el paquete finalmente sea enviado.

Desde el punto de vista del modelo de referencia OSI, dentro del protocolo AX.25 se toman las primeras 2 capas más bajas de este modelo, se subdividen en otras categorías encargadas del manejo general de la conexión y verificación de datos. Se puede realizar una conexión sencilla como en la figura 1, o de forma múltiple como en la figura 2.

Donde el DLSAP (Data Link Service Access Point), es el punto de la capa de conexión de datos que provee el servicio o el paso a la capa 3.

Sobre la capa 3 se observa un sistema de envió y respuesta, esta interacción se conoce como servicio primitivo, este es el intercambio entre la capa de conexión y las capas adyacentes a ella, este tipo de servicio primitivo funciona en el siguiente orden (figura 3).

  • Solicitud
  • Indicación
  • Respuesta
  • Confirmación

3.1. Descripción de tramas

El paquete de transmisión de radio es enviado en pequeños bloques de datos, llamados tramas. Donde existen 3 tipos de trama en el protocolo AX. 25.

  • Trama de información (I frame) (tabla 1).
  • Trama de supervisión (S frame) (tabla 2).
  • Trama sin numeración (U frame) (tabla 3).

Cada trama está compuesta por pequeños grupos llamados campos.

F: Flag (bandera).

A: Address (dirección).

C: Control.

PID: Protocol Identifier (identificador de protocolo).

I: Information (información).

FCS: Frame Check Sequence (secuencia de verificación de trama).

El orden de envío viene dado de derecha a izquierda comenzando por el bit menos significativo y cada subcampo de dirección consta de 7 octetos (bytes): los seis primeros correspondientes al indicativo y el séptimo al SSID. El indicativo está compuesto de caracteres alfanuméricos codificados en ASCII, 7 bits, desplazados una posición para contener el bit de extensión. Si el indicativo es menor de 6 caracteres, el resto se complementa con espacios en blanco. El SSID tiene un valor máximo de 15, lo cual ocupa sólo 4 bits, los 4 restantes indican lo siguiente:

  • E bit de extensión.
  • R dos bits reservados para futuras ampliaciones.
  • C comando/respuesta.

3.2. Bandera

El campo de bandera es un campo especial. Este determina el comienzo y final de la trama. La bandera puede ser transmitida continuamente, si se requiere un retraso para un apropiado comienzo de transmisión o recepción.

3.3. Campo de dirección

El campo de dirección identifica la fuente y el destino de la trama. Además puede contener la ruta de la trama a través de los repetidores.

En la tabla 3 se muestra el ordenamiento de los campos de selección de destino y fuente, los octetos del A1 al A6, además A8 y A13 son caracteres ASCII con un corrimiento de un bit a la izquierda, con el bit menos significativo en 0. Los Octetos de SSID son el A7 y el A14 y llevan la siguiente estructura.

  • C bit, es un bit de comando/respuesta.
  • RR bits, son reservados y podrían ser usados en algunas redes.
  • SSID es un entero entre 0-15.
  • L bit, esta indica el último bit del campo de dirección.

3.4. Campo de control

Identifica el tipo de trama. El campo podría ocupar uno o dos octetos. Solamente un octeto será soportado y descrito.

3.5. PID Field

El campo de PID está presente solamente en las tramas de información (I Frame). Este determina qué tipo de protocolo de capa 3 está en uso.

3.6. Campo de información

El campo de información transporta la información del usuario desde un nodo a otro nodo, esto podría solo aparecer en algunos tipos de trama.

  • Trama información.
  • Trama UI.
  • Trama XID.
  • Trama de prueba.
  • Trama FRMD.

La longitud por defecto de estas tramas es de 256 octetos.

3.7. Campo de FCS

La secuencia de chequeo de trama (FCS) es un número de 16 bits calculado por el transmisor y el receptor de la trama. Esto asegura que la trama no llegará corrupta a causa del medio de transmisión.

3.8. Bit de relleno

El octeto de bandera son 8 bits de sincronización que permite reconocer el inicio y el final de una trama, que corresponde al carácter 7E (1111110). Este carácter no puede aparecer en medio de una trama como dato o información. Para asegurar esto, es usado un método llamado “bit de relleno” (Bit Stuffing). En el momento que se reciban 5 unos consecutivos, el transmisor debe enviar un cero. Por parte del receptor, cuando se reciban 5 unos consecutivos, automáticamente el 0 siguiente será eliminado.

3.9. Trama de supervisión

Las tramas de supervisión proveen la función de requerir acuse de recibo o bien la retransmisión de las tramas de información. La codificación de las tramas de supervisión se describe en la tabla 4.

Dónde:

  • N(R) es el número de secuencia de recibido.
  • P es el bit, indicando que si se encuentran en 1 requiere una respuesta inmediata.

3.10. Tramas no numeradas

Las tramas no numeradas son responsables de mantener un control adicional sobre el enlace, más allá de lo que ha alcanzado con las tramas de supervisión, también establecen y terminan los enlaces de conexión, permiten la transmisión y recepción de la información fuera del control de flujo normal. La descripción del campo se muestra en la tabla 5.

3.11. Campo de información

El comando de información transfiere tramas secuencialmente numeradas que contienen un campo de información a lo largo del enlace de datos (tabla 6).

  • N(S) es el número de secuencia de enviado.
  • N(R) es el número de secuencia de recibido.
  • P es el bit de validación o de final. Es usado para obtener una respuesta inmediata de una trama.

4. METODOLOGÍA

Para el desarrollo de este proyecto, se procedió inicialmente a realizar un estudio general del tipo de información manejada por la estaciones, como también el tipo de modulación, envió y recepción de estas. A su vez se hizo necesario observar el tipo de información adquirida por los radios, para desarrollar a sí mismo el tipo de demodulación y modulación que se aplicaría en este caso.

Se buscó información de antecedentes que se han realizado en este caso y se contrastaron con los requerimientos que se tenían en este proyecto.

Por otro lado, se diseñaron los diferentes algoritmos para: la visualización de las tramas adquiridas, la detección de errores, la adquisición de la información recibida en el dispositivo. Además la configuración del modem el cual llevó las tramas de un nivel digital a un nivel análogo para ser transmitida.

En un principio se inició con pruebas de sincronización, es decir se hicieron pruebas de envíos de datos a 1200 bps. Seguido a esto se realizó el algoritmo de detección de bandera, luego el almacenamiento de información, por último la conversión de estas tramas en caracteres para ser enviados al computador y visualizados por medio del software desarrollado.

4.1. Diseño e implementación de la tarjeta de adquisición usando el micro controlador MSP430F1612

Antes de iniciar específicamente con el diseño e implementación del protocolo AX.25 sobre el micro controlador MSP430F1612, se debe abordar el tema de intercambio de tramas, para poder crear una idea de cómo debe ser la misma implementación y así mismo que requerimientos debe cumplir.

Para un mayor entendimiento se bosqueja un ejemplo de un intercambio de tramas en la figura 4. Para esto, primero se tiene que establecer una conexión entre la estación que transmite y la que recibe. Si la estación A desea conexión con la estación B, este envía la trama no numerada SABM, con lo cual indica que se quiere conectar en módulo 8, esto es, la ventana de tramas de información máxima sin confirmar es de 8 tramas. La estación acepta esta configuración devolviendo la trama no numerada UA. Después de esto el master envía la trama RR, con N(R)= 0 y P=1 indicado con esto que espera la trama 0 de información y desea respuesta inmediata, el esclavo responde con otra trama RR con N(R)= 0 y P=1, indicando de igual forma que espera la trama de información 0 y respuesta inmediata. Si ninguna de las estaciones tiene trama de información que enviarse pueden quedarse enviando tramas RR indefinidamente o desconectar el enlace. [8]

Ya que se ha establecido un enlace entre ambas estaciones, se procede a realizar un intercambio de información entre ambas, esta se observa desde la secuencia 5 a la 12. Desde la secuencia 5 a la 8 la estación A indica en su campo de control de la trama de información (N(S)), que está enviando las tramas 0,1,2 y 3 respectivamente, a su vez, que se encuentra esperando que la estación B haga envío de la trama 0 (N(R)=0), tal como se muestra en la figura 5.

  1. Desde las secuencias de la 5 a la 7, con p=0, la estación A indica que no está solicitando validación de las tramas enviadas.
  2. En la secuencia 8 y 9, se envía la trama de información 4 con P=1, esto indica que la estación B debe responder. Esta lo hace con una trama de información con N(R)=4, N(S)=0 y F = 1, indicando que envía la trama de información 0, espera la trama 4 y ordena respuesta inmediata. Es decir que la estación B ha validado desde la trama 0, a la 3.
  3. En la secuencia 10 y 11, la estación A envía las tramas 4 y 5 con P= 0.
  4. En la secuencia 12 envía un RR con P=1.

Estos dos últimos eventos llevan a que la estación B devuelva un REJ N(R)= 4 y F =1, lo cual significa que el esclavo esta ordenado la retransmisión desde la trama 4, tal como se muestra en la figura 6.

A su vez la estación A vuelve a enviar las tramas 4 y 5 en las secuencias 14 y 15. Las siguientes secuencias bosquejan transferencia de tramas entre la estación A y la estación.

Por último se valida el total de las tramas que se intercambiaron y las secuencias de desconexión, esto se muestra en la figura 7.

4.2. Implementación de AX.25 con Microcontrolador MSP430x

4.2.1. Rx Trama

En la figura 8 se muestra la secuencia de recepción de una trama AX.25, la rutina inicial se encarga de llamar a las siguientes, con el objetivo de capturar todos los datos provenientes del enlace entre las dos estaciones de radioaficionados. Esta rutina es la encargada de garantizar que la tarjeta de adquisición sea capaz de capturar la bandera inicial y final, a su vez todos los datos que están siendo transmitidos entre las estaciones que se encuentran en el enlace [6].

4.2.2. Rx Flag

Al iniciar el programa del monitor, este empieza con la búsqueda de banderas que indican el comienzo de trama. Esta bandera es un 7E en hexadecimal (01111110 en binario). Para evitar que se empiece o termine la transmisión de forma equivoca, el protocolo establece un bit de relleno (bit stuffing), el cual garantiza que se encuentre la bandera de inicio y final correcta cuando se encuentran 6 (1´s) unos seguidos.

Se inicia, comparando si cbyte es un 7E, de no ser así se agrega un bit a cbyte a su lado izquierdo y se descarta el que se encuentra en su lado derecho.

La recepción de la bandera se recibirá en formato NRZI, la rutina se encargará de ensamblar la dicha bandera [6].

4.2.3. Esp Flag

Como se mencionó anteriormente, se requiere hacer uso del bit de relleno Cada vez que se obtiene un nuevo bit, se mueve cada bit que contiene cbyte hacia la derecha, donde el nuevo bit llegaría ocupar la primera posición del lado izquierdo de cbyte. Por ejemplo si cbyte es 10001000, se obtiene un 1, el nuevo valor de cbyte sería: 11000100. Por lo tanto el bit ubicado en la primera posición del lado derecho se descartará. El objetivo de realizar este bit de relleno es almacenar en memoria los anteriores 7 bits que han sido recibidos y mantener recibiendo nuevos bits a la vez, hasta cuando llegue un nuevo bit que al juntarlo con los 7 anteriores me indique la bandera 7E (01111110), asegurando así que se recibió la bandera correctamente [6].

4.2.4. Rx Data

La recepción de datos de una trama se hace mediante la rutina Rx Data. Luego de leer la bandera inicial y el primer dato de la trama. En el buffer trama van quedando los datos leídos, cada vez que se almacena un nuevo dato se incrementa el apuntador de este buffer a la siguiente posición disponible.

Una variable test indica 1 cuando se ha encontrado una bandera y cero si fue lo contrario. Otra variable ones realiza el conteo del total de unos consecutivos que se han recibido, si llegase un cero, este contador se reinicia automáticamente. Si llegasen 5 unos consecutivos, el siguiente bit recibido se almacena en la variable Test. Si el valor de Test es uno, significa que se ha recibido una bandera y por lo tanto la transmisión ha finalizado, en caso contrario, significa que ocurrió un bit de relleno y ese bit será descartado. Al completar un byte completo, se almacena en la variable bte, y el número de bytes se almacena en la variable numbyte [6].

4.3.Diseño e implementación del software analizador de protocolo AX.25

4.3.1. Definición de los requerimientos del sistema

El analizador de protocolo AX.25 tomará toda la información proveniente de dos entidades de radio aficionados que se encuentran transmitiendo información bajo el protocolo AX25, para luego mostrar la cantidad de tramas enviadas y recibidas con el detalle de configuración de cada trama. Este software se compone de 4 módulos que le permiten al usuario una fácil interacción y análisis de tramas AX.25 proveniente de la tarjeta de adquisición.

4.3.2. Especificación de los requerimientos del sistema
  1. El analizador recibirá la información enviada por la tarjeta de adquisición y mostrará la información recibida por tramas, con su detalle de configuración, indicando cuales son de recepción o transmisión.
  • El analizador solo tiene en cuenta la información contenida entre las banderas de principio y fin.
  • La información recibida por parte de la tarjeta de adquisición podrá ser almacenada en el disco duro del computador.
  • El software tiene la opción de trabajar como terminal de comunicación para desplegar en tiempo real la información recibida desde la tarjeta de adquisición.
  • A su vez, el analizador cuenta con la opción de mostrar la información adquirida, en caracteres ASCII y Hexadecimal ASCII, para mostrar lo recibido por parte de la tarjeta de adquisición.
  • El analizador tiene la posibilidad de filtrar solamente el despliegue de información de la dirección destino y fuente especificados.
  • 4.3.3. Requerimientos del usuario

    El analizador de protocolo AX.25 permitirá al usuario visualizar las tramas provenientes de dos estaciones de radio aficionados. Este software proporcionará una herramienta que le permitirá al usuario conocer en tiempo real la información recibida, además dispone de la capacidad de decodificar dicha información en tramas, indicando dirección destino, dirección origen, la secuencia de las tramas de información, el tipo de cada trama recibida, la información.

    Módulo: Terminal de Comunicación

    1. El usuario podrá realizar la configuración del puerto serial.
    2. El usuario podrá usar un campo de texto para enviar información hacia la tarjeta de adquisición.
    3. El software debe contar con un Cuadro de texto, donde el usuario podrá visualizar la información recibida desde la tarjeta de adquisición.
    4. El software debe proveer la función de guardar la información adquirida.
    5. El usuario podrá exportar la información recibida a adquisición de tramas para su decodificación.
    6. El usuario podrá borrar la información adquirida si no desea verla o confundirse con dicha información.

    Módulo: Monitor

    1. El usuario podrá seleccionar el puerto serial donde se encuentra conectada la tarjeta de adquisición.
    2. El usuario podrá escoger el número de tramas que desea que la tarjeta de adquisición le envíe.
    3. El usuario cuenta con un cuadro de texto, donde podrá visualizar en hexadecimal ASCII la información recibida desde la tarjeta de adquisición.
    4. El usuario podrá guardar la información adquirida.
    5. El usuario podrá exportar la información recibida a adquisición de tramas para su decodificación.
    6. El usuario podrá borrar la información adquirida si no desea ver o confundirse con dicha información.

    Módulo: Resultados

    1. El usuario podrá indicar la ruta del archivo de información que desea cargar, para luego ser visualizado en Hexadecimal ASCII en un campo de texto especifico.
    2. El usuario tendrá la función de convertir el archivo cargado en ASCII, dicha información será desplegada en otro campo de texto.

    Módulo: Analizador de tramas

    1. El usuario podrá indicar la ruta del archivo que desea cargar, para luego ser visualizado en tramas.
    2. El usuario tiene la capacidad de ver el detalle de cada trama obtenida, conociendo su información, secuencia, tipo, origen y destino.
    3. El usuario tiene la opción de especificar el origen y destino para solo ver la comunicación entre los indicados.
    4. El usuario podrá indicarle al software cuando quiere que la información cargada sea visualizada en tramas.
    5. El usuario posee la función de reiniciar el formulario existente con el objetivo de realizar un nuevo cargue de información.

    4.4. Diagrama de secuencia

    Se ilustra el diagrama de secuencia en la figura 9.

    4.5. Diagrama de casos de uso

    Se ilustra el diagrama de secuencia en la figura 10.

    5. Resultados

    Se puede verificar el menú inicial con los diferentes 4 módulos de manejo que posee el usuario como lo muestra la figura 11.

    La terminal de comunicación permite al usuario configurar el puerto serial, establecer una comunicación con la tarjeta de adquisición, enviar caracteres hacia la tarjeta, recibir información de la tarjeta, limpiar la pantalla y exportar los datos hacia el módulo del analizador de tramas (figura 12).

    El modulo monitor le permite al usuario escoger el puerto de comunicación, seleccionar la cantidad de tramas que quiere recibir, establecer una comunicación, recibir los datos proveniente de la tarjeta de adquisición y exportar los datos hacia el módulo del analizador de tramas (figura 13).

    El modulo Resultados le da la opción al usuario de convertir la información recibida desde la tarjeta de adquisición en Hexadecimal a caracteres ASCII, de esta manera el usuario podrá visualizar exactamente lo que ha recibido el software (figura 14).

    Por último se tiene el módulo Analizador de Tramas que le permite al usuario decodificar las tramas contenidas en la información recibida desde la tarjeta de adquisición, extrayendo de ellas su detalle: origen, destino, tipo, secuencia, validación, información (figura 15).

    CONCLUSIONES

    El software capturó todos los datos provenientes de la tarjeta de adquisición, permitiéndole al usuario decodificarlos para conocer las tramas contenidas, adquiriendo de ellas: su origen, dirección, tipo, secuencia, información.

    El software fue capaz de convertir la información recibida desde la tarjeta de adquisición en caracteres ASCII para su respectiva interpretación por parte del usuario.

    Para evitar que se perdiera información durante la adquisición de tramas, la tarjeta de adquisición se configuró de tal forma, que estuviera leyendo constantemente ambos canales, en el momento que se inicie transmisión, la tarjeta almacena un número definido de tramas y las envía al analizador.

    Referencias

    1. B. Zieliński; Efficiency estimation of AX. 25 protocol, Theoretical and Applied Informatics 20, pp 199-214, 2008
    2. M. Demin; Desing and implementation of AX.25 Monitor, Engineering Thesis, BRNO University of Technology, Czech republic, 2007.
    3. T. Capitaine, L. Barrandon, J. Senlis & A.Le Mortellec; Robust Satellite AX25 Frames Demodulation, The Small Satellites Systems and Services (4S) Symposium (Vol. 31), pp 1- 13, Protugal, 2010.
    4. K. E. Neumeister; Design and analysis of ground stations for Pacsat applications, Master Thesis, Virginia Tech, United States, 2010.
    5. D. Kodek; System for automatic transmission of meteorological information, Engineering Thesis, University of Ljubljana, Slovenia, 2008.
    6. A. Moncaleano; Diseño e implementación de un analizador para el protocolo AX.25 para visualizar, evaluar y verificar las tramas enviadas y recibidas desde y hacia las estaciones terrestre y espacial, Tesis pregrado, Universidad Distrital Francisco José de Caldas, Colombia, 2012.
    7. AX.25 Link Access Protocol for Amateur Packet Radio Version 2.2. 1988. [En línea], consultado Febrero 11 2014, disponible en: http://tapr.org/pub_ax25.html.
    8. J. Paternina; Diseño y construcción del módulo de control central del CubeSat UD e implementación de AX.25, Tesis de Maestría, Universidad Distrital Francisco José de Caldas, Colombia, 2011.

    Artículos más leídos del mismo autor/a

    Loading...