[gypsylyon]

Dioooos!! Lo tengo! 

 Casi que me da vergüenza contarlo.... Pero una cagada de esas tenía que ser. 

 Pues resulta que el conector de campo que empalme al troncal seatalkng para cambiar a nmea 2000. Uno de los filamentos del cable negro (-) se uqedo fuera del borne, lo cual al apretar y conectar el cable lo apretaba hasta tocar con la regleta del cable central el azul. 

 

 Solucionado esto solucionadas las desconexiones de GPS y tenemos buena señal y el piloto y mando van de lujo. 

 Me di cuenta que la señal GPS es más buena si llevo conectada únicamente la antena que pasa por el ploter. 

 La del AIS desconectada y de respeto. 

 Un millón de gracias Tehani. Si pasas por Valencia o Mallorca avisa te debo una comida! 

 Salut. 

 Por cierto si hubiese comprado el maldito cable fabricado no me habría pasado esto. 

Pues has tenido suerte de que no te haya petado algo.
Pero me alegro que lo tengas. Ahora a relajarse y disfrutar

[Tehani]

Bueno Onilum, pues ahora a disfrutar.
Procura no viciarte demasiado con el mando, y destapa alguna vez el P70. Más que nada, para no perder el hábito de usarlo.
Gypsy ya no tiene solución, está enganchadísimo...

[Tehani]

PD:
Supongo que te falta instalar el cableado del molinete.
Cuanfo lo montes, porfa, cuenta qué tal va el cuentametros de cadena.

[en_transit]

A mi me gusta mucho el mando a distancia del piloto, estoy super adaptado y es como imprescindible.

[gypsylyon]

Bueno Onilum, pues ahora a disfrutar.
Procura no viciarte demasiado con el mando, y destapa alguna vez el P70. Más que nada, para no perder el hábito de usarlo.
Gypsy ya no tiene solución, está enganchadísimo...

El tamaño es perfecto, no pesa nada, usa batería recargable,  o sea nada de pilas . Mucha información de navegación.
Control total del piloto y del molinete.
Mejor imposible.
Como dicen en Suiza Tip-Top

[onilum]

Muy contento!!

 Después de las primeras pruebas y superados los problemas debido a la mala conexión del cable troncal, pudimos hacer prueba navegando, en una pequeña travesía de ida y vuelta de poco menos de 60mn. 
 Durante la ida, las primeras 30mn como comenté fue un calvario, con las dichosas intermitencias de GPS, una vez encontrada la causa y estañados y recolocados los cables solucionamos el problema. 

 La vuelta, compensó los dolores de cabeza de la ida, pudiendo disfrutar de una navegación integra a vela con unas condiciones de viento casi perfectas y jugando con los nuevos componentes. 
 Aún por descubrir cosas como la navegación en modo track entre otras...

 Destacar la comodidad de ir al palo a izar o arriar la mayor y poder aproar el barco perfectamente con el mando. 

 El molinete por el momento no lo conectare, al menos hasta que el mando chino que tengo instalado no diga basta, más que nada porque tengo más ganas de navegar que de pasar los cables. 

 Decir que el receptor GPS que nos vino con el AIS, o tiene algún defecto o es de muy mala calidad, volví a intentar conectarlo, colocado en cubierta sin obstáculos de por medio y seguía fallando, con la del plotter perfecto. 

 

[Tehani]

Voy a explicar un poco lo que parece que está pasando, y que me obliga a publicar una nueva actualización.
De paso, este mensaje servirá para documentar un poco y para proponer una solución, aunque estoy abierto a propuestas.

Por lo visto, hay dos cosas que hacen que el piloto "crea" que hay 2 GPS, cuando el AIS está conectado por NMEA2000.

