Foro Navegantes

Hola, por mi encantando. 
Si te viene bien, cuenta con un barco de 9m con caña en la Ría de Vigo.

Un saludo

(09-10-2025, 07:25 AM)Minhoca escribió: [ -> ]Hola, por mi encantando. 
Si te viene bien, cuenta con un barco de 9m con caña en la Ría de Vigo.

Un saludo

Gracias, tomo nota, pero como estás muy lejos, no me va bien para la primera fase de las pruebas porque tengo que estar en persona.

Parece que este STE300 ya está funcionando correctamente, sólo a falta de consolidar algunos ajustes automáticos y de usuario.
Para los ajustes de usuario me basé en los de Raymarine de toda la vida, pero son modificables automáticamente en función de la velocidad del barco y a otros factores como velocidad de rotación, escora, cabeceo y velocidad del viento cuando se selecciona el modo "aprendizaje" o AutoLEARN.
Como espero obtener consejo, primero describiré lo que está hecho en dos grandes secciones. Una sobre esos ajustes, y otra sobre el comportamiento del piloto ante diversas situaciones más o menos probables y en los diferentes modos de funcionamiento: AUTO, NON FOLLOW UP, NODRIFT, WIND/VANE y TRACK/NAV.
Después de las explicaciones que iré dando sobre lo que ya está programado, me gustaría obtener vuestra opinión y sugerencias para realizar posibles cambios. Muchas gracias por adelantado.
Para entrar en materia, os presento estas páginas de setup  (Puesta en marcha inicial o Commissioning y ajustes de usuario), accesibles mediante un navegador web en un smartphone o PC.

Esta es la página de Commissioning o puesta en marcha inicial después de la instalación, que para evitar líos sólo se puede acceder pulsando el botón rojo que está en la caja del STE300, mientras se da tensión:

El contenido del primer recuadro es similar a todos los dispositivos Ocenav, donde el usuario puede cambiar el modo de funcionamiento de la WiFi, el nombre y password.
En el segundo recuadro, el instalador selecciona:
- El tipo de embarcación (Vessel Hull Type): Desplazamiento, Motora intraborda, Velero, Fueraborda o Pesquero.
- Tipo de accionamiento (Drive Type): Electromecánico (Lineal o rotativo), Hidráulico de bomba reversible o Hidráulico con bomba de flujo contínuo con electroválvulas.
- Embrague y Optimizador de consumo (Clutch / Bypass Valve): Tipo o Regulación de la potencia consumida por el embrague: NO CLUTCH, 100%, 50%, 25% o 16%
- Sensor de timón (Rudder Sensor): Se indica si está instalado o no un potenciómetro sensor de posición del timón.
- Joystick o Pote para accionamiento NON FOLLOW (Joystick Type): En embarcaciones grandes, el accionamiento del timón siempre está asistido por el motor / bomba del piloto y puede gobernarse con un potenciómetro o joystick. Opciones: NOT Available, Joystick o Potenciómetro (este último desaconsejado).
- Modo Autoajuste (Learn Enable): SI / NO. Este modo permite que el propio piloto decida si permitir al usuario acciones que pueden ser arriesgadas en ciertas condiciones de viento y mar, así como ajustar la respuesta (zona muerta, velocidad de la pala, potencia, etc) según esas mismas condiciones. Todo esto se irá explicando en los siguientes post.
- Velocidad habitual de la embarcación (Boat Normal Speed Kn): Este dato es necesario si el piloto no está conectado a una corredera o GPS.
- Intensidad máxima admisible del motor/bomba (Drive Current Limit - Amp): Limitación para la protección tanto del motor como de la electrónica ante un posible bloqueo mecánico.
- Tiempo que tarda la pala del timón de extremo a extremo del recorrido (Rudder Limits Time - Seconds). Este tiempo equivale a un recorrido total de la pala de -30º a +30º.
- Alineado del timón (Rudder Alignement +/- 7 deg). Este parámetro facilita la indicación de los 0º de la pala sin tener que recurrir al centrado mecánico del sensor.

