[Tehani]

Jubilao me ha dejado un piloto Simrad TP22 para acabar de pulir algunos detalles. En concreto la identificación de los modos de funcionamiento en el PGN 65305, y las pruebas enviándole datos de viento y navegación a waypoint.
Este PGN 65305 no es operativo en todos los pilotos Simrad/B&G, puesto que los AC12 y AC42 emplean el PGN 65340 para indicar el status con otro formato. Estas cosas hacen que diferentes pilotos y cabezales de control de la misma marca no sean compatibles entre sí.
Pero claro, los Ocenav tienen que bregar tanto con los TPxx, NAC2 y NAC3, como con los AC12/42 y similares.

La identificación de modos ha ido bastante bien, pero el piloto se mostraba inestable cuando recibía datos desde un Ocenav. Es decir, algún dato que yo le estaba enviando, no le gustaba.

Me pongo a buscar y encuentro que no le gusta el angulo de timón, y analizando el por qué, veo que este piloto no indica la instancia del transductor. Como indica FF (valor no válido), yo rechazo esta lectura en nmea2000, e inyecto el ángulo de timón que me viene por nmea0183. Mal.
El ángulo de timón puede tener dos instancias (babor y estribor) tanto en N2k como en 0183. Esto lo estaba implementando en esta última versión de los Ocenav, pero no imaginaba que alguien (estos de Simrad), enviaran el ángulo sin informar de la instancia. Vale, asunto arreglado: si el ángulo es válido y la instancia no, interpreto por defecto que la instancia es la 0.

Pero sigue quejándose el piloto.
A ver, qué dato más puede estar molestando. Sigo buscando en diversas capturas con el analizador lógico, y encuentro que el piloto envía el PGN 127250 (heading). Es lo normal puesto que tiene fluxgate integrado.
Lo que no es normal es que yo también esté enviando ese PGN 127250, porque si estoy detectando heading en n2k ya no lo debería enviar por ese bus. Afino el analisis, y veo que el piloto envía el heading magnético (cosa normal), y yo le estoy enviando el verdadero, tomado de nmea0183 y traducido a n2k. Los dos van en el mismo PGN, pero con unos bits que indican la naturaleza de ese heading.
Bueno, lo que voy a hacer ahora, es que no se envie ningún tipo de heading por un canal, cuando por ese canal esté recibiendo alguno de ellos (magnético o true).

Continuará...

[Tehani]

Claro, este problema del heading está pasando porque no hay coherencia entre el magnético que calcula el piloto, y el true que le estoy enviando yo a partir de un fichero pregrabado en nmea0183.

Pero tiene que ser posible enviar el true por n2k, calculado a partir del magnético recibido por n2k. Esa operativa tiene más miga, porque hay que planificarlo globalmente para todos los canales: n2k, n0183 cableados, n0183 WiFi y USB. Seatalk no cuenta aquí porque por Seatalk no se puede enviar el true.

De momento, se me ocurre aplicar el mismo criterio que para los navegadores (plotters), estableciendo un orden de prioridad y timeout para cada uno de los canales. Las cosas se complican solas, y todo para que el usuario no se tenga que liar configurando entradas, salidas, sentencias y pgn's...
Este sistema de prioridades permititía añadir un gyro de respaldo en el sistema.
Pero no, si lo analizamos a fondo: el fluxgate o gyro principal puede estar fastidiado, pero seguir enviando datos incorrectos (eso ya está comprobado que pasa). Entonces no hay manera de conmutar automáticamente al gyro de respaldo.

Sigo buscando una solución potente...

Decisión salomónica:
Ya he establecido orden de prioridad: El más prioritario es el conectado a N2k (es un gyro de 9 ejes en la mayoría de los casos, si no todos).
El que menos prioridad tiene es el fluxgate de Seatalk, pero ojo, aunque sea el menos prioritario funciona igual si es el único en el sistema.
A partir de aquí, si se recibe un heading magnético por N2k, se reenvía el verdadero pero calculado a partir de ese magnético en N2k, no que venga de otro sitio. Así la salida es coherente con la entrada.

Y si casca algún sensor, el usuario sólo tendrá que desconectarlo, y reiniciar.

Siento el rollaco, pero es que me ha ido bien para ordenar las ideas...

[Tehani]

Cambios en las nuevas versiones de los dispositivos Ocenav.
Descripción aquí:
https://foronavegantes.net/thread-3306-p...l#pid87606
Y aquí:
https://foronavegantes.net/thread-2813-p...l#pid87605

[Tehani]

Última versión 2.71 del firmware del ATM105. En el ZIP adjunto están las instrucciones para la instalación, el historial de versiones y el atm105dw.bin a seleccionar para la actualización.
Así os podréis llevar de vacaciones la versión más reciente de este gateway.
Pero añado un consejo antiguo: No toques si lo que tienes funciona y no da problemas. Por eso también conviene leer el historial de las versiones por si os pueda interesar algún cambio entre la versión que tenéis instalada y esta 2.71.

Buena proa!  (Los que tenéis barco...   )

[Tehani]

Hay novedades, y con sustancia.
Descubierta nueva cagada de Raymarine en el PGN 129029 de NMEA2000 donde se envía la información más completa y precisa del receptor GPS: GNSS position data.
El campo del importante dato HDOP simplemente está relleno de basura. En concreto contiene el valor FF00, que es  válido, pero es también una barbaridad muy grande.
Simplificando, ese dato indica la calidad de los datos que envía el receptor GPS. Baja calidad se representa con valores altos, y alta calidad con valores del orden de 100cm. Para que os hagais una idea, FF00 en hexadecimal son 62280 centímetros en decimal.

Al grano... Desde hace unos 4-5 años, los dispositivos Ocenav usan ese dato para decidir qué receptor GPS es el más preciso cuando hay varios conectados en el sistema, y si el valor es muy alto, simplemente se ignora ese GPS o GNSS.

Por esa razón, aquellos usuarios que incorporan un Axiom o Element de Raymarine en su barco han tenido problemas ya enquistados, y se han resuelto incorporando un GPS chino conectado a una entrada NMEA0183 (Triste pero efectivo).
Lo que ocurre que esos problemas yo siempre los había atribuído a la baja sensibilidad declarada de los receptores GPS de Raymarine (otro desastre de esa marca). No llegué a sospechar que pudiera coexistir una pifia de ese calibre.

Hoy he procedido a analizar capturas N2k de ese PGN 129029 (Sentencia), extraídas de un Axiom, de un par de Garmin, y de la salida de un gateway Yacht Devices.
Para comprobar a fondo, el análisis se ha hecho en ficheros de gran duración viendo que únicamente Garnin suministra datos fiables, Raymarine envía siempre ese FF00, y Yacht Devices no envía ese dato (campo vacío). Es muy probable que los MFD de Simrad y B&G también suministren correctamente esa info puesto que ningún usuario con esos equipos ha reportado problema alguno.

A partir de hoy, la selección como GPS más preciso se hará comparando la cantidad de satétites que esté usando cada uno para el cálculo de la posición. Este dato también está contenido en ese PGN y lo envían todos los fabricantes, tanto en N2k, como NMEA0183 y Seatalk.
El cambio afectará a los dispositivos Ocenav ATM105A1N, ATM105A3 y Rem072F. Adjunto la
actualización 2.80 en este mismo post. También la colgaré en la web de Ocenav.