/***********************************************************************************************************************/ /***********************************************************************************************************************/ MMB03HW1 Micro: Atmel ATSAMS70Q21B /***********************************************************************************************************************/ /***********************************************************************************************************************/ Versión 2.18 (21/07/2023) Vigilante => MSB del byte de dispositivos a 1 siempre.. excepto si estamos en test que es 0 (para que se resetee al pedir la orden de test) /***********************************************************************************************************************/ Versión 2.17 (20/07/2023) Definición D30D => Variable Turbidez (Cambio el la resolución al leer la trama). Los datos son correctos, solo la definición de la trama /***********************************************************************************************************************/ Versión 2.16 (06/07/2023) Entrada intrusión => Cambiada a normalmente abierta /***********************************************************************************************************************/ Versión 2.15 (03/07/2023) EMA Airmar => Velocidad viento en nudos.. (estabamos interpretándola en 0.1 Knots) Vigilante => Cambios en la trama de tx del vigilante EMA AIRMAR => Estaba actualizando el vigilante en el com3 en vez del com4 MTX => El vigilante del COM1 se reseteará también al recibir el NULL, indicando que la conexión está viva /***********************************************************************************************************************/ Versión 2.14 (28/06/2023) EMA AIRMAR => La velocidad del viento es 0.1Knots, tras obtener el dato, lo pasamos directamente a m/s PC => Las tramas de configuración se pueden leer y escribir directamente a través del PC Entradas impacto: Monoestables /NC / Activación en 10 seg /Remanencia 30 minutos Entrada intrusion: Biestable /NC / Activación en 5 seg /***********************************************************************************************************************/ Versión 2.12 (07/06/2023) Telemando escaneo ALL => Al no estar presente el CTD, se quedaba en proceso... /***********************************************************************************************************************/ Versión 2.11 (18/05/2023) CTD => Turbidez: Estaba limitada a 16 bits.. realmente son 24 bits /***********************************************************************************************************************/ Versión 2.10 (16/05/2023) Habilitación del CTD Versión 2.9 (04/05/2023) Cambiada por defecto el tipo de entrada del sensor de impacto leve y grave -Normalmente cerrado y 2 segundos para que se active /***********************************************************************************************************************/ Versión 2.8 (03/05/2023) Frame 10 : Error detectado en los bits de MMB03 sincronizada con... Deshabilitación del CTD /***********************************************************************************************************************/ Versión 2.7 (27/03/2023) Detectado un problema en la posición GPS al sacar el estado por el puerto Detectado un problema en las alarmas del status MMB03 => Estaba desplazado MTX => Seguridad Keep Alive insertada Cada X segundos, el mtx enviará un "null" a través de la conexión.. y debe recibir un null cada cierto tiempo Cada vez que transcurre el tiempo programado, se envía el null y se aumenta una variable. Tras 4 veces enviando el null y sin recibir ningún dato ni el keep alive de retorno, realizaremos un reset del modem Para programar la frecuencia de keep alive del MTX Lectura de la frecuencia: 2,65535,658,3103221423,M$2,MT1,C*0C Escritura de la frecuencia: 2,65535,658,3103221423,M$3,D10C,010422,MT1,1,900*69 /***********************************************************************************************************************/ Versión 2.6 (13/03/2023) Mismo que la 2.5... cambiado para evitar confusiones /***********************************************************************************************************************/ Versión 2.5 (13/03/2023) Posiciones en formato P7 Comunicación MTX: En la transmisión automática por el MTX, tras detectar la conexión del "tunel", retardaremos la transmisión de paquetes de forma automática 30 segundos Incorporados los comandos T$7 => Enable /Disable la tx automática de paquetes T$8 => Se utilizará en caso de pérdida de los índices: A partir del paquete seleccionado en la trama (normalmente será uno cercano al último transmitido correctamente), buscaremos el último paquete formado correctamente y lo colocaremos como último paquete creado. Ejemplo.. supongamos que estamos en el paquete número 556.. y de repente, la MMB03 se vuelve "loca" y pierde los índices... Enviando el telemando T$8,550, buscaremos el paquete 550.. y leeremos el 551,552,553... hasta el 556 que es el último válido.. pues a partir de ahí crearemos el 557 y será nuestro último paquete.. /***********************************************************************************************************************/ Versión 2.4 (02/03/2023) Cambio de la estrategia de comunicaciones Hasta ahora la MMB03 era cliente.. guardaba los datos en memoria y los entregaba al servidor cuando tenía una petición A partir de ahora, es la MMB03 la que transmitirá los paquetes una vez estén cerrados. Para evitar la pérdida de datos, el equipo detecta cuando la conexión a través del MTX está cerrada y durante esos momentos pausa el envío de datos. Una vez se re-establezca la conexión, la MMB03 lo detectará y volverá a enviar paquetes (si tiene alguno pendiente) Ante la llegada de un telemando, el envío de los paquetes se pausa.. se atiende al telemando y posteriormente se continúa. De esta forma, evitamos que el OCEANCOM tenga que estar cerrando conexiones y abriendo conexiones cada vez que se produce un paquete. Solo cerrará las conexiones cuando el OCEANCOM necesite realizar un telemando. Retardo configurable en la respuesta de los telemandos Debido a que la conexión y desconexión de un socket conlleva un cierto tiempo, se ha previsto que tras el envío de un telemando, se produzca un retardo (configurable y definido en la definición de la trama 1) en la o las respuestas del telemando. Offset de tiempo en el cierre del paquete Debido a que los paquetes se cierran en el mismo minuto que llegan los datos de los sensores, se ha previsto un offset de tiempo (configurable y definido en la definición de la trama 1) para que el paquete se cierre un poco más tarde y que todos los datos de los sensores se incluyan en el paquete antes de cerrarlo. /***********************************************************************************************************************/ Versión 2.3 (28/02/2023) Creado un nuevo modo de funcionamiento transparente a través del telecontrol => Funcionamiento transparente con debug En la MS4 => Si el dato es 0 => Salimos del modo transparente Si el dato es 1 => Entramos en modo transparente por telecontrol Si el dato es 2 => Entramos en modo transparente por telecontrol con modo debug Que signfifica el modo transparente con debug => Que todo los datos serán replicados por el puerto de PC (tanto los tx por el sensor como por el sistema de telecontrol) /***********************************************************************************************************************/ Versión 2.2 (24/02/2023) EMA => Cambiada de puerto COM5 a COM4 ya que el equipo real es RS232 /***********************************************************************************************************************/ Versión 2.1 (24/02/2023) ADCP => Hemos cambiado el peso de las velocidades MSB => Velocidad X / LSB => Velocidad Z Al mismo tiempo hemos desplazado el barrido 3 minutos para que los datos lleguen antes de que se cierre el paquete /***********************************************************************************************************************/ Versión 2.0 (22/02/2023) EMA AIRMAR En este proyecto se han definido y desarrollado las tramas D122, y D123 D122 (Definición sensor) => Definición, Umbrales, Extendida D123 (Status sensor) => Definición de la trama Todas estas tramas se leen y se escriben a través de diferentes métodos (PC, GPRS, etc). En función de estas tramas, el sensor se ha de comportar o extraer unos datos u otros. De este sensor, se han desarrollado las rutinas para: a) Extraer las magnitudes medidas por el sensor y adaptarlas al formato definido en las tramas de D122 Velocidad y dirección viento Velocidad y dirección ráfaga Presión atmosférica Temperatura del aire b) Obtener una muestra de datos cada x tiempo predefinido en la trama D122. c) Extraer datos de fecha y posición para poner en hora la MMB03 y al mismo tiempo calcular el radio de borneo. d) Extraer datos para completar la trama de status D123. e) Realizar las rutinas necesarias para que el sensor pueda obedecir antes un telemando de status o de petición de muestra. CTD Trimeter Se han definido unas nuevas tramas D30 (Definición, umbrales y extendida) En ellas se ha incorporado la Turbidez, pero se eliminan el resto de variables del sensor previamente desarrolladas… Esta eliminación hace que no sea compatible con lo anteriormente desarrollado Según la información recibida, las rutinas de explotación del sensor son las mismas ya desarrolladasADCP Se ha definido una trama nueva “Configuración” => D80C En esta trama, se guarda la configuración del sensor ADCP , 514 bytes de datos que se procesan, se almacenan en memoria y se leen de la memoria cuando es necesario. Cada vez que el sensor ha de realizar un barrido, se lee la configuración del mismo y se compara con la guardada en memoria. Si no son iguales, se vuelca la nueva configuración (la guardada en memoria) MMB03: Cálculo metros de borneo En este proyecto se han definido y desarrollado las trama D10P. En ella definimos Latitud y longitud de origen (Podemos definir una NO posición para que el equipo haga una autoposición). Frecuencia de actualización del radio de borneo en condiciones de NO alerta Frecuencia de actualización del radio de borneo en condiciones de ALERTA Metros de radio de borneo Cambio también de la trama D10 (Status MMB03) => Definición, Umbrales y Extendida Se ha incluído el radio de borneo actual en la trama La posición se obtiene tanto del waves como de la EMA AIRMAR. Cuando llega el momento de actualizar la posición, se realiza una petición a ambos sensores.. para tener en cuenta la opición de los 2.. (o por si alguno de ellos no funciona) Una vez obtenida la posición, se calculan los metros de desplazamiento. Si el desplazamiento es superior a 1Km..respecto a la posición anterior, no se tiene en cuenta (un error en la detección de la posición o en el procesado de la posición). Para dar alarma de rotura de cadena, se han de verificar que estamos fuera del rádio de borneo definido al menos 5 veces.MMB03: Cambio en el proceso de almacenar las muestras. Para evitar muestras duplicadas en un mismo paquete de datos, se ha cambiado la forma de almacenar las muestras Hasta la fecha, las muestas y los status, se van almacenando en el paquete de datos, conforme van llegando. Si un sensor entrega varias muestras en un mismo sample interval, se guardaban todas las muestras Ahora si un sensor entrega varias muestras dentro de un mismo sample interval, se guarda solo la última muestra, las anteriores se sobreescriben De esta forma transmitimos menos datos al exterior. Ha habido que desarrollar rutinas para una vez que llega una muestra, identificar si la muestra ha de ser guardada o sobreescrita. Al mismo tiempo, el paquete de salida se crea ahora al finalizar el mismo, ya que los datos definitivos no se saben hasta el cierre del paquete Modem MTX Primeramente se desarrollaron rutinas siguiendo las directrices de MSM para configurar el tunel de datos de MTX. No obstante todo eso se desechó.. y es MSM quien controla las comunicaciones a través de este modem. Por parte de la MMB03 se considera un “cable virtual”. Por donde entran las comunicaciones y extraemos las mismas Siguiendo las directrices de MSM, la MMB03 es cliente. Ella va almacenando los paquetes terminados en memoria y será el servidor el que realice las peticiones de datos cuando considere oportuno. Esto es similar a “Georgia”.. aunque en este caso se ha terminado de separar el protocolo de comunicaciones del modo de transmisión, ya que el mismo protocolo puede transmitirse por diferentes métodos (AIS, MODEM, VHF, WIFI,etc…) A través del modem MTX, podemos procesar y responder a las tramas: M$0 => Reset sensores M$1 => Petición de tramas de status de los sensores M$2, y M$3 => Lectura y escritura definición y status de los sensores y todas sus variantes (Definición, Extendida, Umbrales, Configuración, Posición) M$4 => Habilitación y deshabilitación de modo transparente con los sensores a través del MTX M$5 => Petición de tramas de sample de los sensores T$1 => Petición de paquetes desde /hasta T$2 => Petición del siguiente paquetes T$3 => Petición del último paquete generado T$4 => Cambio del último paquete “entregado”