Calificación:
  • 1 voto(s) - 5 Media
  • 1
  • 2
  • 3
  • 4
  • 5

MiniPC, Raspberry, OpenCPN,WIFI , AIS, OceanNav. Opiniones

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á...
Responder
Agradecido por:

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...
Responder
Agradecido por: Juan Solis, Martin Iut, Panafunk

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
Responder
Agradecido por:


Posibles temas similares…
Tema / Autor Respuestas Vistas Último mensaje

Salto de foro:


Usuarios navegando en este tema: 2 invitado(s)