En esta nueva entrada y tal como indica el título, la idea es compartir la experiencia de la implementación del tracker APRS desarrollado por el colega EA4AQM Víctor.
Me puese en contacto con Victor para ver como podía implementar su tracker APRS que por cierto, fué publicado en la revista de URE de enero de 2011. Este proyecto, , está basado en plataforma PIC al contrario que el que acabo de publicar que está basado en arduino.
Victor amablemente me facilitó los ficheros .hex para grabarlos en los PIC´s, el esquema y las instrucciones necesarias para ponerme en marcha. Hice acopio de los componentes en la tienda de electrónica de rigor, en mi caso Viloga, que me pilla más cerca. Hago un paréntesis aquí para comentar lo triste que parecen hoy en día las tiendas de compontentes electrónicos, cada vez que entro en la tienda se me cae el alma al suelo, !quien las ha visto en los 90 y quien las ve ahora!. Esto es consecuencia del avance tecnológico.
Bueno "al turrón".... Los pics que utiliza el tracker son dos 16F84A y mi primera sorpresa es que no disponen de ellos pues son algo antiguos, total que me los piden para el día siguiente.
Dispongo de unas placas de prototipo que son muy indicadas para este tipo de montajes y sobre ellas empiezo a colocar todos los componentes y a cablearlos. Cuando está todo terminado, es la hora de grabar los PIC´s. Después de varios problemillas con el grabador finalmente consigo solucionarlo y realizo la grabación de los pic´s. El grabador es uno adquirido por ebay a los chinos muy económico (el JDM programmer) pero funciona muy bien. Lo único es que es por puerto serie y hay que tener algún PC con puerto serie pues no se lleva muy bien con los adaptadores USB-RS232. Como software de grabación de los PIC´s se puede usar el Winpic800 o bien el IC-RPOG, yo he usado éste último y es necesario posicionar el OSC: HT y No usar WDT.
Una vez todo montado en la placa, procedo a dar alimentación al circuito y veo que el circuito está vivo porque los leds se encienden, el rojo de TX por 1 segundo y el verde se mantiene encendido, ésto ya es buen síntoma. El funcionamiento del led verde debe ser el siguiente:
- Encendido mientras el gps no esta fijando la posición.
- Intermitente con una cadencia de 1sg cuando el gps ha fijado posición.
El led verde en su estado de intermitencia, nos sirve como herramienta indicadora de que el PIC 1 esta recibiendo datos, son válidos y también de que el gps está fijando posición.
Yo no conseguí que el led verde se pusiera intermitente, por lo que algo estaba pasando. Verifico niveles de tensión que está entregando el gps en su stream de datos y veo que entrega unos niveles TTL válidos. También verifico el pin RB0 del PIC1 para ver si recibe datos vía el MAX232 y detecto que no hay datos. Después de darle vueltas al tema concluyo que el gps al entregar niveles TTL no debe ir conectado al MAX232 (que trabaja con niveles RS232) sino que debe ir conectado directamente al PIC1 (entre RB0 y masa). Lo conecto directamente como acabo de comentar pero veo que el led sigue sin estar intermitente, posteriormente reparo en que el gps nunca logró fijar la posición porque estaba dentro de casa.
Tan pronto coloco el gps en la ventana para que logre posicionarse, veo que el led verde se pone intermitente..... bueno, pues ya hemos dado un paso importante, de momento sabemos que el sistema "parece" funcionar y que se estan recibiendo los datos del gps correctamente.
Procedo con la configuración del tracker para introducirle el indicativo etc. Ésto se realiza por el puerto serie usando el Hiperterminal de windows y pasando a modo programación al tracker manteniendo pulsado el pulsador y aplicándole alimentación (los dos led deben permanecer apagados). Para enviar la configuración al tracker se debe seguir escrupulosamente las instrucciones que Victor me facilita ya que son un poco "especiales".
Una vez grabada la configuración en el PIC, detecto que el led de TX no luce en ningún momento y Victor me aclara que en función del indicativo (SSID) utilizado se activa una lógica diferente para hacer la TX. Existen cuatro modos predefinidos, el "9" (coche), el ":" moto, el "4" bici y el "7" Jogger. En modo coche y moto el funcionamiento es aplicando lógica de cambio de rumbo y velocidad, el resto es por tiempo y se aplica una velocidad mínima.
Entonces entendí porqué nunca hacía TX independientemente del SSID utilizado y es que el gps estaba estático y nunca se cumple la lógica que activa la TX.
En ese momento caí en que la segunda funcionalidad del pulsador es forzar el envío de una baliza, lo pruebo y veo que pasa a TX... eureka!. Parece que esta todo funcionando correctamente. Fuerzo el envío de unas cuantas balizas y monitorizo en aprs.fi la que la trama ha entrado en la red, pero lamentablemente por algúnmotivo con el que ahora mismo estoy liado, la trama no es reconocida por la red.
A ésto ya le queda muy pero que muy poquito para que esté 100% operativo.
Seguimos....
Después de una larga charla en la frecuencia habitual con Victor EA4AQM y Jesús EA4EP, por cierto muy instructiva, llegamos a la conclusión de que el PIC no estaba configurado puesto que estando en modo programación desde el hiperterminal con tan solo pulsar una tecla, el tracker debe responder siempre son su configuración.
Estaba teniendo problemas en la comunicación serie con el tracker, por lo que decidimos pasar al método alternativo de configuración grabando directamente los datos de configuración en el código del programa (en la parte de memoria eeprom del pic). Utiliza los 16 primeros bytes de memoria. Para ello utilizamos el ic-prog y una vez terminado grabamos el código en el pic.
Lo ponemos en marcha y voilá!!!! todo funciona correctamente, las tramas ahora si entran en la red aprs.
Finalmente, he montado el circuito sobre una placa universal taladrada y sólo queda meterlo todo en una caja. Uso este tipo de placas porque el tema de taladrar como que me aburre un montón.
Un par de fotos....
Detalle del montaje sobre la placa de nodos taladrada.
Un saludo
Ernesto.
