Reloj/Calendario/Posicionador Geográfico/Termómetro sincronizado por módulo GPS

[Jorge Bern]

Buenas tardes colegas.
Este es mi primer posteo con este mi nuevo usuario, antes tuve otros en el foro pero cambié a este para unificar con otras cuentas que tengo por ahí.
El proyecto del asunto lo estoy desarrollando durante esta época tan especial de aislamiento y espero que les sea de interés, ya que integra el uso de PICs (uso el 16F628) enlazado con un módulo receptor GNSS(GPS) modelo Ublox GY-GPSV3-NEO-M8N que le provee la info de hora, fecha, posición, que el Reloj mostrará en su display.
Una particularidad de este Reloj es que utiliza un display de tubos de vacio TRC tipo IEE MIMO de unos 70 años de antiguedad.
Tambíen incorpora un control de temperatura para ventilar los TRCs utilizando un sensor digital tipo  DS18B20
En sucesivos posteos iré desarrollando el proyecto con el mayor detalle posible y será bienvenido todo comentario y/o sugerencia.
Saludos y gracias por la atención

[Nocturno]

Interesante proyecto, permaneceré atento a tus progresos.

Una curiosidad, ¿por qué ese PIC?

[Jorge Bern]

Continuando con el tema del diseño de este Reloj presentaré el display que utiliza como dije, tubos de rayos catódicos (CRT) marca IEE modelo NIMO BA0006-P31 (ó IEE NIMO 6000-31-0006), que en adelante llamaré directamente Tubos.
Estas son joyas electrónicas  de los años 50 y 60, con su placa y circuiteria original recuperada desde el fondo de alguna tienda de antiguedades.
También es original la fuente de alimentación marca IEE modelo 14549, que ingresa con 110VAC por ser americana, y que provee 1,1 VAC para los filamentos (cátodos) y 3.500 VDC para los ánodos de  los Tubos.

Respecto de estos Tubos podemos detallar lo siguiente:
NIMO fue la marca comercial de una familia de Tubos de Rayos Catódicos (CRT) muy pequeños y no estandarizados, fabricados por IEE (Industrial Electronics Engineers de USA) a mediados de 1960.
En este caso el Tubo es el modelo BA0006-P31, que cuenta con 10 cañones de electrones con plantillas que dirigen y dan forma de dígito o caracter alfanumérico al haz de electrones que se proyecta e ilumina su pantalla superior.
Estos Tubos son de diseño interno artesanal y complejo pero de operación simple ya que proyectan un sólo dígito entre 10, normalmente de 0 a 9. Los hay más complejos de proyección multiple que cuentan con deflexión magnética especial pero este no es el caso.
Este modelo de Tubo posee 3 tipos de electrodos, un filamento catódico, un ánodo y 10 grillas o rejas de control que activan los 10 haces electrónicos con sus cuadrículas correspondientes.
Las ventajas de los Tubos NIMO respecto de sus contemporaneos NIXIE es su mejor ángulo de visualización, incluso el dígito proyectado se ve desde atrás del Tubo, y su color y brillo variable (dimmerizable). Sus desventajas es su mayor complejidad de alimentación y mayor consumo. El Tubo requiere mínimo 1750 Voltios de tensión DC de ánodo, 1.1 voltios de tensión AC para los filamentos, y cierta polarización catódica como se verá luego en el circuito de control.

Los datos del Tubo IEE BA0006-p31 pueden verse aqui:
https://drive.google.com/open?id=1DLRQtPeQQ1hgiz-LHyR7V1T94ZohrDft

 La placa de Tubos y su fuente de alimentación:

 

tubos1.jpg
(29.47 kB, 171x338 - visto 644 veces)

 

fuente2.jpg
(13.71 kB, 193x138 - visto 657 veces)

