Seas historicas
#02.- EL MODELO OSI.
#03.- AX.25, EL PROTOCOLO DE LA CAPA DE ENLACE.
#03.a.- Las tramas y los campos AX.25.
#03.b.- Como funciona una unin AX.25 ?
#03.c.- El protocolo de Vancouver.
#04.- LA PUESTA EN FUNCIONAMIENTO DE UNA ESTACION DE PACKET-RADIO.
#04.a.- El equipo terminal.
#04.b.- La TNC.
Codificacion y modulacin
Modos de acceso al canal de radio
Seleccion de la TNC
#04.c.- El equipo de radio.
#04.d.- La conexin RS232.
#04.e.- La conexin con el emisor-receptor.
#04.f.- La velocidad de transmisin.
#04.g.- Caso de usar solo modems en lugar de las TNC's.
#04.h.- Uso de las tarjetas de sonido.
#04.i.- Descripcin tcnica de un minimo del BayCom clasico.
#04.j.- Modos de funcionamiento de las TNC's.
#04.k.- Los programas utilizados.
#05.- PUESTA EN SERVICIO.
#06.- LOS COMANDOS DEL TERMINAL.
#07.- LOS COMANDOS DEL PORT RADIO.
#08.- LOS COMANDOS DE IDENTIFICACION.
#09.- LOS MODOS DE COMANDO, DE CONVERSACION Y TRANSPARENTE.
#10.- OPERACION EN PACKET.
#10.a.- El establecimiento del contacto.
#10.b.- Intercambios de informacion.
#10.c.- El fin del contacto.
#10.d.- Vigilancia de la actividad de packet radio (monitorizacion).
#10.e.- Control de los par metros de la TNC.
#10.f.- La conexin con su propia estacin.
#10.g.- Las conexiones mltiples.
#10.h.- Operacion remota
#11.- ALGUNOS TIPOS DE ESTACIONES DE PACKET ESPECIALES.
#11.a.- Los digipeaters.
#11.b.- Los BBS's de packet radio.
#11.c.- Algunos aspectos de los BBS's.
Acerca de los mensajes
Flags de los mensajes
Los listados "Unproto"
Transferencias binarias: 7PLUS, AUTOBIN, YAPP El uso del password. Proceso de conexion.
El forward (FWD) del correo
#11.d.- Los buzones personales o PMS's.
#11.e.- Los NODOS de packet radio.
#12.- EL PROBLEMA DE LAS COLISIONES.
#12.a.- Introduccion
#12.b.- La capa MAC del modelo OSI.
#12.c.- El metodo de la Persistencia.
#12.d.- El protocolo KISS
#12.e.- El metodo DAMA.
#12.f.- El FLEXNET
#13.- EL BUEN PROCEDIMIENTO.
#14.- PACKET Y SATELITES DE RADIOAFICIONADO.
#14.a.- El protocolo PB/PG
#15.- PACKET RADIO E INTERNET
#15.a.- Introduccion sobre Internet
#15.b.- Radiopaquete digital e Internet
Acceso de usuarios mediante Telnet
Forward entre BBSs por Internet
Ofrecimiento de correo electronico a usuarios terminales
Integracion de estaciones terminales de radiopaquete en Internet
#16.- ALGUNAS APLICACIONES ADICIONALES DEL PACKET
#16.a.- Estaciones Cluster
#16.b.- Estaciones APRS
#17.- ANEXOS
#17.a.- Ejemplo de sesion de packet
#17.b.- Ejemplo de monitorizacion de un canal de packet radio
#17.c.- Ejemplo de archivo enviado en 7Plus
#17.d.- Ejemplo de monitorizacion de tramas APRS
#17.e.- Enrutados jerarquicos
#01.- INTRODUCCION
El "PACKET-RADIO" o "RADIOPAQUETE DIGITAL" es un sistema digital del
mismo tipo que el RTTY o el AMTOR. Buscando afinidades, quizas este mas
cerca de la forma de funcionar del AMTOR.
Esta forma de comunicacion es el resultado de buscar la transmision
libre de errores a la vez que veloz; esto practicamente se ha conseguido.
Para lograr fiabilidad ha sido preciso establecer un protocolo, es
decir, un di logo entre los terminales para comprobar que la informacion ha
sido recibida correctamente, junto con un sistema de control de errores que
va incluido dentro del mismo "paquete" entregado y que comprueba el receptor.
El dar el nombre de "PAQUETE" ha sido debido a la afinidad con estos, ya
que cada "chorro" de transmision de bits de corta duracion va identificado
con el remitente, con el destinatario y hasta las con las "oficinas" por las
que tiene que pasar. Esto da algunas ventajas, como no tener que poner el
indicativo, ya que en cada paquete va incluido autom ticamente.
Al ser la transmision de muy corta duracion, hace posible que el canal
de radio pueda compartido por varias estaciones funcionando a la vez, pues
la TNC (terminal para packet) lleva un sistema de deteccion de canal ocupado
y se espera para hacer su transmision a que quede libre si estuviera ocupa-
do. Si se sobremodula con otra transmision simultanea, por medio del proto-
colo se vuelve a repetir la transmision del paquete hasta que el receptor
distante lo confirma.
El radiopaquete permite conectar dos o mas estaciones directamente en
lo que se llama "teclado a teclado" y mantener un QSO normal, o utilizar los
llamados buzones de correo para conectar a traves de mensajes y/o boletines
de informacion que pueden ser personales (dirigidos a una estacion en concre-
to) o dirigidos a toda la comunidad de radioaficionados. Debido al sistema
de verificacion de errores utilizado en radiopaqute, toda la informacion se
tranfiere teoricamente libre de ellos, es decir que, lo que un radioaficio-
nado teclea le llega intregro a la pantalla del ordenador del otro radioafi-
cionado al que esta conectado. Todos los datos se verifican antes de presen-
tarlos en la pantalla, y si se ha generado algun error en la transferencia,
se pide el reenvio autom tico de esos mismos datos. No se pierde nada puesto
que la reemision continua hasta recibirse los datos correctamente.
#01.a.- RESEAS HISTORICAS
En los EE UU fue en marzo de 1980 cuando la FCC aprobo la transmision
de caracteres ASCII via Radioaficion. Este hecho ocurrio ao y medio despues
de que los radioaficionados canadienses fueran autorizados a transmitir en
modo digital "radiopaquete", y que los canadienses hubiesen estado trabajando
en un protocolo de transmisiones para el mismo desde 1978.
En Vancouver, Doug Lockhart, VE7APU, habia desarrollado un dispositivo
al que bautizo como Terminal Node Controller (TNC). Experimento con un modem
hasta convertir caracteres ASCII en tonos modulados y, a continuacion, demo-
dularlos de nuevo a ASCCI. Doug creo tambien el llamado Vancouver Amateur
Digital Communications Group (VADGC) y denomino su TNC como el modelo VADCG.
Los radioaficionados de los EE UU comenzaron a experimentar con la
tarjeta VADCG hasta que en diciembre de 1980 un radioaficionado de San Fran-
cisco, Hank Magnuski, KA6M, instalo un repetidor digital usando una TNC que
el mismo habia desarrollado. Un grupo de radioaficionados, interesados en
la TNC de Hank, empezaron a trabajar juntos en otros desarrollos de radiopa-
quete formando, asi tambien, la Pacific Packet Radio Society (PPRS)
En la costa este de los EE UU, AMRAD, la Radio Research and Development
Corporation, en Washington (DC), se convirtio en el centro de las actividades
en radiopaquete para la costa este, y en 1982, un grupo de radioaficionados
en Tucson (Arizona) fundo la Tucson Amateur Packet Radio Corporation (TAPR).
Todos estos grupo, trabajando juntos, desarrollaron una version modifi-
cada del protocolo comercial llamado X.25, creando asi el AX.25 para Radio-
aficion (Amateur X.25). En noviembre de 1983, TAPR puso al alcance de los
radioaficionados la primera TCN en forma de kit, denominada TNC1.
Todo el desarrollo era seguido por radioaficionados del Radioclub IBM
Espaa, que recibian la informacion a traves de la seccion del mismo Radio-
club en Tucson (Arizona). En 1984 ya se habia realizado una gran cantidad de
experimentacion, se desarrollaron paquetes de programas para Bases de Datos
de Radiopaquete, y el nuevo modo en radioaficion comenzo a tomar auge en los
Estados Unidos y Canada, y como no, entre los radioaficionados de Espaa, los
cuales esperaron la salida del kit de la nueva TNC2 de TAPR, y con ella ya
dispusieron de todo lo necesario para montar un BBS. Se uso para ello las
TNC montadas en Valencia y los posteriores desarrollados por los mismos
radioaficionados valencianos, la TNC RadiPack-2000, junto con el software
para el BBS de WA7MBL y de AA4RE, este ultimo tambien compaero de IBM (USA).
En Valencia se creo el Valencia Digital Radio club.
Es evidente que en los primeros experimentos en radiopaquete intervinie-
ron radioaficionados de los Radioclules de IBM Vancouver y de IBM Tucson.
El radiopaquete ha sido uno de los logros mas importantes en radioafi-
cion en todo el mundo. Miles de radioaficionados se "engancharon" al "pica-
piones del radiopaquete", lo que creo una gran inquietud sobre nuevas
tecnologias y comunicaciones digitales en todo el mundo de la radioaficion.
Y todo ello varios aos antes del auge de Internet.
#02.- EL MODELO OSI
A fin de evitar una desbandada, la normalizacion debe ser la primera
disciplina a aplicar en nuestro mundo tecnologico.
Tomemos el ejemplo de una cadena estereo, cu ntas veces le ha ocurrido
no poder conectar un cassete a la instalacion de un amigo porque los conec-
tores no eran compatibles?
La normalizacion puede tambien subdividirse en varios aspectos:
* El aspecto mecanico (la forma mec nica de los conectores por ejemplo).
* El aspecto electrico (los niveles de las tensiones presentes en los bornes de un conector).
* el protocolo (la descripcion del di logo entre una maquina y un apara-to asociado).
En inform tica, la International Organization for Standarization (ISO)
ha tenido como mision normalizar las comunicaciones entre ordenadores.
El fruto de su trabajo se concreto en 1984 en la proposicion de un "MODELO
DE REFERENCIA": Open Systems Interconnection Reference Model (OSI-RM).
El modelo consiste en una jerarquia de siete capas; la primera represen-
ta el nivel mas bajo y la septima la de nivel mas elevado. Cada capa no puede
comunicar mas que con una capa que este por encima o por debajo suyo.
Algunas porciones del OSI-RM han sido utilizadas para la normalizacion
del interface con la red publica de datos mediante conmutacion de paquetes.
Esta norma o protocolo se denomina Recomendacion CCITT X.25 y es la base de
la norma AX.25 (Amateur X.25) usada en radiopacket de aficionado.
El modelo de referencia OSI es un armazon alrededor del cual debe ser
concebido el protocolo de comunicacion. Sus 7 capas son las siguientes:
* La primera capa o CAPA FiSICA esta compuesta por todo lo que afecta fisica-
mente (tanto desde el punto de vista mecanico como desde el punto de vista
electrico) al flujo de bits de un lugar hacia otro.
Por ejemplo, la Electronic Industries Association (EIA) ha formulado una
norma para la conexion entre un equipo terminal de tratamiento de datos
(Data Terminal Equipment o DTE - por ejemplo un ordenador o un terminal) y
un equipo de finalizacion de circuito de datos (Data Circuit-terminating
Equipment o DCE - por ejemplo un modem).
Esta norma esta definida por el documento EIA-232-D, sucesor de la famosa
norma EIA RS-232-C, y se le denomina mas comunmente norma RS-232.
Esta norma indica como han de ser los conectores empleados, la funcion de
sus patillas de conexion, los niveles de seal que han de transmitirse por
estas patillas, etc... Como se puede ver, es una norma de capa uno o capa
fisica.
* La segunda capa o CAPA DE ENLACE tiene como objeto colocar los datos en
tramas (paquetes de bits) y proporcionar una transferencia exenta de
errores. Se aaden a esta trama informaciones de direcciones del expedidor
y del destinatario (quien la envia y a quien va dirigida).
Se calcula un codigo ("Cyclic Redundancy Check" o CRC) para cada trama, a
partir de los bits que la constituyen, y que es incorporado en la propia
trama, y este codigo es verificado por la estacion destinataria (lo recal-
cula a partir de los bits correspondientes de la trama recibida) con el codigo de la estacion expedidora (incorporado en la propia trama).
Si no hay concordancia la trama es rechazada (pues la trama tiene errores
de bits).
El procedimiento HDLC (High-level Data Link Control, Control de Enlace de
Datos de Alto Nivel) del ISO ha sido adoptado como protocolo de nivel 2.
Es un protocolo "orientado a bit", define la manera de encapsular informa-
ciones en una trama y como aadirle un CRC (prevencion de errores) y un
"FLAG" o bandera (grupo de bits muy concreto que se colocan al inicio y al
final de una trama para delimitar inequivocamente a esta), para su correcta
transmision por las redes de datos X.25 .
El procedimiento y la codificacion estan descritos en las Normas ISO 3309
e ISO7809. En protocolo de red AX.25 usaddo en packet se utiliza una modi-
ficacion del HDLC.
* La tercera capa o CAPA DE RED, concierne a la ruta de las tramas a traves
de una red de datos. Esto se obtiene gracias a aadir informacion de ruta
en cada trama. Este nivel afecta, pues, a todo lo concerniente al encamina-
miento de las tramas hacia el destino correspondiente a traves de las redes
de datos mediante conmutacion de paquetes.
Existen dos aproximaciones diferentes para el encaminamiento de datos a traves de una red de datos:
* la "CONEXIoN VIRTUAL", que establece primero un circuito especifico y lo
mantiene activo durante toda la duracion de la transferencia de informa-
ciones entre la fuente y el destinatario. Una vez establecido el circuito
virtual, ya no es necesario transmitir las informaciones concernientes a
la ruta. Todas las tramas se van a transmitir a traves de ese circuito
virtual a traves de la red de datos, que une al expedidor de las tramas
con el receptor de estas.
Los circuitos establecidos son virtuales, ya que el camino entre el origen
y el destino de los paquetes de datos esta determinado por la informacion
de ruta que se aaden a estos, que ser la misma para una misma conexion.
Son circuitos de tipo logicos (CANALES LOGICOS), un mismo camino fisico
entre dos puntos de la red puede soportar dos o mas conexiones virtuales,
cada una independiente de las otras.
* El protocolo del tipo "DATAGRAMA": transfiere cada packet independiente-
mente segun la ruta de mejor calidad. Cada packet contiene las informacio-
nes completas de direccion y de rutas. Los distintos paquetes pueden
seguir distintas rutas o caminos, segun las circunstancias, pero todos han
de llegar al mismo destino. A estos paquetes se denominan "datagramas".
* La mision de la cuarta capa o CAPA DE TRANSPORTE es la de mantener una
conexion asegurando que los datos sean encaminados de la fuente hacia el
destinatario.
* La quinta capa o CAPA DE SESIoN, gestiona el "log-on" (contraseas de acce-
so) y la autentificacion de usuario. Establece di logos de control.
* La sexta capa o CAPA DE PRESENTACIoN proporciona el medio de traducir o
de interpretar los datos intercambiados entre los usuarios.
* La septima capa o CAPA DE APLICACIoN proporciona el interface entre el
modelo de referencia y la aplicacion del usuario: Los datos procedentes de
la capa anterior son usados por el usuario para su aplicacion concreta.
Cada nivel o capa puede comunicarse con la inmediatamente superior o inferior a ella.
En una comunicacion de datos entre dos usuarios, si falla una de las
capas, la comunicacion es imposible.
Cada capa se comunica con la otra del mismo nivel de otro usuario usando
un protocolo de capa, que es un conjunto de reglas que sirven para establecer
estas comunicaciones. Existen protocolos para cada capa (protocolos de nivel
1, de nivel 2, etc...).
Resumido todo esto seria lo siguiente:
Capa OSI Funcion
--------- --------------------------------------
7- Aplicacion Uso de datos normalizados.
6- Presentacion Interpretacion de datos.
5- Sesion Establecimiento de di logos de control.
4- Transporte Asegura la integridad de los mensajes.
3- Red Encamina los mensajes hacia su destino.
2- Enlace Detecta errores y prepara los mensajes para su envio.
1- Fisico Conecta equipos a la red de transmision.
usuario que envia usuario que recibe
----------------- -------------------
aplicacion (uso) aplicacion (uso)
capa 6 <- - protocolos nivel 6 - -> capa 6 A
capa 5 <- - protocolos nivel 5 - -> capa 5
capa 4 <- - protocolos nivel 4 - -> capa 4
capa 3 <- - protocolos nivel 3 - -> capa 3
capa 2 <- - protocolos nivel 2 - -> capa 2
capa 1 <- - protocolos nivel 1 - -> capa 1
>> enlace fisico >>
Haciendo una analogia sencilla, si la comunicacion entre dos usuarios
fuera por correo ordinario, los distintos niveles del modelo OSI vendrian a
significar lo siguiente:
Capa OSI Representa
--------- -----------------------------------------------
7- Aplicacion Informacion, contenido o mensaje de la carta.
6- Presentacion Carta escrita.
5- Sesion Sobre donde va la carta.
4- Transporte Paquete de sobres.
3- Red Saca de correos.
2- Enlace Camion de correos, tren, avion...
1- Fisico Carreteras, vias de ferrocarril, ....
Otro ejemplo mas tecnico y mas real: La aplicacion es gobernar disposi-
tivos a distancia:
Capa OSI Representa: en emisor / en receptor
--------- -----------------------------------------------
7- Aplicacion Pulsar un boton o tecla / activar un rele.
6- Presentacion Generar un codigo de control /recibir este codigo
de control.
5- Sesion Codificacion / decodificacion adecuada de los codigos
de control.
4- Transporte Aadir informacion adicional a los datos procedentes
del nivel 5 / extraer informacion para el nivel 5.
3- Red Empaquetar adecuadamente la informacion / desempaque-
tarla.
2- Enlace Preparar la informacion para su envio real por el
nivel 1 / Extraerla del nivel 1.
1- Fisico Circuitos y aparatos telefonicos, de datos, etc..
por donde se enviar la informacion.
Cuando se habla de protocolo AX.25 nivel 2 significa que la capa 2 (la
capa de enlace) esta definida.
Actualmente, en Packet radio la capa 2 esta definida perfectamente, las
capas 3 y 4 se encuentran en plena experimentacion con los Net/Rom, TheNet,
TexNet, TCP/IP y otros softwares de radiopaquete digital.
#03.- AX.25, EL PROTOCOLO DE LA CAPA DE ENLACE
El AX.25 Amateur Packet Radio Link Layer Protocol, Version 2.0, fue
adoptado por la ARRL en octubre de 1984 , este protocolo fue descrito por
Terry Fox WB4JFI, uno de los gurus de la AMRAD. El AX.25 es una adaptacion
del protocolo X.25 de la CCITT (usado en las modernas redes de datos) al
mbito del radioaficionado.
El protocolo AX.25 fue reconocido tambien por la mayoria de las adminis-
traciones encargadas de controlar el servicio de aficionados, en una palabra,
esta reconocido a traves del mundo como "el protocolo st ndard de packet
radio" (radiopaquete digital).
Tal y como esta definido, el AX.25 funciona tanto en semi-duplex como
en full-duplex. El AX.25 autoriza las conexiones multiples y la conexion
consigo mismo.
#03.a.- LAS TRAMAS Y LOS CAMPOS AX.25
Una transmision AX.25 se compone de pequeos "bloques" de bits, denomi-
nados "TRAMAS" ("FRAMES" en ingles). Una trama esta a su vez dividida en
elementos mas pequeos llamados "CAMPOS" (grupos de bits bien definidos).
La transmision de mensajes e informaciones por AX.25 se consigue median-
te el "empaquetado" de los bits que componen el mensaje a transmitir, esto
es, la informacion es adecuadamente fracionada en tramas de bits de informa-
cion, las cuales, transmitidos en el orden correcto, transmitir n al usuario
de destino toda la informacion: El receptor ha de recibir las tramas digita-
les en el orden correcto para poder extraer y reconstruir la informacion
enviada. Ello va a llevar como consecuencia numerar las tramas enviadas, para
facilitar al usuario destino esta reconstruccion.
Estas tramas digitales incluyen, cuando se construyen (en el terminal
de datos del usuario transmisor), ademas de las informaciones de usuario que
se desean enviar, otras informaciones, tales como la identidad del usuario
que la envia, y la identidad del usuario a quien va dirigida, y en segun que
tramas, datos para el establecimiento de la comunicacion (en lugar de infor-
maciones de usuario).
Muchas veces el nombre de tramas es confundido con el de paquetes. Un
PAQUETE (PACKET) puede estar constituido por una o varias tramas enviadas
todas juntas en la misma transmision. Cuando solo se envia una, trama y
paquete es lo mismo.
Para poder enviar estos paquetes digitales de informacion es necesario
establecer un enlace entre los equipos de datos implicados, que en el caso
del radiopaquete digital son los ordenadores que entran en juego, siendo el
enlace de conexion via radio. Ademas, una vez conectados, se ha de mantener
la conexion y controlar el flujo del transvase de informacion entre los ter-
minales de datos. Ello se consigue haciendo uso de la recomendacion X.25 ,
normalizada para las redes de datos, y adaptada para el trabajo en radiopa-
quete digital con la denominacion AX.25 (Amateur X.25).
En X.25 el nivel de enlace es controlado mediante el intercambio de las
tramas, algunas de las cuales se usan para el envio de las informaciones de
usuario, haciendo que estas formen parte de las tramas. Ademas incluyen
informaciones para detectar posibles errores que puedan darse durante la
transmision de la trama, errores que provocarian el falseamiento o la no
recepcion de la informacion de usuario transmitida.
Existen cuatro tipos de tramas:
* las tramas de informaciones o tramas I, contienen las informaciones enviadas de una estacion hacia otra (textos, mensajes....).
* las tramas de supervision o de control o tramas S, realizan el control
del intercambio de las tramas I, por ejemplo acuse de recepcion de una
trama del tipo I o solicitud de repeticion de la transmision de esta.
* las tramas no numeradas o tramas U, que se usan para el establecimiento
y mantenimiento de las comunicaciones por packet.
* las tramas de informacion no numeradas UI, para transmisiones de infor-
maciones sin estar conectado. Son tramas admitidas en el AX.25, pero que no esta n definidas en el X.25 usado en las redes de datos.
Cada trama comprende un campo bandera o flag, un campo de direcciones,
un campo de control, un campo de informacion, un campo FCR y un campo con la
bandera o flag final.
Ŀ
FLAG DIRECC CONTROL INFORM FCS FLAG
8 112-560 8 o 16 N 16 8
El numero indica el numero de bits que constituye cada campo de la
trama. Los distintos campos son los siguientes:
* FLAG o bandera: Establece el inicio y el fin de cada trama. Son 8 bits
cuyo valor es 01111110 (7E en hexadecimal). Esta secuencia de bits no debe
encontrarse en ningun otro campo de la trama, pues el receptor distante
interpretaria que recibe un FLAG. Si en algun otro campo debiera de trans-
mitirse esta secuencia, el sistema usa un procedimiento por el cual inserta
un bit 0 extra cada vez que detectara cinco unos consecutivos. El lado
receptor, al procesar la trama de enlace, suprimir cualquier cero que siga
a cinco unos consecutivos.
Este procedimiento se denomina de "insercion de cero" o de "bit stuffing",
y es realizado por el protocolo HDLC de nivel 2.
Cuando en una transmision de packet se envian dos o mas tramas seguidas,
una misma bandera puede servir para marcar el final de una trama y el
inicio de la siguiente: La bandera esta compartida entre dos tramas suce-
sivas.
* DIRECC: Direccion, es un campo que contiene el indicativo de la fuente y
del destinatario de la trama. Puede tambien contener el indicativo de uno
de los 8 "digipeaters" o repetidores digitales (segun AX.25 version 2) a
traves de los cuales se puede encaminar la trama hacia su destino.
La longitud del campo de direccion varia, pues, de 14 a 70 octetos (112 a
560 bits).
Los 7 primeros octetos del campo de direcciones contienen el indicativo y
el "SSID" del destinatario.
El indicativo tendrapues un maximo de 6 caracteres, su codificacion se
hace sobre 7 bits, siendo siempre el octavo bit de cada car cter un 0,
excepto para el ultimo indicativo mencionado en el campo de direccion.
El SSID permite utilizar el mismo indicativo varias veces. Para el octeto
que contiene el SSID:
* el primer bit, llamado "H", es 0 si se trata del expedidor o del desti-
natario. En el caso de indicativos de repetidores, es 1 si la trama ha
sido ya repetida por un digipeater y 0 en caso contrario.
* los bits 2 y 3 se denominan "R" y esta n reservados a un uso local o
futuro.
* los bits 4 a 7 esta n reservados al SSID propiamente dicho, por lo que
puede tomar todos los valores comprendidos entre 0 y 15.
* el bit 8 llamado bit de extension es siempre 0 excepto si se trata del
ultimo indicativo (fuente o repetidor) mencionado en el campo de direc-
cion.
Los octetos 8 a 14 contienen el indicativo y el SSID del que ha transmitido
la trama (fuente).
Los octetos 15 a 70 son facultativos y llevan pues los indicativos y los
SSID de los diferentes digipeaters que retransmitan la trama.
El SSID es el denominado "Identificador Secundario de estacion" (Secondary
Station Identifier) y se usa para identificar que tipo de estacion de
packet se trata, y por tanto, que tipos de servicios puede prestar.
Como se ha indicado, su valor puede ser desde 0 a 15. Se aade a los indi-
cativos de las estaciones de packet que intervienen en la comunicacion, en
el campo de direccion de las tramas, y actualmente se usan o recomiendan
los siguientes SSID:
* 0 : Usuarios normales (usuarios terminales) conectados via radio.
* 1 : Digipeaters y nodos en VHF.
* 2 : Buzones: BBS + PMS.
* 3 : "Gateways".
* 4 : Usuarios conectados mediante protocolo TCP/IP (Internet)
* 5 : "Clusters".
* 7 : Digipeaters y nodos en UHF.
* 8 : PMS (de usuario terminal, para forward).
* 9 : Estaciones a 9600 baudios.
* 10 : Estaciones en 10 metros.
* 12 : Estaciones en 1200 MHz.
Puesto que el SSID permite usar un mismo indicativo varias veces, es
posible con esto que con un solo indicativo y con equipos separados o
multitareas ofrecer Multi-Conexion o diferentes servicios (segun los SSID
utilizados).
* CONTROL : Identifica el tipo de trama y numeros de secuencias de envio, y
tiene el tamao habitual de un byte u octeto (8 bits).
En las tramas de informacion I e IU, este campo incluye el denominado PID
("Protocol IDentifier" o Identificador de protocolo) el cual indica que
nivel se esta usando de AX.25, que tipo de red se esta usando. Lo habitual
es el nivel tres, que es el mas moderno. El PID es el segundo byte del
campo de control en estas tramas.
Asi este byte siempre estar con el valor hexadecimal F0, esto sirve para
que la TNC de la estacion de packet avise de que cambie el nivel caso de
recibir a alguien en nivel dos; esto es rarisimo de que ocurra, ya que todo
el mundo esta usando el nivel tres.
Los valores de PID utilizados mas comunmente son:
* trafico packet radio normal AX.25 nivel 3 version 2 : F0
* Net/Rom y TheNet : CF
* TCP/IP : CC y CD
* INFORM : Informacion de usuario (fragmento). Solo en las tramas I y UI, en
un grupo de hasta 255 caracteres, donde va parte de la informacion enviada
por el usuario (un fragmento de esta). En la practica no es recomendable
trabajar con el maximo de los 255 caracteres, sino con menos, ya que si el
paquete es muy largo tambien hay mas posibilidades de que se reciba algun
error y se rechace la trama.
* FCS : ("Frame Check Sequence"), bits para la deteccion de errores en la
trama: Son 16 bits (dos octetos) que se calculan mediante la aplicacion de
un codigo polinomico al resto de los bits de la trama: Es una suma de
control conocida como CRC (Codigo de Redundancia Ciclica).
El lado receptor elabora el CRC de la trama que recibe a partir de los bits
que esta contiene, usando el mismo procedimiento que el transmisor, y por
tanto ha de coincidir con el CRC que figura en el campo FCS de la trama si
esta no tiene ningun error.
Si la trama recibida es correcta, el lado receptor lo confirmar al lado
transmisor. Si hay algun tipo de error (error de CRC, error en la secuencia
de envio de trama), no se confirmar la trama recibida y el transmisor
volver a retransmitir la trama no confirmada.
El c lculo de los 16 bits del FCS se realiza segun la Recomendacion
ISO 3309. De hecho se toma el numero binario formado por todos los bits
enviados, se divide por:
x^16 + x^15 + x^2 + 1
o sea, por: 1100 000 000 0101
y el resto de la division proporciona el numero que ser utilizado como
FCS.
El paquete acaba con otra bandera como al principio. Otro sistema de
deteccion de error va en los caracteres, todos estan formados por cuatro unos
y tres ceros, excepto las banderas de principio y fin de paquete:
Con esto el receptor sabe que nunca se puede encontrar un numero superior de
unos y, naturalmente, tambien es causa de error en el paquete.
Los bits del campo de control identifican el tipo de trama, asi como
secuencias de envio y otros datos:
bit ---> 1 2 3 4 5 6 7 8 9-16
----------------------------------------------------
Tramas I 0 ---NS---- P ---NR----- PID
Tramas S 1 0 M M P/F ---NR----- (no hay)
Tramas U 1 1 M M P/F M M M (no hay)
Tramas UI 1 1 0 0 P/F 0 0 0 PID
tipo de : : bit
trama : : 1 2 3 4 5 6 7 8
---------:------------------------:-------------------------
trama I : : 0 ---NS-- P --NR---
---------:------------------:-----:-------------------------
trama S : receiver ready : RR : 1 0 0 0 P/F ---NR-
: receiver not ready RNR : 1 0 1 0 P/F ---NR-
: reject : REJ : 1 0 0 1 P/F ---NR-
---------:------------------:-----:-------------------------
trama U : set SABM mode : SABM: 1 1 1 1 P 1 0 0
: disconnect : DISC: 1 1 0 0 P 0 1 0
: disconnected : DM : 1 1 1 1 F 0 0 0
: unnumbered ack : UA : 1 1 0 0 F 1 1 0
: frame reject : FRMR: 1 1 1 0 F 0 0 1
: unnumbered info : UI : 1 1 0 0 P/F 0 0 0
TRAMAS DE INFORMACION
- - - - - - - - - - - -
Cada trama que contenga informacion (tramas I) va numerada del cero
al siete, y este numero es el numero de orden de envio de la correspondiente
trama I. Cuando llega al siete vuelve al cero. Este numero se aade en el
campo de control de la trama, y son los bits NS indicados en el campo de
control de la anterior tabla, y el receptor ha de dar conformidad a cada
numero que le llega. Es necesario que las tramas I se reciban en el orden
correcto para la correcta reconstruccion en el receptor del mensaje transmi-
tido, ya que este requerir normalmente varias tramas I para ser transmitido
totalmente (a razon de un maximo de 255 bits por trama I).
Esta confirmacion se envia tambien en el campo de control de las tramas
I, enviando la estacion receptora tramas en cuyo campo de control se indica
cual es la siguiente trama I que espera recibir: Este numero esta dado por
los bits NR de la anterior tabla, y sus valores tambien van de 0 a 7 (3
bits). Si este numero es, p.ej, el 5, significa que la estacion receptora ha
confirmado hasta la trama I numero 4, y por tanto espera la recepcion de la
numero 5.
Las tramas I envian en su campo de control su numero de orden de trans-
mision, y la confirmacion de las tramas I recibidas (indicando el numero de
la trama I que esta n a la espera de recibir) por lo que sirven para enviar
informacion y confirmar a su vez al lado distante de las tramas I que este
le haya enviado, y que ha recibido correctamente.
En definitiva:
* NS indica el numero de secuencia en emision, es decir el numero de la trama I que se transmite.
* NR indica el numero de secuencia en recepcion, es decir, el que espera
recibir. Gracias a este numero se sabe que el receptor ha recibido
correctamente todas las tramas I hasta la numero NR-1.
NR y NS son dos informaciones incluidas en las tramas I para lo que se
denomina "CONTROL DE FLUJO" en el envio de la informacion. Un control de flujo
en un sistema de intercambio de informacion es el conjunto de mecanismos que
dispone dicho sistema para que la informacion transmitida se reciba en el
destino en el orden correcto y sin errores.
Una cosa muy importante del X.25, y de su adaptacion para los radioafi-
cionados, AX.25, es que toda trama de informacion enviada ha de ser confir-
mada por el extremo distante, antes de continuar con la secuencia de envio
de tramas I.
TRAMAS DE SUPERVISIoN S
- - - - - - - - - - - -
Si uno de los dos lados no envia tramas I, las confirmaciones se reali-
zan a traves de las tramas de supervision S, las cuales en su campo de
control solo se indica la confirmacion de las tramas recibidas (bits NR),
asi como el tipo de trama S que es. Estas tramas no esta n numeradas (no
tienen numero de orden de envio, NS) y se utilizan para el control del inter-
cambio de las tramas I entre ambas estaciones de packet. Por ello hay tres
tipos de tramas S, que se denominan:
* Tramas RR (Reception Ready), que se usan para indicar al corresponsal que
el equipo esta preparado para recibir tramas I, confirmar las tramas
recibidas I (y que por tanto puede seguir enviando nuevas tramas) y para
mantener el canal ocupado cuando no hay intercambio moment neo de tramas
I.
* Tramas REJ (Reject), o de rechazo, indican que el orden de las tramas
recibidas no es el correcto , y han sido rechazadas por el receptor.
Como es normal, confirma hasta que trama ha recibido correctamente indi-
cando cual es el numero (NR) de la proxima que espera. La recepcion de
tramas REJ obliga a retransmitir de nuevo las tramas rechazadas o no
reconocidas por la otra estacion. Las REJ se envian cuando p.ej, la esta-
cion no ha recibido alguna de las tramas I por haber sido interferida por
la transmision simultanea de otra estacion de packet en el mismo canal.
Un numero elevado de tramas REJ sucesivas puede provocar que una de las
estaciones provoque la desconexion de la comunicacion.
* Tramas NRN (Reception no ready) o de no transmision. Con este tipo de
trama se indica al corresponsal que aunque ha recibido todas sus tramas I
correctamente, no envie moment neamente mas tramas I hasta que se lo indi-
que enviando de nuevo una trama RR. Esto puede ser debido, p.ej, porque
la estacion tiene los buffers de recepcion congestionados y no podria
almacenar las nuevas tramas I que siguiera recibiendo.
Los bits 3 y 4 del campo de control de la trama informan del tipo de esta:
MM = 00 --> Trama RR
MM = 01 --> Trama REJ
MM = 10 --> Trama RNR
TRAMAS NO NUMERADAS U
- - - - - - - - - - - -
La utilizacion de las tramas de informaciones no numeradas (U) es para
el establecimiento y mantenimiento del canal logico entre las dos estaciones
de packet, no tienen numero de orden ni confirman tramas I recibidas, y son
de 5 tipos:
* Trama SABM (Set Asynchronous Balanced Mode), indica al equipo distante la
peticion de establecer una conexion entre las dos estaciones de packet.
La estacion destinataria puede responder con una trama UA o una DM.
* Trama DISC (disconected), se enviar cuando una de las estaciones desee
desconectarse y finalizar la conexion logica. La otra estacion deber
responder con una UA.
* Trama UA (Unnumbered ACK), UA, se envia como respuesta afirmativa a una
trama S del tipo SABM, indicando con ello que la conexion es realizable
y queda establecida), y como respuesta afirmativa a una DISC, dando lugar
a la desconexion del enlace logico.
* Trama DM (Disconnect Mode Response), se envia como respuesta negativa a
una trama del tipo SABM, cuando la conexion no es realizable (estacion
ocupada), y como indicacion de canal logico en situacion de "desconecta-
do". Tambien se envia como respuesta negativa a una DISC, en lugar de una
UA.
* Trama FRMR (Frame Reject), se envia cuando la estacion es incapaz de
tratar la informacion y la reexpedicion de una nueva trama no arregla las
cosas. Este tipo de trama tiene en el campo de informaciones 3 octetos
que especifican la naturaleza del error. El envio de esta trama est
indicando que se reciben tramas bien construidas, pero cuyo contenido
esta alterado o tiene datos ilogicos, puede ocurrir que el canal de comu-
nicacion tenga muchos ruidos e imposibilite al lado receptor leer correc-
tamente las tramas recibidas.... Se envia cuando se han recibido, por
ejemplo, varias tramas REJ sucesivas.
Es muy raro ver este tipo de trama, y suele dar lugar al envio de una
trama DISC, para desconectar la comunicacion.
Los bits M del campo de control de la trama (bits 3,4,6,7,8) informan
del tipo de trama U concreto:
SAMB ---> MM MMM= 11 100
DISC ---> MM MMM= 00 010
UA ---> MM MMM= 00 110
DM ---> MM MMM= 11 000
FRMR ---> MM MMM= 10 001
TRAMAS DE INFORMACIoN NO NUMERADAS UI
- - - - - - - - - - - - - - - - - - -
Las tramas no numeradas del tipo Unnumbered Information (UI) permiten
enviar informaciones sin que este establecida la conexion entre estaciones
(envios de informacion en "MODO NO CONECTADO").
Estas tramas permiten la posibilidad de mandar textos sin estar conec-
tados con nadie, y por lo tanto sin que deban ser confirmadas, como es el
caso de las balizas de las estaciones de packet, el UNPROTO... Pero al no
existir una conexion entre estaciones, no hay mecanismos de control y correc-
cion de errores ni secuencias de envio de tramas, por lo que no se puede dar
ninguna garantia sobre la validez de las tramas UI recibidas.
UNPROTO es la denominacion inglesa abreviada de "sin protocolo", ya que
este tipo de tramas carecen de protocolo (y de hecho no son tramas de proto-
colo X.25): no esta n numeradas ni dirigidas a nadie concreto, lo que transmi-
timos por este sistema sale al aire con nuestro indicativo y el texto, son
tramas de informacion, pero el que no lo reciba a la primera lo pierde.
Por tanto el metodo de enviar una informacion sin existir conexion de
nivel 2 (sin haber enviado y recibido confirmacion de un SABM), a traves de
tramas UI, es el que se conoce como UNPROTO.
El modo UNPROTO es la forma en que el protocolo AX.25 envia informacion
sin numero de paquete. Este es el metodo que utilizan los BBS's de packet
para enviar el listado FBB de las cabeceras de los mensajes que esta n activos
en el BBS. Es, pues, una forma de enviar informacion en "MODO DIFUSION" o
"BROADCASTING" (esto es, con destino a todo el que reciba la trama).
Los BBS's de packet son las estaciones encargadas de guardar y difundir
boletines y mensajes entre usuarios, y para no conectarnos a ellas, podemos
extraer informacion del listado de boletines del BBS gracias al procedimien-
to UNPROTO:
Los BBS's difunden periodicamente el listado de los mensajes activos
que contiene. Para difundir este listado periodicamente, usa las tramas UI,
mediante el metodo UNPROTO, lo cual implica el envio de informacion (en este
caso, el listado de mensajes activos del BBS con sus cabeceras) sin que haya
una conexion al BBS de alguien que solicite esta informacion. Algunos progra-
mas de Packet tienen la opcion de recoger el listado de UNPROTO, por lo que
pueden hacerse con el listado de boletines activos del BBS sin necesidad de
conectarse a esta para pedir el listado (solo monitorizando el trafico del
BBS).
TRAMAS EN MODO COMANDO Y TRAMAS EN MODO RESPUESTA
- - - - - - - - - - - - - - - - - - - - - - - - - -
Las tramas enviadas pueden tener la consideracion de comando o de res-
puesta. Siempre que se envie una trama de tipo comando, ha de ser contestada
por una trama de modo respuesta consecuente.
* Las tramas de informacion son siempre tramas comando.
* Las tramas de supervision pueden ser comando o respuesta.
Entre las tramas no numeradas:
* SABM, DISC son solo tramas de comando.
* UA, DM y FMRmason solo tramas de respuesta.
El bit que es sealado como P/F en algunas tramas es el denominado bit P
("POLL" o de "sondeo") si se trata de una trama comando, o bit F ("Final" o
de "terminacion") si se trata de una trama respuesta.
#03.b.- COMO FUNCIONA UNA UNION AX.25 ?
Supongamos que el trabajo se realiza con una TNC de packet TNC2 de TAPR,
o un equipo compatible (por los comandos que se indiquen).
Supongamos que el radioaficionado con indicativo ON5AV desea contactar
con ON1KAN; ON5AV prepara su estacion de packet para iniciar la conexion.
Para hacer esto, ON5AV comienza por poner su TNC en "modo comando" (teclean-
do CONTROL C y retorno de carro, CTRL C <CR> ), para que este interprete los
comandos que ON5AV va a enviar desde el teclado del terminal (normalmente un
ordenador). Ahora la TNC enviar al terminal una indicacion de que ya est
en modo comando (presentar la palabra :cmd en la pantalla del terminal),
y queda a la espera de un comando por parte del operador.
ON5AV enviar entonces la orden de establecer la conexion con ON1KAN o sea:
CONNECT ON1KAN (o comando similar en otras TNC's), seguido de <CR> .
La TNC de ON5AV va a construir una trama con ON5AV-0 como indicativo de
origen, y con ON1KAN-0 como destinatario, siendo el campo de control del tipo
SABM. Y esta trama va a ser enviada, a traves del conector de microfono, al
emisor de radio y transmitida "on the air" a ON1KAN. Al mismo tiempo, arranca
un temporizador llamado eacknoledgement timer T1e en el programa que usa la
TNC.
La trama enviada puede ser monitorizada en el terminal de ON5AV, y se
presentar de la siguiente manera (o similar):
ON5AV>ON1KAN,SABM (Origen > Destino, tipo de trama)
Si ON1KAN-0 esta operativo, y es capaz de recibir la peticion de cone-
xion de ON5AV, la TNC de ON1KAN responder a la peticion de conexion de ON5AV
enviando una trama UA:
ON1KAN>ON5AV,UA
y la TNC de ON5AV presentar en la pantalla:
** Connected to ON1KAN. (conectado a ON1KAN).
Si ON1KAN-0 esta ocupado y no puede aceptar una peticion de conexion,
su TNC generar una trama DM que se enviar a ON1AV:
ON1KAN>ON5AV,DM
y al recibirla la TNC de ON5AV har presentar en pantalla:
** ON1KAN busy (ON1KAN ocupado)
y despues: ** Disconnected. (Desconectado)
Si no se recibe ninguna respuesta, la TNC de ON5AV continua enviando
SABMes hasta el momento que el tiempo T1 establecido por el temporizador
citado anteriormente llegue a su fin, entonces la TNC de ON5AV presentar
en la pantalla:
*** retry count exceeded (numero de tentativas excedido)
seguido de: ** Disconnected. (Desconectado).
Pero supongamos que la conexion sea posible, ON5AV puede entonces
enviar informaciones hacia ON1KAN, informaciones que ser n eencapsuladase
en tramas de tipo I, y cada vez que se reciba la confirmacion de cada trama
enviada el timer T1 ser puesto a cero. El protocolo AX.25 prevee que se
pueda transmitir como maximo 7 tramas antes de recibir un acuse de recibo
(este numero de tramas sin confirmar puede establecerse por comando entre 1
y 7).
Si el destinatario ON1KAN recibe las tramas I en el orden correcto y sin
errores (el control del FCS es positivo), ON1KAN envia un acuse de recibo.
Una secuencia de envio podria ser la siguiente:
ON5AV>ON1KAN,I11,infoav1
ON5AV>ON1KAN,I21,infoav2
ON5AV>ON1KAN,I31,infoav3
ON1KAN>ON5AV,I14,infokan1
ON1KAN>ON5AV,I24,infokan2
ON1KAN>ON5AV,I34,infokan3
donde los dos numeros tras la indicacion de la trama I significan respectiva-
mente el numero de orden de la trama enviada, y el numero de orden de la
trama que se espera recibir desde el otro extremo: En las tres primeras
lineas, ON5AV ha enviado tres tramas I a ON1KAN, mientras indica que aun no
ha recibido niguna de ON1KAN (pendiente de recibir su primera trama). En las
tres ultimas lineas ON1KAN transmite tres tramas a ON5AV, confirm ndole la
recepcion de las tres que le envio (indica espera de recibir la cuarta trama
de ON5AV). ON5AV ha enviado a ON1KAN el mensaje <infoav1 infoav2 infoav3>
y ON1KAN le ha enviado a ON1AV el mensaje <infokan1 infokan2 infokan3>.
Si no hay trama I para transmitir, enviar una trama RR (o eventualmente
RNR) con el acuse de recibo, pero si hay tramas I para transmitir podr
enviar el acuse de recibo en el interior de estas tramas I. Ejemplo:
ON5AV>ON1KAN,I11,infoav1
ON5AV>ON1KAN,I21,infoav2
ON5AV>ON1KAN,I31,infoav3
ON1KAN>ON5AV,RR4,F
ON5AV>ON1KAN,I41,infoav4
ON1KAN>ON5AV,RR5,F
(Recuerdese que las tramas S no tienen numero de envio, solo confirman).
(F en las tramas RR indican que estas esta n operando como tramas en modo
respuesta, las tramas I son tramas en modo comando).
Si el destinatario recibe tramas en un orden diferente al que se espera,
o no recibe alguna trama por algun motivo, enviar una trama del tipo REJ,
que obligar al origen a retransmitir de nuevo tramas enviadas.
Ejemplo:
ON5AV>ON1KAN,I11,infoav1
ON5AV>ON1KAN,I21,infoav2
ON5AV>ON1KAN,I31,infoav3
ON1KAN>ON5AV,REJ2,F (solo trama 1 correctamente recibida)
ON5AV>ON1KAN,I21,infoav2
ON5AV>ON1KAN,I31,infoav3
ON1KAN>ON5AV,RR4,F
Si durante un cierto tiempo no se intercambian tramas I entre ambas
estaciones, ambas se van enviando periodicamente tramas RR para mantener la
comunicacion. Cada trama RR enviada por una estacion ha de ser contestada
por otra trama RR por la otra estacion. En el ejemplo anterior, tras el
envio de las tramas correspondientes, estarian transmitiendose ciclicamente
las siguientes tramas:
ON5AV>ON1KAN,RR1,P (RR en modo comando)
ON1KAN>ON5AV,RR4,F (RR en modo respuesta)
Si una trama no es v lida (porque el FCS calculado no corresponde al
FCS en la trama), ON1KAN no enviar REJ, ni RR ni RNR, en estas condiciones
la temporizacion T1 de la TNC de ON5AV finalizar y la TNC de ON5AV reenviar
las informaciones al cabo de cierto tiempo. Esta temporizacion con reenvio
de tramas indica que el lado distante no ha recibido las tramas enviadas (y
por tanto no confirma), o las tramas recibidas esta n mal construidas y no
las interpreta correctamente.
Una vez que ha finalizado el contacto entre ON5AV y ON1KAN, uno u otro
podr n romper la conexion. Supongamos que ON1KAN hace una demanda de desco-
nexion, su TNC genera una trama DISC, y coloca el timer T1 a cero.
La estacion que recibe un DISC reenvia un DM y vuelve al modo de desco-
nexion (queda el enlace definitivamente roto):
ON1KAN>ON5AV,DISC
ON5AV>ON1KAN,UA (o ON5AV>ON1KAN,DM )
Cuando la trama UA es recibida por la estacion que ha pedido la desco-
nexion, pone el timer T1 a 0 y vuelve al modo desconectado. Si no se recibe
ninguna respuesta antes del fin de T1, la estacion retransmite una trama
DISC hasta que obtenga una respuesta, o hasta que el numero de intentos
maximo se sobrepase, y entonces la estacion considera que la comunicacion
esta desconectada (desconexion forzada por no presencia de la otra estacion).
Asi funciona b sicamente el AX.25 (no es ex ctamente como se ha indicado
en los ejemplos, pero si muy similar).
#03.c.- EL PROTOCOLO DE VANCOUVER
Antes del AX.25, Doug Lockart (VE7APU) escribio un protocolo base sobre
el SDLC (Synchronous Data Link Control) de IBM.
Con este protocolo se iniciaron las primeras transmisiones de prueba de
Packet, en Canad en 1978, y la primera demostracion publica completa de un
sistema de Packet, realizada por el VADCG (Vancouver Amateur Digital Commu-
nications Group) ocurrio el 26 de Abril de 1980, en la Federacion de Radio-
aficionados de Canada (CARF), en New Westminster, British Columbia, Canad .
Analicemos rapidamente las diferencias esenciales que residen en el
campo de direcciones y el identificador de protocolo (PID).
El campo de direcciones no usa mas que 2 octetos y esta direccion se
calcula a partir de los 2 indicativos de la forma del FCS. Algunos encontra-
r n un fallo en el procedimiento. Segun Doug Lockhart, VE7APU, no es asi,
pues el radioaficionado tiene siempre la posibilidad de identificarse claramente en el campo de informacion.
En efecto, en CW, en fonia, en RTTY, en ATV, puede Ud. pasar su indica-
tivo en cada cambio, cada vez que Ud. toma el manipulador, el micro, el
teclado .. y por lo menos una vez cada 10 minutos (segun la reglamentacion
vigente en materia de radioaficionados) ! Con el protocolo V2, debe Ud.
hacer lo mismo, es decir, pasar su indicativo en el campo de informacion ...!
Ademas el protocolo de Vancouver no reconoce la posibilidad de poder
hacer retransmitir la trama por un digipeater, y no posee PID.
Es necesario conocer todo esto para hacer packet-radio, preguntar n
Uds.? No, pues puede Ud. hacer un QSO de packet, o contactar con los BBS
ignorando todo esto. Pero si quiere comprender realmente las indicaciones
SABM, RR, FRMR... proporcionadas por su TNC, comprender la influencia de
los par metros de la TNC, resolver los problemas eficazmente y quiz s parti-
cipar en el desarrollo del packet, entonces las nociones anteriores son
indispensables.
Conclusion: El aspecto m gico del packet radio se debe principalmente
al protocolo AX.25 y vale la pena molestarse un poco en conocerlo.
#04.- LA PUESTA EN FUNCIONAMIENTO DE UNA ESTACION DE PACKET-RADIO
Una estacion de packet radio de aficionado se puede subdividir en 3 partes:
* el equipo terminal.
* el equipo de packet (modem o TNC).
* y el equipo de radio.
La instalacion tipica de packet es del siguiente tipo:
V
Ŀ Ŀ Ŀ
TNC+MODEM >Ĵmicro EQUIPO
TERMINAL <> o <Ĵaltavoz DE
rs232 MODEM >ĴTX/RX RADIO Antena
Trataremos aqui la instalacion clasica con una TNC tipo TNC 2 de TAPR.
#04.a.- EL EQUIPO TERMINAL
Los terminales que se utilizan habitualmente son terminales u ordenado-
res que emulan la funcion terminal de datos alfanumerico. Han de incorporar
como minimo un teclado y un visualizador de datos (una pantalla, una impre-
sora..).
Generalmente se distinguen los equipos terminales de tratamiento de
datos (equipo inform tico, terminal u ordenador) y los equipos de terminacion
de circuito de datos (modem, etc ...).
Hay programas disponibles a fin de emular un terminal en un ordenador;
"emular" significa "que se le hace trabajar como...".
Sin embargo, la mayoria de estos programas al principio estuvieron
orientados para ser utilizados con lineas telefonicas y algunas funciones no
se podian utilizar logicamente en packet (formacion del numero de telefono a
marcar, etc..). Por otra parte, ciertas funciones especificas del trafico de
packet no estaban implementadas en estos programas. Ello obligo a desarrollar
programas terminales especificamente orientados al "packet radio".
El ordenador, trabajando como terminal, nos servir para ver en la pan-
talla los mensajes que nos envien, y para escribir los mensajes que vamos a
enviar. El uso de ordenadores permite ademas la posibilidad de poder salvar
todo lo que recibamos en disco, depurar y manejar la informacion recibida,
etc..., asi como nos permite enviar comandos a la TNC.
Como veremos, con algunos programas de packet en el ordenador tambien
se puede emular a la TNC. En estos casos, el ordenador esta trabajando como
TNC y como terminal. Ello tiene la ventaja de que no es necesario comprar
una TNC, aunque puede ser necesario un hardware adicional conectado al orde-
nador, siempre mucho mas barato que una TNC.
#04.b.- LA TNC
Se designa por TNC (Terminal Node Controller, controlador de nodo
terminal) un circuito que reagrupa las funciones de traductor de packet (PAD:
empaquetador/desempaquetador de datos) y que suele incorporar un modem.
Una TNC tiene principalmente un microprocesador y un circuito controla-
dor HDLC. La TNC incorpora el software (programas) para su funcionamiento,
normalmente cargado en algun tipo de memoria no vol til. Este software que
incorpora la TNC en algun chip se conoce como "FIRMWARE".
El microprocesador es el cerebro del sistema, controla todas las fun-
ciones de la TNC gracias al programa contenido en la memoria viva (ROM o
EPROM). En los primeros TNC's este microprocesador fue el Z80 de Zilog.
El controlador HDLC por su parte se encarga de la transformacion de los
datos a transmitir en tramas, y las tramas recibidas en datos (funciones de
empaquetado y desempaquetado de los datos). Ademas el HDLC calcula el FCS.
Ciertas TNC's realizan la funcion HDLC en software (GLB y Kantronics).
Ademas, la TNC lleva un interface para la conexion serie al terminal
que responda a las especificaciones RS232, para el intercambio con el termi-
nal de datos (en forma de caracteres ASCII). No obstante, hay algunas TNC's
que usan una conexion paralelo al terminal, conectandose entonces a un puerto
paralelo del terminal, tal como es el puerto LPT o de impresora del ordenador
usado como terminal (la conexion no tiene entonces nada que ver con la espe-
cificacion RS232).
Una TNC tiene tambien memoria viva bajo forma de RAM con alimentacion
por bateria o por acumulador ("battery back-up"), a fin de conservar los
par metros de funcionamiento de la TNC (programables muchos de ellos por el
usuario) y los mensajes en caso de corte de alimentacion, pero la memoria
viva puede tambien presentarse bajo forma de memoria no vol til RAM (NVRAM).
Tambien puede usarse la memoria RAM, si es de mucha capacidad, para almacenar
mensajes recibidos por packet sin necesidad de estar conectado el terminal
(por la noche, cuando el ordenador usado como terminal se esta usando para
otras tareas...). En este ultimo caso, despues podr recuperarse la informa-
cion almacenada desde el ordenador usado como terminal.
al Ŀ Ŀ
terminal salida > Al
<> PAD <>Ĵ entrada < equipo
conexion Ĵ control TX/RX> de radio
RS232 RAM
MODEM
CONTROLADOR
HDLC
El controlador HDLC de la TNC genera un flujo de bits con la informacion
a transmitir, en forma de tramas, y que ha de ser transmitido por el canal de
comunicacion, en este caso un canal de radio. El controlador HDLC realiza las
funciones de las capas 2 y 3 del modelo OSI: Recibe los datos que el usuario
le entrega desde su terminal, en forma de bytes o caracteres, y con ellos
genera los paquetes o tramas AX.25, del nivel 2 de OSI (y realiza el proceso
inverso en recepcion de datos desde el canal de radio). Con todo ello, la TNC
entrega a la salida un flujo de bits (los bits que constituyen las tramas a
transmitir), que han de ser enviados por el canal de radio (o recibidos de
este, en recepcion de tramas), por lo que ya nos encontramos en el nivel 1
del modelo OSI.
En este punto hay que adaptar los bits para su envio por el canal de
radio, teniendo en cuenta su ancho de banda. Ello es necesario ya que las
seales digitales (los bits binarios) no pueden transmitirse como tales por
un canal analogico sin mas: Se ha de realizar una transformacion de las
seales digitales binarias en seales analogicas equivalentes, y viceversa
(segun se transmita o reciba), y esta funcion la realizar el modem de la
TNC. Esta funcion se realiza en dos fases: Codificacion NRZI y modulacion.
Codificacion y modulacion
- - - - - - - - - - - - -
La codificacion establece la forma definitiva que tendra el flujo de
bits para su envio por el medio de transmision, en este caso el canal de
radio. Y la modulacion consiste en transformar este flujo de bits en seales
analogicas equivalentes aptas para ser enviadas por el canal de radio.
Para la codificacion de las seales binarias se puede emplear la codi-
ficacion RZ (Return to Zero), en la cual a cada elemento binario "1" le
corresponde un impulso y hay un retorno hacia el potencial cero. Esta
codificacion ocupa un espectro de frecuencia importante, y se prefiere la
codificacion NRZ (Non Return to Zero), es una codificacion que todos los que
hacen RTTY conocen bien.
0 1 0 0 1 1 0 0
Ŀ Ŀ
Codificacion
NRZ
0 1 0 0 1 1 0 0
Ŀ Ŀ Ŀ
Codificacion
RZ
El NRZ tiene el inconveniente de definir de forma estricta la marca y
el espacio, y para evitar el problema de sentido de manipulacion "normal" o
"reverse" (invertida), se puede adoptar el codigo NRZI (Non Return to Zero
Inverted) donde la marca y el espacio no esta n asociados al estado logico (1
o 0) del elemento binario transmitido, sino que un 0 indica un cambio logico
entre dos elementos binarios sucesivos (de 0 a 1 o viceversa), mientras que
un 1 es signo de no cambio (se mantiene el valor del bit anterior). Este
sistema de codificado NRZI es el empleado en la capa fisica del protocolo
AX.25 y del HDLC.
0 1 0 0 1 1 0 0 <-elementos binarios
1 Ŀ Ŀ Ŀ
Codificacion
NRZI
0
1 0 0 1 0 1 0 1 <- codificado NRZI
La misma secuencia ocurre en sentido inverso, en recepcion de tramas.
Una vez que el controlador HDLC ha generado los paquetes o tramas en
codigo binario NRZI, se las entrega al modem para que este genere las sea-
les analogicas equivalentes (Proceso de modulacion); en recepcion ocurrir
el proceso inverso (proceso de demodulacion), el modem transforma las seales
analogicas recibidas en un flujo de impulsos binarios.
Dependiendo de la velocidad de transmision, la tecnica de modulacion
puede ser una u otra, y que incluso podria llevar consigo un nuevo proceso
de codificacion de los bits. En el caso de transmisiones a bajas velocidades,
como los 300 o 1200 bits/segundo, se emplea la tecnica de modular con los
bits una portadora analogica de baja frecuencia (que el mismo modemasuele
generar), y esta portadora es la que modular el transmisor del equipo de
radio. En recepcion, el modem ha de demodular la seal de baja frecuencia
entregada por el receptor del equipo de radio.
Esta portadora de audio se conoce tambien como PORTADORA DE DATOS, ya
que sobre ella se va a modular los datos transmitidos.
De hecho, la palabra Modem es la abreviatura de MOdulador-DEModulador.
El modem llevar una toma para enviar la seal a transmitir hacia el
equipo de radio, otra toma para recibir de este las seales de packet, y un
control de la transmision/recepcion. Este control se activar poniendo al
equipo de radio en transmision cuando se inicie la transmision de paquetes.
Puede ordenarlo la logica de la TNC, pero en los casos mas sencillos la
presencia de la seal de datos en la via de transmision es la que activa el
control TX/RX (por una especie de "Vox control").
Cuando los pioneros hicieron los primeros ensayos, utilizaron modems
telefonicos (adaptados) que respondian al antiguo esta ndar Bell 202, pues
estos modems eran disponibles en el mercado de recuperacion. Por esto la
norma Bell 202 se utiliza actualmente en VHF.
En esta norma se establece como velocidad de transmision la de 1200
baudios o bits/segundo (bps), una frecuencia de marca de 1200 Hz y una
frecuencia de espacio de 2200 Hz. La modulacion empleada es la AFSK (Audio
Frequency Shift Keying), esto es, la portadora de datos generada por el modem
es modulada por la la marca y el espacio desplazando su frecuencia.
Ŀ Ŀ espacio
Seal binaria
moduladora
marca
Portadora de datos
modulada.
1/2
1200 2200 1200 2200 1200 2200 Hz
El termino SEMI-DUPLEX significa la posibilidad de transmitir y de
recibir informaciones en momentos diferentes. Tal y como se emplea en el
dominio del radioaficionado, el esta ndar Bell 202 no puede ser utilizado
mas que en semi-duplex (o "half duplex"): el equipo de radio solo puede estar
en transmision o en recepcion, no puede hacer las dos cosas a la vez (caso
del duplex total o "full duplex"): El modo de trabajo en packet es necesa-
riamente semiduplex (aunque esto puede cambiar con los equipos bibanda,
capaces de transmitir en una banda y recibir en otra simultaneamente).
En HF las normas de modulacion son un poco diferentes : se utiliza la
norma Bell 103 con una velocidad m xima de 300 bits/segundo o baudios. En
esta norma, la diferencia de frecuencias empleadas en la modulacion, llamada
tambien "SHIFT", es de 200 Hz (1000 Hz para V/UHF), los tonos estandarizados
para esta norma son de 1170 o 2125 Hz (valores centrales) para el st ndard
telefonico (modem full-duplex, una frecuencia central para cada sentido de
transmision). Para la operacion en HF, al trabajar con modulacion SSB, el
tono central empleado en la transmision es indiferente, ya que lo que cuenta
es la sintonia de recepcion del equipo de radio de la estacion receptora.
Los valores empleados de tonos y shifts son los siguientes:
1200 Bd (V/UHF) 300 Bd (HF)
-------------- -----------
Marca 1200 Hz 650 Hz
Espacio 2200 Hz 850 Hz
Shift 1000 Hz 200 Hz
La menor velocidad de transmision binaria respecto a la VHF es debido a
que la transmision, aunque sea mas lenta, es mas inmune a los ruidos y par -
sitos radioelectricos, que son mucho mas importantes en las bandas de HF que
en las bandas de VHF y superiores (mucho mas limpias de ruidos).
En las modulaciones de tipo AFSK tambien se han llevado a cabo experien-
cias a velocidades mayores en VHF y UHF, a 2400 y 4800 bps, pero estas
transmisiones requieren anchos de banda de canal mayores que las transmisio-
nes a 1200 bps, y solo pueden funcionar bien en equipos de radio que permitan
un ancho de banda mayor de fonia que lo habitual. Sin embargo, al ser velo-
cidades de transmision mas elevadas que la esta ndard de 1200 bps, permite un
envio de informacion mas rapido entre estaciones de packet-radio, por lo que
se pueden emplear en zonas donde la actividad del radiopaquete digital es
grande.
Se han desarrollado ciertos modems que utilizan la tecnica de modulacion
PSK (modulacion por desplazamiento de fase de la portadora de datos), princi-
palmente para el trafico por satelite y a altas velocidades de transmision.
Pero para transmisiones a altas velocidades se emplea la tecnica FSK
(Frequency Shift Keying), cuya diferencia respecto a la AFSK es que mientras
esta ultima modula una portadora de datos de baja frecuencia, que a su vez
modular el transmisor, en FSK el modem modula directamente la portadora de
radio con el flujo de bits a transmitir. El esta ndar empleado para la tecnica
FSK es el esta ndard G3RUH, con velocidad de transmision de 9600 bps.
En el st ndard G3RUH, en el caso de los 9600 bits por segundo en FSK,
ademas el el modemase encarga de realizar primero un proceso de "aleatoriza-
cion" de los bits llamado "SCRAMBLING". Este proceso es necesario debido a
que a la velocidad de 9600 baudios (y superiores) no es posible emplear tonos
de audiofrecuencia para la modulacion como ocurre en AFSK, ya que se saldrian
del rango permitido por las emisoras de banda estrecha, por lo que en este
caso se hace necesario el empleo de modulacion FSK directa sobre las etapas
de radiofrecuencia. Esto conlleva aplicar directamente los niveles NRZI del
flujo de bits a la etapa de modulacion de la emisora de radio, y el scram-
bling se encarga de evitar que se produzcan componentes de bajas frecuen-
cias en este proceso (debidos a largas secuencias de bits a 1 o a 0 seguidos)
, que son indetectables o mal tratados por el modulador.
El "scrambler" b sicamente lo que hace es combinar el flujo de bits ori-
ginal con varios flujos que son copias del original pero con un retardo de
varios bits. El "Scrambleador" esta constituido b sicamente por un circuito
denominado "Registro de Desplazamiento" o "Shift Register", que es el que
realiza los distintos retardos de bits del flujo original y combina los
bits de estos flujos a lo largo de varias etapas de retardo.
En recepcion, la seal se extrae directamente del demodulador del recep-
tor, y se "desescramblea" para obtener el flujo de bits original.
El st ndard de 9600 bits/seg tiende a ser empleado entre estaciones de
packet que intercambian una gran cantidad de informacion entre ellas, como
son los BBS's de Packet, recomend ndose el uso de esta velocidad en bandas
de UHF y superiores. Es obvio que a mayor velocidad de transmision, mas
rapidamente se transmiten los datos, lo cual es muy de tener en cuenta en el
caso de las estaciones de packet que esta n manejando un alto numero de
paquetes a lo largo del dia (caso de los BBS's y Nodos de Packet).
En general, se puede concluir que las velocidades recomendadas en el
radiopaquete digital son las siguientes:
300 Bd Recomendada para HF. Shift: 200 Hz.
1200 Bd Recomendada para VHF y UHF. Usa tonos de 1200 y 2200 Hz.
Shift: 1000 Hz (tambien se ha usado 800 Hz).
2400 Bd Propuesto como alternativo a los 1200 Bd.
9600 Bd Usado para enlaces entre BBSs y nodos, y tambien para su uso
por usuarios terminales alternativos a los 1200 y 2400 Bd,
para uso en bandas de UHF y superiores, y para satelite.
Modulacion FSK.
Modos de acceso al canal de radio
- - - - - - - - - - - - - - - - -
El packet radio utiliza conexiones del tipo "acceso aleatorio". Cada
una de las estaciones examina si el canal de radio esta libre antes de pasar
a transmision. Este metodo se denomina "Carrier Sense Multiple Access with
Collision Detection" (CSMA/CD), Acceso Multiple por Percepcion de la Porta-
dora con Deteccion de Colisiones.
La TNC suele realizar esta funcion, y para ello establecer que el
canal esta limpio si no oye durante un tiempo de espera corto (decimas de
segundo o menos), seal alguna de packet. Los propios programas con que
funcionan las TNC's incluyen el software necesario para este proposito.
Desgraciadamente dos estaciones pueden oir a una tercera, esperar el fin
de la transmision de esta ultima y pasar simultaneamente a emision. Se dice
entonces que hay una "COLISION". Esto tambien se produce si las dos estacio-
nes oyen a la tercera, pero no se oyen entre si.
Si las dos seales tienen practicamente el mismo nivel de RF, ser n
indecodificables, por contra, si una trama es recibida con un nivel de RF
por lo menos 20 dB superior a la de la otra estacion podr ser decodificada
pero la seal mas debil ser "aplastada": no la oir la estacion receptora
y por tanto, no la confirmar .
Los programas modernos suelen usar actualmente unas rutinas pseudo-
aleatorias para obviar este problema y el metodo se denomina metodo de la
PERSISTENCIA. Consiste b sicamente en que tras el envio de un paquete, si
este no es confirmado en el tiempo fijado, en vez de retransmitir de nuevo
la trama inmediatamente, el expedidor genera un numero aleatorio interna-
mente y lo compara con un valor de un par metro que ha sido fijado anterior-
mente para la persistencia (par metro de "oportunidad" de transmision).
Si el numero aleatorio generado por la rutina es superior al valor del par -
metro, se realiza la retransmision de la trama que se supone no ha sido oida
por el corresponsal por motivos de una colision. Si es inferior, se repite
de nuevo la generacion de un nuevo numero aleatorio al cabo de un tiempo
prefijado (el "slottime"), normalmente de unas decimas de segundo.
Si este procedimiento estuviera en todas la estaciones de packet, se
minimizaria el numero de retransmisiones debidas a las colisiones de tramas.
Como informacion, existe otro procedimiento de acceso al canal de radio,
llamado ALOHA, en el cual cada estacion de radiopaquete realiza la transmi-
sion sin antes comprobar que el canal este libre. Llamado asi porque fue el
primer procedimiento de acceso al canal de radio en los primeros experimentos
de la Universidad de Hawai, solo se usa en la actualidad en usos muy concre-
tos del packet (trabajo por satelite), debido a que como es de esperar, este
metodo genera un alto numero de colisiones.
Seleccion de la TNC
- - - - - - - - - -
Finalmente Ud. elegir su TNC en funcion de los criterios siguientes:
* Ciertas TNC's no llevan modem, otros tienen un modem ajustable sea para la HF (Bell 103) sea para la VHF-UHF (Bell 202), otros disponen de dos modems optimizados por filtros de entrada (dos puertos).
* Ciertas TNC's permiten la operacion simultanea en HF y en VHF.
* Algunos permiten el "GATEWAY" entre los dos ports (conexion de un puerto
de radio con el otro, permite p.ej, usar la TNC como repetidor de packet
si cada puerto es conectado a un equipo de radio con frecuencias de ope-
racion distintas). Tambien uno de los ports puede ser para conexion te-lefonica (lo que permite enviar por conexion telefonica el trafico de packet almacenado en la TNC hacia otra estacion con conexion telefonica como alternativa a las conexiones via radio).
* Ciertas TNC's esta n destinadas especificamente a un tipo de ordenador.
* Ciertas TNC's pueden funcionar tambien en otros modos (CW, Baudot, ASCII,
AMTOR, SSTV, Facsimil, ...): Son las TNC's denominadas "MULTIMODOS".
Una TNC bastante estandard es la TNC2 de la TAPR; TAPR es la abreviatura
de la "Tucson Amateur Packet Radio Corporation", una asociacion de Tucson
(Arizona, Estados Unidos) que se dedica a investigar para el desarrollo del
Packet sin nimo de lucro alguno.
Cada TNC incorpora en su microprocesador y en su memoria ROM o EPROM
el software necesario para funcionar. Este software cargado en las memorias
PROM o ROM de la TNC se conoce genericamente como "FIRMWARE", y los programas
terminales que se usan en el ordenador o terminal que se conecte a la TNC ha
de ser compatible con el firmware de la TNC, y por tanto es especifico segun
la TNC usada.
Con este software emulador de terminal se puede manejar la TNC desde
el ordenador terminal, y ademas del manejo del ordenador como terminal, per-
mite:
* Usar la TNC en modo normal, para enviarle datos de programacion, cambiar
algunos par metros de funcionamiento de la TNC, del flujo de intercambio
de datos entre terminal y TNC, y del programa del PAD de la TNC (para la
generacion y envios de paquetes), ponerlo en modo comando, etc...
* Usar la TNC en "modo comando". En este modo lo que se envia a la TNC
desde el terminal y lo que se recibe de el esta referido al trafico de packet: Envio de orden de conexion a otra estacion, envio de mensajes a la otra estacion, desconexion, comandos de manejo de BBS's...
Uno de los firmwares mas conocidos es el usado en las TNC-1 de la TAPR,
conocido por el nombre de su autor, Ronald Raikes, WA8DED. Este firmware
establecido por primera vez (la primera version) por Ronald Raikes en 1985,
soporta el protocolo AX25 descrito por la ARRL en octubre de 1984, y se carga
en las Eproms de las TNC-1 de TAPR y TNC's clonicas. Es el firmware WA8DED
(o firmware TF).
#04.c.- EL EQUIPO DE RADIO
Generalmente se utiliza un transceptor de FM tradicional para la banda
de 2 metros o un transceptor de SSB tradicional para bandas decametricas.
Habitualmente la conexion de la TNC al equipo de radio usa tres circui-
tos de conexion:
* una conexion-directa al conector "micro" para la transmision de paquetes
(ya entregados por el modem de la TNC).
* una conexion al jack "external speaker" (toma para altavoz externo) por otra parte, para enviar las seales recibidas al modem.
* y una conexion al mando TX/RX del transceptor (mando PTT), para controlar
el paso de este a transmision o su vuelta a recepcion. Normalmente la transmision se activa al poner a masa el hilo de conmutacion PTT.
Las conexiones se realizar n con hilos blindados (a traves de sus mallas
quedan conectadas la masa del equipo de radio con la de la TNC).
Con este tipo de conexiones directas las transmisiones de packet funcio-
nan, pero se han constatado numerosos tipos de problemas que se han de tener
en cuenta y que pueden malograr las transmisiones de packet:
* La sobremodulacion del emisor por una seal de entrada en su toma de micro
excesiva provoca distorsiones de modulacion que degradan la seal trans-
mitida ya a nivel de alta frecuencia: Se ha de regular correctamente el
nivel de seal que el modem entrega a la toma de micro del transmisor para
evitar este problema. Normalmente una transmision de packet sonar un poco
mas baja que una transmision de fonia.
Los tonos enviados se tienen que oir "redondos", sin carraspeos ni otros
ruidos raros.
* Algo parecido puede decirse para la seal entregada por el equipo al modem:
Un nivel alto de seal entregada en la toma del altavoz puede dar lugar a
que esta se distorsione en el modem; un nivel muy bajo puede dar lugar a
que el modem no la oiga. Como al conectar la toma de seal del modem a la
toma de altavoz exterior del equipo su altavoz interno se silencia, el
ajuste del volumen de recepcion ha de ser a ojo, con toda la instalacion
funcionando y en un canal donde hayan transmisiones de packet, observando
en la pantalla del terminal cuando se reciben bien el trafico de packet.
* La distorsion que provocan las etapas de audio (moduladora y de recepcion)
sobre la seales analogicas, principalmente en los equipos modulados en FM:
Los compresores y dinamizadores de la modulacion pueden provocar alteracio-
nes en la amplitud de la seal de audio, los circuitos pasobanda y de pre-
enfasis y desenfasis introducen desfases y atenuaciones dependientes de la
frecuencia en la seal de audio...
Tambien una FI de la etapa receptora muy estrecha de paso de banda puede
provocar problemas.
Todas estas "mutilaciones" pueden ser tan importantes que la seal de
packet sea inutilizable. Si no son muy importantes, las transmisiones por
packet no suelen dar problemas por estos aspectos.
Normalmente a 1200 bits/seg o velocidades inferiores no suelen haber estos
problemas. A 2400 bits/seg pueden manifestarse algunos problemas en algunos
equipos. Ello es debido a que a esta velocidad las frecuencias transmitidas
son mas altas que para 1200 bits/seg, y la frecuencia mas alta empieza a
ser afectada por los filtros pasabandas y de preenfasis/desenfasis de las
etapas de audio del equipo de radio.
En estos casos, actuando sobre el control de tono del receptor (si lo hay)
realzando los agudos, se suele solventar este problema.
A velocidades mas altas, las frecuencias transmitidas, que son mas altas,
son muy afectadas (fuertes desfases y atenuaciones), imposibilitando el
uso del packet de la manera tradicional a estas velocidades.
Para trabajo a estas velocidades elevadas con equipos de radio, de FM, es
preferible aplicar la modulacion directamente al varicap del modulador (o
a la etapa que le precede) y recuperar la seal de BF recibida justo
despues del discriminador de FM. Los equipos de radio modernos que ya
vienen preparados para trabajar en packet a 9600 bits/seg ya incorporan
una toma preparada con conexiones directas el varicap y el demodulador de
FM (antes del desenfasis), con lo cual evitan las etapas de baja frecuen-
cia, causantes del problema.
* El tiempo de conmutacion emision/recepcion: Este tiempo es bastante impor-
tante para los equipos antiguos a reles, actualmente con las conmutaciones
electronicas, este tiempo es considerablemente reducido. En el tiempo de
conmutacion hay que tener en cuenta tambien el tiempo necesario para la
estabilizacion de los VCOes y de la potencia de salida. Los softwares
empleados por las TNC's han de tener en cuenta esto y para ello dan lugar
a la transmision de los paquetes de datos tras haber ordenado activar la
conmutacion TX/RX al equipo de radio, pero de manera no inmediata: se deja
un tiempo prudencial (de decimas de segundo normalmente) antes del envio
de los datos para dar tiempo a que la conmutacion se haya efectuado en el
equipo de radio y se haya estabilizado la transmision de este en frecuen-
cia y amplitud. Este retardo se suele conocer como "TX DELAY", y suele ser
ajustable por comando.
* El ajuste del "squelch" o silenciador del receptor: el "squelch" de la
emisora debe estar en el punto critico de cierre, ya que hay equipos
lentos en abrirse y puede ser un problema con gente que transmita muy
rapido, pero tampoco hay que dejarlo abierto, ya que el detector de canal
ocupado no dejaria enviar nada si considera como canal ocupado la presen-
cia de cualquier cosa en el canal, como es el ruido de este, o peor aun,
el soplido que genera el propio receptor en ausencia de seal si es un
receptor de FM: Hay modems muy sensibles que al recibir ruido, incluso de
bajo nivel, entregan seal al PAD de la TNC.
No obstante hay softwares para TNC's que permiten trabajar con el squelch
abierto (con lo cual se evitan los problemas anteriores), al poder analizar
por software la seal que les llega del modem y poder deducir cuando se
trata de ruido (y el canal esta libre) y cuando de una transmision de
packet (canal ocupado).
#04.d.- LA CONEXION RS232
La conexion entre la TNC y el terminal necesita un cable RS232. Si la
norma EIA 232-D es clara y precisa, su aplicacion en packet no lo es en
absoluto y probablemente se pasar Ud. un cierto tiempo para resolver este
problema.
El conector RS232 es un conector del tipo DB25 (25 teminales), pero en
el los PCs-IBM pueden encontrarse conectores DB9, version reducida de 9
terminales del conector RS232, con las principales lineas del conector DB25.
Las conexiones RS232 son para la transmision de datos en serie, por lo
que en el lado del terminal deber emplearse para ello uno de los puertos de
comunicacion serie del terminal (uno de los puertos COM del ordenador, si se
usa un ordenador como terminal).
El equipo ETD o DTE (equipo terminal de datos) posee habitualmente un
conector macho, mientras que el ECD o DCE (equipo de terminacion del canal
de datos: TNC) posee un conector hembra.
Le aconsejamos vivamente utilizar cables RS232 estandard cableados en
linea, es decir las patillas 1 unidas, las patillas 2 unidas, etc ..., y utilizar "las pequeas cajitas" para realizar todas las interconexiones.
Segun la norma RS232 un nivel logico bajo (L, "0") es dado por una
tension positiva, y un nivel logico alto (H, "1") por una tension negativa.
Los niveles de tension son como minimo de +3 y -3 voltios, y como maximo de
+15 y -15 voltios.
Aunque las funciones de las 25 patillas esten bien definidas en la norma
RS232, en numerosos casos no se emplean todas las patillas. Por ello el
conector DB9 usa solo las mas habituales, y suele ser mas que suficiente en
la mayoria de las aplicaciones.
Las patillas siguientes son las mas utilizados (DB25):
1 : FG : Frame ground (masa del chasis).
2 : TD : Transmitted Data (datos transmitidos hacia el otro equipo).
3 : RD : Received Data (datos recibidos, linea de recepcion de datos
procedentes del otro equipo).
4 : RTS : Requesta to Send (Peticion para enviar: el DTE pone esta linea
en estado H, si quiere transmitir hacia el DCE).
5 : CTS : Clear To Send (el DCE pone esta linea en H si esta dispuesto a
recibir del DTE).
6 : DSR : Data Set Ready (Datos listos para enviar: el DCE pone esta linea
en estado H si esta dispuesto a enviar al DTE).
7 : GND : ground (masa electrica: blindajes...).
8 : DCD : Data Carrier Detect (deteccion de portadora de datos: el DCE
envia un 1 si recibe la portadora de datos del canal analogico).
20: DTR : Data Terminal Ready (Terminal de datos preparado: en estado H
si el terminal esta en funcionamiento).
La correspondencia entre los conectores DB25 y DB9 es la siguiente:
Seal DB25 DB9
DTR - 20 - 4
RTS - 4 - 7
CTS - 5 - 8
GND - 7 - 5
TXD - 2 - 3
RXD - 3 - 2
DCD - 8 - 1
DSR - 6 - 6
En la mayoria de las TNC2-TAPR y compatibles, la seal CTS no entra por
la patilla 5, sino por la 20, lo cual va contra la norma RS-232.
A menudo la simple conexion de 3 hilos es suficiente:
TXD 2 <----------------< 2 TXD
TNC RXD 3 >----------------> 3 RXD Terminal
GND 7 ------------------ 7 GND
Pero si su terminal utiliza RTS/CTS para el "handshaking" (proceso de
"ponerse de acuerdo" el ordenador con la TNC):
TXD 2 <----------------< 2 TXD
RXD 3 >----------------> 3 RXD
TNC RTS 4 <----------------< 4 RTS Terminal
CTS 5 >----------------> 5 CTS
GND 7 ------------------ 7 GND
Si su terminal utiliza obligatoriamente las seales CTS, DSR y DCD,
entonces tendraque utilizar el siguiente cableado:
TXD 2 <----------------< 2 TXD
RXD 3 >----------------> 3 RXD
GND 7 ------------------ 7 GND
,-----< 4 RTS
TNC |-----> 5 CTS Terminal
|-----> 6 DSR
|-----> 8 DCD
e-----< 20 DTR
A veces tambien, el terminal no esta cableado como un DTE sino como un
DCE, ser necesario entonces realizar un cableado con conexiones cruzadas.
En todos los casos un mini-tester con LED ser un instrumento muy eficaz
por no decir indispensable, para hacer pruebas sobre los conectores RS232.
#04.e.- LA CONEXIoN CON EL EMISOR-RECEPTOR
La conexion entre la TNC y el emisor-receptor necesita:
RX input : la seal de BF recibida y que pasa por el circuito
del silenciador ("squelch").
TX output : la seal emitida aplicada en lugar del microfono.
PTT : linea puesta a masa cuando se pasa a emision
masa : la masa
Las seales RX input y TX deben ser conducidas por cables blindados.
La mayoria de los transceptores modernos poseen un conector de micro
de 6, 7 u 8 contactos, estando presentes la entrada de micro, el PTT y la
masa, pero tambien a veces la seal del receptor.
Si a pesar de todo no se encuentra presente la seal del receptor, ser
suficiente tomar una patilla libre del conector (o si no la hay utilizar la
patilla que lleva los +5V al teclado DTMF de los micros utilizados en los
Estados Unidos) y de conectar esta patilla a la salida de altavoz (el jack
"external speaker") a traves de una resistencia de 100 ohms por ejemplo.
Antes de realizar los primeros test, ser conveniente verificar los
par metros de funcionamiento del programa.
#04.f.- LA VELOCIDAD DE TRANSMISION
En las transmisiones por packet hay dos velocidades de transmision a
tener en cuenta: la velocidad entre el propio puerto del ordenador y la TNC,
y la velocidad usada en radio.
La velocidad de transmision se evalua en bits/segundo. La TNC se comu-
nica con el terminal habitualmente por medio de un puerto serie, es decir,
que los bits son transmitidos sucesivamente unos despues de otros por los
hilos correspondientes (uno para transmision DTE-->DCE y el otro para la
transmision DCE--->DTE) del cable de union RS232.
Las velocidades de transmision deben ser iguales en el terminal y en la
TNC. A nivel del terminal una tecla o alguna funcion del programa debe per-
mitir acceder a un menu de configuracion que permitir a su vez elegir la
velocidad de transmision del terminal por su puerto serie.
La velocidad de transmision de la TNC se selecciona gracias a interrup-
tores DIP, puentes u otros, incorporados en la circuiteria de la TNC.
Ciertas TNC esta n equipadas con una seleccion autom tica de velocidad
con el terminal, denominada "AUTOBAUD": Enviando desde el terminal algunos
caracteres (CR, * , ..ver la documentacion), la TNC calcula la velocidad con
que le transmite el terminal, y se posiciona en ella.
Aunque no exista ninguna regla imperativa, se aconseja trabajar a una
velocidad igual o superior a la velocidad utilizada en el canal de radio y
se utiliza habitualmente 4800 o 9600 bits/seg. En efecto, una velocidad de
trabajo entre el terminal y la TNC inferior a la velocidad de transmision
por radio da lugar a que la transmision de informaciones por radio sea mas
lenta (pues la TNC vacia su buffer de transmision mas rapidamente que es
recargado por nuevos datos procedentes del terminal, y ha de esperar a que
se llene lo suficiente para continuar la transmision de datos), y que pueda
dar lugar a congestiones en el buffer de recepcion de la TNC (entran mas
datos en este via radio que los que puede volcar hacia el terminal), dando
entonces lugar al envio de tramas NRN.
Las velocidades de transmision en el canal radio son actualmente de 300
bits/seg para HF, o de 1200 bits/seg para VHF-UHF. Se usan tambien velocida-
des mas elevadas para UHF, tipicamente la de 9600 bits/seg. para estaciones
de packet con fuerte trafico entre ellas (BBS's), e incluso con estaciones
terminales en UHF, lo que agiliza las comunicaciones de packet.
#04.g.- CASO DE USAR SOLO MODEMS EN LUGAR DE LAS TNC's
Algunos programas hacen que el ordenador usado como terminal integre
las funciones de TNC y de terminal, por lo que solo requiere el modem para
conectarse al equipo de radio. El programa consta b sicamente de dos partes,
la emulacion del terminal, y la emulacion de la TNC, incluyendo tambien el
manejo del puerto donde este conectado el modem, y la comunicacion entre el
terminal y la TNC virtual emulada.
Otros programas permiten seleccionar el modo de funcionamiento: con TNC
externa, o integrando por software TNC y terminal en el mismo ordenador.
Algunos de los programas que permiten el uso de modem externo, emulando
el ordenador las funciones de terminal y de TNC son el BayCom, el TPK, el
TSTHOST, el AGWPE, el WinTST, etc...
Cuando se usa este modo de operar en packet, la instalacion es muy
sencilla, pues se usa tan solo un modem externo que hace de interfaz entre
el equipo de radio y el ordenador. Estos modems se conectan al ordenador
tipicamente a traves de uno de los puertos serie de este (puerto COM) aunque
por su sencillez de diseo, no suelen cumplir las especificaciones RS232,
como veremos. Algunos modems esta n diseados para la conexion al puerto
paralelo (LPT o de impresora) del ordenador en lugar del puerto serie.
La simplificacion de la instalacion tiene como desventaja de que para
trabajar en packet se tenga que tener el ordenador encendido y funcionando
con el programa correspondiente. Con las TNC's, se puede operar autom tica-
mente sin necesidad de estar el ordenador (operando como terminal) conectado
la mayor parte del tiempo.
El programa BayCom es un viejo programa de packet de origen alem n del
tipo de los que permite integrar en el ordenador las funciones de TNC y de
terminal de usuario. Usa varios tipos de modems, pero el mas popular es un
modem que por su sencillez es de bajo consumo y puede ser autoalimentado a
traves del puerto al que se conecte, un puerto serie. Dicho modemase denomina
modem BAYCOM, y en general este nombre se da a cualquier modemasencillo que
opere similarmente al modem BayCom original, sea cual sea el programa de
Packet usado: BayCom, TPK, TSTHost, Winpack... son programas usados actual-
mente para packet que tienen como opcion usar este tipo de modem.
El modem BayCom no tiene inteligencia alguna, todo lo hace el ordenador.
Lo unico que hace es modular la portadora de audio que genera por los datos
que el ordenador le entrega por su puerto serie, ya empaquetados por la TNC
virtual emulada en el ordenador, para su transmision por radio, y demodular
las seales que el receptor del equipo de radio le entregue.
Este modem esta basado originalmente en el integrado TCM3105 de Texas,
el cual es un modem integrado para telefonia, que puede operar en las normas
Bell 202 y V23. Actualmente este integrado ya no se fabrica. La conexion al
ordenador, a traves de uno de los puertos COM de este, usa las siguientes
patillas del conector COM:
Seal DB25 DB9 Descripcion- uso (en modem BayComaserie)
DTR - 20 - 4 - Datos para TX
RTS - 4 - 7 - Control del PTT (+12V = TX ; -12V = RX)
CTS - 5 - 8 - Datos RX.
GND - 7 - 5 - Masa de blindaje.
TXD - 2 - 3 - Alimentacion +12V modem BayCom
Con las salidas DTR, RTS y TXD utilizando 3 diodos se puede alimentar
al modem BayCom en la mayoria de los casos (ya que es un modem de muy bajo
consumo).
El estado de ocupacion del canal se detecta por el nivel de tension de
la la patilla CTS, entregado por el modem. No obstante, con el TCM3105 el
modem presenta condicion de canal ocupado con la sola presencia de ruido en
el canal: Es entonces necesario trabajar con el squelch ajustado a supresion
de ruido de fondo.
No obstante hay programas que permiten reconocer el estado de ocupacion
de un canal por software, y ello es util para equipos con squelch lento, los
cuales deber n de operar con el squelch abierto. El reconocimiento se raliza
por la linea CTS tambien, pero de otra manera, intentando detectar la porta-
dora de datos (DC) y no es por supuesto tan bueno como un buen Squelch o el
CTS activado mediante un modem basado en un integrado PLL.
Para decidir cuando un canal esta "Libre" u "Ocupado" por software, se
utiliza el siguiente o similar criterio, basado en el an lisis de lo que
el modem entrega a la TNC u ordenador, an lisis que se traduce en un valor
de una variable X al analizar la seal de entrada durante intervalos de
tiempo muy cortos:
* mas de 6 bits recibidos con valor 1 de forma continuada: No se trata
de una bandera (flag) que delimita un paquete. Por tanto es un caso de
datos de entrada erroneos o no v lidos, y entonces se supone que el
canal puede estar en situacion de eCanal libree, y se asigna a X el
valor 0.
* 6 bits recibidos con valor 1 consecutivos, se emplean como comienzo y
final de los paquetes (banderas) sirviendo para la sincronizacion de
las TNC's: X se incrementar en 5 unidades.
* Menos de 5 bits recibidos con valor 1 consecutivos: X se incrementa en
una unidad.
* Resultado: si tras un intervalo de tiempo X tiene un valor >= 10, se
toma el canal como "Ocupado", si X < 10 se considera el canal "Libre".
En general, cualquier programa y TNC que permita la operacion con
squelch abierto, esta opcion deber de funcionar reconociendo el estado de
libre u ocupado del canal por software.
Existen incluso aadidos adicionales a estos programas que simplifican
aun mas la instalacion de packet, al emular el ordenador por software no ya
solo las funciones de terminal y de TNC, sino que incluso las del modem.
Para ello, el equipo de radio se conecta al puerto serie del ordenador
a traves de un sencillo adaptador de seales. En transmision, la emulacion
de TNC del programa utilizado genera los paquetes que se transmitir n, y la
emulacion del modem har que estos generen un tren de impulsos en la salida
correspondiente del puerto serie (salida DTR), cuyas frecuencias sean las
correspondientes a las que generaria un modem externo (1200 y 2200 impulsos/
seg para 1200 Baudios). El adaptador en transmision lo que realiza es "sua-
vizar" la forma de los impulsos, que son "cuadrados" (pues son seales digi-
tales, con dos estados: alto y bajo), para que sean seales de tipo analogico
y poco cargadas de armonicos, a la vez que atenua el nivel de la seal (de
varios voltios) para que pueda aplicarse a la toma de microfono del transmi-
sor (nivel de milivoltios). Una serie de celulas de filtro RC cumplen esta
funcion en el adaptador.
En recepcion de datos la emulacion de modem "lee" la seal que le entra
por el terminal correspondiente del puerto serie (entrada CTS), y determina
por la duracion de los impulsos leidos (duracion entre dos transiciones suce-
sivas del nivel de la seal) si se corresponden con una cadencia de 1200 o
2200 impulsos, en el caso de una transmision packet de 1200 bits/s (lo
cual determina si se esta recibiendo una marca o un espacio). Pero para ello
la seal analogica entregada por el receptor del equipo de radio ha de
convertirse en un tren de impulsos equivalente (de la misma frecuencia) y
ello se consigue en el adaptador por amplificacion elevada de la seal
entrante (la saturacion del amplificador recorta las crestas y cuadratiza la
forma de la seal a su salida). Un operacional trabajando al maximo de su
ganancia es suficiente para conseguir esto con una baja seal de entrada.
Como ejemplo de esto, esta el adaptador conocido como EMBayCom, que
junto con el archivo "driver" correspondiente, permite trabajar en packet a
algunos programas que requieren el modem BayComasin necesidad de este modem.
Este adaptador es un interface que funciona de una manera similar a la des-
crita, esta constituido por un operacional, y el interface esta conectado al
equipo de radio por un lado, y a dos de los puertos serie (COM) del ordena-
dor. A traves de uno de los dos puertos se manejan las seales enviadas y
recibidas sobre el equipo de radio (y aqui es donde el programa driver rea-
liza la emulacion del modem), mientras que por el otro puerto se intercambian
las seales con la TNC virtual emulada por el programa de packet, esto es,
como si un modem BayCom real estuviera conectado a este puerto. Por tanto, a
traves de uno de los puertos el ordenador emula al modem, mientras que por
el otro puerto se estaria trabajando normalmente. Ademas del programa de
packet empleado se requiere un programilla adicional, el driver EMBayCom o
similar, cuya funcion es la de emular el modem BayCom para el programa de
packet que se este usando.
Normalmente, para el caso del EMBayCom, la emulacion de modem por el
otro puerto COmase realiza para las seales recibidas del equipo de radio,
para las transmitidas no suele ser necesaria esta emulacion y se opera por
el puerto COM usado normalmente.
La emulacion del modem ademas de la emulacion del terminal y de la TNC
tiene como inconveniente que sobrecarga de trabajo la CPU del ordenador, pero
actualmente no es problema para los actuales ordenadores, muy rapidos.
BayCom y otros programas admiten tambien el uso de modems para puerto
paralelo, b sicamente siguiendo una filosofia de funcionamiento similar a la
de los modems BayCom de puerto serie. Para este tipo de modem el conexionado
mas habitual al puerto paralelo del ordenador es el siguiente:
Seal 25pin. Significado en modem BayCom paralelo
DATA7 8 Envio de datos. Nivel TTL (Datos para TX)
DATA8 9 PTT. Activo en "alto": 0V=RX, 5V=TX
BUSY 11 Recepcion de datos (ACK)
GND 18-25 Masa
Observese que no se contempla la alimentacion del modem desde el propio
puerto paralelo, por lo que han de ser alimentados externamente.
Uno de los modems mas usados para puerto paralelo es uno basado en el
circuito integrado AM 7910, que tambien es un chip para modems telefonicos
antiguos.
#04.h.- USO DE LAS TARJETAS DE SONIDO
Las tarjetas de sonido no esta n consideradas como elementos imprescin-
dibles en los ordenadores PC actuales, pero si es un elemento que se equipa
en la mayoria de estos, sobre todo en todos aquellos que se dediquen a todo
lo que es "Multimedia".
Estas tarjetas se usan para todo lo que es reproduccion de sonidos, bien
almacenados en archivos de sonido, bien procedentes de otras fuentes (repro-
ductor de CD-ROM reproduciendo un Compact musical), asi como para la genera-
cion de sonidos en altavoz externo. Por tanto estas tarjetas tienen tomas
para microfono o seal externa, y para salidas hacia altavoces externos.
Estas tarjetas requieren de los drivers adecuados (software apropiado)
para funcionar, y estos drivers pueden ser diseados no solo para las funcio-
nes de grabacion y reproduccion de sonidos, sino que tambien pueden ser
usados para generar seales de baja frecuencia de todo tipo, como son las
seales de AFSK, y para recibir y analizar estas. Ello es posible porque en
la tarjeta de sonido hay equipados circuitos generadores de sonido programa-
bles, asi como circuitos de procesamiento digital de seales de sonido (DSP),
que se pueden programar y manejar por software.
Por tanto, usando el driver y los programas adecuados, se puede conse-
guir que una tarjeta de sonido se pueda comportar como un modem, y diseados
adecuadamente, puede ser usada como modem de packet radio. Y esto se est
imponiendo actualmente, lo cual simplifica y abarata mucho la instalacion,
ya que no hay modem o TNC externa conectada al ordenador, sino que se emplea
la propia tarjeta de sonido como modem de packet radio. Basta conectar las
tomas de micro y altavoz de la tarjeta de sonido a las tomas de seales
correspondientes del equipo de radio, y usar un programa de packet que sopor-
te la tarjeta de sonido como modem. Y por supuesto, regular los niveles de
seal que se intercambian tarjeta de sonido y equipo de radio, para evitar
sobremodulaciones y distorsiones de las seales (regulacion que se puede
hacer con resistencias ajustables y/o con el mezclador de sonido virtual que
suelen incorporar los modernos sistemas operativos de ordenador.
Dado que la tarjeta de sonido no tiene ninguna funcion de enviar alguna
seal de control cuando genera sonidos, que pueda ser usada para controlar
el PTT del transmisor, es necesario aadir algun tipo de dispositivo o cir-
cuito adicional que controle el PTT del transmisor. Una solucion es la de
aadir un dispositivo de "vox-control" (que puede estar ya incorporado en
el propio equipo de radio) para activar el PTT a transmision con las seales
de salida de la tarjeta de sonido (seales a transmitir). Otra opcion muy
usada es habilitar una de las lineas de salida de uno de los puertos serie
(COM) del ordenador para control del PTT del transmisor, pero esto implica
usar un puerto COM del ordenador solo para este uso.
#04.i.- DESCRIPCION TECNICA DE UN MINIMODEM BAYCOM CLASICO
Este modem elemental permite la practica del Radiopaquete digital
(Packet Radio) de radioaficionados a la velocidad de 1200 Baudios, usando
programas que emulen en el ordenador una TNC virtual. Usa el standard BELL
202 utilizado para modems telefonicos.
Puede alimentarse exteriormente, pero debido a su bajo consumo, est
preparado para alimentarse directamente de las tensiones que recibe de algu-
nas de las patillas del puerto serie al que es conectado este modem (COM1 o
COM2 del PC).
Por otro lado se conectar a la toma de microfono y de altavoz del
equipo emisor-receptor, asi como al PTT (mando emision- recepcion del equipo).
esta basado en el circuito integrado TCM3105 de Texas, que ya desde
finales de los 90 ya no se fabrica (ya esta anticuado).
O MIC <---- Din ----> O PTT O ALTAV O GND
Para talky solamente (R14)
IJ
R14 2.2k
C8 c \u178 b R13
100n T1 IJijĿ
e / BC548 10k
R12 /
100k R7 R8 R10
OIJIJĴ +5V R6 100
+5V 15k 33k IJĴ
b Ŀ 47k Ŀ
R11 Ĵ 9 8 ijĿ
IJĿ C6 R9
10k ij10 T 7 100n
R15 C7 C 100
IJ ij11 M 6 Ŀ
10k 100n
Ĵ12 3 5 Ŀ 8
1 o
C5 Ĵ13 0 4 ijij
Ŀ 5 9
33p ij14 3
4.433 MHz D4
ijij15 2 o |<Ĵ
C4 33p Q1 13 12 3.3M
ijij16 1 O IJĴ
> +5V +5V R5 +
10F + Ĵ C2 10F
O C3
100n Ĵ C9 +5V
ijĿ 2 5 R4
78- o 100k
L05 Ĵ o
1 6 4
ij R1 R3
100F + Ĵ C1 100k 2.2k o
a
3x |<Ĵ 3
1N4148D3 R2
|<Ŀ 100k Ĵ
D2
|<Ŀ ijĴ
D1 O O O O O
TXD DTR CTS RTS GND
DB9 --> (3) (4) (8) (7) (5)
DB25 -> (2) (20) (5) (4) (7)
c todo nodo
Salida |< Diodo
o
Puerta 74HC04 1/6, la alimentacion es pin 14 (+5) y pin 7 (gnd)
Entrada
/b
R16 22k b / c
aIJIJ Para FT-470 unicamente
e
Ajuste.- Situar los potenciometros a mitad de recorrido, conectar al port
RS232 correspondiente (COM1) y ejecutar el programa ajustando con R6 una
tension de 2.6 Volt. entre el pin 7 del TCM y masa. La salida de audio se
ajusta con R11. Regular correctamente el nivel de audio en altavoz del
equipo transmisor para una correcta decodificacion de las seales digitales
recibidas.
Modificacion: Cambiando el cristal de 4.433619 Mhz por otro de 6.5536 Mhz,
el modem puede trabajar a 2400 Baudios, aunque puede ser mas critico de funcionamiento.
CONEXION PARA RS-232:
(cables a conectar en el BayCom)
DB-9 * DB-25 * Notas
- * 1 = Chasis del aparato.
3 * 2 = TXD Salida de datos del ordenador. *
2 * 3 = RXD Entrada de datos del ordenador.
7 * 4 = CTS Clear To send (Limpio para enviar). *
8 * 5 = RTS Requesta to Send (Quiero enviar). *
6 * 6 = DSR Data Send Ready (Puedes enviar datos).
5 * 7 = Masa comun de datos (Tierra comun pero no de Chasis). *
1 * 8 = DCD Data Corrier detect (Detectada portadora).
4 * 20 = DTR Data Terminal Ready (Terminal presente y listo para RX. *
DIAGRAMA DE FUNCIONAMIENTO:
DB-25 Arran- : trabajando el programa de packet : salida
que PC : Reposo : Recibiendo : Transmitiendo : Reposo : prgr.
----- -------:---------:------------:-----------------:--------:-------
: : : : :
: : : : :
* Ŀ
2 TXD 0 : : :
* : : :
: : : : :
* Ŀ : Ŀ :
4 CTS 0 : :
*
: : : : :
+ : Ŀ : :
5 RTS 0
: : : : :
: : : : :
* Ŀ -------------Ŀ
20 DTR 0 ....
* -------------- 1 2 2 2 2
Las seales TXD, CTS, DTR son puestas por el PC hacia el modem, sus valores
de tension son niveles RS-232 (+V/-V ; V = 3 a 12 Volts).
La seal RTS es entregada por el modem al PC cuando este recibe algo. Su valor es de 0/+5 Voltios.
Nota: El circuito integrado TCM 3105, concebido como modem para telefonia a
1200 Baudios, es muy sensible a los ruidos y activa la linea RTS f cilmente
cuando reciba algo de ruido: conviene que el receptor este dotado de squelch
(silenciador de recepcion).
Notas del diagrama:
1- Retardo de envio de datos en transmision (txdelay).
2- Envio de datos.
Nota: El estado del puerto RS232 al arrancar el PC y al salir del programa
de radiopaquete podria depender del PC utilizado.
Nota: En transmision, a 1200 Baudios:
DTR a nivel bajo --------> envio de 1200 Hz. al micro
DTR a nivel alto --------> envio de 2200 Hz. al micro
En transmision, a 2400 Baudios:
DTR a nivel bajo --------> envio de 1775 Hz. al micro
DTR a nivel alto --------> envio de 2250 Hz. al micro
Nota: Debido a los pocos componentes que componen este modem, este puede
llegar a realizarse en una placa pequea, que puede caber en el in-
terior de la carcasa de un conector DB25. En estos casos, convendria
sustituir los ajustables R6 y R11 por puentes divisores de tension de
dos resistencias, de valores determinados experimentalmente, y usar
resistencias de 1/4 de watio, con el fin de ahorrar espacio.
La conexion de este modem al puerto serie COM1 o COM2 del ordenador
ha de ser muy corta (se recomienda la integracion del modem dentro
del conector DB25 como mejor solucion). Para conexiones mas largas,
el funcionamiento del modem puede presentar muchos problemas debido
a que las debiles induciones que se pueden producir entre las lineas
DTR y CTS de conexion al PC son suficientes para que el TCM3105 las detecte como ruido y se perturbe su funcionamiento.
Se recomienda en estos casos usar cables blindados individuales para
cablear las lineas DTR y CTS.
Datos del TCM3105:
Tensiones m ximas aplicables: VDD: -0.3 a +10 V.
en cualquier pin: -0.3 a +VDD. en alguna entrada respecto a VDD : -0.3 V. en alguna salida respecto a VSS : +0.3 V.
Oscilador a cristal: 4.4336 Mhz
El TCM 3105 se presenta con dos encapsulados, de 16 y de 24 patillas, siendo
el mas usual el de 16 patillas:
Ŀ
VSS Ĵ 9 8 RXD Patilla 16 pin 24 pin
------- ------ ------
CDL ij10 T 7 RXB VDD 1 1
C CLK 2 2
TXA ij11 M 6 RTX CDT 3 3
RXA 4 5
TXR2 Ĵ12 3 5 TRS TRS 5 7
1 RTX 6 9
TXR1 Ĵ13 0 4 RXA RXB 7 11
5 RXD 8 12
TXD ij14 3 CDT VSS 9 13
CDL 10 14
OSC1 ij15 2 CLK TXA 11 16
TXR2 12 17
OSC2 ij16 1 VDD TXR1 13 20
TXD 14 22
OSC1 15 23
OSC2 16 24
TXD: Transmitter Digital Input: Entrada en la que se colocan los datos
digitales a transmitir. En logica positiva:
Tension positiva -----> 1 logico o marca. tension 0 V -----> 0 logico o espacio.
TXA: Transmitter Analogue output: Salida de seales analogicas moduladas
en FSK a transmitir hacia linea. El nivel de estas seales depende de
la tension de alimentacion VDD.
TXR1, TXR2 y TRS : Receive Transmit mode select Inputs: Los estados logicos
y conexionados de estas patillas establecen el modo de trabajo del
modem (6 modos).
RXA : Receiver Analogue Input: Entrada de la seal analogica modulada reci-
bida. Debido a las referencias internas de tension, esta entrada ha de
acoplarse a traves de un condensador de paso.
RXD : Receiver Digital Output: Salida que entrega la seal recibida demo-
dulada en forma de corriente de bits.
RXB : Receiver Bias Adjust Input: Permite el ajuste externo, por tension,
de la correccion de la distorsion de los bits en la salida RXD, al
actuar sobre una etapa de comparacion de niveles interna del integrado
que fija el disparo para los niveles logicos que formar n la seal
logica que se entregar en RXD.
CTD : Carrier Detector Output: Permanece en estado bajo, pasando a nivel
alto con un leve retardo cuando es recibida una seal de datos de
nivel suficiente para su deteccion. Es una salida que indica la recep-
cion de la seal de datos.
CDL : Carrier Detect Level Adjust Input: Entrada que permite ajustar el
nivel de deteccion minimo del detector de recepcion.
OSC1 y OSC2: Clock Oscillator Input Output: Entrada (OSC1) y salida (OSC2)
del circuito oscilador de reloj interno del integrado, a las
cuales se conecta un cristal de cuarzo (de 4.4336 Mhz de
frecuencia). Si se usa un oscilador externo, conectar su salida
a la entrada OSC1, y dejar OSC2 en circuito abierto.
CLK : Clock Output: Salida que entrega una seal de reloj, cuya frecuencia
indica cual es la mayor velocidad binaria (baud rate) de trabajo del
modem, ya sea la de transmision o la de recepcion.
RTX : Receiver Testa Output: Esta salida es una salida de un limitador
intermedio del bloque de recepcion.
VDD, VSS : Power Supply Inputs : Alimentacion del integrado. VDD es la
entrada positiva, y VSS la negativa (conectada al substrato del
integrado).
#04.j.- MODOS DE FUNCIONAMIENTO DE LAS TNC's
Debido a la existencia de programas de packet que pueden trabajar con
TNC's externas y/o con TNC's internas emulados en el ordenador, y las
prestaciones de las TNC's externas, hay algunos modos de trabajo en packet
vistos desde el punto de vista del manejo del programa empleado en el ter-
minal, y del funcionamiento de las TNC's.
Algunos de estos modos son los siguientes:
* HOST: (Anfitrion). En este modo la TNC recibe la informacion como si fuera un dispositivo serie "normal", y se encarga de informar al programa del estado del envio, del trafico que se escucha, etc...
Es decir: la TNC realiza todo el trabajo, y el ordenador solo opera
como terminal de datos: el ordenador cuando trabaja, trabaja en "modo
terminal", ha de ser conectado a la TNC, comportandose como un "huesped
de la TNC (que hace de anfitrion o "host").
* Modo BayCom: El modo BayCom es el modo en que trabaja BAYCOM (el programa
BAYCOM original del radioaficionado alem n DL8MBT), en que los datos
son enviados y recibidos a traves de los pins de uno de los puertos
serie (COM) del ordenador, y ya en forma de tramas de AX.25 .
Por tanto, el propio ordenador asume las funciones de terminal de
usuario y de TNC (TNC interna, emulada por software), usando un modem
BayCom para transmitir y recibir los datos ya empaquetados al equipo
de radio. El software para trabajar con este tipo de modems tiene dos
funciones: Uso del ordenador como terminal, y creacion de una TNC
interna virtual, que se comunique con el software de terminal.
Dado que los datos que circulan por el puerto serie ya esta n empaque-
tados de acuerdo con el protocolo sincrono AX.25, y al ser la norma
RS232 asincrona, los programas que usan este modo (p.ej, el BayCom)
necesitar "engaar" la logica del manejo del puerto serie empleado
para conseguir la transferencia de datos correcta entre el puerto serie
y el modem BayCom externo.
Puede considerarse como modo BayCom tambien cualquier modo de opera-
cion con emulacion de la TNC por el ordenador, aunque el puerto empleado
para conexion con el modemasea el puerto paralelo del ordenador (puerto
para impresora). El mismo programa BayCom permite el uso de modems para
puerto paralelo.
* Modo KISS: "Keep It Simple Stupid", literalmente: "Hazlo de forma f cil,
tonto. El modo KISS, a grandes piceladas, es un metodo de funciona-
miento de las TNC's externas, el cual hace trabajar a esta en un siste-
ma pseudo-transparente. Es decir, el terminal envia los datos a trans-
mitir de la manera mas compactada que le sea posible, mediante tramas
con un formato especifico para el modo KISS, y la TNC solo tendraque
coger esta informacion y configurarla en paquetes AX.25 para su envio
al modem y al canal de radio.
En este modo la TNC "pierde" el control sobre los paquetes y se com-
porta cual MODEM "tonto" (tipo BayCom), para entendernos: gran parte
del trabajo lo hace el ordenador, y la TNC solo hace las acciones mi-
nimas necesarias.
La comunicacion entre el ordenador y la TNC es mediante un protocolo
especifico, el protocolo KISS, por el cual se establecen los par metros
de funcionamiento de la TNC en la operacion de packet radio, y alguna
cosa mas (mediante el uso de comandos "KISS").
* Modo SCC . Bajo la definicion de SCC (Serial Communication Card, Tarjeta
de comunicacion serie) se conocen algunas tarjetas que han sido desa-
rrolladas por algunos radioaficionados preparadas para ser conectadas
en el interior del propio ordenador (en uno de los slots de expansion
libres del bus del ordenador), y que incluyen el interface y el modem
para packet radio, y que pueden estar equipadas con varios puertos de
salida, para conectar varios equipos transceptores (tarjetas multicana-
les).
Las tarjetas SCC van conectadas directamente al bus del ordenador,
y contienen el hardware de un puerto serie y el modem de radiopaquete.
A nivel de programas, estas tarjetas funcionan con softwares del tipo
BayCom, es decir, no tienen funcion alguna de TNC, y esta ha de ser emulada por el propio ordenador con el programa adecuado.
Algunos programas como el BayComasoportan tambien este tipo de tar-
jetas, ya que incluyen el driver correspondiente para estas tarjetas.
La conexion de la TNC con el ordenador a traves del puerto serie puede seguir uno de los siguientes modos:
* Conexion normal, donde la conexion es similar a la usada para los modems
BayCom. No es una conexion RS232 normalizada, como ya se ha visto ante-
riormente.
* Conexion segun el modo WA8DED, mucho mas proxima a las conexiones RS232
normalizadas. Se usa con las TNC's de tipo TNC1 de la TAPR y TNC's clo-
nicas; WA8DED (tambien denominado TF) es el firmware que tienen cargado
estas TNC's, y actualmente este firmware soporta la operacion multipuerto
(posibilidad de conectar varios equipos de radio a la TNC a traves de
varios puertos).
El ordenador conectado a la TNC ha de estar trabajar en Modo Host WA8DED, existen algunos drivers de interface terminal para ello.
RS232 DB25 DB9 Modo normal (BayCom) modo WA8DED
DTR - 20 - 4 - Datos para TX (*) (*)
RTS - 4 - 7 - Control del PTT (TX/RX)(*) Control del PTT (*)
CTS - 5 - 8 - Datos en RX. (sin uso)
GND - 7 - 5 - Masa de blindaje. Masa de blindaje
TXD - 2 - 3 - Sin Uso expecifico (*) Datos para TX
RXD - 3 - 2 - Sin uso Datos en RX
Con las lineas marcadas con (*) y utilizando unos diodos puede adi-
cionalmente enviarse alimentacion al modem conectado al ordenador, si hu-
biera un modem conectado en lugar de la TNC, y si fuera un modem de muy
bajo consumo (como en el caso del modem BayCom o de algun interface compa-
tible con WA8DED).
#04.k.- LOS PROGRAMAS UTILIZADOS
Diversos programas existen para packet radio, que permiten mediante el
uso de un ordenador tipo PC (o de otro terminal) operar a un usuario terminal
en packet radio, ya sea usando una TNC externa, como usando un modem BayCom
o de otro tipo, con TNC virtual interna emulada por software, o bien trabajar
con tarjeta de sonido. Algunos programas de los mas conocidos actualmente son
el BayCom, el TPK, el Tsthost (para DOS), el Winpack, el Graphic Packet (GP),
el Tsthwin (version de TstHost para Windows), el AGWPE (AGW Packet Engine,
para Windows), etc...
Algunas caracteristicas generales de estos programas son las siguientes:
Suelen permitir la existencia de varios canales logicos para trabajar
en packet, normalmente estos canales suelen ser un canal de monitorizacion
del trafico de paquetes, y varios canales de conexion (con o sin monitoriza-
cion, segun los casos). La existencia de varios canales de conexion (cada
uno con su pantalla de trabajo) permite mantener varios contactos simultanea-
mente con otras estaciones, aunque estos sean en el mismo canal de radio.
Incluso pueden permitir la posibilidad de usar varias TNC's y/o modems BayCom
distintos conectados a los puertos del PC y asi poder operar simultaneamente
por distintos canales de radio (e incluso con alguna conexion telefonica).
Mediante la funcion de monitorizacion, se puede observar el trafico de
tramas o paquetes en el canal. Normalmente una de las pantallas de trabajo
del programa es solo para monitorizacion, las demas pueden tener monitoriza-
cion o no (o ser opcional). La monitorizacion nos mostrar las tramas inter-
cambiadas entre estaciones que esten en el correspondiente canal de radio, y
podemos ver como se intercambian todo tipo de tramas: I, RR, REJ, SABM...
Esto puede ser util para analizar problemas, si se sabe interpretar toda la
informacion que se muestra en pantalla.
Muchos programas permiten la opcion de que la monitorizacion sea solo
para el tipo de trama que se elija (p.ej, monitorizar tramas I solamente), e
incluso para monitorizar solo las tramas intercambiadas por una determinada
estacion (o por determinadas estaciones).
Cada canal logico tiene asignada una pantalla, que podemos acceder
mediante alguna operacion en el teclado (es corriente asignar cada pantalla
a alguna tecla del teclado. P.ej: 8 canales de conexion y una pantalla de
monitorizacion accesibles mediante las teclas de funcion F1 a F9 respectiva-
mente, caso del programa BayCom).
Suele ser habitual en muchos programas que la pantalla de cada canal
este dividida en varias ventanas, tipicamente tres: Una donde vemos lo que
nosotros tecleamos (comandos o texto para enviar; ventana de transmision),
otra donde vemos lo que recibimos para nosotros (ventana de recepcion), y
la ultima, opcional en algunos programas, donde monitorizamos el trafico
en el canal de radio (ventana de monitorizacion). Solo en la pantalla de
monitorizacion, la ventana de recepcion no existe, y en algunos programas
la ventana de transmision solo es usada para el envio de tramas en modo no
conectado (tramas UI).
En cada pantalla suelen mostrarse algunas lineas diferenciadas, barras
informativas, donde aparecer n informaciones varias, tales como el indicativo
de la estacion que se nos conecte o que nos conectemos en el canal actual,
en otros canales, informaciones de cantidad de bites transmitidos y recibi-
dos, modo de trabajo del programa...
Los programas pueden operar en cualquiera de estos modos:
* Desde el teclado se puede trabajar en modo CMD (COMANDO)‡‡
* y en modo CONV (Conversacion):
Cuando se trabaja en modo CMD, el texto entrado desde el teclado es
reconocido como un comando para ejecutar por el programa en la sesion de
trabajo, es decir, va dirigido al propio programa. Logicamente, han de ser
comandos v lidos del programa, cualquier otro texto entrado no ser recono-
cido como comando v lido por el programa, y lo rechazar con un mensaje de
error.
En el modo CONV el texto tecleado se reconoce como texto y se envia a
la estacion conectada, permitiendo establecer una conversacion con otra
estacion conectada a la nuestra: todo lo tecleado sale por antena, y el
corresponsal lo recibir tal cual.
El modo CONV solo esta permitido en la mayoria de los programas cuando
hay una conexion efectuada con otra estacion, y se activa autom ticamente
cuando la conexion se establece. No obstante se da la posibilidad de que
mediante alguna tecla sea posible cambiar de un modo a otro rapidamente; el
modo de trabajo es indicado de alguna manera en pantalla.
Muchas veces es necesario realizar estos cambios de modo de trabajo
durante una sesion. Por ejemplo, estamos conectados a un BBS y queremos
indicar al programa que nos grabe la informacion que recibamos de esta.
Entonces tendremos que pasar del modo CONV en que estaremos, al modo CMD,
para dar la orden de grabacion al programa con el comando correspondiente,
y una vez dada esta orden, volvemos al modo CONV y seguimos normalmente
trabajando con el BBS.
Ademas, los programas de packet disponen de algunos tipos de buffers
(memorias de trabajo) para poder mirar o recuperar cosas durante la sesion
de trabajo: buffers de teclado, buffers de recepcion... El buffer de teclado
memoriza las ultimas lineas tecleadas, por lo que se pueden recuperar si se
desea en un momento dado. El buffer de recepcion memoriza las ultimas infor-
maciones recibidas en la sesion en curso, por lo que nos permite hojear lo
ultimo que hayamos recibido, aun cuando ya haya desaparecido de la pantalla
reemplazado por la nueva informacion entrante.
Tambien los programas disponen de opciones tales como la posibilidad de
grabar la mensajeria recibida en un archivo de registro o ARCHIVO LOG, enviar
el contenido de un archivo de texto a la estacion conectada, posibilidad de
usar "MACROS" (archivos ejecutables constituidos en formato texto por una
serie de comandos usados por el programa y que se ejecutar n secuencialmente
cuando la macro sea requerida), recoger la informacion enviada por los BBS's
mediante el Unproto (grab ndola en un archivo log especifico para Unproto),
etc...
Los archivos log son archivos de texto que recogen la informacion reci-
bida de las estaciones corresponsales. Ello permite poder examinar posterior-
mente la informacion recibida, para leerla mas tranquilamente, editar sus
contenidos para salvar la informacion que consideremos interesante a otros
archivos de texto (informaciones tecnicas, o cualquier otra de nuestro
interes), etc...
Normalmente en los programas de packet, tanto si ha de manejar una TNC
externa, como un modem BayCom o una tarjeta SCC, se necesita el auxilio de
un programa "driver" adecuado que sirva para operar con el dispositivo uti-
lizado.
Entonces, el ejecutable del programa de packet realiza las funciones
logicas de manejo de la informacion enviada(b sicamente), y maneja
al driver, el cual es entonces un controlador de comunicaciones, que comunica
al programa de packet con el dispositivo de comunicaciones empleado.
Cada dispositivo suele requerir un driver propio: Un programa deber de
usar un driver concreto para trabajar con modem BayCom, otro driver para
trabajar con TNC en modo Host (y puede ademas depender de la TNC usada)...
Los programas de packet pueden operar en alguno de estos casos:
* Modo terminal : Programa de usuario terminal: Es el dirigido al usuario ordinario de la red de packet.
* Modo BBS : La estacion opera haciendo de BBS de packet. Son estaciones
de funcionamiento autom tico, que operan con programas de
packet especificos para este tipo de estacion, tales como
el FBB, el BPQ, el WNOS, el TheNet, el Pavillon, el RMNC/
PCF, etc.. y que permiten realizar trafico de mensajes
entre usuarios de packet radio.
* Modo PMS : La estacion dispone de un "buzon" personal del usuario,
capaz de recoger mensajeria dirigida al usuario de forma
autom tica, enviar mensajeria propia y realizar algunas
funciones que las aproximan algo a las funciones de un BBS,
como la capacidad de poder ser manejados por usuarios
remotos (ademas del propio usuario de la estacion).
Muchos programas de packet para usuarios terminales
disponen tambien de estos modos de trabajo (PMS y manejo
desde remoto).
#05.- PUESTA EN SERVICIO
Sea el caso de una instalacion de packet con TNC externa (para los
casos de TNC emulada interna, bastar en principio arrancar la ejecucion del
programa de packet cargado en el ordenador).
Cuando conecte su TNC, deber ver aparecer en la pantalla un mensaje de
bienvenida del siguiente tipo (caso de la TNC2 de TAPR):
|| A:
Tucson Amateur Packet Radio TNC2 AX.25 level 2 Version 2.0 Release 1.1.4 11/13/86 - 32 kRAM Checksum $21 cmd:
Este anuncio de bienvenida suele indicar el software interno (firmware)
que usa la TNC, y que esta en modo comando (cmd), pero su aparicion es indi-
cativa de que la conexion entre la TNC y el terminal funciona.
Si eso sale lleno de garabatos, algo asi como &tf$d.h#sxn , indica
que los par metros de la TNC y del ordenador no coinciden y ser necesario
volver a revisarlos y entrarlos bien. Es habitual que la primera vez que se
conecte la TNC es raro que funcione a la primera, no se inquiete demasiado
por ello, he aqui algunos puntos a verificar:
* proceda siempre por partes y razone logicamente.
* verifique el terminal:
* Desconecte el terminal de la TNC, si teclea algo no ver nada (la funcion ECHO de su terminal esta en OFF) o ver el car cter que ha tecleado (la funcion ECHO esta en ON); La funcion ECHO (eco) permite ver en pantalla lo que tecleamos, es una funcion del terminal.
* En el DB25 del terminal conecte RD con TD (patillas 2 y 3): debe ver aparecer todo lo que teclea o bien una vez (ECHO en OFF) o bien dos veces (ECHO en ON); Al buclear TD con RD se provoca un eco a traves del conector DB25: Se ha cableado la linea de trans-mision de datos del conector con la de recepcion de datos.
* En estas condiciones su terminal no utilizar las seales RTS/CTS y el control del flujo de datos entre terminal y TNC deber estar
gestionado por el procedimiento XON/XOFF (uso de caracteres especia-
les) y el cableado entre el terminal y la TNC se har con 3 hilos;
* Si no es este el caso entonces su terminal necesita utilizar control
de flujo de datos usando otras seales del puerto serie: reensaye conectando RTS y CTS unidos;
* En estas condiciones su terminal utilizar las seales RTS/CTS, se dir tambien que el flujo de informaciones esta gestionado de forma fisica, y el cableado entre el terminal y la TNC se har con 5 hilos;
* En caso de fallo pruebe tambien con DTR, DSR y DCD (patillas 20, 6 y 8);
* Mientras no haya solucionado el problema del terminal es inutil abordar el apartado siguiente !
* Inserte la TNC, conectele la tension, debe ver el mensaje de bien-venida. Si no es este el caso, el procesador, la EPROM, la RAM o la mitad del controlador HDLC que sirve para terminal pueden ser defectuosos.
* Realice un bucle digital, es decir, conecte RD y TD del controlador
HDLC juntos (quitar eventualmente el o los circuitos integrados del
modem), ponga FULLDUP ON, teclee algo, de nuevo debe obtener una
copia doble de su mensaje. Si falla el test, la mitad del controlador
HDLC que sirve para el port radio puede ser defectuosa.
* Realice a continuacion un bucle analogico (es decir, en AFSK),
uniendo en el conector que va al emisor-receptor RX y TX (atencion:
el nivel de emision deber a menudo ser puesto al maximo) estando FULLDUP en ON, debe obtener una copia doble. Si el testa falla, el modem y los circuitos anejos pueden ser defectuosos.
La mayoria de los errores del nivel RS232 se deben a una velocidad
incorrecta de la TNC o del puerto del ordenador al que esta conectado, un
formato incorrecto de los datos transmitidos entre la TNC y el ordenador o
terminal (numero de bits, numero de bits de stop por cada car cter ASCII
transmitido; el mas habitual es el formato 8N1: 8 bits de datos, no paridad
y un bit de stop), o un cableado RS232 incorrecto.
Si todos los tests son positivos y a pesar de todo no le reciben, habr
que verificar el nivel de modulacion del emisor o ver si no hay "retorno HF".
El error mas frecuente a nivel radio, es tambien una sobremodulacion, escuche
su modulacion con la ayuda de un receptor auxiliar y disminuya lentamente la
modulacion hasta el momento en que la seal de audio disminuya tambien.
#06.- LOS COMANDOS DEL TERMINAL
Es evidente que todos los comandos que describiremos aqui deber n ser
introducidos cuando la TNC este en modo "comando", si no fuera este el caso
habr que enviar desde el teclado la orden adecuada para ello (p.ej. un
CTRL C en muchas instalaciones de packet con TNC externo), que generar en
pantalla el prompt "cmd:" caracteristico del modo comando.
La mayoria de los comandos esta n seguidos por un argumento (de un valor)
que puede ser un numero (del que daremos los limites) o un valor logico (ON u
OFF = Si/no). Los nombres de los comandos descritos aqui son los mas usua-
les, aunque el nombre del comando podria variar de unas TNC's a otras (e
incluso de unos progamas de packet a otros).
Los comandos pueden ser introducidos tal y como se representan aqui, o
de modo abreviado (p.ej, solamente los 2 o 3 primeros caracteres), consulte
el manual de su TNC. Si se introducen en modo abreviado, el programa de
packet empleado suele requerir un minimo numero de caracteres del nombre del
comando para reconocerlo, con menos caracteres no lo reconoce.
Los comandos descritos son los correspondientes a la TNC2 de la TAPR,
para otras TNC's habr n comandos similares.
La funcion de eco permite ver en la pantalla terminal lo que escribe en
el teclado.
La mayoria de los terminales generan de oficio el eco, pero si no fuera
el caso, su TNC podria encargarse de ello si teclea ECHO ON. Entonces cual-
quier car cter tecleado ser transmitido por la linea TD del RS232, su TNC
har el eco, retransmitiendolo por RD del RS232 hacia el terminal.
Si el eco se realiza a nivel del terminal y a nivel de la TNC ver
aparecer todos los caracteres dobles, ya que tanto terminal como TNC generan
cada uno de ellos un eco, y ser suficiente entonces poner ECHO OFF para
suprimir el eco de la TNC.
La mayoria de los terminales generan un retorno de carro autom tico (LF)
despues de cada retorno de carro (CR de fin de linea). Si no fuera el caso,
se puede realizar por medio de la TNC tecleando AUTOLF ON .
La TNC y el terminal deben funcionar a traves de la union RS232 con
longitudes de palabra identicas. Habitualmente se puede elegir entre 7 y 8
bits por car cter. Por defecto la TNC trabaja con 7 bits. Si su terminal no
sabe trabajar mas que con 8 bits, ser suficiente teclear AWLEN 8 para que
la TNC pase a trabajar con 8 bits por caracter (AWLEN 7 para volver a 7 bits
por car cter).
De la misma manera la TNC y el terminal deben trabajar con la misma
paridad; por defecto, se elige la paridad impar porque la mayoria de los
terminales trabajan en paridad impar. Aqui tambien, en caso de conflicto, se
puede adaptar la TNC al terminal:
PARITY 1 : paridad impar
PARITY 2 : sin paridad
PARITY 0 : paridad par
La mayoria de las pantallas tienen una anchura de 80 caracteres (por
linea), si no fuera el caso el comando SCREENLN n (donde 0<n<255 ) permite
hacer una presentacion en pantalla con cualquier numero, despues de enviar
un CR-LF.
El comando LCOK OFF permite convertir las minusculas ("Lower Case") en
mayusculas ("Uper Case") en el caso de que el terminal no acepte las minus-
culas.
Cuando su terminal, o su ordenador este ocupado en otras tareas (acceso
a disco, impresora, ...) es necesario poder controlar el flujo de datos entre
el terminal y la TNC. Esto puede hacerse por medio de seales electricas
(... fisicamente, a traves de las lineas del puerto del ordenador), o por
software, mediante caracteres especiales (...de manera logica: control por
caracteres Xon/Xoff).
Cuando el flujo se controla de forma fisica se utilizan las seales
RTS/CTS, hay que poner entonces XFLOW OFF (control logico deshabilitado).
Por contra si el flujo se controla de forma logica, hay que poner XFLOW ON,
la TNC reconoce entonces los 2 caracteres XON, XOFF a los que se atribuye
los valores estandarizados ASCII 11 y ASCII 13 respectivamente.
#07.- LOS COMANDOS DEL PORT RADIO
Las velocidades de transmision usuales del port radio, son, como hemos
comentado anteriormente, de 300 baudios en HF o de 1200 bits/seg en VHF-UHF,
y mas modernamente, 9600 baudios en UHF. Habitualmente se selecciona en la
TNC por medio de interruptores DIP (miniatura), y su eleccion entraa la
seleccion y utilizacion autom tica del modem apropiado, a saber Bell 103
para los 300 bits/seg y Bell 202 para los 1200 bits/seg.
Una serie de comandos, que suelen ser los mismos para diferentes TNC's,
son utilizados para definir las caracteristicas de la transmision de los
paquetes por el puerto de radio. Los mas caracteristicos suelen ser los
siguientes:
HBAUD : Velocidad de trabajo. Este comando o alguno similar existir cuando
se pueda seleccionar por comando la velocidad de transmision por el
el puerto de radio (1200 o 300 baudios).
TXDELAY N : Tiempo (N x 10 mseg) desde que la TNC activa el PTT (iniciando
el envio de la portadora de datos) hasta que lanza los datos.
Con esto se garantiza que en el paso de recepcion a transmision
para el envio de paquetes se tiene en cuenta el tiempo que tardan
los reles de conmutacion de TX/RX en bascular (en equipos antiguos,
en amplificadores lineales externos conectados al equipo de radio)
y el tiempo de estabilizacion del VCO (de la frecuencia de trans-
mision) antes del envio real de los paquetes de datos. El valor de
TXDELAY depender del equipo utilizado, y suele esta r comprendido
20 (200 mseg) para equipos de conmutacion rapidos, y 50 (500 mseg)
con los mas lentos.
Un TXDELAY largo favorece ademas la recepcion de nuestros paquetes
a equipos que tienen squelchs lentos de apertura.
Un valor adecuado para la mayoria de los casos puede ser el de 30
(300 mseg).
MAXFRAME N : (N de 0 a 7) M xima cantidad de paquetes que pueden ser envia-
dos quedando a la espera de la confirmacion del corresponsal (es el
par metro K en AX.25).
Un MAXFRAME alto da lugar a que en la misma transmision se envien
varias tramas sucesivas (hasta completar las N que esten pendientes
de ser confirmadas), por lo que el tiempo de la transmision es un
poco largo, y esta muy expuesto a colisiones si en el canal de
radio hay mucho trafico packet (Usar entonces un MAXFRAME bajo, de
por ejemplo, 1 o 2, si el enlace es de mala calidad, o en HF). Para
buenos enlaces en VHF se recomienda un valor de 4.
PACLEN N (N= 1 a 255): Numero de caracteres maximo del campo de informacion
en el paquete: Fija el tamao en bits del campo de informacion de
las tramas I (par metro N1 en AX.25). Un valor alto permite trans-
mitir paquetes con mayor rapidez (se necesitan menos paquetes I
para transmitir un mismo mensaje, y hay menos tramas de confirma-
cion), pero al ser paquetes de duracion mas larga, esta n mas
expuestos a las interferencias y colisiones accidentales. Un valor
recomendado es el de PACLEN 128 para los enlaces en VHF de buena
calidad. Con estaciones muy proximas se puede aumentar este valor,
mientras que con estaciones lejanas es mejor disminuirlo.
Para transmisiones en HF se usan Paclen mas bajos, debido al ruido
de estas bandas y a la menor velocidad de transmision empleada (300
baudios), lo que hace mayor el riesgo de que los paquetes recibidos
se reciban con interferencias o colisiones.
SENDPAC $13 : determina el car cter que forzar a la trama a ser transmitida
desde el terminal, incluso si no se llega al valor PACLEN; este
car cter es por defecto el CR o RETURN (valor hexadecimal de 13).
RETRY N : Es el numero N de reintentos o tentativas en el envio de un paque-
te de informacion I cuando este paquete no es confirmado por el
corresponsal, o de intentos de conexion (Paquetes SABM).
Superado el numero de intentos del valor de retry sin recibir la
confirmacion por el corresponsal, la TNC deber de realizar la des-
conexion autom ticamente (por entenderse que falla la conexion o
la estacion de nuestro corresponsal, o que esta no nos oye por el
motivo que sea). La TNC mostrar en la pantalla del terminal un
mensaje similar al siguiente:
*** retry count exceeded (numero de reintentos excedidos)
*** DISCONNECTED (desconectado)
El tiempo que media entre el envio de un paquete y su nueva retras-
mision vendr dado por el par metro FRACK.
Se recomienda un valor de 5 a 10 reintentos como valor optimo.
El valor 0 suele indicar numero de reintentos ilimitado.
FRACK N : (timer T1 de nivel 2 de AX.25) Indica el tiempo N de espera (en
segundos) antes de repetir el envio de un paquete, si no llega ningun reconocimiento del anterior enviado.
Aunque se puede fijar en el programa en un valor inicial (recomen-
dado entre 4 y 7 segundos), muchos programa suele adaptar el FRACK
(Frame ACK o Timer 1) durante una conexion de acuerdo al tiempo de
respuesta de los paquetes del corresponsal.
Con HBAUD en 300, Frack se suele desactivar autom ticamente, ya que esta demostrado que no se debe utilizar en HF.
Si la transmision es via digipeater, se recomienda el siguiente valor para el FRACK:
FRACK = ( 3 x (2 x numero de digipeaters +1)
DWAIT N : Tiempo (medido en N x 10 mseg) desde que el canal de radio es
detectado como libre hasta que se ordena el inicio de la transmi-
sion. A este valor se le suma una variable aleatoria para minimi-
zar el riesgo de colisiones entre estaciones de packet que operen
en el mismo canal de radio. Las colisiones tienen lugar cuando dos
estaciones transmiten al mismo tiempo, y ello da lugar a que la
estacion que recibe las tramas no las reciba correctamente: se
generan tramas REJ o no hay confirmaciones de tramas.
Con enlaces en canales muy ocupados donde se necesita mas tiempo
para el envio y recepcion de paquetes, deber aumentar el valor
de Dwait: Lo contrario hace que puedan haber muchas colisiones de
paquetes, y por tanto se ralentice aun mas la operacion en packet,
al generarse muchas tramas REJ y haber por tanto mucha repeticion
de envios de paquetes; con un DWAIT largo la posibilidad de "coli-
sion" disminuye mucho y por tanto el uso del canal mejora.
Los BBS y digirepeaters tienen un DWait muy bajo, para poder
emitir con prioridad una vez la frecuencia queda libre.
Un valor normal es el de 16 (160 mseg).
Un valor pequeo acelera la comunicacion, pero si se excede un
cierto valor logico se pueden generar multitud de reenvios de
paquetes, haciendo el canal poco operantivo.
SLOTTIME : El slottime tambien se aplica como temporizacion en los progra-
mas que usan el metodo de la persistencia para minimizar las colisiones entre estaciones, para intentar la transmision.
Un valor tipico puede ser 3 o 4.
AXDEL N, TXDEL N, AXHANG N : Se podria tambien utilizar un repetidor de
fonia para enlazar las seales de packet. Esta tecnica es muy
popular en los Estados Unidos, pero no se utiliza en Europa.
El retardo AXDEL n (donde 0 < n < 250 y esta expresado en unida-
des de 10 ms) se aade al retardo TXDEL a fin de estar seguro de
que el repetidor este conmutado en posicion de transmision.
La mayoria de los repetidores de FM fonia continuan transmitiendo
una portadora no modulada un cierto tiempo incluso en ausencia
de seal de entrada una vez cesa la seal entrante, y como la TNC
hace una deteccion de portadora BF, es necesario incluir un
tiempo adicional antes de pasar a transmision, fijado con el
comando AXHANG n (donde 0 < n < 20 y esta expresado en 100 ms).
PACTIME : Ajusta el tiempo de envio de los paquetes desde que son creados
en modo transparente, o en modo conversacion si CPACTIME esta en
"ON". Como subcomandos permite EVERY N o AFTER N, donde N fija
este tiempo (N x 100 ms) de manera que con EVERY cada 100 x N ms
se envia un paquete de informacion, y con AFTER despues de n*100
ms sin ningun caracter tecleado envia el paquete, dentro de la
misma transmision.
Para otras TNC, pactime adopta directamente la sintaxis PACTIME N.
RESPTIME N : Tiempo de espera (N x 100 ms) antes de enviar el reconocimiento
de los paquetes recibidos. Si este valor se deja a 0, puede ser
que el reconocimiento de los primeros paquetes enviados colisione
con el envio de los ultimos paquetes con informacion.
Un valor adecuado puede ser de 7 a 10.
PPERSIT N : Fija el par metro de comparacion (N) de las rutinas pseudoalea-
torias que utilizan los programas de Packet dotados del metodo de
persistencia para obviar el problema de las colisiones, y por
tanto fija la probabilidad de que una trama no haya sido recibida
por el corresponsal a causa de una colision, y deba de ser nueva-
mente retransmitida. Ello conduce a un tiempo aleatorio para la
retransmision del paquete (y no fijo como ocurre con la transmi-
sion inmediata al vencer FRACK en algunos programas).
Cuando la TNC deba pasar a emision, espera a que el canal de
radio este libre, genera despues un numero aleatorio ( 1<n<255 ).
Si este numero es menor o igual al par metro PERSIST, la TNC
pasar inmediatamente a emision, en caso contrario, espera un
tiempo especificado par SLOTTIME n (donde 0 < n < 255, y est
expresado en unidades de 10ms), despues genera un nuevo numero aleatorio y lo compara de nuevo con PERSIST, repitiendose de nuevo el proceso.
El par metro SLOTTIME esta asociado a estas rutinas pseudoalea-
torias.
El par metro de persistencia N adopta valores de 0 a 255. Un
valor normal en un canal denso de trafico es de 64 y en un canal
vacio puede ser 128 o mas.
LINKTIME N: Periodo de tiempo (timer T3 en AX-25) usado para comprobar la
o CHECK N inactividad en el enlace si no se esta efectuando trasferencias
de informacion en la conexion (Tiempo de observacion de enlace
inactivo por no envio de tramas I) .
Se realiza un testa cada N segundos con el fin de determinar si la
estacion distante esta activa en caso de que no haya intercambio
de datos. Este testa utiliza tramas del tipo RR:
En cada testa se enviar al corresponsal una trama RR,P.
Si se recibe una trama RR,F , indicar que el corresponsal est
todavia activo, y que la conexion entre ambas estaciones sigue
establecida.
En caso de no respuesta despues de varios ensayos (RETRIES) se
activa un procedimiento de desconexion, por entenderse que la
otra estacion no esta presente.
DISCTIME N : Tiempo de espera (segundos) para desconectar a una estacion
que no envia ningun dato. Ajustar a varias decenas de segundo.
TXTAIL N: Tiempo que seguir en transmision el transmisor despues de haber
mandado todos los paquetes, pasado este se desactiva el PTT para
pasar el equipo de radio a recepcion.
Este tiempo no se tiene en cuenta en operaciones normales, por lo
que su valor ser TXTAIL 0. Solo se emplea en casos muy concretos.
Para optimizar el uso del canal de radio, hay dos modos basados en los
anteriores par metros: El primero usa las temporizaciones basadas en los
par metros DWAIT, FRACK y RESPTIME. Es el mas utilizado, pero no el mas
optimo. El segundo modo basado em PERSIT y SLOTIME es mucho mejor si todas
las estaciones en el canal lo utilizan.
#08.- LOS COMANDOS DE IDENTIFICACION
A fin de modificar su indicativo y su SSID, se utiliza el comando
MYCALL. Habitualmente TODAS las estaciones utilizan el SSID "-0".
MYCALL indicativo : Con este comando ponemos el indicativo de la estacion
que saldr autom ticamente en los campos de direccion de los paquetes
(identifica quien envia el paquete). Algunas TNC's no funcionan si
no se expecifica el MYCALL, otras si funcionan, pero entonces ponen
como indicativo de identificacion de la estacion en los paquetes "NOCALL" (no indicativo), que no ser reconocido o validado por las demas TNC's.
En el MYCALL el indicativo de la estacion ir acompaada del SSID de la
estacion. Si no se expecifica el SSID, por defecto este toma el valor cero.
El SSID, se comento, define el tipo de estacion de packet radio que se
esta usando. Siempre se expresa con un guion delante del valor del SSID.
Las estaciones de packet normales tienen como SSID el "-0", y solo otros
tipos de estaciones usan otros SSIDes. Normalmente el SSID sale reflejado en
la pantalla (al observar el trafico de packet en un canal de radio) cuando
no es "-0". Cuando no sale reflejado es porque el SSID toma el valor "-0".
Por defecto, el SSID de una estacion es 0, salvo que se indique lo contrario.
DCALL indicativo : Indicativo empleado por la estacion de packet, cuando
opere como estacion digipeater.
Es similar al mycalls (indicativo de estacion) pero con
diferente SSID.
#09.- LOS MODOS DE COMANDO, DE CONVERSACION Y TRANSPARENTE
En el modo de comando la TNC2 de TAPR envia el prompt cmd: indicando
al operador que espera un comando. Algunos comandos han sido descritos antes.
El modo de conversacion es aquel mediante el cual se "conversa" con su
corresponsal, todo lo que se escribe en el teclado es transmitido integra-
mente hacia el corresponsal distante.
Ciertos caracteres son interpretados como comandos y la TNC interpretar
por ejemplo un CTRL C como una solicitud de paso a modo comando, esto puede
ser muy molesto en caso de transmision de ficheros o mensajes en el modo
conversacion que incluyan esos caracteres.
Para evitar este problema se introduce el modo transparente, donde todos
los caracteres ser n transmitidos. Opera como el modo conversacion, pero
evita que los caracteres usados como comandos sean interpretados como coman-
dos. Para volver al modo de comando habr que teclear 3 veces un caracter
especial.
#10.- OPERACION EN PACKET
(Los comandos mencionados son los usados por la TNC2 de TAPR, para otras
TNC's, externas o emuladas por software, han de existir comandos similares).
#10.a.- EL ESTABLECIMIENTO DEL CONTACTO
Supongamos que ON1KAN quiera entrar en comunicacion con ON5AV, estando
la TNC de ON1KAN en modo comando, teclea entonces: CONNECT ON5AV, la TNC
envia una peticion de conexion (Una trama SABM dirigida a ON5AV). Si la TNC
admite comandos en el modo abreviado (suele ser lo mas usual), este comando
podria ser simplemente: C ON5AV .
Conviene hablar aqui del comando NEWMODE que en posicion ON hace cambiar
a la TNC del modo comando al modo conversacional o transparente desde que se
establece la conexion.
El modo al cual es conmutado esta determinado por CONMODE CONV (para el
modo conversacional) o CONMODE TRANS (para el modo transparente).
La TNC envia entonces peticiones de conexion hasta que esta sea esta-
blecida, o hasta que el numero maximo fijado de tentativas ("retries") se
alcance. En este caso la TNC enviar al terminal el mensaje:
*** retry count exceeded (numero de tentativas excedidas)
y *** DISCONNECTED (desconectado)
Si su corresponsal esta ocupado recibir el mensaje:
*** ON5AV busy (ON5AV ocupado)
y *** DISCONNECTED (desconectado)
Si por fin, asi lo esperemos, se establece la conexion, se recibir :
*** CONNECTED to ON5AV. (conectado a ON5AV)
Muchas TNC's, al producirse la conexion, pasan autom ticamente del modo
Comando al modo Conversacion o al modo Transparente. Una vez en el modo
conversacion, puede pasarse al modo comando (si se desea ejecutar un comando
de programa durante la conversacion) con alguna combinacion de teclas espe-
cificas (CTROL C para TNC's, o Escape para el programa BayCom, tipicamente),
y volver de el al modo conversacion usando la mismas teclas.
#10.b.- INTERCAMBIOS DE INFORMACION
Contrariamente a los otros modos utilizados en el dominio amateur, no
debe esperar a que su corresponsal le ceda la palabra (... o el teclado),
desde que se establece la conexion, puede introducir su texto en el teclado,
que ser enviado inmediatamente, en tramas I, en cuanto se detecte que el
canal esta libre.
El packet radio permite la transmision de textos, mensajes y cualquier
cosa que este escrita en modo texto, esto es, en caracteres ASCII, como
puede ser el contenido de un archivo de texto. No permite la transmision
directa de programas de ordenador, esto es, de archivos binarios, si no es
recurriendo a determinados procedimientos.
El texto a transmitir es fraccionado en trozos, con los cuales se re-
llenar n los campos de informacion de las tramas I que van a sevir para
enviar el texto. El numero de caracteres ASCII que puede contener el campo
de informacion de una trama I es como maximo, 255, y se fija con el comando
PACLEN. Una particularidad a tener en cuenta es que en los textos transmiti-
dos y recibidos, el final de cada linea esta marcado unicamente por el
car cter CR ("retorno de carro"). Los antiguos ordenadores AMIGA usaban este
final de linea en sus archivos de texto, pero los ordenadores personales PC
de IBM y compatibles usan como final de linea el car cter CR seguido del
car cter LF (avance de linea). Por ello, los programas de terminal Packet,
si este es un PC o compatible, han de dar lugar a que en el envio de los men-
sajes se suprima el caracter LF que sigue a cada CR en los finales de linea,
y en los mensajes recibidos han de aadir LF tras cada CR, salvo que recoja
el fichero recibido en modo binario (recibido en "MODO TRANSPARENTE").
#10.c.- El FIN DEL CONTACTO
Un contacto radioamateur se termina habitualmente por un "73 see you
later..." (73, nos veremos mas adelante) o similar. En packet, hay que aadir
una etapa adicional: habra que desconectar su TNC.
Si esta en modo conversacion (lo mas seguro) habr que pasar primero al
modo comando mediante CTRL C (o comando similar).
Si esta en modo transparente, ser necesario enviar 3 veces CTRL C en
un tiempo inferior al especificado por CMDTIME n (donde 0 < n < 250 y expre-
sado en segundos).
En uno u otro caso recibir entonces el prompt cmd:, podr entonces
desconectarse enviando DISCONNECT (o abreviado D), y el terminal presentar :
*** DISCONNECTED. (Desconectado).
De hecho, la desconexion es reconocida como tal cuando la estacion de
packet a la que estamos conectados nos ha enviado una trama UA a nuestra
solicitud de desconexion, realizada con el envio de una trama DISC. Entonces
se ha producido la desconexion completa del enlace.
El caracter de control que permite pasar a modo comando puede tambien
ser modificado gracias al comando COMMAND n , donde N es el valor hexadecimal
del caracter de control.
#10.d.- VIGILANCIA DE LA ACTIVIDAD DE PACKET RADIO (MONITORIZACION)
Una TNC es capaz tambien de presentar en pantalla el trafico escuchado
y establecer una lista de las diferentes estaciones que esta escuchando.
Los comandos que se citen, salvo indicacion en contra, corresponden a
la TNC2 de TAPR. Para otras TNC's habr n comandos similares con las mismas
funciones.
La presentacion en pantalla se obtiene gracias al comando MONITOR. Si
esta activado (puesto a ON: MONITOR ON) se presentar en pantalla el trafico
en el canal, incluyendo los paquetes de estaciones a las cuales no se est
conectado. Si se desactiva la monitorizacion (MONITOR OFF) solo se mostrar n
los paquetes enviados por la estacion a la que se esta conectado.
En algunas TNC's, por ejemplo, los PK-232, se seleccionan las funciones
de monitorizacion con un numero entrado a continuacion del comando monitor,
por ejemplo MONITOR 3, o simplemente M 3. Esto hace que se seleccione la
clase de paquetes que se deseen monitorizar (I, UI, REJ...).
En otros programas de packet, que generan TNC's internas emuladas (p.ej
el programa BayCom), hay una monitorizacion constante del trafico de packet
que escucha la TNC (emulada). Ello se consigue dividiendo la pantalla en
varias ventanas, siendo una de ellas empleadas para visualizar lo que llega
con destino a nuestra estacion, y otra para monitorizar el trafico de packet
escuchado.
Tambien suele ser normal en muchos programas de packet que se dedique
una pantalla completa solo para monitorizacion, pantalla accesible al pulsar
una tecla concreta.
Las informaciones aparecen entonces, en el caso de la TNC2 de TAPR, bajo
la forma del siguiente ejemplo:
ON5WB-2>ON5DX:He reservado 30 plazas para la comida con los amigos de
Nancy ... es suficiente?
El signo > separa el destinatario del expedidor, y los : separan los
indicativos de la informacion. El primer indicativo es la estacion que envia
(ON5WB), el segundo la estacion destinataria (ON5DX). Estos datos son la
cabecera del paquete, y pueden presentarse en linea aparte de la informacion
que transmite el paquete (si es del tipo I), mediante el uso del comando
HEADERLIN (linea de cabecera). Si esta a ON, el paquete anterior ser
presentado de la siguiente forma:
ON5WB-2>ON5DX:
He reservado 30 plazas para la comida con los amigos de Nancy ... es sufi
ciente?
Se puede tambien vigilar el trafico durante una conexion ya establecida
gracias al comando MCON:
Con MCON ON se monitoriza todo el trafico del canal de radio.
Con MCON OFF se anula esta opcion. Solo se monitorizan paquetes I.
MCON permite la monitorizacion de todas los paquetes que se envian por
el canal, de todas las estaciones que envian y para todo tipo de tramas.
Es posible tambien saber los digipeaters utilizados gracias al comando
MRPT ON y las tramas aparecer n entonces bajo la forma siguente:
ON7PC> ON7KL,ON7LE,ON5EB,ON1KLM*: Desolado, quedo qrt ahora, te volvere
a llamar hacia las 21 horas ...
El asterisco * indica la estacion que ha enviado el paquete recibido, y
que es un repetidor digital (ON1KLM en el ejemplo; el mensaje no se ha reci-
bido directamente del expedidor, ON7PC).
Con MRPT OFF, solo se presentar n los paquetes de la estacion origen y
destino que los generan, no aparecer n los indicativos de los repetidores
utilizados en la conexion.
Puede ser tambien interesante tener informacion relativa a la fecha y a
la hora que se ha recibido la trama. El comando MSTAMP, puesto a ON, permite
presentar para cada trama recibida la fecha y hora de los paquetes recibidos.
Con la opcion OFF estos datos no se muestran. La fecha y hora la pone la TNC
a cada trama recibida, no son datos que se envien en los paquetes.
Un ejemplo de como se muestran las tramas recibidas, caso del programa
BayCom (con emulacion de TNC interna):
T:58 00:32 ON7PC>ON1KLM>I07,C,F0: Desolado, quedo qrt ahora, te volvere
a llamar hacia las 21 horas ...
En este caso se informa al usuario de mas cosas: hora de envio de la
trama (00:32), tipo de trama (trama I), numero de trama I enviada y de trama
I pendiente de recibir (0 y 7 respectivamente), y otros datos.
Cada programa de packet tendrasu propia sintaxis para presentar las
tramas monitorizadas en pantalla.
Las TNC's externas poseen un reloj interno que hay que poner en hora
primero, y ello puede realizarse con el comando DAYTIME yymmddhhmm , donde
yy es el ao, mm el mes, dd el dia del mes, hh la hora y mm los minunutos.
Se puede tambien elegir entre el formato americano (mm/dd/yy) o el formato
europeo (dd-mm-yy) gracias al comando DAYUSA ON u OFF.
Es importante que el reloj de la TNC este puesto en la fecha y hora
correcta si se desea que el comando MSTAMP muestre la fecha y hora correcta
de las tramas recibidas, si esta a ON.
De todas formas el reloj no es preciso, pero se puede ajustar gracias
al comando CLKADJ n donde n representa un numero de 0 a 65535. Hay que sea-
lar que la hora se pierde con cada corte de alimentacion.
Cuando se haya puesto el reloj en hora, es posible pedir MSTAMP ON, lo
que har aparecer el dia y la hora en que se ha recibido la trama, por
ejemplo:
ON5WB-2>ON5DX[07/20/88 12:34:45]:He reservado 30 plazas para la comida
con los amigos de Nancy ... es suficiente?
Esta presentacion puede estar bastante sobrecargada a veces, el comando
HEADERLN ON puede paliar este inconveniente presentando la informacion bajo
la forma:
ON5WB-2>ON5DX[07/20/88 12:34:45]:
He reservado 30 plazas para la comida con los amigos de Nancy ... es suficiente?
(Se separa la informacion enviada de la cabecera: se diferencian en lineas
distintas la cabecera de la trama de lo que se envia en el campo de infor-
macion de las tramas I).
El reloj interno puede servir tambien para fechar los mensajes de cone-
xion a condicion de haber puesto CONSTAMP ON, el mensaje aparecer entonces
bajo la forma:
*** CONNECTED to ON7LE [03/08/88 12:23:34]
Se puede obtener la lista de las estaciones escuchadas pidiendo MHEARD,
lo que dar la lista de las 18 ultimas estaciones escuchadas (20 en el caso
del programa BayCom) bajo la forma:
ON6YO-5 27/02/89 20:57:33
ON6YO* 27/02/89 20:57:32
ON4AWP-2 27/02/89 20:57:27
ON1BGX* 27/02/89 20:55:29
ON7NU 27/02/89 20:54:51
ON1ANR-2 27/02/89 20:53:29
ON1BBO 27/02/89 20:51:47
ON6MR-15 27/02/89 20:51:32
ON4LC 27/02/89 20:50:10
ON7NU-5* 27/02/89 20:48:25
ON5EB 27/02/89 20:42:55
ON7JB 27/02/89 20:38:43
ON1ANI 27/02/89 20:24:01
ON4OR-15 27/02/89 20:21:53
ON7VM 27/02/89 20:21:15
ON1BGX-5 27/02/89 20:18:29
ON4OR* 27/02/89 20:11:00
ON1BBO-2 27/02/89 20:07:32
El asterisco significa que esta estacion ha sido escuchada a traves de
un digipeater.
La fecha y la hora no aparecen mas que si MSTAMP esta ON y la lista
puede ser puesta a cero gracias a MHCLEAR.
La TNC permite tambien un monitoreo selectivo, se debe introducir una
lista de como maximo 8 indicativos y SSID de las estaciones gracias a
LCALLS CALL1,CALL2,... CALL8. Entonces en la monitorizacion del canal de
radio solo se visualizar el trafico donde esten implicadas las estaciones
declaradas con el comando LCALLS (indicativos CALL1, CALL2...), es una
monitorizacion selectiva. Pero si entonces se usa el comando BUDLIST ON, lo
que conseguimos es eliminar todas las tramas que provengan de estas estacio-
nes (se excluyen de modo selectivo en ese caso la monitorizacion de las
tramas en las que esta n implicadas las citadas estaciones).
Otra forma de proceder es la utilizacion del comando MFROM CALL1,...
,CALL10 que permite eliminar los mensajes que provengan de una de estas 10
estaciones, o el comando MTO CALL1,..., CALL10 que permite eliminar los
mensajes destinados a una de estas 10 estaciones.
Estos comandos aceptan tambien ALL y NONE como indicativos (en lugar
de los indicativos de estacion CALL1,.....,CALL10).
MALL permite vigilar tanto las tramas entre estaciones conectadas como
entre estaciones no conectadas (tramas UI, como son las balizas, los unpro-
tos...).
Finalmente, hay programas que permiten la monitorizacion selectiva
segun el tipo de tramas (monitorizar solo las tramas I, solo las de supervi-
sion...).
#10.e.- CONTROL DE LOS PARAMETROS DE LA TNC
El comando DISP permite presentar la lista de los parametros. Para
conocer el valor particular de un par metro, basta introducirlo en el teclado
sin argumento. Por ejemplo, para conocer el MYCALL, basta teclear MYCALL para
tener la respuesta MYCALL ON7PC-3 (o similar).
#10.f.- LA CONEXION CON SU PROPIA ESTACION
El protocolo AX.25 permite, a fin de experimentacion, conectarse con
su propia estacion. Si por ejemplo ON5AV quiere conectarse a si mismo via
ON1KAN utilizado en digipeater, basta teclear el comando C ON5AV V ON1KAN.
Todo lo que transmita ON5AV le ser reenviado por ON1KAN.
#10.g.- LAS CONEXIONES MULTIPLES
Una TNC se puede conectar a 10 estaciones simultaneamente. Cada uno de
los contactos es gestionado en un canal que lleva una letra de la A la J pero
se puede limitar el numero gracias al comando USERS n, donde n es un numero
de 1 a 10.
Los canales de conexion son canales "logicos", que pueden estar en el
mismo canal de radio o en distinto canal de radio, en este ultimo caso solo
si la TNC tiene posibilidad de conectarse a traves de varios puertos de radio
a distintos equipos de radio. Lo que se consigue entonces al operar en varios
canales de conexion logicos es diferenciar en el mismo canal de radio, o en
distintos canales, las tramas que se envian y reciben en funcion del corres-
ponsal (afecta al campo de direccion de las tramas).
Para pasar de un canal a otro, hay que encontrarse en modo comando y
pedir |B, la TNC cambia de canal y presenta entonces |Bcmd: a partir de
entonces todo comando se dirigir al canal B, las tramas recibidas estar n
precedidas de |B . Lo mismo se usar para pasar a otro canal (|C, |D...).
Todo mensaje introducido por el teclado estar precedido de |n , donde
n indica el canal por el que debe ser transmitido.
Con otros programas incluso se generan pantallas distintas para cada
canal logico de conexion, pudiendo pasar de una pantalla a otra con una
simple operacion desde el teclado, y que autom ticamente implica pasar a
trabajar en ese canal de conexion logico: Lo que se teclee se enviar auto-
m ticamente al corresponsal con el que estamos conectados en el canal logico
cuya pantalla hemos seleccionado.
El comando CSTATUS permite obtener una lista tal como:
A stream - Link state is: CONNECTED to ON1KJR VIA ON5VL-2 B stream - IO Link state is: CONNECT in progress C stream - Link state is: CONNECTED to ON1KTA D stream - Link state is: DISCONNECTED etc ...
Esta lista nos informa del estado de cada canal logico. El IO indica
que todo lo que se introduce en el teclado ser transmitido hacia ese canal
(pues estaremos seguramente en la pantalla correspondiente a ese canal).
Tambien es posible aadir el indicativo de su corresponsal gracias al
comando STREAMCA ON, los mensajes aparecer n bajo la forma:
|A:ON1KJR: Te agradezco el ultimo programa que ...
Personalmente encuentro que con mas de 2 interlocutores (dos conexiones
logicas distintas), es muy dificil tener una conversacion coherente.
#10.h.- OPERACION REMOTA
Hasta ahora el control de la estacion de packet radio es realizada por
el operador de la estacion desde el terminal: configuracion de la TNC, envio
de comandos, etc... Sin embargo algunas TNC's (reales o virtuales emuladas
por software) permiten que estaciones remotas que se conecten a nuestra
estacion de packet radio, puedan manejar esta con los propios comandos del
programa, y que el operador de la estacion usaria normalmente desde su ter-
minal. Este tipo de operacion es operar la TNC en MODO REMOTO por otras
estaciones.
En modo remoto es peligroso que cualquier estacion remota que se conecte
a nuestra estacion pueda manejar todos los comandos disponibles para gober-
nar esta, ya que la malicia o un mal hacer de algun usuario remoto nos puede
provocar daos graves en nuestro ordenador. Por ello los programas de packet
que admiten la operacion desde remoto limitan esta de una o varias maneras:
* La mas evidente: Con la opcion de permitir o no el uso del modo remoto.
* Limitando el numero de comandos para operar en modo remoto a comandos que
no son peligrosos para nuestro sistema: Comandos de lectura de archivos,
de grabar archivos en nuestro ordenador, etc...
* Limitando los directorios de nuestro ordenador a los que se tiene acceso
en modo remoto.
* Solo aceptar el acceso al modo remoto mediante el uso de "password" o
palabra clave, que solo facilitaremos a estaciones que sabemos que har n
buen uso de nuestra estacion en modo remoto.
Normalmente para usar el modo remoto (si lo permite nuestro programa de
packet radio con nuestra TNC), las estaciones distantes se conectar n a la
nuestra como es habitual (usando su comando CONNECT), y una vez conectado a
nuestra estacion (canal logico establecido), puede usar los comandos de
nuestro programa de packet autorizados para modo remoto, siempre que los
identifique como comandos en modo remoto. Esto depender del programa de
packet que empleemos en nuestra estacion. Asi, con el programa BayCom, los
comandos en modo remoto deben de ir precedidos de e//e para ser reconocidos
por nuestro progama como comandos remotos y no como texto enviado a nuestra
estacion.
Ejemplo: Si nosotros para abrir un fichero en nuestra estacion que nos
recoja todo el trafico de packet para nosotros debemos de emplear desde
el terminal el comando READ (seguido del nombre del fichero), si una esta-
cion remota quiere enviarnos un fichero de texto o un largo mensaje y quiere
guardarlo en un fichero de texto en nuestro ordenador, enviar el comando
en modo remoto //READ antes de iniciar el envio de su informacion. Una vez
acabado el envio, deber cerrar el fichero que ha creado, con, por ejemplo,
el comando //READ OFF .
#11.- ALGUNOS TIPOS DE ESTACIONES DE PACKET ESPECIALES
Las estaciones ordinarias que trabajan en packet podemos denominarlas
como ESTACIONES TERMINALES de packet, pues son el origen y destino de la
mayoria de los mensajes intercambiados por packet.
Las estaciones de packet que esten definidas como terminales tienen
asignado el SSID 0, y no es necesario indicarlo en las conexiones con otras
estaciones terminales, ni aparece reflejado al monitorizar un canal de radio.
El SSID indica el tipo de estacion que se trata, y por tanto nos dice
que servicios puede incluso prestarnos. El SSID se indica detr s del indica-
tivo de una estacion de packet, separado por un guion, y asi aparece en las
monitorizaciones de los canales de radio, a excepcion del SSID 0, que es
omitido. Por ejemplo, al observar la siguiente trama que es presentada en
la pantalla de nuestro terminal (en monitorizacion del canal):
R:00 00:32 ED3HDM-2>ED3PLD>I61,P,F0:
CODIGO MORSE-SIGNOS MAS UTILIZADOS
deducimos que es una trama intercambiada entre un BBS de packet, que esta n
caracterizados por el SSID 2 (ED3HDM) y una estacion terminal (ED3PLD), cuyo
SSID, al ser 0, no es presentado en pantalla (ED3PLD y ED3PLD-0 es lo mismo).
Los SSIDes recomendados actualmente son los siguientes:
* 0 : Usuarios normales.
* 1 : digipeaters y nodos en VHF.
* 2 : buzones: BBS + PMS.
* 3 : "Gateways".
* 4 : Protocolo TCP/IP (de Internet).
* 5 : "Clusters".
* 7 : digipeaters y nodos en UHF.
* 8 : PMS (de usuario terminal, para forward).
* 9 : Estaciones a 9600 baudios.
* 10 : Estaciones en 10 metros.
* 12 : Estaciones en 1200 MHz.
e identifican distintos tipos de estaciones de packet.
#11.a.- LOS DIGIPEATERS
El DIGIPEATER (contraccion de "DIGIgital rePEATER") es un equipo capaz
de recibir packets de otras estaciones digitales y retransmitirlos. Son el
equivalente digital de los repetidores de fonia, y por ello se colocan
tambien en ubicaciones elevadas para tener mejor cobertura y facilitar asi
las comunicaciones digitales en una amplia zona.
Un digipeater no retransmite los packets en los que hay concordancia
entre el indicativo y el valor del bit H (bit asociado a cada indicativo en
el campo de direccion).
Hemos visto que el campo de direccion del AX.25 puede contener, ademas
de los indicativos del destinatario y del expedidor, hasta 8 indicativos de
digipeaters. Los indicativos de los digipeaters esta n colocados en orden, es
decir, que el primer indicativo de digipeater que sigue al indicativo del
expedidor, ser el digipeater que repetir en primer lugar la trama. La trama
alcanzar al destinatario a traves de los digipeaters siguiendo el orden de
retransmision entre los digipeaters que se haya establecido en el campo de
direccion del AX.25.
De hecho, una conexion entre estaciones a traves de uno o mas digipea-
ters se establece desde la estacion iniciadora de la conexion con un comando
del tipo:
C estacion V repetidor1 repetidor2 .....
donde eestacione es el indicativo de la estacion destinataria, y erepetidor1e
erepetidor2e... son los indicativos de los repetidores que han de establecer
la conexion (en el orden en que ser n usados). La C suele ser la abreviacion
del comando CONNECT (conectar), V significa evia...e.
A fin de asegurar una retransmision en el orden correcto, el bit H
asociado al indicativo de un digipeater se pone a 0 mientras el packet no
haya sido retransmitido por dicho digipeater. Cuando el packet ha sido
retransmitido por el digipeater, el bit H correspondiente a dicho digipeater
es puesto a 1. Una trama no es retransmitida por el digipeater siguiente
mientras que los bits H de los digipeaters que le preceden no esten a 1.
Los digipeaters no dan acuse de recepcion, unicamente la estacion
destinataria puede hacerlo, "remontando" hacia atr s la cadena de los digi-
peaters. En consecuencia, cuando se utilizan digipeaters, el temporizador
T1 debe ser puesto a un valor elevado.
Toda TNC AX.25 es capaz de servir de digipeater, aunque hay un comando
que permite prohibir esta posibilidad.
Un digipeater multiports puede recibir una trama en una frecuencia y
retransmitirla en otra frecuencia. La TNC ordinaria no puede funcionar como
digipeater multiport, solo algunas TNC especiales como PAC-COMM DR200 o
Kantronics pueden realizar esta funcion.
Los puristas dir n que la funcion digipeater pertenece a la capa 3 (capa
de red) y que fue un error definirla al nivel 2 como lo hizo la AMRAD... y no
estaran equivocados.
La funcion digipeater es muy interesante cuando el canal radio est
libre, y este era el caso en los primeros aos del uso del packet ... actual-
mente la utilizacion de nodos de packet (NET/ROM, TheNet, Texnet, etc...) es
mas util. La diferencia entre un digipeater y un nodo de packet esta en el
"nivel de inteligencia" de estas estaciones: Mientras el digipeater simple-
mente se "traga" cualquier paquete que este dirigido para el en el campo de
indicativos y lo retransmite hacia el proximo que figure en la lista de este
paquete, los nodos hacen mas cosas.
En conclusion utilice el minimo de digipeater posible!
Una observacion respecto a la monitorizacion de las seales de packet
de los digipeaters: Suele ser habitual que algunas estaciones de packet usen
nombres en lugar de indicativos, por ejemplo, TONI, EA5A-1, o cosas asi,
ello indica que son estaciones repetidoras digitales funcionando como nodos
de enlaces. Esos "indicativos" que utilizan son los llamados "apodos" o
"ALIAS" en ingles. Su baliza de radiopaquete anunciando su precencia apara-
recer cada pocos minutos y ser presentada en el monitor del terminal.
#11.b.- LOS BBS's DE PACKET RADIO
Un BBS es una estacion que permite recibir y enviar informacion a un
usuario determinado (mensaje personal) o a todos los usuarios que se conecten
al BBS (boletin). Tienen pues una funcion de servir de correo electronico
entre estaciones terminales de packet que se conecten a ellos regularmente,
y por tanto, son buzones electronicos.
BBS viene de "Bulletin Board System", o sea algo asi como un tablero de
boletines. El objetivo basico es el manejo de mensajes publicos (boletines)
y privados (mensajes personales) que quedan a disposicion de los usuarios:
Es el servicio de mensajeria o "MAILBOX".
Los BBS intercambian informacion entre ellos y encauzan el correo de
forma totalmente automatizada, si se entran los datos adecuados para encami-
nar el correo.
Los BBS's forman en conjunto una red de packet, a traves de la cual los
BBS's pueden enviar los distintos mensajes que reciban, por lo cual los men-
sajes de caracter publico o BOLETINES emitidos por un usuario terminal en un
BBS concreta, con el tiempo, puede llegar a lugares insospechados, gracias a
la red de BBS's.
Se denomina "Store and Forward", (Almacenar y enviar, S&F) a la capaci-
dad que tiene un BBS para aceptar informacion de un usuario, almacenarla
(store) y enviarla en un tiempo prudencial a otro(s) a traves de la red de
BBS's (proceso de forward, FWD).
La estructura de un BBS es igual que una estacion normal, lo unico es
que el ordenador usado lleva un disco duro de gran capacidad y maneja un
programa especifico de packet para funcionamiento como BBS. Este programa
hace del ordenador del BBS una autentica base de datos y gestiona el traspaso
de estos hacia otros BBS's. Puede contener programas y ficheros de interes
para el radioaficionado, ademas de los mensajes que le llegan via "FWD" de
todo el mundo, y enviados por usuarios terminales que se conectan a ella.
Tienen una baliza que ciclicamente avisa de su presencia y si hay algun
mensaje para alguien en particular.
El BBS esta montada normalmente en el domicilio de algun radioaficionado
o de la sede de un radioclub, y al encargado del BBS (el radioaficionado
propietario de ella o que la mantiene) es conocido como el "SYSOP" (System
Operator) del BBS.
El Sysop es la persona encargada del mantenimiento y de la correcta
operacion del BBS.
Los usuarios de los BBS's han de elegir un BBS como aquel al que accedan
f cilmente y donde llegar n los mensajes personales dirigidos a ellos que les
manden otras estaciones. Este BBS se denomina entonces como "HOMEBBS".
Para una estacion final usuaria de BBS y que tenga declarada ya un
HomeBBS, a esta llegar n los mensajes personales que le dirijan. Esos mensa-
jes pueden ser puestos en cualquier BBS y ser n pasados de BBS en BBS avan-
zando (FORWARDING) por la red de Packet hasta llegar a su destino.
Los mensajes personales solo pueden ser leidos, y borrados, por la
estacion destinataria o por el remitente.
En cualquier BBS tambien se encontrar n boletines y material variado.
Los boletines van dirigidos a todos los usuarios de la red de packet, pueden
ser puestos por cualquier usuario en su HomeBBS (o en cualquier otro BBS al
que acceda), se difunden por FWD por el mayor numero de BBS posibles, pueden
ser leidos por cualquier usuario, y pasado un tiempo dado (varios dias) ser n
borrados por el propio BBS, para no saturar las memorias donde esta n almace-
nados en el BBS a medida que se reciban boletines nuevos.
Debido al "forward" entre BBS's a traves de la red de packet, un boletin
puesto en un BBS suele alcanzar con el tiempo a todos los BBS's de un pais o
de una zona geografica (que puede incluir a todo el mundo), por lo que un
boletin depositado por un usuario en un BBS podr aparecer con el tiempo en
todos los BBS's del mbito geogr fico al cual se envia en boletin.
Los boletines y mensajes son pasados de un BBS a otro siguiendo un
criterio acorde con su destino. Los mensajes dirigidos a un BBS especifico
(los mensajes personales para alguien) son recibidos y retransmitidos por
los BBS's buscando la ruta mas adecuada para la llegada a su destino.
Los boletines son enviados a alguna "red de distribucion", esto es, que
puedes poner un boletin para que sea distribuidos a todos los BBSs del pais,
de latinoamerica, de Europa, y ademas dirigirlos a un "grupo de interes" o
tema determinado, etc....
Una vez que un usuario se ha conectado a un BBS (como en cualquier
conexion de packet, pero no olvidando en este caso poner el SSID 2 despues
del indicativo de la estacion BBS) y esta le haya dado conexion, el BBS
envia un mensaje de bienvenida, con la hora y fecha de la conexion y alguna
otra cosa que puede dejar el sysop del BBS a su gusto. Tambien le indica si
tiene algun mensaje personal para el. Este mensaje de bienvenida finaliza
con una linea de comandos, que le muestra cuales son los comandos (abrevia-
dos) que se pueden usar con el BBS. Esta linea de comandos es el "PROMPT"
del BBS, e igual que ocurre con los ordenadores personales con el viejo
sistema opertivo MS DOS, el prompt del sistema indica al usuario que el BBS
espera un comando para hacer algo.
Establecida la conexion, el BBS ahora se manejar con comandos que
ser n enviados desde el terminal de la estacion de packet, que ahora deber
de estar en modo conversacion.
Estos comandos se han de enviar en modo conversacion o transparente, se
escriben desde el teclado del terminal y se ordena el envio hacia el BBS al
actuar la tecla <enter>. El BBS entiende que se le envia un comando cuando
esta mostrando su prompt al usuario conectado, y normalmente el prompt
muestra en la misma linea la lista de comandos (abreviados) que el BBS reco-
noce. El prompt se presentar como una linea del siguiente tipo:
Cmd: A,B,C,CW,D,F,G,H,I,J,K,L,N,O,PS,R,S,T,U,V,W,X,YI,? -->
(Cmd suele ser la abreviatura de "comando" o "Comandos").
Estos comandos permiten por ejemplo:
* Listar los boletines (comandos de listado: comandos L). Se obtienen lis-
tados, generales o selectivos (segun los comandos usados) de los boletines
existentes. Cada boletin tiene un numero de orden en el BBS, y esta memo-
rizado en un fichero dentro de un directorio del BBS destinado para alma-
cenar el correo.
Los listados enviados por el BBS son listados de las cabeceras de boleti-
nes, cada cabecera presentada muestra una serie de datos tales como el
numero de orden del boletin en ese BBS, el tipo de boletin, su tamao,
quien lo remite, a quien o a que grupo de interes lo ha remitido, y el
titulo del boletin.
Los comandos de listado suelen comenzar por L, hay un repertorio de ellos,
L, LC, LR, L<, L>, etc... , lo mismo ocurre con los comandos para otras
funciones.
* Leer boletines y mensajes personales que puedan haber en el BBS (comandos
de lectura: Comandos R, seguidos del numero de boletin que se desea leer).
Con estos comandos pedimos leer aquellos boletines que, por su titulo (el
que presenta en la cabecera en un listado de boletines) parece que sean de
nuestro interes, asi como los mensajes personales existentes para nosotros.
* Enviar boletines y mensajes personales (comandos de envio: comandos S).
En el caso de los boletines hay que expecificar a que ambito se envia
( mbito geogr fico o por que cadena de distribucion entre BBS's se ha de
enviar) y para que "grupo de interes" va dirigido (p.ej: TODOS, RADIO, CW,
TECNICA...) y en el caso de los mensajes personales, se ha de indicar a
que destinatario va dirigido y la HomeBBS de este.
Nota: En el caso de las opciones de listado de boletines es posible listar
los boletines existentes para un "grupo de interes" concreto.
* Cancelar mensajes personales enviados o recibidos y ya leidos (comandos de
cancelacion o borrado: comandos K). Normalmente los BBS no suelen cancelar
los mensajes personales hasta pasado cierto tiempo, pero urgen al usuario
destinatario a que lo lean y despues de la orden de borrar el mensaje, para
asi evitar que este ocupe espacio en el disco duro indefinidamente.
Los boletines generales no pueden ser cancelados por ningun usuario, solo
por quien lo envio. La orden de cancelacion es enviada entonces por FWD a
todos los BBS posibles.
* Salir del BBS, deconectarse (Comando B). Da lugar al envio de una trama
DISC. La desconexion ser completa cuando el BBS emita como respuesta una
trama UA.
Los BBS's disponen de un sistema de ayudas que permite a cualquier
usuario conectado a ella, en especial a los que se conectan las primeras
veces, tener una ayuda de las opciones que permite el BBS y de los comandos
con que esta se maneja y para que sirven. Tipicamente se usa ? para solici-
tar ayudas (comando de peticion de ayuda):
? : Lista las ayudas del BBS.
? comando : Pide una consulta acerca del comando que se indique.
Este comando (o el equivalente) permite incluso a un usuario nuevo en
packet comenzar a desenvolverse en el uso del BBS, ya que con el, puede
comenzar a trabajar partiendo de cero.
Hay muchos tipos de BBS las cuales le ofrecen similares caracteristicas,
como ejemplo FBB, TCP, WNOS, MSYS son las mas comunes que puede encontrar por
aqui y los comandos que utilizan son similares o iguales (El tipo de BBS hace
referencia al software que usa). Como nota adicional, las que usan TCP o
soportan el protocolo de comunicaciones TCP/IP (como el sofware WNOS) esta n
preparadas para su conexion a Internet, ya que la red Internet usa precisa-
mente este protocolo.
Ademas de la mensajeria entre usuarios (Mailbox), que es la funcion
primordial de los BBS's, existen otros servicios a los que pueden acceder
los usuarios conectados manejando los comandos adecuados del BBS:
* Servicio de archivos: Los BBS's tienen a disposicion de sus usuarios
archivos conteniendo Textos, Programas, Temas de interes, Datos, etc.
Estos Archivos esta n agrupados en Directorios en el disco duro del BBS, y
el BBS permite con el uso de los comandos adecuados al usuario que pueda
traerse del BBS alguno de estos archivos.
* Funciones: Permite acceder a servicios de:
Documentacion ___ Otra manera de trabajar con archivos.
Estadisticas ___ de la actividad y funcionamiento del BBS.
Nomenclator ____ Informacion de los usuarios del BBS.
Qra_locator ____ Determinacion de posiciones geograficas.
Trayectografia __ Informacion, Par metros y C lculos de satelites.
* Modo de trabajo en DOS: En este modo de trabajo con el BBS se dispone de
comandos an logos a los del sistema operativo MS-DOS/DOS, y que permiten
un cierto manejo de los archivos del BBS y de su disco duro, o de una
parte de este. Sin embargo este modo de trabajo no es igual que el manejo
normal de un ordenador, hay restricciones de uso, para evitar que un usua-
rio, malintencionado o por error, pueda alterar archivos en el ordenador
(borrarlos...) o acceder a directorios privados del Sysop (muchas veces,
el BBS esta en casa de un radioaficionado que pone su propio ordenador
para esta funcion, pero que tambien lo usa para sus cosas particulares).
* La conferencia: Por este modo de trabajo del BBS, las estaciones que
entran en conferencia reciben todo lo que escriban las demas, por lo que
pueden estar "al habla" entre ellas a traves del BBS.
El BBS se comporta para ellas como un repetidor digital.
* El modo GATEWAY: Un BBS opera sociada a algun nodo de packet. Dicho nodo
puede formar parte del propio BBS. Si el modo Gateway esta activo, permite
al usuario conectarse al nodo a traves del BBS.
Gateway indica tambien "puente de conexion" a otro tipo de redes, y de
hecho hay BBS's de packet que tienen gateway con Internet, pudiendo dar un
tipo de acceso al usuario de packet al Internet a traves del BBS (solamente
para servicio de mensajeria, Email de Internet).
* El modo CLUSTER: Un cluster es una estacion de packet que permite dar
informacion sobre propagacion, DX, Meteorologia, y en general, informacio-
nes de utilidad para el radioaficionado.
Una estacion de cluster puede estar integrada en el mismo BBS, y cuenta con
una serie de bases de datos donde se recogen las informaciones mencionadas,
que son accesibles para cualquier usuario que se conecte al cluster (cone-
xion Packet-cluster). Si la informacion solicitada por el usuario al
cluster no estuviera en este, la obtendrade otras estaciones cluster con
las que esta interconectada via packet y en directo o a traves de otros
nodos.
* Servicio de WP (White Pages/paginas Blancas): da acceso a una base de datos
o Guia de las estaciones que usan el Packet-Radio. Esta Guia se actualiza
autom ticamente con la informacion del encabezamiento de los mensajes que
llegan a este BBS procedentes de sus usuarios o de otros BBS (mediante el
forwarding), en la que se indica el usuario que envia el mensaje y desde
que BBS (que en la mayoria de casos ser su HomeBBS).
En las WP podremos conocer la HomeBBS de un usuario (si ha sido registrado
por el BBS), lo cual es un dato importante si deseamos enviarle un mensaje
personal y no conocemos su HomeBBS.
* Servicios de "SERVERs": Los SERVERs (Servidores) son "enanitos" que tienen
los BBS para atender autom ticamente algunos pedidos del usuario.
Cada SERVER tiene una funcion especifica. Son programas instalados o suple-
mentarios en un BBS que permiten ejecutar tareas especificas con solo
notific rselo mand ndole un mensaje personal al Server en cuestion. No
forman parte de los programas de packet radio usados por los BBS's, pero
complementan las funcionalidades de estos.
La manera de solicitarlos por un usuario remoto es dirigiendo un mensaje
personal al propio server (como usuario de destino) del BBS que se expeci-
fique. Cuando un mensaje personal dirigido a un server llega al BBS, este
programa se ejecutar autom ticamente, y el resultado de la ejecucion ser
enviado en forma de mensaje personal al usuario que envio el mensaje al
server.
Los servers son practicos, por ejemplo, para pedir directorios y archivos
a un BBS remoto). Algunos de los Servers mas usuales son los siguientes:
REQDIR, REQFIC, REQFIL, AUTO7P, WP....
El BBS puede tener operativo varios "PORTs" (puertos) o salidas fisicas.
Los ports pueden conectarse a TNC's/RADIOS que operen en varios canales de
radio, a modems telefonicos, a otros ordenadores, etc..., e incluso actual-
mente hay BBS's que son accesibles por Internet.
El BBS es multiusuario, es decir, que varias conexiones pueden ser
soportadas simultaneamente. Un usuario que se conecta ocupa una VIA, que
es un enlace logico. Al entrar en el modo Gateway un usuario ocupa 2 vias
(una con el BBS y otra entre el BBS y el nodo o dispositivo conectado a la
otra via).
En un mismo canal de comunicaciones, por ejemplo, un canal de radio,
pueden haber varias vias (enlaces logicos) funcionando, lo cual supone que
el mismo canal de comunicaciones (canal fisico) esta siendo compartido por
varios usuarios, pero cada usuario es tratado por el BBS individualmente,
con una conexion propia (canal logico).
Los BBS's son el punto de acceso para los usuarios terminales a la red
de packet, por lo que los BBS's se pueden denominar como estaciones de packet
"finales" o "servidoras".
#11.c.- ALGUNOS ASPECTOS DE LOS BBS's
En la estructura logica de los BBS's existen una serie de directorios
donde se almacenan divesas cosas. Existir algun directorio donde se almace-
nen los distintos mensajes y boletines recibidos, a razon de un archivo por
mensaje. Habr n otros directorios donde existir n programas y archivos de
informacion que se pueden acceder mediante el servicio de archivos, de docu-
mentacion, etc.. del BBS. El software con que corre el BBS se encarga de
gestionar todo esto, tanto las funciones autom ticas del BBS (el forwarding,
el borrado autom tico de boletines pasado un cierto tiempo...) como las
operaciones activadas por el Sysop o por los usuarios terminales conectados
al BBS.
Acerca de los mensajes
- - - - - - - - - - - -
Del tratamiento de los mensajes y boletines por el BBS, podemos citar
varias cosas:
* Un BBS considera como mensaje de origen local a aquel que ha sido generado
en el propio BBS (por el Sysop, por la respuesta de un server) y los reci-
bidos directamente de un usuario terminal conectado a ella. Los que llegan
por FWD no tendran, pues, esta consideracion.
* Los mensajes enviados por los usuarios se envian con la siguiente direc-
cion, que ha de ser especificada en el comando S adecuado empleado al ser
enviado el boletin o mensaje personal:
INDICATIVO@HOMEBBS Para el caso de un mensaje personal. Ejemplo:
EA3MNO@EA3PRS (mensaje para EA3MNO, usuario
del BBS EA3PRS).
TEMA_DE_INTERES@AMBITO Para el caso de boletines generales. Ejemplo:
TODOS@EA3 , RADIO@WW, TECNICA@EUR, ...
SERVER@HOMEBBS Para enviar una peticion a un server de un BBS.
Ejemplo: REQFIL@EA3PRS
* A los mensajes locales de un BBS este les pone un numero de identificacion,
el "BID" o Licitacion: Es un numero de serie inequivoco que el BBS da a un
mensaje o boletin recibido de un usuario local suyo, y que se incluye en
este, para evitar posteriores duplicaciones de mensajes en otros BBS's que
lo puedan recibir posteriormente por dos o mas caminos o fechas distintas.
Cuando un BBS recibe por FWD un boletin, mira su BID, y comprueba si este
BID (constituido por: BBS local y numero de serie del boletin dado por el
BBS local), y solo si el BID recibido coincide con el de algun boletin aun
presente en el BBS, es rechazado el boletin, pues considera que el boletin
recibido es un duplicado de alguno que ya tiene almacenado (el mismo bole-
tin, recibido anteriormente por FWD por otro camino...).
* A los mensajes pueden aadirseles algunas lineas informativas mas, tales
como:
* La ruta jer rquica o HROUTE: HRoute es la abreviatura de "Hierarchical
route". Es la ruta jer rquica de cada estacion de packet, define la
direccion jer rquica (HRoute) dentro de la red mundial de packet del
usuario, y se escribe en el formato:
.[ZONA].PROVINCIA.PAIS.CONTINENTE
Con ello, la direccion completa de una estacion de packet quedaria de la
siguiente manera:
INDICATIVO @BBS_LOCAL.[ZONA].PROVINCIA.PAIS.CONTINENTE
En Espaa actualmente no se usa la ZONA. PROVINCIA se refiere a una
provincia, region o departamento administrativo del pais.
Esta direccion facilita a los BBS's el encaminamiento de los mensajes,
personales, sobre todo cuando se trata de mensajes dirigidos a usuarios
de packet en otros paises.
Ejemplo: EA3MNO@EA3PRS.EAB.ESP.EU
(La estacion EA3MNO tiene como HomeBBS a EA3PRS, esta en Barcelona, Espaa, Europa).
* Las lineas R: Las lineas R (Rlines, lineas de ruta) forman la descrip-
cion detallada la ruta seguida por un mensaje desde su origen, y la
incluyen en los mensajes los BBS's.
Salvo que se solicite con el comando adecuado al BBS la lectura de un
boletin con las lineas R, estas lineas no se envian en el contenido de
los mensajes que los usuarios de los BBS's solicitan a esta para leerlos,
solo se envia una descripcion resumida de los BBS's por donde ha pasado
el mensaje (es una linea R muy resumida).
Cada vez que un mensaje pasa por un BBS, este aade su linea R a conti-
nuacion de las ya existentes en el mensaje.
Esta linea identifica el BBS, su ubicacion geografica (o su HROUTE) y
algun dato mas. La lectura de las lineas R que acompaan a un mensaje o
boletin informan a su destinatario, o a quien lo lee (si es un boletin
general), por que BBS's ha pasado el mensaje (desde su origen) y en que
orden, en que fecha y hora, etc...
Flags de los mensajes
- - - - - - - - - - -
* Los boletines y mensajes son etiquetados con unos "flags", que indican el
tipo y condicion (Status) de los mensajes. Estos flags son mostrados tanto
en la presentacion del mensaje cuando es enviado a un usuario que ha pedido
leerlo, como en los listados de cabeceras de mensajes, pedidas con los
comandos de listado L. Los principales flags son los siguientes (suelen
expecificarse tres como maximo):
* L : La letra L, si se indica, significa que el mensaje se creo localmen-
te en ese BBS (lo creo su Sysop o lo envio a ese BBS algun usuario
que se conecto a ella). Si no se indica L, significa que el mensaje
ha sido recibido en forwarding desde otro BBS.
* P : Significa que el mensaje es personal: este tipo de mensaje puede
accederse unicamente por el remitente y el destinatario del mensaje,
y son los unicos que pueden cancelar (borrar) el mensaje en el BBS.
* B : Significa que el mensaje es un boletin: Cualquier usuario podr
leer este mensaje, pero como este mensaje es publico, unicamente el
remitente puede cancelarlo.
Nota: Un mensaje ser de tipo P o B.
* D : Este flag solo se presenta cuando el mensaje tiene un tipo especial
de formato, y es el caso de un archivo binario que ha sido codifi-
cado a modo texto, para poder ser enviado como boletin, ver mas
adelante.
* Flag de status del mensaje:
N : significa mensaje personal/boletin nuevo. El status de mensaje
puede tener algunas variacciones segun su tipo: por ejemplo, un
mensaje personal, si es leido por el destinatario, pasa a Y en
el status.
Los mensajes de boletin no cambian a status Y, porque no tienen
un destinatario realmente al ser un mensaje para cualquiera que
lo quiera leer, y permanecer n en estado N (el status Y no est
previsto para los boletines). En los mensajes personales, N
indica que es un mensaje nuevo, que aun no ha sido leido por su
destinatario.
Y : Correo personal ya leido, pero no cancelado (El destinatario ha
usado un comando R para leerlo del BBS).
K : significa que el mensaje se cancelo ("killed"). Un mensaje can-
celado no es accesible por los usuarios, no es presentado en los
listados, es como si no existiera, aunque aun permanezca en el
BBS. Los mensajes en estado K ser n borrados definitivamente del
disco duro del BBS en corto espacio de tiempo.
En el caso de los mensajes personales, el mensaje solo puede ser
cancelado por quien lo envio, y tambien por su destinatario, pero
en este caso solo cuando este lo haya leido.
Los comandos K son usados para cancelar los mensajes en el BBS.
H : significa que el mensaje esta bloqueado o retenido ("Held") en
el BBS. Un mensaje bloqueado no es accesible para el usuario, ni
es enviado por FWD, hasta que el sysop lo desbloquee (este status
solo lo ver el Sysop en su BBS). Este estado deja un mensaje
"bloqueado" en el BBS por algun motivo hasta que lo examine el
SySop y lo desbloquee.
F : significa que el mensaje ha sido ya enviado por forwarding a
otros BBS. Un mensaje recien llegado al BBS (tanto local como
procedente de otro BBS) deber ser forwardeado a otros BBS para
la m xima difusion del mensaje a traves de la red de packet,
pero esto no se realiza inmediatamente, ya que el BBS realiza
su forwarding hacia otros BBSs cada cierto tiempo o a horas pre-
programadas. Cuando el mensaje ha sido forwardeado, es cuando en
el BBS se le coloca el flag F.
Los sysop de los BBS's pueden acceder a todos los mensajes, incluso a
los que esta n en situacion de "cancelados" (K) y bloqueados (H).
En los BBS's cada mensaje se guarda en un archivo en un directorio
concreto del BBS. Un programa de gestion de estos archivos ser el encargado
de marcar cada mensaje con el status adecuado, anotar sus BIDes, su tamao,
otros datos... y borrarlos cuando sea requerido (generalmente tras un tiempo
de permanencia del mensaje en el BBS, para no saturar la memoria del ordena-
dor).
Los listados "Unproto"
- - - - - - - - - - - -
Los BBS's tambien envian periodicamente, aunque no haya nadie conectado
a ellos, el listado de las cabeceras de los mensajes almacenados en el aun
activos, usando para ello tramas Unproto, UI, enviando normalmente una cabe-
cera de mensaje por cada trama UI. Las tramas UI tambien son usadas para
enviar el texto de la baliza del BBS.
Cuando un BBS de tipo FBB recibe un mensaje nuevo, emite una trama
Unproto especial con la cabecera del mensaje.
Bajo este aspecto, un usuario con el ordenador o la TNC activa todo el
dia puede recibir y mantener la lista de los mensajes presentes en el BBS, y
examinarla posteriormente para ver si alguno le interesa, y todo ello sin
necesidad de conectarse al BBS y pedirla listados de boletines.
Sin embargo, para usar optimamente esta funcion, obtener la "lista de
Unproto" existe un procedimiento que exige por otro lado estar habilitado
en el BBS por su sysop para ello. Esta habilitacion le permite al usuario de
una manera comoda actualizar su lista de Unproto con los mensajes nuevos en
el BBS, mediante el envio al BBS de tramas UI de sincronizacion de la lista,
que indican al BBS a partir de que numero de mensaje se desea actualizar.
La resincronizacion se consigue enviando al BBS una trama UI caracte-
ristica, que contiene en su campo de informacion una expresion del tipo
"?0000123e5", y es la denominada trama de llamada al Unproto. La expresion
indicada va dentro del campo de informacion de la trama UI, y el valor de
lo que va detr s del caracter "?" depender del numero de mensaje a partir
del cual se pide la resincronizacion (valor expresado en hexadecimal). Si
el usuario no esta habilitado en el BBS para esta funcion, este ignorar su
llamada a resincronizacion, y la unica opcion que le queda al usuario, si se
lo permite su programa de packet, es la de crear la lista de unproto por
interceptacion de las tramas de Unproto que el BBS envia, pero no podr pedir
resincronizacion con el BBS si una trama UI unproto se pierde o no es escu-
chada por la estacion terminal del usuario (se obtienen asi listados incom-
pletos de unproto).
Transferencias binarias: 7PLUS, AUTOBIN, YAPP
- - - - - - - - - - - - - - - - - - - - - - -
Los BBS's de packet se usan para transferir mensajes entre usuarios,
por lo que en principio solo pueden transmitir informacion en formato ASCII,
esto es, en modo texto, y no pueden transmitir informacion binaria directa-
mente a los usuarios. Pero existen procedimientos para poder transmitir
informacion binaria entre usuarios y entre BBS y usuario, y ello es util
para poder enviar archivos de cualquier tipo a traves del packet radio,
tanto binarios (programas) como de texto.
El procedimiento comunmente empleado es el de codificar el archivo
binario que se desea enviar (tambien sirve para cualquier tipo de archivo,
como puede ser un archivo de texto Ascii) y cuya estructura es incompatible
con los archivos Ascii (por la presencia de caracteres de control, longitudes
de lineas muy cortas y muy largas...), y la codificacion es de forma que la
estructura del archivo binario se transforma en una estructura de archivo
ASCII, y por tanto, el archivo resultante tras la codificacion puede enviar-
se en un boletin o un mensaje. La estacion destinataria tras recibir este
boletin, ha de realizar el paso inverso para recuperar el archivo original a
partir del contenido del boletin o mensaje recibido.
Los programas UUCODE y UUENCODE son dos cl sicos programas que permiten
realizar estas conversiones binario/ASCII, pero su uso ha sido relegado a la
mensajeria por Internet. Para Packet radio se ha adoptado practicamente con
caracter universal para realizar estas funciones el programa 7PLUS, el cual
permite realizar las dos funciones indicadas:
* Codificar un archivo binario a archivo ASCII (texto), con un formato
especifico: formato 7Plus.
* Extraer la informacion ASCII con formato 7PLUS de los mensajes que la
contienen, y regenerar a partir de ella el archivo binario original.
Este programa actualmente puede codificar a modo texto archivos binarios
bastante grandes, aunque suele limitar el tamao de los archivos ASCII gene-
rados a un maximo de 10 KBytes (en las versiones mas antiguas de 7Plus). Si
el resultado de la codificacion es de un tamao superior a 10 K, el resultado
de la codificacion se trocea en varios archivos ASCII (con un tamao maximo
de 10 KB cada uno), que pueden ser enviados en boletines individuales.
Estos archivos esta n perfectamente identificados, ya que la codificacion a
ASCII del 7PLUS da un formato especifico a estos archivos Ascii, y el propio
7PLUS es capaz de recuperar el archivo original en estos casos sin mas
problemas, si encuentra todas las partes en formato ASCII en que ha sido
enviado codificado el archivo binario original.
El algoritmo de codificacion del 7PLUS suele prevenir errores en el
envio de la informacion codificada a formato texto, para asi conseguir que
la informacion binaria enviada se recupere en el lado receptor integra, y
por tanto el archivo binario enviado sea plenamente utilizable por quien lo
ha recibido. Pero a veces pueden darse errores en la transmision de la infor-
macion, que el 7PLUS no puede corregir, y que daria lugar a que el archivo
original no sea recuperado con exactitud por el usuario receptor, y esto har
que sea un archivo inutil la mayoria de los casos (sobre todo si es un
archivo binario).
Pero el programa 7PLUS detecta esta circunstancia de error al intentar
recuperar el archivo original a partir de los archivos ASCII recibidos, y
entonces realiza la decodificacion, hasta donde puede, generando un "meta-
archivo" 7PLUS, y ademas elabora un informe de los errores detectados, que
es almacenado en un "archivo de error".
La estacion receptora ha de enviar este archivo de error a la estacion
que expidio el archivo original codificado 7PLUS, y cuando esta lo reciba, ha
de usar su programa 7PLUS para que con la presencia del archivo original,
7PLUS examine los errores codificados en el archivo de error recibido, lo
compare con el archivo original, y elabore una informacion de correccion, que
es almacenada en un "archivo de correccion".
Este archivo de correccion es enviado a la estacion distante, y cuando
lo recibe, usa de nuevo el programa 7PLUS para que, junto con el metaarchivo
que guardo con la decodificacion fallida anterior, recupere finalmente el
archivo binario original, sin errores, y por tanto plenamente utilizable.
Como se puede ver, el programa 7PLUS permite el envio de archivos bina-
rios por la red de packet con bastante seguridad de envio, con procedimiento
de correcciones de errores de envio y de decodificacion. A partir de la
codificacion 7Plus se han elaborado algunos Servers y otras utilidades que
realizan todos estos procesos autom ticamente.
Como informacion adicional, los archivos que genera 7PLUS tienen las siguientes extensiones:
.7PL Archivos codificados 7PLUS a un solo archivo ASCII.
.P01 .P02 .P03 ... Partes de un archivo original que al codificarse con
7PLUS no pueden ser enviado en un unico archivo 7PL.
.7MF Metafile 7PLUS, donde se recoge todo lo que ha podido decodificar
correctamente el 7PLUS cuando la decodificacion no consigue
corregir errores en los archivos 7PLUS recibidos.
.ERR Archivo de informacion de error, que se genera junto con el .7MF
.COR Archivo de correccion, generado por el expedidor del archivo
7plus original al recibir un archivo de error ERR.
Como curiosidad, los boletines que contienen informacion que ha sido
codificada a ASCII mediante 7PLUS son los que aparecen marcados con el flag
de status "D".
La limitacion del tamao maximo de cada boletin generado con 7PLUS es
de 10 K, para evitar generar boletines excesivamente largos, poco practicos
para su envio por la red de packet. Por la misma razon, y tambien para evitar
que un programa o texto enviado que es demasiado largo ocupe mucho tiempo de
envio, los programas a enviar, antes de ser codificados a modo texto con el
7PLUS o programa similar, son comprimidos mediante el uso de programas
compresores/descompresores, programas que consiguen reducir incluso notable-
mente el tamao del fichero una vez lo han comprimido. Ello obliga a que tras
recuperar en el lado receptor el archivo binario transmitido, comprimido, se
deba de usar el programa descompresor correspondiente para recuperar el
archivo binario o de texto original.
Como ejemplos de programas compresores/descompresores, muy populares,
esta n el ARJ, el PKZIP/PKUNZIP, el RAR, el LHA, el WinZip...
Este procedimiento es usado para transmitir mediante la mensajeria
archivos de cualquier tipo entre estaciones de packet a traves de la red de
packet, pero existe otros procedimientos para transferir archivos entre las
estaciones terminales y sus HomeBBS, como son el uso de los protocolos de
transferencias binarias AUTOBIN y YAPP.
Al principio la transferencia de ficheros era "manual". Dos corresponsales
se ponian de acuerdo en enviarse un fichero. Ponian ambos la instruccion de
la TNC para transferir 8 bits, y entonces el que tenia el fichero, le decia
(tecleaba) "esta s preparado?" "Si." "Pues all va". En ese momento el receptor
tecleaba la instruccion para recoger un fichero binario, con el nombre que
queria para el mismo, y el emisor tecleaba la instruccion para mandar el
fichero binario. Al final, se comunicaban el tamao que tenia que tener para
saber si la transferencia habia sido buena.
Posteriormente aparecio el programa YAPP. Este incluia un pseudo-protocolo
para pasar ficheros. Al YAPP se le aadio la capacidad de si la conexion
fallaba, se podia retomar desde donde se perdio, sin tener que comenzar desde
el principio. Posteriormente aparecieron otros programas terminales mas
modernos que que utilizan el protocolo YAPP, o que usan nuevos protocolos
para la transferencias de ficheros. De estos ultimos, el mas conocido es el
protocolo AUTOBIN, que hace todo autom ticamente.
Estos protocolos obligan a transferir la informacion entre estaciones en
modo transparente en tramas I. Esto quiere decir que la informacion se
enviar y se recibir tal cual, sin que se procesen los bytes que puedan
tener significado de caracteres de control, como ocurriria en el modo conver-
sacion (donde por ejemplo, el CR tiene significado de "retorno de carro" y
el LF de "Avance de linea" para la informacion recibida, que se considera
es texto. Una informacion de tipo binario no tiene por que ser de texto, y
por tanto los bytes que la componen pueden significar cualquier cosa, por lo
que al transmitirla no debe de ser procesada en la estacion receptora como
si de un texto se tratara: Se ha de transmitir y almacenar integra.
El protocolo AUTOBIN es bastante sencillo, b sicamente consiste en que
en la estacion emisora el contenido del archivo binario es leido y enviado
con tramas I en modo transparente (desde su primer byte), y la estacion
receptora lo recibe en modo transparente, almacenando la informacion recibi-
da en un archivo de log (archivo de registro). Una vez recibida toda la
informacion binaria, cerrar el archivo log y lo renombrar con el nombre
original del archivo que ha recibido. Al ser la transmision en modo transpa-
rente, el archivo creado por la estacion receptora con la informacion binaria
recibida deber de ser exactamente igual al archivo binario original enviado
por la estacion expedidora.
Sin embargo el protocolo YAPP es el protocolo de transferencias binarias
mas conocido, fue desarrollado por los propios radioaficionados, y mediante
el uso de este protocolo, una estacion terminal de packet puede bajar de su
HomeBBS o enviarle un archivo de cualquier tipo (incluso binarios). El
procedimiento de transferencia yapp se maneja por comandos, los comandos Y
de los BBS. Este protocolo es practicamente el esta ndard de transferencia de
ficheros en radiopaquete (AUTOBIN es muy usado por las estaciones de packet
alemanas).
La unica limitacion actual de este procedimiento es que solo pueden
bajarse de la HomeBBS los archivos que esta n en un directorio muy especifico
del disco duro del BBS, el directorio YAPP, o de sus subdirectorios.
El contenido de este directorio se puede examinar con el comando Y
adecuado, lo cual permite al usuario terminal ver si le interesa algun
archivo de este directorio para bajarlo del BBS. Con otros comandos Y, puede
proceder a transferir un archivo desde/hacia el BBS.
Los archivos enviados al BBS mediante la transferencia YAPP se cargar n
en este mismo directorio del BBS.
Los BBS's actualmente incorporan el protocolo YAPP; para poderlo usar
la estacion terminal, el programa de packet que use ha de tener implementada
esta funcionalidad.
En el protocolo YAPP los bits que componen el archivo transferido se
envian en modo transparente (en tramas I). Una secuencia de inicio de trans-
mision y otro de cierre de la transmision indican a la estacion receptora de
que se va a iniciar la transferencia en modo transparente y de cuando esta
acaba. Estas dos secuencias b sicamente esta n controladas mediante el inter-
cambio de los caracteres ASCII de control adecuados.
La transferencia del fichero b sicamente consta de dos partes: La trans-
ferencia de una cabecera informativa, con datos del fichero (nombre, tamao
en bytes, y CRC ? de 8 bits), y despues su contenido. La generacion de la
cabecera del archivo solo la podr realizar el programa de packet si incorpo-
ra el protocolo Yapp, ya que los datos de la cabecera del archivo no se guar-
dan con el contenido del archivo juntos en el disco del ordenador, sino en
ubicaciones distintas del disco.
Como ejemplo de transferencia desde el BBS a la estacion terminal,
escuetamente, es la siguiente (todo a traves de tramas I):
BBS estacion terminal
------------- -------------------
<----------------- YD nombre_fichero (solicitud transferencia)
texto de confirmacion -----> (acepta transferencia)
ENQ SOH ------------------> (peticion inicio transfer.)
<---------------------- ACK SOH (estacion preparada)
SOH^?Nombre tamao dato -----> (Cabecera del archivo:
Nombre, tamao, y CRC ?)
<---------------------- ACK ACK
STX bits_del_programa ----->
bits_del programa -------->
ETX SOH ----------------------> (final de archivo)
<-------------------- ACK ETX (acuse de recibo)
EOT SOH -----------------------> (final de transferencia)
<-------------------- ACK EOT (confirmada)
(Nota: durante el envio de los bits de programas en tramas I sucesivas,
en cada 254 bits enviados sus 3 bits finales son bits de control con la
secuencia ?^B , donde ? indica un caracter que depender de los 251 bits
anteriores, no se refiere al caracter e?e).
Si la transferencia fuera abortada desde la estacion terminal:
BBS estacion terminal
------------- -------------------
<----------------- YD nombre_fichero
texto de confirmacion ----->
ENQ SOH ------------------>
<---------------------- ACK SOH
SOH^?Nombre tamao dato----->
<---------------------- ACK ACK (??) (peticion de cancelacion)
CAN ACK Texto_de_cancelacion ------> (Cancelacion transferenc.)
<-------------------- ACK ETX
Los caracteres de control utilizados son:
SOH (Ascii 1) : Inicio de cabecera (^A)
STX (Ascii 2) : Inicio de texto (^B)
ETX (Ascii 3) : Fin de texto (^C).
EOT (Ascii 4) : Fin de transmision (^D).
ENQ (Ascii 5) : Peticion (^E)
ACK (Ascii 6) : Acuse de recibo, confirmacion (^F)
NACK (Ascii 21) : No confirmacion (^U)
CAN (Ascii 24) : Cancelacion (^X)
^? : caracter de control que depende del archivo a transferir
YD : Comando de BBS para indicar que se quiere transferir un archivo
desde el BBS al usuario terminal mediante protocolo yapp.
: (Ascii 250)
Los distintos codigos de control se pueden conseguir manualmente
pulsando la tecla "Control" (representada por el simbolo ^), y sin soltarla,
pulsar la letra que se indica. Esto puede ser util para realizar transfe-
rencias YAPP en programas poco depurados o antiguos, donde hay que realizar
estas transferencias un poco "a mano". Segun esto, las anteriores transfe-
rencias quedarian de la siguiente forma:
* Caso de transferencia desde el BBS a la estacion terminal:
BBS estacion terminal
------------- -------------------
<----------------- YD nombre_fichero (solicitud transferencia)
texto de confirmacion -----> (acepta transferencia)
^E^A ----------------------> (peticion inicio transfer.)
<---------------------- ^F^A (estacion preparada)
^A^?Nombre tamao dato -----> (envio de cabecera)
<---------------------- ^F^F
^B bits_del_programa ----->
bits_del programa -------->
^C^A -----------------------> (final de archivo)
<-------------------- ^F^C
^D^A -----------------------> (final de transferencia)
<-------------------- ^F^D (confirmada)
* Si la transferencia fuera abortada desde la estacion terminal durante esta:
BBS estacion terminal
------------- -------------------
<---------------------- ^F^F (peticion de cancelacion)
^X^F Texto_de_cancelacion ------> (Cancelacion transferenc.)
<---------------------- ^F^C
La cancelacion tambien puede ser abortada por el BBS, en ese caso enviar
^X^F y el texto de aborto de cancelacion (por ejemplo, ^X^FAbort).
En sentido inverso, transferencia desde el usuario terminal al BBS de
un archivo mediante yapp, el proceso es similar, aunque en este caso la
estacion terminal usar en comando YU para indicar al BBS que le va a trans-
ferir un archivo:
BBS estacion terminal
------------- -------------------
<---------------- YP nombre_fichero (solicitud transferencia)
Texto pidiendo descripcion del fichero ---->
<---------------- descripcion del fichero
<---------------- ^E^A (petic. inicio transferencia)
^F^A -----------------> (estacion preparada)
<---------------- ^A^?Nombre tamao dato (Envio de cabecera)
^F^B -----------------> (ACK e inicio de contenido)
<---------------- ^B bits_del_fichero (Envio del contenido)
<--------------- bits_del_fichero
^F^C -----------------> (ACK recepcion contenido)
<---------------- ^D^A (Final de transferencia)
^F^D -----------------> (Confirmacion)
El uso del password. Proceso de conexion.
- - - - - - - - - - - - - - - - - - - - -
El acceso a un BBS es libre, por lo que puede acceder cualquier usuario,
aunque no tenga licencia de radioaficionado. Como ello puede dar lugar a la
usurpacion de indicativos por parte de usuarios "no legales", existe un pro-
cedimiento que cualquier usuario puede solicitar al Sysop de su HomeBBS, para
evitar que alguien no autorizado entre en su HomeBBS usando su indicativo, y
le pueda robar su correo personal, o poner mensajes a su nombre. Es el uso
del PASSWORD (PWD) o "Palabra clave".
El PWD ser solicitado por el BBS al usuario cuando se conecte a ella
(si asi lo solicito en su momento al Sysop del HomeBBS) o cuando quiera
acceder a algunas funciones especificas del BBS. Mediante este procedimiento
el usuario ha de tener declarada una "palabra clave" en su HomeBBS, que el
logicamente conoce, y que va a servir de base para elaborar el PWD.
La palabra clave puede tener un numero elevado de caracteres alfanume-
ricos (y no ha de tener espacios entre ellos), tipicamente hasta 50 carac-
teres.
Existen dos formatos de PWD: El formato standard y el de algoritmo MD2.
En el formato standard, muy usado, el sistema requerir como PWD al usuario
cuando se conecte cinco de los caracteres alfanumericos de su palabra clave.
Para ello el BBS generar aleatoriamente 5 numeros, comprendidos entre 1 y
el numero de letras que componen la palabra clave del usuario (que en este
caso ha de ser una palabra clave constituida por solo letras mayusculas, sin
espacios de separacion), y enviar al usuario estos numeros en la peticion
de password, en una linea similar a la siguiente:
PASSWORD 2 5 7 15 25 ? -->
El usuario deber contestar como PWD los las cinco letras de su palabra
clave que ocupan las posiciones en ella que indican las cinco cifras enviadas
por el BBS. Si el PWD que recibe el BBS es correcto, se da pleno acceso al
usuario al BBS, y esta le envia su promp. Si es incorrecto, interpreta de que
quien quiere conectarse no es el propietario del indicativo que usa, y
rechaza la peticion de conexion al BBS (normalmente vuelve a solicitarle dos
o tres veces mas el PWD, por si el usuario se equivoco al teclearlo en su
terminal, pero si en todos los casos envia un PWD incorrecto, es cuando ya
le deniega el acceso al BBS). Al no enviar la palabra clave completa el
usuario, sino los 5 caracteres concretos que le solicita en ese momento el
HomeBBS, se evita que un usuario ilegal pueda conocer la palabra clave de
ese usuario por monitorizacion del trafico de packet.
Ejemplo: Si la palabra clave es MICLAVEESQUESOYDEBARCELONA (se han de
especificar sin espacios en blanco y con caracteres alfabeticos en mayuscu-
las), y el BBS le envia al usuario en el momento de la conexion el requeri-
miento del password como:
Password ? 2 5 7 15 25
el usuario deber de contestar: IAEYN (letras correspondientes a los carac-
teres 2, 5, 7, 15 y 25 de su palabra clave).
En el caso del PWD mediante el sistema MD2, la peticion del PWD se
realiza generando 10 caracteres alfanumericos aleatorios (letras y numeros),
que son enviados al usuario encerrados entre corchetes, algo parecido a lo
siguiente:
PASSWORD ? [3252cr7i8] -->
Dado que el BBS conoce la palabra clave del usuario, tanto BBS como usuario realizar n las siguientes operaciones con estos 10 caracteres:
* A los 10 caracteres se aadir la palabra clave del usuario, si esta fuera
ABCDEF, la cadena resultante seria 3252cr7i8ABCDEF. Esta cadena es pasada
a una rutina de codificacion MD2, le aplica su algoritmo de codificacion,
y devolver como respuesta 16 caracteres ASCII, que ser n entregados en
notacion hexadecimal. Como cada caracter Ascii esta codificado por dos
bytes en esta notacion, se obtendrauna secuencia de 32 bytes.
* La estacion que se desea conectar enviar esta secuencia de 32 bytes (en
notacion hexadecimal) al BBS como PWD, y deber de coincidir con la secuen-
cia que ha calculado el BBS si el PWD es correcto (ambas estaciones, BBS y
terminal, usan el mismo algoritmo de codificacion MD2), y si es asi, como
en el caso anterior, se da plena conexion a la estacion terminal al BBS.
A nivel de software, los BBS's gestionan las conexiones de los usuarios
a traves de un programa de "filtro de conexion" (programas tales como el
Con-filter, Protus, etc...), y entre sus funciones, esta el comprobar si un
usuario que quiere conectarse tiene declarado password o no. Si tiene decla-
rado un PWD, se inicia el procedimiento de peticion del PWD. Si el usuario
entra el PWD correcto, el programa de filtro le enviar el SID, el texto de
bienvenida del BBS, alguna informacion que pueda haber puesto el sysop, y le
da entrada al sistema, envi ndole por ultimo este el prompt del BBS.
Si el usuario no da el PWD correcto, el BBS da lugar a la desconexion
de la comunicacion, inmediata o despues de requerirle el PWD una o dos veces
mas.
Si el usuario no tiene declarado PWD, el programa de filtro de conexion
omitir el procedimiento de peticion del PWD y le dar conexion al BBS direc-
tamente (envio del prompt), salvo que ese usuario este registrado en la base
de usuarios del programa de filtro como usuario inhabilitado para todo tipo
de conexion (por ser un mal usuario o por el motivo que sea, el SySop del
BBS lo ha incluido en esta base). En esta misma base de usuarios es donde
estar n registrados los usuarios con PWD, y la palabra clave para el PWD de
cada uno de ellos.
El denominado SID del BBS, mencionado unas lineas atr s, es una identi-
ficacion del software de la estacion, es una cadena del tipo siguiente:
[FBB-5.15-ABFHM$]
y es presentado al usuario durante el proceso de la conexion (antes o despues
de la peticion de PWD, segun el BBS). Esta informacion puede ser usada por el
programa de packet del usuario que se conecta para conocer que software usa
el BBS (en este ejemplo, el FBB), y por tanto, para saber que protocolos de
comunicacion ha de emplear el programa para algunas funciones de este que
implican conexiones autom ticas con el BBS (p.ej, para realizar FWD autom -
tico entre BBS's o entre BBS y estacion terminal).
Con respecto a los sistemas de PWD, muchos programas de filtro de cone-
xion tienen implementados ambos sistemas, el standard de 5 letras y el MD2.
Cuando es asi, las peticiones de PWD usan los dos sistemas simultaneamente,
aunque el usuario que se conecta contestar con el sistema que prefiera, o
que este implementado en su programa. En estos casos, siempre la peticion
segun el metodo standard ha de preceder a la del sistema MD2, y el usuario
sabr cual es cual al tener en cuenta que en el metodo MD2 los caracteres se
envian entre corchetes. La peticion ser algo similar a lo siguiente:
PASSWORD 2 5 7 15 25 [3252cr7i8] ? -->
El usuario podr contestar con una u otra modalidad. Si la respuesta
del usuario son 32 caracteres, el programa filtro interpretar que se le
esta contestando segun el modo MD2, en caso contrario supondr que ser
segun el modo standard de 5 letras.
El forward (FWD) del correo
- - - - - - - - - - - - - -
Normalmente los BBS's realizan el FWD del correo almacenado, tanto de
boletines como de mensajes personales, periodicamente, a horas programadas,
o a horas de bajo trafico, ya programadas, y algunas de ellas incluso recha-
zan conexiones de usuarios terminales a esas horas de bajo trafico (p.ej,
horas nocturnas), para usar los canales de radio a los que esta n conectados
para el FWD. Otras pueden usar canales de radio en otras frecuencias para
realizar a cualquier hora del dia el FWD con otros BBS's, y es usual en
estos casos realizar las transferencias de mensajes a velocidades de trans-
mision mucho mas elevadas que las usadas con los usuarios terminales:
Mientras estos usan la velocidad de 1200 Bd actualmente para VHF/UHF, los
traficos de FWD entre BBS's en canales de radio dedicados a este fin son
como minimo a 9600 Bd, lo cual en la realidad, es trabajar entre 7 y 8 veces
mas rapido que a 1200 Bd. Ello permite una transferencia de datos mas rapida
entre BBS's, o transferir un mayor numero de datos en el mismo tiempo que a
1200 Bd, lo cual da una mayor eficacia al FWD a traves de la red de Packet.
Ademas el FWD puede realizarse segun algunos protocolos y formatos de
envio de la informacion, y los dos mas empleados son los siguientes:
* FWD standard o de protocolo MBL/RLI
* FWD de FBB comprimido (con BBS's de tipo FBB).
El FWD standard o de protocolo MBL/RLI es la version automatizada de
como se envian los mensajes en una conexion manual a la estacion distante.
Cada mensaje se envia integro (sin ninguna manipulacion), y es acabado auto-
m ticamente por el preceptivo /EX en ultima linea que marca el final del
envio de un mensaje. Es decir, el protocolo MBL/RLI transmite la informacion
en formato ASCII (de texto), y por tanto sin ningun tipo de manipulacion
adicional. El nombre de RLI procede del radioaficionado que ideo este metodo
de FWD, el norteamericano W0RLI.
En el FWD comprimido se realiza una compresion de la informacion que se
envia, a formato binario, y ello significa que el tamao de un fichero de
texto se puede reducir sustancialmente, conservando toda la informacion del
texto. Ello se traducir por tanto en un menor tiempo para el envio de bole-
tines y mensajes si esta n en modo comprimido, agilizando el tiempo de ocupa-
cion de los canales de radio y del FWD.
En la estacion de destino, el FWD recibido ser descomprimido para
recuperar la informacion original remitida.
Este protocolo es propio de los BBS's de tipo FBB, y al estar estos muy
difundidos, esta implementado en muchos programas de packet para estaciones
terminales.
El software y el protocolo FBB fue ideado por el radioaficionado
frances F6FBB.
Normalmente cada BBS tiene conocimiento de que BBS's hay declarados en
la red nacional de Packet, y tiene un plan de envio del FWD, dirigido a
determinados BBS's, normalmente a los BBS's mas proximos, asi como a BBS's
de otras provincias, e incluso de otros paises, si con estas hay enlaces
via radio fiables (uso de antenas directivas, por satelite...), o incluso
por conexion telefonica o via Internet. No obstante, el FWD dado a cada
mensaje depender del tipo de este, no es lo mismo un mensaje personal que
un boletin general. Para los mensajes personales se tender a enviarlo a
aquellos BBS's que esten formando parte de la ruta que deberia de seguir ese
mensaje para llegar a su destino. Para los boletines generales, se pretende
dar una difusion m xima de estos a traves de la red de packet, por lo que
cada BBS lo enviar a todos los BBS's con los cuales realice FWD normalmente,
los cuales a su vez realizar n el FWD con los BBS's que estos tengan decla-
rados en su plan de FWD, y asi sucesivamente, y la unica limitacion a este
FWD ser la del ambito geografico al cual va dirigido el boletin: no es lo
mismo un boletin dirigido solo a Catalua (EA3), a Espaa (EA) o a "Todo el
mundo" (WW): El FWD de los distintos boletines ha de realizarse solo dentro
del ambito geografico al cual van dirigidos (aunque el BBS tenga conexiones
con otros BBS's de otros mbitos geogr ficos).
#11.d.- LOS BUZONES PERSONALES O PMS's
Los PMS's son buzones personales de las propias estaciones terminales.
Muchos programas de packet para estacion terminal permiten este modo de
funcionamiento, en el cual la estacion terminal puede operar autom ticamente,
sin la presencia del operador, realizando funciones que lo aproximan a las
de un BBS, aunque sin llegar a ser un BBS:
* Recogida de cabeceras de mensajes del BBS, usando el mecanismo de las listas de Unproto.
* Peticion autom tica al BBS para que envie los mensajes previamente
seleccionados por el operador en la lista unproto, realizando el PMS la
conexion autom tica a su HomeBBS. Estas peticiones suelen ser inmediata-
mente atendidas por el HomeBBS.
* Recepcion autom tica de los mensajes procedentes del HomeBBS que han sido
pedidos (de la lista unproto) y mensajes personales dirigidos al operador
del PMS/estacion terminal, mediante FWD autom tico.
La conexion y el FWD lo puede iniciar autom ticamente, segun los casos,
la PMS (para enviar mensajes al HomeBBS y para recibir los mensajes
seleccionados en la lista unproto) o al HomeBBS (para remitir mensajes
a la PMS. Para esta opcion, normalmente se ha de estar habilitado por el
Sysop del BBS para ello).
* Posibilidad de depositar mensajes en la PMS para que esta realice una
conexion posterior con el HomeBBS y los envie a esta mediante FWD auto-
m tico.
* Tambien suelen permitir que usuarios remotos puedan conectarse al PMS y
realizar cosas, como dejar mensajes y boletines (que pueden ser enviados
posteriormente mediante FWD al HomeBBS, en esto se parecen a los BBS's),
entrar en el sistema para examinar, dejar o traer archivos (siempre el
operador de la estacion pondr limites a lo que se puede hacer o restrin-
gir la entrada al PMS, o acceder mediante password), permite el uso de
"servers" en el buzon, etc...
En la PMS de la estacion, el operador podr examinar todo el correo que
haya depositado en ella (tambien los usuarios remotos).
Este modo de operar es superior al de operar manualmente la estacion
terminal, pues permite al operador de la estacion terminal estar ausente,
mientras su estacion esta trabajando para el. Muchos de los modernos progra-
mas de packet para usuarios terminales incluyen la funcion de PMS.
Los comandos de manejo de la PMS (tanto para el propio operador de la
estacion como para usuarios remotos) suelen ser similares a los empleados
para manejar los BBS's de packet: Se pueden listar mensajes depositados en
el BBS y leerlos (comandos L), borrarlos (comandos K), enviar mensajes a la
PMS (comandos S), etc... El propio operador de la estacion usar estos
comandos desde el teclado de la estacion, los operadores remotos los usar n
como si de un BBS se estuviera tratando.
Es recomendable que para usar una estacion de packet en modo PMS con
largos periodos de funcionamiento, se trabaje con una TNC, y no con el orde-
nador y modem BayCom, ya que ello permite tener el ordenador apagado
(ahorrando consumo electrico) o dedicado a otras cosas, y solo de vez en
cuando podemos acceder con el ordenador a la PMS para ver lo que hay deposi-
ado en ella.
Cuando una estacion terminal esta operando como buzon personal, se
recomienda que use como SSID el valor 8 (Ejemplo: ED3AKJ-8).
#11.e.- LOS NODOS DE PACKET RADIO
Los nodos de packet, tambien definidas como estaciones transportadoras
o nodales, son las que tienen como funcion cursar el trafico entre estaciones
finales o servidoras (los BBS's), asi como entre nodales y finales. Eventual-
mente dan acceso a las estaciones individuales terminales hacia las estacio-
nes finales (BBS's) cuando la ubicacion de las primeras no permita el enlace
directo con las segundas.
Bastantes BBS's de la red de packet tienen un nodo asociado en la propia
instalacion de radio. Entonces, cuando esta trabajando el BBS, sus tramas
llevan el SSID 2 asociado al indicativo de la estacion, pero cuando trabaja
como nodo, aparecer n, segun los casos, los SSIDes 1 o 7 (tipicos).
Un NODO es una TNC con el programa del microprocesador cambiado, junto
con un emisor y su antena. Hay varios programas para que una TNC opere como
nodo, como por ejemplo THENET, NORD-LINK, NET/ROM, TEXNET, BPQ..., y son
bastante similares en cuanto a los comandos de uso. Los nodos pueden operar
con el protocolo AX.25 puro (que es un protocolo de capa de red y enlace)
sin mas (como los BBS's) o incluir protocolos adicionales de orden superior
(de capa de transporte) para el enrutado de los mensajes (caso del protocolo
NET/ROM), soportados sobre el AX.25.
Se situan a se posible en sitios elevados, por lo que pueden recibir a
otras estaciones de packet, del tipo Nodos y BBS principalmente, todos
trabajan en la mismas frecuencias, y ello contribuyen a su fucion principal,
que es la conexion entre buzones (BBS) para el envio de mensajes autom tico
(por forwarding).
Cuando un usuario terminal se desea conectar a un nodo (para poder
acceder a un BBS al cual no llega en directo), ha de pedir conexion al nodo
igual que si fuera a una estacion individual o un BBS, pero a diferencia de
los casos anteriores, cuando se produce la conexion, el nodo no envia mensaje
alguno de conexion, no aparecer nada en la pantalla del terminal.
Sin embargo, el nodo espera un comando para ejecutarlo. Aparentemente parece
que el nodo no hace caso al pedir la conexion, pero ello es consecuencia de
la forma peculiar que usan los nodos para conectarse entre ellos.
Si se envia el comando N, el nodo contestar con la lista de los otros
nodos que escucha y algunos otros que esta n en la lista de estos nodos reci-
bidos.
Si se envia el comando R (o ROUTES), el nodo contestar con la lista de
los nodos que realmente esta recibiendo.
Para pedirle conexion a otro sitio se le pone "C" seguido del indicativo
o el "alias", que es un nombre apodo que tiene el NODO para que sea mas f cil
de recordar.
Tienen mas comandos y mas funciones, no los vamos a describir aqui.
Usualmente se han denominado "nodos" de packet a cualquier punto de
entrada de datos en la red de packet, y ello incluye tanto a estaciones
servidoras (BBS's) y a estaciones nodales.
Los nodos saben donde tienen que encaminar los distintos paquetes diri-
gidos al resto de la red, y ello lo suelen realizar de la siguiente manera:
* Cada nodo dispone de una lista de nodos conocidos de la red de packet a
los cuales tiene acceso, con algunos de los cuales (ya asignados) se
realizar el forward autom tico periodicamente, normalmente a horas de
bajo trafico de usuarios (p.ej, de madrugada). Softwares como el NET/ROM
permiten este tipo de encaminamientos.
* Cada nodo escucha las transmisiones de presencia de los nodos vecinos,
para saber si esta funcionando o si tiene acceso a el (caso de estar
alejado y depender la conexion de la propagacion).
El nodo es capaz de seleccionar las rutas mas favorables hacia otro
NODO si tiene para elegir, ya que las marca con un valor numerico y empieza
por la que tiene asignada el valor mas alto, y si este falla, prueba la
siguiente, y asi hasta varias veces.
El envio de un mismo mensaje desde el nodo de origen a varios nodos
vecinos garantiza la mayor difusion de los boletines que se reciben de los
BBS's, incluso a grandes distancias. Para evitar duplicaciones de los bole-
tines almacenados en los BBS's al ser recibido cualquiera de ellos por
distintos caminos, el BBS que expende un boletin a la red vimos que lo eti-
queta con una identificacion, el "BID", por lo que si un BBS recibe de un
nodo un boletin con un Bid que se corresponde con el de un boletin que ya
tiene almacenado, lo ignora.
NET/ROM es un protocolo que funciona sobre el protocolo AX.25 y que
sirve para el intercambio de informacion entre los nodos sobre que rutas hay
disponibles, con que calidad, etc... NET/ROM tiene en cuenta lo din mica que
es la red de radiopaquete: Nodos que esta n en funcionamiento, nodos que dejan
de funcionar por algun motivo, etc... y permite disponer en los nodos de
una tabla de nodos activos con los que se pueden comunicar, que se actualiza
autom ticamente, y que es consultada por el nodo para los enrutados de los
mensajes. El problema de este protocolo de transporte es que solo gestiona
estaciones de radiopaquete que sean NET/ROM, y por otro lado no es "transpa-
rente": al nodo no se le entregan los paquetes simplemente para que los pase
a sus destinos, sino que hay que conectarse a el, y decirle a que otro nodo
hay que conectarse. Entonces se establece la conexion con el nodo destino a
traves del nodo intermedio, y la conexion dura mientras no se corte alguna
alguna de las conexiones intermedias. Por ello NET/ROM ha demostrado ser una
mala solucion para las comunicaciones en red de las estaciones de
radiopaquete, y hoy en dia esta superado mediante la inclusion de las
estaciones de radiopaquete en Internet mediante el uso del protocolo de
transporte IP (Internet Protocol; ver mas adelante).
Otros softwares tales como el TheNet o el BPQ son softwares para nodos
compatibles con el protocolo Net/Rom. El software BPQ, por ejemplo, permite
conexiones multiples de nodo compatibles con el protocolo Net/Rom, y debe su
nombre al radioaficionado ingles G8BPQ, que fue quien lo ideo en la decada
de los 1990es.
El acceso de los usuarios terminales a los nodos son por canales de
radio en modo semiduplex de baja/media velocidad (hasta 2400 Bd), mientras
para las conexiones entre nodos se recomienda el uso de canales full-duplex
y el trabajo a altas velocidades de transmision (9600 Bd o mas) y en modula-
cion PSK, ya que estas garantizan un mejor manejo de la transferencia de una
elevada cantidad de informaciones.
Finalmente decir que a titulo informativo, las tramas AX.25 intercambia-
das con los nodos de radiopaquete usan en su campo de direccion los SSID -1
y -7 para los nodos de VHF y UHF respectivamente, y en el campo de control
usan los identificadores CF para los nodos Net/Rom y TheNet, y CC o CD si es
un nodo IP.
#12.- EL PROBLEMA DE LAS COLISIONES
#12.a.- INTRODUCCION
Recordemos que el acceso al canal de radio de una estacion de packet
para proceder a enviar paquetes puede ser uno de estos dos modos:
ALOHA: Procedimiento de "acceso al canal sin coordinacion alguna" en la que
cada estacion de radiopaquete transmite sin antes comprobar que el
canal este libre; asi llamado despues de los primeros experimentos
en la Universidad de Hawai.
Conduce a un gran riesgo de colisiones entre estaciones, por lo que
normalmente no se usa, solo en casos especificos de trabajo en packet
(packet por satelite, donde las estaciones que se conectan no se
pueden escuchar entre si).
CSMA.- "Carrier Sence Multiple Accses". Acceso Multiple por Percepcion de
la Portadora: Es el procedimiento usualmente utilizado en el que una
estacion, antes de acceder al canal para transmitir, escucha el canal
durante unos instantes para detectar la presencia de portadoras de
otras estaciones, evitando transmitir hasta que escuche el canal
limpio de transmisiones. Este metodo reduce mucho el riesgo de coli-
siones.
Las estaciones de packet de tipo digipeater, BBS's y nodos, pueden
atender en zonas muy pobladas un fuerte trafico de packet originado por
un alto numero de usuarios, y entonces surge inevitablemente el problema de
las colisiones, por el cual dos estaciones usuarias de un mismo BBS o digi-
peater y que no se escuchan entre si pasan a transmitir a la vez. Si la
seal de una de ellas es predominante (en unos 20 dB como minimo) sobre la
seal de la otra estacion, en el receptor del digipeater o el BBS chafa o
"pisa" totalmente a esta ultima, y el receptor, supongamos es un BBS, solo
recibir la seal de la primera estacion. En el peor de los casos, si las
seales recibidas de ambas estaciones son similares, la mezcla de ambas hace
que el BBS no las entienda y las considere como "ruido".
Este problema es conocido como problema de las "ESTACIONES OCULTAS", y
en estos casos las tramas enviadas por la estacion, cuya transmision es
chafada por la de otra que transmite al mismo tiempo, no son oidas por el BBS
y por tanto no ser n confirmadas por este, lo cual obligar a una nueva
retransmision de dichas tramas por parte de la estacion terminal afectada,
cargando con ello aun mas el trafico de packet con el BBS. Puede ocurrir
tambien que solo sea chafada una parte de la transmision de la estacion
afectada. Si en esa transmision esta transmitiendo varias tramas sucesivas,
puede que algunas de ellas queden afectadas y el BBS no las reconozca, pero
si las demas. Pero esto implica que, para el BBS, va a recibir una serie de
tramas con orden de secuencia incorrecto a partir de una de ellas, y ello va
a dar lugar al envio de tramas REJ hacia la estacion terminal, y nuevo reen-
vios de las tramas por parte de esta, cargando tambien ello el trafico de
packet en el canal de radio.
Si las colisiones son elevadas, incluso puede provocar la desconexion
de alguna de las estaciones conectadas al BBS.
Estos riesgos de colision son elevados cuando el canal esta muy concu-
rrido, asi como tambien cuando hay dos estaciones conectadas al BBS que no
se oyen entre si (caso de BBS's de VHF y UHF con ubicacion en una zona ele-
vada, las cuales oir n a estaciones terminales lejanas que entre si no se
oir n), o cuando hay alguna estacion terminal que trabaja a muy poca potencia
o en malas condiciones de trabajo (antena interior, etc...), que hace dificil
que las demas estaciones terminales la puedan oir.
Siempre ser n perjudicadas las estaciones que trabajan con muy baja
potencia, o alejadas del BBS, sobre todo a las horas de mayor actividad de
packet con el BBS.
Se realizaron en su momento experimentos diferentes para solucionar
este dilema en el Radio Packet. Una posible solucion que fue apuntada es a
traves del uso de repetidores full duplex (BTMA), sin embargo este metodo
tiene muchas desventajas en este sistema. En las instalaciones "full duplex"
los costes de equipos suelen ser mucho mas altos y el sistema ocupa dos
frecuencias (una para cada sentido de transmision) pero solamente usar una
con el maximo rendimiento (del BBS hacia las estaciones terminales).
Una solucion mejor podia ser aumentar el rendimiento del canal a base
de reducir las colisiones en un canal unico, en vez de dividir el trafico en
dos canales. Y este es el metodo usado actualmente.
Los metodos para reducir colisiones van desde aumentar la potencia de
transmision de la estacion (para que la estacion tenga mas posibilidades de
ser oida por las demas estaciones y puedan reconocer estas la condicion de
canal ocupado cuando la primera transmita), operar con el squelch abierto
(si el programa con que funciona la TNC permite esta posibilidad, detectando
el estado de libre u ocupado del canal por software), probar de buscar los
mejores valores de los par metros TXDELAY, DWAIT, MAXFRAME, etc..., usar
modos de persistencia....
#12.b.- LA CAPA MAC DEL MODELO OSI
Anteriormente se explico en que consiste la jerarquia OSI de los proto-
colos de comunicaciones, y dentro de esta jerarquia el denominado Nivel
Fisico es la parte de un sistema de comunicaciones que trata con el medio
fisico (el denominado "Canal de comunicaciones"), y tiene la mision de adap-
tar los paquetes de datos que el Nivel del Enlace le entrega para su trans-
mision por el medio fisico, asi como detectar y recuperar los datos que
aparezcan en el canal de comunicaciones para entregarlos al Nivel de Enlace.
En Radiopaquete digital podemos considerar que existe una subcapa
intermedia entre el nivel fisico (capa 1) y el nivel de enlace (capa 2),
denominada "Subcapa de Acceso al Medio", ya que esta muy ligada al proceso
de transmision de datos. Esta subcapa se encarga de controlar como y en que
momento se debe acceder al canal de comunicaciones cuando se va a transmitir
un paquete, lo cual es especialmente importante cuando hay varias estaciones
que comparten el canal y hay riesgos de colisiones. Esta capa se conoce
tambien como capa MAC (Medium Access Control, control de acceso al medio).
Segun esto, el camino que sigue un paquete AX.25 hasta su transmision
por el canal de radio seria el siguiente:
| |
| Nivel 2 |
| |
e------,------e
|
| (paquete AX.25 formado)
|
v
______|_______
| |
| Nivel MAC |
| |
e------,------e
|
| (se entrega en el momento oportuno)
|
v
______|_______
| |
| Nivel 1 |
| |
e------,------e
|
| (bits codificados en FSK/PSK...)
|
v
(canal de Radio)
Las funciones de estas capas o niveles son realizadas por lo general
por componentes de software (excepto el proceso de codificacion de los bits,
que suele ser realizado mediante el hardware del modem). Estos componentes
de software pueden encontrarse entre nuestro ordenador personal y la TNC,
ya que ambos son ordenadores capaces de ejecutar software. Dependiendo del
tipo de TNC o modem que poseamos, ser capaz de realizar mas o menos funcio-
nes, liberando a la CPU del ordenador de este trabajo (si bien actualmente
cualquier ordenador actual es lo suficientemente potente para realizar este
trabajo sin interferir en las demas tareas que este realizando). A continua-
cion de especifica la distribucion de los niveles OSI para algunos tipos de
TNC's:
Tarjeta SCC / modem TNC KISS TNC TAPR / TF
------------------- --------- -------------
Nivel 1 Nivel 1 Nivel 1
Nivel MAC Nivel MAC
Nivel 2
Asi, en el caso de una TNC con firmware TAPR o TF (WA8DED), ser la TNC
la encargada de realizar las tareas de constitucion de paquetes AX.25 (nivel
2), determinar el momento cuando se pueda enviar el paquete (nivel MAC), y
prepararlo para ser transmitido directamente por la emisora de radio (nivel
1). Ademas, si no se usa el llamado Modo Host de estos firmwares, la TNC
realizar ademas las funciones del Nivel 7 o Nivel de Aplicacion, comport n-
dose en este caso el ordenador como un "terminal tonto", destinado unicamente
a la presentacion por pantalla de los datos que llegan de la TNC y el envio
hacia la TNC de los caracteres que escribe el usuario a traves del teclado.
En el caso de una TNC con firmware KISS, ser el software residente en
el ordenador personal el que formar los paquetes AX.25 y los enviar a la
TNC (usando el protocolo KISS) para su posterior transmision a traves del
canal de radio. Ya que la TNC KISS hace las funciones del Nivel MAC, almace-
nar en su memoria los paquetes que recibe del ordenador hasta el momento en
que sea conveniente su emision.
Por ultimo, si solo poseemos un sencillo modem o una tarjeta SCC inter-
na, ser el ordenador quien ademas decida el momento oportuno en que puede
transmitir los paquetes AX.25, envi ndolos en ese momento al modem o SCC
quienes unicamente realizar n la tarea de codificacion de bits (como se dijo
antes, por lo general esto se realiza con algun componente de hardware, es
decir, un modem) y tambien de proporcionar a la emisora de radio la seal
analogica a transmitir.
Desde el punto de vista del usuario, una TNC KISS y una tarjeta SCC
pueden parecer iguales, sin embargo un modemasuele tener mas limitaciones,
aunque estas esta n impuestas por la forma en que se comunica el modem con el
ordenador. Por lo general, la tendencia actual suele ser dejar al ordenador
la mayor parte de las tareas posibles, ya que esto proporciona una mayor
flexibilidad. La TNC KISS se diferencia de la tarjeta SCC y del modem en un
aspecto aparte de la realizacion del Nivel MAC, que es el empleo del proto-
colo KISS.
#12.c.- EL METODO DE LA PERSISTENCIA
El nivel MAC consiste en un software (ya este en la TNC o en el ordena-
dor) cuya funcion es decidir cu ndo se pueden transmitir los paquetes AX.25
por el canal de radio. Es necesario establecer un "protocolo de acceso al
medio" debido a que el canal de radio empleado puede ser compartido por
varias estaciones, y surgir el problema de las colisiones. Al decir "proto-
colo de acceso al medio" simplemente significa que es una convencion esta-
blecida que hay que seguir en el momento en que deseamos transmitir (esto es,
acceder al medio de transmision de datos, que es el canal de radio).
Los radioaficionados saben lo que es el uso compartido de un canal de
comunicaciones. Por lo general, lo que hacen es esperar hasta que la frecuen-
cia se encuentre libre, y en ese momento aprovechan para transmitir, si es
que alguien no ha sido mas rapido en ello. Pero a veces ocurre que dos
radioaficionados empiezan a transmitir en el mismo momento, haciendo ininte-
ligible uno de los comentarios o incluso los de ambos. Las emisoras de radio-
aficionado no incorporan ningun sistema para detectar esta colision entre
emisiones, debido a que cada persona suele esperar un tiempo ligeramente
distinto a las demas, ya que los humanos no somos del todo precisos, y esto
hace que las colisiones sean infrecuentes.
Sin embargo, los ordenadores pueden alcanzar precisiones del orden de
milisegundos o incluso menores, lo cual conlleva a que si se establece un
tiempo fijo de espera antes de transmitir para cada estacion en el canal de
radio, basta que dos estaciones tengan el mismo tiempo de espera para que
colisionen entre si de forma continuada, lo cual dificulta enormemente la
comunicacion.
Este metodo de elegir de antemano un tiempo de espera antes de trans-
mitir era el empleado en las TNC con firmware TAPR, y se fijaba con el
comando DWAIT. Tecnicamente, esta es una de las formas de implementar un
metodo de acceso multiple por deteccion de portadora (CSMA) "1-persistente",
en el que la probabilidad de transmitir es 1 (100%) en el momento de quedar
el canal libre).
Para mejorar este metodo se emplea el CSMA "p-persistente". Consiste en
que en el momento de transmitir, se "lanzan los dados". Si ganamos, comenza-
mos a transmitir en ese instante. Si perdemos, tendremos que esperar de nuevo
un lapso de tiempo para volver a intentarlo. Es decir, transmitiremos con una
probabilidad dada. Esto a la practica implica que cada estacion espera un
tiempo aleatorio antes de transmitir, lo cual se acerca bastante al metodo
que emplean los radioaficionados de carne y hueso. La probabilidad de trans-
mitir se fija mediante el par metro "p-persistencia", donde p ser un valor
(teoricamente) fraccional entre 0 y 1. En la practica, se emplean valores
enteros para especificar la probabilidad, normalmente con un rango de 0 (0%)
a 255 (100%).
Este procedimiento de acceso al canal, denominado procedimiento de la
persistencia, se establece mediante rutinas pseudoaleatorias del programa de
packet empleado (si usa este procedimiento) estableciendo una probabilidad u
"OPORTUNIDAD" de transmision:
Cuando la TNC deba transmitir datos, genera un numero aleatorio entre
0 y 255 (hace la "tirada de dados"). Si el numero es mas alto que el valor
declarado en un par metro P (PERSIST), puede proceder a transmitir el o los
paquetes que ya tiene preparados para transmitir en cuanto detecte la condi-
cion de canal libre y venzca un tiempo de espera dado, que no es declarado
por DWAIT, sino por otro par metro denominado SLOTTIME, antes de generar un
nuevo numero aleatorio y volver a repetir de nuevo el proceso.
Este par metro que establece el tiempo de espera se llama "SlotTime"
(tiempo de ranura), por la siguiente razon: se considera que el tiempo est
dividido en ranuras ("Slots"). Es como si nos movieramos por una pared en
la que existen una serie de ranuras separadas en intervalos regulares, y es
a traves de estas ranuras como podemos acceder al otro extremo (que seria el
canal de comunicacion). Cada vez que llegamos a una ranura (lo cual ocurre
pasado el Tiempo de Ranura "Slottome") miramos si esta el canal libre para
transmitir, y si es asi lo haremos con una probabilidad epe (de p-persisten-
cia), mediante el "lanzamiento de dados" citado anteriormente. Si no "gana-
mos" en la tirada, esperaremos a que llegue la siguiente ranura para volver
a intentarlo.
Los valores de estos dos par metros, PERSIST y SLOTTIME, se puede esta-
blecer por comando en los programas de packet que usan el procedimiento de
la persistencia (CSMA p-persistente).
Con esto se busca aleatorizar el tiempo de espera de transmision de
paquetes, en lugar de enviarlos esperando un tiempo fijo (solamente el fijado
por DWAIT), una vez el canal es detectado como libre. Este procedimiento
reduce realmente el riesgo de colisiones, si bien seguir n estando mas
desfavorecidas las estaciones que sean mas dificil de ser escuchadas por el
resto de las estaciones. No obstante, se reducen mucho los reenvios de
tramas de informacion, las tramas RR, REJ...
En el siguiente gr fico se muestra la eficiencia en la utilizacion del
canal segun la p-persistencia empleada y con un numero de estaciones dado.
Eficiencia
1.0 -| ____________________________ p=0.01
| .---
0.8 -| /.-------._______
| // __ -------.________ p=0.1
0.6 -| (/.- ---.___
| |/__ --._
0.4 -| |/ -. -
|// -. p=1
0.2 -|| - -._
|| ---.____ ------------- p=0.5
0 -+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 Estaciones
Como se puede observar, con una p-persistencia de 0.01 (que corresponde
a un 1% de probabilidad) se obtiene el mejor resultado en cuanto a utiliza-
cion del canal cuando el numero de estaciones que comparten el canal es
elevado (lo cual es muy comun en el caso del Packet Radio). Sin embargo, el
valor que se suele utilizar en las estaciones de packet radio no baja de 32
(sobre 255), que viene a ser un 18% de probabilidad, y el resultado obtenido
es similar al de la grafica cuando p=0.1, aunque son muchos los radioaficio-
nados que aumentan este valor incluso hasta el 100%, degradando considera-
blemente la eficiencia del canal.
#12.d.- EL PROTOCOLO KISS
Este protocolo surgio de la necesidad de enviar paquetes AX.25 completos
del terminal (el ordenador) a la TNC para que esta los transmitiera por el
canal de radio cuando tenga oportunidad de hacerlo.
KISS es una palabra inglesa que significa "beso", pero en realidad
es un acronimo cuyo significado es "Keep It Simple, Stupid", y que viene a
significar algo asi a "deja que sea tonta y simple", indicando que la TNC
solo va a realizar las acciones minimas necesarias.
Las TNC's KISS se conectan al ordenador por una conexion serie RS-232,
esto es, conectados a uno de los puertos serie del ordenador, y ambos se
comunican a traves de una de las lineas serie (una para cada sentido) de la
conexion RS-232. Los datos se transmiten en formato asincrono 8N1, esto es,
por palabras de 8 bits, sin paridad y un bit de stop o parada.
La TNC tiene que saber cu ndo el ordenador ha terminado de enviar un
paquete AX.25 completo, para lo cual se usa un caracter especial que delimita
los paquetes, llamado FEND (Frame End, Fin de trama o paquete). Pero puesto
que los paquetes AX.25 pueden contener cualquiera de los 256 codigos posibles
que resultan de las combinaciones de 8 bits, y entre los cuales se encuentra
el codigo del caracter FEND, se hace necesario el uso de un nuevo caracter
de especial significado, el caracter FESC (Frame Escape), cuya mision ser
preceder a los posibles caracteres FEND o FESC que puedan aparecer en el
contenido del paquete AX.25.
Estas "tramas" KISS (delimitadas por codigos FEND) no solo pueden con-
tener datos (ya sean paquetes AX.25 o cualquier otra cosa susceptible de ser
retransmitida por la TNC), sino que tambien pueden delimitar comandos KISS,
destinados al ajuste de algunos par metros que ser n empleados por la TNC
para decidir cu ndo puede enviar los paquetes recibidos (esto es, son par -
metros empleados en el Nivel MAC).
Para diferenciar las tramas KISS que contienen datos de las que contie-
nen comandos, se emplea un codigo al principio de cada trama. Este codigo es
un byte que se divide en dos partes de 4 bits cada una: los 4 bits de mas
peso (superiores) indican el puerto de radio por donde se enviar n los datos
o los comandos (de entre 16 posibles que como maximo permite KISS), mientras
que los 4 bits inferiores pueden tener los siguientes significados:
,------,-----------,
|Codigo| Funcion |
|------+-----------|
| 0 | Datos |
| 1 | TXDelay |
| 2 | P-Persist |
| 3 | SlotTime |
| 4 | TXTail |
| 5 | FullDuplex|
| FF | Salir KISS|
e------e-----------e
De esta forma el ordenador puede indicarle a la TNC cu les van a ser los
valores de estos par metros que, por lo general, han sido elegidos por el
usuario. El ultimo codigo, FF en hexadecimal, sirve para indicarle a la TNC
que se desea salir del modo KISS y retornar al modo normal de trabajo, lo
cual es util cuando la TNC puede actuar en otros modos de radiopaquete ademas
del KISS (como es el caso de los firmwares TAPR o TF). Este codigo, a dife-
rencia de los demas, es obvio que no cabe en 4 bits sino que ocupa los 8 bits
del primer codigo de la trama KISS. Por eso, a veces para salir del modo KISS
se suele enviar a la TNC la secuencia de codigos: 192, 255, 192 (FEND, FFh,
FEND).
El protocolo KISS ha sido ampliamente utilizado por los fabricantes de
TNC's en sus firmwares. Algunos han aadido otros codigos para controlar otras
funcionalidades de la TNC. Por lo general, una TNC KISS se comunica con el
ordenador mediante conexion serie RS-232, en formato de datos 8N1, y sin
emplear control de flujo mediante las lineass RTS/CTS de la conexion RS-232
ni tampoco la linea DCD, aunque nada impide que otros fabricantes aadan
estas funcionalidades a la TNC mediante comandos KISS adicionales.
Sin embargo, el protocolo KISS adolece de un problema: no es capaz de
detectar errores en la transmision de datos a traves de la linea serie, ya
que no emplea paridad. Esto no es problema si el paquete de datos que se
envia ya incluye esta deteccion de errores (como es el caso del AX.25, donde
cada paquete lleva un codigo CRC de comprobacion), aunque no se pueden detec-
tar errores en los paquetes de comandos. Para solucionar esto, se han inven-
tado otros protocolos como el SMACK (que anecdoticamente tambien significa
"beso", en ingles), que incluye un codigo CRC de comprobacion en cada trama.
Para terminar con el protocolo KISS, diremos que se puede considerar
que pertenece al Nivel 1 pero solo desde el punto de vista del ordenador, ya
que en el momento de enviar la trama por el canal de radio no quedar rastro
alguno de este protocolo, sino que se emplear otro protocolo de nivel 1.
Podemos decir que el ordenador, cuando le decimos que use una TNC KISS,
emplea el KISS como protocolo de Nivel 1, y no emplea protocolo MAC. Despues
ser la TNC la encargada de transformar las tramas KISS en el formato adecua-
do (tramas HDLC) para su transmision por la radio.
#12.e.- EL METODO DAMA
Existe un procedimiento para los BBS's y nodos para evitar el problema
de las colisiones, y es el procedimiento "DAMA". Este procedimiento no se ha
implantado en Espaa. Es una extension del protocolo AX25 que indica en cada
momento quien debe emitir, quedando los demas en silencio (con el ahorro de
"pisotones" y colisiones que eso conlleva). Literalmente DAMA significa
"Multiple acceso asignado por demanda" (Demand Assigned Multiple Access).
DAMA es un protocolo para la prevencion de Colisiones en el Acceso de
Usuario a un Digipeater. Este protocolo ha sido creado DK4EG, y hasta ahora
solo ha sido instrumentado por DL8ZAW en el Software del Nodo TheNet, perma-
nece aun en el rea de la investigacion y puede traer mejoras en el futuro,
con una mayor comprension tecnica de usuarios de digipeater.
El principio basico es, que el digipeater o BBS llama a cada usuario
individualmente y posiblemente por esa razon no envia el usuario peticion de
repuesta. Por lo tanto no existen colisiones entre usuarios individuales.
En este procedimiento, el problema de un usuario terminal practicamente
se reduce al momento de la conexion al BBS o digipeater, ya que ha de conec-
tarse igual que en los casos normales (mediante ALOHA o CSMA), y pueden haber
en esta fase colisiones entre los intentos de conexion (tramas SABM) y las
estaciones que ya esta n conectadas. Una vez que la peticion de conexion es
reconocida por la estacion principal (BBS, nodo o digipeater), el indicativo
de la estacion que se conecta se incluye en una lista de estaciones conecta-
das en la estacion principal, y de esta forma la estacion principal controla
a todas las que esta n conectadas. La autorizacion para enviar datos se garan-
tiza mediante el empleo de peticiones que pueden estar incluidas en paquetes
de tipo ACK o incluso dentro de paquetes de datos en plena transferencia. Por
lo tanto en este caso, a un usuario solo se le permitir transmitir despues
de recibir la correspondiente autorizacion de la estacion principal. Una vez
que se reciba esta autorizacion se pueden enviar varios paquetes en un solo
bloque. Sin embargo, si el usuario no responde en un tiempo establecido
(p.ej, en 1/2 segundo) entonces la estacion principal supone que el usuario
no llego a recibir la autorizacion para transmitir. La estacion principal va
pasando entonces la autorizacion para transmitir a todos los demas usuarios
de la lista de estaciones conectadas, y una vez terminada vuelve a atender
al primer usuario y le da otra oportunidad. Y asi sucesivamente con el resto
de estaciones conectadas.
Por tanto, con el DAMA implementado, las estaciones terminales no
deber n transmitir hasta que les autorice la estacion principal, y esta ir
dando la autorizacion para transmitir a las estaciones terminales conectadas
de una manera secuencial y ciclica.
Por otra parte, si un usuario terminal recibe en un momento dado la
autorizacion para transmitir (poll) y contesta enviando un paquete tipo I,
la estacion principal no confirmar este paquete hasta que vuelva a tocarle
el turno a ese usuario en la lista, despues de haber servido a todas las
demas estaciones activas. Si cuando es autorizado por la estacion principal,
el usuario responde con un paquete vacio (RR /Bit Final), entonces la esta-
cion principal reducir la prioridad de autorizaciones para dicho usuario,
pues entiende que de momento no va a enviar informacion (tramas I), y se lo
saltar de la lista en el siguiente turno (se agiliza la ocupacion del canal
de radio). Considera a esa estacion terminal moment neamente inactiva (pero
conectada).
Cuando la actividad en el canal aumente, la prioridad de autorizaciones
para las estaciones inactivas puede bajar aun mas, pero cuando esta estacion
responda con un paquete tipo I recobrar otra vez su prioridad original, ya
que pasa a estar de nuevo plenamente activa.
Si se ha entendido lo que se ha explicado hasta el momento del DAMA, se
puede pensar que se esta hablando de protocolo AX.25 nivel 2, y esta es la
razon por la que DAMA puede aplicarse al packet radio. El protocolo AX.25
nivel 2 proporciona todos los elementos necesarios para implementar el DAMA
y no es necesario emplear una nueva sintaxis. La mayoria de las nuevas fun-
ciones que hacen falta se pueden obtener simplemente modificando los actuales
par metros operacionales mientras que el resto se lograria a traves de
pequeos cambios en el firmware (EPROM) de las TNC's.
Por lo tanto, Como se puede incorporar el protocolo DAMA al AX.25
actualmente?
Las estaciones principales (BBS, nodos, digipeaters...) pueden incorpo-
rar el DAMA en el AX25, pero las estaciones terminales pueden manejar o no
un software que no conozca el DAMA. Como el DAMA no requiere ninguna nueva
sintaxis para AX25, puede ser trabajado por las estaciones terminales,
incluso por aquellas que usen programas de packet que no conozcan lo que es
el DAMA. En este caso se deber n de tener en cuenta algunos detalles para
poder trabajar con una estacion principal que trabaje con DAMA.
* Si es la estacion principal la que intenta establecer la conexion con una
estacion terminal, la estacion principal incluye al indicativo de la esta-
cion terminal en la lista de estaciones que esta manejando, y la comienza
a enviar solicitudes de conexion SABM cuando toca a esa estacion.
La estacion llamada deber de contestar con un UA, si no fuera asi despues
de varios intentos, la estacion principal considera a la estacion llamada
como inoperable, y la elimina de su lista.
* Si es el usuario terminal el que se desea conectar a la estacion princi-
pal, empieza a enviar paquetes SABM a la estacion principal en modo CSMA
(el usado normalmente). Se pueden producir colisiones durantes esta fase,
por lo tanto puede que sea necesario repetir los SABM varias veces hasta
que la estacion principal la reconozca y conteste con UA. Entonces la
estacion principal aade el indicativo de la estacion terminal a la lista
de estaciones conectadas, y asi la estacion principal toma el control de
las transmisiones de la estacion conectada. Esta ultima, tras recibir la
trama UA, confirmar su recepcion contestando con RR0.
* Mientras no exista ninguna transferencia de informacion entre el usuario
y la estacion principal, esta enviar sus autorizaciones de transmision
como una trama RR con el correspondiente numero de conteo. Si la respuesta
por parte del usuario es simplemente una RR#, entonces el tiempo transcu-
rrido hasta la siguiente autorizacion para transmitir se alargar para
evitar una carga innecesaria del canal. La cantidad exacta de tiempo a
aadir depende de la actividad total del canal.
Si la transferencia de informacion de otros usuarios simultaneos de la
estacion principal es grande (determinada por el numero de paquetes I
enviados) entonces la cantidad de tiempo aadido antes de atender a una
estacion "inactiva" de la lista es mayor que en el caso en el que haya
poca actividad en el canal.
Eso quiere decir que cuando la frecuencia esta practicamente vacia, los
tiempos de espera se reducen a un minimo, con lo que no se produce una
reduccion de prestaciones en el nodo. Este es el principio del mecanismo
de auto-regulacion del DAMA, que asegura que un canal sea siempre empleado
con sus m ximas prestaciones.
Si alguna vez la estacion principal no recibe un RR del usuario (debido a
colisiones con el envio de autorizacion a transmitir o de respuestas RR de
otros usuarios) entonces la estacion principal pasar a atender a la
siguiente estacion de la lista, y volver a atender a esta estacion cuando
haya acabado con todas las demas de la lista.
Si despues de un cierto numero de intentos enviando la autorizacion a
transmitir esta estacion aun no ha contestado, se le considerar fuera de
alcance de la estacion principal y se eliminar completamente de la lista.
Esto es como decir que hay que mantener la estacion activa contestando a
las solicitudes de la estacion principal para no quedar excluidos.
* En cuanto a las transferencias de informacion entre las estaciones conec-
tadas y la estacion principal, no existen diferencias entre el CSMA normal
y el DAMA. Ya que siempre va a ser la estacion principal la que actue
primero, puede enviar uno o mas paquetes I, o una autorizacion para trans-
mitir (RR), al usuario.
El usuario confirmar los paquetes I recibidos inmediatamente con un RR#,
pero tambien puede enviar sus propios paquetes I con el correspondiente
numero de conteo.
Usando DAMA la estacion principal NO confirmar los paquetes recibidos en
el instante en que sean escuchados. En lugar de ello primero atender a
todas las demas estaciones de la lista y luego respondera con un RR# a las
estaciones que hayan enviado paquetes I junto con una autorizacion de
transmision para dichas estaciones. Esta autorizacion viene a significar
" Tienes alguna otra cosa para mi ?".
* Para la desconexion, si la estacion principal es la que quiere cortar la
conexion, enviar el paquete habitual de DISC al usuario. El usuario
responder entonces rapidamente con un paquete UA (con el bit de "final"
activado). Si el nodo no recibe el UA y vuelve a enviar el paquete DISC,
el usuario responder con un paquete DM. Esto funciona igual que en la
version actual de CSMA.
Cuando sea el usuario el que quiera desconectarse de la estacion principal,
esperar a enviar su paquete DISC hasta haber sido autorizado por la esta-
cion principal. En este caso no hay diferencia entre que la estacion prin-
cipal responda al usuario directamente con un UA o se espere al siguiente
turno para hacerlo. Sin embargo es preferible una contestacion inmediata
de UA por parte de la estacion principal.
Dado que el DAMA usa los mismos elementos que el CSMA ordinario, con la
unica diferencia de que las estaciones conectadas solo deben de transmitir
cuando lo indique la estacion principal, DAMA es muy compatible con el CSMA,
y mientras los usuarios implementan el DAMA en sus programas de packet, los
que aun funcionen en CSMA ordinario pueden operar con estaciones principales
que usen DAMA ajustando una serie de par metros para evitar colisiones con
las estaciones que operen ya con DAMA.
Por ejemplo, el retardo entre la recepcion de un paquete y la confirma-
cion de la TNC (a veces denominado D2 o DWAIT) debe ser reducido a un valor
inferior a 1 segundo. Al mismo tiempo, el intervalo de tiempo entre que se
envia un paquete I y que la TNC envie un RR# para preguntar por un ACK
pendiente a un paquete I ya enviado, debe ser ajustado a un valor que sea
claramente mayor que el tiempo entre dos autorizaciones a transmitir envia-
das por la estacion principal (normalmente mas de 30 segundos a 1200 Bd).
Por tanto, el uso de DAMA tiene la ventaja es el erradicar la satura-
cion del sistema que existe cuando se sobrecarga el canal. Empleando DAMA,
las prestaciones del canal aumentan continuamente hasta alcanzar el maximo.
No existe el efecto que se produce en CSMA, donde a un 60% las prestaciones
caen en picado a causa de las colisiones.
Tambien se da un fuerte componente "social" en el DAMA, sistema en el
que incluso las estaciones menos potentes pueden trabajar a traves de la
estacion principal de forma decente sin ser chafadas por las estaciones
cercanas al nodo.
#12.f.- EL FLEXNET
Es una nueva implementacion del AX25, pero corrigiendo los problemas
que tenia. Por ejemplo: una estacion A manda 4 tramas I a la estacion B.
Pero a causa de una colision o una interferencia moment nea la estacion B
no ha recibido la primera trama I, supongamos es la I0, pero si ha recibido
las tres tramas restantes I1, I2 e I3. Esta informar a A que no ha recibido
la primera, I0, mediante el envio de una trama REJ0, y A vuelve a repetir
los envios de las 4 tramas I, aunque B haya recibido las 3 ultimas correcta-
mente. Se se ve claro que se esta ocupando el canal para mandar 3 paquetes...
que B ha podido escuchar perfectamente. Con el Flex, solo se manda el paquete
que no ha sido confirmado; si se habian recibido los paquetes posteriores a
este correctamente en B, los guarda hasta que llega el que no habia recibido:
B solicitar que A le envie el paquete en cuestion, y cuando lo reciba
correctamente, confirmar este y los que tenia guardados correctamente que
seguian a este: A no se ver obligado a reemitir de nuevo estos ultimos, para
seguir la correcta secuencia de envio del AX25 ordinario (ahorrando tiempo
de envio y de ocupacion del canal).
Otra ventaja del Flexnet es que reparte mejor la actividad en el canal
entre los usuarios que esten usando una estacion principal, p. ej. un BBS.
Si hay un solo usuario conectado al BBS, el Flexnet le ajusta el Max-
frame a 7, y el Frack a valor bajo. Asi le va muy bien al usuario. Pero si
entran nuevos usuarios, le baja el Maxframe y le sube el Frack... , o sea,
que lo reparte segun el numero de usuarios que tiene en la frecuencia...
Ademas tiene un modo de funcionamiento que controla el TXDelay de todos
los usuarios que se conecten a el. Si considera que es excesivo, manda un
mensaje al usuario que dice "TxDelay too long" (TXDelay demasiado largo) y
le desconecta.
El FLEXNET puede implementarse en muchos de los programas de packet
(aadiendo los archivos y controladores adecuados del programa FLEXNET), y
funciona con la mayoria de programas para packet, tales como el FBB, Cluster
de Pavillion, Clusse, TPK, TSTHOST, GP, TOP, Terminal de BayCom, y todos los
que admitan el modo WA8DED (TF).
Como modems, admite BayComes, TNC-2es, tarjeta de sonido, etc..., ya
que el software Flexnet incorpora los drivers correspondientes a estos
dispositivos, incluso para el trabajo multitarea en sistemas operativos como
Windows95 y Windows98.
#13.- EL BUEN PROCEDIMIENTO
Como todos los modos particulares de comunicacion, el uso del packet
tiene recomendadas frecuencias bien precisas para los radioaficionados:
160 m 1,838 - 1,842 Mhz RTTY + packet radio
80 m 3,580 - 3,620 Mhz RTTY + packet radio
40 m 7,035 - 7,045 Mhz RTTY + packet radio
30 m 10,140 - 10,150 Mhz RTTY + packet radio
20 m 14,075 - 14,100 Mhz RTTY + packet radio
17 m 18,100 - 18,110 Mhz RTTY + packet radio
15 m 21,080 - 21,120 Mhz RTTY + packet radio
12 m 24,920 - 24,930 Mhz RTTY + packet radio
10 m 28,050 - 28,150 Mhz RTTY + packet radio
2 m 144,800 - 144,995 Mhz packet radio
70 cm 430,600 - 430,800 Mhz packet radio
433,625 - 433,775 Mhz packet radio
438,025 - 438,175 Mhz packet radio
23 cm 1240,000 - 1241,000 Mhz packet radio
1298,500 - 1300,000 Mhz packet radio
13 cm 2355,000 - 2365,000 Mhz packet radio
2392,000 - 2400,000 Mhz packet radio
Conviene atraer la atencion sobre el hecho de que el comite HF de la
IARU Region 1 preconiza utilizar los mismos segmentos recomendados para el
trafico RTTY y para el packet radio. En USA, se adopto un plan de frecuen-
cias diferente, y asi es corriente escuchar estaciones americanas en 14.103,
14.105 , 14.107 y 14.109 Mhz por ejemplo.
Para evitar las colisiones, elija una frecuencia donde haya menos acti-
vidad.
Llamada CQ: gracias al comando UNPROTO CQ se puede lanzar una llamada,
incluso sin conexion establecida (envio de tramas UI).
La TNC puede tambien enviar autom ticamente un mensaje en el momento de
que una estacion se conecte a nuestra estacion. Este mensaje estar definido
mediante el comando comando CTEXT texto ... o similar, y si CMSG esta ON
entonces su corresponsal ver su texto cuando se conecte a su estacion,
texto que que puede ser un aviso del tipo "Lo siento estoy ausente, estare
de vuelta hacia las 20 horas", o si su sistema posee un PMS "Por favor
conecta con mi PMS en ON7PC-5".
Las TNC pueden enviar un texto de baliza que se puede introducir gracias
al comando de TNC BTEXT, por ejemplo: BTEXT ON7PC * JO20EU * BRUSSELS.
Con esto la estacion tendracomo baliza el envio del texto:
ON7PC * JO20EU * BRUSSELS
envio que se realizar mediante el uso de tramas UI. Existen varias posibi-
lidades de envio, definidas por comando, como son:
* Enviar el texto de la baliza periodicamente cada n x 10 segundos (comando
BEACON EVERY n).
* o despues de n x 10 segundos de desocupacion de la frecuencia (comando
BEACON AFTER n).
Con n=0 se desactiva la baliza.
Las balizas informan periodicamente de la presencia de una estacion en
el canal de radio, que puede incluso no estar conectada con ninguna otra
estacion (las tramas UI pueden enviarse en modo desconectado), pero se
recomienda no usar las balizas en canales cargados de trafico de packet,
como son en horas puntas con digipeaters y BBS's, pues es un trafico ficti-
cio que sobrecargaria al ya existente en el canal de radio.
La funcion de baliza fue introducida en una epoca en la que el packet
radio estaba en estado de balbuceo. Actualmente las frecuencias esta n tan
llenas que se aconseja no poner l a baliza en funcionamiento. Y si lo hace
... haga BEACON EVERY 250 (es decir cada 41e40") y quedese en el cuarto de
radio para responder ... sino la baliza no tiene sentido!
#14.- PACKET Y SATELITES DE RADIOAFICIONADO
Desde el comienzo del packet-radio muchos aficionados pensaron que los
satelites podrian ser un buen complemento a la red terrestre, especialmente
para transportar la mensajeria a puntos distantes o salvar las distancias
transoceanicas. Las primeras pruebas via satelite se hicieron utilizando los
transpondedores analogicos, principalmente diseados para retransmitir voz,
a velocidades comprendidas entre los 300 y 1200 bps.
Este tipo de comunicacion permite el enlace entre dos estaciones en
tiempo real durante el periodo en que las dos estaciones se encuentren en
la zona de cobertura del satelite, ya que este se comporta unicamente como
un repetidor situado en el espacio. En el caso de los satelites de orbita
baja este tiempo es muy corto y limita de forma seria el volumen de informa-
cion que se puede "mover". La solucion a este problema es un tipo de satelite
que pueda almacenar y retransmitir la informacion en otro punto y en otro
momento. El desarrollo de un satelite de estas caracteristicas fue la base
del "Proyecto PACSAT" de AMSAT. Este proyecto, que comenzo en 1983, ha dado
lugar a varios satelites digitales, dedicados fundamentalmente a la transmi-
sion de datos, que actualmente esta n en funcionamiento y a disposicion de
los radioaficionados de todo el mundo.
En la red de radiopaquete terrestre el sistema de uso del canal com-
partido es del tipo CSMA (Carrier Sense Multiple Access), las diferentes
estaciones que operan en semiduplex en la misma frecuencia (canal) solo
transmiten cuando no detectan la portadora de otra estacion. Esta situacion
supone que todas las estaciones se escuchan entre si y que por tanto no hay
"terminales escondidos", cuando esto no sucede asi ocurren colisiones en las
transmisiones y la eficiencia del canal se ve disminuida.
Si la frecuencia queda libre, y distintas estaciones intentan el acceso
al canal de forma simultanea, sin esperar a verificar la presencia de otras
estaciones que hayan comenzado a transmitir, tendremos el metodo de acceso
ALOHA, que conduce a un elevado numero de colisiones.
En el caso del satelite, y debido a la gran cobertura geografica del
mismo, ocurre que las estaciones terrestres no se escuchan entre si, compor-
tandose como terminales escondidos, y que el satelite escucha a todas las
estaciones. Esto hace que el sistema de uso del canal no pueda ser CSMA.
En el caso de que todas las colisiones resulten en la destruccion de
los paquetes, la eficiencia m xima de un canal ALOHA es del 18%, por lo cual
es un procedimiento de muy bajo rendimiento, de ser empleado.
Existen diferentes formas de abordar este problema. Una es el uso de
mas canales (diferentes frecuencias) en el enlace ascendente al satelite,
manteniendo un solo canal en el descendente, de esta forma el satelite reci-
be en varias frecuencias por lo que disminuyen las posibilidades de colision.
Esto incrementa el rendimiento hasta un 72% de la velocidad de transmi-
sion de los datos, pero tiene dos inconvenientes inmediatos: la complejidad
de aadir mas receptores al satelite y la saturacion del sistema cuando el
satelite se encuentre sobre zonas densamente pobladas donde cuatro canales
pueden resultar insufucientes (con uno de bajada).
#14.a.- EL PROTOCOLO PB/PG
La segunda solucion, que es la actualmente adoptada para recoger infor-
macion del satelite (bajar boletines, correo, ficheros, etc), es un protocolo
sencillo de "Acceso Multiple por Division de Tiempo, TDMA (Time-Division
Multiple-Access) que utiliza pequeos periodos de solicitud ALOHA.
Este protocolo, que no exige un enlace exclusivo con el satelite, se
denomina PB (PACSAT Broadcast Protocol). El protocolo PB permite que un
numero de estaciones, actualmente fijado en 20, accedan de forma "simultanea"
(TDMA) al satelite para bajar datos. El satelite forma una lista con las
estaciones solicitantes y las pone en orden, con lo que hace una cola. El
lugar que cada estacion ocupa en la cola depende del momento de acceso, la
longitud de la transaccion solicitada (por ejemplo, una estacion que solicita
un mensaje de pequeo tamao tiene prioridad sobre las que solicitan grandes
ficheros y "salta" al primer lugar de la cola), la prioridad de la solicitud,
etc. El satelite despacha con la estacion que ocupa el primer lugar durante
un breve periodo de tiempo y rota la cola pasando la estacion a ocupar el
ultimo lugar. Cuando se completa la transaccion, la estacion deja su lugar
en la cola y el satelite invita a solicitar (transmitir) a las estaciones
que estan a la espera de que quede un hueco libre, durante este periodo el
acceso es de tipo ALOHA. Para "subir" informacion al satelite resulta nece-
sario conectarse y hacer "log-in" antes de iniciar la transferencia, para
esto se utiliza otro protocolo denominado PG. El satelite admite un maximo
de dos estaciones conectadas en modo PG.
En el modo de trabajo de Packet con satelite se usan actualmente enlaces
a 9600 Baudios como minimo y modulacion FSK, y puede emplearse la modalidad
full-duplex, y esto ultimo es posible ya que las frecuencias para el canal
ascendente y descendente al satelite esta n en distintas bandas de radio, por
lo cual es posible transmitir y recibir al mismo tiempo.
Todo esto contribuye a que las transmisiones de datos sean mas rapidas,
y por tanto a minimizar el tiempo de ocupacion del satelite (permitiendo el
acceso a mas estaciones terrestres de packet), y a disminuir mas el riesgo
de colisiones.
Las TNC's empleados pueden ser del mismo tipo de los que se emplean en
la red terrestre de radiopaquete. B sicamente son versiones del esta ndar
desarrollado por TAPR (Tucson Amateur Packet Radio) con el modelo TNC-2.
La TNC se conecta al ordenador por un puerto serie (RS232). La conexion
entre equipos analogicos (radios) y los digitales (TNC) se hace por medio de
un modem. El tipo de modem a emplear depende de la velocidad y modo de comu-
nicacion que deseemos emplear, los mas utilizados son los modems de 9600 bps
FSK.
James Miller, G3RUH, diseo un modem fullduplex de 9600 bps FSK para
aplicaciones de radioaficionados y este diseo es el mas utilizado en la
actualidad, y de hecho se habla de modems G3RUH o "G3RUH compatibles". Estos
modems se usan en transmisiones de radiopaquete de altas velocidades, y como
se comento al hablar del equipamiento de las estaciones de packet, estos
modems trabajan con la tecnica de modulacion FSK, no AFSK, esto es, modulan
directamente el transmisor de radio con el flujo de bits que la TNC entrega
(y no un tono de baja frecuencia como ocurre en AFSK).
Existen otros modems de este tipo como los diseados por TAPR y otros
grupos de aficionados.
En la actualidad se dispone tambien de modems con proceso digital de
seales (DSP). La ventaja de los DSP es que se pueden programar para traba-
jar con diferentes especificaciones (velocidad, modulacion, etc). Existen
dos DSP en el mercado, desarrolladas por Advanced Electronics Applications
(AEA 2232) y L.L. Grace Inc. (DSP-12), que son adecuados para el trabajo
via satelite, aunque son costosas. AMSAT y TAPR han desarrollado mas recien-
temente una unidad DSP.
#15.- PACKET RADIO E INTERNET
#15.a.- INTRODUCCION SOBRE INTERNET
Desde principios de la decada de los 90es el fenomeno de Internet se ha
popularizado y a ello no ha sido ajeno el mundo de la radioaficion.
Internet es una especie de gran red mundial que ofrece a los usuarios
una serie de servicios de todo tipo: correo electronico (email), transferen-
cias de ficheros (ftp), acceso a paginas personales, de empresas, y documentos
de todo tipo (paginas web), servicios Telnet de conexion remota en modo
terminal a ordenadores distantes, etc...
Internet es en realidad una gran red constituida por un gran numero de
redes de todos tipos, a la cual se puede acceder de diversas maneras, entre
ellas la conexion telefonica a puertas de acceso a Internet. Cualquier red
de ordenadores es susceptible de ser conectada a Internet y formar parte de
esta "Red de redes", desde una red domestica de ordenadores, hasta las redes
de radiopaquete digital.
Internet usa para operar varios protocolos a nivel de las capas de red
y del transporte (segun el modelo OSI), siendo los protocolos IP (Internet
Protocol) y TCP (Transfer Control Protocol) los mas conocidos. Por ello a
Internet y a las redes que operan con estos protocolos se las suele conocer
como redes TCP/IP.
El protocolo IP es el protocolo usado a nivel de capa de red, significa
"Internet Protocol", es decir, protocolo de inter-red (no protocolo de
Internet, aunque es el protocolo de red usado por Internet). IP fue diseado
para unir varias redes con distintos protocolos cada una en una unica red por
encima de ellas, llamada la inter-red o internet (con i minuscula). Entonces
todas las estaciones conectadas en estas redes parecen estar en una misma red,
aunque fisicamente no esten realmente conectadas por un cable, o por un enlace
de radio, o esten conectadas por el medio que sea. Internet (con I mayuscula)
es la mayor internet existente, de mbito mundial.
Una red TCP/IP como Internet esta constituida por una serie de nodos de
la red, y una serie de caminos que unen unos nodos con otros. Los usuarios se
conectan a algun nodo de acceso a la red, bien mediante conexiones fijas,
mediante conexion telefonica o mediante cualquier otro medio.
Son los nodos de la red los encargados de encaminar a traves de esta las
conexiones de los usuarios que solicitan un servicio a los ordenadores o
sistemas conectados a la red que ofrecen el servicio solicitado. Se denominan
como "CLIENTES" a los usuarios que solicitan servicios, y "SERVIDORES" a los
sistemas que pueden ofrecerlos.
El encaminamiento a traves de la red se hace mediante el uso del proto-
colo IP. Para ello cualquier sistema conectado a la red debe de tener una
direccion propia y exclusiva dentro de esa red (algo asi a su numero de
telefono) para que pueda ser identificada dentro de la red. En Internet se
usan las direcciones IP, direcciones constituidas por 32 bits, que correspon-
den a 8 cifras hexadecimales. Normalmente se dan en formato decimal, de la
forma x.x.x.x , donde cada cifra decimal x puede tomar un valor comprendido
entre 0 y 255 (FF hexadecimal). Asi, por ejemplo, las direcciones IP 44.x.x.x
esta n asignadas a organizaciones de radioaficionados, y mas concretamente,
las direcciones 44.133.x.x lo son a las organizaciones espaolas.
Pero el uso de numeros IP para las direcciones de los sistemas conectados
a la red es bastante engorroso para los usuarios (no lo es para las maquinas)
por lo que existe otro sistema que resuelve esta "pega": El uso de direcciones
DNS (Sistema de nombres de dominio), que son mas intuitivas para los usuarios
humanos.
Segun el sistema DNS cada ordenador tiene un nombre y un apellido, por
decirlo de algun modo, compo por ejemplo "ea3zzz.ampr.org" . En realidad una
direccion DNS consta de un nombre de maquina y de lo que se denomina un
"DOMINIO". El dominio viene a ser una especie de grupo de maquinas de
Internet con direcciones parecidas. En este ejemplo, ea3zzz es el nombre de
la maquina y ampr.org es el dominio. Un punto separa al nombre de la maquina
del nombre del dominio que la alberga.
A su vez cada dominio puede estar constituido por varios nombres, sepa-
rados por puntos, siendo el ultimo nombre lo que se denomina el dominio supe-
rior dentro de la red. La estructura de dominios en la red es jer rquica,
constituida por subdominios dentro de otros dominios de mayor envergadura. En
el anterior ejemplo, amrp.org es el nombre de un dominio o grupo de ordenado-
res que en realidad es el subdominio eampre que esta formando parte de un
dominio superior de la red, el dominio eorge.
En el nivel superior del sistema DNS, se asigna un dominio superior en
la red a cada pais y varios dominios genericos, estos ultimos en principio
asignados a Estados Unidos. Algunos ejemplos de dominios de pais son los
siguientes:
.es : Espaa
.fr : Francia
.ar : Argentina
.uk : Reino Unido
.ru : Rusia
En cuanto a los dominios genericos, estos esta n en principio asignados a
Estados Unidos, nacion que no tiene asignado dominio propio de pais, y los
admitidos actualmente son los siguientes:
.org : Para organizaciones de todo tipo, no lucrativas.
.com : Para organismos y firmas comerciales,
.mil : Para organismos militares (estadounidenses),
.edu : Para organismos e instituciones educativas y academicas
(colegios, universidades, etc...),
.net : Para organismos relaccionados con la administracion y uso de
la propia red Internet.
.gov : Para organismos y departamentos gubernamentales (norteame-
ricanos)
.int : Para organismos internacionales (ONU, Cruz Roja,...)
Solo los dominios .mil y .gov son estrictamente para uso de Estados
Unidos, el resto permiten aceptar usuarios de otros paises.
Cuando un usuario desea conectarse a otro usuario o a un servidor de la
red Internet, debe de especificar la identidad de este usuario, y esto se
hace especificando la direccion IP de este, o su direccioon dns. Pero la red
solo entiende de numeros, y por tanto solo opera con direcciones IP. Para
compaginar ambos tipos de direcciones, existen en la red una serie de servi-
dores, que se encargan de traducir direcciones dns (alfanumericas) en direc-
ciones IP. Cuando un nodo de la red recibe una direccion dns, se intentar
conectar a la red de servidores DNS buscando aquel que le traduzca la direc-
cion dns a la correspondiente direccion IP (las tablas de traduccion de
direcciones DNS-IP esta n repartidas entre muchos servidores DNS de todo el
mundo. En realidad, cada servidor DNS guarda una parte de esta tabla, la
correspondiente a la parte de la red que controla).
Asi, por ejemplo, el dominio ampr.org abarca el rango de direcciones IP
44.xxx.xxx.xxx . Una maquina perteneciente a este dominio, por ejemplo,
ea3zzz.ampr.org , tendraasignada una direccion en este rango, por ejemplo
44.23.15.255 .
La transmision de informacion a traves de la red Internet es mediante
paquetes de informacion: La informacion transmitida se fracciona en paquetes
y a cada uno de ellos se aade la direccion IP del destino del paquete. Estas
tramas o paquetes son las generadas a nivel de la capa de red del modelo OSI,
a su vez ser n fraccionadas y enviadas en tramas de capa de enlace mediante
el protocolo de enlace que se emplee en la red, que puede ser por ejemplo el
protocolo X.25 de las redes de datos clasicas, o cualquier otro protocolo de
enlace. La estructura de un paquete IP es del siguiente tipo (ejemplo):
,-------------,-------------,----------------,---------------------,
| Dir origen | Dir destino | Otros datos IP | Informacion enviada |
| 44.133.1.31 | 44.133.2.8 | xxxxxxxxxxxxxx | yyyyyyyyyyyyyyyyyyy |
e-------------e-------------e----------------e---------------------e
IP no es un protocolo de capa de red seguro, no incorpora mecanismos para
la deteccion y correccion de errores de transmision, como ocurre en el proto-
colo X.25 de la capa de enlace. Si toda la red Internet funcionara a nivel de
enlace con el protocolo X.25, un envio erroneo seria detectado a nivel de capa
de enlace, pero en la red Internet hay enlaces entre nodos que usan protocolos
de enlace de distintos tipos, algunos de ellos sin mecanismos de deteccion y
correccion de errores.
Dado que IP es un protocolo poco seguro, y que no se puede garantizar el
uso de protocolos seguros a nivel de capa de enlace, se asigna la seguridad
de la transferencia de informacion al la capa de transporte, por encima de la
capa de red, y para ello se usa el otro protocolo citado, el protocolo TCP o
protocolo de control de transferencias.
El conjunto de protocolos usados en Internet queda en el modelo OSI asi:
,--------------------,
Protocolo de transporte | TCP |
|--------------------|
Protocolo de red | IP |
|--------------------|
Protocolo de enlace | X.25 , otros... |
|--------------------|
| Nivel fisico |
e--------------------e
Los errores de la transmision de informacion si son detectados a nivel
del protocolo TCP, el cual si provee de mecanismos de deteccion y correccion
de errores. Pero ademas tiene otra funcion importante: proporcionar multiples
conexiones de usuario.
En efecto, cada ordenador conectado a la red tiene una direccion IP,
unica, y sin embargo, puede mantener varias conexiones, con otros ordenadores
a traves de la red: Puede estar usando un servicio de mensajeria electronica
(email) conectado a un servidor de correo electronico, mantener una conexion
ftp con otro ordenador para transferir un fichero, y a la vez estar examinando
una pagina web alojada en otro ordenador de la red. Incluso puede darse el
caso de que las conexiones sean con una misma maquina remota, con lo que
habrian dos maquinas conectadas a traves de la red usando tres servicios
distintos. A nivel de red, ambas maquinas estarian conectadas mediante varias
conexiones IP que tienen las mismas direcciones de origen y las mismas de
destino. Como diferencia cada sistema que paquete IP va destinado a uno u
otro servicio?. El protocolo IP solo establece conexiones entre maquinas
(entre direcciones IP), no sabe nada sobre que tipo de informacion transmiten
los paquetes transmitidos entre maquinas.
El protocolo TCP resuelve este problema, ya que si tiene en cuenta el
tipo de informacion transmitido, esto es, el tipo de servicio que esta usando
en cada caso. Ello permite diferenciar las distintas conexiones IP que tenga
establecida cada maquina a traves de la red con otra u otras. Para ello se
establece el concepto de PUERTO (port).
En TCP un puerto es un numero que identifica un tipo de servicio de
Internet, y es un concepto de tipo logico (no tiene nada que ver con los
puertos fisicos de un ordenador). Cuando se establece una conexion IP entre
dos maquinas a traves de Internet, ademas de las direcciones de Internet del
ordenador de origen y de destino, que son manejadas por el protocolo IP, hay
que especificar la direccion de los puertos implicados en cada maquina, ya
que identifican el tipo de servicio que usar esa conexion IP. Por tanto,
se usan direcciones del tipo: x.x.x.x:p , donde x.x.x.x es la direccion IP,
y p es el puerto solicitado en la maquina (que es un concepto del protocolo
TCP). Dos puntos se suelen usar para separar la direccion IP de la direccion
de puerto. Ejemplo: 192.15.63.225:80 . Esto indica el puerto 80 de la maquina
cuya direccion IP es la 192.15.63.225 .
Por tanto dos maquinas pueden tener establecidas dos o mas conexiones IP
a traves de la red entre ellas, y dado que las direcciones IP de las maquinas
de origen y de destino son las mismas en cada conexion IP, estas conexiones
se diferenciar n entonces por los puertos conectados en ambas maquinas, es
decir, se diferenciar n a nivel del protocolo TCP.
Existen una serie de puertos en los servidores de la red que esta n estan-
darizados, y que identifican por tanto al tipo de servicio que prestan.
Algunos de ellos, los mas conocidos, son los siguientes:
Puerto Servicio
------ ------------
23 Telnet (conexiones remotas en modo terminal)
20 FTP (Transferencia de ficheros)
80 http (paginas web, documentos en la red, www...)
25 Email (correo electronico) mediante servidores de protocolo SMTP
110 Email a traves de servidores de protocolo POP3
Cuando el servicio solicitado por un usuario a un servidor de la red es
accedido a traves del puerto esta ndar en el servidor, no es necesario especi-
ficar el numero de puerto, de lo contrario si debe de ser especificado.
Finalmente decir que cada tipo de servicio usa un protocolo propio para
la transferencia de informacion, protocolo que esta por encima del protocolo
TCP en el modelo OSI: Son protocolos de nivel de capa de aplicacion. Asi se
habla de los protocolos Telnet, FTP, http, SMTP, POP3, etc.. como protocolos
que soportan los distintos servicios existentes en Internet.
Los distintos servicios son dados por los programas adecuados tanto en
los ordenadores clientes (usuarios) como en los servidores. No son los mismos
softwares los empleados en clientes y servidores, ya que un "PROGRAMA CLIENTE"
esta especializado en solicitar un servicio, y un "PROGRAMA SERVIDOR" est
especializado en darlo. El requisito que han de cumplir es que para que un
usuario acceda a un servicio, use un programa cliente en su maquina que se
corresponda o sea compatible con el programa servidor correspondiente usado
por el servidor al que desea acceder.
Con todo esto, la pila de protocolos usados en Internet, segun el modelo
OSI, seria del siguiente tipo:
,--------------------,
| telnet, pop3, irc, |
Protocolos de aplicacion | ftp, http, smtp, |
| otros.... |
|--------------------|
Protocolo de transporte | TCP |
|--------------------|
Protocolo de red | IP |
|--------------------|
Protocolo de enlace | X.25 , otros... |
|--------------------|
| Nivel fisico |
e--------------------e
#15.b.- RADIOPAQUETE DIGITAL E INTERNET
Hecha esta introduccion a Internet, vamos a ver como se puede aplicar
Internet dentro de la modalidad del Radiopaquete digital.
Varios usos son posibles (y se esta n usando algunas de ellas):
* Acceso de los usuarios terminales a los BBS de radiopaquete a traves de Internet (y no por conexion clasica por radio).
* BBS conectados a traves de Internet, para fordward de la mensajeria entre
BBS's a traves de la red.
* Ofrecer servicios de Internet a los usuarios terminales a traves de los BBS de radiopaquete (tipicamente correo electronico).
* Integrar las estaciones de radiopaquete en la red Internet asignandolas direcciones IP reales, tanto a BBS's como a estaciones terminales que acceden a estas por conexion radioelectrica.
Veamos cada uno de estos casos posibles. En todos ellos es necesario que
los BBS's implicados tengan acceso a Internet, y por tanto, tengan asignada
alguna direccion IP. Han de tener algun tipo de "Gateway" con Internet.
Por otro lado dado que Internet esta abierto a todo tipo de usuarios, los
sistemas de radioaficionados conectados a la red han de tener algun tipo de
filtrado del acceso a ellos a traves de Internet, para evitar el acceso de
usuarios no radioaficionados. El uso de claves de acceso o "passwords" se hace
entonces necesario, y ello es posible en todos los servicios de Internet que
un sistema conectado a la red puede proporcionar.
ACCESO DE USUARIOS MEDIANTE TELNET
- - - - - - - - - - - - - - - - - -
Telnet es uno de los servicios mas antiguos soportados por Internet, y
permite la conexion en modo terminal de un ordenador o terminal de usuario a
otro ordenador o sistema host, a traves de la red Internet, usando para ello
el protocolo Telnet (protocolo de nivel de aplicacion).
Mediante este servicio, un usuario, usando un programa cliente Telnet,
puede conectarse a otro ordenador que use un programa servidor de Telnet, a
traves de la red, y entonces funcionar como un terminal conectado al ordenador
servidor, que hace de host. En el caso del radiopaquete esto consistiria en
que el usuario terminal conecta en modo terminal su sistema a un BBS no a
traves de una conexion a traves de las ondas radioelectricas, como es tradi-
cional, sino mediante una conexion Telnet a traves de Internet.
Para ello el BBS ha de tener uno de sus puertos fisicos conectados a un
acceso a Internet (en lugar de a un TNC y/o equipo de radio), y el software de
BBS que use ha de incorporar una aplicacion servidor de Telnet. An logamente
el usuario terminal requiere disponer de al menos un programa cliente Telnet
que le permita conectarse mediante protocolo Telnet al BBS a traves de la
linea de acceso a Internet que use (conexion telefonica, RDSI, cable, ADSL..).
El usuario debe de especificar la direccion IP o la direccion dns del BBS al
que desea acceder, y su software cliente establecer la conexion con este.
La conexion Telnet entre el usuario y el BBS usa el protocolo Telnet,
no tiene nada que ver con el intercambio de tramas de capa de enlace que se
usa en el protocolo AX.25, y una vez establecida la conexion entre el usuario
terminal y el BBS, el usuario opera exactamente igual que si estuviera conec-
tado a traves de las ondas de radio: puede enviar los mismos comandos al BBS,
recibir boletines y mensajes personales, etc...
La ventaja de este tipo de acceso a los BBS es que las transferencias son
mucho mas rapidas (a una velocidad muy superior a los 1200 Bd que usan la
mayoria de las conexiones via radio, y sin que la conexion Telnet este compar-
tida con otros usuarios, cosa que no ocurre via radio), si bien como desven-
taja los mas puristas dicen que este modo de hacer radiopaquete no es hacer
radio.
En cualquier caso, muchos softwares actuales de BBS (como el WinFBB) y de
usuario (como el WinPack) incluyen respectivamente una aplicacion servidor o
cliente de Telnet, lo que posibilita que, por ejemplo, un usuario pueda usar
una mismo programa de Packet radio para conectarse via radio con su BBS local,
o via Telnet por Internet con un BBS que puede estar ubicado en cualquier
parte del mundo.
FORWARD ENTRE BBS POR INTERNET
- - - - - - - - - - - - - - - -
De igual manera que un usuario puede acceder por Internet a un BBS,
tambien es posible conectar dos BBS's entre si a traves de Internet para la
transferencia de mensajeria y ficheros. Para ello suelen usarse los servicios
de Telnet, mensajeria electronica y ftp.
La utilidad de esto es el forward entre BBS's, mucho mas rapida y segura
que el tradicional forward a traves de las ondas radioelectricas, y con la
ventaja que el forward se puede hacer con cualquier BBS del mundo.
Los BBS's actuales que disponen de este servicio usan el forward con
BBS's proximas a traves de radio, y forward con algun BBS remoto a traves de
Internet.
OFRECIMIENTO DE CORREO ELECTRONICO A USUARIOS TERMINALES
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mediante los server adecuados, los sistemas BBS con acceso a Internet
pueden ofrecer algunos servicios de Internet a los usuarios terminales de
radiopaquete, tipicamente el servicio de correo electronico y el de "news"
(noticias), servicios que no dan lugar a la transferencia de un gran volumen
de datos, y que se pueden soportar por tanto mediante el envio de mensajes
personales y boletines a traves de la red de radiopaquete.
Tipicamente el servicio funciona gracias a la inclusion en el BBS de un
server para correo electronico y un programa cliente de correo. El server es
es capaz de recibir mensajes de los usuarios terminales y enviarlos a su
destino como emails, o recibir emails desde Internet y meterlos en mensajes
personales que son enviados a traves de la red de packet a los correspondien-
tes usuarios terminales.
Para enviar un correo electronico un usuario terminal tipicamente se
conecta a su BBS, y dirige un mensaje personal al server del BBS que soporte
el servicio (procedimiento igual al usado para acceder a otros Servers),
poniendo como tema del mensaje la direccion de email al que se envia este. El
BBS local de usuario har llegar mediante forward el mensaje al BBS en cues-
tion, y su server ser el encargado de transformar el formato del mensaje
personal recibido en formato de email para su envio al destinatario a traves
de Internet. Un camino similar, a la inversa, ser el empleado por los emails
recibidos en el BBS desde Internet con destino a usuarios terminales de la
red de radiopaquete.
INTEGRACION DE ESTACIONES TERMINALES DE RADIOPAQUETE EN INTERNET
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Este ultimo caso consiste en integrar las estaciones terminales en la
propia Internet, asign ndoles direcciones IP propias, y por tanto, direccio-
nes DNS opcionales, tipicas de los ususarios de Internet, asi como la exten-
sion del protocolo TCP-IP hasta las propias estaciones terminales de radio-
paquete.
Para ello es necesario que los BBS soporten un acceso a Internet que le
permita disponer de algun dominio, y por tanto de un rango de direcciones IP.
El propio BBS tendra asignada una o varias direcciones de ese rango, el resto
de las direcciones las puede asignar a sus usuarios terminales.
Y tambien es necesario que las estaciones terminales soporten el proto-
colo TCP-IP, lo que les permitir acceder a los servicios de Internet que
permita el BBS con mas o menos limitaciones (limitaciones impuestas por las
velocidades globales de las conexiones a traves de las conexiones via radio,
bajas para permitir grandes transferencias de datos). Los servicios de
correo electonico y de transferencias de ficheros (ftp) suelen ser los que
normalmente se habilitan.
Las estaciones terminales se conectan al BBS mediante enlaces via radio,
como es habitual, usando el protocolo AX.25 . Pero la transferencia de infor-
macion no se raliza en modo llano, como se haria normalmente, sino usando
los protocolos TCP-IP, esto es, mediante el envio de paquetes IP.
El protocolo AX.25 es un protocolo que afecta a las capas 2 y 3 del
modelo OSI, que permite establecer las conexiones entre elementos de la red
de radiopaquete (BBS's, estaciones terminales), mientras que el protocolo
TCP-IP afecta a las capas 4 y 5 del modelo OSI (capas de transporte y de
aplicacion respectivamente).
Lo que se propone aqui es que las estaciones terminales puedan acceder
a los servicios de Internet a traves de su HomeBBS usando el protocolo TCP-
IP, pero soportado sobre conexiones las AX.25 . Y esto actualmente se consi-
gue con softwares para radiopaquete digital pensados para soportar TCP-IP,
como son los softwares NOS (JNOS, TNOS...) o incluyendo modulos adicionales
de TCP-IP para softwares de radiopaquete digital cl sico.
Esto implica que cada usuario terminal tendra asignadas dos direcciones
para estos procesos: Por un lado la que usa para identificarse en la red de
radiopaquete AX.25, y por otro lado la direccion IP que se le haya asignado
como usuario IP de su HomeBBS. En su HomeBBS deber de existir un fichero,
el fichero Host, donde esten recogidas las correspondencias entre las direc-
ciones AX.25 de las estaciones de radiopaquete y las direcciones IP que
tengan asignadas.
Sea por ejemplo el siguiente caso:
En la provincia XX hay un BBS llamado EA5XX-2.
En la provincia YY hay un BBS llamado EA5YY-2.
Uniendo a ambos, en lo alto de un monte, hay un nodo enlace EA5XY-1.
Tenemos 2 usuarios, uno de cada BBS:
EB5XXX es un usuario de EA5XX-2 y EB5YYY es un usuario de EA5YY-2.
Tradicionalmente, si EB5XXX quiere enviar algo a EB5YYY, el camino que
deben de seguir los paquetes de AX.25 es el diguiente:
/==> EA5XY-2 <==
EB5XXX <--> EA5XX-2 <==/ /""" ==> EA5YY-2 <--> EB5YYY
_____________________________/ -_______________________________
usuario BBS Nodo BBS Usuario
En este gr fico <--> son los enlaces "lentos" (1200 baudios), mientras
que los <===> son los "rapidos" (9600 bits por segundo).
Los protocolos usados serian AX.25 "puro" en los enlaces lentos a 1200 Bd.
En los enlaces con el nodo puede haber AX.25 puro, o NET/ROM + AX.25, depende
de los casos. Entre nodos deberia haber NET/ROM + AX.25 ( NET/ROM es un
protocolo que funciona sobre AX.25 y que sirve para el intercambio de infor-
macion entre los nodos sobre que rutas hay disponibles, con que calidad,...).
Pero si se introduce el protocolo TCP-IP, y se asignan direcciones IP a
todas las estaciones, la configuracion anterior no cambia, y en todo caso es
recomendable (aunque no imprescindible) que cambie la velocidad de los enla-
ces, en especial la de los mas lentos (los de los usuarios terminales).
Lo que cambian son los protocolos: Todas las estaciones deben de soportar
ahora el protocolo TCP-IP, soportado sobre el protocolo AX.25. Con todo esto
el grafico ahora podria quedar asi:
44.133.1.1
44.133.1.31 44.133.1.15 /==> EA5XY-2 <== 44.133.2.8 44.133.2.36
EB5XXX <--> EA5XX-2 <==/ /""" ==> EA5YY-2 <--> EB5YYY
_____________________________/ -_______________________________
usuario BBS Nodo BBS Usuario
Ademas de los indicativos de cada estacion, que son necesarios para las
identificaciones de estas en el protocolo AX.25, cada estacion deber tener
ahora un numero IP asignado, necesario para los protocolos TCP-IP. Recordar
a este respecto que los numeros IP de la serie 44.x.x.x fueron reservados
para los radioaficionados a nivel mundial, de los cuales los 44.133.x.x le
corresponden a Espaa. La tercera cifra de las 4 es el codigo postal de la
provincia.
Con todo esto se consiguen varias cosas:
* Que todas las estaciones de la red de radiopaquete funcionen con un unico
protocolo: IP. AX.25 queda como mero "transportista" de la informacion
de IP en cada uno de los enlaces. Incluso aunque se inventara un proto-
colo de red mas rapido que el AX.25, solo bastaria sustituir el AX.25 por
el nuevo protocolo y nada mas. IP funcionaria sobre el nuevo protocolo.
Esto conlleva otra consecuencia:
Independencia fisica: Da igual que los enlaces sean por radio, por cable
o por cualquier otro medio, y por donde va este. Simplemente el protocolo
IP ha de ser soportado por el protocolo de red empleado en cada tipo de
enlace.
Y otra cosa: mientras AX.25 funciona entre 2 estaciones que se conectan
directamente, TCP-IP funciona directamente entre 2 estaciones IP, asi
que no tienen por que estar conectadas directamente. El protocolo IP ya
se encargar que los paquetes lleguen ambas estaciones.
* Que todas las estaciones IP de la red de radiopaquete puedan conectar con
cualquier otra que este activa, este donde este ubicada (aunque sea en un
BBS distante). Incluso con los nodos (pues tienen direccion IP), pero estos,
por su funcion, rechazar n las conexiones IP que no esten referidas a la
transmision de paquetes entre BBS's : un nodo solo ofrece servicios de
"puente" entre BBS's, no necesita prestar otros servicios, como la mensaje-
ria.
* Todo esto da una nueva gran ventaja: La red de radiopaquete queda unifica-
da. Con solo AX.25 la estructura de la red de radiopaquete clasica se
parece a la practica mas a un conjunto de pequeas redes que de vez en
cuando, por un corto espacio de tiempo, esta n conectadas entre si para
permitir el forwarding. Pero con los protocolos TCP-IP quedan integradas
dentro de la estructura de Internet, y por tanto conectadas a una red
global. Cualquier estacion IP de la red de radiopaquete puede comunicarse
con cualquier otra, siempre que este activa. Un mecanismo, llamado "ping"
permite comprobar a cualquier usuario de Internet (y por tanto a una
estacion IP de radiopaquete) si otro usuario de Internet esta activo o no
en cualquier momento. Este mecanismo consiste en enviar un paquete IP de
"sondeo" a la direccion IP deseada, y si la estacion correspondiente est
activa en Internet, responder a la primera con un paquete IP de respuesta.
Cuando una estacion terminal se conecta a su HomeBBS usar como direc-
cion el indicativo del BBS, ya que las conexiones son mediante AX.25 . Pero
si la estacion terminal usa ademas el protocolo IP, y envia una direccion
IP de otra estacion con la que desea conectarse, el nivel de AX.25 del BBS
se dar cuenta de que recibe paquetes AX.25 que como informacion llevan
paquetes IP,, por lo que estos los pasar al nivel IP del BBS. Este nivel
observar la direccion de destino del paquete, y mirar en su fichero Host
si corresponde a un usuario del mismo BBS o es de un usuario ajeno al BBS
(lo mismo ocurrir si el BBS recibe un paquete IP procedente de Internet).
Si la direccion IP de destino corresponde a un usuario del mismo BBS, este
sabr si esta conectado y usando el protocolo IP. Si es de un usuario ajeno
al BBS, este enviar pings a la direccion de destino para saber si est
activo. Si la direccion de destino esta activa, el BBS proceder a enviarle
la informacion que le envie el usuario terminal. Si no esta activo, deber
de almacenar la informacion y enviarla cuando detecte al usuario de destino
activo a traves de Internet.
Los BBS's pueden hacer la funcion de "gateway" con Internet para los
paquetes IP que vayan dirigidos a/desde usuarios ajenos al BBS. Pero
tambien se puede encargar esta funcion a los nodos de la red de radiopacket,
de manera que los BBS pueden no tener conexiones a Internet, y encaminen
el trafico de paquetes IP al nodo del que dependen si no van dirigidos a
usuarios terminales del BBS. En este caso, el nodo actua como gateway para
la subred que estaria constituida por todos los BBS's y sus usuarios termi-
nales, que tienen acceso a dicho nodo.
Finalmente decir que las estaciones terminales que usan el protocolo
TCP-IP usan el SSID -4 (En el campo de direccion de las tramas AX.25), y
todas las estaciones TCP-IP usan los identificadores CC o CD en el campo
de control de las tramas AX.25 .
#16.- ALGUNAS APLICACIONES ADICIONALES DEL PACKET
#16.a.- ESTACIONES CLUSTER
La red de cluster es una red paralela de radiopaquete digital, creada
para el uso de los radioaficionados que practican la actividad del DX ("caza"
de comunicados con estaciones de todo el mundo, sobre todo en concursos)
tanto en HF (principalmente) como en otras bandas.
El servicio de cluster se basa en que si un radioaficionado DX-ista
escucha una estacion interesante para hacer un contacto, genera un boletin
informativo que envia al resto de los usuarios del cluster, boletin en el
que explica que estacion y en que frecuencia ha sido oida, ademas de posibles
comentarios adicionales. De esta forma otros usuarios del cluster son infor-
mados de este evento y pueden intentar hacer tambien el contacto con la
estacion que se informa.
Lo interesante del servicio cluster es tener todos los cluster nacio-
nales, o incluso internacionales, conectados. A nivel local las estaciones
terminales no requieren mas que tener el equipo de VHF o UHF conectado a la
frecuencia de la estacion local de cluster e ir pasando o cogiendo la infor-
macion de DX que circule por el cluster, todo ello mientras puede estar
trabajando con su transceptor de HF (u otras bandas) en la actividad de DX.
Lo fundamental de una red cluster es que exige velocidad por encima de
fiabilidad en la circulacion de los mensajes. Es mas importante que un
mensaje llegue rapido a todos los posibles usuario, a garantizar que llegue
bien. Porque tratar de garantizar que un mensaje llegue bien puede significar
un retraso en la difusion del mensaje, de tal forma que cuando llegue a
otros usuarios, la informacion puede ya ser inutil, incluso en cuestion de
media hora.
Las redes de clusters son similares a las de radiopaquete clasica, esta n
formadas por estaciones clusters, que equivalen a los BBS's de las redes de
radiopacket clasicas, y estas se identifican con el SSID -5 (en el campo de
direccion de las tramas AX.25) en lugar del SSID -2 de las estaciones BBS.
Los usuarios terminales siguen usando su SSID -0 tipico de usuario terminal
de una red de radiopaquete. Por otro lado los mismos programas terminales
que se usan para radiopaquete ordinario sirven para la operacion con los
clusters, lo que va a variar va a ser el software de las estaciones cluster:
A nivel de AX.25 trabajar n igual que cualquier estacion de radiopaquete, lo
que varia es el repertorio de comandos que usan, que es diferente al usado
por los BBS, ya que es mas apropiado para el tipo de boletines que circulan
por la red de cluster. Ello no impide que las estaciones cluster permitan
tambien el servicio de mensajeria tipico de los BBS, pero no es su funcion
b sica.
Incluso las estaciones BBS pueden incluir un cluster, y desde el propio
BBS se puede pasar al modo cluster mediante el comando adecuado del BBS (un
comando de "modo de trabajo", que permite pasar del modo de mensajeria ordi-
nario del BBS al modo cluster).
Como ejemplo del repertorio de comandos que usan las estaciones cluster
con los usuarios terminales esta la siguiente (lista abreviada), usada en
estaciones cluster con software FBB:
Comando Abr. Descripcion Ejemplo
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ANNOUNCE A Hace un anuncio general al nodo local A
ANNOUNCE A/F Hace un anuncio general para toda la red A/F
BYE B Bye, adios, salir del PacketCluster B
CONFERENCE Entra en el modo conferencia de la red CONFER
DELETE DE Borra el mensaje de correo indicado DE MSJ#
DIRECTORY DI Muestra los mensajes activos del correo DI
DIRECTORY DI/A Muestra todos los mensajes activos DI/A
DIRECTORY DI/O Muestra el correo de o para ti DI/O
DX DX Realiza un anuncio de DX en la red DX QRG INDIC.
LIST L Sinonimo de DIRECTORY L
Show DX SH/DX Muestra los ultimos anuncios de DX SH/DX
HELP H , ? Ayuda (muestra este listado) H
HELP comando Muestra ayuda para un comando particular HELP SHOW
QUIT Q Sinonimo de BYE Q
READ R Lee un mensaje de correo R MSJ#
REPLY REP Contesta ultimo mensaje de correo leido REP MSJ#
SEND indicat Envia mensaje a una sola estacion SEND N6IXX
SEND indic,indic Envia mensaje a varias estaciones
SEND N6IXX,W6GO,K6LLK
SEND S , S/P Envia un mensaje de correo privado S EA3KKK
S/P EA3KKK
TALK T Conversacion con la estacion indicada T K6LLK
TYPE TY Muestra un fichero en particular: TY/BULLetin User.cmd
UPDATE UPD Actualiza una base de datos, enviando un
registro (nuevo o de actualizacion). UPD/Basedat
UPLOAD/FILE Descarga un fichero generico UPL/File
UPLOAD/BULLETIN Descarga un fichero de boletines UPL/Bull
WWV WWV Hace anuncio WWV (informe de propagacion)
WWV SF=xxx,A=xx,K=xx,Prediccion
WX WX Hace un anuncio del tiempo WX
SHOW SH/basedat Muestra el contenido de alguna base de
datos del PacketCluster SH/USERS
SET SET/dato Entrar datos (personales y de otros tipos)
al cluster (se almacenar n en la base de datos
correspondiente), o activa ciertos servicios
del cluster. SET/NAME PEPE
(Nota: MSG# = numero de mensaje).
#16.b.- ESTACIONES APRS
El APRS es un sistema autom tico de Informacion de posicion, es decir que
podemos ver en un mapa la posicion en la que esta una estacion fija o movil
de radioaficionado. Tambien tiene otras capacidades como poder ver informacion
meteorologica, sealizacion en el mapa de todo tipo de eventos (cat strofes,
puntos de interes para el radioaficionado) o telemando.
Combinando un receptor GPS (Posicionamiento global por satelite) con un
equipo transmisor de Packet-radio (Radio + TNC o similar), puede enviarse
por packet la informacion de posicion de la estacion a traves de las ondas
radioelectricas.
Si esta estacion esta situada en un movil que se desplaza, y enviando
esta cada cierto tiempo su ubicacion de esta manera, la estacion movil estar
localizada en todo momento, e incluso puede ser seguida sobre un mapa de la
zona.
El receptor GPS de la estacion movil ha de disponer de una salida RS232
que le permita conectarse a un ordenador (y este, a su vez ha de conectarse
a un transmisor de radiopaquete).
De la combinacion del radiopaquete digital con las tecnicas de posicio-
namiento (basadas principalmente en el uso del GPS), nacio en la decada de
los 90 de la mano de un radioaficionado norteamericano, Bob Bruninga WB4APR,
la nueva modalidad digital conocida como APRS (Automatic Packet Reporter
System), que entre las cosas mas vistosas que tiene es que puede presentar
en la pantalla del ordenador en el que corra un programa de APRS mapas de
zonas locales o mas extensas (incluso de mbito mundial) en la que queden
marcadas las posiciones de las estaciones (con su identificacion) que esten
transmitiendo informacion de posicionamiento APRS. Y no solo estaciones de
radioaficionado, APRS permite que puedan ser muchas otras cosas las que se
puedan representar en los mapas mediante iconos especificos para cada caso
siempre que se informe de su posicion geografica exacta: Repetidores de
radioaficionado, puestos de socorro en carretera, hospitales, aviones en
vuelo, barcos, incendios forestales, lluvia, nieve, etc...
El APRS funciona a traves del protocolo AX.25 mediante la transmision de
las informaciones de posicionamiento (y otras) mediante tramas en modo desco-
nectado, tramas UI, las cuales tienen un formato especifico para ser identi-
ficadas como tramas de APRS. La transmision de informaciones mediante tramas
UI APRS siguen unos protocolos especificos para APRS.
Dado que las tramas APRS no dejan de ser tramas UI de radiopaquete
digital (como las empleadas para balizas y Unproto), no hay problemas en que
la actividad APRS se pueda soportar sobre las redes de BBS's y nodos de
radiopaquete digital, y ademas el APRS es compatible con los modems y TNC's
usados en el packet convencional.
Dado que el APRS se basa en la transmision de tramas UI, que no tienen
campos de bits para control de flujo (secuencias de envios de tramas), la
confirmacion de que la informacion transmitida ha llegado a su destino y sin
errores no recae en el protocolo AX.25, sino que es el propio protocolo APRS
el que tiene que hacerlo (protocolo que en el modelo OSI esta por encima del
AX.25).
Junto con la informacion de posicion, APRS permite tambien el envio de
mensajes entre estaciones, directamente o a traves de repetidores digitales.
Los mensajes son enviados linea a linea mediante tramas UI, y el propio
protocolo APRS es el encargado de enviar desde el equipo receptor una trama
UI con la confirmacion de recepcion de la trama recibida. Si la estacion que
envio la primera trama UI no recibe la confirmacion, vuelve a emitir el
mensaje hasta que se reciba. Si en un numero predeterminado de intentos no se
recibe la confirmacion, se descarta y se marca el mensaje como no-enviado.
Como se puede ver, no se ha establecido una conexion real entre las dos
estaciones (como ocurriria en packet convencional), pero ambas estaciones se
estan comunicando mediante el envio de tramas UI (en modo desconectado).
El APRS es practico para transmitir mensajes pasando por hasta 4 repeti-
dores, con lo que se pueden conseguir distancias de 400-500 km dependiendo de
la orografia de la region. mas lejos de estas distancias se hace poco practico
debido al retardo que se produce al ir pasando por muchos repetidores.
Este sistema de enviar mensajes funciona en tiempo real, es decir que
los mensajes llegan a su destinatario en unos 2 a 20 segundos, dependiendo del
numero de digipeaters por los que tenga que pasar el mensaje.
Ya que el APRS nace como un sistema tactico de informacion de posicion
y comunicaciones de emergencia, es un requisito basico que no sea necesario
conocer la ruta que ha de seguir un mensaje para llegar a la estacion de
destino. Para eso los repetidores de APRS aparte del indicativo propio que
tienen asignado, tienen unos "ALIAS" o sobrenombres esta ndares, usados para
identificar el tipo de repetidor, y que son RELAY, WIDE, TRACE, y repiten los
paquetes que escuchen dirigidos a estos alias.
Estos sobrenombres de los repetidores APRS son importantisimos ya que
gracias a ellos se puede hacer APRS en cualquier sitio sin tener que conocer
que indicativos tienen los Repetidores.
A parte de los mensajes entre estaciones tambien se pueden mandar anun-
cios o boletines generales para todas las estaciones.
Los mensajes se transmiten linea a linea, siendo estas de unos 55 carac-
teres, por lo tanto segun vamos escribiendo en el teclado se van transmitiendo
continuamente (cada linea se envia en una trama UI).
El protocolo APRS asigna un numero a cada linea para poder comprobar la
confirmacion del destinatario a cada una de ellas, y para poder mostrarlas en
la pantalla del ordenador del destinatario en orden.
En cuanto a los repetidores digitales usados en APRS, estos se encargan
de retransmitir los paquetes Unproto (UI) que emiten las estaciones APRS para
ampliar su cobertura y comunicarse con estaciones mas lejanas. Hay tres tipos
de repetidores que son identificados por sus "alias":
* Repetidores de amplia cobertura : WIDE
* Microrepetidores (pequea cobertura) : RELAY
* Repetidores que deben de identificarse: TRACE
Son diferentes a los repetidores de packet convencionales ya que no
valen para establecer una comunicacion en modo conectado con otra estacion.
Es decir, que no van a repetir un paquete SABM. Solo retransmiten paquetes UI.
Los paquetes UI-APRS tienen la siguiente estructura en su campo de
direccion (simplificada):
ESTACION_EMISORA>DIRECCION_UNPROTO, VIA, VIA, VIA
Por ejemplo:
EB1DPB>APRS, EC1I-1, EA1A-8, EC1H-9
La direccion Unproto para una estacion base es normalmente APRS, aunque
puede ser otra, es una especie de direccion de destino para la informacion
enviada por la estacion emisora.
En los campos VIA es donde va la lista de repetidores por donde se desea
que vayan las tramas UI. En los campos VIA se pueden poner los indicativos
reales de los repetidores que han de encaminar las tramas UI hacia su destino,
pero ello exige conocer la identidad de los repetidores a emplear. Pero una
de las ventajas del APRS es que ello no es estrictamente necesario, y en
lugar de los indicativos reales de los repetidores se pueden usar los alias
esta ndares que APRS permite para los repetidores:
EB1DPB>APRS,WIDE,WIDE,WIDE
Esto permite a un usuario que pueda ir de viaje a cualquier lado y pueda
practicar la actividad APRS sin que tenga necesidad de conocer los indicativos
de los repetidores de la zona y los que deba de emplear.
WIDE identifica a cualquier repetidor APRS de amplia cobertura. Repetir n
cualquier trama UI que reciban. Si la trama UI tiene la estructura:
EB1DPB>APRS,WIDE,WIDE,WIDE
para este caso se puede tambien expresar con la estructura:
EB1DPB>APRS,WIDE3-3
donde WIDE,WIDE,WIDE = WIDE3-3 . En este formato, se aprovecha el SSID como
contador de repetidores por los que ha pasado el paquete: Si un repetidor
recibe una trama UI con WIDE3-3 , lo retransmitir con WIDE3-2. Los siguientes
repetidores que retransmitan la trama la enviar n con WIDE3-1, WIDE3-0 y
aqui cesar el envio de la trama hacia otros repetidores.
TRACE identifica a repetidores de tipo WIDE con una caracteristica espe-
cial: Han de poner su indicativo real en el campo VIA correspondiente en las
tramas UI que retransmita. Por ejemplo, si el usuario EB1DPB envia la
siguiente trama UI:
EB1DPB>APRS,TRACE3-3
y alcanza sucesivamente los repetidores EC1I-1, EA1A-8 y EC1H-9, que han de
ser de tipo TRACE, la trama ser repetida de la siguiente forma:
Por EC1I-1 : EB1DPB>APRS,EC1I-1*,TRACE3-2
Por EA1A-8 : EB1DPB>APRS,EC1I-1, EA1A-8*,TRACE3-1
Por EC1H-9 : EB1DPB>APRS,EC1I-1, EA1A-8, EC1H-9*,TRACE3-0
RELAY identifica a cualquier repetidor de pequea cobertura, y est
pensado principalmente para las estaciones moviles. Para estas es muy aconse-
jable que emitan sus paquetes via RELAY para alcanzar otros de mayor cober-
tura. Las tramas UI enviadas por la estacion movil deber n entonces tener
una estructura del tipo:
EB1DPB>APRS, RELAY,WIDE2-2
La ventaja del alias RELAY es que cualquier estacion terminal de APRS
puede funcionar como repetidor RELAY para tramas UI que reciba con direccion
RELAY. Tambien pueden disponerse de microrrepetidores APRS tipo RELAY en
ubicaciones no cubiertas por el repetidor WIDE de la zona, y en ambos casos
lo que se consigue es garantizar por uno u otro medio que una estacion APRS
con mala cobertura del repetidor WIDE de la zona (situacion usual en comuni-
caciones moviles) pueda acceder a este a traves de microrrepetidores RELAY
o estaciones base mejor situadas.
Hay que tener en cuenta que los repetidores de amplia cobertura (WIDE y
TRACE) han de estar estrategicamente ubicados, y lo mas separados posible,
pero claro, que se escuchen entre ellos. Porque si estuvieran muy juntos,
primero, no se aprovecharia sus privilegiadas coberturas, segundo, muchos se
escucharian entre si, y tercero, se produciria mucho trafico redundante y el
tiempo de envio de mensajes aumentaria.
En cambio en la zona de cobertura de un WIDE se pueden poner pequeos
repetidores RELAY sin producir muchos paquetes redundantes, para mejorar la
cobertura de la red APRS en las zonas deficientemente cubiertas por el WIDE.
Una observacion: Los repetidores de amplia cobertura (WIDE, TRACE) han
de responder siempre a las tramas UI que han sido enviadas a RELAY, WIDE y
TRACE. Asi, si un repetidor WIDE escucha una trama UI enviada a RELAY, la
retransmitir , pero sustituyendo RELAY por su indicativo. Si por ejemplo el
repetidor de amplia cobertura EC1I-1 recibe la siguiente trama:
EB1DPB>APRS,RELAY,WIDE2-2
la retransmitir como:
EB1DPB-2>APRS,EC1I-1*,WIDE2-2
Finalmente decir que en Europa se esta usando la frecuencia de 144.800
Mhz para la actividad de APRS, operando con una velocidad de transmision de
1200 baudios. Programas para el APRS actualmente usados son el WinAPRS y el
UIView, entre otros.
#17.- ANEXOS
#17.a.- EJEMPLO DE SESION DE PACKET
Aqui puede ver una sesion de packet radio, tal como le seria presentada
en el monitor de su ordenador (trabajando como terminal). Entre parentesis
se aaden comentarios aclaratorios.
C ED3ZAD-2 (Peticion de conexion a ED3ZAD-2)
[FBB-7.00g-AB1FHMR$] (Contesta ED3ZAD-2)
{PROTUS-3.3}
ED3ZAD-> 41 34 5 26 31 [0938546256] (Peticion de Password a EB3EMD)
EDADZ (EB3EMD envia el Password)
(r) WinFBB v7.00g (ED3ZAD valida la conexion)
Hola..!!
Gracias por conectar FERNANDO.-
BBS ED3ZAD en U.R. Sabadell, Sab.-
Mensajes nuevos: 200152 al 201218
Port: 2/MODEM_TFN Canal: 15
Estaciones conectadas: 1
Ayudas: ?+
S.T. Local de U.R.E en Sabadell
BBS ED3ZAD
+ BBs en periodo de pruebas
+ Puertos activos 144925 y 439900
BBS CLUSTER y BBS
ED3ZAD-2 ED3ZAD-5 EA3ZAD-2
[1] (r)BBS ED3ZAD Ahora "NewsGroups" dando TH.
Cmd: !,%,#,=,A/B/C/CW/D/F/G/H/I/J/K/L/N/O/PS/R/S/T/TH/U/V/W/X/Y/YI/? ->
LC TEC* (EB3EMD selecciona temas TEC....)
* TEC* (confirmacion por ED3ZAD)
[1] (r)BBS ED3ZAD Ahora "NewsGroups" dando TH.
Cmd: !,%,#,=,A/B/C/CW/D/F/G/H/I/J/K/L/N/O/PS/R/S/T/TH/U/V/W/X/Y/YI/? ->
LR (EB3EMD pide listado de boletines)
Msj# TSLD Tam. Para @ BBS De Fecha/Hora Titulo - Filtro LC para: TEC*
200300 BF 3346 TECNO @LATNET LU7FQU 0921/1816 Hable con su marcapasos
200361 BF 1254 TECNIC@EA EB7BFV 0923/0954 Integrado X24C44P
200364 BF 1251 TECNIC@EA EB7BFV 0923/0954 Integrado LTC10P1
200373 BF 2756 TECNO @LATNET LU9DJS 0922/1634 MOTOROLA Y LOS COCHES INTELIGE
200376 BF 4035 TECNO @LATNET LU7FQU 0917/2101 Un motor milagroso
200379 BF 3812 TECNO @LATNET LU7FQU 0917/2104 Alarmas en el cielo
200704 BF 711 TECH @WW EB3FNQ 0927/0057 Looking for DOPPLER RDF system
200750 BF 862 TECH @WW EB3FNQ 0927/0110 Busco un sistema DOPPLER.
200751 BF 4025 TECNO @LATNET LU7FQU 0917/2102 Robot en equilibrio
200805 BF 1857 TECHNI@WW DL5SFC 0926/1305 electronic tube pl 519 data
200844 BF 3282 TECNO @LATNET LU7FQU 0924/2126 Hormigon contra terremotos
200849 BF 3948 TECNO @LATNET LU7FQU 0924/2129 Telescopio submarino
201157 BF 2300 TECHNI@EU SQ3DLT 0927/0625 Re: pic12c508-Emulator info
[1] (r)BBS ED3ZAD Ahora "NewsGroups" dando TH.
Cmd: !,%,#,=,A/B/C/CW/D/F/G/H/I/J/K/L/N/O/PS/R/S/T/TH/U/V/W/X/Y/YI/? ->
R 200704 (EB3EMD pide leer un boletin)
Msj N: 200704
Tipo : B
Estado: F
Para : TECH @WW
De : EB3FNQ
Bid : 64366_EA3RKT
Fecha : 0927/0057
Titulo: Looking for DOPPLER RDF system.
Path: !EA3B!ED3ZAF!EA5VDR!EA3ARR!EA3RKT!
From: EB3FNQ@EA3RKT.EAT.ESP.EU
To : TECH@WW
Hi, Iem looking for doppler radio direction finding schemes, I know that exist at least one model which can send information throw RS-232, if can be that model, much more better, reply me with a personal message, pse.
Thank you very much for read this message. 73es!
!! Fin Msg #200704 de EB3FNQ !!
[1] (r)BBS ED3ZAD Ahora "NewsGroups" dando TH.
Cmd: !,%,#,=,A/B/C/CW/D/F/G/H/I/J/K/L/N/O/PS/R/S/T/TH/U/V/W/X/Y/YI/? ->
B (EB3EMD envia peticion de desconexion)
Estuvo conectado : 3mn 51s -
73e. Saludos FERNANDO - Hasta pronto.
#17.b.- EJEMPLO DE MONITORIZACION DE UN CANAL DE PACKET RADIO
Aqui puede ver una sesion de packet radio similar a la anterior, pero
monitorizada a nivel de envios de tramas AX25, realizada con el programa
TSTHost para DOS. La presentacion en el canal de monitorizacion depender
del programa utilizado.
"fm" identifica las tramas ("frames") observadas. Observe como la linea
fm identifica el emisor de la trama, la estacion que la recibe, el tipo de
trama, las secuencias de envio y validacion (en tramas I, RR, REJ), longitud
(len) de la informacion transportada en bits (en tramas I) y algun dato mas.
En las tramas de informacion (I) y unproto (UI) se indica el PID (usualmente
F0), y la informacion que llevan se muestra en las lineas siguientes a la
linea fm de la trama correspondiente.
fm EB3EMD to ED3ZAD-2 ctl SABM+
fm ED3ZAD-2 to EB3EMD ctl UA-
fm ED3ZAD-2 to EB3EMD ctl I00^ pid F0 len=072 [FBB-7.00g-AB1FHMR$]
{PROTUS-3.3}
ED3ZAD-> 31 40 15 35 33 [0938748614]
fm EB3EMD to ED3ZAD-2 ctl RR1v
fm EB3EMD to ED3ZAD-2 ctl I10^ pid F0 len=033
952acdd90a4300d08a10d369ff239859
fm ED3ZAD-2 to EB3EMD ctl I11^ pid F0 len=250
(r) WinFBB v7.00g
Hola..!!
Gracias por conectar FERNANDO.-
BBS ED3ZAD en U.R. Sabadell, Sab.-
Mensajes nuevos: 201699 al 201881
Port: 1/XARXA Canal: 1
Estaciones conectadas: 1
Ayudas: ?+
S.T. Local de U.R.E en Sabadell
fm ED3ZAD-2 to EB3EMD ctl I12^ pid F0 len=250
BBS ED3ZAD
+ BBs en periodo de pruebas
+ Puertos activos 144925 y 439900
BBS CLUSTER y BBS
ED3ZAD-2 ED3ZAD-5 EA3ZAD-2
[1] (r)BBS ED fm ED3ZAD-2 to EB3EMD ctl I13^ pid F0 len=111 3ZAD Ahora "NewsGroups" dando TH.
Cmd: !,%,#,=,A/B/C/CW/D/F/G/H/I/J/K/L/N/O/PS/R/S/T/TH/U/V/W/X/Y/YI/? ->
fm EB3EMD to ED3ZAD-2 ctl RR4v
fm EB3EMD to ED3ZAD-2 ctl I41^ pid F0 len=010
lc * tec*
fm ED3ZAD-2 to EB3EMD ctl I24^ pid F0 len=134
=> * TEC*
[1] (r)BBS ED3ZAD Ahora "NewsGroups" dando TH.
Cmd: !,%,#,=,A/B/C/CW/D/F/G/H/I/J/K/L/N/O/PS/R/S/T/TH/U/V/W/X/Y/YI/? ->
fm EB3EMD to ED3ZAD-2 ctl RR5v
fm EB3EMD to ED3ZAD-2 ctl I52^ pid F0 len=008
lc tec*
fm ED3ZAD-2 to EB3EMD ctl I35^ pid F0 len=132
* TEC*
[1] (r)BBS ED3ZAD Ahora "NewsGroups" dando TH.
Cmd: !,%,#,=,A/B/C/CW/D/F/G/H/I/J/K/L/N/O/PS/R/S/T/TH/U/V/W/X/Y/YI/? ->
fm EB3EMD to ED3ZAD-2 ctl RR6v
fm EB3EMD to ED3ZAD-2 ctl I63^ pid F0 len=003
lr
fm EB3EMD to ED3ZAD-2 ctl I63+ pid F0 len=003
lr
fm ED3ZAD-2 to EB3EMD ctl RR4-
fm ED3ZAD-2 to EB3EMD ctl I46^ pid F0 len=250
Msj# TSLD Tam. Para @ BBS De Fecha/Hora Titulo - Filtro LC para: TEC*
201710 BF
fm ED3ZAD-2 to EB3EMD ctl I47^ pid F0 len=250
2186 TECHNI@EU ON4CBL 0929/2329 Scheme drive Stepmotors ?
201722 BF 2200 TECHNI@WW SQ3DLT 0930/0909 schema connect IR CONNECTOR
201819 BF 2426 TECHNI@WW DG7MDB 0930/0710 ukw-pa
[1] (r)BBS ED3ZAD Ahora "NewsGroups" dando TH.
Cm
fm ED3ZAD-2 to EB3EMD ctl I40^ pid F0 len=071
d: !,%,#,=,A/B/C/CW/D/F/G/H/I/J/K/L/N/O/PS/R/S/T/TH/U/V/W/X/Y/YI/? ->
fm EB3EMD to ED3ZAD-2 ctl RR1v
fm EB3EMD to ED3ZAD-2 ctl I14^ pid F0 len=009
r 201710
fm ED3ZAD-2 to EB3EMD ctl I51^ pid F0 len=250
Msj N: 201710
Tipo : B
Estado: F
Para : TECHNI @EU
De : ON4CBL
Bid : 60080_ON6AR
Fecha : 0929/2329
Titulo: Scheme drive Stepmotors ?
Path: !EA3B!ED3ZAF!EA5VDR!EA5RCI!EA5RKE!EA5URD!EA7GRA!EA7URC!SV1AAW!SV1AAW!
!HA3PG!HA5OB!OK0PAB! fm ED3ZAD-2 to EB3EMD ctl I52^ pid F0 len=250 OK0PBB!OK0PHL!OK0PPR!OK0PKL!DB0MAK!DB0SON!DB0SIF!
!DB0GV!DB0LJ!DB0ACH!DB0MKA!DB0IZ!ON6AR!
From: ON4CBL@ON6AR.#AN.BEL.EU
To : TECHNI@EU
Hi All,,
I am intrested in schemaes for 6 wire - and more _ STEP-MOTOReS schematics .
It is difficuld
fm ED3ZAD-2 to EB3EMD ctl I53^ pid F0 len=250
, mayby have you a plan for testing these devices, i have
one for the 6wire type with 3 normal TTL ices, with 4 Po Transistors.
It is no check here, later well..
I hope op succses, your scheme in ARJ-ZIP-LHA-C..-GIF-JPG >> 7+ pse
Thanks ,, i need fm ED3ZAD-2 to EB3EMD ctl I54^ pid F0 len=250 this for testing small stepmotors, and some bigger .
73es de Eric-ON4CBL
!! Fin Msg #201710 de ON4CBL !!
[1] (r)BBS ED3ZAD Ahora "NewsGroups" dando TH.
Cmd: !,%,#,=,A/B/C/CW/D/F/G/H/I/J/K/L/N/O/PS/R/
fm ED3ZAD-2 to EB3EMD ctl I55^ pid F0 len=026
S/T/TH/U/V/W/X/Y/YI/? ->
fm EB3EMD to ED3ZAD-2 ctl RR6v
fm EB3EMD to ED3ZAD-2 ctl I65^ pid F0 len=002
b
fm ED3ZAD-2 to EB3EMD ctl DISC+
fm EB3EMD to ED3ZAD-2 ctl UA-
#17.c.- EJEMPLO DE ARCHIVO ENVIADO EN 7PLUS
Asi apareceria en pantalla un boletin en el que se ha enviado un archivo
en formato ASCII con codificacion 7Plus.
Si se analiza un poco el contenido del boletin, descubrir que el
archivo original es el archivo WAIT8!.EXE (por tanto es un archivo binario),
y que ha sido fragmentado en dos partes por la utilidad 7Plus (o equivalente)
para su envio. Esta es la segunda parte.
Si en este documento estuviera tambien la primera parte del envio, la
propia utilidad 7Plus es capaz de extraerlas de este documento en archivos
aparte, y despues, con estos, regenerar el archivo original WAIT8!.EXE .
Msj N: 200129
Tipo : B
Estado: $
Para : MIDI @WW
De : DL2MGA
Bid : N99DB0AAB02H
Fecha : 0923/1537
Titulo: Wait8!.MID 2/2
Path: !EA3B!EA3ARR!EA5VDR!EA5RCI!EA5RKE!EA5URD!EA7GRA!EA7URC!WU3V!WB0TAX!
!ON6AR!DB0IZ!DB0AIS!DB0SRS!DB0ABH!DB0BOX!DB0MAK!DB0PV!DB0AAB!
From: DL2MGA @ DB0AAB.#BAY.DEU.EU (Frank)
To: MIDI @ WW
Reply-To: DL2MGA @ OE9XPI.AUT.EU
X-Info: No login password
go_7+. 002 of 002 WAIT8!.EXE 0009153 0280 08A (7PLUS v2.1) †fw
#jUT8xK3/4--BE;‡ˆY1e9meše;ŠƐž1"A%l1iX;u"\u193€HPlK]:!+
xs7=/WUB@:}qP•b1/2e_-}c:y["•V1/4(r)Yس4a]wu|n!3
a9[1/4›žFe"fXaT^fXc-ˆ‡;#Wxƒš{‰,Nfgˆ4€uW?˜>1!•e
Š5<WZ[XҰ)&?ufŒWX"npg.\u249DAA+eiUCwOŠ 8AbiŠCX(G_-q#4"r
‡Oܬ‹MSeie%x-;{w"œA‰4Vyh8:"Cq(tm)<>=PQ"
e+vw]#I"(r)"P1/4oo†(tm)5A•‰ˁK3/4sve/"8œ?q>...a2"@-""_
me-$ϰ<›ƒƒAf":ːƒC|TWq0vܹ|BD"C#
(5f;Q#ѴIY9-‡eŨm˜r̲(tm)29v(c)33o"<o#Q2sF(c)4K‹#XV
"ey"jgO,3/4VR"{JC,PApecyœW|l/")1/4†œ‹7•w/Q...-%$q
L˜ˆeNe9Š_ds;ِDŽI"z-i,;1J=‡ݰƒ5!!!!!!!!!!!!!!!!!!!!!!!!WH$
stop_7+. (WAIT8!.P02/02) [271F7EAA] o-F
!! Fin Msg #200129 de DL2MGA !!
#17.d.- EJEMPLO DE MONITORIZACION DE TRAMAS APRS
Tramas monitorizadas con el programa TSTHost (para DOS) en un canal con
actividad APRS. Observese que todo el trafico es mediante tramas UI. El
formato de los datos de informacion que transportan las tramas depende del
tipo de informacion. Asi, p.ej, las que tienen la indicacion QTH dan una
ubicacion geografica (latitud/longitud e informaciones adicionales).
0:fm EA3ANS-7 to APZ18A via WIDE3-2 ctl UI^ pid F0 len=029 >Barcelona Ciudad(Barcelones)
0:fm EA3ANS-7 to APZ18A via EA3RCC-15* WIDE3-1 ctl UI^ pid F0 len=029 >Barcelona Ciudad(Barcelones)
0:fm EA3ANS-7 to APZ18A via EA3ANS-15* ctl UI^ pid F0 len=029 >Barcelona Ciudad(Barcelones)
0:fm EA3CTK to APU24P via EA3ANS-15* ctl UI^ pid F0 len=063 =4207.23N/00307.71E-QTH - LeESCALA - JN12NC - OP LLUIS {UIV32} 0:fm EA3BBP to TQPXP0 via EA3ANS-15* WIDE ctl UIv pid F0 len=011 ew+_l _K]
0:fm EA3CTK to APU24P via EA3F-15 WIDE4* ctl UI^ pid F0 len=063
=4207.23N/00307.71E-QTH - LeESCALA - JN12NC - OP LLUIS {UIV32}
0:fm EB3ESK-15 to APZ18A via EA3RCC-15* WIDE3-2 ctl UI^ pid F0 len=037
>Sierra del Catllar(Ripolles)1118msnm
0:fm EB3ESK-15 to APZ18A via EA3ANS-15* ctl UI^ pid F0 len=037
>Sierra del Catllar(Ripolles)1118msnm
0:fm EB3GKX-15 to APRS via EA3RCC-15* TRACE7-6 ctl UI pid F0 len=058
!4136.75N/00148.99E#PHG4990/Can Martorell(Montserrat) LT3
0:fm EB3GKX-15 to APRS via EA3ANS-15* ctl UI pid F0 len=058
!4136.75N/00148.99E#PHG4990/Can Martorell(Montserrat) LT3
0:fm EA3BSJ-1 to APEWX via EA3BSJ-7* WIDE4-2 ctl UI pid F0 len=058
>122333z Prev.Lluvia WM918 Pic-E WxStation-Pinos 930 m asl
0:fm EB3GKX-15 to APRS via EA3RCC-15* WIDE4-3 ctl UI pid F0 len=058
!4136.75N/00148.99E#PHG4990/Can Martorell(Montserrat) LT2
0:fm EA3ABN-2 to APRS via EA3ANS-15* ctl UI^ pid F0 len=079
}EA3ABN-2>APU250,TCPIP*,EA3RKU*:=/9O-1O#cCB BINTERNET STATION TESTING {UIV32}
0:fm EA3CQQ to APRS via EA3ANS-15* ctl UI^ pid F0 len=080
}EA3CQQ>APU250,TCPIP*,EA3RKU*:=4136.59N/00205.29E-ea3cqq@telefonica.net {UIV32}
0:fm EA3BSJ-1 to APEWX via EA3ANS-15* ctl UI pid F0 len=058
>122333z Prev.Lluvia WM918 Pic-E WxStation-Pinos 930 m asl
0:fm EB3GKX-15 to APRS via EA3ANS-15* ctl UI pid F0 len=058
!4136.75N/00148.99E#PHG4990/Can Martorell(Montserrat) LT2
0:fm EA3ANS-15 to APZ18A via WIDE3-3 ctl UI^ pid F0 len=043
!4121.77N/00209.48E# UIDIGI1.8b10 144800MHz
0:fm EA3ANS-15 to APZ18A via EA3RCC-15* WIDE3-2 ctl UI^ pid F0 len=043
!4121.77N/00209.48E# UIDIGI1.8b10 144800MHz
#17.e.- ENRUTADOS JERARQUICOS
Las direcciones completas de una estacion de packet tiene una expresion
del siguiente tipo:
INDICATIVO@BBSLOCAL.[ZONA].PROVINCIA.PAIS.CONTINENTE
[ZONA].CIUDAD.PAIS.CONTINENTE es la denominada "Ruta Jer rquica" (HROUTE)
de la estacion considerada. En Espaa y en otros paises actualmente no se
usa la ZONA. PROVINCIA se refiere a una provincia, region o departamento
administrativo del pais.
Esta direccion facilita a los BBS's el encaminamiento de los mensajes,
personales, sobre todo cuando se trata de mensajes dirigidos a usuarios de
packet en otros paises.
Ejemplo: F6FBB@F6FBB.FMLR.FRA.EU
Para el caso de los mensajes dentro de Espaa, o con destino a las redes de packet espaolas, tienen la expresion:
indicativousuario@indicativoBBS.EAprovincia.ESP.EU
(ESP indica Espaa, y EU indica Europa)
Para el codigo de la provincia se usan las letras de matricula provincial
de automoviles del antiguo sistema de matriculas espaolas (que quedo fuera
de servicio el ao 2000):
AB - Albacete C - A Corua MA - M laga SO - Soria
A - Alicante CU - Cuenca ML - Melilla T - Tarragona
AL - Almeria GC - Gran Canaria MU - Murcia TF - Tenerife
AV - Avila GE - Gerona NA - Navarra TE - Teruel
B - Barcelona GR - Granada OR - Orense TO - Toledo
BA - Badajoz GU - Guadalajara O - Asturias V - Valencia
BI - Vizcaya H - Huelva P - Palencia VI - Alava
BU - Burgos HU - Huesca PM - Baleares VA - Valladolid
CC - C ceres J - Jaen PO - Pontevedra ZA - Zamora
CA - C diz LE - Leon SA - Salamanca Z - Zaragoza
CE - Ceuta L - Lerida SS - Guipuzcoa
CS - Castellon LO - Logroo S - Santander
CR - Ciudad Real LU - Lugo SG - Segovia
CO - Cordoba M - Madrid SE - Sevilla
Ejemplos de rutados jer rquicos:
EA1AS@EA1URR.EALO.ESP.EU
EA3BRA@EA3RCN.EAB.ESP.EU
EA4DAU@EB4CTD.EAM.ESP.EU
EA5FHC@EA5ERC.EAV.ESP.EU
EA6IC@EA6RCL.EAPM.ESP.EU
A nivel mundial se tiene que:
* Identificaciones de continentes:
NA - Norteamerica
SA - Sudamerica
EU - Europa
AS - Asia
AF - Africa
AU - Australia
* Identificaciones de paises (incompleta):
Argentina ARG Japon JPN
Australia AUS Korea,Norte PRK
Austria UT Korea,Sur KOR
Belgica BEL Libano LBN
Bermuda BMU Liechtenstein LIE
Bolivia BOL Luxemburgo LUX
Brasil BRA Malasia MYS
Brunei BRN Mexico MEX
Bulgaria BGR Monaco MCO
Canad CAN Marruecos MAR
Chile CHL Holanda NLD
China CHN Nueva Zelanda NZL
Colombia COL Nicaragua NIC
Costa Rica CRI Noruega NOR
Cuba CUB Pakist n PAK
Dinamrca DNK Panam PAN
Republica Dominicana DOM Paraguay PRY
Ecuador ECU Peru PER
Egipto EGY Filipinas PHL
El Salvador SLV Polonia POL
Espaa ESP Grecia GRC
Finlandia FIN Portugal PRT
Francia FRA Rumania ROM
Polinesia Francesa PYF Arabia Saudi SAU
Rep.Fede. Alemana DEU Singapur SGP
Groenlandia GRL Sur Africa ZAF
Guatemala GTmasuecia SWE
Haiti HTI Suiza CHE
Honduras HND Siria SYR
Hong Kong HKG Taiw n TWN
Hungria HUN Tailandia THA
Islandia ISL Turquia TUR
India IND Reino Unido GBR
Indonesia IDN Estados Unidos USA
Irlanda IRL Uruguay URY
Israel ISR Venezuela VEN
Italia ITA Yugoslavia YUG
Por Fernando Fernandez de Villegas (EB3EMD; Barcelona). Noviembre 2002
Basado en el articulo: Teoria de Packet radio, de Pierre Cornelis, ON7PC
Setiembre 1989, y traducido por Iaki, EA2BQV.
Aadidos procedentes de distintos boletines de packet:
EA5EC Antonio Esteve,
EB1DNA Ricardo Alvarez Brion (sobre el APRS) otros...
Ampliaciones, actualizaciones y aadidos de Fernando, EB3EMD.