- Una que ya está solucionada, es consecuencia de que en NMEA2000, el PGN de velocidad de corredera, contiene también un campo con el SOG. Claro, este SOG proviene del GPS conectado a Ocenav.
Y Ocenav genera este PGN automáticamente a partir de la velocidad GPS, cuando nadie envía datos de corredera. Esto se hizo por demanda de usuarios, y se hace "engañando" a los instrumentos de viento para que pudieran calcular el viento real, a pesar de no tener una corredera instalada (como es el caso).
Total, que como el COG/SOG se envía en otro PGN de GPS, y nadie más que un GPS lo puede enviar, puedo dejar el campo SOG vacío del PGN de corredera, dando exclusivamente el STW simulado. Con esto, el piloto no verá ningún dato extraño GPS de otro dispositivo diferente del GPS conectado en NMEA2000.
(Ni sé si me he explicado bien, ni si resulta muy lioso el tema).

[Tehani]

- El otro problema:
Ni los GPS tipo seta, ni los pinchos USB, ni los AIS en general, calculan la declinación.
Normalmente, se necesita un Plotter u OpenCPN para aportar ese dato.
Como sabemos, por haberlo hecho a mano en el curso de PER, necesitamos las coordenadas y la fecha para hacer el cálculo con la carta.
Ocenav calcula la declinación según el último modelo geomagnético mundial, publicado por la NOAA. Y lo hace cuando recibe datos GPS y si ese GPS no la está calculando ni enviando.
También tiene una opción de menú WiFi para forzar ese cálculo si sabemos que la base de datos de declinación del Plotter está desactualizada. Algo útil para plotters antiguos y en otras localizaciones donde la declinación puede ser de más de 25 grados.

Ese dato de declinación es posible que el piloto lo entienda vinculado a un GPS diferente del AIS, y por eso interprete que hay 2 GPS's.
Seguramente tendré que eliminar el cálculo automático.

[Tehani]

Como esto ha llegado al monólogo, empiezo a parecerme a U25...
Problema que se presentará cuando Ocenav no envíe la declinación:
El piloto presentará en pantalla "NO DATA" cuando se intente activar el modo Track (Nav).
Así que lo que creo sería la mejor solución, sería que el AIS se conecte por NMEA0183 a Ocenav.
Así, sólo será Ocenav el que envíe datos GPS por NMEA2000, incluída la declinación.
Así que dejo el cálculo automático.
Siempre ha sido lo mejor para que el usuario no se líe...

[Tehani]

Ya puestos, estoy de celebración, y por eso esta verborrea...
Por fin funciona el USB en el Ocenav ATM115/200.
Ha sido terrible. Unas tres semanas a un promedio de 14 horas diarias.

Y tengo que modificar la placa por una putada del chip. Es lo que hay...

[onilum]

Ya que Tehani ha sacado el tema explicaré un poco de donde viene el asunto... 

 Este domingo pasado volvimos a salir a dar unos bordos y vualá!! Lo que la última navegación había ido de lujo se volvió a torcer y fue un auténtico desastre. Seguíamos con imprecisiones con la señal gps lo que provocaba la desconexión del piloto y el mando continuamente. 

 Manteniendo contactos con Tehani por privado, para no saturar el foro de mensajes sin fundamento, parece que poco a poco vamos sacando cosas en claro. 

 Algún problema de programación como explica Tehani para funcionar con estos nuevos pilotos raymarine, sumado a algunos descuidos en la instalación por mi parte, nos han estado llevando de cabeza en este asunto.

 Por mi parte no puedo más que agradecer a Tehani su interés por ayudarme a solucionar todos estos inconvenientes, en mi trabajo acostumbro a tratar con servicios tecnicos de muchos productos y equipos y pocos pueden presumir de la calidad e implicación en la asistencia técnica que me está ofreciendo José Luis. 

 Así que esperamos en breve tener todo solucionado, estoy ansioso de que todo esté funcionando perfectamente ya que las prestaciones del equipo son espectaculares. 

 Os mantendremos informados! 

Un saludo y de nuevo, gracias Tehani. 