En la siguiente figura puede verse como varía el brillo o luminancia del Tubo en función de la tensión de Ánodo, lo que hace variable (dimmerizable) el brillo del tubo. Normalmente el control de brillo de un display numérico construido con estos Tubos se lograba con un reostato en el circuito primario del transformador de su fuente anódica, hoy con una alimentación switching variable supongo se lograría el mismo efecto.

 

nimo1.jpg
(16.84 kB, 363x274 - visto 675 veces)

En la siguiente figura se muestra el circuito típico de testeo del Tubo NIMO.
Como en todo tubo de rayos catódicos, la corriente de haz se controla con la tensión del electrodo Grilla o reja. Como se ve en la figura, una tensión de Grilla de -6 Voltios respecto del Cátodo producirá la repulsión de los electrones del haz, llevando la corriente del Tubo al corte y apagando el brillo de la pantalla. En cambio una tensión de Grilla de +4 Voltios respecto del Cátodo permitirá el paso pleno de los electrones del haz y el brillo máximo de la pantalla del Tubo.
Cuando la Grilla de control sea negativa, su efecto de repulsión electrónica hará que la  corriente de haz de su cañon catódico sea nula. Cuando la Grilla sea positiva tomará unos pocos microamperes de corriente del haz, por lo cual debe usarse una resistencia de limitación de corriente de Grilla de un valor mínimo de 1 MegaOhms.

 

nimo2.jpg
(27.9 kB, 363x297 - visto 653 veces)

Con esto y para no aburrir, finalizo la introducción a los Tubos a utilizar.
Un saludo.

[Jorge Bern]

Interesante proyecto, permaneceré atento a tus progresos.

Una curiosidad, ¿por qué ese PIC?

Ese PIC, si entiendo que es viejo, pero la principal razón fue que lo tenía en mi cajón jeje
Y en capacidad, memoria, USART, etc. estimo alcanza para este proyecto, aunque siempre se está a tiempo de cambiar.
Y gracias por el interés. espero no defraudar.
Un saludo

[Jorge Bern]

Continuando con este desarrollo, les cuento que como interface entre el PIC y los Tubos del Display, utilicé la técnica de registros de desplazamiento y decodificadores BCD que me anduvo bien en otros proyectos.
El decodificador BCD a decimal que utilicé es el CD4028 y su funcionamiento es simple, tiene 10 salidas y cada una se activará de acuerdo al código BCD de sus entradas. La alimentación será de 12 Voltios, de modo que con una polarización catódica de los Tubos de 6  Voltios, las 10 salidas del deco atacarán las 10 Grillas con +6 Voltios (tensión grilla-cátodo) cuando la salida está activa y encendiendo el dígito del Tubo, y con -6 Voltios (tensión grilla-cátodo) cuando la salida se desactiva y el dígito del Tubo se apaga. Claramente habrá un deco por cada Tubo.
Los códigos BCD de entrada a los decos los proveerán registros de desplazamiento o conversores serie/paralelo de 8 bits  tipo CD4094, entonces habrá un CD4094 por cada dos CD4028. Como el Reloj será de seis dígitos (Hora: Minutos:Segundos ó Año:Mes:Dia) usará seis CD4028 y tres CD4094. Los tres registros estarán en cascada y los datos entrarán en serie desde el PIC.

De acuerdo a esto, el circuito para dos Tubos (dígitos) es el siguiente:

 

nimo_c.jpg
(76.54 kB, 640x360 - visto 662 veces)

Y el diagrama para seis Tubos (dígitos) será:

 

nimo_d.jpg
(64.69 kB, 640x353 - visto 656 veces)

Un saludo.

[Jorge Bern]

Continuando con este proyecto, adjunto una foto de las primeras pruebas de los Tubos aún con su circuiteria original, la cual cambié por la detallada arriba.

 

nimos5.jpg
(166.37 kB, 1083x613 - visto 691 veces)

