/****************************************************************************************************************/
/********************************************** Microcontrolador   R5F64111		*********************************/
/****************************************************************************************************************/

/*****************************************************************************************************************/
/*********************************		MTU300C-HW5				**************************************************/
/*****************************************************************************************************************/
Cambios realizados en el hardware:
	Nuevo módulo de radio Radiocrafts
	Cambio del modem GSM al SIM900D

/*****************************************************************************************************************/	
	Firmware 20 (05-09-16): 			

		Trama estado:
			- MFUHF Y MFVHF en el lugar de las revoluciones (que no puede medir), se introduce la pauta del destellador tanto en el modo ethernet (v3 MSM) como java


/*****************************************************************************************************************/	
	Firmware 19 (05-05-16): 			
		Se incorporan en el test:
			- Test de transmisión de radio constante => Que durará unos 10 segundos. Una vez hecho por primera vez el test, con pulsar intro, volveremos a repetir el test

/*****************************************************************************************************************/	
	Firmware 18 (11-02-16): 			
		Tras analizar los mensajes en el coordinador de Palma vía Satel, hemos visto que sí, cada vez que el coordinador recibe una respuesta por parte de las remotas
	de "no tengo incidencias", el coordinador lo que hacía era pedir un estado. Hemos corregido esto para que al llegar esta respuesta, el coordinador no pida estado.
	
	Tras una petición de estado o de telemando por GPRS (mediante la trama de ethernet), el dispositivo contestará a todos los clientes la misma trama.
		

/*****************************************************************************************************************/	
	Firmware 17 (04-05-15): 			
		Se ha limitado el número de mensajes "salientes" hacia el exterior (netcom) de los radiomodems a 1 por slot. El tiempo de slot no se puede subir de 
	25'5 segundos porque habría que cambiar el protocolo de los dispositivos remotos, ya que el tiempo del slot se envía en las trams y se utiliza para
	sincronizar y dormirse cuando toca.

/*****************************************************************************************************************/	
	Firmware 16 (22-04-15): 			
		Partiendo de la versión 12 que es muy estable, tras el envio de una trama de cambio de hora se inicia la actualización automática de las balizas
	
	
/*****************************************************************************************************************/	
	Firmware 15 (21-04-15): 			
		Fracasada se vuelve loca

/*****************************************************************************************************************/	
	Firmware 14 (20-04-15): 			
		Fracasada por no enviar tramas de estado				
/*****************************************************************************************************************/
	Firmware 12 (17-03-15): 			
	
		Insertado modo de programación remota (deja de enviar mensajes a las remotas durante 10 minutos)
		Insertado el modo de depuración (Similar a poner el jumper)
	