SAVE CONFIGURATION: Se guarda esta configuración y para que sea efectiva, el piloto debe reinicializarse (Apagar y encender de nuevo).

NOTA: Por favor, no citéis los mensajes completos porque luego esto se volvería indigerible...

En funcionamiento normal, el piloto presenta esta página cuando el usuario accede a la WiFi y usa un navegador Web cualquiera:

Si no aparece esta página automáticamente, el usuario deberá introducir la IP 45.0.20.1 (U otra si ha sido cambiada) en la barra de direcciones del navegador.

Los ajustes de usuario (Fine Tuning) son muy similares a los de Raymarine de toda la vida:


(Si algún día vendo muchos STE300 en España y Sudamérica , a lo mejor me lanzo a traducir todo esto...)

De momento, lo traduzco aquí:
La respuesta del piloto puede ajustarse mediante nueve parámetros. Seis de ellos permiten al piloto adaptarse a las características de la embarcación.
- Contratimón: (Counter Rudder): Ajuste de la velocidad de reacción a las olas a cambos bruscos de rumbo. Un valor elevado produce una respuesta rápida, pero puede conllevar la inestabilidad.
- Zona muerta (Damping): Impide que el timón se mueva contínuamente con movimientos pequeños. Un valor alto de Damping ahorra energía, pero reduce la precisión en el rumbo.
- Límite de fuera de rumbo (Off Course Limit): Es el ángulo máximo de error de rumbo permitido desde el rumbo inicial al activar los modos automáticos Wind, Track y No Drift. Cuando se supera se dispara una alarma.
- Ángulo de virada (Tack Angle): Es el ángulo preestablecido a variar para las maniobras de TACK (viradas). En Modo WIND/VANE, el cálculo es automático según el ángulo inicial del viento real. Más adelante lo explicaré con el máximo detalle.
- Velocidad máxima de rotación (Max Turn Rate - deg/sec): Velocidad máxima de giro en grados / segundo. Valor por defecto para barcos de recreo: 20 °/seg. Una velocidad permitida demasiado alta durante una maniobra conlleva riesgos. Más adelante explicaré los detalles de cómo funciona.
- Opción de trasluchada (Gybing Option): Selecciona a acción de trasluchada en modo viento: Nunca pemitida, permitida con velocidades bajas de viento, permitida siempre.

