Pues eso, no hay riesgo para la vida, pero hay urgencia.
Necesito ayuda de alguien que tenga un piloto Simrad o B&G (puede ser AP44 o Triton) con un computador de rumbo NAC-2 o NAC-3.
Parece ser que las últimas versiones de software de los Ocenav han dejado de funcionar con estos pilotos, y no encuentro el problema sin poder hacer pruebas con uno de ellos. Desde luego, no hay riesgo alguno.
Si se ofrece alguien entre Valencia y Almería, le estaría enormemente agradecido.

Para quitar miedos describo de qué pruebas se trata y en qué condiciones:
1- No hace ninguna falta salir a navegar.
2- Me conectaría al bus de comunicación Simnet y con un software de análisis tomaría datos en secuencias cortas de no más de 10-15 segundos cada una.
3- Las secuencias se tomarían al iniciar la electrónica, en estos modos de funcionamiento del piloto: WIND, NO DRIFT, NAV y NON FOLLOW UP (NFU). En modo WIND se tomarían los datos de la orden de virada (TACK).
4- Se probaría un Ocenav ATM105 con control remoto.
5- Tiempo total máximo estimado para las pruebas: No más de 30 minutos, más lo que tardemos en charlar un rato en el bar (Birras pagadas, por supuesto, y alguna cosa más...).

Te sirve 1 nmea2k logger en modo actisense?

Yo tengo 1 nac2

Sí que me sirve, ya que de momento sería útil para establecer diferencias con los que tengo.
Tengo logs de un AC12 y otro en formato actisense que no sé de qué piloto puede ser. Probablemente sea de un AC42.
Pero lo que me falta exactamente es alguno más con los PGN 65305 y 65340. Los AC12/42 envían los dos, pero yo diría que los NAC sólo envían el 65305, que hay que interpretarlo en una secuencia de dos mensajes "single packet" consecutivos.
Desde luego, los AP´s de Simrad son una purria en las comunicaciones. Ni ellos mismos son compatibles entre sí. Y eso está escrito en sus tablas de compatibilidad.
Una versión anterior del ATM105 funcionó interpretando ese PGN 65305, pero con un error en reconocimiento del modo Track. Creo que eso ya lo tengo resuelto.
Eso fue hace casi dos años, y en este tiempo he añadido el control para pilotos Garmin, además del reconocimiento de teclas de los Tritón y AP44 y similares, con objeto de cancelar las alarmas generadas por el sistema de alarmas del ATM.
Como en el start-up de los sistemas N2k, Simnet y StkNG, existen una o varias rondas Iso Address Claim de identificación, yo aprovecho para detectar tipo de piloto y direcciones de los AC,NAV, Triton y AP's dentro de la red. Pero puede ser que eso no sea suficiente o no los pille a tiempo.
Por eso he extendido la detección en la recepción de los PGN propietarios que he mencionado antes: 65305 y 65340.
El problema que tengo es que el piloto NAC-3 (Está en EEUU) no se entera de las órdenes que le envía el ATM, y puede ser por ese problema de detección.

Bueno, me estoy enrrollando. Puedes decirme si puedes capturar más logs?
De momento, si tienes ya uno con NAC-2, de algo me servirá, sobretodo si tiene capturadas órdenes de teclado. (AUTO, NAV, TACK).
También sería muy interesante disponer de uno tomado durante el start-up (arranque), con objeto de comprobar la identificación de los dispositivos.
Gracias.

Bueno, ya he avanzado algo.
El usuario americano me acaba de decir que en el mando Ocenav ve correctamente el modo de trabajo del piloto.
Ahora sé que puedo aprovechar la recepción de esos mensajes para identificarlo y detectar direcciones en el Bus, incluso prescindiendo del Iso Address Claim, pero falta volver a comprobar que las órdenes que yo envío coinciden exactamente. Casi lo tenemos.

https://github.com/jiauka/KeyPadSim

Este es el código del simulador de keypad de piloto que uso y me funciona en el NAc2.

Dime la secuencia que quieres que haga desde 0 y este finde la grabo

(14-03-2024, 10:32 AM)jiauka escribió:  https://github.com/jiauka/KeyPadSim