/*****************************************************************************************************************/

	Firmware 11 (10-03-15): 			
		
		Tras que una baliza se de por muerta, si se recibe una trama de esa baliza, se vuelve a incorporar en el sistema, pero a la web se sigue indicando que no existe. 
	Solo desaparecerá esta indicación cuando se reciba alguna trama de estado (con ello actualizaremos los datos)
	
		Se ha incoporado tambien la posibilidad de leer los registros internos de los módulos de radio
		
		Como novedad en este firmware, utilizamos los eventos recibidos de los módulos para saber si el dispositivo está dentro de la red. (Como si fuese una trama recibida)
		

	Firmware 10 (19-02-15): 			
		Detectado un problema en el arranque de autobanda del GSM a raiz de una reparación. Teníamos dos variables que debería ser una sola (cambiaba una letra).

	Firmware 9 (18-02-15): 			
		RSSI : En esta versión se miden la señal de las últimas 20 conexiones vía radio y se extrae la media para su análisis. Si una comunicación falla por timeout, en este caso
	la Rssi es 0
		Comandos Ethernet => Se ha incorporado un comando nuevo INTERROGAR=/ESTADOB/ que pregunta directamente a la baliza
		
		Una vez que el dispositivo "no responde" al preguntar el estado a través de la web, anteriormente se preguntaba al coordinador y este respondía. Ahora se intentará comunicar 
	con la baliza y posteriormente dar la respuesta
	
		Cuando el coordinador recibía una trama de presentación,automáticamente enviaba una petición de estado. Esto generaba tramas incorrectas en la web. Ahora se envía una petición
	de estado automático.
		www

	Firmware 8 (11-02-15)(Palma): 			
		Se han cambiado alguna cosita de debug para que diera más información.. pero nada importante

	Firmware 7 (26-01-15): 			
		En la pantalla de debug (RS232A) sacamos por el puerto todo lo que sucede en el coordinador... Desde todas las tramas de radio tanto interrogaciones como respuestas
	a todas las interrogaciones de otros puertos RS232B,RS485A,RS485B, GPRS.. etc...
	
	Tras un reset o un comando de comunicación del coordinador, tendremos una ventana de tiempo de 10 segundos donde no se mirarán las comunicaciones inhalámbricas. Solo se atenderá
	al PC (Para poder comunicarse con el transceiver)
	
	Cuando la WEB pregunte por un dispositivo y no se encuentre en la red, al no conocer que tipo de dispositivo es contestará con todas las tipos conocidos
	es decir MMB02,MTU300,MTU310,MUUFH,MFVHF
	
	Podremos poner hora al coordinador con  una serie de comandos. Como el transceiver todavía no tiene implementada esta función, el checksum "solo" en estos 2
	comandos es transparente
		


	Firmware 5 (18-11-14): 			
		Trama Ethernet MMB25:
			- Se han introducido las alarmas analógicas 1 al 6 en la trama MMB25		


	Firmware 5 (04-08-14): 			
		Radio modem:
			- Se ha incluido en esta versión una nueva funcionalidad. La MMB02 a partir de la versión 7_9 es capaz de hacer de repetidor de un radio modem
			
			
			
	Firmware 4 (01-08-14): 			
		Mejorada la recepción de datos de radio ICM. Se actualizaba el parámetro de saltos solo en el estado, con lo que ha veces podía aparecer salto=0. como este parámetro llega cada vez que hay una transmisión de datos, sea estado o sea lo que sea.. siempre se recoge.
		
	Firmware 3 (31-07-14): No OK			
		Eliminado problema de no poder comunicar por los puertos secundarios RS232B, RS485A y RS485B.

	Firmware 2 (30-07-14): No OK			
		GPRS con el modem SIM900D que permite multiples conexiones (hasta 6 conexiones simultáneas)
		Tras un reset, el dispositivo lee de su memoria interna las balizas que anteriormente existían en el sistema e intenta recuperarlas más rapidamente interrogándolas. Si no consigue recuperarlas, estas se darán de alta con el paso del tiempo.


	Firmware 1 (02-07-14):			
		Copiado el funcionamiento que teníamos con el módulo de Telit, pero en este caso con el módulo de Radiocrafts. No se ha puesto ninguna nueva función
		
				