Los siguientes ajustes son los más habituales y permiten adaptar la respuesta al estado de la mar, al consumo de energía deseado y la precisión /velocidad en las correcciones de seguimiento del rumbo en los diferentes modos de trabajo.
- Ganancia de timón (Rudder gain): Ajusta la amplitud del movimiento de la pala. Afecta a la velocidad de rotación del barco. El ajuste del usuario sirve como base para el ajuste automático que realiza internamente el piloto y dependerá de la velocidad del barco: A mayor velocidad se requiere un movimiento de menor amplitud del timón. 
- Autoajuste (Autotrim): Tiempo de espera entre ajustes de referencia de rumbo (Ángulo de viento aparente para el modo WIND, COG para el modo NODRIFT y Bearing to Waypoint BRG + XTE para el modo Track/NAV. Es variable también con la velocidad del barco y la del viento: A mayor velocidad, los ajustes son más frecuentes. Funcional en esos modos Track/NAV, Wind/Vane y No Drift.
- Respuesta (Response): Limita la velocidad máxima del motor/bomba para controlar la demanda de energía. Un valor bajo es indicado para mar en calma, un valor alto para mar embravecido. También se autoajusta según el estado de la mar (utilizando el sensor de 9 ejes -> Aceleraciones lineales) a partir del valor introducido por el usuario.

NOTA: Voy a esperar antes de seguir con la descripción profunda por si hay alguna pregunta o sugerencia.

sin palabras 

Hola Jose Luis. Gracias por compartir. Estoy interesado en q desarrolles como has implementado el PID sin feedback del timon, control de la integral y otras estrategias encima del PID para anticiparte a la orzada o detectar el estado del mar y adaptar el control en consecuencia. Tambien ese auto learn, es capaz de ajustar los parametros del pid?
Gracias!

Hola Sergio,
El control PID está establecido con el ángulo de referencia programado al piloto como consigna (BOATDATA.Plt), y la lectura del heading procesado por el gyro como realimentación de ese control (magn):
    int32_t HdgError = ang_subs(BOATDATA.Plt, magn);
Ese HdgError, multiplicado por KP es directamente la parte proporcional de salida, que multiplicada por RudGainF, nos da un equivalente al ángulo que debe aplicarse a la pala. Este RudGainF es el resultado de la ganancia de timón seleccionada por el usuario, corregida con la velocidad del barco. (Como he comentado, a mayor velocidad, menor ángulo de pala).
No hay realimentación del ángulo de timón en ese nivel del servo:
    int32_t i32tmp = (RudGainF * (KP * HdgError + Integral + Differ)) / 20;
    // Rudder limit, RUDDER>:
    ReqPos = RudderLimits(i32tmp);
Este ReqPos (Requested Position) es un equivalente al ángulo de timón solicitado, que en mi caso, lo transformo a Velocidad * Tiempo de motor, o "ticks" totales de PWM.
Para que se entienda, supongamos que el recorrido total de la pala de extremo a extremo tarda 10 segundos, o lo que es lo mismo, 30 grados se recorrerán en 5 segundos.
Como ese tiempo es lo que tarda el motor a tensión PWM máxima (Valor de Timer con factor de ciclo 100% = 511), y el PWM se refresca casa 20mS, tenemos que la cantidad total PWM * tiempo (5 segundos en secciones de período 20mS) será:  511 * 5 * 50(frecuencia) = 127.750 "ticks" totales de centro a extremo.
Si el usuario introduce otro valor en lugar de los 10 segundos de tiempo total de extremo a extremo, los ticks totales se recalculan durante el inicio, y siempre aplicando un margen de seguridad del 95% para evitar golpes en los topes del recorrido de la pala:


La función RudderLimits mencionada comprueba y limita la salida ReqPos a ese valor DistMax.
NOTA: Esas cosas "raras" como (47 * RuddMax) / 100, las hago porque trabajo con enteros, no en punto flotante. (No hace falta matar moscas a cañonazos...)

Como el piloto puede funcionar con o sin sensor de timón, sólo uso el valor analógico para enviar el ángulo al display, y en su defecto, el equivalente en grados de los "ticks" PWM acumulados, sabiendo que ese valor de 127.750 (O lo que se calcule según del tiempo puesto por el usuario) equivale a 30 grados de pala.

Más cosas. Qué pasa con la parte integral y diferencial de esta expresión:
int32_t i32tmp = (RudGainF * (KP * HdgError + Integral + Differ)) / 20;

La parte diferencial (Differ) la calculo con la velocidad de rotación que recibo del Gyro, multiplicada por el coeficiente de contratimón o CounterRudder en inglés (CntRudderC):

    int32_t Differ = -CntRudderC * BOATDATA.TurnRate;
Este CntRudderC está calculado en AP_ParAdjust(void) mencionado en el listado según la constante diferencial y Setup.CntRudder seleccionado por el usuario.
Como la velocidad del motor se irá ajustando según otros parámetros como el estado de la mar y tipo de maniobra, no modifico el factor CntRudderC porque sería redundante ya que el efecto sobre la pala sería el mismo.

La parte integral tiene mucha, pero que mucha miga, y podría decir que aún tendrá más. Como sabemos, el efecto integral es acumulativo, llegando fácilmente a saturar el servo. También ocurre que es muy comprometido resetearlo, y sólo se puede hacer cuando a pala esté en un extremo por el efecto proporcional del PID.
Esta técnica que voy a exponer es un invento que desarrollé hace más de veinte años para otro proyecto del control de posición de los motores de las ópticas de las cámaras de cine profesional. Está adaptada a este uso del piloto. Empezaré por describir el objetivo principal y condiciones de la parte integral del servo:
- El objetivo básico es hacer llegar la pala a la posición solicitada aunque el error de heading sea mínimo, lo que quiere decir que esa parte Integral debe ir incrementándose con el tiempo hasta llegar a accionar el motor.
- Si ese incremento se hace "a la brava" según los cánones Integral = Integral + KI * HdgError, el resultado sería un desastre absoluto y descontrolado.
- Entonces interesa que el "crecimiento" de la parte integral sea progresivo en el tiempo, limitado entre valores máximo(+) y mínimo(-) y que a la vez no haga actuar al motor contínuamente con movimientos pequeños.
- Para que el motor no se active contínuamente tenemos lo que se llama "Zona Muerta" (Damping), que en otros pilotos se compara con ángulo de error de heading, y si el error no supera esa zona (ángulo) el motor no se mueve. En este, la zona muerta no es un ángulo como tal, sino un valor en "Ticks" del PWM, que se compara en la máquina de estados del control del motor:

Ese Umbral de Damping o Zona Muerta también varía a partir del valor introducido por el usuario en el setup según la velocidad del barco y del viento (En modo Wind).

Total, que la parte integral del PID la calculo así:
Los incrementos (incS) dependen de la constante integrativa KI, del tiempo trancurrido entre recepciones de heading, (que normalmente es cada 100mS, pero puede fallar alguna), y del error de rumbo HdgError dividido por 2 para que no crezca tan deprisa, aunque creo que será mejor sustituirlo por la raíz cuadrada del valor absoluto del error, ya veremos cómo se comporta en condiciones reales.
Como podéis ver, hay limitación de ese valor a "IntegralMax", disparándose la alarma de "fuera de rumbo" cuando se supera. (HdgError > 5) quiere decir que el acumulado de la integral sólo se modifica para errores de heading mayores de 0.5 grados. 5 son décimas de grado.

A todo esto, cada vez que el piloto recibe el Heading del gyro por NMEA2000, se reinicia un timer que representa el "tiempo de vida" de ese valor. Si transcurre ese tiempo si recepción de un nuevo dato, el piloto reacciona pasando al modo "NON FOLLOW UP", bloqueando la pala (Manteniendo activo el Clutch), pero sin moverla.
De la misma manera se establece un control de tiempos en recepción de los datos para el GPS (Modos  NO DRIFT y TRACK), para el viento aparente (AWA) en el modo WIND/VANE, y para el navegador (Plotter, OpenCPN) en el modo TRACK/NAV. Las transiciones entre esos modos las iré explicando...

En este post ya colgué el fuente de esa parte del control del piloto: https://foronavegantes.net/thread-1010-p...l#pid75081
Posteriormente he realizado algunos cambios, pero el concepto sigue siendo el mismo. 

Me faltaba contestar a lo de la "anticipación" a la orzada.
Esa idea que venden es puro cuento chino. Es mucho más seguro disponer de un sistema de sensores y procesado con respuesta rápida que un sistema de anticipación por sofisticado que sea.
En este punto me pregunto si como anticipación se refieren a la predicción del heading que se hace matemáticamente con la fusión de los sensores magnetómetro + giróscopo usando los filtros Kalman, Madgwick o Mahoni. (La respuesta del magnetómetro es lenta ante cambios de heading, y se compensa con las lecturas del giróscopo que tiene una respuesta muy rápida).

Sólo describiré una situación que viví hace muchos años para ilustrar un poco eso del "cuento chino":
Volvíamos de noche de una regata de Barcelona a Pollensa, después de haberla hecho con temporal fuerza 9 (Año 2000, para quien quiera investigar).
Estaba yo a la rueda, y un compañero en el palo haciendo no recuerdo qué. De repente, una mole / pared de agua barrió la cubierta y estuvo a punto de volcar el barco. No había señales previas de un oleaje de ese tipo, fue una ola aislada asesina que por poco lanza a mi amigo al mar, si no se hubiera agarrado al palo con todas sus fuerzas. (La bronca que recibí después fue antológica porque el señor pensó que yo podía haber evitado a la bestia sin verla)
En este caso, y en otros muchos donde existe mar cruzada de fondo y viento, ¿Hay alguna forma de adivinar cuándo se va a producir la orzada, y de qué calibre?

La decisión que he adoptado en este piloto STE300 es aplicar el contratimón directamente a la lectura de los giróscopos con un tiempo de cadencia máximo de 100 milisegundos, que es el tiempo que transcurre entre dos mensajes de heading en NMEA2000. Y luego, modificar el nivel de zona muerta según el estado de la mar con el promedio de las lecturas de los acelerómetros (Linear Accelerations), compensados eliminando la gravedad en los tres ejes. Para este fín, me inventé un PGN NMEA2000 propietario de Ocenav que también envía el Gyro GNY115, ya que no existe uno normalizado que envíe esos datos.

Hasta aquí habéis podido ver la relación que hay entre casi todas las opciones en el setup de usuario y el comportamiento del piloto. Las que faltan son aplicables a las maniobras de TACK/GYBE (Virada y trasluchada) y al cambio de segmento de una ruta en modo TRACK. Más adelante explicaré paso a paso esas acciones y el comportamiento al esquivar obstáculo (Dodge).

Pregunta tonta: ¿Cómo se sabe dónde está el timón si no hay sensor?
Partimos del supuesto que cuando se activa un modo automático en el piloto, el timón está a la vía, "o casi".
A partir de ahí, dentro de la máquina de estados controlada por el timer de 20mS, se hace un cálculo a partir del valor de pala solicitado RecPos y el valor acumulado AccuPos:

SpeedReq es el cómputo total de "Ticks" PWM que controlarán el motor en ese ciclo de 20mS, realizado en varias fases o estados según si se parte de motor parado (acelerando), motor en marcha manteniendo velocidad, motor en marcha pero iniciando frenado, o motor en marcha pero con solicitud de inversión.
Existen otras fases intermedias que se consideran en tiempo real dentro de estos 20mS: Motor girando frenando pero con solicitud de aumentar velocidad, tanto en un sentido de giro como en el otro.
Con este procedimiento se consigue suavizar extraordinariamente el funcionamiento del servo, ya que no existen golpes bruscos ni picos salvajes de corriente. Después de muchísimas pruebas, he establecido unas rampas de aceleración y frenado que tardan sólo 120 milisegundos, pero que son suficientes para eliminar esas sobrecorrientes.
Supongo que a muchos os habrá pasado que una batería algo descargada o unos cables no muy gruesos entre piloto y batería, y piloto y brazo son suficientes para que el piloto NO funcione. Con este sistema de aceleración y frenado progresivo se reduce enormemente esa eventualidad, y lo mejor es que resulta del todo imperceptible.

Lo que voy preparando para el "AutoLearn":
Aunque el tipo de barco está seleccionado por el usuario, la verdad es que no es posible aplicar correcciones precisas en los parámetros de "Zona Muerta" y ganancia de timón de forma dinámica, ya que cada uno se comporta de forma muy diferente incluso perteneciendo a un mismo tipo, por ejemplo "Velero".
Por eso, una de las cosas que están pensadas y medio escritas es la evaluación de la velocidad de rotación en maniobra solicitada (Correcciones de rumbo y viradas) con respecto al ángulo de pala y velocidad del barco, de manera que la ganancia de timón de forma permanente en modo automático se ajuste a esa relación.

Está previsto y escrito que el coeficiente de contratimón se ajuste según el oleaje transversal, que calculo por la velocidad promediada de las variaciones de escora (Roll).
Por otra parte, en esa función "AutoLearn", también se evalúa la amplitud del cabeceo para ajustar la potencia del motor del brazo, a partir del parámetro "Response" del setup de usuario.

Y también se hace un seguimiento del ángulo de viento en modo WIND/VANE cuando se navega de aleta, de manera que cuando exista el peligro de una transluchada, el piloto orce automáticamente. Esto tiene mucha, pero mucha miga, y aunque ya esté escrito, no estoy seguro de que lo implemente ya que supondría que el piloto haga maniobras por su cuenta...
(No sé si me ha pasado de la rosca, por favor, paradme y preguntad / criticad / opinad porque creo que me estoy embalando...)

Impresionante el PID, es un verdadero PID industrial.
La modificación que has introducido me recuerda incluso a procesos de Fizzy Logic con continuous learning.
He estado investigando en algoritmos de autolearning utilizados por los autopilotos de para negra que parece que sirven para ajustar su PID según como responda el barco a los movimientos del timon. Esta claro que cada barco tiene una dinámica diferente debida entre otros, a la superficie del timon, inercia del casco, respuesta del actuator, desplazamiento, orza, velocidad y etc. Asi que la idea es que el sistema aprenda la relación correcta entre el angulo del timon y la velocidad de giro real. Para ello cuando el velero va a motor en la fase de calibracion, se inducen movimientos al timon y se registra la respuesta del barco que se mide con el sensor gyrocompas. Así se pueden calcular los parámetros mas idóneos para el PID.
El autopiloto que tengo ahora , el evo200 de raymaryne lleva un algoritmo de continuos learning . Después de instalarlo tras creo que después de recorrer una 100nm, salió un mensaje que decía calibracion terminada.

Hoy he mantenido una interesantísima conversación con Eugeni (Bel Ami, en_transit).
La cosa ha ido más o menos así:
J.L.: Bien, ya sabes que estoy buscando voluntarios, y sobretodo necesito a alguien que navegue, o sea, tú mismo.
Eugeni: Beta tester?. Explica.
J.L.: Mira, yo aprendí mucho observando las reacciones del piloto ante situaciones diversas.
Eugeni: Leí que buscabas a alguien, pero no me dí por aludido. Estamos en Grecia.
J.L.: Tampoco me refería a tí. Lo dije en general.
Entro a saco:
J.L.: Navegas habitualmente en el modo viento del piloto?
Eugeni: Si, sobretodo cuando es larga la travesía, en AUTO (compás) también, pero nunca en modo TRACK/NAV.
J.L.: Si es así, haces alguna vez un TACK / virada en automático?. Esto ya veo que será difícil si no haces regatas...
J.L.: En el diseño del piloto tengo que prever todas las eventualidades posibles en todos los modos de funcionamiento.
J.L.: Esto puede parecer una tontería, pero me ha supuesto mucho trabajo y más que dará.
J.L.: Por ejemplo: Qué tiene que hacer el piloto si navegando en modo WIND/VANE deja de recibir datos de viento?
Eugeni: El Garmin salta automáticamente a modo Rumbo / heading (AUTO) manteniendo su última lectura. (*)
J.L.: En principio, yo hago lo mismo que observaba en el piloto Raymarine, que era más antiguo que tu Garmin. Es decir, siempre navega usando la referencia de Heading como principal, y cada tanto compara el ángulo inicial de viento con el actual y va haciendo las correcciones de referencia de rumbo inicial avisando si son de más de 1 grado.

Añado ahora que inicialmente hice que el piloto tomara la referencia de ángulo de viento real en el momento de seleccionar ese modo de trabajo. Hace unos días la he cambiado por la de viento aparente y eso tiene una razón de peso: Las velas de ajustan al ángulo del aparente, y el modo WIND/VANE sirve para no tener que andar trimando cada dos por tres. Luego, calculo 2 x ángulo de real como variación de heading que hay que hacer en una virada - TACK. Cuando termina la virada, el nuevo ángulo de referencia es 360 - AWA inicial.

J.L. Contesto a (*): Exacto, eso hago yo.
J.L.: Y cómo has podido observar esa reacción en tu piloto? Te ha fallado alguna vez el equipo de viento?
Eugeni: Lo he desconectado por curiosidad. A veces hago experimentos.  ( Sorprendente Eugeni...   )

J.L.: Sabes si tu piloto tiene el modo sin deriva (NO DRIFT)?
Eugeni: Esto no me suena. El Garmin está muy capado, pero el mío no es el último modelo. Sí que tiene el modo TRACK.
J.L: Este modo NO DRIFT consiste en mantener el COG inicial.
Eugeni: En modo AUTO (Rumbo) el barco deriva, y en modo viento aún más.
J.L.:Ya lo creo. La cuestión es que en los diversos modos hay que prever cómo tienen que ser las transiciones cuando fallan los sensores o plotters:
Si en TRACK falla el navegador(Plotter) -> NO DRIFT (Usa sólo el GPS, referencia COG), si falla GPS -> Rumbo (AUTO normal).
En modo viento, pasa a Rumbo (AUTO) como ya hemos dicho.
J.L.: El piloto Raymarine tiene dos alarmas que se activan si la cosa se va de madre: Off Course y Wind Shift.
J.L.: Qué pasa con tu piloto si lo pones en AUTO sin navegar (amarrado o en boya), y pulsas +/-1 o +/-10?
Eugeni: Fuerza la caña hasta el límite y avisa.
J.L.: Llega al extremo sin quejarse?
Eugeni: Si. Sólo cuando llega al límite del recorrido.
J.L: Yo (mi piloto) paro y aviso antes (Alarma Off Course). No hace falta llegar al extremo para saber que la cosa no funciona...
Eugeni: No avisa de que el barco no está reaccionando, no salta ninguna alarma. Lo he probado estado fondeado.
Eugeni: Alguna vez se ha conectado por error porque alguien ha tocado donde no debía.
J.L: Ok, otra pregunta: Qué pasa si en modo WIND/VANE, la velocidad del viento es muy baja, pongamos 1-2 nudos?
J.L.: O si en modo TRACK, el SOG (velocidad GPS) actual es también muy baja?.
Eugeni: Se vuelve tonto, no hay alarma y no cambia de modo. Pero se pueden configurar alarmas de velocidad al margen del piloto.
J.L: El mío cambia a AUTO pero no avisa. (Añado ahora: Las alarmas a las que se refiere Eugeni las genera el propio equipo de viento, y claro, no están asociadas a los modos de funcionamiento del piloto).
J.L.: Si hace falta, haré que avise, pero al final todo son pitos y molestan... Estas cosas pueden suponer un riesgo si no se tratan correctamente.
Eugeni: Eso también es verdad, me sirven si me voy a dormir, pero normalmente me gusta estar atento y hacer yo las correcciones. Cuando navego, prácticamente desactivo todas las alarmas. (Añado ahora: Y muy bien porque eso ayuda a mantener la vigilia al tener el cerebro activo).
J.L.: Mira, he retocado el software. Ya aviso de Wind Shift con una alarma cuando cae el viento o se dejan de recibir datos, además de cambiar a AUTO.
J.L. Muchas gracias por aguantarme.
Eugeni: (que se dirige a Leros al encuentro con Caribdis). Ahora cae el viento, tendré que poner motor. Estamos a 4 millas.

Si no le molesta mucho, seguiré dándole la lata...
Por favor, si algun lector tiene alguna experiencia relacionada, le estaría muy agradecido que la explique.