Ahora algunas consideraciones sobre el display del Reloj.
Como puede verse en las fotos, la placa de Tubos posee cinco Tubos NIMO o sea que falta uno para completar los seis dígitos necesarios para mostrar con dos dígitos cada uno, los tres valores de Hora, Minutos y Segundos en el modo Reloj, ó Día, Mes, Año en el modo Calendario. Y además como dije arriba, también mostrará Longitud y Latitud en el modo de Posicionador Geográfico.
Como estos Tubos son reliquias escasas y caras, la solución del sexto dígito será utilizar un Tubo especial (no NIMO) llamado de "medio dígito" que solamente mostrará un "1" o estará apagado.

Entonces de acuerdo a este criterio, el Display de seis dígitos mostrará (la X corresponde a dígito apagado):

- En el modo Reloj, la hora en el formato de 12 horas AM/PM, desde  X1:00:00 hasta 12:59:59
- En el modo Calendario, la fecha en el formato Mes:Año:Día, desde X1:20:01 hasta 12:20:31 (desde el 1ro de enero hasta el 31 de diciembre de este año, por ejemplo)
- En el modo Posicionador Geográfico,   
  - Longitud en el formato Grados (tres dígitos) y Minutos (dos digitos mas un dígito decimal)  desde + 180:00.0  hasta - 180:00.0
  - Latitud en el formato Grados (tres dígitos) y Minutos (dos digitos mas un dígito decimal)  desde + X90:00.0 hasta - X90:00.0

Como sólo hay seis digitos para mostrar todo, el cambio entre vista de Hora / Fecha será automático.
El Reloj en cada cuenta de diez segundos mostrará durante ocho segundos la Hora y durante dos segundos la Fecha.
Según esto, se verá en los segundos de 0 a 5 la Hora, durante los segundos 6 y 7 la Fecha, y en los segundos 8 y 9 de nuevo la Hora.

Y el cambio para pasar a mostrar Longitud/Latitud será con un pulsador que mientras esté oprimido, las vistas de Longitud/Latitud se alternarán cada cinco segundos.

Por ejemplo en este momento en Argentina, el Reloj mostrará:
- Hora,   2:31:35 ; Fecha,  12:03:20 ; Longitud, - 58:08.0;  Latitud, - 37:86.6

Toda esta info mostrada es sumistrada como ya dije, por el módulo GPS y ya está funcionando en un prototipo.
Pronto subiré algún video que aclarará lo expuesto.

Un saludo.

[Picuino]

Interesante. Me apunto al hilo.

[Jorge Bern]

Continuando por aquí, aunque faltan algunos detalles sobre el Display, ya tenemos una idea general de como se verá.

Pasaré ahora al estudio del módulo GNSS (GPS) que le suministrará la info al PIC, que procesará y  mostrará en el Display.

El módulo como ya adelanté, será un receptor y procesador de señal GNSS (Global Navigation Satellite System) marca Ublox modelo GY-GPSV3-NEO-M8N de octava generación (8G), que fue liberado para uso civil en 2018 (hasta 2018 la Ublox 8G  era de uso militar (drones), hoy es de uso militar la Ublox 9G)

El módulo en su placa de evaluación con su antena integrada:

 

gps.jpg
(61.62 kB, 700x700 - visto 622 veces)

Sus características principales son las siguientes:

UbloxCompact 8th generation GPS/GNSS receive/processor GPS module‎ GY-GPSV3-NEO-M8N breakout board general features:

 - 72-channel u-blox M8 engine GPS/QZSS L1 C/A, GLONASS L10F, BeiDou B1 SBAS L1 C/A: WAAS, EGNOS, MSAS Galileo-ready E1B/C (NEO-M8N)
- SuperSense Indoor GPS, -167dBm
- On-board Ultra low noise 3.3V voltage regulator and RF filter for noise blocking
- I2C (SDA,SCL) and Uart (Tx,Rx)
- Triple band GPS, Glonass and BeiDou antenna
- Triple band Band Pass filter
- Triple Band LNA
- U-center GPS Evaluation Software
- Extensive visualization and evaluation features
- Supports AssistNow Online and AssistNow Offline A-GPS services
- 1 TTL UART port, 1 I2C port
- Time pulse LED
- Battery for HOT module start and settings storage
- Build-in HMC5983 Compass
- Dimensions: 33*33mm hole distance 22x22mm
- Fully assembled and ready to use