Este es el código del simulador de keypad de piloto que uso y me funciona en el NAc2.

Dime la secuencia que quieres que haga desde 0 y este finde la grabo

Gracias Jaume, lo analizaré.
Pero parece que por ahí no van los tiros.
He detectado una anomalía en el Iso Address Claim de un posible AP44 en el log que tengo.
Resulta que no se está identificando correctamente según normas de la NMEA.
Una KK. Esá enviando esto: ISO Function: 00, Device Class: 70
ISO Function 00 no corresponde a nada normalizado, y Device Class 70 es "Communication Systems".

Para un Device Class = 70, las posibilidades normalizadas para el campo ISO Function son:
130 Emergency Position Indicating Beacon (EPIRB)
140 Automatic Identification System
150 Digital Selective Calling (DSC)
160 Data Receiver
170 Satellite
180 Radio-Telephone (MF/HF)
Ninguna de ellas es 00, y por supuesto, ninguna de ellas tiene que ver con un teclado de control de piloto.
190 Radio-Telephone (VHF)

PUES NO. Había traspapelado los bits, está bien:
60928,10,255,8,b4,0b,32,e8,00,8c,50,c0 (8c(hex) = 140, 50(hex) / 2 = 40)
ISOClaim 140 = Mode Controller, 40 = Steering Systems.

(14-03-2024, 10:32 AM)jiauka escribió:  https://github.com/jiauka/KeyPadSim

Este es el código del simulador de keypad de piloto que uso y me funciona en el NAc2.

Dime la secuencia que quieres que haga desde 0 y este finde la grabo

Estoy analizando el código OwnN2K.cpp, y de momento no veo diferencias en el contenido del PGN de teclado (130850). Lo que veo es que no activas todos los modos posibles de estos pilotos, sólo STBY y AUTO y un "MODE" que no sé qué es. También echo en falta el "TACK", que como no pude capturar orden directa en los logs, lo que hago es calcular el ángulo del viento real en ceñida, multiplicándolo por 2 y dando orden de variar esos grados a la banda contraria. Piensa que +1,-1,+10 y -10 son en realidad la misma orden, pero cambiando sentido de giro (0x02 o 0x03) y añadiendo el ángulo a variar en diezmilésimas de radián.

Veo que tomas la dirección (ID) del piloto en los PGN 65480 que no aparece en mis logs, y 65341 que nunca contiene datos útiles en los logs.
Para identificar la ID del piloto, yo usaba su respuesta ISO Address Claim, donde aparece lo que he mencionado antes. Ahora he añadido la identificación en el PGN 65305, que en dos mensajes consecutivos puedes saber si está "engaged" o no, y el modo de funcionamiento: STBY (not engaged), AUTO, WIND, NAV, NO DRIFT y NFU. Y el PGN 65340 mucho más simple, también con esta información con estructura diferente, pero que parece que los NAC no lo envían. De momento, el usuario me dice que estos modos aparecen en el mando de Ocenav, y por lo tanto, están identificados en un NAC-3.

Como no veo diferencias de calado en el envío del PGN 130850 en tu software, ahora voy a revisar con qué ID te identificas en N2K, y si es la misma que usas para enviar órdenes al piloto. En mi caso, estoy suplantando la ID del "Mode Controller" usando su misma ID al enviar. Veremos, sigo investigando...

El "Mode" lo pone en modo viento.

Tema track y No drift, como nunca los uso, ni los he puesto

La id, el la del teclado b&g triton 2
https://www.bandg.com/bg/type/autopilots...ontroller/

Piensa que lo hice en 1 par de tardes y pensando en que funcionase en mi barco, está muy lejos de ser algo ,digamos, "industrializable".

Pero es 100% operativo en mi NAc-2 y los tritones 2.

(14-03-2024, 01:37 PM)jiauka escribió:  El "Mode" lo pone en modo viento.

Tema track y No drift, como nunca los uso, ni los he puesto

La id, el la del teclado b&g triton 2
https://www.bandg.com/bg/type/autopilots...ontroller/

Piensa que lo hice en 1 par de tardes y pensando en que funcionase en mi barco, está muy lejos de ser algo ,digamos, "industrializable".