[Tehani]

Bueno, en realidad se trata de un caso particular, y dado que el ATM105 está ya instalado en combinación con bastantes pilotos Evolution, es posible que el origen del problema sea una nueva versión de software del propio piloto. También puede pasar que lo normal es tener instalado un plotter en NMEA2000 cuando se pone un Evolution. En concreto, los plotters de moda son los de B&G porque las pantallas son muy llamativas.
Resulta bastante difícil relacionar si una mejora como la generación de STW o la declinación, que se hicieron hace unos 3-4 años, afecta a ciertas configuraciones de equipos. No es posible ver inmediatamente esa relación causa / efecto. Tampoco resulta fácil investigar un problema a distancia.

Recuerdo un caso problemático en una combinación AIS Garmin y Plotter Garmin. Curioso, no?. La cosa era que los dos estaban entregando datos GPS por NMEA2000, y la antena GPS del AIS estaba bajo cubierta en un barco de aluminio. En aquel momento el ATM105 recogía la posición de los dos GPS, y el resultado era que el icono del barco en OpenCPN saltaba contínuamente unos cuantos metros. Era imposible configurar el AIS para que dejara de enviar cosas de GPS, así que la solución temporal fue conectar el AIS por NMEA01823 al Ocenav. Entonces empecé a buscar una solución, y fue reestructurar el software para seleccionar automáticamente el GPS que diera datos de mejor calidad, analizando el HDOP (Horizontal Dilution of Precission) que entregan los GPS dentro de las sentencias GNSS position: GGA o GNS en el caso de NMEA0183, PGN 129029 en el caso de NMEA2000, y Datagrama 0x57 de Seatalk, aunque este último da una resolución muy baja (1 metro).

También pasa que, por lo general, cuando un usuario instala un Ocenav, luego no se preocupa de actualizar si todo le está funcionando. Hay muchísima gente con versiones de software verdaderamente antiguas. Lo que se dice: no hay feedback para todas las combinaciones de equipos que hay por ahí.

Tanto por el lado Raymarine como por Ocenav, no podemos afirmar que se trate de errores de software. Simplemente, o complejamente, se trata de pulir ciertas incompatibilidades. De esa manera, vamos mejorando el producto para ampliar el rango de aplicación.

En los 8 años de Ocenav se han realizado cientos de retoques en ese sentido. Los últimos importantes han sido para los pilotos Simrad / B&G.

[onilum]

Si finalmente conectamos el AIS por nmea0183, según esta imagen del manual del Camino108 
   

Deberé conectar de la siguiente manera, correcto? 

Camino108 cable GRIS   -----  Ocenav CH3 (I+)

Camino 108 cable AMARILLO -----Ocenav CH3  (I-)

   

Los baudios son 38400, tampoco tendré que cambiar nada, es así? 

Asi tengo ahora mi configuración, no se si al actualizar tendré que cambiar algo, y me diras.

   

[Tehani]

Bueno, vamos a ver si explico los diversos escenarios de combinaciones GPS, y de paso, me organizo la cabeza para establecer un criterio coherente y esperemos que final sobre el tema...

