/****************************************************************************************************************/ /********************************************** Microcontrolador R5F21257 *********************************/ /****************************************************************************************************************/ /*****************************************************************************************************************/ Firmware 2_04 (13/07/23): Transceiver 1.0.2 o superior. Tras una nueva autoposición: Quitaremos la alarma de rotura de cadena(si estuviese activada)y reiniciaremos los metros /*****************************************************************************************************************/ Firmware 2_03 (07/07/23): Monitoreo => Al crearse un mensaje IRIDIUM, actualizaremos el tiempo de ON del IRIDIUM. La finalidad es intentar que el iridium extraiga el mensaje /*****************************************************************************************************************/ Firmware 2_02 (06/07/23): Protocolo IRIDIUM => MFSAT-V2 Monitoreo => Error detectado en los tiempos de encendido/apagado del equipo Si pasados los 20 minutos de tiempo, no hemos conseguido enviar el mensaje, apagaremos el módulo IRIDIUM y el mensaje no se enviará El vigilante espera que el equipo tenga al IRIDIUM registrado antes de 6 horas.. En modo monitoreo esto no tiene porque suceder, ya que si todo funciona bien, el IRIDIUM se debería encender solo en los cambios de estado (12 horas aprox). Por tanto, tras apagar el IRIDIUM, engañamos al vigilante durante 24 horas.. Cada vez que el modem se registre, volveremos a recargar las 24 horas... Transcurridas estas 24 horas, dejaremos que el vigilante actue. /*****************************************************************************************************************/ Firmware 2_01 (22/06/23): Modificada simplemente la identificación del firmware. En el transceiver se identifica como fw 201 /*****************************************************************************************************************/ Firmware 2 (28/05/23): Transceiver 1.0.2 o superior. Modificada la comunicación con el MFSINCLOC El cálculo de la alarma de rotura de cadena se ha realizado de forma similar a la B360 Se incluye: IRIDIUM => Funcionalidad de monitoreo o telemando Telemando: realizará los ciclos normales de on/off Monitoreo: Tanto los tiempos de ciclo de on/off de iridium deben estar a 0. Tras un reset el Iridium se activará durante 20 minutos y solo se volverá a activar tras un evento (ya sea paso de día a noche y viceversa o activación de una alarma) MFSINCLOC: La posición de origen puede ser automática (tras un reset) o fija en los parámetros. Si el automática, el mfsincloc calculará la posición actual y la tomará como origen Si es fija, el MFSAT le enviará la posición de origen y el MFSINCLOC la tomará como origen. /*****************************************************************************************************************/ /*****************************************************************************************************************/ Firmware 1_21 (15/02/21): SBD Binario => Cambiada la cabecera de "MFSAT" por un código /*****************************************************************************************************************/ Firmware 1_20 (16/11/20): El envio de los SBD será binario o ASCII... el usuario lo seleccionará por parámetros /*****************************************************************************************************************/ Firmware 1_19 (06/08/20): Incorporados Telemando MMB03 /*****************************************************************************************************************/ Firmware 1_18 (26/09/18): LOG INTERNO: En la media de la cobertura IRIDIUM, no tendremos en cuenta las mediciones "sin cobertura" de IRIDIUM. Es decir, si el módulo devuelve un 0 (SIN COBERTURA), no utilizaremos este dato para calcular la media En el mensaje de LOG, ponemos el número de dispositivo asociado /*****************************************************************************************************************/ Firmware 1_17 (26/09/18): LOG INTERNO: En el log se guarda la versión de firmware. Si se detecta que se ha cambiado la version de firmware, automáticamente se borra el log Los parámetros medios guardados en el log siempre serán de una hora. En el log se guardan las últimas 24 horas, y el parámetro que mostramos es una media de las últimas 24 horas, (siempre que el log sea superior a 24 horas. Si el log es inferior a 24h, el dato obtenido es la media de las horas transcurridas desde el inicio del log). Ejemplo LOG 56 días Datos medios de las últimas 24 horas LOS 7 horas Datos medios de las últimas 6 horas, (Ya que la hora en curso no se toma en cuenta) Cada vez que se graba la hora en servicio, se guardan los datos de las medias en el log /*****************************************************************************************************************/ Firmware 1_16 (18/09/18): Hemos quitado un error del log interno. El log se ha verificado durante 4 días consecutivos. También había un problema a la hora de enviar el log a través del mensaje IRIDIUM: solucionado /*****************************************************************************************************************/ Firmware 1_15 (06/09/18): Este firmware parte del firmware 1_12 Novedades: Introducción de un log interno que se podrá consultar e inicializar - Dentro del test (Con los comandos "LOG" y "RESET LOG") - A través de mensaje IRIDIUM (Con los comandos "CLAVE!LOG" y "CLAVE!RESETLOG") Parámetros del log interno 1=> Cantidad resets MFSAT 2=> Horas en servicio 3=> Cantidad resets MF12 4=> V max MF12 5=> V min MF12 6=> T max MF12 7=> T min MF12 8=> T avg MF12 9=> Cantidad fallos comunicaciones MF12 10=> Avg satélites MFSINCLOC 11=> Avg calidad satélites MFSINCLOC 12=> Cantidad fallos comunicaciones MFSINCLOC 13=> Avg Q IRIDIUM 14=> Minutos sin registro red IRIDIUM Comunicacíon con el MF12 - El MFSAT, lo primero que hará será leer si el destellador ha tenido algún reset. - No ha habido ningún reset, perfecto, seguimos con las comunicaciones como hasta ahora -Sí ha habido reset, contabilizamos los reset del destellador en el log interno del MFSAT, escribimos estas posiciones a 0 y no tenemos en cuenta los datos, esperando la siguiente interrogación, donde los datos serán mucho más fiables /*****************************************************************************************************************/ Firmware 1_14 (20/07/18): Verificación alarmas MF12: Alarma batería baja Alarma baja corriente baliza Alarma sobreconsumo baliza Alarma exceso temperatura Todas estas alarmas tanto para activarse como para desactivarse se verificarán 3 veces de forma consecutiva. Cada vez que el MFSAT detecte un "posible" cambio del estado de una de estas alarmas, volverá a preguntar al destellador en un tiempo máximo de 3 minutos. (Si el ciclo de interrogación del MF12 es superior a 3 minutos, recortaremos este ciclo a 3 minutos, si es inferior, dejaremos el tiempo de su ciclo normal). Una vez detectemos una posible activación/desactivación de una alarma, el valor del parámetro implicado no se actualizará hasta que se verifique el cambio de estado de la alarma o se descarte este cambio de estado). Estos parámetros son: Alarma batería baja => Parámetro implicado valor batería Alarma baja corriente baliza => Parámetro implicado valor corriente baliza Alarma sobreconsumo baliza => Parámetro implicado valor corriente baliza Alarma exceso temperatura => Parámetro implicado valor temperatura Ejemplo: Supongamos que tenemos un ciclo de interrogación del MF12 de 10 minutos con una tensión de alimentación de 12v Cada 10 minutos, el MFSAT interroga al destellador y todo funciona correctamente. Supongamos ahora que la tensión de batería baja a 8v El destellador detectará la alarma de batería baja, así como su nueva tensión de alimentación Cuando termina el ciclo de 10 minutos, el MFSAT interroga al destellador y detecta la activación de alarma batería baja... No la retransmite, simplemente internamente pone un indicador de "posible alarma". Automáticamente no actualiza el valor de la batería, por tanto para el telecontrol siguen habiendo 12v en la tensión de alimentación Ahora el nuevo ciclo de interrogación al MF12 es de 3 minutos, ya que el ciclo normal es recortado Transcurridos estos 3 minutos, volvemos a interrogar y verificamos de nuevo este cambio en el estado de la alarma Posibilidad 1 => Falsa alarma => Quitaremos el estado de "posible alarma", actualizaremos la tensión de batería y volveremos al ciclo de 10 minutos Posibilidad 2 => Segunda verificación de la posible activación de la alarma batería baja.. Volveremos a repetir el ciclo de 3 minutos Finalizado el ciclo de 3 minutos, volveremos a verificar y si de nuevo es positiva la verificación, activaremos la alarma de batería baja, actualizaremos el valor de la batería y retransmitiremos el mensaje correspondiente. /*****************************************************************************************************************/ Firmware 1_13 (17/07/18): Cambios en el proceso de dia/noche: Hasta la fecha, nos fiábamos de la información recibida por el MF12, pero hemos visto que si por ejemplo estamos en NOCHE y el MF12 se resetea, el MFSAT detectará primero un "falso paso noche/día" y posteriormente volverá a detectar el paso de "dia a noche", con el consiguiente mensaje IRIDIUM, (que no debería haber habido ya que en teoría deberíamos encontrarnos siempre en noche) Para evitar estos mensajes y falsos pasos día/noche ahora se seguirá la siguiente estrategia: - Si han transcurrido 5 horas desde el último cambio día/noche o noche/día => Nos creeremos lo que dice el destellador sin verificar nada. - Si no han transcurrido las 5 horas desde el último cambio día/noche o noche/día => Para realizar el cambio, verificaremos 3 veces el cambio. Si las 3 veces consecutivas leemos el cambio de estado, entonces realizaremos el cambio. Sin embargo, la fecha y hora del mensaje IRIDIUM será de la primera vez que hemos detectado el cambio de estado. /*****************************************************************************************************************/ Firmware 1_12 (03/11/17): Cuando realizamos un comando de "reset posición", borramos la posición de origen. Antes no se borraba. Por si acaso, también hemos activado un registro que da más corriente a la salida que activa el reset del gps Las entradas externas ahora tienen la posibilidad de ser monoestables o biestables /*****************************************************************************************************************/ /********************************* MFSATHW1 **************************************************************/ /*****************************************************************************************************************/ Firmware 1_11 (18/11/16): Hemos encontrado un fallo al desactivar el MFSINCLOC. Para enviar el primer mensaje, deberíamos tener actualizada la hora, pero al no tener GPS, esta hora no se actualiza nunca. De ahí que no enviase los mensajes. /*****************************************************************************************************************/ Firmware 1_10 (29/02/15): Los mensajes de Rotura de cadena no les debe afectar el telemando de "Callate" (son los únicos a los que no debe afectar) No obstante sí tienen la limitación de cantidad de mensajes enviados x día. /*****************************************************************************************************************/ Firmware 1_9 (24/02/15): Hemos eliminado todo lo referente a la interrogación de la hora via IRIDIUM ya que ha dejado de tener sentido. Por otro lado.. hemos cambiado la estrategia de ON/OFF módulo radio Cuando el tiempo ON IRIDIUM y tiempo OFF IRIDIUM sean igual a 0 => Función telemando desactivada. El módulo IRIDIUM se activará durante 20 minutos cada vez que tenga algo que tranmitir.. y se volverá a dormir hasta que vuelva a tener algo que transmitir En el resto de casos, hará los ciclos programados Si el módulo tiene algo que transmitir, permanecerá activado hasta que esta acción se realice (Por ejemplo por falta de cobertura etc) Cada vez que llega una trama con checksum correcto, el tiempo de "encendido" empezará de nuevo /*****************************************************************************************************************/ Firmware 1_8 (17/12/15): El número de ID de los dispositivos se ha aumentado hasta 999 La rotura de alarma, tras activarse, enviará un mensaje cada 30 minutos hasta que se supere el número máximo de mensajes IRIDIUM permitidos. Se identifica bien el firmware en el programa transceiver /*****************************************************************************************************************/ Firmware 1_6 (01/09/15): En los mensajes IRIDIUM, el parámetro de cobertura será la última cobertura obtenida que no sea "SIN COBERTURA" Tras realizar ciertos telemandos (todos aquellos que afectan a los periféricos)el dispositivo realizará la acción y esperará 30 segundos. Al cabo de dicho tiempo realizará una actualización del estado de todo el sistema y enviará la respuesta Se indica por hyperterminal cuando se ha "prohibido" el envio de mensajes SMS Solo cuando no hay MFSINCLOC, antes de montar y enviar un mensaje el dispositivo debe coger la hora IRIDIUM (para evitar mensajes con horas totalmente erroneas). Esta condición solo se realizará cuando venga de un reset /*****************************************************************************************************************/ Firmware 1_5 (01/09/15): Versión fallida /*****************************************************************************************************************/ Firmware 1_4 (27/09/15): IRIDIUM: En marzo del 2015, IRIDIUM cambió de ERA.. con lo que cambió su base de tiempos a la hora de calcular la hora a través del comando AT+CCLK Para solucionar esto, a la hora que te devuelve el módulo hay que sumarle un offset Hemos detectado que cuando el módulo IRIDIUM está desactivado y hemos de enviar un mensaje, intentamos grabar el mensaje antes de inicializar correctamente el módulo. (En esta versión esto se soluciona. Hasta que no está el módulo inicializado no se graba el mensaje a extraer en el buffer) En versiones anteriores esto provocaba entrar en un bucle que solo salíamos a través del vigilante. También se ha cambiado la forma de tratar la cola de mensajes. Aunque hayan varios mensajes pendientes de enviar por activación o desactivación de entradas externas o por la razón que sea, cuando se envía un mensaje, el resto de mensajes pendientes se anulan, ya que la información se actualiza en el mensaje enviado. Sucede lo mismo al enviar un mensaje de estado. Se envía el mensaje de estado y en el mensaje de estado está el "estado" de las entradas externas o incluso el estado de la baliza. Cuando se elimina un mensaje por tmp... (ya que hay otros mensajes esperando a salir), se indica en el hyperterminal Al montar los mensajes IRIDIUM: - El parámetro de cobertura ha cambiado de forma que siempre es la última cobertura conocida que no sea 0 (Sin cobertura) - Si no existe MFSINCLOC, tras un reset, antes de montar un mensaje deberemos preguntar al IRIDIUM por la hora y colocar en el mensaje la fecha y hora correctas Cuando el módulo IRIDIUM tiene un mensaje en cola para leer y no tenemos nada que enviar.. Enviaremos mensajes "vacios" (Antes se enviaba el estado) MF12: Se ha actualizado el protocolo de comunicaciones con el MF12 (24 horas hw3 o hw4.. etc..) Ahora cada vez que se interroga al MF12, aparecerá la información en el hyperterminal MFSINCLOC: Ahora cada vez que se interrogue al MFSINCLOC aparecerá la información en el hyperterminal Nada más empezar el programa, lo primero que debe saber es en que estado está.. por lo que interrogará al MF12 y al MFSINCLOC /*****************************************************************************************************************/ Firmware 1_3 (22/09/15): Versión Beta que arregla la nueva Era de IRIDIUM /*****************************************************************************************************************/ Firmware 1_2 (03/10/14): Al poner el jumper JP1, arrancaba la fuente de IRIDIUM y consumía.. Ahora ya no Cuando no hay comunicación con el GPS, lo reintenta varias veces y si no consigue comunicación, avisa de error y continua con su trabajo Hemos insertado en el ESTADO: - Si el módulo IRIDIUM está registrado - Cuantos minutos hace que se registró por última vez /*****************************************************************************************************************/ Firmware 1_1 (29/09/14): Problema detectado a la hora de resetear el contador de mensajes IRIDIUM en el vigilante. El contador se resetea cada vez que se registra el módulo IRIDIUM. No estabamos reseteándolo siempre /*****************************************************************************************************************/ Firmware 1 (20/09/14): Firmware: Versión inicial del MFSAT. Transceiver: Version 0.8.95 Jumper comunicación (JP1) Se utiliza para configurar el dispositivo con el transceiver. El dispositivo solo atiende a la comunicación que le llega del PC. Jumper modo verboso (JP3) Se utiliza para depurar el firmware y ver que está sucediendo en el dispositivo. A través del hyperterminal con la siguiente configuración, veremos todo lo que está sucediendo en el dispositivo. Envio de mensajes El MFSAT enviará de forma automática un mensaje al producirse alguna alarma o algún evento importante que transmitir. Tras recibir un telemando o una petición de estado, el MFSAT tambien responderá con un mensaje (que denominaremos "ACK") El MFSAT tiene un número máximo de mensajes permitidos al día. Si se supera ese máximo de mensajes dejará de transmitir mensajes, durante ese día, a excepción de los mensajes "ACK". De forma automática el MFSAT enviará mensajes si se producen las siguientes alarmas: * Rotura de cadena * Batería baja * Bajo consumo corona leds * Sobreconsumo panel solar * Sobreconsumo corona leds * Fallo comunicación con MF12 * Entrada externa 1 * Entrada externa 2 * Entrada externa 3 * Entrada externa 4 * Temperatura excesiva * Fallo en la baliza Y los siguientes eventos: * Baliza en noche * Baliza en día Recepción de mensajes A través de telemandos, podremos: * Leer la configuración del dispositivo de forma remota * Escribir la configuración del dispositivo de forma remota * Realizar una petición de estado * Forzar día * Forzar noche * Quitar el forzado día/noche * Resetear el MF12 * Nueva autoposición (Resetear MFSINCLOC04) * Reset completo del sistema Para ahorrar energía en el sistema, el MFSAT se encargará de activar y desactivar el módulo IRIDIUM en función de un ciclo programado, teniendo en cuenta que el inicio del ciclo coincide con las horas en punto Ejemplo: Suponiendo un ciclo de 10 min ON y 20 min OFF Cada hora se repetirá el siguiente ciclo 00 a 10 => IRIDIUM ON 10 a 30 => IRIDIUM OFF 30 a 40 => IRIDIUM ON 40 a 00 => IRIDIUM OFF Si algún evento o alarma se produce mientras en periódos de OFF, el MFSAT automáticamente encenderá el módulo IRIDIUM para transmitir el mensaje correspondiente. Este ciclo solo se realizará mientras no tengamos nada que transmitir (ya sea un mensaje automático o un ACK). Si hay alguna cosa que transmitir, el módulo IRIDIUM permanecerá activo hasta que la transmisión se realice. Cabe la posibilidad de que en el sistema no exista un MFSINCLOC04. Cuando esto ocurre, el MFSAT obtendrá la hora y la fecha de la red IRIDIUM y la actualizará cada x tmp (Minutos off GPS)