Informe - Escuela de Ingeniería Eléctrica

Universidad de Costa Rica
Facultad de Ingeniería
Escuela de Ingeniería Eléctrica
IE – 0502 Proyecto Eléctrico
Propuesta de Diseño de Comunicación Remota en
Radiofrecuencia para el Laboratorio de Ingeniería
Sísmica de la U.C.R.
Por:
Marco Villalta Fallas
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
2
Propuesta de Diseño de Comunicación Remota en Radiofrecuencia
para el Laboratorio de Ingeniería Sísmica de la U.C.R.
Por:
Marco Villalta Fallas
Sometido a la Escuela de Ingeniería Eléctrica
de la Facultad de Ingeniería
de la Universidad de Costa Rica
como requisito parcial para optar por el grado de:
BACHILLER EN INGENIERÍA ELÉCTRICA
Aprobado por el Tribunal:
___________________
Ing. Jorge Romero Chacón, Ph.D.
Profesor Guía
___________________
Ing. Federico Ruiz Ugalde
Profesor Lector
___________________
Ing. Jhonny Cascante Ramírez
Profesor Lector
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
3
DEDICATORIA
A mi familia, amigos y profesores que me han ayudado a alcanzar esta meta.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
4
RECONOCIMIENTOS
Al profesor Jorge Romero por su confianza, consejos, apoyo bibliográfico, aportes y
guia en la elaboración de este trabajo, así como también el tiempo brindado para discutir las
dudas y avances. A los miembros del tribunal Federico Ruiz Ugalde y Jhonny Cascante
Ramírez, en especial a Federico por su constante disposición a ayudarme en la propuesta del
prototipo e ideas.
Al director Ing. Víctor Schmidt Díaz y a Carlos Segura Vargas del L.I.S. por el tiempo
para aclarar consultas, el material bibliográfico de los acelerógrafos y confianza al permitirme
realizar las simulaciones.
A mi madre por su colaboración en la redacción del documento, apoyo y palabras en los
momentos difíciles a pesar de la distancia. A mi padre por el apoyo constante, en especial en el
inicio de este proceso. A mis hermanos por estar siempre dispuestos a ayudarme en lo que
pudieran. A mi abuela y abuelo por sus oraciones.
A mis grandes amigos, Mario Quesada por la compañía e interés en mi avance, a
Roberto Cardona por su invaluable ayuda bibliográfica, técnica, aportes y tiempo en todo el
transcurso del desarrollo con el sistema incrustado. A Gloriana Alvarado por sus constantes
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
5
palabras de apoyo, compañía en todo momento, por siempre escuchar mis problemas y la
comprensión en la realización de este proyecto.
Muchas gracias.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
6
INDICE GENERAL
ÍNDICE DE FIGURAS............................................................................................9
ÍNDICE DE TABLAS............................................................................................11
NOMENCLATURA...............................................................................................12
RESUMEN...............................................................................................................13
CAPÍTULO 1: Introducción.................................................................................14
1.1
Objetivos...............................................................................................................................14
1.1.1 Objetivos específicos.................................................................................................14
1.2 Metodología............................................................................................................................15
1.3 Justificación............................................................................................................................17
CAPÍTULO 2: Acelerógrafos Kinemetrics..........................................................19
2.1 Características Generales......................................................................................................19
2.1.1 Descripción General...................................................................................................19
2.1.2 RS-232C.....................................................................................................................23
2.1.3 El “firmware”..............................................................................................................24
2.2 Modos de Comunicación......................................................................................................26
2.2.1 Modo Terminal o Monitor.........................................................................................28
2.2.2 Modo “Block” - Comunicación Binaria de Paquetes................................................33
CAPÍTULO 3: GPRS y Sistemas Incrustados....................................................39
3.1 GPRS.....................................................................................................................................39
3.1.1 Antecedentes..............................................................................................................39
3.1.2 Principales características del GPRS.........................................................................43
3.1.3 Arquitectura de la red GPRS......................................................................................45
3.1.4 Dispositivos GPRS.....................................................................................................50
3.1.5 Comandos AT............................................................................................................52
3.1.6 Acceso a la red...........................................................................................................53
3.2 Sistemas Incrustados.............................................................................................................56
CAPÍTULO 4: Propuesta de diseño y prototipo.................................................59
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
7
4.1 Propuesta...............................................................................................................................59
4.2 Desarrollo..............................................................................................................................61
4.2.1 Aspectos generales.....................................................................................................61
4.2.2 Configuración del sistema huésped...........................................................................64
4.2.3 Sistema raíz de archivos de la SBC...........................................................................68
4.2.4 Configuración del kernel............................................................................................72
4.2.5 Primer arranque..........................................................................................................75
4.2.6 Reconfiguración del sistema incrustado y huésped...................................................77
4.2.7 Segundo arranque.......................................................................................................80
4.2.8 Configuración de túnel para la VPN..........................................................................84
4.2.9 Comunicación con acelerógrafo................................................................................88
CAPÍTULO 5: Otras alternativas........................................................................91
5.1 Módems PCMCIA y EIA232................................................................................................92
5.2 Soluciones de conectividad locales.......................................................................................94
5.2.1 Internet vía satelital....................................................................................................94
5.2.2 Red RACSARID........................................................................................................96
5.3 Transmisión en FM.............................................................................................................100
5.3.1. Conceptos básicos...................................................................................................100
5.3.2. Diseño......................................................................................................................104
5.4 HAM radios.........................................................................................................................110
5.5 RF Módems.........................................................................................................................115
CAPÍTULO 6: Conclusiones y recomendaciones.............................................122
6.1 Conclusiones.......................................................................................................................122
6.2 Recomendaciones................................................................................................................123
BIBLIOGRAFÍA..................................................................................................125
APÉNDICES.........................................................................................................129
La codificación ASCII.......................................................................................................129
EIA-232...............................................................................................................................131
Comandos AT – GSM.........................................................................................................136
ANEXOS................................................................................................................139
Simulación con acelerógrafo...............................................................................................141
Simulación con dispositivo GPRS......................................................................................144
Scripts..................................................................................................................................146
Historial de inicio................................................................................................................150
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
8
Asignación de pines puerto serial del Net4801..................................................................155
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
9
ÍNDICE DE FIGURAS
Figura 1.1 Ubicación Geográfica de Acelerógrafos.................................................................18
Figura 2.1 Acelerógrafos digitales. a. SMA-QDR, b. Etna......................................................19
Figura 2.2 Elementos de un acelerógrafo K2...........................................................................21
Figura 2.3 Diagrama de Bloques K2/Etna................................................................................22
Figura 2.4 Paquetes de comandos enviados por PC/huésped...................................................35
Figura 2.5 Paquetes de comandos enviados por equipo Altus.................................................36
Figura 3.1 Divisiones en GSM..................................................................................................40
Figura 3.2 Uso de las divisiones de tiempo..............................................................................40
Figura 3.3 Datos y voz compartidos en GPRS.........................................................................42
Figura 3.4 Comparación de típica sesión GPRS y CS..............................................................44
Figura 3.5 Implementación de GPRS sobre una red ya existente............................................45
Figura 3.6 Arquitectura de un sistema móvil............................................................................45
Figura 3.7 Arquitectura de un sistema GPRS...........................................................................46
Figura 3.8 Niveles de transporte de un paquete GPRS.............................................................49
Figura 3.9 Acceso de comandos AT al MT..............................................................................52
Figura 4.1 Sistema incrustado Net4801....................................................................................62
Figura 4.2 SBC lista para primer arranque...............................................................................75
Figura 4.3 Net4801 operando dispositivo GPRS/GSM............................................................81
Figura 5.1 Esquema de conexión con acelerógrafos................................................................93
Figura 5.2 Topología del servicio de Internet Satelital............................................................95
Figura 5.3 Topología del servicio de RACSARID...................................................................98
Figura 5.4 La Frecuencia Modulada.......................................................................................100
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
10
Figura 5.5 Espectro electromagnético.....................................................................................102
Figura 5.6 Diagrama de bloques del BiM1.............................................................................105
Figura 5.7 Asignación de pines del BiM1..............................................................................106
Figura 5.8 Esquemático para el BiM1....................................................................................107
Figura 5.9 Antena de cuarto de onda......................................................................................108
Figura 5.10 Enlace por radio remoto......................................................................................109
Figura 5.11 Estación de Radio Digital....................................................................................111
Figura 5.12 Arquitecturas para módems RF...........................................................................118
Figura 5.13 Diagrama de flujo de transmisión para módulo RF............................................119
Figura 5.14 Diagrama del flujo interno de datos de módulo RF............................................119
Figura A.1 Ejemplo de dispositivos DTE y DCE...................................................................132
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
11
ÍNDICE DE TABLAS
Tabla 2.1 Descripción de la asignación de pines de acelerógrafos.........................................24
Tabla 5.1 Rangos de las ondas de radio.................................................................................102
Tabla 5.2 Bandas de frecuencias de microondas...................................................................103
Tabla A.1 Tabla ASCII..........................................................................................................130
Tabla A.2 Descripción de los códigos de control ASCII......................................................130
Tabla A.3 Descripción de comandos AT-GSM/GPRS..........................................................137
Tabla B.1 Teléfonos celulares GSM, compatibles con la red del ICE..................................139
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
12
NOMENCLATURA
ASCII: American Standard Code for Interchange Information
BSC: Base Station Controller
BTS: Base Transceiver Station
DCE: Data Communications Equipment
DSL: Digital Subscriber Line
DSP: Digital Signal Processing
DTE: Data Terminating Equipment
FPGA: Field-Programmable Gate Arrays
GGSN: Gateway GPRS Support Node
GPRS: General Packet Radio Services
GSM: Global System for Mobile communications
ISP: Internet Service Provider
MCU: Micro Controller Unit
MSC: Mobile Switching Center
PCMCIA: Personal Computer Memory Card International Association
RTOS: Real Time Operating System
SBC: Single Board Computer
SGSN: Serving GPRS Support Node
TDMA: Time Division Multiple Access
TNC: Terminal Node Controller
UART: Universal Asynchronous Receiver Transmitter
WAP: Wireless Application Protocol
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
13
RESUMEN
El presente trabajo describe una propuesta para un sistema de comunicaciones remoto,
en radiofrecuencia, para las estaciones del L.I.S. de la U.C.R. Esta soluciona el problema que
implica el tener que trasladar un equipo técnico a todas las estaciones para la recolección de
datos, permitiendo desde el L.I.S. comunicarse con los acelerógrafos para adquirir los archivos
y cambiar parámetros de operación.
Se tratan distintas soluciones tanto para las estaciones en el área metropolitana como
fuera de esta, indicando las ventajas y desventajas de cada una. Se establecen las bases para
realizar la comunicación de las estaciones en lugares remotos y de difícil acceso, usando un
sistema incrustado como interfaz y un dispositivo GPRS.
Con la propuesta de diseño se demuestra que se puede implementar efectivamente una
comunicación remota de bajo costo, así como también se indican las posibilidades y funciones
que permite el esquema escogido.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
14
CAPÍTULO 1: Introducción
1.1
Objetivos
Plantear una propuesta de diseño para un sistema de comunicaciones remoto, en
radiofrecuencia, para el Laboratorio de Ingeniería Sísmica de la U.C.R y las estaciones de este
organismo.
1.1.1 Objetivos específicos
i. Agilizar la transmisión del sistema de información desde las estaciones sismográficas hasta
el Laboratorio de Ingeniería Sísmica de la U.C.R.
ii. Identificar alternativas de solución del sistema de transmisión accesibles a los recursos
disponibles.
iii. Diseñar alternativas de solución al sistema de transmisión que sean compatibles con los
modelos de acelerógrafos digitales ETNA Kinemetrics, QDR Kinemetrics y K2 Kinemetrics.
iv. Recomendar una alternativa económica al sistema de transmisión para su implementación.
v. Realizar pruebas de simulación para tal alternativa económica.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
1.2
15
Metodología
La metodología propuesta tiene como finalidad reflejar sistemáticamente las fases por
las que va a transcurrir el proceso investigativo hasta conseguir los objetivos antes formulados.
Inicialmente se consulta con el usuario, en este caso con el Laboratorio de Ingeniería
Sísmica de la U.C.R., los detalles concernientes a las necesidades y requisitos que debe cumplir
el sistema remoto, además de definir una agenda planificada para la coordinación y el
desarrollo del proyecto.
Se identifica luego el funcionamiento de los acelerógrafos digitales de interés, lo que
incluye interfaces de comunicación, protocolos de comunicación, almacenamiento de datos,
comandos, reconocimiento de los elementos de hardware, compatibilidades entre los sistemas,
etc. Esto por medio de la consulta bibliográfica disponible en manuales o brindada por el
fabricante de forma digital, complementando con simulaciones apropiadas.
Luego se definen las distintas variables o instrumentos de diseño basados en transmisión
en radiofrecuencia. Se procede posteriormente a discriminar aquellas alternativas que no
cumplen satisfactoriamente los requisitos necesarios debido a aspectos tales como la ubicación
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
16
geográfica de las estaciones deseadas, el presupuesto disponible, tiempo como variable
limitante, las necesidades de los usuarios, disponibilidad del equipo y factibilidad. Se justifica
este procedimiento incluyendo las ventajas y desventajas de cada solución.
Una vez escogida la alternativa más adecuada, se realiza la elaboración del marco
teórico con la revisión, obtención, extracción y recopilación de literatura proveniente de libros,
revistas, artículos, bibliotecas y de Internet.
El siguiente paso es el desarrollo de la solución escogida con la adquisición de todas las
herramientas y elementos necesarios, diseño de la interfaz entre el acelerógrafo y el sistema de
comunicación en radiofrecuencia finalizando con pruebas de simulación para su debida
verificación.
Diciembre del 2004
IE-0502
1.3
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
17
Justificación
A raíz de una problemática planteada por parte del director del Laboratorio de
Ingeniería Sísmica de la U.C.R., Ing. Víctor Schmidt Díaz al profesor Dr. Jorge Romero
Chacón se decidió desarrollar una posible solución como proyecto eléctrico, requisito parcial
para completar el plan de estudios de bachillerato.
Esta consiste en la dificultad presente en la recolección de datos digitales de eventos
sísmicos, de las estaciones pertenecientes a este organismo científico que se encuentran fuera
del área metropolitana, en regiones de difícil acceso y sin servicios básicos, ubicadas en lugares
tales como Golfito o Guanacaste (Figura 1.1). Para dicha recolección de datos se requiere
realizar una gran cantidad de procesos administrativos y posteriormente un técnico se moviliza
hasta la ubicación donde se encuentra cada estación con un equipo de cómputo.
Este procedimiento dura un periodo de tiempo inadecuado y poco práctico, por lo que
agilizar la transmisión del sistema de información desde las estaciones sismográficas hasta el
Laboratorio de Ingeniería Sísmica de la U.C.R. es vital para realizar una investigación eficiente
y que reduce al mínimo, los recursos usados para alcanzar los objetivos de la organización y de
operación. Por ello, se pretende con este proyecto crear un instrumento para recolectar los
datos, que a la vez sea capaz de transmitir la información adquirida por cada acelerógrafo.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
18
Figura 1.1 Ubicación Geográfica de Acelerógrafos
Fuente: [15]
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
19
CAPÍTULO 2: Acelerógrafos Kinemetrics
2.1
Características Generales
2.1.1 Descripción General
Kinemetrics Inc. es líder en la industria de equipos sismográficos. Esta empresa
denominó a su línea de acelerógrafos como Altus, de los cuales existen dos tipos, digitales y
analógicos. Los modelos SMA analógicos pueden ser actualizados a sistemas digitales QDR.
a.
b.
Figura 2.1 Acelerógrafos digitales. a. SMA-QDR, b. Etna.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
20
En términos generales, el funcionamiento de un acelerógrafo digital consiste en lo
siguiente: en el momento en que el sensor detecta una señal de velocidad o aceleración del
suelo, se monitorean continuamente esas señales para verificar si cumplen satisfactoriamente
con el criterio de un eventual movimiento sísmico. Cuando las señales cumplen con dicho
criterio, se graban como dato de un evento en una tarjeta PCMCIA o en una memoria flash
dependiendo del modelo.
Los modelos SMA-QDR son equipos simples de adquisición de datos cuyo hardware
consiste esencialmente en sensores sísmicos, convertidor A/D y un sistema basado en
microprocesador encargado de hacer el manejo de la memoria RAM (128kB), procesamiento
digital de las señales, manejo de la memoria flash (512kB) y la comunicación a través del
puerto serial RS-232 de forma muy básica.
Durante operaciones que requieran accesos
significantes a la memoria flash, tales como los necesarios por el usuario para obtener los datos,
la adquisición de datos se debeshabilitar manualmente.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
21
Figura 2.2 Elementos de un acelerógrafo K2.
Fuente [6], página 5.
Los modelos Etna o K2 son más complejos que el anteriormente mencionado pero muy
similares entre sí. Estos equipos están compuestos esencialmente por un puerto de energía
externa, switch para encender el sistema o ponerlo en estado “standby”, una entrada para
sensores externos o un sistema GPS externo, fusibles para protección de sobrecarga, tarjeta
PCMCIA que contiene la circuitería de interfaz para las bahías, bahías PCMCIA para los
SanDisk donde se graban los archivos de los eventos sísmicos, batería con carga para 36 horas
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
22
aproximadamente, un puerto RS-232, conector auxiliar para extender el sistema Altus, conector
a tierra para protección contra descargas electrostáticas y asegurar bajos niveles de ruido, y una
pantalla de LEDs que provee información del estado del equipo.
Figura 2.3 Diagrama de Bloques K2/Etna.
Fuente [4], página 78.
Cabe destacar, que los equipos Etna y K2 tienen una línea externa de hardware la cual
puede ser programada para proveer una señal de encendido para equipos externos. Esta línea
está configurada como una salida activa en bajo de drenaje abierto, permitiendo un uso
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
23
adecuado de la energía de un posible sistema de comunicación externo, sin afectar la autonomía
propia del instrumento o de su batería si esta se utiliza como alimentación para tal propósito.
Además tienen una tarjeta de procesamiento digital de señales que incluye un
convertidor analógico / digital cuya función es digitalizar las señales analógicas provenientes de
los sensores y procesarlas antes de enviar los datos a la tarjeta MCU. La tarjeta MCU (MicroController Unit) recibe la información y decide si la tarjeta PCMCIA debe almacenar esos
datos, también controla la interacción con el puerto de comunicaciones.
Está compuesta
principalmente por un microcontrolador Motorola HC16 con 256kB de RAM, 512kB de
memoria flash para almacenar el firmware, un oscilador interno y un reloj.
2.1.2 RS-232C
El puerto de comunicaciones RS-232C cumple con el estándar DTE, con la excepción
de que usa un conector tipo circular-militar y a la asignación de pines la cual se asemeja a la de
un puerto típico de comunicaciones de una computadora personal. En la tabla 2.1 aparece la
asignación de pines adoptada para estos instrumentos.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
24
Los acelerógrafos usan el circuito integrado Maxim MAX248 RS-232C, que opera a
una velocidad de hasta 57.6 Kbaud. La configuración de la palabra serial está fijada a 8 bits, 1
bit de parada y sin paridad (Conocida como la configuración 8N1), sin ningún tipo de control
de flujo.
Tabla 2.1 Descripción de la asignación de pines de acelerógrafos
Fuente: [4], página 97.
2.1.3 El “firmware”
El firmware controla todos los aspectos de operación del sistema. El módulo conocido
como “bootloader” se ejecuta por la tarjeta principal HC16 cada vez que la unidad se enciende,
introduce una pausa la cual permite al usuario descargar a la unidad una nueva versión de este
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
25
módulo si se le indica a través del puerto RS-232C, o en condiciones normales después de la
pausa, se ejecute el bloque de aplicaciones.
El bloque de aplicaciones es el código MCU que controla la operación del procesador
de la tarjeta principal HC16. Su primer tarea consiste en configurar el FPGA en el sistema y
descargar el código DSP al subsistema de DSP. Posteriormente ejecuta el programa de DSP,
realiza inicialización de hardware adicional y comienza con la adquisición de los datos.
Continúa ejecutándose, controlando la operación del sistema, la interfaz con el usuario, la
escritura de los datos, la comunicación con el usuario, y configurando y controlando el
subsistema de ADC/DSP.
Este bloque de aplicaciones esta escrito en el lenguaje C y usa un RTOS (conocido en
sus siglas en inglés como Real Time Operating System) para controlar las diferentes
herramientas de software del equipo.
El código de DSP está contenido en este bloque de aplicaciones, es el encargado de
manipular la operación de la tarjeta de DSP. Este se encuentra en la memoria flash del MCU, el
cual carga este código en la memoria SRAM del DSP a la hora de inicializar el hardware. Este
código controla el circuito integrado de ADC (Convertidor analógico / digital) encargado de
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
26
adquirir la señal de entrada, luego el programa de DSP filtra y le aplica decimación a estos
datos para su posterior procesamiento por parte del MCU. Este código se encuentra escrito en
lenguaje ensamblador para maximizar la velocidad y eficiencia del equipo.
La interfaz con el usuario sólo permite el acceso a las instrucciones u operaciones
propias de un acelerógrafo y no se permite modificar cualquier parte del código del firmware o
ejecutar alguna aplicación fuera de las incluidas por el paquete predeterminado de herramientas
de software.
2.2
Modos de Comunicación
Los instrumentos Altus digitales tienen cuatro modos de comunicación, donde las
comunicaciones se desarrollan en un protocolo de paquetes de datos binarios. Para los equipos
que tienen un puerto PCMCIA interno donde se les puede instalar un módem compatible, uno
de los siguientes modos de comunicación se activa: modo ANSWER o modo AUTOCALL.
Ambos modos de operación proporcionan control del canal de comunicaciones, el primer modo
espera continuamente una comunicación remota que se contesta automáticamente por el
módem a través del par telefónico, posteriormente inicia una sesión terminal. El segundo modo
realiza la comunicación remota llamando por medio del módem a un número telefónico
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
27
predeterminado cuando ocurre un evento o cuando se programa el acelerógrafo digital para tal
operación.
El modo predeterminado de arranque es el MONITOR. Cuando el instrumento termina
la secuencia de arranque o boot, y no detecta ninguna actividad de comunicación, cambia al
modo BLOCK, ambos se realizan a través del puerto serial RS-232C incorporado con
velocidades de 1200 baudios a 57600 baudios. Para cambiar de modo de operación de BLOCK
a MONITOR se utiliza el comando '\\\<cr>' y para la forma inversa se utiliza el comando
'BLOCKMODE<cr>'. Los comandos enviados y las respuestas por parte de los acelerógrafos
son en caracteres ASCII.
Todos los dispositivos Altus están habilitados para realizar comunicaciones digitales por
el puerto serial al incluir en cada sistema los distintos modos de comunicación, de esta forma se
garantiza la compatibilidad entre todos los dispositivos y las interfaces, tanto de hardware como
de software.
La diferencia existente radica en los comandos que cada modelo soporta e
incluye.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
28
2.2.1 Modo Terminal o Monitor
El modo monitor utiliza una ventana terminal, usa el protocolo de comunicaciones
estandarizado RS-232C que acepta y recibe caracteres tipo ASCII. El formato general de los
comandos consiste en el comando más los argumentos, terminando con <cr> (carriage return).
Estos se dividen en tres categorías; los comandos principales ('*' prompt), los comandos del
editor de parámetros ('EDIT>' prompt) y los comandos de diagnóstico ('DG>' prompt). Estos
están compuestos por las tres primeras letras de la palabra del comando.
Las velocidades disponibles a través del puerto serial son las siguientes: 57600, 38400,
19200, 9600, 4800, 2400 y 1200 baudios, la velocidad predeterminada por el fabricante
inicialmente es de 19200 baudios. Cuando se desconoce la velocidad del puerto serial del
acelerógrafo y el parámetro AUTOBAUD se encuentra activado, se envían dos caracteres
BREAK en un intervalo menor a 5 segundos. Esto inicia una secuencia que finaliza al devolver
en caracteres ASCII el baudaje actual del acelerógrafo cuando coincide con el predeterminado
en el sistema huésped; por lo tanto, la secuencia decrementa la velocidad hasta que se da el
despliegue en la terminal al repetirse este procedimiento. Posteriormente es necesario entrar en
el modo de comunicación adecuado.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
29
Los principales comandos son:
*\\\<cr>: Entrar a modo monitor.
A:,B: Cambiar de unidad actual.
ALARM ALARM n: Fija el número de niveles de alarmas habilitados.
ALARM DURATION s: Fija la duración en segundos para las alarmas.
ALARM OFF: Apaga las alarmas.
ANSWERMODE: Entra en modo ANSWER. El equipo requiere un módem interno. Se termina
con '\'.
AQ ON/OFF: Habilita/deshabilita la adquisición de datos.
AQ AUTO_DELETE n: Habilita/deshabilita el borrado automático de archivos. Cuando se
habilita (n=1) se borran los archivos con los registros de menores amplitudes cuando hay
menos de 90% de espacio libre.
AQ CLEAR_EVENT_COUNTER n: Habilita (1)/deshabilita (0) el contador de eventos en el
arranque. Usado para iniciar el conteo sincronizado con los eventos y construir el nombre del
último archivo de evento creado.
AQ DVM: Indica el número de señales de entrada en adquisición.
AQ FT: Ejecuta una prueba funcional de grabado.
AQ TRIGGER: Cuando la adquisición está habilitada, inicia el grabado de un evento de teclado.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
30
AQ DETRIGGER: Cuando la adquisición está habilitada, termina de grabar un evento de
teclado.
AUTOBAUD n: Habilita (1)/ Deshabilita (0) la secuencia de detección de velocidad.
debeshabilitarse cuando se está usando equipo de comunicaciones externo conectado al puerto
serial, dado que caracteres tipo BREAK causan que el instrumento cambie de velocidad.
BAUDRATE r: Cambia permanentemente la velocidad en baudios. Las velocidades (r) son
57600, 38400, 19200, 9600, 4800, 2400 y 1200. (Comando ejecutable sólo en modo monitor)
BLOCKMODE: Termina modo terminal (comunicación serial de caracteres) e inicia modo
blockmode (comunicación binaria de paquetes).
CALLMODE: Entra en modo AUTOCALL. El equipo requiere un módem interno. Se termina
con '\'.
CD p, CHDIR p: Comando para cambiar de directorio. p = nombre del directorio.
COPY af da: Copia un archivo. Af: Archivo fuente, da= Destino de archivo.
DEL p: Borra un archivo de evento del directorio actual.
DG: Entra en modo diagnóstico. ABORT o QUIT terminan el modo.
DIR p: Muestra los directorios o contenidos del directorio. p = nombre del directorio. Este
comando es similar al usado en MS-DOS o Unix donde la información consiste en los nombres
de los archivos, la extensión de cada archivo, tamaño y fecha de creación o modificación del
archivo.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
31
DISPLAY BITMAP: Muestra los canales seleccionados para grabar.
DISPLAY CHANNEL: Muestra los parámetros del canal.
DISPLAY RWMISC: Muestra información extra de la condición actual.
DISPLAY SENSOR: Muestra información relacionada con el sensor.
DISPLAY SERIAL_DATA_STREAM: Muestra los parámetros de los datos seriales.
DISPLAY WRITE archivo: Escribe a un archivo específico todos los parámetros de display.
EDIT: Inicia modo editor de parámetros. ABORT o QUIT terminan el modo.
ERASE p: Borra un archivo de evento del directorio actual.
FORMAT d: Formatea para el uso adecuado una nueva unidad PCMCIA. (Comando ejecutable
sólo en modo monitor)
HELP: Muestra una lista de los comandos principales.
MD p, MKDIR p: Crea un nuevo directorio. p = nombre del directorio. (Comando ejecutable
sólo en modo monitor)
PASSWORD w: Introducir clave. Predeterminada=””.
PASSWORD NEW w: Cambio de clave.
RENAME nva nna: Cambia el nombre de archivos de eventos. nva = nombre viejo de archivo,
nna = nombre nuevo de archivo. (Comando ejecutable sólo en modo monitor)
RD p, RMDIR p: Borra el directorio p. Este tiene que estar vacío. (Comando ejecutable sólo en
modo monitor)
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
32
RX an: Recibe el archivo an desde el sistema huésped usando transferencia XMODEM CRC.
STATUS: Muestra el estatus actual del acelerógrafo.
SUMMARY: Muestra un resumen de texto sobre los archivos de eventos en el directorio actual.
SYSTEM LOAD: Reinicia el sistema desde el bootloader sin resetear el hardware.
SYSTEM RESET: Resetea el instrumento Altus. (Comando ejecutable sólo en modo monitor)
TIME y,m,d,h,m,s: Fija una nueva fecha y hora donde y = año, m = mes, d = dia, h= hora, m =
minuto, y s = segundo. La adquisición debe estar deshabilitada antes de usar este comando.
TX fn [H] [K] [T] [lista de canales]: Transmite un archivo hacia el sistema huésped usando
transferencia XMODEM CRC, fn es el nombre del archivo a transmitir. [H] permite transmitir
el encabezado (header) nada más. [K] permite transmitir usando el protocolo XMODEM-1K.
[T] transmite los datos truncados a 16 bits.
VERSION: Muestra la versión del software.
WIPEDISK d: Borra toda la unidad. d = nombre de la unidad. (Comando ejecutable sólo en
modo monitor)
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
33
2.2.2 Modo “Block” - Comunicación Binaria de Paquetes
Es importante saber que este modo de comunicación es sólo para los instrumentos K2 y
Etna. Para cualquier cadena mayor a un byte, se tiene predeterminado el formato Motorola, el
byte más significativo de primero. La estructura del paquete binario tiene la siguiente forma:
<PKTFRAME> (1 byte)
Packet Header (8 bytes)
Unsigned char typeCode
// comando o número de respuesta
Unsigned char seqNo
// número interno, módulo 256
Unsigned short source
// número de tarea
Unsigned short destination
// 0x0000
Unsigned short dataLength
// número de bytes en cada área de dato
Header Checksum (1 byte)
PacketData // 0 bytes a 2992 bytes
Data Checksum/CRC (2 bytes) // siempre se envía, 0x0000 si no hay data bytes
<PKTFRAME> (1 byte)
<PKTFRAME> (1 byte)
El protocolo de paquetes tiene dos códigos reservados: <PKTFRAME> (en hexadecimal
corresponde a 0xC0) y <PKTESC> (en hexadecimal corresponde a 0x5C).
Los paquetes
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
34
inician con el carácter PKTFRAME y terminan con dos de estos últimos. Antes de transmitir el
paquete, el remitente debe sustituir todas las ocurrencias de los bytes de datos (es decir, esos
bytes entre el carácter de inicio y los caracteres de conclusión <PKTFRAME>) 0xC0 y 0x5C
por una secuencia de salida equivalente del byte:
END_EQUIVALENT:
Datos 0xC0 se reemplazan por <0x5C> <0xDD>
ENC_EQUIVALENT:
Datos 0x5C se reemplazan por <0x5C> <0xDC>
Esto, con el fin de no producir una mala interpretación en el flujo de datos con los
códigos reservados.
En la recepción del paquete, el receptor debe traducir estos bytes
especiales por sus caracteres iniciales de un byte.
Después del primer <PKTFRAME> viene el encabezado del paquete, compuesto por
una estructura de 8 bytes.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
35
Figura 2.4 Paquetes de comandos enviados por PC/huésped.
Fuente: [3], página 19.
El primer byte corresponde al código del tipo de paquete (typeCode). Existen dos tipos
de paquetes: los paquetes de comandos (con el prefijo PKC_) y los paquetes de respuesta (con
el prefijo PKR_). Para cada paquete de comando enviado desde la computadora al instrumento
Altus debe recibirse un paquete de respuesta, si este no es recibido en un periodo de tiempo
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
36
adecuado se debe reenviar el paquete de comando. Los paquetes enviados desde el instrumento
Altus hacia la computadora no ocupan de un paquete de respuesta como confirmación.
Figura 2.5 Paquetes de comandos enviados por equipo Altus.
Fuente: [3], página 19.
El segundo byte corresponde al código de la secuencia de paquetes (seqNo), es usado
para sincronizar los paquetes de respuesta con los paquetes de comandos. Cuando el transmisor
envía un paquete de comando, predetermina el código de secuencia a un número entre 0x00 y
0xFF. El receptor recibe el paquete de comando, lo procesa, y envía de vuelta un paquete de
respuesta con el mismo código de secuencia. De esta forma el transmisor sabe cual código del
paquete de respuesta le corresponde a cada paquete de comando. Si fuera el caso de que se
requiera retransmitir un paquete debido a algún error de transmisión, el receptor puede volver a
pedir el paquete con el mismo número de secuencia. Sólo se puede pedir la retransmisión del
último paquete.
El tercer, cuarto, quinto y sexto byte corresponden a la identidad de la fuente y del
destino (source, destination), esto se debe a que más de una tarea en la computadora se puede
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
37
comunicar independientemente con el equipo. A cada tarea se le asigna una identificación
distinta para poder diferenciarlos. En una transmisión típica, el instrumento Altus responde al
enviar de vuelta un paquete de respuesta con la identificación del destino; la computadora
recibe este paquete y enruta el paquete apropiadamente hacia la tarea correspondiente para su
procesamiento.
El sétimo y octavo byte corresponden a la longitud del paquete de datos (dataLength) en
bytes. El tamaño máximo para un paquete de datos es de 2992 bytes, el tamaño mínimo es de 0
bytes.
Posteriormente al paquete de encabezado le sigue el byte de chequeo correspondiente
(Header checksum), luego prosigue lo que son los paquetes de los datos con sus dos bytes de
chequeo CRC (Data Checksum), finalmente se termina la transmisión con los bytes del código
reservado <PKTFRAME>.
La secuencia: <PKTESC> <PKTESC> <PKTESC> <0X0D> es una secuencia especial
interpretada como instrucción para detener el procesamiento de paquetes y retornar el control
hacia el teclado; esta es equivalente a escribir “\\\\” y <Enter> en el teclado. Se observa que es
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
38
la misma secuencia utilizada para entrar en el modo terminal desde el modo de comunicación
binaria de paquetes y es usada para dar al usuario el control manual del equipo.
Es importante ver la utilidad de este modo de comunicación, ciertamente existen
comandos del modo terminal que no se pueden ejecutar con este modo, sin embargo este
permite ejecutar el protocolo de datos seriales (SDS) en tiempo real. Este protocolo permite
recibir los datos provenientes de los sensores con el comando PKR_STRDATA o con el
comando PKR_STRRQDATA.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
39
CAPÍTULO 3: GPRS y Sistemas Incrustados
3.1 GPRS
3.1.1 Antecedentes
A partir del momento en que el sistema WAP alcanzó popularidad durante el año 2000
alrededor del mundo los usuarios notaron algunos defectos tales como la velocidad, costos y su
falta de comodidad en el uso.
El hecho mas importante de esto es que muchas de las
características de WAP sobre GSM que los usuarios se quejaban no eran propias del
rendimiento WAP, sino más bien eran problemas típicos de redes CS (conocido en sus siglas en
inglés como Circuit-Switched Networks). Una conexión típica usando estas redes funciona
como una llamada telefónica regular, donde se marca un número telefónico a un ISP y se tiene
una velocidad de 9.6Kbps mientras dure la sesión y no se comparta esta capacidad con otro
usuario.
Esta solución es óptima para aplicaciones de
sonido y voz, sin embargo para
aplicaciones tales como navegación WAP se vuelve ineficiente tanto para el usuario como para
el operador.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
40
Los sistemas GSM usan la división múltiple de tiempo (conocido en sus siglas en inglés
como TDMA), donde se separan los usuarios en tiempo al asignarles distintos canales por cada
espacio de radio. En GSM existen ocho divisiones o canales por espacio, dándole al usuario la
oportunidad de transmitir cada ocho divisiones de tiempo como se observa en la figura 3.1.
Usuario 1
0
Canal 1
1
Usuario 4
2
3
Canal 4
Usuario 6
4
5
6
Usuario 1
7
0
1
2
3
4
5
6
7
Canal 6
1 Espacio = 8 canales
Tiempo
Figura 3.1 Divisiones en GSM.
Figura 3.2 Uso de las divisiones de tiempo.
Fuente: [7], página 30.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
41
La figura 3.2 muestra que un canal de radio es asignado a un usuario y que se
transfieren los datos usando una de las ocho posibles divisiones de tiempo disponibles en un
sistema GSM/WAP. Una de estas divisiones es equivalente a la capacidad requerida para una
llamada de voz y hay ocho de estas divisiones por cada una de las unidades de transmisiónrecepción ubicadas en cada estación.
Sin importar cuantos datos y cuando se estén
transmitiendo, los datos de una red CS ocupan al menos una de estas divisiones durante la
sesión.
Similarmente, el operador no puede aprovechar sus capacidades al máximo dado que
nadie puede accesar a la sección no usada del canal. Esta situación es parte del problema al
usarse redes de datos CS, aparte de lo anteriormente mencionado que cada vez que se desee
obtener información se debe iniciar una nueva sesión (si no se encuentra conectado), la cual
dura aproximadamente en establecerse un periodo de 20 a 40 segundos si no se usan
enrutadores especiales; lo cual reduce el tiempo a unos 5-10 segundos. En resumen, las redes
CS son menos convenientes para sesiones de datos cuando no se tiene garantizada una
velocidad de transmisión especifica y donde la cantidad de información que se transmite o
recibe varía enormemente, incurriendo en un alto costo tanto para el usuario como para el
operador.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
42
Estos problemas se solucionan al usarse paquetes de datos en la red, lo que también
permite que varios usuarios compartan a la vez los recursos de radio de forma similar a la que
el tráfico de datos es manejado en la Internet para maximizar la eficiencia. El sistema GPRS
tiene un mayor alcance, donde los usuarios no sólo comparten la capacidad, sino también se
comparte comunicaciones de datos y voz al mismo tiempo. Este concepto se ejemplifica en la
figura 3.3 donde dos usuarios de GPRS comparten las dos primeras divisiones (también se
permite compartir sólo una división) sin percibir una degradación en la calidad de la velocidad
de transmisión de datos; aquí también se observa que al mismo tiempo se usan las divisiones
del tres al siete para otras comunicaciones de voz o datos sin afectar las sesiones de GPRS.
Figura 3.3 Datos y voz compartidos en GPRS.
Fuente: [7], página 31.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
43
Esta característica es aprovechada también por el operador, el cual puede acomodar
varias comunicaciones a la vez en la misma red, permitiendo también emplear otras secciones
de la red que no se podían usar anteriormente.
3.1.2 Principales características del GPRS
La transmisión inalámbrica de paquetes de datos, GPRS, tiene tres características
fundamentales que la describen; la opción de estar siempre “en línea” o conectado al sistema de
forma similar a una conexión DSL a la Internet, consiste en una actualización de la
infraestructura ya existente y es una forma de introducción de los futuros sistemas 3G. A
continuación se detalla cada una de estas características.
Como se mencionó anteriormente, GPRS permite al usuario estar conectado y
permanecer siempre en línea sin la necesidad de realizar un pago del costo por minuto de uso.
Esta funcionalidad implica un cambio importante en el uso de aplicaciones móviles como los
teléfonos celulares, agendas digitales o las computadoras portátiles. De la misma forma que se
indicó antes, esta función no es exclusiva del GPRS sino también de otras tecnologías de
Internet tales como RDSI o ADSL que la emplean; sin embargo, es la primera vez que las redes
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
44
móviles de Internet tienen esta característica; en contraste con las redes CS que requieren de un
proceso de conexión. Esta diferencia es la misma que existe entre tener una conexión de
Internet con una computadora personal por medio de un módem, forma usual en nuestro país
para las residencias, y de tener esta misma pero por medio de banda ancha donde la red está
siempre disponible sin ningún proceso de conexión. Esto último se ilustra en la figura 3.4.
Figura 3.4 Comparación de típica sesión GPRS y CS.
Fuente: [7], página 33.
GPRS no es un sistema completamente nuevo; es una actualización que amplía el
potencial de las redes existentes GSM. El funcionamiento usual de las llamadas de voz se
mantiene para cualquier aparato móvil, hasta es posible para algunos de estos tener
simultáneamente tanto una comunicación de voz como de datos. Esta situación es posible
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
45
porque GPRS se introduce como una simple actualización de software para la mayoría de
equipos ubicados en las estaciones centrales, sin la necesidad de construir una infraestructura
completamente nueva y sin requerir movilizarse hasta cada una de las torres de transmisión,
con bajos costos por la implementación de esta tecnología.
Figura 3.5 Implementación de GPRS sobre una red ya existente.
Fuente: [7], página 34.
3.1.3 Arquitectura de la red GPRS
Figura 3.6 Arquitectura de un sistema móvil.
Fuente: [7], página 4.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
46
En la figura 3.6 se muestra un ejemplo típico de una red celular como la GSM donde
cada MSC está conectada a varias BSC y cada una de estas controla a la vez varias BTS.
Telephone
Network
Internet
Network
Figura 3.7 Arquitectura de un sistema GPRS.
Fuente: [7], página 37.
En la figura 3.7 se tiene la arquitectura de un sistema GPRS, se omiten varios nodos
fuera del interés de esta investigación como el HLR (Home Location Registry), el AuC
(Authentication Center), el EIR (Equipment Identity Registry) y el SMS-C (Short Message
Service Center).
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
47
Un elemento importante de la estandarización del GPRS consiste en ser una transición
simple y barata. Para esto no se podía modificar o cambiar las torres de transmisión por los
costos que implicaría esto, por lo que sólo puede ser una actualización del software.
En GSM, la interfaz Abis está estandarizada para facilitar la conexión entre las BTS y
una BSC. Los datos que pasan por esta interfaz son GSM y paquetes GPRS, porque estos
comparten las misma interfaz en radiofrecuencia y permite abaratar los costos. Para manejar
eficientemente esto se requiere tener distintos núcleos de redes, el correspondiente al existente
GSM más el nuevo para los paquetes GPRS. La separación de los distintos flujos de datos se
realiza en las BSC con la adición de hardware, específicamente un PCU (Packet Control Unit).
La PCU separa los dos distintos flujos de datos provenientes del dispositivo móvil y
multiplexa estos en uno sólo cuando se dirigen desde la red de datos y la red de voz hacia este.
La BSC requiere una actualización de software para manejar los nuevos canales con los
paquetes de datos multiplexados. La mayoría de las nuevas funciones que se agregan a la
interfaz son implementados en la BSC, donde se conectan varias estaciones y un SGSN.
El núcleo de la red de GPRS tiene dos nodos principales: el SGSN y el GGSN, cuando
se menciona a ambos se refieren como GSN. Para conectar estos nodos a la red de radio se
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
48
requiere una nueva interfaz llamada Gb que es una conexión de alta velocidad “Frame Relay”
que se corre usando una conexión E1 o T1. La conexión entre los distintos nodos GSN y otros
componentes de la red se llama “GPRS backbone”. Esta es una red sobre IP que tiene
enrutadores de acceso, firewalls y otros. Usualmente se conecta con el servicio que factura el
uso.
El SGSN tiene la responsabilidad de la movilidad de los paquetes de datos. Cuando se
realiza una conexión a la red GPRS el MS tiene una conexión lógica al SGSN y puede ejecutar
negociaciones entre distintas torres sin ningún cambio en esa conexión. El SGSN mantiene un
registro de cual BSC usar para enviar los paquetes a un MS originados fuera de la red, su
funcionalidad es similar a la de un enrutador IP. Entre otras funciones están la autenticación de
los usuarios, la distribución de las direcciones IP y el cifrado.
Debido a las características de una conexión por radio distintas a un enlace fijo y que se
pierden bits existen funciones adicionales. El protocolo RLC (conocido en sus siglas en inglés
como “Radio Link Control”) que opera entre un MS y las estaciones de radio, reenvía los datos
que se pierden en el aire. El protocolo LLC (conocido en sus siglas en inglés como “Logical
Link Control”), entre el MS y un SGSN, puede ser configurado para ejecutar funciones
similares. Cuando un MS está conectado a una página de Internet, la mayoría de la pérdida de
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
49
datos ocurren en el enlace por radio y manejar esto con un protocolo en una capa superior como
el TCP puede ser muy ineficiente.
El GGSN es similar a la combinación de un gateway, un firewall y un enrutador IP. El
GGSN maneja las interfases con las redes IP externas, los proveedores de Internet, enrutadores
y nodos adyacentes. Para una red externa, el GGSN aparece como cualquier gateway que puede
enrutar paquetes a los usuarios dentro de su propio dominio. Este mantiene un registro del
SGSN al cual un MS en específico está conectado para enviar los datos correspondientes. Un
SGSN y un GGSN pueden localizarse físicamente de forma distante por medio del backbone o
cerca. Esto dado a que el backbone se puede compartir con otros operadores usando un
protocolo llamado GTP (conocido en sus siglas en inglés como “GPRS Tunneling Protocol”).
En otras palabras, los paquetes que viajan por el backbone GPRS tienen un apilado con IP y
TCP en dos niveles como se ve en la figura 3.8.
Figura 3.8 Niveles de transporte de un paquete GPRS.
Fuente: [7], página 39.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
50
3.1.4 Dispositivos GPRS
Existen varios tipos de dispositivos móviles (equipos donde las aplicaciones se ejecutan)
que incluyen equipos terminales con distintas capacidades. Estos se pueden dividir en tres
clases.
Clase A
Son los equipos terminales capaces de manejar datos y voz al mismo tiempo. Para esto
se ocupan dos “transceivers” porque se necesita enviar/recibir datos y voz por separado.
Clase B
Son los equipos terminales capaces de manejar datos y voz pero no al mismo tiempo.
Se usa un único “transceiver”; en la práctica, la sesión GPRS se suspende (como cuando se
navega en WAP) cuando entra una llamada de voz GSM.
Clase C
Son los equipos terminales capaces de manejar sólo datos o voz.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
51
El flujo teórico de datos de GPRS es de 170Kbps asumiendo que se usan las ocho
divisiones de tiempo y que ningún otro usuario las está compartiendo. Existen 31 tipos de
configuraciones definidas para las terminales indicadas anteriormente, en la realidad estos
limitan el flujo de datos. Por ejemplo, una terminal 4+1 puede recibir datos usando cuatro
divisiones de tiempo y enviar datos usando sólo una división de tiempo, la capacidad por
división varía (9Kbps a 20Kbps) dependiendo de la compresión de datos usada.
Para los teléfonos GPRS, donde el consumo de potencia es un factor importante, la
configuración usada responde a la disipación de energía en forma de calor y el consumo de la
batería que las altas velocidades de transferencia disponen.
Por eso es difícil construir
dispositivos que usen la configuración 8+8 por el enorme consumo de energía y la alta
disipación requiriendo ventilación por convección forzada, muy poco práctico para este tipo de
aplicaciones.
Una terminal 4+1 debe ser capaz de usar cinco divisiones al mismo tiempo, lo que deja
tres para otros propósitos como señales de control para mantener la conexión con la torre de
transmisión.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
52
3.1.5 Comandos AT
Con las funciones adicionales de los dispositivos GPRS es posible para los
desarrolladores de aplicaciones accesar al hardware terminal GPRS y a las propiedades de la
red directamente. El estándar GPRS define los comandos AT para ello. Los comandos AT son
desarrollados con las recomendaciones del ITU V.25ter (control y llamado automático serial
asincrónico) en consideración a lo que la comunicación de equipos ofrece a las capas
superiores. Por ello, muchos de estos se parecen a los de GSM y módems fijos y los estándares
se mencionan en el apéndice. En las especificaciones de los estándares el terminal móvil (MT)
se divide en el adaptador terminal (TA) y el equipo móvil (ME) donde el TA es la etapa donde
se interpretan los comandos, figura 3.9.
Figura 3.9 Acceso de comandos AT al MT.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
53
Fuente: [7], página 43.
Para comunicarse directamente con el módem del MT se pueden usar distintos métodos,
desde llamadas de sistema en un lenguaje programadas hasta una sesión telnet.
Los comandos se dividen en los básicos y los extendidos como se definen en el V.25ter.
El prefijo AT inicia cada comando y múltiplos comandos pueden ser agregados con el prefijo
+. Estos incluyen lo siguiente:
•
Compresión de datos de 24bits
•
Compresión del encabezado
•
Requerimiento del perfil de QoS (calidad del servicio)
•
Requerimientos de operación (A, B o C)
•
Des/Enganchar servicio GPRS
•
Requerir estatus de la red.
3.1.6 Acceso a la red
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
54
El procedimiento inicia cuando el dispositivo le indica a la red el tipo de clase al cual
corresponde, A, B o C y de esta forma indica las capacidades. Este procedimiento se llama
enganche y es similar para GSM y GPRS. El proceso para GSM incluye la autenticación, el
cifrado, etcétera y pone al usuario en estado de espera listo para hacer o recibir llamadas. Para
GPRS se crea un enlace lógico entre el SGSN y el MS. Esta tarea se efectúa de la siguiente
manera:
1. El MS envía una petición para iniciar al SGSN.
2. El SGSN determina si conoce el MS y trata de encontrar su número de identificación. Si el
MS no es conocido, se envía un mensaje de error.
3. El SGSN ejecuta la autenticación del MS.
4. Si el MS se encuentra en una nueva área de servicio el HLR (“Home Location Registry”) y el
MSC (“Mobile Switching Center”) se actualizan.
5. El SGSN le indica al MS de la identificación de enlace temporal asignada (TLLI) usada
durante toda la sesión para identificar el enlace lógico existente entre el MS y el SGSN.
En el momento en que se establece un enlace entre el MS y el SGSN el equipo móvil
necesita adquirir una dirección IP. Esta tarea se realiza por medio del PDP (“Packet Data
Protocol”), que puede ser visto como un registro de software que mantiene los parámetros
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
55
relevantes a cierta conexión como el protocolo usado (IP o X25), la dirección IP, el perfil de
calidad y la información de la compresión.
Los parámetros PDP pueden fijarse por la
aplicación usando los comandos AT. Los pasos de este procedimiento son los siguientes:
1. El MS envía una petición PDP al SGSN.
2. Funciones de seguridad se ejecutan entre el MS y el SGSN para validar la petición.
3. El SGSN revisa la suscripción, la calidad del servicio, envía información al GGSN de cómo
conectarse con el MS y configura el enlace lógico al GGSN configurando un túnel.
4. El GGSN contacta al proveedor de Internet y adquiere una dirección IP para el MS.
5. La dirección IP asignada se envía de vuelta al MS.
Existen otros métodos para asignarle la dirección IP al MS. Entre ellas están que el
GGSN asigna una dirección IP dinámica de su propio banco de direcciones o que el SGSN
requiera del HLR una dirección estática.
Raramente se usan direcciones IP estáticas, debido al uso de IPv4 que aplica una
restricción al proveedor de direcciones IP. El IPv6 se está adoptando gradualmente en la
Internet; sin embargo, la versión inicial del GPRS no lo soporta. En el futuro será así por la
amplia cantidad de usuarios de equipos móviles que no se podrá manejar usando el IPv4.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
56
3.2 Sistemas Incrustados
Un sistema incrustado, también conocido como empotrado o embebido, se puede
entender como una pequeña computadora o hasta un chip, capaz de ser programado y empleado
generalmente para desempeñar una tarea en específico como controlar sistemas de procesos, ser
sistemas de comunicaciones como un enrutador o firewall en redes locales o de Internet,
sistema de navegación, en equipos médicos, controles en automóviles, etcétera. Las funciones,
capacidades y arquitectura difieren entre cada sistema incrustado, dependiendo exclusivamente
de la aplicación por ser sistemas altamente optimizados para abaratar el costo de su
implementación.
En términos generales tienen capacidad de tener entradas y salidas, con la lógica de
control guardada en una memoria muy limitada, sin capacidad de expansión y con una interfaz
para el usuario mínima o hasta inexistente.
Usualmente todos los componentes como el
microprocesador, la memoria RAM, puertos I/O, fuente de poder y demás controladores están
en una sola tarjeta impresa o conocido también como SBC.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
57
En la actualidad se pueden encontrar dispositivos cotidianos que son sistemas
incrustados complejos en el área industrial o comercial tales como teléfonos celulares de
fabricantes como Samsung o Motorola, agendas electrónicas como las conocidas Palm y
dispositivos multimedia como el reproductor de mp3's Ipod.
Estos sistemas son controlados por un sistema operativo encargado de manejar las tareas
que desempeña, muchos de los cuales son RTOS como el usado en los acelerógrafos
anteriormente mencionados.
Cada sistema empotrado puede tener un sistema operativo
exclusivo para el funcionamiento del dispositivo; sin embargo la tendencia actual es usar
soluciones de software que reduzcan el costo en especial si son aplicaciones comerciales, que
sean altamente soportadas, estables y sean fácil de actualizar. La velocidad con la que avanzan
las innovaciones en hardware presentan un enorme desafío para los RTOS comerciales que
fácilmente pueden dejar de soportar a los desarrolladores que desean en sus diseños el hardware
y software más confiable o actual. La principal característica que diferencia un RTOS con un
sistema operativo común de una computadora personal es el requerimiento de una rápida y
garantizada respuesta en el tiempo para una única aplicación.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
58
El sistema operativo con más impulso y proyección en la actualidad para estos sistemas
es Linux por sus grandes ventajas que ofrece. Linux ofrece confiabilidad y eficiencia porque es
un sistema operativo de código fuente abierto, esto quiere decir que puede cambiarlo cualquiera
para que un producto dado sea exitoso, depurable y compatible. Esto permite que miles de
desarrolladores alrededor del mundo le apliquen mejoras y adiciones en términos del
funcionamiento, desarrollo de controladores, aprovechamiento de recursos y adaptación para
distintas arquitecturas de microprocesadores como x86, PowerPC, MIPS, SuperH y SPARC.
Otra ventaja que ofrece Linux es el no tener la necesidad de pagar la cuota de licencia,
derechos de autor o tarifa por el código fuente implicando una reducción sustancial en el
desarrollo de aplicaciones empotradas. Con el paso de los años la tendencia típica para los
sistemas incrustados de introducir la menor cantidad de bytes en la memoria se ha visto
influenciada también con el factor del tiempo para implementar una gran cantidad de funciones
en sus soluciones, por lo que se puede aprovechar el soporte ya existente de gran cantidad de
paquetes programados.
Uno de los elementos más importantes de un sistema operativo es el kernel. Se puede
entender como el núcleo del sistema operativo. Es el software responsable de facilitar a los
distintos programas acceso seguro al hardware de la computadora. Como hay muchos
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
59
programas y el acceso al hardware es limitado, el núcleo también se encarga de decidir qué
programa podrá hacer uso de un dispositivo de hardware y durante cuánto tiempo, lo que se
conoce como multiplexado. Acceder al hardware directamente puede ser realmente complejo,
por lo que los núcleos suelen implementar una serie de abstracciones del hardware. En el
kernel se especifican los soportes del hardware y por ejemplo se configura las opciones para
operar como un RTOS.
CAPÍTULO 4: Propuesta de diseño y prototipo
4.1 Propuesta
A partir del estudio realizado a los acelerógrafos se logra ver que el único medio para
interactuar con ellos y establecer una comunicación exterior es a través del puerto serial. Un
sistema empotrado con un puerto serial permite operar los modos de comunicación habilitados
y efectuar las tareas cotidianas necesarias para adquirir la información o cambiar los parámetros
de operación de los acelerógrafos.
Entre otras ventajas que tiene el usar un sistema incrustado con el sistema operativo
Linux como interfaz es su facilidad para adaptarse y aprovechar al máximo el puerto serial.
Con el sistema operativo Linux se cuenta con una gran cantidad de soporte de hardware y
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
software, como sistemas de comunicación y protocolos de Internet.
60
Un aspecto muy
importante es la habilidad de depurar y ser altamente estable. Linux puede considerarse como
el sistema operativo más estable después de FreeBSD.
También permitiría tener una copia de seguridad de los archivos guardados en los
acelerógrafos en caso de falla o por tener necesidad de accesar a archivos de registros sísmicos
poco recientes, dado que en los acelerógrafos se van borrando para tener sólo los eventos mas
recientes por el espacio reducido que estos tienen. Esta opción es de gran interés científico para
el L.I.S. porque permitiría tener a fácil alcance un historial amplio de todos los eventos de una
región dada, permitiendo por ejemplo la elaboración de estudios estadísticos.
Como medio de comunicación en radiofrecuencia se opta por usar un dispositivo GPRS
que son soportados por Linux. Las ventajas que tiene este medio son que la infraestructura ya
se encuentra presente reduciendo la inversión para establecer el enlace, esta tiene una amplia
cobertura en todo el país y además hay una gran cantidad de dispositivos compatibles en el
mercado local listos para operar con esta función sin la preocupación de tener que exportarlos
fuera del país en caso de falla. Además para el enlace no hay necesidad de tener línea vista
entre el L.I.S. y cada estación como otras alternativas tratadas en el presente trabajo.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
61
Se puede adquirir sistemas empotrados que cumplan con las necesidades de esta
aplicación a un bajo precio como el TS-7200 de Technologic Systems1 cuyo costo es de
aproximadamente $140.
Con respecto al dispositivo GPRS, como puede ser un teléfono
celular, se puede encontrar en el mercado local muchos modelos con un costo de $90, también
se pueden adquirir equipos exclusivos para operar sólo con esta función, fuera del país, más
económicos.
Una desventaja de este tipo de solución es que su costo de oportunidad no se aplica para
las estaciones que se encuentran en el valle central; sin embargo, estas no son prioridad para el
L.I.S. y se puede usar soluciones que se mencionan en el capítulo 5 en sustitución.
Es importante mencionar que se ocupa una computadora con Linux para operar este
medio de comunicación.
4.2 Desarrollo
4.2.1
1
Aspectos generales
Dirección de Internet: http://www.embedded586.com/epc/ts7200-spec-p.php
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
62
Figura 4.1 Sistema incrustado Net4801
Para el desarrollo del prototipo se cuenta con una SBC modelo Net4801 de Soekris
Engineering como sistema incrustado. Está basado en el procesador embebido SC1100 de
AMD y es básicamente una computadora compatible con la arquitectura PC, optimizada para
redes y aplicaciones de comunicaciones.
Entre sus características de hardware se puede
mencionar que tiene 128 megabytes PC133 de memoria SDRAM, una ranura PCI de 3.3V y
otra mini-PCI tipo IIIA, tres conectores Ethernet usando el chip DP83816 de National
Semiconductors, dos puertos seriales usando la UART 16C550, un puerto USB, un socket para
memoria CompactFlash y varios pines GPIO. Como elemento de almacenamiento se cuenta
con una memoria CompactFlash de 32 megabytes.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
63
El BIOS de la Net4801 está diseñado para operar usando el primer puerto serial como
consola y se encuentra en la memoria Flash, puede ser actualizado usando el mismo puerto
serial. Tiene funciones incluidas para modificar los parámetros del puerto serial o indicar cual
dispositivo se debe iniciar primero, incluye la posibilidad de arrancar un sistema operativo
usando el PXE boot ROM sobre la red desde un sistema huésped.
La velocidad del puerto serial predeterminada es de 19200bps, usa un conector estándar
PC de 9 pines D-SUB, por lo que cualquier cable crossover sirve para conectar otra
computadora. La terminal conectada debe ser ANSI/VT100 configurada para operar a una
velocidad de 19200, 8 databits, sin paridad, 1 bit de parada y sin ningún control de flujo.
Como dispositivo GPRS se cuenta con un teléfono celular Motorola modelo C333, este
teléfono es clase B compatible con redes GSM1900 y GSM850. Las especificaciones GPRS
incluyen que es clase 8 (4+1) y módem de 32-40 kbps. Contiene antena interna y batería de LiIon con tiempo de operación en reposo de 250 horas.
Se evaluaron distintas distribuciones del sistema operativo Linux; entre ellas están
PeeWee, ELW, Debian, RedHat y Pebble, que operan en el sistema incrustado sin ningún
problema.
Sin embargo ninguna cumplía satisfactoriamente por diferentes motivos como
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
64
exceso de programas de poca utilidad para la presente aplicación, algunas usaban demasiado
espacio y no alcanzaba en los 32 megabytes disponibles, no estaban actualizadas, etcétera. Por
lo que se prefirió el enfoque planteado por el autor Roberto Cardona Soto2 de crear una
distribución mínima. También se hace uso de la guía de este autor para crear la distribución
dado que se basa en el mismo sistema incrustado Net4801. Se omiten algunos detalles ya
incluidos en este documento.
4.2.2
Configuración del sistema huésped
El sistema huésped consiste en una computadora PC, con Windows 2000 y Linux con la
distribución Debian Sid, operando con el kernel 2.4.27.
Para el presente trabajo se usó
exclusivamente Linux por los requerimientos que conlleva. En términos generales tiene puerto
serial, puertos USB, dos tarjetas de red y otros componentes usuales. Se omite el proceso de
instalación del sistema operativo Linux y del kernel en el sistema huésped por ser poco
importante, se supone conocimiento básico de parte del lector para esto y otros detalles
correspondientes a este sistema operativo3.
2
3
[21]
Consultar [19], [20], [21], [31], [32]
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
65
Se instalaron los paquetes NFS-USER-SERVER, TFTPD y DHCP3, se descargó el
bootloader SYSLINUX para el sistema incrustado y el paquete “minicom” para comunicarse
con la SBC por medio del puerto serial. Se crearon directorios para el sistema raíz del sistema
incrustado (referido como rootfs), un directorio para el servidor TFTP (referido como tftpboot)
y otros para compilar el kernel y los programas que se debían de instalar en el sistema
incrustado.
La configuración del servidor NFS para que la tarjeta del sistema incrustado pudiera
montar el directorio raíz que le correspondía en el archivo /etc/exports se realizó al incluir en
este archivo la siguiente línea:
/sbc/crustaceo/rootfs 10.0.0.100(rw,no_root_squash)
La configuración del servidor DHCP necesario para iniciar la SBC se hizo de tal forma
que se le asigna una dirección IP fija al adaptador Ethernet de la tarjeta del sistema incrustado,
también se configura en el archivo /etc/network/interfaces la tarjeta de red del sistema huésped
para que tenga también una dirección IP estática (10.0.0.1). El archivo de dhcpd3 se ubica en /
etc/dhcpd3/dhcpd.conf e incluye las siguientes líneas:
ddns-update-style none;
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
66
allow booting;
allow bootp;
option domain-name "domain.com";
option domain-name-servers ns1.domain.com, ns2.domain.com;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet 10.0.0.0 netmask 255.0.0.0 {}
host sbc1
{
hardware ethernet 00:00:24:c1:cc:4c;
fixed-address 10.0.0.100;
option subnet-mask 255.255.255.0;
option broadcast-address 10.0.0.255;
option router 10.0.0.1;
filename "pxelinux.0";
}
Se probó el servidor DHCP al conectar otra computadora y cambiando los parámetros
correspondientes para esto, el servidor DHCP asignó exitosamente una dirección IP aceptable.
Se editó el archivo de configuración /etc/inet.d de tal forma que el servidor tftp esté
disponible para abrir conexiones agregando la siguiente línea:
tftp dgram udp wait root
/usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /tftpboot
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
67
Para probar el funcionamiento se creó un archivo llamado test en /tftpboot y usando el
comando tftp 10.0.0.1 se descargó exitosamente.
El archivo de configuración default usada para el PXELINUX es el siguiente:
SERIAL 0 19200
DEFAULT vmlinuz-2.6.9 console=ttyS0,19200n81 root=/dev/nfs
nfsaddrs=10.0.0.100:10.0.0.1:10.0.0.1:255.255.255.0:soekris:eth0
nfsroot=10.0.0.1:/sbc/crustaceo/rootfs
panic=10
IPAPPEND 1
Este archivo reside en el servidor tftp dentro de la carpeta pxelinux.cfg, con otro archivo
llamado pxelinux.0 y un kernel. A la hora de iniciar la SBC, usando el comando boot f0 carga
el servidor tftp e inicia el kernel incluido, posteriormente lo que sucede es que se monta la raíz
del sistema por medio de la red usando el NFS. También se verificó que el NFS funcionara
correctamente.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
4.2.3
68
Sistema raíz de archivos de la SBC
En esta etapa se describe la creación del sistema raíz para el sistema incrustado. Se
crearon en la carpeta rootfs el sistema raíz compuesto principalmente de la siguiente estructura:
boot, bin, bin/grub, dev, dev/cciss, etc, lib, opt, proc, sbin, tmp, var, var/lib, var/lock, var/log,
var/run, var/tmp usr, usr/bin, usr/sbin, usr/lib, usr/local, usr/local/sbin, mnt y etc/init.d.
Se crearon todos los archivos especiales en /dev ejecutando /dev/MAKEDEV para cada
dispositivo, entre estos están std, ttyS0 (primer puerto serial), ttyS1 (segundo puerto serial),
hda, sda, hde y console (consola del sistema). También se ejecutó mknod para crear los
archivos especiales para el puerto USB, para el PPP, túneles virtuales/ethernet y terminales
virtuales. El archivo especial para operar el dispositivo GPRS/GSM por USB, la memoria
USB, el PPP y las terminales virtuales creados son:
mknod /dev/ttyACM0 c 166 0
mknod /dev/vc/0 c 4 0
mknod /dev/ppp c 108 0
mknod /dev/vc/1 c 4 1
mknod /dev/uba b 125 0
mknod /dev/vc/2 c 4 2
mknod /dev/uba1 b 125 1
mknod /dev/vc/3 c 4 3
mknod /dev/net/tap0 c 36 16
mknod /dev/net/tap2 c 36 18
mknod /dev/net/tap1 c 36 17
mknod /dev/net/tun c 10 200
mknod /dev/ptmx c 5 2
Se instaló el paquete busybox que contiene programas y utilidades necesarios para
realizar tareas típicas para operar en Linux. Busybox es un sólo archivo ejecutable y crea
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
69
enlaces de todos los comandos, es especialmente usado en sistemas incrustados por su tamaño y
habilidad de ser modular, instalando lo necesario. Se configura fácilmente invocándolo con el
comando make menuconfig, luego se compila estáticamente usando make y se instala como
usualmente se realiza con make install, se usa la bandera PREFIX para indicar el lugar donde se
encuentra la raíz del sistema de archivos.
Se instaló también el programa “microcom”, que es similar al “minicom” cuya utilidad
es ser un emulador terminal serial con soporte para ejecutar scripts, este es un programa útil
para manejar por medio del segundo puerto serial un acelerógrafo. Su tamaño es pequeño, sólo
ocupa 17k. No se instaló el “minicom” por no ser compatible con la distribución y la SBC,
además “microcom” tiene las funciones necesarias. Se tiene acceso también al editor de texto
“pico”.
Otra de las utilidades incluidas es “vtun”, sirve para crear túneles virtuales sobre redes
TCP/IP. Soporta túneles en Ethernet, IP, PPP y SLIP, puede ser usado para efectuar tareas de
red.
También es necesario tener un daemon PPP para proveer una forma de transmitir
datagramas por un enlace serial, como también tener una forma para que ambas máquinas en un
enlace negocien varias características opcionales del enlace. Usando PPP, un enlace serial
puede ser usado para transmitir datagramas IP permitiendo conexiones TCP/IP. Se usó el
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
70
tinylogin v1.4 para manejo del login, grupos y usuarios. La instalación de estos programas se
realizó usando la bandera PREFIX para indicar que no se instalen en el sistema huésped sino en
la raíz del sistema para la SBC.
Se debe colocar el archivo fstab en /etc para que se monten los sistemas de archivos
apropiadamente, como el sistema proc en /proc, también la raíz por medio de NFS sobre red, el
sistema especial devpts y una vez instalado Linux se especifica que monte la raíz de archivos;
incluye las siguientes líneas:
10.0.0.1:/sbc/crustaceo/rootfs / nfs nolock,intr,rw 0 0
proc
/proc proc defaults 0 0
/dev/pts /dev/pts devpts mode=0622
#/dev/hda1
0
/ ext3 defaults,errors=remount-ro
0
0
1
Se copiaron desde el sistema huésped a la carpeta rootfs los programas para la creación
del sistema de archivos en la memoria CompactFlash (fdisk, mke2fs y mkfs.ext3) y el
bootloader LILO en la sub-carpeta sbin.
Se usa el programa init del busybox para manejar los procesos, está diseñado para ser
ejecutado sólo por el kernel. El archivo inittab de configuración ubicado en la carpeta /etc
contiene las siguientes líneas:
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
71
::sysinit:/etc/init.d/rcS
::respawn:/sbin/getty 19200 ttyS0
::restart:/sbin/init
::shutdown:/bin/umount -a -r
Se especifica que en el inicio se ejecute el script rcS, luego se ejecute el programa getty
para iniciar una sesión de login en el primer puerto serial con una velocidad de 19200 bps. En
caso de que se termine el programa init este se reinicie. Finalmente cuando se apague el
sistema incrustado se desmonten los sistemas de archivos. El scripts rcS en /etc/init.d tiene lo
siguiente:
#! /bin/sh
mount -n -o remount,rw /
mount /proc
mount /dev/pts
/sbin/ifup eth0
/sbin/ifup lo
/usr/sbin/telnetd
mkdir -p /var/tmp
mkdir -p /var/log
mkdir -p /var/run
mkdir -p /var/spool/cron/crontabs
hostname -F /etc/hostname
/sbin/syslogd -O /var/log/messages
/sbin/klogd -c 3
/usr/sbin/crond -l8 >>/var/log/cron 2>&1
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
72
Lo que se indica es que se remonte el sistema de archivos para lectura y escritura así
como también el sistema proc y pts. La cuarta línea configura el adaptador de red eth0, luego
se crean unos cuantos directorios en el sistema de archivos temporal y se inician unos cuantos
daemons.
4.2.4
Configuración del kernel
La configuración del kernel es un ejercicio que requiere un entendimiento de las
funciones y componentes de hardware, así como también las tareas que va a ejecutar el sistema
donde se instale. Las opciones que se incluyen en este son sólo las necesarias para evitar que el
kernel sea lento, grande, ineficiente y no tenga incluso complicaciones de hardware.
El kernel disponible y que se escogió para el prototipo es el 2.6.9, se puede descargar de
Internet4 el código fuente. Este se descomprimió en una carpeta para tal propósito llamada
kernel. Primero se requiere aplicarle un parche que incluye arreglos para la operación del
sistema incrustado Net4801. Son tres los arreglos que incluye el parche; el primero para poder
seleccionar en la sección “Processor type and features” el procesador MediaGX/Geodo, el
segundo para que el escaneo de bus PCI funcione y el tercero incluye soporte para el watchdog
4
Dirección: www.kernel.org
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
73
de la Net4801. Para aplicarlo se ejecutó el siguiente comando en el directorio raíz donde se
descomprimió el kernel:
# patch -p1 < net4801.kernel.patch_2.6.9
# patch -p1 < scx200_wdt.patch
Se ejecuta make xconfig para seleccionar las opciones que debe contener el kernel.
Específicamente, para el hardware de la SBC se debe incluir también, aparte de los
mencionados anteriormente, el controlador IDE del procesador SCx200 y soporte para el
adaptador de red PCI 100Mbps “National Semiconductor DP8381x.
Con respecto al resto de opciones se puede resumir las más importantes en los siguientes
puntos:
•
En “General Setup/Configure standard kernel features” se deshabilita la opción de cargar los
símbolos para debug, se deshabilita la opción de “Use full shmem filesystem” (para
pequeños sistemas sin “swap”) y se habilita la opción de optimizar por espacio. Estas
funciones son especiales para los sistemas incrustados para reducir el tamaño del kernel. Se
deshabilitan varias opciones para debug en todo el kernel para tal propósito.
Diciembre del 2004
IE-0502
•
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
74
Soporte PPP y SLIP en “Device Drivers/Networking Device Support” como parte del
método de enlace.
•
En “Device Drivers/Networking Options/TCP/IP Networking” las opciones de “IP: kernel
level autoconfiguration”, “IP: tunneling” y “IP: GRE tunnels over IP”. En “File
Systems/Network File Systems” habilitar “NFS File System Support” y “Root file system on
NFS” para montar la raíz del sistema sobre red y soporte para Internet.
•
Soporte para crear túneles virtuales (TUN) y de ethernet (TAP).
Se habilita “Device
drivers/Networking Options/Universal TUN/TAP device driver support”.
•
Soporte para los puertos seriales. Se habilita en “Device drivers/Input devices/Serial port
line discipline” y en “Character Devices/Serial Drivers/8250/16550 and compatible serial
support/Console on 8250/16550 and compatible serial port”.
•
Soporte para el dispositivo GPRS/GSM. En “Device Drivers/USB Support/Support for hostside USB” se habilitan las opciones de “EHCI HCD (USB 2.0) support”, “OHCI HCD
support” y “USB Modem (CDC ACM) support”. Aquí también se incluyó la opción para
soportar las llaves de almacenamiento USB, para traspasar archivos en las visitas de
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
75
mantenimiento a los acelerógrafos en caso de necesitarlo, habilitando “USB Mass Storage
support”.
•
Soporte para el sistema de archivos EXT3. Se habilita en “File Systems” la opción de “Ext3
journalling file system support”.
También en esta sección, en el apartado de “Pseudo
Filesystems” se habilita el soporte para los sistemas de archivos /proc, sysfs, /dev y /dev/pts;
en especial este último para que el servidor de telnet funcione correctamente.
Se compila el kernel ejecutando make bzImage, make modules y make modules_install
con la bandera INSTALL_MOD_PATH, para instalar los módulos en una carpeta temporal y
no en el sistema huésped. Luego se copió el archivo arch/i386/boot/bzImage y el archivo
System.map a la carpeta boot y los módulos a la carpeta lib del sistema raíz para la SBC.
4.2.5
Primer arranque
Figura 4.2 SBC lista para primer arranque
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
76
Se preparó todo para realizar el primer arranque, se instaló la memoria CompactFlash,
se conectó un cable serial “null modem” para operar la consola y se conectó el cable de red
UTP en configuración crossover. Como se indicó anteriormente, se verificó en el sistema
huésped que todo estuviera configurado correctamente y operando.
Se procedió a realizar el inicio del sistema desde red, sin embargo la SBC no respondía
para iniciar el procedimiento, la línea de comandos correspondiente es la siguiente:
comBIOS ver. 1.26
20040721
Copyright (C) 2000-2004 Soekris Engineering.
net4801
0128 Mbyte Memory
CPU Geode 266 Mhz
Pri Mas
LBA 490-4-32
Slot
SanDisk SDCFB-32
Vend Dev
ClassRev Cmd
Stat CL LT HT
Base1
31 Mbyte
Base2
Int
------------------------------------------------------------------0:00:0 1078 0001 06000000 0107 0280 00 00 00 00000000 00000000
0:06:0 100B 0020 02000000 0107 0290 00 3F 00 0000E101 A0000000 10
0:07:0 100B 0020 02000000 0107 0290 00 3F 00 0000E201 A0001000 10
0:08:0 100B 0020 02000000 0107 0290 00 3F 00 0000E301 A0002000 10
0:18:2 100B 0502 01018001 0005 0280 00 00 00 00000000 00000000
0:19:0 0E11 A0F8 0C031008 0117 0280 08 38 00 A0003000 00000000 11
2 Seconds to automatic boot.
comBIOS Monitor.
Press Ctrl-P for entering Monitor.
Press ? for help.
> boot f0
No Boot device available, enter monitor.
comBIOS Monitor.
Press ? for help.
> show pxeboot
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
77
= Enabled
>
Se realizaron varios intentos sin tener éxito a pesar de estar habilitada la opción de
arranque pxeboot para la SBC, se revisó extensamente toda la documentación y se actualizó el
BIOS que opera en la SBC. Se usaron herramientas como “tcpdump” para verificar que la SBC
estuviera intentando iniciar sobre red, sin embargo no se detectó ningún paquete o llamada
procedente de la SBC hacia el dispositivo de red del sistema huésped.
Por lo tanto se optó por el segundo método recomendado por el fabricante.
Este
consiste en usar un lector de memorias CompactFlash para escribir directamente en la memoria.
4.2.6
Reconfiguración del sistema incrustado y huésped
Este procedimiento requería reconfigurar algunos aspectos de ambos sistemas. En el
sistema huésped se habilitó en el kernel el soporte para el lector de memorias. Se instaló el
lector para operar la memoria CompactFlash, este es visto por el sistema operativo como un
disco duro en el archivo especial /dev/sda1.
Se usó la herramienta “cfdisk” para borrar la partición existente y crear una nueva
partición, se invocó como cfdisk /dev/sda1. Se indicó que la partición fuera del tipo 83 o
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
78
Linux. Luego se formateó el sistema de archivos con el tipo EXT3 ejecutando mkfs.ext3 /
dev/sda1 y se escribió la nueva tabla de particiones fijando la bandera de boot en la misma.
Se montó en el sistema huésped la memoria usando el comando mount -t ext3 /
dev/sda1 /mnt/cf.
Ya montado, se copió la raíz de archivos que ya se tenía dispuesta
anteriormente a la memoria incluyendo el nuevo kernel. Inicialmente, se tenía en mente usar el
bootloader LILO. La configuración es la siguiente:
lba32
boot=/dev/hda
root=/dev/hda1
prompt
install=/boot/boot.b
map=/boot/map
delay=20
vga=normal
serial=0,19200n8
append="video=vga16:off console=ttyS0,19200n81"
default=MarcOS_Linux
image=/boot/vmlinuz
label=MarcOS_Linux
read-only
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
79
Sin embargo, con ejecutar el comando “chroot /mnt/sda1 lilo -C /etc/lilo.conf” o el
comando “lilo -v 3 -r /mnt/cf -C etc/lilo.conf” no se lograba iniciar el sistema incrustado. Se
procedió a usar otro bootloader llamado Grub que se tenía instalado en el sistema huésped.
Se copiaron del directorio fuente de Grub los archivos stage1, stage2 grub en /
mnt/cf/boot/grub y se creó el archivo de configuración menu.lst. Se ejecutó el bootloader
usando el comando grub y se usaron los siguientes comandos:
>root (hd2,0)
>setup (hd2)
>quit
Para el Grub el dispositivo 0 corresponde al dispositivo a en Linux, 1 a b y 2 a c; por lo
que el dispositivo sda1 es visto como hd2,0. La primer línea le indica en cual dispositivo se
esta operando, el segundo prepara la configuración indicada en menu.lst y el tercero sirve para
salir del programa. El archivo menu.lst contiene las siguientes líneas:
serial --unit=0 --speed=19200
terminal serial
root (hd2,0)
timeout 3
default 0
title MarcOS_Linux
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
80
kernel /boot/vmlinuz boot=/dev/hda root=/dev/hda1 rw init=/bin/init
video=vga16:off console=ttyS0,19200n81
Lo más importante aquí son las primeras dos líneas y la correspondiente a kernel. Las
dos primeras indican que se va usar el puerto serial COM1 a una velocidad de 19200bps como
consola, la línea kernel indica cual será el kernel que se bootea así como los parámetros que se
le pasaran al kernel desde el bootloader.
Finalmente, se desmontó el lector con umount /mnt/cf. Todo se encontraba listo para
reiniciar la SBC.
4.2.7
Segundo arranque
Se reinició la SBC con la nueva configuración. En ese momento arrancó exitosamente,
el historial del inicio se incluye en los anexos. Inicialmente la distribución, incluyendo los
programas
mencionados
anteriormente
y
las
librerías
correspondientes,
aproximadamente 10 MB, esto se comprobó usando el comando df.
ocupan
El espacio libre es
aproximadamente 18.5 MB. En el historial se puede observar los datos así como también el
llamado de los programas “vtun” y “microcom”.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
81
Figura 4.3 Net4801 operando dispositivo GPRS/GSM
A modo de prueba se ejecutaron dos instrucciones para probar el programa “microcom”
y el dispositivo GPRS:
/ # microcom -D/dev/ttyACM0
AT
OK
AT+CGMI
+CGMI: "Motorola CE, Copyright 2000"
OK
De forma similar se pueden ejecutar las instrucciones para manejar los acelerógrafos por
medio del segundo puerto serial (ttyS1) disponible internamente en la Net4801, en los
parámetros para iniciar el “microcom” se indica el puerto ttyS1 en lugar del ttyACM0. Es muy
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
82
importante indicar el puerto correcto, de lo contrario microcom busca el puerto y ocurre un
conflicto con la consola, requiriendo reiniciar el sistema. Además se tiene que revisar el
manual del sistema incrustado incluido en este documento como anexo para encontrar la
ubicación física del puerto (JP4, COM2).
Para iniciar una sesión de Internet por medio del dispositivo GPRS se usaron los scripts
“gprsconectar”, “gprsdesconectar”, “gprs-connect-chat” y “gprs-disconnect-chat”. El contenido
de cada uno de estos archivos se incluye en los anexos. Cabe destacar que para poderlos correr
era necesario cambiar los permisos de ejecución usando el comando chmod. La línea de la
consola al probar estos scripts es:
/etc/ppp # gprsconectar
Presione Ctrl-C en cualquier momento si la conexión falla
Enviando los comando iniciales al módem...
rAT
OK
ATH
OK
ATE1
OK
AT+CGDCONT=1,IP,icecelular
OK
Esperando estar conectados...
ATD*99***1#
CONNECT
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
83
Conectado!.
Si las próximas negociaciones fallan,
pruebe reseateando el teléfono
Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/ttyACM0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x5a99315>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x5a99315>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xf785d02> <pcomp>
<a]
sent [LCP ConfRej id=0x1 <auth pap> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0xf785d19>]
sent [LCP ConfAck id=0x2 <asyncmap 0x0> <magic 0xf785d19>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 10.40.3.21>]
sent [IPCP ConfReq id=0x2 <addr 10.40.3.21>]
rcvd [IPCP ConfAck id=0x2 <addr 10.40.3.21>]
rcvd [IPCP ConfReq id=0x3 <addr 192.168.100.101>]
sent [IPCP ConfAck id=0x3 <addr 192.168.100.101>]
local
IP address 10.40.3.21
remote IP address 192.168.100.101
Terminating on signal 2.
sent [LCP TermReq id=0x2 "User request"]
rcvd [LCP TermAck id=0x2 "User request"]
Connection terminated.
Connect time 0.5 minutes.
Sent 40 bytes, received 30 bytes.
Enviando orden de fin al modem...
La conexión se ha terminado
Serial link disconnected.
/etc/ppp #
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
4.2.8
84
Configuración de túnel para la VPN
Es posible usando el VTUN crear un túnel a través de Internet para crear una red
privada entre un servidor con IP estática pública y las estaciones con los sistemas incrustados
operando como clientes. Es necesario porque la red GPRS es una red privada que asigna IPs
dinámicas para accesar a Internet. Esto permite disponer de una gran cantidad de servicios y
funciones, por ejemplo; el servidor puede montar por NFS la raíz del sistema de archivos de los
clientes o iniciar una sesión en los mismos, con lo que se tendría acceso a manejar directamente
el sistema incrustado.
Las configuraciones del cliente y del servidor son distintas y se
especifican en el archivo /etc/vtund.conf. Para el servidor se tiene lo siguiente:
options {
type stand;
# stand(default), inet (usado sólo en el servidor)
port 50000;
# Servidor acepta llamadas en este puerto.
syslog daemon;
# Syslog facility
# Ubicación de varios programas
ppp
/usr/sbin/pppd;
ifconfig
/sbin/ifconfig;
route
/sbin/route;
firewall
/sbin/iptables;
ip
/sbin/ip;
}
# Default session options
default {
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
type tun;
#tun, ether, tty(default), pipe (Usado en el servidor)
proto tcp;
#udp, tcp(default) (Usado sólo en el servidor)
85
device tun0;
#
compress no;
# no, yes, zlib:(1-9), lzo:(1-9);
encrypt no;
#yes, no (Usado sólo en el servidor)
stat yes;
#yes, no: check /var/log/vtund/SessionName_X
speed 0;
#Por default la maxima velocidad
keepalive yes;
#Usado para mantener viva la conexión
}
# TUN session 'lissbc'.
lissbc {
passwd
type
villalta;
# Password
tun;
# IP tunnel
proto tcp;
compress
# UDP protocol
encrypt
no;
no;
# LZO compression level 9
# Encryption
keepalive yes;
# Keep connection alive
stat yes;
#yes, no
up {
# Connection is Up
# 10.3.0.1 - local, 10.3.0.2 - remote
ifconfig "%% 192.168.254.201 pointopoint 192.168.254.200 mtu 1450";
route
"add
-net
192.168.0.0
netmask
255.255.255.0
gw
netmask
255.255.255.0
gw
192.168.254.200";
};
down {
# Connection is down
# 10.3.0.1 - local, 10.3.0.2 - remote
ifconfig "%% down";
route
"del
-net
192.168.0.0
192.168.254.200";
};
}
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
86
Para el cliente (sistema incrustado) la configuración correspondiente es:
options {
port 50000;
syslog 7;
# Listen on this port.
# Syslog facility
# Path to various programs
ppp
/usr/sbin/pppd;
ifconfig
/sbin/ifconfig;
route
/sbin/route;
firewall
/sbin/tables;
ip
/sbin/ip;
}
# Default session options
default {
type tun;
#tun, ether, tty, pipe
proto tcp;
#udp, tcp
compress no;
encrypt no;
# no, yes, zlib, lzo
#yes, no
stat yes;
#yes, no
speed 0;
# By default maximum speed, NO shaping
}
# TUN example. Session 'lissbc'.
lissbc {
passwd
type
villalta;
tun;
# IP tunnel
proto udp;
compress
encrypt
# Password
# UDP protocol
no;
no;
# LZO compression level 9/No
# Encryption
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
keepalive yes;
#
87
# Keep connection alive
persist yes;
up {
# Connection is Up
ifconfig "%% 192.168.254.200 pointopoint 192.168.254.201 mtu 1450";
route
"add
-net
192.168.2.0
netmask
255.255.255.0
gw
-net
192.168.2.0
netmask
255.255.255.0
gw
192.168.254.201";
};
down {
# Connection is down
ifconfig "%% down";
route
"del
192.168.254.201";
};
}
Esencialmente lo que se logra hacer con este túnel es que el servidor tenga una IP
correspondiente a
192.168.254.201 y que el cliente tenga una IP correspondiente a
192.168.254.200, estas direcciones IP son arbitrarias y se asignan de tal forma que no tengan
conflictos con otras redes. Al establecerse la conexión se ejecutan las instrucciones en la
sección “up”, aquí se asignan las IP, cuando se termina la conexión se ejecutan las instrucciones
en la sección “down” borrando el enlace IP. En el archivo /etc/vtund-start.conf se especifica la
función de servidor o cliente. En el caso del servidor está la opción de configurar el puerto para
escuchar las llamadas y en el caso del clientes está la opción de especificar la ubicación del
servidor. Es muy importante usar un puerto que se encuentre libre para realizar conexiones
tanto en la computadora que desempeña la función de servidor como en la propia red donde
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
88
esta se encuentra, porque es practica usual tener cerrados varias puertos para evitar ataques a la
red o al sistema. En la configuración del servidor también se puede incluir la cantidad de
túneles que se pueden crear, esto en caso de tener varios acelerógrafos conectados al servidor al
mismo tiempo.
Se inicia el servidor con el comando “vtund -s -f /etc/vtund.conf” y en el cliente con
“vtund -f /etc/vtund.conf lissbc hostname-server(IP)”.
También es posible iniciar estos
servicios usando el init. Se probo exitosamente al crear un túnel ethernet, donde el sistema
huésped pertenece a la red ADSL del ICE, con la misma configuración.
4.2.9
Comunicación con acelerógrafo
Con el planteamiento anterior, una vez iniciado el túnel es posible que desde el servidor
se inicie una sesión de login, para esto es necesario configurar e instalar algún programa que
permita el acceso a la SBC. Por defecto el paquete busybox tiene tanto el cliente como el
servidor de telnet. Sin embargo, si es necesario mayor seguridad se puede instalar un servidor
de “ssh” en el sistema incrustado. Esto se recomienda y se instaló el servidor “ssh” conocido
como Dropbear cuyo tamaño no supera los 200kb. El OpenSSH no es compatible con la
distribución, aunque el “vtun” puede encriptar los datos.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
89
Es importante que se debe realizar la conexión usando las direcciones IP asignadas por
el túnel. Desde aquí se puede ejecutar todas las herramientas que se incluyen en la distribución.
Al ser un prototipo no se cuenta con un programa que facilite al usuario realizar las tareas
necesarias para comunicarse con los acelerógrafos, por lo que iniciada la sesión el usuario debe
ser capaz de abrir la sesión del “microcom” correctamente, operar el acelerógrafo con las
instrucciones correctas, saber usar el comando rx del busybox para recibir los archivos desde el
acelerógrafo y conocer la forma de enviar los archivos hacia algún servidor usando comandos
como ftpput. También de esta forma se puede cambiar los parámetros de operación de los
acelerógrafos.
Como parte del prototipo se puede implementar alguna automatización básica para que
el mismo sistema operativo se conecte a un servidor y envíe los archivos.
En este punto se aprovechó que el kernel se había compilado con la opción de servidor
NFS, por lo que se instalaron los paquetes PORTMAP y NFS-KERNEL-SERVER en el sistema
incrustado. La configuración de estos servidores es para que operen con las direcciones IP
asignadas por el túnel, fue necesario cambiar los scripts de inicialización para que fueran
compatibles con la distribución. Con esto el servidor puede montar la raíz de archivos del
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
sistema
incrustado
usando
la
instrucción
“mount
-t
nfs
90
192.168.254.200:/
/
carpeta/ubicada/en/servidor”, facilitando el traspaso de archivos entre ambas terminales,
actualizar el sistema incrustado y agregar nuevas funciones.
Para abrir la sesión con el acelerógrafo se introduce el comando “iniciarsesion”, debido
a que el acelerógrafo por defecto no envía la señal de terminal, esta instrucción se encarga de
abrir el puerto serial indicado e inicia el protocolo para abrir la sesión.
Cada vez que el sistema operativo inicia, los servidores de telnet y NFS están
configurados para iniciar con este. Se utiliza la herramienta Cron, sirve para programar la
ejecución de tareas en un momento dado en el tiempo, incluida en el paquete Busybox para
programar un horario de operación del sistema remoto. Este consiste en abrir, mantener y
cerrar la sesión GPRS y el túnel con el servidor durante horas de oficina de lunes a viernes.
Con el documento se incluye un CD-ROM con la raíz de archivos para el sistema
incrustado, la configuración del kernel, la configuración del busybox y los paquetes usados en
la distribución. En /docs se incluye información pertinente a la operación del sistema en
general.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
91
CAPÍTULO 5: Otras alternativas
Parte de la investigación fue la evaluación de varias alternativas para solucionar el modo
de comunicación necesario que se debía de establecer entre las estaciones remotas con el L.I.S.
A continuación se presentan distintas opciones que se tomaron en cuenta, desde las más
hipotéticas hasta la recomendada a desarrollar.
Cabe destacar los factores tomados en cuenta para tomar la decisión de cual alternativa
recomendar. El presupuesto disponible por parte del L.I.S. tanto para el desarrollo del prototipo
como también el costo económico del producto final es el primer parámetro a considerar, el
cual es mínimo y de varios procesos administrativos burocráticos. Elementos limitantes como
el
tiempo necesario para el diseño e implementación y las herramientas o componentes
requeridos, es importante no sobre-dimensionar las expectativas o los objetivos del alcance de
un proyecto de bachillerato. Aspectos de la disponibilidad de las estaciones remotas como su
acceso terrestre o los recursos básicos como la disponibilidad de pares telefónicos, también se
requiere que estos equipos tengan la alternativa de ser movidos de su locación dado que es
frecuente su reubicación por su interés científico dentro de una misma región. La facilidad de
instalación, mantenimiento, soporte técnico y manejo por parte del usuario final, por lo que
debe ser sumamente versátil. Finalmente el interés didáctico del valor educativo que puede
presentar para el estudiante.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
92
5.1 Módems PCMCIA y EIA232
El primer paso fue contactar a la compañía Kinemetrics para obtener información de las
soluciones que ellos proveen. Como se mencionó anteriormente, algunos de los sismógrafos de
interés tienen la opción de incorporar un módem, sin embargo los módems disponibles en el
mercado no eran de utilidad dado que el fabricante tiene especificaciones únicas de
compatibilidad, siendo los únicos proveedores de este tipo de alternativa. Por lo tanto se toma
como parámetro de referencia la alternativa que presentan cuyo costo asciende a los $655.00.
Tampoco ellos tienen disponible el material técnico de como desarrollar o como se realiza tal
comunicación.
Esta alternativa queda descartada por el costo económico asociado fuera del alcance de
los recursos disponibles por el L.I.S., también que no es viable una solución por módem dadas
las condiciones donde se encuentran las estaciones remotas que no disponen de acceso al
sistema telefónico local y la necesidad de que estos sean sistemas móviles.
Además, es
importante disponer de un sistema compatible y lo suficientemente amplio como para operar
cualquier tipo de sismógrafo en lo posible.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
93
Lo anterior también es aplicable para cualquier tipo de módem que opere con la opción
de comunicación por medio del puerto serial RS-232 y sea necesario una línea telefónica
disponible permanente. Lo que deja como única opción realizar la comunicación con alguna
alternativa tipo “wireless” o inalámbrica de largo alcance.
Además los sismógrafos no tienen la capacidad de manejar por medio del puerto RS232 que tienen incorporado un módem de cualquier tipo, dado que no se puede ejecutar en estos
ningún tipo de programa para tal propósito ni tampoco existen tales comandos. Si fuera del
caso, sería necesario tener alguna interfaz bidireccional en medio de ambos equipos como se ve
en la figura 5.1 para optimizar la comunicación y poder usar las distintas funciones.
Interfaz
Figura 5.1 Esquema de conexión con acelerógrafos
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
94
5.2 Soluciones de conectividad locales
Bajo esta situación se hizo un estudio de las alternativas presentes en el mercado local
de Costa Rica.
5.2.1
Internet vía satelital
RACSA ofrece un servicio de acceso a Internet que, vía antenas satelitales, permite el
acceso a la red mundial Internet desde cualquier punto del territorio nacional, incluso desde las
zonas geográficas que por sus características no permiten otro tipo de conexión, como pudiera
ser vía teléfono, fibra óptica, o cable módem.
El servicio es ofrecido a través de estaciones remotas (antenas) VSAT de 1.8 metros de
diámetro, que operan bajo la modalidad de acceso TDM/TDMA en la banda Ku, con un ancho
de banda compartido y una disponibilidad satelital mínima del 99.5%.
Es un servicio de tipo asimétrico con un rendimiento garantizado a nivel de recepción
de 10 kbytes/s por antena y que está diseñado para cualquier aplicación de Internet. Como parte
del servicio asigna una dirección IP privada por cada VSAT instalada.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
95
El principal beneficio para el cliente es contar con una alternativa de acceso a Internet
donde no existe la posibilidad de acceder a otras soluciones tales como Internet vía telefónica,
Internet Banda Ancha, Cable MODEM, ADSL entre otras.
Figura 5.2 Topología del servicio de Internet Satelital
Fuente: [11], página de Internet.
El costo de la instalación es de $300, con un depósito de $350 y una mensualidad de
$400.
Dados los requisitos así como también el aspecto económico esta opción queda
descartada. Además esta sobre-dimensionada dado que el tamaño promedio de los archivos de
eventos de datos es de aproximadamente 250 kbytes lo que no requiere de una alta velocidad,
además de que se requiere una vez más una interfaz para los acelerógrafos.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
5.2.2
96
Red RACSARID
También existe el RACSARID que está diseñada especialmente para la interconexión de
zonas remotas de difícil acceso o para aquellos lugares donde no es posible establecer un enlace
mediante planta externa, red alambrada de cobre o red de fibra óptica.
Por ser una red digital, se garantiza al cliente enlaces con un alto nivel de calidad.
Además, por las frecuencias de operación, los enlaces no son afectados por la lluvia o la niebla.
El servicio se ofrece en una amplia gama de velocidades, sin importar la distancia a la que se
encuentre el punto remoto, permitiendo a los usuarios el transporte de múltiples protocolos de
comunicación. Los beneficios son:
· Rapidez en la instalación de enlaces digitales en zonas de difícil acceso, ya que la
infraestructura requerida es sumamente sencilla.
·
Agilidad en el desarrollo de una red privada, en vista de que se trata de un único punto de
contacto.
·
Disminución del presupuesto de las comunicaciones.
·
Adaptabilidad de acuerdo con la aplicación del cliente.
·
Respaldo, ya que el sistema cuenta con una plataforma redundante.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
97
·
Ingeniería de alto nivel tanto en el diseño como en el mantenimiento de los enlaces.
·
Alta disponibilidad del enlace porque éste es digital.
·
Esta red de RACSA ofrece también servicios inalámbricos, los cuales se instalan a través
de una estación y una antena para la transmisión de información. Debido a la cobertura que
ofrece el servicio en el territorio nacional, es posible ofrecer canales digitales "punto a
punto" con conexión permanente en zonas de difícil acceso a través de redes terrestres
convencionales.
La red utiliza acceso múltiple por división en el tiempo (TDMA) para distribuir
("multiplexar") los enlaces que se establecen mediante microondas en la banda de frecuencias
de 1.4 a 2.7 GHz. La transmisión en esta banda garantiza un enlace que no se degrada por
factores climáticos.
Esta red cuenta con una estructura redundante que garantiza al cliente amplio respaldo
en sus enlaces, pues en caso de que una conexión falle, puede establecerse el enlace
nuevamente a través de otro puerto. Tiene una cobertura de aproximadamente un 85% del
territorio nacional.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
98
Las bandas de frecuencia que utiliza el enlace que se da al cliente son fijas. Esto
beneficia al usuario al no existir interferencias por frecuencias compartidas.
La conexión al nodo de acceso se hace por medio de líneas dedicadas. La longitud de
esta línea define la velocidad máxima de transmisión permitida en el enlace; por ejemplo, para
velocidad de 64 kbps se requiere que la línea no sea mayor de 4.5 kilómetros.
La cobertura de este servicio de RACSA se extiende a todo el territorio nacional, para
ello han sido instaladas repetidoras tanto en zona pacífica como en la región atlántica de nuestro
país, en las siguientes localidades; Sistema Pacífico: Vista al Mar, Santa Rita, Puntarenas,
Gallo, Santa Elena, Abra. Sistema Atlántico: Irazú, Lomas de Sierpe, Buena Vista, Adams,
Garrón, Uatsí.
Cañas Dulces
Santa Elena
Lomas de Sierpe
Gallo
Irazú
Vista almar
Puntarenas
Abra
RACSA
Garrón
Santa Rita
Uats í
Sistema Pacífico
Sistema Atlántic o
Buena Vista
Repetidor Futuro
Adams
Figura 5.3 Topología del servicio de RACSARID
Fuente: [12].
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
99
Antes de instalar la antena y la microestación se debe realizar un estudio de "línea de
vista" entre la oficina del cliente y el repetidor más cercano. Éste consiste en verificar que se
puede establecer un enlace eficiente por microonda, sin pérdidas por obstáculos (árboles,
cerros, etc.). Con dicha base se define el tamaño y las características de la torre que se instalará
en la oficina del cliente. El estudio no tiene costo adicional y es realizado por personal de
RACSA. Una vez cumplido lo anterior, se requiere que el cliente instale una torre o mástil,
según indique el estudio de campo.
El costo de la instalación es de $1000, con un deposito de $850 y una mensualidad de
$850 para una velocidad de conexión permanente de 9.6kbps; para velocidades mayores el
costo se incrementa.
A pesar de ser una solución de conectividad permanente con una
infraestructura ya existente, el valor asociado a la velocidad lo hace poco atractivo y fuera del
alcance económico.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
100
5.3 Transmisión en FM
5.3.1.
Conceptos básicos
Figura 5.4 La Frecuencia Modulada
Fuente: [22], página 6.
En la FM, la frecuencia de la onda portadora se varía dentro de un rango establecido a
un ritmo equivalente a la frecuencia de una señal.
La información transportada por una onda modulada se devuelve a su forma original
mediante el proceso inverso, denominado demodulación o detección. Las emisiones de ondas
de radio a frecuencias bajas y medias van moduladas en amplitud. Para frecuencias más altas se
utilizan tanto la AM como la FM.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
101
La transmisión en FM es un sistema de transmisión de radio en el que la onda portadora
se modula de forma que su frecuencia varíe según la señal de audio transmitida.
La frecuencia modulada posee varias ventajas sobre el sistema de modulación de
amplitud (AM) utilizado alternativamente en radiodifusión. La más importante es que al
sistema FM apenas le afectan las interferencias y descargas estáticas. Algunas perturbaciones
eléctricas, como las originadas por tormentas o sistemas de encendido de los automóviles,
producen señales de radio de amplitud modulada que se captan como ruido en los receptores
AM. Un equipo de FM bien diseñado no es sensible a tales perturbaciones cuando se sintoniza
una señal FM de suficiente potencia. Además, la relación señal-ruido en los sistemas FM es
mucho mayor que en los AM. Por último, las emisoras de FM pueden trabajar en bandas de
frecuencias muy altas, en las que las interferencias en AM son importantes. El alcance en estas
bandas está limitado para que pueda haber emisoras de la misma frecuencia situadas a unos
cientos de kilómetros sin que se interfieran entre ellas.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
102
Figura 5.5 Espectro electromagnético
Fuente: [24], página 2.
Las ondas electromagnéticas cubren un amplio rango de frecuencias y de tamaños de
onda, figura 5.5. La clasificación se basa principalmente en la fuente de radiación. Los
tamaños de onda van desde los miles de kilómetros hasta 0.1 mm. El rango de frecuencia va
desde los pocos hertz hasta los 3 Thz. Las ondas que tienen tamaños o frecuencias mas altas
que las ondas de radio se clasifican en infrarrojas, luz visible, ultravioleta, rayos X y rayos
gamma.
Tabla 5.1 Rangos de las ondas de radio
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
Nombre de Rango de Frecuencia y Abreviatura (inglés)
103
Frecuencias
Very Low Frecuency (VLF)
3-30 kHz
Low frequency (LF)
30-300 kHz
Medium frequency (MF)
300-3,000 kHz
High frequency (HF)
3-30 MHz
Very high frequency (VHF)
30-300 MHz
Ultrahigh frequency (UHF)
300-3,000 MHz
Superhigh frequency (SHF)
3-30 GHz
Extremely high frequency (EHF)
30-300 GHz
Tabla 5.2 Bandas de frecuencias de microondas
Banda
Frecuencia
L
1-2 GHz
S
2-4 GHz
C
4-8 GHz
X
8-12 GHz
Ku
12-18 GHz
K
18-26 GHz
Ka
26-40 GHz
El espectro de las ondas de radio se divide en rangos con un ancho de una década, como
se indica en la figura 5.5 y en la tabla 5.1. Las microondas están subdivididas en bandas de
acuerdo a la tabla 5.2.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
5.3.2.
104
Diseño
Es posible diseñar un sistema que sirva de interfaz modulando las señales en frecuencia.
Para esto se debe tomar en cuenta que debe consistir en un diseño de bajo costo y que sea
compacto, dado que por la ubicación de las estaciones de los acelerógrafos no se puede instalar
por ejemplo una antena de grandes dimensiones y que no sea portátil.
Bajo estas condiciones se puede realizar un diseño usando un circuito integrado de
Radiometrix, fabricante ubicado en Inglaterra especializado en el diseño de productos de radio
con bajo consumo de potencia.
El integrado en específico es el BiM1 que es un receptor-transmisor que opera a una
frecuencia típica de 151.300MHz, sin embargo puede operar en el rango de 120MHz a
180MHz. Este es de bajo consumo, menos de 80mA con una alimentación de 3.8V, capaz de
usarse para transmisiones de hasta 10 km con velocidad máxima de 10kbps. Lo importante y
útil es que ya está integrado el soporte para transmisiones de datos digitales de forma serial. En
la figura 5.6 se muestra su diagrama de bloques.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
105
Figura 5.6 Diagrama de bloques del BiM1
Fuente: [13], página 2.
Este contiene el circuito correspondiente al transmisor BiM1T y al receptor BiM1R
cuyas entradas y salidas están conectadas a una sola terminal RF (radio-frecuencia) por medio
de un switch RF. Estos se pueden adquirir por separado también.
Funcionalmente la sección del transmisor consiste en un modulador de frecuencia
VCXO (conocido por sus siglas en inglés como Voltage Controlled Crystal Oscilator) que se
conecta a un multiplicador de frecuencia con dos etapas de amplificación y de filtrado RF. La
etapa final de amplificación se predetermina por el fabricante para operar en la banda con la
potencia apropiada. La operación es controlada por una línea de selección Tx, la transmisión se
alcanza completamente en 5ms cuando esta línea se mantiene en bajo.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
106
La sección del receptor es un receptor superhet con una IF a 21.4MHz. Esta última es la
frecuencia intermedia que es la diferencia entre la frecuencia de la señal recibida y la del
oscilador local del sintonizador. Con este sistema se obtiene una estabilidad y una selectividad
elevadas. El receptor es controlado por una línea Rx de selección que se enciende típicamente
en menos de 2ms cuando esta línea se pone en bajo. Se tiene una señal indicadora de potencia
RSSI (conocido en sus siglas en inglés como Received Signal Strength Indicator) con un rango
de 60dB. La asignación de pines se muestra en la figura 5.7.
Figura 5.7 Asignación de pines del BiM1
Fuente: [13], página 4.
El fabricante predetermina la desviación en FM para una entrada a TXD de 3V de
amplitud, 0V corresponden al 0 lógico y 3V a un 1 lógico. Si la amplitud es mayor a 3V se
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
107
puede usar una resistencia en serie para limitar la señal modulada de voltaje a los 3V y usar un
nivelador de voltajes como el circuito integrado MAX232 para transmisiones seriales.
Es posible transmitir datos seriales RS232 directamente a velocidades de 600 a
19200bps entre dos BiM1, lo que requiere reajustar las velocidades de las terminales si fuese
necesario. En la figura 5.8 se tiene el esquemático para una terminal.
Figura 5.8 Esquemático para el BiM1
Fuente: [14].
Es necesario el uso de una computadora o de un sistema basado en un microcontrolador
por ejemplo, para controlar el envío y recepción de datos porque se tienen que optimizar para el
BiM1. Se deben de enviar en paquetes especiales, la información debe ser precedida por un
preámbulo mayor a 5ms (de un byte 55h o byte AAh) para que se estabilice el sintonizador de
datos interno, seguido por un byte 00h y un byte FFh para que se enganche la UART del
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
108
receptor. Luego se envía un único mensaje de inicio (byte 01h) para empezar la transmisión de
los datos y terminar finalmente con un CRC.
Se debe usar una codificación 50:50
(marca:espacio) para disminuir los errores. Un ejemplo de este tipo de codificación es enviar
cada bit dividido en dos, la primera mitad es el bit y la otra es su complemento. De esta forma
se garantiza el 50:50, esta codificación es del tipo Manchester.
Se puede usar una antena de cuarto de onda que consiste generalmente en una barra de
acero inoxidable o un alambre semiflexible.
Un mejoramiento significante en el
funcionamiento se obtiene si se usa en conjunto con una base plana de metal con un radio
mínimo de 300mm; bajo estas condiciones el rendimiento se aproxima al de una antena de
media onda, esta se observa en la figura 5.9.
Figura 5.9 Antena de cuarto de onda
Fuente: [13], página 13.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
109
El BiM1 puede usarse en distintas configuraciones desde una simple conexión entre dos
equipos hasta una red multinodo. Al ser un dispositivo de una sola frecuencia un sistema de red
multinodo requiere de un protocolo de señales como el TDMA donde sólo puede existir un
transmisor a la vez.
Esta alternativa puede ser implementada para las estaciones que se encuentran dentro
del área metropolitana, sin embargo estas no son del interés para el L.I.S. por no tener dificultad
para el acceso a estas, por lo que no se desarrolla un estudio más a fondo del diseño que se
puede usar; queda fuera del objetivo de este proyecto pero puede desarrollarse a futuro. Se
puede proponer una arquitectura con varios nodos que sirvan como repetidores entre ambas
terminales para las estaciones fuera del área metropolitana. Es importante la necesidad de la
existencia de línea vista entre nodos similar a la figura 5.10. Esto sería poco práctico conforme
aumente la distancia y los obstáculos, sin embargo su inversión inicial sería de muy bajo costo,
cada unidad de estas tiene un monto de 41.35 GBP ($77).
Figura 5.10 Enlace por radio remoto
Fuente: [24], página 313.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
110
5.4 HAM radios
Los HAM radios son los radios utilizados para transmisión en la banda de
radiofrecuencia aficionada/amateur. La radio amateur es una comunidad de personas que
transmiten y reciben comunicaciones de voz con otros operadores amateurs a lo largo del
mundo.
Usando uno de estos radios es posible por medio de un TNC, que es similar a un módem
de los que se usan para conectarse a la Internet, tener una red local. Una de las diferencias es
que el TNC es usado como interfaz con el equipo terminal o computadora con el medio RF,
además
dentro
del
TNC
se
tiene
un
firmware
llamado
PAD
(“Packet
Assembler/Disassembler”). EL PAD captura los datos que entran o salen y los ensambla en
paquetes para ser enviados hacia y desde el radio.
La información recibida del radio es convertida también en el PAD, en un flujo de datos
y es enviada al TNC/módem. Posteriormente los datos son enviados al puerto serial para ser
desplegados en la pantalla o para ser manipulados por un programa terminal residente.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
111
El uso de paquetes de datos tiene tres grandes ventajas para este tipo de medio sobre
otros transportes digitales: transparencia, corrección de errores y control automático.
Es
transparente en el sentido que el usuario se conecta con otra estación, escribe un mensaje y es
enviado automáticamente. El TNC divide automáticamente el mensaje en paquetes y los envía.
Cuando se reciben datos el TNC decodifica, chequea errores y despliega el mensaje sólo si no
encontró errores. Otra ventaja de otros modos es la habilidad para que muchos usuarios
compartan el mismo canal en frecuencia simultáneamente.
Figura 5.11 Estación de Radio Digital
Fuente: [29].
Una estación está compuesta por una computadora, un TNC y un radio, figura 5.11. El
TNC contiene un módem, un microprocesador y la circuitería encargada de convertir las
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
112
comunicaciones entre la computadora y el protocolo de radio en uso. La mayoría de usuarios
usan una velocidad de 1200 bps para transmisiones locales en VHF y UHF, mientras que para
largas distancias se usa 300 bps en comunicaciones de ancho de banda reducido en HF. Para la
velocidad de 1200 bps se usan los radios comunes de voz en FM. Para los paquetes en HF, los
datos en 300 bps se usan en modulación SSB (“single side band”). Velocidades mayores (por
encima de los 9600 bps) ocupan de radios especiales o modificados.
Dado que es común usar altas frecuencias (VHF), el rango de la transmisión es limitado.
Este es influenciado por la potencia de transmisión, el tipo y ubicación de la antena, como
también la frecuencia usada y la extensión del cable que se conecta a la antena. Otro factor que
influye es la existencia de obstáculos como edificios o colinas. Por eso el rango puede oscilar
entre 10 a 100 millas.
A diferencia de las comunicaciones de voz, se puede soportar múltiples conversaciones
en la misma frecuencia al mismo tiempo. Esto no significa que exista interferencia entre dos
estaciones que transmitan al mismo tiempo, conocido como colisiones. Las comunicaciones
ocurren durante el tiempo en que las otras comunicaciones no se estén llevando a cabo usando
un protocolo llamado AX.25 (Amateur X.25) para compartir el mismo canal. El AX.25 fue
desarrollado en la década del 70 basado en el protocolo para redes inalámbricas X.25.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
113
En términos generales lo que el protocolo AX.25 especifica es que cuando un TNC
requiere transmitir, monitorea si el canal se encuentra libre. Dado el caso en que nadie más se
encuentre en un proceso de comunicación se envía la información y el resto de las estaciones
captan y no transmiten hasta que se finalice. Si ocurre una colisión de alguna índole, los TNC
transmisores no reciben la señal de recibido, luego cada TNC espera una cantidad de tiempo al
azar para retransmitir. Una ventaja del AX.25 es que cada paquete contiene el usuario o
sobrenombre del emisor y receptor para identificar cada transmisión y sirve también para
manejar otros protocolos como el TCP/IP. Existen otros protocolos; sin embargo, el AX.25 es
el más usado y el predeterminado por defecto.
La plataforma mas popular en el desarrollo y uso de este método de comunicaciones es
el sistema operativo Linux, al incluir en el kernel el soporte completo. Un aspecto importante
de esta plataforma es que permite aparte del soporte para un TNC, usar algunas tarjetas de
sonido para emular las funciones requeridas conectando la tarjeta de sonido directamente a las
terminales de audio del radio, convirtiéndola en un soft-módem. En lugar de tener como
equipo terminal un computador personal se puede utilizar un sistema incrustado como interfaz.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
114
Las desventajas de este método de comunicación para el presente trabajo son que se
requiere de al menos dos radios que operen en la banda de radio aficionada y la inversión
necesaria por cada equipo es considerablemente costosa, sin contar el dispositivo TNC si fuese
necesario al no contar con una tarjeta de sonido para la interfaz que se comunicaría con los
acelerógrafos como puede serlo un sistema incrustado. También es necesario en Costa Rica,
para operar en una banda de aficionado, realizar un examen que le acredite al usuario el
permiso necesario.
Es importante resaltar que en nuestro país se está experimentando la combinación de los
protocolos AX25 v.2 y el TCP/IP de Internet, encapsulando y creando así una compuerta capaz
de enlazar computadores ubicados en lugares remotos o inaccesibles, interconectando redes de
datos muy diferentes, desde y hacia la Internet durante las 24 horas. Se está planeando la
instalación de los próximos 2 nodos, uno ubicado en El Cerro de La Muerte que cubre el Sur de
Costa Rica y parte del Norte de Panamá, el otro en Cerro Santa Elena con lo cual se cubre el
Norte de Costa Rica.5
5
Dirección del gateway: http://163.178.88.12/
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
115
5.5 RF Módems
Un módem RF convierte una señal digital en una forma conveniente para ser
transportada por medio de un enlace de comunicaciones analógico, convirtiendo esta señal a
una frecuencia más alta para la transmisión.
Usualmente estos módems tienen capacidad de “half duplex”, esto quiere decir, que para
cualquier nodo en un instante dado puede transmitir o recibir, pero no ambas cosas al mismo
tiempo. Es similar al estándar RS485 y diferente al estándar RS232 el cual es “full duplex”.
Dado que la transmisión y recepción se efectúa en un mismo canal, sólo puede haber un
transmisor activo. Toma una cantidad finita de tiempo apagar un transmisor, encender un
receptor y dejar que se estabilicen. El periodo de retardo entre la transmisión y recepción es de
varios milisegundos, depende del hardware que compone al módem y del tiempo requerido
para los protocolos de software conmutar el flujo de datos.
Las transmisiones son del tipo “multicast”, como se usa un canal en RF cualquier nodo
que se encuentre dentro del rango del nodo transmisor recibe información, no existe forma de
limitar el alcance de la transmisión hacia un receptor en específico. Todas los mensajes son
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
116
enviados en paquetes que consisten en un encabezado, los datos y un chequeo cíclico
redundante (CRC).
Cada nodo tiene una dirección única. Todas las transmisiones pueden ser captadas por
todos los nodos dentro del rango de recepción, pero dentro de cada transmisión está una
dirección receptora opcional. El encabezado del mensaje y la dirección del receptor pueden
identificar el mensaje como un mensaje de difusión deliberado, hacia todos los receptores o
hacia uno en específico.
Típicamente, un nodo se programa para recibir mensajes grupales o individuales. Sin
embargo, existen circunstancias donde se desea que un nodo reciba todos los mensajes con la
intención de depurar una red, analizar el trafico, determinar si el mensaje fue enviado a una
dirección equivocada, etcétera.
Los módems RF son dispositivos punto a punto, esto significa que cualquier par de
nodos pueden establecer una comunicación entre ellos, sin pasar por medio de un servidor.
Dado que todos los nodos dentro de un mismo rango de recepción comparten un único canal,
existe la posibilidad de que ocurran colisiones de datos si dos transmisores empiezan al mismo
tiempo.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
117
Debido a que un nodo no puede controlar quien puede recibir los datos, la seguridad
debe implementarse usando el encriptado de datos antes de ser transmitidos. Los nodos que no
tienen la habilidad de desencriptar el mensaje no puede descifrar el contenido del mensaje.
Es común el deseo de extender una interfaz serial por cable reemplazando por un
módem RF. Esto no es tan simple, se necesita modificar el código del programa para construir
los paquetes de datos y manejar el hecho de que la comunicación es “half duplex”, además de
que típicamente aumenta en gran medida el retardo y los datos se pueden perder o corromperse.
En el mercado actual se pueden adquirir distintos tipos de módulos que tienen todas las
funciones requeridas para un módem RF a un bajo costo de última tecnología. Entre otros
aspectos permiten la implementación de distintas arquitecturas de comunicación como en la
figura 5.11 por tener la capacidad de manejar varios canales a la vez.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
118
Figura 5.12 Arquitecturas para módems RF
Fuente: [25], página 2.
Hablando de un caso en específico se puede mencionar el módulo 9XTend del
fabricante MaxStream que puede tener un rango de alcance de hasta 64 km con una antena de
alta ganancia y línea vista para una velocidad máxima de 9600 bps. Opera a una frecuencia de
aproximadamente 900MHz y usa modulación FSK. Cabe destacar el soporte que tiene para el
protocolo RS-232, el encriptado de datos, configuración de parámetros por medio de comandos
AT y con 1 Watt de salida.
Este módulo se puede interfasar a un sistema huésped a través del puerto serial
asincrónico con niveles TTL. Por medio de su puerto serial, el módulo se puede comunicar con
cualquier UART compatible en los niveles de voltaje o por medio de un nivelador de voltajes.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
119
Figura 5.13 Diagrama de flujo de transmisión para módulo RF
Fuente: [26], página 9
La UART ejecuta tareas tales como el manejo de los tiempos de conmutación y el
chequeo de paridad.
La comunicación serial consiste en dos UARTs configuradas con
parámetros compatibles (velocidad, paridad, bit de inicio, bit final, cantidad de bits).
Figura 5.14 Diagrama del flujo interno de datos de módulo RF
Fuente: [26], página 10
La secuencia del flujo de datos se inicia cuando el primer byte es recibido del módulo
transmisor. En la figura 5.13 se tiene un diagrama típico para este tipo de dispositivos. Cabe
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
120
destacar el uso de un buffer tanto para la etapa de transmisión como para la etapa de recepción.
Cuando los datos seriales entran por DI desde la UART se almacenan en el buffer hasta poder
ser transmitidos, en este momento el módulo cambia su estado para iniciar la conexión RF con
otros módulos. La cantidad de información necesaria para transmitir se configura con los
comandos AT. El buffer DI puede almacenar hasta 2.1KB. Si se supera la capacidad se debe
usar control de flujo de hardware o software para prevenir un “overflow” (pérdida de datos
entre el huésped y el módulo).
Si el módulo detecta una señal RF mientras se encuentra en el modo de espera, cambia
su estado al modo de recepción para comenzar a recibir los datos. Una vez que el paquete de
datos es recibido el módulo chequea el CRC para asegurarse que no hubo pérdida de datos o
errores de transmisión. Si el chequeo CRC es inválido el paquete se descarta; cuando es
aceptado procede al buffer DO.
Los módulos se adquieren en grupos, el costo de cada unidad es de $209 para un pedido
de 12 módulos, es decir, un costo total de $2508.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
121
Los inconvenientes que tiene este tipo de opción son la velocidad de operación y la
necesidad de línea vista, pues para la topografía de Costa Rica es difícil obtener regiones sin
obstáculos. También se destaca el costo comparado con la opción del BiM1.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
122
CAPÍTULO 6: Conclusiones y recomendaciones
6.1 Conclusiones
Se concluye que debido a la topografía del país y los costos que implica realizar un
enlace en radiofrecuencia, la mejor alternativa para los acelerógrafos ubicados fuera del área
metropolitana es el uso de un sistema incrustado aprovechando la arquitectura presente en todo
el país para realizar una comunicación usando un dispositivo GPRS/GSM, tomando en cuenta
las distintas soluciones planteadas en este documento.
Así mismo, en el estudio realizado en este documento, se logra concluir que esta opción
no es la más barata para las estaciones que se encuentran en el área metropolitana debido a que
la topografía permite la existencia de línea vista entre el Laboratorio de Ingeniería Sísmica de la
U.C.R. y los acelerógrafos que se encuentren en este rango.
Se demuestra que se puede usar efectivamente un sistema incrustado operando Linux
para comunicarse por medio del puerto serial con los acelerógrafos usando el modo terminal de
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
123
comunicación que estos tienen y a la vez transmitir los archivos de interés por el enlace de
Internet que se establece por medio del dispositivo GPRS.
Además se establecieron las bases para un diseño preliminar para los acelerógrafos
ubicados cerca del L.I.S.
6.2 Recomendaciones
Se recomienda como primer alternativa para las estaciones que se encuentran en lugares
remotos y de difícil acceso el uso de un sistema incrustado como interfaz usando un dispositivo
GPRS para establecer una comunicación de Internet. El costo de oportunidad asociado a esta
solución es el mejor para dichas circunstancias, además de permitir gran flexibilidad en la
operación de un acelerógrafo. Es necesario que el usuario tenga un conocimiento básico del
sistema operativo Linux para aprovechar este tipo de medio de comunicación inicialmente.
Si es del interés para el Laboratorio de Ingeniería Sísmica, se puede usar la alternativa
de construir una red usando módems RF para las regiones donde exista línea vista, dado que
esta es la mejor opción para estas condiciones, por su costo y fácil uso al tener varios canales de
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
124
comunicación. Como segunda alternativa se recomienda el diseño con el integrado BiM1 al ser
el más barato.
Se recomienda mejorar la interfaz con el usuario para que sea más amigable y
aprovechar la capacidad de procesamiento del sistema incrustado para que sea capaz por sí sólo
de adquirir los archivos, comprimirlos con las herramientas incluidas como Gzip, cambiar los
parámetros de operación y enviar información a un servidor. Además se recomienda usar una
memoria con mayor capacidad, la diferencia de costo es despreciable.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
125
BIBLIOGRAFÍA
1.
Hernández Sampieri, R.
Fernández Collado, C.
Baptista Lucio, P.
“Metodología de la Investigación”, 2da. edición, Editorial McGraw-Hill,
México, 1998.
2.
Kinemetrics Inc. “Altus Monitor Mode Communications”, Documento
302219, Revisión O, U.S.A., Junio 2004.
3.
Kinemetrics Inc. “Altus Block Mode Communications”, Documento 302218,
Revisión F, U.S.A., Junio 2004.GPRS)
4.
Kinemetrics Inc. “Etna Digital Recorder”, Documento 302230, Revisión C,
U.S.A., Junio 2004.
5.
Kinemetrics Inc. “Kinemetrics QDR Quake Data Recorder”, Documento
302704, Revisión E, U.S.A., Noviembre 2001.
6.
Kinemetrics Inc. “Altus Digital Recorder”, Documento 302200, Revisión I,
U.S.A., Abril 2002.
7.
Andersson, Christoffer. “GPRS and 3G wireless applications: professional
developer's guide”, 1era. Edición, Editorial John Wiley & Sons, Inc., U.S.A.,
2001.
8.
Lloyd-Evans, R. “QoS in Integrated 3G Networks”, 1era. Edición, Editorial
Artech House, Inc. U.S.A., 2002.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
9.
126
Wakerly, John F. “Diseño Digital. Principios y Prácticas”, 3era. Edición,
Editorial Prentice Hall, U.S.A., 2001.
10.
Strangio, Christopher E. “The RS-232 Standard”, CAMI Research Inc.,
Lexington, Massachusetts, U.S.A., 2004.
11.
Radiográfica Costarricense S.A. “Internet Vía Satelital”, www.racsa.co.cr.
12.
Radiográfica Costarricense S.A.
“Servicio de Red Nacional Inalámbrica
Digital”, www.racsa.co.cr.
13.
Radiometrix
Ltd.
“VHF
Narrow
Band
FM
transceiver”.
www.radiometrix.co.uk
14.
Radiometrix Ltd. “Error Performance of BIM Transceiver with RS232
Interface”. Application Note 101. 1997.
15.
Laboratorio de Ingeniería Sísmica de la U.C.R. “Red de acelerógrafos (Marzo
del 2003)” www.fing.ucr.ac.cr/~lis/espa/estaciones.html
16.
E.T.S.I. “GSM 07.07: AT command set for GSM Mobile Equipment (ME)”
ETS 300 916. Febrero, 1998. www.etsi.org
17.
E.T.S.I. “3GPP TS 27.005 v5.0.0: Use of Data Terminal Equipment - Data
Circuit terminating; Equipment (DTE - DCE) interface for Short Message
Service (SMS) and Cell Broadcast Service (CBS)” . Junio, 2002. www.etsi.org
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
18.
127
E.T.S.I. “3GPP TS 27.007 v5.4.0: Universal Mobile Telecommunications
System (UMTS); AT command set for 3G User Equipment (UE)” .
Setiembre, 2003. www.etsi.org
19.
Lombardo, J. ”Linux Incrustado” , 1era Edición, Editorial Prentice Hall,
España, 2002.
20.
Hollabaugh, C. “Embedded Linux. Hardware, Software and Interfacing”,
1era Edición, Editorial Addison-Wesley, U.S.A., 2002.
21.
Cardona Soto, R. “Guía de Laboratorio de Sistemas Incrustados”, U.C.R.,
Agosto del 2004.
22.
Arias Obando, D. Villalta Fallas, M. “Experimento Especial II-2003:
Demodulación FM”, U.C.R. Diciembre del 2003.
23.
Heatherington, D.
“The WA4DSY 56KB RF modem information page”,
http://www.wa4dsy.net/rfmodem.html
24.
Letho, A.
Raisanen, Antti V.
“Radio Engineering for Wireless
Communication and Sensor Applications”, 1era. Edición, Editorial Artech
House, Inc. U.S.A., 2003.
25.
Aerocomm. “AC4490, 900 Mhz Transceiver. Users Manual.”, Version 1.7,
Aerocomm Inc., 2004.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
26.
MaxStream.
“Xtend OEM RF Module.
128
Product Manual.”, Version 1.0,
MaxStram Inc., 2004.
27.
Dawson, T.
“Linux HAM HOWTO.
Amateur Radio.”, Version 2.0,
http://www.radio.org/linux/HAM-HOWTO.html
28.
Tranter, J.
“Linux Amateur Radio AX.25 HOWTO.”,
Version 2.0,
http://www.ibiblio.org/pub/Linux/docs/HOWTO/otherformats/html_single/AX25-HOWTO.html
29.
Jones,
G.
“Introduction
to
Packet
Radio”,
http://www.tapr.org/tapr/html/Fpktfaq.html
30.
Soekris Engineering. “Net4801 series boards and systems. User's manual.”,
Version 0.05. Abril 10, 2004.
31.
Progeny Linux Systems, Inc. “Debian GNU/Linux User's Guide”. Version
1.00p00. Febrero, 2003.
32.
Aoki,
O.
Sewell,
D.
“Debian
GNU/Linux
Reference”.
http://gref,sourceforge.net/
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
129
APÉNDICES
La codificación ASCII
En un esfuerzo por buscar una solución para estandarizar las representaciones de
caracteres, la mayor parte de fabricantes de computadoras y software han diseñado sus
máquinas o programas para utilizar una de las dos codificaciones mas populares, ASCII o
EBCDIC. Existen otros tipos de codificaciones, sin embargo estas dos son las mas utilizadas,
en especial el ASCII.
El Código Estándar Americano de Intercambio de Información (conocido en sus siglas
en inglés como ASCII), es usado como una representación de distintos símbolos alfanuméricos,
involucra la manipulación de los códigos numéricos apropiados y no de los caracteres asociados
a estos propiamente.
El ASCII representa cada carácter con una cadena de 7 bits, y produce un total de 128
caracteres diferentes conteniendo el alfabeto en mayúscula y minúscula, números, signos de
puntuación y diversos caracteres de control no imprimibles.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
130
Dado que se manipulan los códigos, es usual decir que un código numérico es mayor
que, menor que o igual a otro código numérico, es posible relacionar varios caracteres o
cadenas una con la otra. Cabe destacar que todas las letras mayúsculas en el conjunto de
caracteres ASCII tienen valores enteros que son equivalentes en valores ASCII a sus letras
correspondientes en minúscula menos 32.
Tabla A.1 Tabla ASCII
Hex
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI
DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US
SP !
"
#
$
%
&
'
(
)
*
+
,
.
/
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?
@
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
[
\
]
^
_
`
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
{
|
}
~ DEL
Tabla A.2 Descripción de los códigos de control ASCII
NUL
SOH
STX
ETX
EOT
ENQ
ACK
BEL
BS
HT
LF
VT
Nulo (Null)
Comienzo de encabezado (Start of heading)
Comienzo de texto (Start of text)
Fin de texto (End of text)
Fin de transmisión (End of transmition)
Pregunta (Enquiry)
Admisión (Acknowledge)
Campana (Bell)
Retroceso (Backspace)
Tabulador horizontal (Horizontal tab)
Avance de línea (Line feed)
Tabulador vertical (Vertical tab)
DLE
DC1
DC2
DC3
DC4
NAK
SYN
ETB
CAN
EM
SUB
ESC
Escape de enlace de datos (Data link escape)
Control de dispositivo 1 (Device control 1)
Control de dispositivo 2 (Device control 2)
Control de dispositivo 3 (Device control 3)
Control de dispositivo 4 (Device control 4)
Admisión negativa (Negative acknowledge)
Sincronía (Synchronize)
Fin de bloque transmitido (End transmitted b.)
Cancelación (Cancel)
Fin del medio (End of medium)
Sustitución (Subtitute)
Escape (Escape)
Diciembre del 2004
IE-0502
FF
CR
SO
SI
SP
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
Avance de página (Form feed)
Retorno de carro (Carriage return)
Corrimiento hacia fuera (Shift out)
Corrimiento hacia dentro (shift in)
Espacio (Space)
FS
GS
RS
US
DEL
131
Separador de archivo (File separator)
Separador de grupo (Group separator)
Separador de registro (Record separator)
Separador de unidad (Unit separator)
Eliminación (Delete)
EIA-232
El EIA-232 o RS-232 es una interfaz de comunicaciones seriales estándar desarrollado
por el comité de asociaciones industriales de electrónica (conocido en sus siglas en inglés como
Electronic Industries Association) desde 1960.
Regula la calidad, interconectividad entre
equipos de diferentes fabricantes y características de las comunicaciones; tales como las señales
de voltaje, tiempos y formas de onda, nombre y función de cada cable / pin, protocolos para el
intercambio de información y conectores mecánicos.
Existen dos tipos de dispositivos en este tipo de comunicación, los DCE o equipo de
comunicaciones de datos y los DTE o equipo terminal de datos. El primero es el dispositivo
encargado de manejar las comunicaciones a través de un canal para tal propósito hacia otro
dispositivo. El segundo es el dispositivo que trata de comunicar datos digitales, este a la vez
utiliza un DCE para comunicarse con otro equipo. Por ejemplo, en una computadora personal
el módem, mouse y teclado (el puerto PS2 es EIA232) son DCE y la computadora es el DTE,
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
132
también se puede usar el puerto DB9 en la parte trasera para comunicarse con otra computadora
o con otro algún equipo similar.
Figura A.1 Ejemplo de dispositivos DTE y DCE.
Fuente: [10].
Este estándar especifica 14 posibles configuraciones para las comunicaciones de los 22
tipos de conectores machos o hembras, los conectores machos son los que tienen pines mientras
los hembra son los que tienen agujeros. La asignación de pines en las conexiones seriales se
puede organizar en seis grupos:
vi. Cable de tierra/blindado
vii.Canal primario
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
133
viii.Canal secundario
ix. Estatus DCE y señales de control
x. Temporización de transmisor / receptor
Se usan voltajes no fijos y señales de control para habilitar comunicaciones asincrónicas
entre el DTE y el DCE. Los voltajes en los cables abarcan un rango de +/- 3V a +/- 15V,
dependiendo del tipo de aplicación. El 1 lógico binario es transmitido como una señal de
voltaje negativo, mientras que el 0 lógico binario es transmitido con un voltaje positivo.
Cuando no hay ninguna transmisión de datos en las líneas, el estado del voltaje se revierte a un
valor predeterminado, en cuyo caso es el 1 lógico. De esta manera, el receptor al percibir un
cambio del estado de la señal detecta que el dispositivo remoto esta iniciando una transmisión.
Algunos problemas que se pueden presentar debido a los distintos tipos de interfases son
la falta de señales de control de flujo produciendo sobre-flujo en los buffers o trabas en las
comunicaciones, función incorrecta del cable (DTE/DCE) revertiendo las líneas de las señales
de recepción y transmisión como también las líneas de control de flujo, etc. La circuitería
interna de los dispositivos EIA232 es sumamente tolerante a los errores de conexiones
sobreponiéndose a aterrizamiento de líneas transmisoras de señales o conexión de dos distintas
señales.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
134
Muchas de las señales en el estándar EIA232 pertenecen a conexiones donde el
dispositivo DCE es un módem y son usadas solamente cuando el protocolo de software las
implementa. Para cualquier dispositivo distinto a un módem o para dos dispositivos DTE
conectados directamente, pocas señales son necesarias.
La descripción de las principales
señales es:
GND (Ground): Todas las señales se refieren a una tierra común, este conductor puede o no
estar conectado con la tierra protectora dentro del dispositivo del DCE.
TxD (Transmitted Data): Esta señal es activa cuando los datos se transmiten del dispositivo del
DTE al dispositivo del DCE. Cuando no se transmite ningunos datos, la señal se establece en la
condición de 1 lógico de voltaje negativo. En el dispositivo del DCE se etiqueta comúnmente
"Received Data", aunque por el estándar EIA232 debe todavía ser llamado “Transmitted Data”.
RxD (Received Data): Esta señal es activa cuando el dispositivo del DTE recibe datos del
dispositivo del DCE. Cuando no se transmite ningunos datos, la señal se establece en la
condición de 1 lógico
de voltaje negativo. El dispositivo del DCE se etiqueta comúnmente
"Transmitted Data", aunque por el estándar EIA232 debe todavía ser llamado “Received Data”.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
135
RTS (Ready to Send): Esta señal se habilita con un 0 lógico, voltaje positivo. Sirve para
preparar el dispositivo DCE para aceptar datos transmitidos desde el dispositivo DTE como una
solicitud.
CTS (Clear to Send): Esta señal se habilita con un 0 lógico, voltaje positivo. Sirve para indicar
que el dispositivo DCE al dispositivo DTE que se encuentra listo para iniciar la transmisión de
datos. Las señales RTS y CTS son utilizadas frecuentemente para controlar el flujo de datos.
DTR (DTE Ready):
Esta señal se habilita con un 0 lógico, voltaje positivo, cuando el
dispositivo DTE desea abrir un canal de comunicaciones.
RI (Ring Indicator): Esta señal es relevante cuando el dispositivo DCE es un módem, se habilita
con un 0 lógico, voltaje positivo, cuando una señal es recibida desde la línea telefónica.
DCD (Data Carrier Detect): Esta señal es relevante cuando el dispositivo DCE es un módem,
se habilita con un 0 lógico, voltaje positivo, cuando por medio de la línea telefónica se ha
establecido una conexión y hay tono en la línea de la calidad requerida (con ruido aceptable).
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
136
DSR (Data Ready): Originada por un módem, esta señal es habilitada con un 0 lógico, voltaje
positivo, cuando el módem esta conectado a una línea telefónica activa, opera en modo de datos
y el módem ha completado la rutina de llamada.
Comandos AT – GSM
En la actualidad la mayoría de los teléfonos celulares de tecnología GSM incluyen un
módem interno. Estos tienen la capacidad de conectarse a una computadora por medio del
puerto serial o de un puerto USB y desempeñar comandos para accesar a Internet, enviar faxes,
mensajes SMS, contestar llamadas de voz y funciones propias de un teléfono celular; como
modificar el directorio telefónico, obtener información del nivel de batería o configurar los
servicios de acceso. Los módems son controlados por el estándar industrial de comandos AT
los cuales están definidos por la ETSI (European Telecommunications Standards Institute) en
las especificaciones GSM 07.07, V.25ter, T.32, 3GPP TS 27.005 y 27.007; aunque algunos
fabricantes tienen extensiones de los comandos dependiendo de las funciones y modelos de
equipos móviles. La cantidad de comandos hábiles para un dispositivo varia entre modelos y
fabricantes.
En la tabla A.3 se especifican algunos de estos comandos y una breve descripción de su
función. Para mayor detalle de ellos referirse a [16], [17], y [18].
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
137
Tabla A.3 Descripción de comandos AT-GSM/GPRS
Comando
Descripción
AT+CGMI
Identificación del fabricante.
AT+CGMM
Identificación del modelo.
AT+CGSN
Identificación del número de serie.
ATH
Desconectar la línea, terminar llamada.
ATE1
Módem habilita el “echo” de caracteres.
AT+CGDCONT
Define el nombre del punto de acceso, nombre que se usa para
seleccionar el GGSN o la red de datos externa. (GPRS)
ATD
Inicia una llamada desde el equipo móvil.
ATD>
Inicia una llamada desde el # del directorio telefónico seleccionado.
AT+CSCS
Selecciona el conjunto de caracteres usado por el módem, útil para
mensajes SMS.
AT+CEER
Provee información detallada de la falla de la ultima llamada.
AT+CCWA
Permite controlar la opción de llamadas en espera.
AT+CLCC
Provee lista de llamadas del módem realizadas.
AT+CFUN
Fija el nivel de funcionalidad del módem.
AT+CPIN
Usado para pedir y introducir la clave PIN.
AT+CSQ
Información de la calidad de la señal de la red registrada.
AT+CRSL
Nivel del parlante de sonido.
AT+CMEE
Controla nivel de información de errores.
AT+FCLASS
Fija el modo de operación del módem. (Datos o fax)
AT+VTS
Permite transmitir tonos DTMF durante llamada de voz.
+++
Cambia módem de modo enlinea de datos a modo enlinea de
comandos, mientras se encuentra en una llamada.
A/
Repetir último comando ejecutado.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
Comando
138
Descripción
ATZ
Resetea a la configuración predeterminada.
AT&F
Fija la configuración a la definida por el fabricante.
AT+CBC
Indica nivel de batería.
AT+GCAP
Indica las capacidades completas (GSM, Fax).
AT+CPAS
Indica el estatus actual.
AT+CCLK
Provee y permite fijar hora y fecha.
ATS0
Contestar automáticamente llamadas.
AT+CGATT
Desconecta/Conecta del servicio GPRS.
AT+CGCLASS
Comando usado para fijar la operación del módem de acuerdo a la
clase especifica GPRS.
AT+CGQREQ
Permite al dispositivo DTE seleccionar un perfil de la calidad de
servicio, p.e. para escoger la cantidad máxima de divisiones de
tiempo (velocidad) y si son para enviar o recibir.
AT+WGPRS
Permite modificar algunos parámetros del GPRS, p.e. el uso de
NAT.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
139
ANEXOS
Tabla B.1 Teléfonos celulares GSM, compatibles con la red del ICE.
Marca
Modelos
Básico GPRS WAP
900/1800 Mhz
1900 Mhz
A388
C200
C332, C333
C350
T190
T720, T720i
V66, V66i
V300
V600
850 MHZ
V70
311
331
511
715
T68i
T100
T200
T300
T310
T600
T610
P800
A52
C55
S45
S55
SL55
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
140
SGH-A300
SGH-C100
SGH-E700
SGH-N620
SGH-R210S
SGH-S300
GD-75
MW 3020
MY C1*
MY C2
MY X1W
MY X2
1100
2100
3100
3310*
5210
6310i
6510
7210
7650
8310
ESC!
Q
Track
Twin
G5400
W3000
TARJETAS PCMCIA PARA DATOS
Globe Trotter
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
141
Nota importante: Algunos de estos terminales (teléfonos) pueden presentar programaciones
de otras redes diferentes a la de ICE Celular lo que puede ocasionar no tener acceso a
alguno (s) servicios.
Simulación con acelerógrafo
La siguiente es una simulación realizada con el paquete Minicom de Linux con uno
de los acelerógrafos disponibles en el L.I.S.
\\\\
* time
Aug 19, 2004
16:58:18.000
Syntax: TIME year, month, day, hour, minute, seconds
* dir
Directory of A:\EVT\040819
Volume Label: "ALTUS_K2
", Volume S/N: 2100-3900
.
<DIR>
2004-08-19 14:20
..
<DIR>
2004-08-19 14:20
HM002
EVT
220.2 kb
2004-08-19 14:20
HM003
EVT
222.4 kb
2004-08-19 16:51
A
453272 bytes in 4 file(s) (31548 kb free)
* blockmode
Entering block mode...
Type '\\\' <CR> to enter monitor mode
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
142
\\\\
* cd
Syntax is: CHDIR pathname
* cd ..
You are now in directory A:\EVT
* cd..
Unknown command
* b:
* dir
Error 36:
- Error opening directory B:\
* a:
* dir
Directory of A:\EVT
Volume Label: "ALTUS_K2
", Volume S/N: 2100-3900
.
<DIR>
1997-08-15 17:59
..
<DIR>
1997-08-15 17:59
040819
<DIR>
2004-08-19 14:20
001113
<DIR>
2000-11-13 11:44
040625
<DIR>
2004-06-25 16:49
031225
<DIR>
2003-12-25 07:13
040107
<DIR>
2004-01-07 10:44
0 bytes in 8 file(s) (31548 kb free)
* dismod
Commands:
BITMAP
CHANNEL
MODEM
RWMISC
SENSOR
SERIAL_DATA_STREAM
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
143
STREAM
* cd
040107
You are now in directory A:\EVT\040107
* dir
Directory of A:\EVT\040107
Volume Label: "ALTUS_K2
", Volume S/N: 2100-3900
.
<DIR>
2004-01-07 10:44
..
<DIR>
2004-01-07 10:44
ZD009
EVT
189.0 kb
2004-01-07 10:44
193576 bytes in 3 file(s) (31548 kb free)
* tx
zd009.evt
K
Transmitted 190 packets
* edit
CAUTION: Acquisition is ON.
EDIT> abort
* hel
Commands:
A:
ALARM
ANSWERMODE
AUTOBAUD
AQ
B:
BAUDRATE
BLOCKMODE
CALLMODE
CD
CHDIR
CLEAR
COPY
DEL
DG
DIR
DISPLAY
EDIT
ERASE
FORMAT
HELP
MD
MKDIR
PASSWORD
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
PW
RD
RELEASE
RENAME
RMDIR
RX
STATUS
SUMMARY
SYSTEM
TIME
TX
VERSION
144
WIPEDISK
* ver
K2 Strong Motion Software 02.73
4/6/12 Channels.
P/N 302292.
Copyright (c) 1999 Kinemetrics, Inc.
Last Revised: June 24, 1999
Boot Block Version 01.10
DSP Block Version 08.60
Simulación con dispositivo GPRS
La siguiente es una simulación de algunos comandos realizada con el paquete
Minicom de Linux con un dispositivo celular GPRS.
ATZ
OK
AT+CGMI
+CGMI: "Motorola CE, Copyright 2000"
OK
AT+CGMM
+CGMM: "GSM1900","GSM850","MODEL=C330"
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
145
OK
AT+CGSM
ERROR
AT+CGSN
+CGSN: IMEI350647622562688
OK
ATE1
OK
AT+CSCS=?
+CSCS: ("8859-1","ASCII","GSM","UCS2","UTF8")
OK
AT+CEER
+CEER: No information available
OK
AT+CLCC=?
ERROR
AT+CFUN=?
ERROR
AT+CSQ
+CSQ: 15,99
OK
AT+CMEE=?
+CMEE: (0-2)
OK
AT+FCLASS=?
+FCLASS: 0,1
OK
A/
+FCLASS: 0,1
OK
AT+CBC
+CBC: 0,60
OK
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
146
AT+GCAP
+GCAP: +FCLASS
OK
AT+CCLK=?
+CCLK: "99/12/31,23:59:59,(-47...+48)"
OK
AT+CPAS
ERROR
AT+CGATT=?
+CGATT: (0,1)
AT+CGCLASS=?
+CGCLASS: (B)
OK
AT+CGREG=?
ERROR
AT+CGPADDR=?
+CGPADDR: (1,2,3)
OK
AT+CGDCONT=?
+CGDCONT: (1-3),(IP),,,(0,1),(0,1)
OK
AT+CGDCONT=1,"IP","icecelular"
OK
AT+CGQREQ=?
+CGQREQ: (1-3),(0-3),(0-4),(0-5),(0-9),(0-18,31)
OK
AT++WGPRS=?
ERROR
Scripts
GPRSCONECTAR
#!/bin/sh
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
147
exec /usr/sbin/pppd call gprs
GPRS
# gprs:
# Para que se quede en la consola la salida en lo gar de modo "demonio"
nodetach
# Para más información
debug
# Para que salga la contraseña en los mensajes
show-password
# Script que se usa para inicializar el modem, etc
connect /etc/ppp/peers/gprs-connect-chat
# Comandos AT para terminar la conección
disconnect /etc/ppp/peers/gprs-disconnect-chat
# Dispositivo al cual pppd le va a usar para conectarse a internet
/dev/ttyACM0
# Velocidad a la que pppd le va a hablar al módem (varía según cada
dispositivo)
115200
# Control por Hardware
crtscts
# cable serial, Bluetooth y USB
# Ignorar "tono" (carrier)
local
# Pedir IP sin proponer alguno
noipdefault
# Aceptar el IP que el servidor proponga
ipcp-accept-local
# Agregar esta conexión como ruta por defecto, como salida a internet
defaultroute
# Usar el servidor de Nombres (DNS) que nos ofrece el servidor
usepeerdns
# Desabilitar cualquier tipo de compresión, no es necesaria
novj
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
148
nobsdcomp
novjccomp
nopcomp
noaccomp
# The phone is not required to authenticate:
noauth
# Usar el usuario "icecelular" con una contraseña vacía
user "icecelular"
# Algunos teléfonos requieren esta Opción
#asyncmap 0xa0000
# No magic:
# some phones may require this option.
#nomagic
# some phones may require this option.
#require-pap
GPRS CONNECT
#!/bin/sh
#
exec /usr/sbin/chat
TIMEOUT
\
5
\
ECHO
ON
\
ABORT
'\nBUSY\r'
\
ABORT
'\nERROR\r'
\
ABORT
'\nNO ANSWER\r'
ABORT
'\nNO CARRIER\r'
\
ABORT
'\nNO DIALTONE\r'
\
ABORT
'\nRINGING\r\n\r\nRINGING\r'
''
\rAT
TIMEOUT
SAY
falla"
\
\
\
12
"Presione
\
Ctrl-C
en
cualquier
momento
si
la
conexión
\
SAY
"\nEnviando los comando iniciales al módem...\n"
\
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
OK
ATH
\
OK
ATE1
\
OK
AT+CGDCONT=1,"IP","icecelular"
OK
ATD*99***1#
TIMEOUT
SAY
149
\
22
\
\
"\nEsperando estar conectados...\n" \
CONNECT
""
\
SAY
"\nConectado!.\n"
\
SAY
"\nSi las próximas negociaciones fallan,\n"
SAY
"pruebe reseateando el teléfono\n"
\
GPRS DISCONNECT
#!/bin/sh
exec /usr/sbin/chat -V -s -S
\
ABORT
"BUSY"
\
ABORT
"ERROR"
\
ABORT
"NO DIALTONE"
\
SAY
"\nEnviando orden de fin al modem...\n"
""
"\K"
\
""
"+++ATH"
\
SAY
"\nLa conexión se ha terminado\n"
\
Existe también un archivo llamado gprsdesconectar que es un symlink hacia el script
encargado de desconectar el servicio, pero este se ubica para que sea ejecutable desde la línea
de comandos. Se crearon otros scripts para facilitar el proceso de comunicación, sus nombres
son: iniciartunel y detenertunel, contienen las instrucciones para crear el túnel y detenerlo. Su
ubicación es en /usr/sbin. También hay un script en /lisucr para recibir un archivo de prueba.
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
150
Historial de inicio
comBIOS ver. 1.26
20040721
Copyright (C) 2000-2004 Soekris Engineering.
net4801
0128 Mbyte Memory
CPU Geode 266 Mhz
Pri Mas
LBA 490-4-32
Slot
SanDisk SDCFB-32
Vend Dev
GNU GRUB
ClassRev Cmd
version 0.95
Stat CL LT HT
Base1
31 Mbyte
Base2
Int
(639K lower / 130048K upper memory)
Linux version 2.6.9 (root@milmares.VILLA) (gcc version 3.3.4 (Debian 1:3.3.4134
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000008000000 (usable)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
128MB LOWMEM available.
DMI not present.
ACPI: Unable to locate RSDP
Built 1 zonelists
Kernel
command
video=vga16:1
line:
boot=/dev/hda
root=/dev/hda1
rw
init=/sbin/sh
No local APIC present or hardware disabled
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 266.663 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 125816k/131072k available (1789k kernel code, 4752k reserved, 976k
data)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
151
Checking 'hlt' instruction... OK.
CPU0: NSC Unknown stepping 01
per-CPU timeslice cutoff: 160.14 usecs.
task migration cache decay timeout: 1 msecs.
SMP motherboard not detected.
Local APIC not detected. Using dummy APIC emulation.
Brought up 1 CPUs
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.00 entry at 0xf7861, last bus=0
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
................................
IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com>
scx200: NatSemi SCx200 Driver
scx200: GPIO base 0x6100
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
vesafb: probe of vesafb0 failed with error -6
vga16fb: mapped to 0xc00a0000
Console: switching to colour frame buffer device 80x30
fb0: VGA16 VGA frame buffer device
Real Time Clock Driver v1.12
scx200_wdt: timer margin 60 seconds
sc1200wdt: build 20020303<3>sc1200wdt: io parameter must be specified
Hangcheck: starting hangcheck timer 0.5.0 (tick is 180 seconds, margin is 60
se.
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
152
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
ub: sizeof ub_scsi_cmd 60 ub_dev 940
usbcore: registered new driver ub
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
originally by Donald Becker <becker@scyld.com>
http://www.scyld.com/network/natsemi.html
2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
natsemi
eth0:
00:00:24:c1:cc:4.
NatSemi
DP8381[56]
at
0xa0000000
(0000:00:06.0),
natsemi
eth1:
00:00:24:c1:cc:4.
NatSemi
DP8381[56]
at
0xa0001000
(0000:00:07.0),
natsemi
eth2:
00:00:24:c1:cc:4.
NatSemi
DP8381[56]
at
0xa0002000
(0000:00:08.0),
PPP generic driver version 2.4.2
NET: Registered protocol family 24
SLIP: version
encapsul.
0.8.4-NET3.019-NEWTTY
(dynamic
channels,
max=256)
(6
bit
CSLIP: code copyright 1989 Regents of the University of California.
SLIP linefill/keepalive option.
Equalizer2002:
Simon
(davem@redhat.co)
Janes
(simon@ncm.com)
and
David
S.
Miller
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SC1200: IDE controller at PCI slot 0000:00:12.2
SC1200: chipset revision 1
SC1200: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:pio, hdd:pio
hda: SanDisk SDCFB-32, ATA DISK drive
SC1200: set xfer mode failure
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 62720 sectors (32 MB) w/1KiB Cache, CHS=490/4/32
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
153
hda: hda1
ohci_hcd 0000:00:13.0: Compaq Computer Corporation ZFMicro Chipset USB
ohci_hcd 0000:00:13.0: irq 11, pci mem c8836000
ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
usbcore: registered new driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.23:USB Abstract Control Model driver for USB
mos
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
: probe failed
: probe failed
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
ip_conntrack version 2.1 (1024 buckets, 8192 max) - 304 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 4
kjournald starting.
Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing unused kernel memory: 168k freed
drivers/usb/class/cdc-acm.c: Ignoring extra header
cdc_acm 1-1:1.0: ttyACM0: USB ACM device
init started:
BusyBox v1.00 (2004.11.26-07:08+0000) multi-call binary
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
154
-------------------------Bienvenido a MarcOS_Linux!
Estacion Experimental
L.I.S. - U.C.R.
-------------------------LisSbc login: root
Password:
warning: cannot change to home directory
login[675]: root login
on `ttyS0'
BusyBox v1.00 (2004.11.26-07:08+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/ # df
Filesystem
1k-blocks
/dev/hda1
30313
Used Available Use% Mounted on
11261
17487
39% /
/ # vtund
VTun ver 2.6 11/27/2004
Usage:
Server:
vtund <-s> [-f file] [-P port]
Client:
vtund [-f file] [-P port] [-L local address] [-p] [-t timeout] <host>
<>
/ # microcom
Usage: microcom [options]
[options] include:
-Ddevfile
use the specified serial port device;
if a port is not provided, microcom
will try to autodetect a modem
example: -D/dev/ttyS3
-S
run scripts from scripts.scr (default)
-Sscrfile
run scripts from scrfile
microcom provides session logging in microcom.log file
Diciembre del 2004
IE-0502
Propuesta de Diseño de Comunicación Remota en RF para el L.I.S. de la U.C.R.
155
Asignación de pines puerto serial del Net4801
Diciembre del 2004