Foro Navegantes

Conecta solo el ais a opencpn y grasa sentencia a ver que salr

(07-03-2024, 07:29 AM)Antonio Sollano escribió: [ -> ]En este archivo es donde ha estado el barco saltando

Hola,
La explicación del problema es algo compleja, pero voy a ver si me explico para que se entienda:
Este caso actualmente es bastante común dada la proliferación de GPS/GNSS en las redes de datos de los barcos. (Radios con GPS, Plotters, AIS...)
Hay duplicidad en todos los mensajes de GPS: GGA, GLL, RMC, VTG (esto es lo habitual cuando hay más de un GPS. Pero en este caso, los mensajes mútiples GSV aparecen truncados: Son bloques de tres, pero llegan alatoriamente el primero, segundo o tercero, nunca los tres. Y los demás mensajes de uno de los GPS no aparecen cada segundo como debería ser.
La entrada NMEA0183 del Quark-Elec es a 4800 bauds (fija), por lo que se tuvo que reducir también la velocidad de salida del Gyro a 4800, que resulta muy lenta para que se transmitan correctamente los mensajes muy frecuentes de Heading True (HDT) en combinación con los del GPS y los mensajes propietarios del Gyro.
El resultado es que hay "Overflow" en el transmisor NMEA0183 del Gyro y se pierden bastantes mensajes de todo tipo, afectando más a los largos como RMC y GSV/GSA. Estos últimos GSV/GSA contienen información de azimut, altura y nivel de señal de los satélites GPS que están en uso. No son datos importantes, pero ocupan tiempo de transmisión.
A la vez, El Quark-Elec tiene su propio receptor GPS con diferente calidad de recepción, y el envío de esos datos no puede anularse por configuración. Lo único que se puede hacer es desconectar la antena de GPS para evitar que tansmita mensajes con contenido.

Propuesta para corregir el desaguisado:
1- El dispositivo Moxa Nport 5210A tiene dos puertos de entrada RS232, y sólo se está utilizando uno, por eso:
2- Configurar la salida del Gyro NAVIGAT X MK1 y el canal 2 del Moxa a 38400 baud (manual ->serial settings cap.5.9), y conectar el Gyro directamente al Moxa. Con ello resolvemos el cuello de botella en la salida de datos del Gyro.
3- Desconectar la antena GPS del Quark-Elec para impedir que pueda calcular la posición y sólo envíe mensajes de GPS vacíos. Como es sólo receptor AIS, esto no afectará a la recepción de blancos.

Inconvenientes de esto: Toda la info estará presente sólo en Ethernet, no en la WiFi, y el sistema OpenCPN dependerá totalmente de los datos del Gyro. No será autónomo como pretendías.
Solución definitiva: Ocenav (puede servir tanto el ATM105 como el Rem072), ya que su software se diseñó para seleccionar dinámicamente el GPS/GNSS con mejor calidad de datos (HDOP). De esta manera, sólo se tomarán los datos de un GPS, y el otro actuaría como respaldo en caso de fallar el primero. (Esto siempre y cuando se resuelva previamente el cuello de botella en la salida del Gyro).

NOTA: De los 3 ficheros VDR, sólo uno tiene anuladas las sentencias GGA, pero siguen las duplicidades aleatorias de las demás sentencias GPS con diferencias sustanciales en las coordenadas.

Planteado con Ocenav, sería preciso el ATM105A3 puesto que dos de sus canales NMEA0183 se pueden configurar a 38400.
Entonces las I/O del ATM105A3 quedarían:
NMEA0183 canal 1: Sin conectar. (Sólo funciona a 4800)
NMEA0183 canal 2, entrada: Salida del Gyro. (Configurar salida del gyro a 38400)
NMEA0183 canal 2: salida: Entrada RS232 del Moxa. (Configurar ATM105 "NMEA0183 Canal 2: 38400 y "Output All")
NMEA0183 canal 3: entrada: Salida del Quark-Elec. (Velocidad "Auto", tal como sale de fábrica)

Entrada del Quark-Elec: Sin conectar.

El ATM105A3 tiene conexión NMEA2000 para ampliaciones / sustituciones futuras. Puede conectarse a un Ocenav GNY115, y de esta manera tener un sistema OpenCPN totalmente autónomo, en este caso desconectando el Gyro NAVIGAT X MK1.
El GNY115 es un GNSS de última generación + Gyro de 9 ejes. Suministra datos GNSS (GPS+Glonass+Beidou+Galileo), Heading Magnético y Verdadero (calcula la declinación), Attitude (Pitch, roll, yaw), Velocidad de rotación y en un PGN propietario, también aceleraciones lineales en los tres ejes. No será tan bueno ni tan caro como un NAVIGAT, pero hace su trabajo.

(07-03-2024, 12:35 PM)Tehani escribió: [ -> ]Hola,
La explicación del problema es algo compleja, pero voy a ver si me explico para que se entienda:
Este caso actualmente es bastante común dada la proliferación de GPS/GNSS en las redes de datos de los barcos. (Radios con GPS, Plotters, AIS...)
Hay duplicidad en todos los mensajes de GPS: GGA, GLL, RMC, VTG (esto es lo habitual cuando hay más de un GPS. Pero en este caso, los mensajes mútiples GSV aparecen truncados: Son bloques de tres, pero llegan alatoriamente el primero, segundo o tercero, nunca los tres. Y los demás mensajes de uno de los GPS no aparecen cada segundo como debería ser.
La entrada NMEA0183 del Quark-Elec es a 4800 bauds (fija), por lo que se tuvo que reducir también la velocidad de salida del Gyro a 4800, que resulta muy lenta para que se transmitan correctamente los mensajes muy frecuentes de Heading True (HDT) en combinación con los del GPS y los mensajes propietarios del Gyro.
El resultado es que hay "Overflow" en el transmisor NMEA0183 del Gyro y se pierden bastantes mensajes de todo tipo, afectando más a los largos como RMC y GSV/GSA. Estos últimos GSV/GSA contienen información de azimut, altura y nivel de señal de los satélites GPS que están en uso. No son datos importantes, pero ocupan tiempo de transmisión.
A la vez, El Quark-Elec tiene su propio receptor GPS con diferente calidad de recepción, y el envío de esos datos no puede anularse por configuración. Lo único que se puede hacer es desconectar la antena de GPS para evitar que tansmita mensajes con contenido.

Propuesta para corregir el desaguisado:
1- El dispositivo Moxa Nport 5210A tiene dos puertos de entrada RS232, y sólo se está utilizando uno, por eso:
2- Configurar la salida del Gyro NAVIGAT X MK1 y el canal 2 del Moxa a 38400 baud (manual ->serial settings cap.5.9), y conectar el Gyro directamente al Moxa. Con ello resolvemos el cuello de botella en la salida de datos del Gyro.
3- Desconectar la antena GPS del Quark-Elec para impedir que pueda calcular la posición y sólo envíe mensajes de GPS vacíos. Como es sólo receptor AIS, esto no afectará a la recepción de blancos.

Inconvenientes de esto: Toda la info estará presente sólo en Ethernet, no en la WiFi, y el sistema OpenCPN dependerá totalmente de los datos del Gyro. No será autónomo como pretendías.
Solución definitiva: Ocenav (puede servir tanto el ATM105 como el Rem072), ya que su software se diseñó para seleccionar dinámicamente el GPS/GNSS con mejor calidad de datos (HDOP). De esta manera, sólo se tomarán los datos de un GPS, y el otro actuaría como respaldo en caso de fallar el primero. (Esto siempre y cuando se resuelva previamente el cuello de botella en la salida del Gyro).

NOTA: De los 3 ficheros VDR, sólo uno tiene anuladas las sentencias GGA, pero siguen las duplicidades aleatorias de las demás sentencias GPS con diferencias sustanciales en las coordenadas.

Tehani, me cuadra lo que me dices porque además el dato de rumbo verdadero de la Giro también desaparece de vez en cuando en el Dash board del opencpn, configurar la Giro en el segundo puerto del Nport con 38400 me parece perfecto pero si desconecto el GPS el dato de la velocidad supongo que lo perderia tambien no?.

(07-03-2024, 02:48 PM)Antonio Sollano escribió: [ -> ]Tehani, me cuadra lo que me dices porque además el dato de rumbo verdadero de la Giro también desaparece de vez en cuando en el Dash board del opencpn, configurar la Giro en el segundo puerto del Nport con 38400 me parece perfecto pero si desconecto el GPS el dato de la velocidad supongo que lo perderia tambien no?.

Lamentablemente la cosa se complica. El dispositivo NAVITWIN  extrae la info para los repetidores de datos en formato NMEA0183 según norma IEC 61162-1, lo que quiere decir que es a baja velocidad (4800 baud). No se puede cambiar. (Manual app.1.7).
La única manera que veo posible para reducir el atasco es ir al GNSS del sistema y reducir los mensajes que envía a los gyros limitándolos exclusivamente a RMC y GGA. Entre los dos ya están presentes todos los datos importantes. Habría que eliminar GLL, VTG, GSV, GSA.
Lo habitual es que los Plotters / GNSS con conexión NMEA0183 permitan seleccionar los mensajes de salida.
Si consigues hacer esto, ya no será necesario el GPS del AIS y podrás desconectar su antena para que "enmudezca".

Nota: GGA añade info de HDOP, número de satélites en uso, fecha y tipo de adquisición (dead reckoning, autonomous, diferencial, etc). Es posible que quitándola, la cosa también funcione. Todo eso es información complementaria, no vital.

Lo que parece mentira es que la gente de Sperry no haya previsto este problema de overflow en la salida a 4800 baud.

(07-03-2024, 02:48 PM)Antonio Sollano escribió: [ -> ]Tehani, me cuadra lo que me dices porque además el dato de rumbo verdadero de la Giro también desaparece de vez en cuando en el Dash board del opencpn, configurar la Giro en el segundo puerto del Nport con 38400 me parece perfecto pero si desconecto el GPS el dato de la velocidad supongo que lo perderia tambien no?.

Si consigues reducir el parloteo del GNSS a RMC, y como máximo RMC/GGA, el dato de velocidad que está presente en RMC (COG + SOG) llegará de forma estable a OpenCPN.
RMC contiene:
- Hora UTC.
- latitud / Longitud.
- COG / SOG
- Fecha
- Declinación. (Magnetic variation).
- Indicador de datos válidos.

Así, GGA sólo añadiría HDOP y Quality indicator como datos con cierta importancia. El resto serían complementarios:
https://receiverhelp.trimble.com/alloy-g...s_GGA.html

Por otra parte, no te preocupes por ese cambio, ya que no afectará a los gyros. Según su manual, obtendrán igualmente los datos que necesitan.

Desde el punto de vista de OpenCPN, sólo son necesarias las sentencias RMC (GPS), VDM (AIS) y HDG/HDT (FLUXGATE/GYRO).
Lo demás es totalmente superfluo.
OcenCPN no usa ROT para nada.

(07-03-2024, 03:53 PM)Tehani escribió: [ -> ]Si consigues reducir el parloteo del GNSS a RMC, y como máximo RMC/GGA, el dato de velocidad que está presente en RMC (COG + SOG) llegará de forma estable a OpenCPN.
RMC contiene:
- Hora UTC.
- latitud / Longitud.
- COG / SOG
- Fecha
- Declinación. (Magnetic variation).
- Indicador de datos válidos.

Así, GGA sólo añadiría HDOP y Quality indicator como datos con cierta importancia. El resto serían complementarios:
https://receiverhelp.trimble.com/alloy-g...s_GGA.html

Por otra parte, no te preocupes por ese cambio, ya que no afectará a los gyros. Según su manual, obtendrán igualmente los datos que necesitan.

Buff la Giro ni tocar porque encima que soy yo el responsable de ella, esta involucrada en los sistemas de tendido de cable y termino en la calle si la lio. Voy a Hacer las pruebas que me dices , de todas maneras esto es un sistema solo de referencia y como esta ahora me valdría  porque no son saltos muy grandes con la Giro puesta. De todas maneras tengo la posibilidad de usar tambien un Satellite Speed Log de Furuno model GS 100 2 que tiene libres dos salidas de data y una de Net, lo tengo que estudiar.
Pregunta: Si el barco aumenta la velocidad estos saltos serian mas pequeños igual o mayores que por lo que tengo visto al aumentar la velocidad creo que me iba bastante mejor.

(07-03-2024, 04:56 PM)Antonio Sollano escribió: [ -> ]Buff la Giro ni tocar porque encima que soy yo el responsable de ella, esta involucrada en los sistemas de tendido de cable y termino en la calle si la lio. Voy a Hacer las pruebas que me dices , de todas maneras esto es un sistema solo de referencia y como esta ahora me valdría  porque no son saltos muy grandes con la Giro puesta. De todas maneras tengo la posibilidad de usar tambien un Satellite Speed Log de Furuno model GS 100 2 que tiene libres dos salidas de data y una de Net, lo tengo que estudiar.
Pregunta: Si el barco aumenta la velocidad estos saltos serian mas pequeños igual o mayores que por lo que tengo visto al aumentar la velocidad creo que me iba bastante mejor.

Las diferecias en las coordenadas son del mismo orden, lo que pasa es que al aumentar la velocidad, se incrementa la distancia en diagonal y las diferencias de los catetos de los dos GPS (diferencias de coordenadas en un mismo punto) son en proporción más pequeñas (Proyección Mercator).
Además, el COG/SOG son más estables por la misma razón.
El GPS calcula el COG como ángulo que existe entre dos coordenadas separadas cada segundo de tiempo. Cuanto más distantes sean esas coordenadas (Mayor velocidad), mejor saldrá el cálculo y también será más estable.
Y el SOG lo mismo, lo hace calculando distancia entre dos coordenadas (hipotenusa) y divide por el tiempo transcurrido entre esas dos posiciones, que también suele ser de 1 segundo exacto.
Ahora mi pregunta:
Sin tocar nada, ¿puedes decirme marca y modelo del GNSS principal?. Si encuentro el manual, le echaré un vistazo.
Por otra parte, puedes hacer una última prueba con el Gyro conectado y la antena del GPS del AIS también conectada: En conexiones de openCPN, quita todas las sentencias que tenías en "ignorar"; y en "aceptar sólo setencias", pones RMC, VDM y HDT. Nada más. Debería saltar bastante menos, pero el problema de fondo persiste.

(07-03-2024, 05:26 PM)Tehani escribió: [ -> ]Las diferecias en las coordenadas son del mismo orden, lo que pasa es que al aumentar la velocidad, se incrementa la distancia en diagonal y las diferencias de los catetos de los dos GPS (diferencias de coordenadas en un mismo punto) son en proporción más pequeñas (Proyección Mercator).
Además, el COG/SOG son más estables por la misma razón.
El GPS calcula el COG como ángulo que existe entre dos coordenadas separadas cada segundo de tiempo. Cuanto más distantes sean esas coordenadas (Mayor velocidad), mejor saldrá el cálculo y también será más estable.
Y el SOG lo mismo, lo hace calculando distancia entre dos coordenadas (hipotenusa) y divide por el tiempo transcurrido entre esas dos posiciones, que también suele ser de 1 segundo exacto.
Ahora mi pregunta:
Sin tocar nada, ¿puedes decirme marca y modelo del GNSS principal?. Si encuentro el manual, le echaré un vistazo.
Por otra parte, puedes hacer una última prueba con el Gyro conectado y la antena del GPS del AIS también conectada: En conexiones de openCPN, quita todas las sentencias que tenías en "ignorar"; y en "aceptar sólo setencias", pones RMC, VDM y HDT. Nada más. Debería saltar bastante menos, pero el problema de fondo persiste.

Utilizo una antena Furuno GPA017 conectada a la entrada GPS del  Quark Elec A026 dispongo de otra antena Furuno GSC001 que nunca he probado, la verdad al principio haciendo pruebas obtenía mejores resultados con un a antena UBLOX conectada por USB a mi ordenador pero no me sirve para esta instalación ya que no la puedo meter al NPORT individualmente que yo sepa y la verdad me parecía mas profesional la Furuno.
He probado la ultima configuración que me dices y va mas o menos, hay algún salto de vez en cuando pero estamos caminando a 022 nudos y como dices cuando vamos muy lentos los saltos son mayores, he probado a configurar en la MOXA la salida a 38400b y creo que es peor o igual, también he probado a deshabilitar el FIFO y sigue igual.
De momento lo tengo configurado como me dices y me sirve para el proyecto que abri sobre seguridad en caso de ataque pirata y tener referencia en el ECR.
Además lo compagino con algún mapa del SAS Planet y de EMODNET API que me configuraron en Cartografía Digital y la verdad queda muy chulo y los compis Americanos felices.
Como este proyecto esta aprobado, cuando lo termine y presente se instalara en los 8 barcos restantes y podre hacer pedidos por lo que me interesa lo que me propusiste sobre los equipos que me recomiendas. Del Quark Elec me estoy desilusionando.

(08-03-2024, 10:16 AM)Antonio Sollano escribió: [ -> ]Utilizo una antena Furuno GPA017 conectada a la entrada GPS del  Quark Elec A026 dispongo de otra antena Furuno GSC001 que nunca he probado, la verdad al principio haciendo pruebas obtenía mejores resultados con un a antena UBLOX conectada por USB a mi ordenador pero no me sirve para esta instalación ya que no la puedo meter al NPORT individualmente que yo sepa y la verdad me parecía mas profesional la Furuno.
He probado la ultima configuración que me dices y va mas o menos, hay algún salto de vez en cuando pero estamos caminando a 022 nudos y como dices cuando vamos muy lentos los saltos son mayores, he probado a configurar en la MOXA la salida a 38400b y creo que es peor o igual, también he probado a deshabilitar el FIFO y sigue igual.
De momento lo tengo configurado como me dices y me sirve para el proyecto que abri sobre seguridad en caso de ataque pirata y tener referencia en el ECR.
Además lo compagino con algún mapa del SAS Planet y de EMODNET API que me configuraron en Cartografía Digital y la verdad queda muy chulo y los compis Americanos felices.
Como este proyecto esta aprobado, cuando lo termine y presente se instalara en los 8 barcos restantes y podre hacer pedidos por lo que me interesa lo que me propusiste sobre los equipos que me recomiendas. Del Quark Elec me estoy desilusionando.

Este es el salto que realiza el barco Responder en el plotter

(08-03-2024, 10:16 AM)Antonio Sollano escribió: [ -> ]Utilizo una antena Furuno GPA017 conectada a la entrada GPS del  Quark Elec A026 dispongo de otra antena Furuno GSC001 que nunca he probado, la verdad al principio haciendo pruebas obtenía mejores resultados con un a antena UBLOX conectada por USB a mi ordenador pero no me sirve para esta instalación ya que no la puedo meter al NPORT individualmente que yo sepa y la verdad me parecía mas profesional la Furuno.
He probado la ultima configuración que me dices y va mas o menos, hay algún salto de vez en cuando pero estamos caminando a 022 nudos y como dices cuando vamos muy lentos los saltos son mayores, he probado a configurar en la MOXA la salida a 38400b y creo que es peor o igual, también he probado a deshabilitar el FIFO y sigue igual.
De momento lo tengo configurado como me dices y me sirve para el proyecto que abri sobre seguridad en caso de ataque pirata y tener referencia en el ECR.
Además lo compagino con algún mapa del SAS Planet y de EMODNET API que me configuraron en Cartografía Digital y la verdad queda muy chulo y los compis Americanos felices.
Como este proyecto esta aprobado, cuando lo termine y presente se instalara en los 8 barcos restantes y podre hacer pedidos por lo que me interesa lo que me propusiste sobre los equipos que me recomiendas. Del Quark Elec me estoy desilusionando.

Me parece que no me expresé con claridad.
Las antenas Furuno GPA017 y Furuno GSC001 son antenas pasivas (tontas por así decirlo), y lo único que pueden aportar es una mayor o menor ganancia de señal. No importa la que pongas porque el que realiza el cálculo de la posición es el GPS que está dentro del Quark-Elec, y por lo visto es bastante mediocre. Desde luego no es un receptor GNSS.
Lo que te estaba proponiendo era inutilizar ese GPS precisamente desconectando la antena Furuno para impedir que el QE pudiera realizar los cálculos y no introdujera coordenadas ni COG/SOG imprecisos.
Te preguntaba acerca del receptor GNSS o plotter principal. El que suministra datos a los Gyros.
Las imágenes que has adjuntado parecen indicar que el Magnetic Heading (Sentencia HDG), que es lo que usa OpenCPN para orientar el barco en la carta, llega muy de vez en cuando. Voy a comprobarlo en los logs que enviaste, ya que en la primera revisión que hice no encontré más que HDT (true).

(08-03-2024, 11:49 AM)Tehani escribió: [ -> ]Me parece que no me expresé con claridad.
Las antenas Furuno GPA017 y Furuno GSC001 son antenas pasivas (tontas por así decirlo), y lo único que pueden aportar es una mayor o menor ganancia de señal. No importa la que pongas porque el que realiza el cálculo de la posición es el GPS que está dentro del Quark-Elec, y por lo visto es bastante mediocre. Desde luego no es un receptor GNSS.
Lo que te estaba proponiendo era inutilizar ese GPS precisamente desconectando la antena Furuno para impedir que el QE pudiera realizar los cálculos y no introdujera coordenadas ni COG/SOG imprecisos.
Te preguntaba acerca del receptor GNSS o plotter principal. El que suministra datos a los Gyros.
Las imágenes que has adjuntado parecen indicar que el Magnetic Heading (Sentencia HDG), que es lo que usa OpenCPN para orientar el barco en la carta, llega muy de vez en cuando. Voy a comprobarlo en los logs que enviaste, ya que en la primera revisión que hice no encontré más que HDT (true).

Los GNSS son dos Furuno GP 170

Bueno, parece que se empieza a ver lo que está pasando.
Heading magnético no se envía nunca y el verdadero (HDT) es suficiente para OpenCPN. Por ahí no van los tiros.
El problema grave del GPS del Quark-Elec se puede ver aquí:

En esta sentencia RMC, A está indicando que los datos son válidos a la vez que ,, es un campo vacío que corresponde a COG: 
$GPRMC,230132.00,A,3711.68921,N,01211.21898,E,0.231,,060324,,,A*7B      Esto está volviendo loco a OpenCPN (Y a cualquiera...)

$HEHDT,163.53,T*1D                                    Esto lo está enviando el Gyro (Heading true)
$GPVTG,,T,,M,0.231,N,0.428,K,A*2D               VTG debería contener COG / SOG. Aquí el campo COG se lo han comido. (SOG = 0.428Kn)
...
$HEHDT,163.42,T*1D
Aquí lo mismo, A que indica datos válidos, y ,, campo vacío sin COG:
$GPRMC,230133.00,A,3711.68915,N,01211.21900,E,0.268,,060324,,,A*71
...              Más sentencias que no vienen al caso: HDT, GLL, GGA, VDM...
$HEHDT,163.28,T*11
Aquí ya está correcto, pero le falta la declinación y el indicador de modo al final:
$GPRMC,230134.00,A,3711.68906,N,01211.21912,E,0.376,158.71,060324,,,A*6D     COG = 158.71
$HEHDT,163.27,T*1E
$GPVTG,158.71,T,,M,0.376,N,0.697,K,A*3D       Cuando RMC contiene COG, VTG también: 158.71 grados.


Esta secuencia de desapariciones de COG durante períodos de tiempo de bastantes segundos ocurre frecuentemente.
La conclusión es que cuando OpenCPN decodifica la sentencia RMC, si A le indica que los datos son válidos, en lugar de COG está leyendo basura de la memoria.
Alguien podrá decir: Bien, si el campo está vacío, ignóralo. Pero es que TODOS los GPS/GNSS que he visto hasta la fecha, cuando dicen que los datos son válidos, todos los campos de RMC contienen valores coherentes. En este caso no.
Sabemos ya quién es el candidato para visitar y quedarse en el chatarrero...