Las hojas de datos del módulo NEO-M8N pueden verse aquí:
NEO-M8N Hoja de datos
https://drive.google.com/open?id=1Wg52KlsVJ4rXwirX9jqGIUmcF6VxzKho
 
Y sus características mas detalladas de funciones y protocolos pueden verse aquí:
NEO-M8N características, funciones y protocolos
https://drive.google.com/open?id=1hKEx1slVAucMVO-bgP09KaiCiaI47X_1


Este módulo receptor/procesador NEO-M8N cumple con las especificaciones y normas actuales de los sistemas GNSS globales que están en operación, que actualmente son cuatro, el GPS(USA), el GLONASS(URSS), el BeiDou(China) y el Galileo(UE, aún en desarrollo),
y realmente de su gran potencia y versatilidad se usará muy poco en esta aplicación.

Aquí el uC se comunicará con el módulo por medio de su interface serial USART, utilizando el protocolo universal NMEA por medio del cual recibirá los parámetros de tiempo necesarios para actualizar su indicación de Hora, Minutos y Segundos,  de Dia, Mes y Año, y de Posición.
El protocolo NMEA es un estandar de comunicaciones jerárquico bidireccional (master-slave) para equipos electrónicos marítimos introducido en USA en el año 1983 y actualizado en los 2000s. Su manual de referencia puede verse aquí:
https://drive.google.com/file/d/1RhDY-q_ySYCkBr4vmcCsvrs7YXQbilkR/view?usp=sharing

El módulo NEO-M8N dispone entre otros de ese protocolo, que utiliza comunicación serial asincrónica (normas RS422/RS232) entre un dispositivo "hablador" (master ó talker) y uno o varios "escuchas" (slave ó listener).
Los parámetros de comunicación serial normalizados son los siguientes:

Baud rate: 9600
Number of data bits: 8 (bit 7 is 0)
Stop bits: 1 (or more)
Parity: none
Handshake: none

El formato general de los mensajes del protocolo NMEA  utiliza exclusivamente caracteres imprimibles en formato ASCII de 8 bits, comenzando el mensaje con el signo $ (pesos) y terminando con CR (carriage return) y LF (line feed)
El formato general del mensaje que recibirá el PIC será el siguiente:

 $TTSSS,D1,D2,...<CR>,<LF>

Donde TT es el identificador del dispositivo Master que envía el mensaje (dos letras), SSS es identificador de mensaje (tres letras) , y D1, D2, etc. son los datos que eventualmente acompañaran la respuesta.

Para testear el módulo  NEO-M8N, conocer sus características principales y elegir el mensaje adecuado para obtener los datos de Hora,  Fecha y Posición en tiempo real,  utilizaré la aplicación provista por el fabricante, la U-Center v20.01 GNSS Evaluation Software for Windows cuya guía de usuario puede verse aqui:

U-Center v20.01 User Guide
https://drive.google.com/file/d/1r5-AHrd7OM2dSNtgfnSi6tgzCkTW0eCF/view?usp=sharing

Un saludo.

[Jorge Bern]

Test y pruebas del módulo GNSS NEO-M8N

Entonces continuando, para testear el módulo  NEO-M8N, conocer sus características principales y elegir el mensaje a utilizar para obtener los datos, utilizaré la aplicación provista por el fabricante, la U-Center v20.01 GNSS Evaluation Software for Windows
cuya vista principal se ve asi:

 

p1.jpg
(96.38 kB, 640x349 - visto 594 veces)

