Interfaz de ordenador para el RIG RX2
Como muchos recién llegados al hobby de la recepción de satélites meteorológicos, mis primeros pasos fueron utilizar un receptor-escáner portátil como receptor. Caí en la cuenta que quería algo más serio y como base normal decidí montar el 'kit' del receptor RX2 de Remote Imaging Group. Este receptor funciona bien. Estoy impresionado con su sensibilidad y la calidad de las imágenes que he recibido, utilizando ese receptor, una modesta antena de dipolos cruzados y el software WXSat de Christian Bock que descodifica la señal de audio de los satélites que esta grabada en ficheros WAV en mi disco duro.
Un aspecto en el cual RX2 no es ideal cuando se quieren recibir imágenes de satélite sin atención personal es que no puede controlar que pases recibe. En primer lugar hay muchos pases que se sitúan dentro de nuestro campo de acción pero que están distantes, y por lo tanto ruidosos, careciendo de interés en muchas oportunidades. Estaría bien no molestarse en grabarlos. Segundo y más molesto, cuando concurren dos pases al mismo tiempo, el receptor se cierra en el primero que oye, por lo que perdemos la mayor parte del segundo, que de acuerdo con la ley de Sod será el que realmente quería. Esto fue una verdadera molestia mientras Meteor 3-5 estuvo activo, pues debido a la 'temblorosa' calidad de sus imágenes, yo hubiera preferido ignorar por completo sus pases.
Como programador, no tuve ningún problema en escribir mi propio software para planificar la grabación de los pases de satélite. De hecho ya tenia escrita una utilidad para realizar la grabación de ficheros WAV debido a la incapacidad del WXSat para efectuar grabaciones fiables mientras se hacían otros trabajos en el ordenador. Lo que necesitaba era algún procedimiento para que el ordenador controlara el RX2. Este artículo describe una interfaz que hace que esto sea posible.
No soy lo que se puede llamar un experto en electrónica pero por alguna razón durante 1998 compré un ejemplar de la revista Elektor - la edición de Septiembre - que contenía un artículo relativo al uso del puerto de juegos (interfaz joystick) del ordenador. De su lectura aprendí que el puerto de juegos tiene cuatro entradas analógicas TTL (A1-A4, ver esquema) y cuatro entradas digitales (D5-D7) para permitir leer las posiciones de los interruptores y mandos de dos joysticks. Estas entradas se pueden utilizar como sensores para detectar el estado de otras cosas pero, lo más importante de todo para nuestro propósito, con la ayuda de un simple circuito las entradas analógicas se pueden utilizar como salidas digitales.
Cuatro entradas digitales son suficientes para proporcionar información acerca del canal en el que RX2 está sintonizado y si hay presente una señal. La salida podría utilizarse para "pulsar el botón" y cambiar de canal. Creí en la posibilidad de controlar el RX2 utilizando el puerto de juegos del PC. Era una solución elegante para los muchos usuarios del RX2 que, como yo mismo, ya utilizan la tarjeta de sonido para recibir el audio. En efecto, una tarjeta de sonido barata se convierte en una interfaz dedicada al receptor de satélites.
Un intercambio de e-mails con el diseñador del RX2, Ray Godden, confirmó la existencia de las salidas adecuadas para detectar el número de canal y la presencia de una señal. Ray también sugirió la forma en que el transistor de conmutación excitado por el puerto analógico podía ser conectado al botón pulsador del receptor para hacer el cambio de canal. El cambio a un canal específico podía conseguirse simplemente "pulsando el botón" hasta obtener el canal deseado. El sistema funcionaria con independencia de si inicialmente, en el momento de su encendido, el receptor estaba en un canal fijo o en la modalidad scan.
Los 7 segmentos del LED de lectura son activados directamente por las patillas del controlador PIC del RX2, es decir, no hay ningún número de canal binario que pueda ser leído directamente por la interfaz del ordenador. Sin embargo, pronto me di cuenta que tomando los segmentos c, d y f producirían un código binario de tres bits que es único para cada uno de los cinco canales posibles. [Nota: en el artículo publicado en el número 57 de la revista RIG los segmentos fueron incorrectamente mencionados como b, c y e.]. Para el software de ordenador sería sencillo convertir este código en el verdadero número de canal.
Antes de describir el circuito de la interfaz necesito hacer una puntualización importante. La descripción de este circuito se presenta como guía para todos aquellos que tienen conocimientos para copiar o mejorar mi interfaz y no como un conjunto de instrucciones paso a paso que alguien, con poca o sin experiencia electrónica, pueda seguir. No quiero que nadie que pueda reventar su ordenador me responsabilice. Como se indica en el artículo original de Elektor, el puerto de juegos del ordenador no tiene ningún tipo de protección por lo que una conexión negligente puede dañar la placa de sonido. En particular, debe tenerse mucha precaución con la salida de los +5 voltios que aparecen en cuatro de las patillas del conector del puerto de juegos. Si inadvertidamente se cortocircuita alguna de ellas, tal y como argumenta el artículo, algunos componentes del ordenador podrían quemarse y posiblemente podría dañarse la fuente de alimentación. Al publicar estas instrucciones, no acepto responsabilidad alguna por los daños que, como resultado del seguimiento de las mismas, puedan causarse a su ordenador o a cualquiera otra cosa:
Las entradas del puerto digital de juegos están diseñadas para determinar cuando un interruptor está abierto o cerrado. Un voltaje de +5V. está presente en circuito abierto y cuando se cierra el circuito fluye una corriente de unos 5mA.. Ray me confirmó que el PIC del RX2 es capaz de disipar esta corriente, es decir las entradas digitales podían ser conectadas directamente a las patillas del IC6. Sin embargo, me preocupaba lo que podría suceder si el receptor se ponía en tensión mientras el ordenador estaba apagado. En ese caso la energía circularía en sentido contrario, es decir hacia atrás a través de las resistencias 'pull-up' de la placa de sonido, lo que no sería bueno para el receptor y probablemente encendería los segmentos del LED. Decidí utilizar un transistor de conmutación en cada una de esas salidas. Ray también me confirmó que la conmutación por transistores sería necesaria para prevenir que una posible conexión externa a la salida SCAN del PIC (que indicaría si una señal estaba presente) interfiriera la correcta operación del receptor.
[Observe que en la copia de este diagrama publicada en el número 57 de la revista RIG, tres de las conexiones al IC6 están numeradas incorrectamente].
El uso de las entradas analógicas para excitar un transistor de conmutación y crear una salida digital es muy complejo y, si se precisa más información, debe consultarse el artículo original de Elektor. La entrada utilizada debe conectarse a +5V. a través de una resistencia de 27K ohm. Cuando el software escribe un valor en la dirección I/O del puerto de juegos, se abre un interruptor interno permitiendo que ese voltaje cargue un condensador. Cuando se conecta un joystick, en uso normal del puerto, la medida analógica se hace determinando el tiempo de caída de voltaje en ese condensador a través del potenciómetro conectado externamente.
Lo que daba a conocer el artículo de Elektor es que con la escritura repetida de un valor en la dirección I/O del puerto de juegos es posible obtener un voltaje presente en el puerto analógico de hasta 2V., suficiente para excitar un transistor. El condensador externo de 220nF situado entre la entrada y masa está recomendado por el artículo para los ordenadores más lentos que no son capaces de escribir repetidamente al puerto con la adecuada rapidez. Aunque no esperaba que esto fuera problema con mi sistema Pentium a 400Mhz, decidí incluir el condensador por si se daba el caso que la multitarea de Windows introdujera retardos entre escrituras, impidiendo así que el voltaje alcanzara el nivel requerido. Puede ser que usted no lo necesite.
Debido a los riesgos que entraña la utilización de los +5V proporcionados por el puerto de juegos, en mi instalación inicialmente tomé los +5V del mismo RX2. Esto fue un error. El resultado es que si la interfaz se desconecta o se apaga el ordenador y el receptor está en tensión, el transistor está conduciendo en permanencia y el receptor se comporta como si el botón pulsador estuviera permanentemente pulsado. Debido a la dificultad en obtener componentes en mi apartada zona del Reino Unido, de momento me encuentro atascado con un cable de seis hilos y un conector y no tengo posibilidad de cambiarlo fácilmente, pero imagino que el problema se solventará tomando los +5V. suministrados por el puerto de juegos, como se muestra en el esquema. De esta manera cuando se apague el ordenador o se desconecte el cable de la interfaz, se eliminaran al mismo tiempo los +5V de la entrada al transistor. Para evitar el riesgo de cortocircuitos accidentales que provocarían daños en el ordenador debe considerarse la instalación de una resistencia de 27Kohm en el interior del conector D de 15 patillas situado en el extremo del cable correspondiente al ordenador.
El puerto de juegos contiene unos condensadores para filtrar el ruido en estas entradas. Yo no he dispuesto ningún filtrado extra en la interfaz, no obstante, si su ordenador produce ruidos eléctricos, cuando conecte la interfaz podrá observar un incremento de ruido, por lo que si lo estima necesario puede prever el añadir un filtro.
El software necesario para controlar el receptor utilizando esta interfaz es sumamente fácil de escribir. El puerto de juegos tiene una sola dirección I/O, que normalmente es 201h. Si usted lee esta dirección, los valores de las cuatro entradas digitales están en los cuatro bits superiores del byte, Por lo tanto, lo que debería hacer es leer un byte del puerto y hacer una división integra por 16 del resultado de la lectura (o desplazarlo 4 posiciones hacia la derecha). Si hay una señal presente el número resultante será mayor que o igual a 8. El número del canal estará en los tres bits inferiores pero, como se indica anteriormente, el valor debe ser convertido para obtener el correcto número de canal. Para los canales 1 a 5 los valores que obtendrá serán 1, 2, 3, 5 o 7. Nunca debería ver los valores 0, 4 ó 6.
Observe que si el receptor o bien la interfaz están desconectados, el byte obtenido cuando leamos el puerto estará con todos los bits a uno. Esto es lo mismo que si se recibe una señal en el canal 5. El único método para que el software nos indique si el receptor está conectado y trabajando, es probar el cambio de canal y ver si el número de este cambia.
Para pulsar el botón del panel frontal y cambiar de canal, el software debe escribir repetidamente un byte de valor 1 en el puerto de juegos. Yo hago esto durante un periodo de 200ms, que puede o no ser innecesariamente largo. El código de ejemplo contenido en la revista Elektor utiliza un bucle fijo de 10.000 iteraciones, Obviamente, en este caso la duración dependerá de la velocidad del ordenador.
Para poner el RX2 en modalidad scan se necesita pulsar el botón y mantenerlo pulsado durante un segundo aproximadamente. Para conseguir esto en software, hago un bucle de iteración de 1200ms. La función de Windows GetTickCount proporciona una vía fácil para medir el tiempo transcurrido con la precisión de un milisegundo. Si alguien escribe un software en DOS para controlar esta interfaz necesitará algún otro medio para medir el tiempo transcurrido..
// utilidades básicas para la interfaz de control para el RX2
unit RX2_Util;
interface
uses Windows;
// set address of game port (default '$201')
procedure SetPortAddr(const addr: string);
// get current channel number and signal presence
procedure GetStatus(var chan: Integer; var signal: Boolean);
// push button for t milliseconds
procedure PushButton(t: Integer);
implementation
uses SysUtils;
var
port_addr: Word;
function ReadPort: Byte;
begin
asm
mov dx,port_addr;
in al,dx
shr al,4
mov result,al
end;
end;
procedure SetPortAddr(const addr: string);
begin
port_addr := StrToInt(addr);
end;
procedure GetStatus(var chan: Integer; var signal: Boolean);
var
data: Byte;
const
chan_no: array[0..7] of Integer = (0,1,2,3,0,4,0,5);
begin
data := ReadPort;
signal := data > 8;
chan := chan_no[data mod 8];
end;
procedure PushButton(t: Integer);
var
start: Integer;
begin
start := GetTickCount;
repeat
asm
mov dx,port_addr
mov al,1
out dx,al
end;
until (GetTickCount - start) >= t;
end;
initialization
SetPortAddress('$201');
finalization
end.
El listado 1 muestra las rutinas básicas de software que utilicé para probar la interfaz. Están escritas en Borland Pascal, el lenguaje del sistema de desarrollo Delphi de Borland. Si está escribiendo un programa en Delphi para controlar su receptor, puede simplemente llamar a las tres funciones exportadas por esta unidad cuando las requiera su interfaz de usuario. Observe que, para hacer las lecturas de y escrituras al puerto I/O, he tenido que utilizar la función ensamblador incluida dentro de Delphi, puesto que Borland Pascal no dispone de ninguna función para lograrlo.
Debería ser posible el control de la interfaz utilizando cualquier lenguaje de ordenador que pueda leer y escribir en los puertos I/O. Los listados del programa en el artículo original de Elektor estaban claramente diseñados para DOS y escritos en Turbo Pascal o GW-Basic. He probado este software en Windows 98 (No utilizo ni tengo lo necesario para crear programas de 16 bits para el Windows 3.1 o para DOS). Si utiliza Windows NT puede ser que estas rutinas no funcionen pues no creo que Windows NT permita el acceso directo a los puertos I/O.
Un problema con el que se puede encontrar (¡Yo lo encontré!) es que la dirección de su puerto de juegos no sea la estándar 201h. Mi ordenador Dell tiene una tarjeta de sonido integrada que es plug-and-play y después de perder mucho tiempo, preguntarme si el artículo del Elektor era erróneo y la interfaz no trabajaría con cualquier placa de sonido, me encontré con que mi puerto de juegos estaba asignado a la dirección 208h. No sé de ningún modo para determinar la dirección utilizada que no sea mirar en el Administrador de Dispositivos de Windows y utilizar la conjetura. Mi ordenador mostraba dos puertos de juegos, uno utilizaba la dirección 201h (que claramente no existía y que suprimí) y el otro utiliza el rango 208h a 20Fh. Probé 208h y ¡las cosas comenzaron a funcionar! En consecuencia cualquier software que se escriba debe incluir la posibilidad de que la dirección del puerto sea especificada por el usuario.
He escrito una aplicación de control que utiliza esta interfaz del ordenador y que está disponible para su descarga en este sitio.
Esta interfaz es muy fácil de construir, pero no está disponible como 'kit' de componentes ni existe una Placa de Circuito Impreso ya preparada, por lo que es de presumir que quienquiera que la construya estará razonablemente preparado técnicamente.
Que yo sepa, tan solo un constructor tuvo problemas en la construcción de la interfaz y ello fue debido al uso de un transistor deficiente procedente de la 'caja de los truenos' Para ayudar en la búsqueda de fallos ofrezco esta utilidad de prueba que muestra en binario los datos leídos del puerto de juegos.
Traducción al español de Ferran Alegret, EA3DLV, supervisada por Paulí Núñez, EA3BLQ, en Febrero de 2000