Pero es 100% operativo en mi NAc-2 y los tritones 2.

La librería de Timo Lappalainen asigna y gestiona los cambios de ID en ISO Address Claim. Por eso piensas que los tritón tienen ID propia.
Lo que resulta curioso es que el piloto trague bien tu estructura SetProductInformation con Manufacturer's product code = 381 (B&G), y luego el PGN 130850 se lo mandes con Manufacturer's product code = 1857 (Simrad) en los dos primeros bytes de datos. Cosas de Simrad, supongo...
Bueno, lo dejo como está porque el uso de la misma ID del keypad de Simrad / B&G ya me funcionó en su día, y no estoy dispuesto a crear un SetProductInformation alternativo identificándome en N2k como una de esa marcas (porque eso sí podría ser delictivo si no es exclusivamente para uso personal como haces tú).

No tengo piloto para enchufar el Ocenav, pero voy a simular que lo he detectado y comprobaré que el envío de las órdenes de teclado funcionan y los mensajes tienen el contenido correcto.
Gracias de todos modos.

Lo dicho, si quieres 1 log, dime la secuencia y si lo quieres binario o ASCII, este finde estaré por el barco.

(15-03-2024, 12:10 AM)jiauka escribió:  Lo dicho, si quieres 1 log, dime la secuencia y si lo quieres binario o ASCII, este finde estaré por el barco.

Gracias,
No estaría mal hacer un log en el start-up para ver cómo se identifican los equipos. Veremos si los Triton dicen que son B&G o Simrad (Eso tiene un poco de morbo...)
En principio tenía una duda con la identificación del modo track (NAV) y con la orden TACK en modo viento. Pero el modo NAV sólo funcionará si el MFD tiene una ruta o waypoint activo. Intenta que no te salgan sarpullidos por tu alergia a ese modo...  

Sabes si TACK funciona también en el modo AUTO?. En los antiguos pilotos de Raymarine funciona, aunque no me gusta.
En el caso de los Simrad, el mismo Ocenav permite el TACK sólo en modo WIND, y sólo de ceñida (no JIBE), pero si me dices que también lo hace en AUTO, le quito esa restricción.

Prefiero los logs en ASCII, en formato actisense mejor porque los números de PGN los ponen en decimal.
Y está muy bien tener uno o varios logs de los NAC porque sólo tengo de AC12 y y AC42. Veríamos qué PGN envían y te podría echar un cable para que tú también identifiques el modo en el que está trabajando el piloto. El rumbo que está siguiendo lo puedes leer en el PGN 127237 (Heading/Track control), que de hecho es lo único que envían en ese PGN, todos los demás campos están vacíos. Raymarine usa uno propietario para eso y Heading/Track control ni lo envían siquiera.

Para que luego digan que sus productos están homologados por la NMEA 

Y otra cosa que seguramente te interesará: El modo NFU representa que sirve para accionar el timón con un joystick, pero es posible que se ponga en ese modo de forma automática si pulsas +1,-1,+10 o -10 cuando el piloto está en STBY.
Aunque no aparezca NFU por ningún lado, los AP de caña de Raymarine lo hacen así para poder mover el brazo y ajustarlo al enganche de la caña.
Pienso que esa característica puede ser muy socorrida si hay problemas con el Gyro porque mantendría fijo el timón.

Bien jodido ha sido detectar el origen del problema. Noche en blanco...
A falta de que prueben la modificación de software en EEUU, la cosa ha sido que este usuario comparte el bus Simnet con el bus SeatalkNG, teniendo el piloto NAC-3, a la vez que tiene instrumentos i60 o similares.
Los i60 se autoidentifican como "General Instument" en la red SeatalkNG.
Los p70 de Raymarine (displays de control de piloto), se identifican en la red SeatalkNG / NMEA2000 también como "General Instrument", y eso parece que está confundiendo al ATM105, ya que a la vez, el keypad del piloto (AP44) se está identificando como "AP Mode Controller". La solución que he aplicado ha sido priorizar la identificación del piloto NAC-3, Evolution o Reactor, y después validar la identificación del instrumento de control, sea Mode controller o General Instrument.
Vaya lío, no?