Como se vé,  la aplicación brinda toda la información en tiempo real que provee el módulo NEO-M8N. Le daremos un rápido vistazo a sus ventanas.
En la linea de abajo se lee que el módulo está conectado al Computador por la interface serial COM6 a 9600 baudios y que utiliza el protocolo NMEA.
De izquierda a derecha en la pantalla de la aplicación aparecen distintas ventanas con información variada.
La primera ventana muestra los satélites GNSS recibidos, su rótulo y nivel de señal, los 6 de letra G son GPS (USA) y los 4 de letra R son GLONASS (Rusia), los Verdes están OK recibidos normalmente, los Azules están en proceso de adquisición, y en los Rojos se ha perdido la señal.
Luego está la ventana de Satellite Position que muestra la constelación visible y su posición relativa, luego la ventana de Signal History que indica el historial de señal, sus rotulos y las banderas de nacionalidad de los distintos satélites visibles.

Luego aparecen las ventanas de Data View, Altitude, Compass y Watch (Reloj) que se muestran con mas detalle aquí:

 

p22.jpg
(58.64 kB, 320x287 - visto 614 veces)

Por último aparece la ventana de Consola que muestra los mensajes en formato NMEA que se reciben del módulo y que proveen toda la información para actualizar todas las ventanas.
Luego de este vistazo a las pantallas de la aplicación U-center de test y control, veremos cual mensaje de la gran variedad que envía el módulo será el requerido para que el uC rescate la info de Hora,  Fecha y Posición necesaria para mostrar en el Reloj.

El mensaje seleccionado será el $GNRMC, cuyo formato será:

 

GNRMC.jpg
(101.17 kB, 556x420 - visto 570 veces)

El mensaje a procesar entonces será el que tenga el encabezado $GNRMC, (24-47-4E-52-4D-43-2C en Hexa)  cuyos datos se marcan en la siguiente captura de consola y será la info que el PIC deberá extraer.

 

p4.jpg
(96.46 kB, 640x372 - visto 609 veces)

Un saludo.

[Nocturno]

Tiene buena pinta ese modulito. Yo tengo experiencia con la serie SIM900 pero este parece mucho más pequeño.

[Jorge Bern]

Tiene buena pinta ese modulito. Yo tengo experiencia con la serie SIM900 pero este parece mucho más pequeño.

No conocía ese módulo, parece interesante para aplicaciones GSM/GPRS

[Jorge Bern]

Continuando con este proyecto, ya hemos definido que mensaje transmitido por el módulo NEO-M8N proveerá toda la info a mostrar en el display del Reloj
Este será el mensaje $GNRMC, donde el identificador de dispositivo es GN (GNSS módule) y el tipo de memsaje es RMC (Recommended Minimum Specific GNSS Data)
Como se ve, la indicación de tiempo es suministrada con una resolución de milesimas de segundo y la presición será la correspondiente a los relojes atómicos del sistema GPS. Logicamente esta gran presición excede los requerimientos de este diseño.
Toda la info adicional suministrada como vimos será:

 

GNRMC.jpg
(101.17 kB, 556x420 - visto 605 veces)

Entonces la USART del módulo se comunicará con el PIC a 9600 baudios (parámetros vistos arriba) pasándole los mensajes.
La USART del PIC actuará por interrupciones y su rutina (rutina de servicio de interrupción o ISR) identificará el mensaje requerido y recogerá los datos que serán almacenados en registros de memoria.
Luego el PPal (programa principal) procesará estos datos y los mostrará en el Display.

El siguiente diagrama muestra la interacción entre la ISR y el PPal

 

isrppal.jpg
(58.54 kB, 640x360 - visto 557 veces)

