[Tehani]

Por favor, explícalo un poco más.
¿Es para mantener ese ángulo al viento con objeto de bajar mayor, pero con el motor en marcha?.
Si no hay arrancada, ¿No te parece peligroso?.
Si es para parar un velero sin usar motor, la mejor forma es acuartelar el génova, no dirigir la proa al viento porque eso sería del todo inestable.
En algunos casos, como por ejemplo en los barcos con mayor de sables verticales enrrollable en el palo, conviene enrrollar con un pequeño ángulo de manera que los sables que están dispuestos en una cara de la vela, no rocen con el perfil de entrada al palo. También en ese tipo de aparejo, a veces es mejor enrrollar con viento de popa porque ayuda a entrar la vela.

Otro asunto peludo es el riesgo de lanzar un producto que pueda tomar decisiones de gobierno por su cuenta. Casi seguro que no sería homologable, o para que lo fuera, se le exigieran montones de pruebas por parte de una empresa de certificación. Una pasta, y además un contrato de seguro extra.

En fín, que no veo clara la cosa, y que le sirva a todo el mundo...
Pero de todas formas, espero que expongas los objetivos de esa función.

PD: ¿Ya tienes instalado algún dispositivo Ocenav?. Si es así, ¿cuál de ellos?. Lo digo porque probablemente sólo el ATM105 reúne las características para poderlo hacer (Sin responsabilidad por mi parte ante lo que pueda pasar en ese modo de funcionamiento...).

[aspen]

Oks Tehani lo desarrollo un poco.

Tengo o mejor "disfruto" del Rem072-F y la pregunta te la lanzo dentro del tema "Nuevo gateway y control remoto. Rem072F". Nos va de miedo para enlazar la electrónica Raymarine NG (equipo de viento, sonda) con el piloto ST2000 y la Raspberry con OpenPlotter.
En nuestro velero (un modesto 30 pies con más de 30 años a las espaldas) a la hora de bajar la mayor ponemos el motor a revoluciones bajas, buscamos proa al viento y la bajamos. Pude ocurrir que el caña se despiste porque no está 100% pendiente y se le vaya un poco de ángulo con lo que los patines ya no deslizan bien y los sables se acaban enganchando con el lazy complicandole la existencia al tripulante que va al palo a ayudar en la maniobra.
El piloto automático ST2000 tiene la posibilidad de virar 100º a estribor o babor pulsando a la vez -1 -10, o +1 +10, de fábrica; también la opción de mantener un rumbo con el viento aparente que el usuario decide pulsando a la vez los botones  AUTO + StandBy y por eso no entiendo muy bien lo que comentas de "Otro asunto peludo es el riesgo de lanzar un producto que pueda tomar decisiones de gobierno por su cuenta" ..... ya, pero eso es justo lo que hace un piloto automático!!!!!.

Por eso, y más aún en un velero el rumbo "Proa al viento" no es algo anormal de buscar y si el piloto lo hace y LO MANTIENE vendría de coña para por ejemplo bajar la mayor.

[Minhoca]

Hola, eso q pides es el modo piloto de viento lo q pasa es q usado a motor y con el viento a 0 grados, no?

[Tehani]

Bueno bueno, muchas cosas habría que explicar aquí. Lo haré de forma telegrafica para no enrrollarme mucho:
1) Cuando hay muy poca arrancada, los movimientos de timón deben ser muy amplios para que se note la respuesta. Eso supondría enviar órdenes al piloto de más de 10 grados contínuamente. (Modo Non Follow Up - NFU-que no tienen los pilotos no profesionales).
2) Cuando se navega en modo viento, los pilotos realizan correcciones del rumbo de referencia cada bastantes segundos y sólo de grado en grado, de tal manera que ese modo no sirve para mantener la proa al viento cuando hay mar formada y/o posibles rachas.
3) Los usuarios de los equipos Ocenav suelen llevar el mando a la base del mástil mientras trabajan en la vela (rizando o arriando). Con eso suele ser suficiente para un control total. Yo lo hacía también, ahora no tengo barco...
Lo que pasa es que el mando del Rem072F no es tan preciso ni rápido realizando cambios de rumbo de más de 1° cada vez. Hay que esperar 0,5 segundos pulsando A o B para que se envíe un -10 o +10, y luego repite la orden cada 0,5 segundo.
4) Los pilotos no toman las decisiones de cambio de rumbo. Sólo lo hacen de forma muy limitada cuando trabajan en modo wind/vane, variando como he dicho sólo de grado en grado, y avisando con un pitido cada vez, y también en modo track cuando hay cambio de segmento de una ruta de varios waypoints, previa autorización / confirmación del patrón. Cuando la variación entre el rumbo original al darle a "vane" y el actual sobrepasa un valor límite "off wind", que es equivalente a "off course" en modo track, de unos 15-20 grados programables en setup, el piloto se pone a pitar como un loco, y deja de realizar correcciones posteriores.

Nota: El modo NFU no usa el compás para funcionar. Viene a ser como llevar el timón a mano dentro de puerto.

[Tehani]

Hola, eso q pides es el modo piloto de viento lo q pasa es q usado a motor y con el viento a 0 grados, no?

Sí, Aspen pide justo eso.

[aspen]

Hola, eso q pides es el modo piloto de viento lo q pasa es q usado a motor y con el viento a 0 grados, no?

Pues tienes toda la razón del mundo, no se me había ocurrido. Lo probaré!!!!  

[Tehani]

Pues tienes toda la razón del mundo, no se me había ocurrido. Lo probaré!!!!  

No creo que funcione como esperas. Lee el punto 2 de mi post anterior. Pero bueno, no habrá riesgo si la prueba la haces con gaseosa... (Poco viento y mar)

De hecho, si aparentemente funciona la prueba no será porque el piloto mantenga el ángulo de viento, sino porque incluso en ese modo wind vane estará usando el fluxgate como referencia principal de rumbo.

[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 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.
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 (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 ese FF00, y Yacht Devices no envía ese dato. 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 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. Adjuntaré la
actualización 1.34 del Rem072F en este mismo post cuando esté a punto.