Planteamiento de partida:
1) Un GPS se puede conectar a un Ocenav en cualquier lugar: Un canal cualquiera NMEA0183, Seatalk, NMEA2000 o WiFi.
2) A un dispositivo Ocenav pueden conectarse más de un GPS, en diferentes canales, o incluso más de uno en NMEA2000. Decidirá de forma automática qué GPS entrega mejor calidad de datos basándose en el dato HDOP que se envía con la sentencia GNSS position (GGA, GNS en NMEA0183, PGN129029 en NMEA2000 y datatrama 0x57 en Seatalk).
3) Un receptor GPS que no esté integrado en un Plotter no calcula la declinación, es decir: En NMEA0183, deja vacío el campo de declinación en la sentencia RMC, y si está conectado a NMEA2000, no envía el PGN 127258.
4) Un dispositivo Ocenav no enviará datos GPS por el canal donde esté el GPS activo (De mejor calidad de recepción). Tampoco enviará la declinación por ese canal aunque esté activada la opción del cálculo WMM2020 en el setup. O sea, o no enviará ningún dato GPS, o los enviará todos.
5) Se puede dar el caso de que haya un GPS con baja calidad transmitiendo en NMEA2000. En ese caso, si hay otro GPS mejor conectado en un canal NMEA0183, Ocenav transmitirá esos datos sobre NMEA2000. En este caso, el piloto podrá decidir qué fuente escoger (Por menú de configuración del piloto).
6) Para acabar de liarla, puede darse el caso (Y se dá) de que un receptor GPS sólo envíe la sentencia RMC (Sin datos GNSS y por tanto sin HDOP). En este caso, Ocenav toma esos datos y los traduce a los demás canales si ese GPS es el único instalado en el sistema.

Posible problema que se puede presentar en el caso de Onilum:
- Un receptor GPS integrado en el AIS y conectado a NMEA2000 (sin documentación de lo que está enviando).
- Ese receptor GPS no hace el cálculo de la declinación, y por tanto, no la envía.
- Ese receptor GPS es más nuevo y mejor que el del plotter que está conectado a NMEA0183. Y eso hace que Ocenav esté calladito en NMEA2000, y por tanto tampoco envía la declinación por ese canal. Con lo cual, el piloto no podrá activarse en modo TRACK.
- Claro, este problema no pasa cuando el piloto es un antiguo STxxxx, smartpilot (Seatalk). Ni tampoco pasa cuando el plotter también está conectado a NMEA2000 con un Evolution o NAC2/NAC3 de Simrad.

De momento, la solución que parece más acertada (ya que no se puede configurar el AIS para que no transmita datos GPS por NMEA2000) es conectar tanto AIS como plotter por canales NMEA0183 de Ocenav. Entonces Ocenav decidirá qué GPS es mejor y añadirá la declinación al traducir hacia NMEA2000.
...

¿Cómo se resolvía la selección de GPS activo antes de que empezaran a proliferar GPS / AIS / Plotters conectados todos en NMEA2000?
Se establecía un criterio de prioridad según el canal donde estuviera conectado el GPS. El de máxima prioridad era NMEA2000, luego los canales NMEA0183 1,2 y 3 por ese orden, luego WiFi (OpenCPN enviando datos, por ejemplo) y por último Seatalk por ser obsoleto y con muy baja precisión en los datos debido al propio protocolo seatalk.
Tanto antes como ahora se establece un tiempo de vida de datos válidos de GPS de 5 segundos. Eso quiere decir que si el GPS activo deja de transmitir, al cabo de 5 segundos será validado un segundo GPS que sería el de respaldo.
Desde que se realiza la selección automática de GPS activo, el dispositivo Ocenav puede conmutar dinámicamente de un GPS a otro, según sea su informe de HDOP. Este HDOP es enviado cada segundo por los GPS's.

Bueno, ya véis que no es un tema trivial ni demasiado fácil. Podéis ver que un dispositivo Ocenav hace bastante más que traducir tontamente...

[Tehani]

Final (provisional) de esta historia, de hecho he tocado bien poca cosa, sólo he simplificado, mejorando así la consistencia y fiabilidad.

Definiciones:
- HDOP es el dato de calidad de recepción GPS/GNSS. Es mejor cuanto más bajo. Con buena recepción suele estar por debajo de 1,00. Se toma un valor de 5,00 como límite para determinar si hay que ignorar al GPS en cuestión (como si no estuviera).
- Canal es una conexión del dispositivo Ocenav al mundo exterior. Puede ser cableada (NMEA2000, Seatalk, NMEA0183 (1 a 3) o USB), o inalámbrica: WiFi.