La USART recibe los mensajes NMEA del módulo y dispara la ISR con cada caracter (dato) recibido, identifica el encabezado del mensaje y almacena los datos en registros de memoria. el PPal lee esos registros, procesa los datos como veremos luego y los muestra en el Display.
El Display como ya vimos es de seis digitos y mostrará alternativamente Hora, Minutos y Segundos, y Mes, Año, Dia.
En la figura, HD y HU corresponden a Hora Decenas y Hora Unidades, MD y MU a Minuto Decenas y Minuto Unidades, y SD y SU a Segundos Decenas y Segundos Unidades. Lo mismo ocurre con la Fecha y DD,DU, ED,EU y AD,AU (la E la uso para Mes pues la M ya esta usada). La info de Posición no esta en el diagrama pero se obtiene en forma similar.

La ISR de la USART sigue el modelo de "maquina de estados", o sea tiene una variable de estado que le indica en que punto del mensaje está y que debe hacer con  el dato recibido.
Un diagrama simpificado de esta ISR es el siguiente:

 

rsi.jpg
(112.55 kB, 640x491 - visto 563 veces)

El proceso ingresa por el punto Verde y en la primera columna sigue el encabezamiento de mensaje $GNRMC y avanza la variable de Estado (É) comparando el dato recibido (Á) con los caracteres del encabezamiento. Cualquier comparación que no se cumpla en el seguimiento del encabezado de mensaje $GNRMC abortará la secuencia volviendo al Estado de Reposo (É=0)
Si se alcanza el estado É=7 significa que el mensaje fué identificado con exito y comienza en la segunda columna la adquisición de los datos en los registros de memoria.
Al final de esta columna se habilita un "contador de comas" para que la ISR saltee los parámetros que trae el mensaje y que no interesan, las comas son los separadores de parámetros y son constantes.
Por último en la tercera columna se recojen los datos de fecha y finaliza la secuencia exitosa de la ISR, volviendo al Estado de reposo y comenzando de nuevo con la detección del encabezamiento.
Luego con el código del programa aclararé más detalles.

Un saludo.



 

[Nocturno]

Jorge, ¿el lenguaje que vas a usar no tiene rutinas de tratamiento de strings?
Lo digo porque la máquina de estados que vas a implementar, carácter a carácter, tiene pinta de pesadilla y a poco que cometas el más mínimo error te va a dar muchos dolores de cabeza para depurar.
Recuerdo que en mi aplicación (en lenguaje C) recibía líneas enteras hasta detectar el retorno de carro, y luego hacía una búsqueda de un string dentro de otro (strstr) y en caso de encontrar GPRMC, iba extrayendo los trozos de cadena que me interesaban.

Así se simplifica mucho el código y es mucho más fácil de depurar

[KILLERJC]

Recuerdo que en mi aplicación (en lenguaje C) recibía líneas enteras hasta detectar el retorno de carro, y luego hacía una búsqueda de un string dentro de otro (strstr) y en caso de encontrar GPRMC, iba extrayendo los trozos de cadena que me interesaban.

Pero no es tan dificil tampoco implementar una maquina de estados que lo haga sobre la marcha... solo necesitas un indice, y luego ir comparandolo con otro string, que tenga el mismo comienzo (que te interese), menos memoria necesaria para procesar todo un string mas si lo hace con un PIC16F. Lo que si no se como lo implementó, imagino que ya lo tiene realizado.

[Jorge Bern]

Jorge, ¿el lenguaje que vas a usar no tiene rutinas de tratamiento de strings?

Hola, te comento que en todo este proyecto, el código lo hice en ASM (assembler) o como le llames.
Tengo alguna experiencia en C o VisualBasic con las instrucciones InString, mid$, etc. de tratamiento de strings.
Pero acá la detección es caracter por caracter con comparaciones en ASM y avanzando en la secuencia con la variable de estado.
Esta ISR ya la tengo funcionando y para chequearla hago eco de los datos recogidos a una HiperTerminal en PC.
En el diagrama de la ISR no aclaré pero se indica que el retorno de la rutina cuando recoje los datos es con "eco de datos" (salida con círculo rojo), y mientras sincroniza el mensaje no hay eco de datos (salidas con circulo naranja).
Luego pondré algo del código de la ISR, que es bastante largo.

Un saludo.