/*****************************************************************************************************************/
/*********************************		MTU300C-HW4				**************************************************/
/*****************************************************************************************************************/

	Firmware 23 (28-09-12):			
		
		Error detectado en las bandas del GSM. Se enviaba de forma incorrecta el comando
		
		Habilitación de un jumper que solo deja activo las comunicaciones
		
		Caundo el tmp de refresco estado balizas es 0, no hace peticiones de estado a las balizas
	

	Firmware 22 (19-09-12):			

	Tras un telemando, las estaciones remotas envian un mensaje de estado. Dicho mensaje de estado no se extrae vía sms.Si se envia la confirmación del telemando.
	
	Radio modem:
		Cuando hay una única estación remota vía radio modem, tras enviar los comandos de lectura de e2prom o escritura de e2prom, dejaba de interrogar.



	Firmware 21 (17-09-12):			
		
		Hemos incorporado un nuevo dispositivo (MTU310 = MTU300 con Radio Modem). Este dispositivo envía las tramas igual que cualquier MTU300, pero con la cabecera "MTU310".
		
		Hemos habilitado el envio de estados y telemandos vía SMS. 
			- A través de SMS se pueden realizar peticiones de estado (2 centros de control) o telemandos remotos. El SMS llega al coordinador y este envia el telamando a la baliza correspondiente. Una vez ejecutado el telemando devolverá al centro de control una confirmación de telemando con el estado adecuado

			- Si se habilita la extracción de tramas a través de SMS, el coordinador no extraerá toda la información que le llegue de las balizas, (ya que sería un sistema ruinoso porque podría enviar un sms cada minuto). Hay un parámetro (Refresco estado balizas), con el que indicamos cada cuanto tiempo el coordinador hace una petición de estado a las balizas.
			Solo cuando llegue la respuesta a esta petición de estado, será cuando se extraiga el mensaje SMS, por lo que se pueden poner un refresco del sistema largo para no enviar muchos sms. 
			Al mismo tiempo, cuando se produzca algún cambio en la baliza, sí enviará un SMS el coordinador por su propia cuenta



		


	Firmware 20 (05-07-12):			
	
		Se ha descubierto un error si se desactivaba el radio modem. El dispositivo hacía caso al parámetro de "Nº de baliza inicio radio Modem". Por lo que podía darse el caso, si se ponía un nº bajito que las balizas de radio ICM no entrasen y se registrasen.
		Para evitar esto, cuando el Radio Modem se desactiva, el dispositivo hace caso omiso a este parámetro y automáticamente lo configura como la última baliza del sistema. De esta forma todo el espectro será para radio ICM.
	

	Firmware 19 (01-07-12):			
	
		Incorporado telemando de las salidas externas del coordinador
			La salida 1 sirve para resetear el radio modem del coordinador
			La salida 2 sirve para ver si existen balizas "vivas" en dicho coordinador.
		
		Cambio de las tramas de estado de los dispositivo MFVHF
			- Ahora empiezan por MFVHF
			- Se ha incorporado la eficiencia del enlace en las tramas (Se toman las últimas 1500 tramas para calcular la eficiencia. Si hay un reintento se resta 1, si la trama llega correctamente se suma 1).
			
		Se ha puesto una seguridad de forma que si no se recibe ninguna trmaa por radio modem pasados 10 minutos, automáticamente el dispositivo realizará un reset de Radio Modem.	
			

	Firmware 18 (15-06-12):	
		Se ha cambiado el proceso de gestión de las balizas por Radio Enlace (Se ha incorporado la gestión de slots).
		Cada dispositivo dispone de un slot para realizar la transmisión. El coordinador irá preguntando a los diferentes dispositivos de radio modem y estos solo contestarán dentro de su slot y cuando se les pregunte.
		Al mismo tiempo se ha incorporado un nuevo dispositivo que es el MFVHF (con Radio modem). Sus tramas de estado similar a los MFUHF
		
	Firmware 17 (22-03-12):			

	A partir de esta versión, el coordinador es capaz de gestionar balizas que se comunican por Radio ICM y por Radio Enlace.
	Comunicación Radio enlace:
		El coordinador siempre va a ser el maestro del enlace. Él es el que va a coordinar las comunicaciones y va a dar los permisos para que el resto de dispositivos contesten cuando se les pregunta. 
		Por parámetros se indicará que números de balizas se comunican por radio enlace.
	
	El mapa de balizas será de la 0 hasta N-1   => Radio ICM
				   De la N hasta M    => Radio Enlace

	Máximo número de balizas a gestionar por el coordinador 150 elementos

	El coordinador siempre preguntará a las balizas de radio enlace si tienen alguna incidencia. Las balizas enviarán la incidencia si tienen algo y si no una respuesta corta indicando que no tienen nada nuevo que decir. Si la respuesta no llega, pasará a la siguiente baliza (se configura por parámetros un timeout)

	Al mismo tiempo, tambien se le ha dado vida al GPS del coordinador. Cuando se recibe una trama, con posición GPS todo a 0, significa que no tiene GPS instalado o correcto. Por lo que si el coordinador tiene habilitado el GPS, cambiará la hora de la trama.
	Puede suceder que si tenga una posición GPS correcta (posición GPS teórica), se comprueba la hora.y la fecha. Si la hora y la fecha está todo a 0, significa que el dispositivo remoto no tiene GPS y por tanto cambia la hora de la trama.
	(El mismo protocolo que para el Radio enlace se utilizará para la comunicacion RS485 en un futuro).
	La comunicación de Radio enlace se puede hacer por los puertos RS232B,RS485A y RS485B. La velocidad de comunicación es 9600 baudios

	Firmware 16-3 (18-01-12):			
		Error detectado en el formato de estado de la trama GMV en el estado de las salidas digitales
		Tras un telemando de GMV, la confirmación del telemando pasa de un retardo de 2 minutos a 30 segundos

	Firmware 16-2 (09-01-12):			
		La interpretación del telemando de la salida de potencia, a cambiado de "SDP" a "SD10"

	Firmware 16-1 (22-12-11):			
		Error en el telemando Ethernet (Destinatario telemando)


	Firmware 16 (20-12-11):
		Cambiada la cabecera de las tramas Ethernet MMB02   => Cabecera anterior (MMB02) Cabecera nueva (MMB25)


	Firmware 15 (17-10-11):
		Solucionado los problemas de la trama NMEA MMB02: La corriente de baliza y la corriente de panel solar se enviaban de forma erronea y se enviaban en formato erroneo los estados de las salidas y día/noche		
		El módulo de radio se reseteará siempre y cuando pase un determinado tiempo sin recibir ni una trama de los routers o puntos finales (antes lo hacían al pasar x tiempo.. recibiese trama o no)
		

	Firmware 14 (27-10-11):
					
	Detectado problema línea de control 485:
		- Cuando se enviaban tramas Ethernet y NMEA al mismo tiempo, tan solo se extraian por RS485 una de ellas, debido a un error en la línea de control de RS485
	
	Firmware 13 (13-10-11):
			
	Interpretación de la revisión 2 del protocolo Ethernet con GMV
	Interpretación de la revisión 2 del protocolo JAVA
	Tras el envio de un telemando de reset, envía una respuesta de confirmación.
	Modificación de la orden "Cambiar configuración red" de forma que ahora se puede modificar:
		- Numero del dispositivo dentro de la red
		- Nombre del dispositivo dentro de la red
		- Número de la red del dispositivo
	
							
	Firmware 12 (15-9-11):

	Interpretación de la revisión 1 del protocolo Ethernet con GMV
		Cambio del panel solar instantáneo por la corriente del sensor de potencia.
	Detección de fallos en el protocolo de JAVA tras el cambio realizado en la MMB02 (Una entrada analógica puede ser configurada como corriente de baliza o panel solar, estando dicha entrada analógica configurada como tensión)							

	Firmware 11 (26-8-11):

	Error detectado en la versión 10: Configuración uart vigilante...   se ha configurado para otra velocidad.
	Se ha modificado la radio para que sea compatible con el sitema "all in one". (Version radio 3.11)
	Tambien no hace falta colocar el jumper para entrar en test
	En el test se ha introducido el test de las 3 salidas digitales.

	Firmware 10(30-7-11):
		
	Partiendo de la versión 9 del MTU300CHW3.

	Hemos hecho una modificación de forma que a través de la salida digital 2 indicamos si existe una baliza en el sistemo o no.
	Si hay, aunque sea una baliza registrada y viva en el sistema, activaremos la salida digital 2, por el contrario, si no existen balizas registradas o ninguna responde, desactivaremos la salida digital 2.
	Esta salida la conectaremos a un selector que activará un coordinador u otro en función de si el coordinador funciona o no. (Sistema redundante de coordinadores Ej. Santander)