Acciones globales con respecto a los datos GPS/GNSS:
- Supervisión del tiempo de vida de los datos del GPS válido. Este tiempo es de 5 segundos, es decir que al cabo de ese tiempo, Ocenav vuelve a habilitar la salida de datos GPS en todos los canales, y empieza a tomar datos de un posible GPS de respaldo en cualquier canal. Esto es un procedimiento controlado por un timer hardware.
- Si la calidad de datos (HDOP) recibidos por un canal es suficiente, se impide la salida de datos GPS por ese canal.
- Si la calidad de datos (HDOP) es mejor que el del GPS activo, se conmuta la recepción de GPS activo, y los datos de salida hacia los demás canales (excluyendo aquellos con GPS conectado de una mínima calidad) serán los del nuevo GPS validado.

Luego, esta es la forma de proceder en cada canal:

1) NMEA2000:

- Como en el mismo bus NMEA2000 pueden coexistir más de un GPS/GNSS, se tomarán los datos del mejor de ellos, pero no se transmitirán por allí mientras haya uno enviando con una mínima calidad HDOP.
- Si el usuario fuerza la generación de la declinación en el setup de Ocenav, se ignorará el dato de declinación que venga en el PGN 127258 (Magnetic variation). En su lugar, esa declinación será calculada por Ocenav y transmitida a los demás canales cada vez que se reciba el PGN 129029 (GNSS position data), puesto que este PGN contiene los datos necesarios (Coordenadas y fecha) para realizar el cálculo.
-En el caso de que un GPS conectado en NMEA2000 no entregue el dato de declinación (AIS en el caso de Onilum), Ocenav realizará el cálculo, pero no lo enviará a NMEA2000 en el PGN 127258 que es propio de un dispositivo GPS, sino que lo hará incluyendo ese dato en el PGN 127250 (Heading) tanto cuando se envíe el magnético como el verdadero.

2) Canales NMEA0183 (Cableados 1, 2 y 3, USB (REM072/ATM200), y WiFi):
- Algunos dispositivos GPS no envían ni la sentencia GGA ni GNS, siendo estas sentencias las que contienen el dato HDOP. 
En este caso, se tomarán los datos GPS de la sentencia RMC si no existe ningún otro conectado en el sistema, pero serán retransmitidos también por el mismo canal. Si el GPS en cuestión acaba enviando GGA o GNS, se procederá como en el caso general: Bloqueando la salida en ese canal y manteniendo la salida hacia los demás.
- Cuando un GPS sea activo en un canal NMEA0183: Si el usuario fuerza la generación de declinación en el setup de Ocenav o el campo de declinación en la sentencia RMC recibida está vacío, esa declinación será calculada por Ocenav y transmitida a los demás canales NMEA0183 añadiéndola en la sentencia RMC. También generará el PGN 127258 (Magnetic variation) en NMEA2000 y el datagrama 0x99 correspondiente en Seatalk.

3) El viejecito Seatalk:
- Seatalk usa el datagrama 0x57 para transmitir HDOP y el número de satélites usado para el cáculo de la posición. Ocenav explora ese datagrama y valida el GPS si su HDOP es mejor que el mínimo (5m) en el caso de ser el único conectado, o mejor que el de otro posible GPS conectado en el sistema (cosa improbable ya que los GPS Seatalk - Raystar son viejos y de calidad bastante baja). En cualquier caso, si no hay otra cosa, Ocenav enviará esos datos GPS hacia los demás canales.
- De manera análoga a NMEA2000, si el usuario fuerza la generación de la declinación, Ocenav ignorará el datagrama 0x99 (Magnetic variation) que le llegue por Seatalk, y realizará el cálculo de la declinación cuando reciba la fecha y coordenadas (datagramas 0x56 - fecha, 0x50/051 o 0x58 - coordenadas). Esa declinación será transmitida a los demás canales NMEA0183 y 2000 en las sentencias RMC y PGN 127258.