Estoy viendo como reorganizo la electrónica en mi barco y creo que ya he dado con mi esquema ideal.

Actualmente tengo lo siguiente:
- Raymarime ST40 bidata y viento (seatalk)
- AP ST6000+ con unidad Type 100 (seatalk y entrada/salida nmea 0183, según el manual convierte de seatalk a nmea)
- VHF Navicom RT-650 (1 entrada/salida nmea 0183 de baja velocidad, 1 salida nmea 0183 de alta velocidad para AIS)
- Navtex Furuno NX-300 (1 entrada nmea 0183 para obtener posición)
- GPS Valsat 02L (1 salida nmea 0183). Ahora mismo no obtiene la posición y creo que es por la antena con cable coaxial del exterior.
- MDF Furuno Navnet vx2 + Antena GPS Furuno conectada a él.

Los problemas que tengo son los siguientes:
- Toda la red seatalk esta conectada entre sí y no tiene conexión con nada más.
- El MDF Furuno esta conectado a la VHF para ver los blancos AIS (esto funciona) pero no al piloto (se podría conectar)
- La VHF y el Navtex recibían la posición GPS del Valsat, pero ahora como no va, no tengo DSC en la radio.

Aprovechando que tengo una raspberry, un GPS usb y un RS-422 usb me he planteado reorganizar la electrónica de la siguiente manera:

   

Me faltaría por comprar lo siguiente:
- Una pantalla HDMI pequeña para mostrar información conectada a la raspberry (esto lo puedo hacer en el futuro)
- El radar (también lo instalaría durante el invierno que viene)
- Un RS-422 más
- Tablet, aunque ahora mismo tengo un teléfono rugged que me valdría.

El Furuno MDF de momento lo dejaría ya que no me molesta, me faltaría ver si puedo conectarlo a la raspberry para ver si puedo hacer que envíe sus datos a signalk para enviar sentencias de rumbo al piloto y/o para backup de gps, pero de momento probablemente no lo haría. Además es posible que en el futuro lo eliminase y añadiese un B&G Vulcan para el exterior y en previsión de que haya alguna cosa que no pueda hacer con el radar HALO desde opencpn.

¿El esquema estaría bien o hay algo que es incorrecto y/o mejorable?

Más o menos tienes una elctronoca muy parecía a la mía. 
Pero la nmea183 del type100 solo es de entrada. Así que olvidate de que te traduzca seatalk.
La única solución es un convertidor seatalk a nmea183 y al revés.
Yo tengo uno nacional de ocenav que además es multiplexor y traduce también a nmea2000. 

Lo produce tehani.  También tiene un sistema que hace algo parecido pero con menos prestaciones.

Mi intención era esa, pero el otro día revisando todos los dispositivos vi que el type 100 tiene entrada y salida nmea y en el manual dice que convierte, pero no lo he probado.

Lo probaré y ya veo que hago. 

TIENES ais emisor receptor??? si no es asi esa seria una de las primeras adjudicaciones

(20-08-2022, 07:01 AM)josefu escribió:  Mi intención era esa, pero el otro día revisando todos los dispositivos vi que el type 100 tiene entrada y salida nmea y en el manual dice que convierte, pero no lo he probado.

Lo probaré y ya veo que hago. 

He estado leyendo el manual del type 100. Lo que dice es que salen sentencias de GPS, navegación y de rumbo de piloto (no es heading).
Es decir, NO salen datos de viento, ni compás, ni corredera / log, ni profundidad ni temperatura del agua. Total: ningún dato de sensores.
No es exactamente lo que dice Gypsy, pero para el caso, es lo mismo. No sirve para nada esa salida.

(20-08-2022, 09:31 PM)Tehani escribió:  He estado leyendo el manual del type 100. Lo que dice es que salen sentencias de GPS, navegación y de rumbo de piloto (no es heading).
Es decir, NO salen datos de viento, ni compás, ni corredera / log, ni profundidad ni temperatura del agua. Total: ningún dato de sensores.
No es exactamente lo que dice Gypsy, pero para el caso, es lo mismo. No sirve para nada esa salida.

Gracias por aclararlo. Algo recordaba de que no se podia utilizar para traducir tdas las sentencias de SeaTalk. Ahora de vuelta en casa he visto el manual y solo salen 9 sentencias NMEA183 qe son: XTE, BWC, GLL, HDG,HDM,HDT, HSC, VTG, y GLL.

O sea que faltan todas las de viento y tambien la STW. Asi que para un velero no sirve

Después de pegarle una vuelta e incorporando el Rem072F de ocenav, el esquema quedaría así:

   

Ahora mismo la VHF me introduce los blancos AIS y no tengo emisor, si en el futuro añado uno, cambiaría la conexión NMEA que viene de la radio por la que vendría del emisor AIS.

Las conexiones NMEA0183 a través de ethernet no se qué es mejor ¿hacerlas al signalk o al Rem072F? Los datos entiendo que serán los mismos por lo que en principio da igual, no?

Luego tengo una duda:
- Tengo un GPS USB conectado a la raspberry y conectado a signalk
- Tengo signalk y la Rem072F conectados a través de una conexión NMEA0183 TCP/UDP, tanto entrada como salida.
- Tengo el furuno, con su GPS, conectado al Rem072F a través de una entrada/salida NMEA 0183.

Al Rem072F le llegan dos señales GPS y por lo que he leído, él decide cuál es la "buena" y sólo retransmite una en cada momento (¿esto es así?).
¿Tengo un problema en signalk al recibir la posición por el GPS USB y por la conexión NMEA 0183 que viene del Rem072F?
¿Sería mejor enviar la señal GPS del USB directamente al Rem072F del alguna forma y que así sea el multiplexor el que decida cuál es la "buena" y que signalk lo reciba ya filtrado por red?

¿O simplemente es más sencillo tener un sólo GPS y hacer que el GPS furuno no envíe su posición?

(23-08-2022, 09:01 AM)josefu escribió:  Después de pegarle una vuelta e incorporando el Rem072F de ocenav, el esquema quedaría así:



Ahora mismo la VHF me introduce los blancos AIS y no tengo emisor, si en el futuro añado uno, cambiaría la conexión NMEA que viene de la radio por la que vendría del emisor AIS.

Las conexiones NMEA0183 a través de ethernet no se qué es mejor ¿hacerlas al signalk o al Rem072F? Los datos entiendo que serán los mismos por lo que en principio da igual, no?

Luego tengo una duda:
- Tengo un GPS USB conectado a la raspberry y conectado a signalk
- Tengo signalk y la Rem072F conectados a través de una conexión NMEA0183 TCP/UDP, tanto entrada como salida.
- Tengo el furuno, con su GPS, conectado al Rem072F a través de una entrada/salida NMEA 0183.

Al Rem072F le llegan dos señales GPS y por lo que he leído, él decide cuál es la "buena" y sólo retransmite una en cada momento (¿esto es así?).
¿Tengo un problema en signalk al recibir la posición por el GPS USB y por la conexión NMEA 0183 que viene del Rem072F?
¿Sería mejor enviar la señal GPS del USB directamente al Rem072F del alguna forma y que así sea el multiplexor el que decida cuál es la "buena" y que signalk lo reciba ya filtrado por red?

¿O simplemente es más sencillo tener un sólo GPS y hacer que el GPS furuno no envíe su posición?

Creo que algunos conceptos no los tienes claros. En tu configuración  SignalK solo corre en la Raspi. Lo hace OpenPlotter. 
OpenPlotter traduce todo lo que le entra a SignalK. Luego por un plugin de SignalK traduce todas las sentencias a nmea183. 
Si tienes el plugin de nmea2000  se traducirán las sentencias de signalK a nmea2000. 

Esto es si programas las correspondientes entradas y salidas en signalK.

Entonces el Rem072F va a gestionar la red seatalk,  las entradas y salidas nmea183 y la red WiFi con las sentencias nmea183. 

Si tuvieras una red nmea2000  también la gestionaría. 

Es decir que el Rem072F va a leer todas las sentencias de SeaTalk1,  nmea2000,  nmea183,  las va a gestionar, mezclar ordenar y las va a sacar por nmea183,  nmea2000  y SeaTalk1. 

Como veo que comunicas raspi con rem072F por wifi , también verá las sentencias de GPS que le entran a la raspi. Es decir, no es necesario que conectas el gps al Rem072F. Aparte de que no podrías.

Como comento Tehani el Rem072F elegirá la mejor señal.

Respecto a tu última pregunta es mas sencillo tener un solo GPS conectado al Rem072F.

Lo mejor es que la VHF y el AIS tengan su propio GPS.
Y uno conectado al Rem072F bien por nmea183 o nmea2000.
Yo me compre una seta de nmea2000

(23-08-2022, 11:55 AM)gypsylyon escribió:  Creo que algunos conceptos no los tienes claros. En tu configuración  SignalK solo corre en la Raspi. Lo hace OpenPlotter. 
OpenPlotter traduce todo lo que le entra a SignalK. Luego por un plugin de SignalK traduce todas las sentencias a nmea183. 
Si tienes el plugin de nmea2000  se traducirán las sentencias de signalK a nmea2000. 

Esto es si programas las correspondientes entradas y salidas en signalK.

Entonces el Rem072F va a gestionar la red seatalk,  las entradas y salidas nmea183 y la red WiFi con las sentencias nmea183. 

Si tuvieras una red nmea2000  también la gestionaría. 

Es decir que el Rem072F va a leer todas las sentencias de SeaTalk1,  nmea2000,  nmea183,  las va a gestionar, mezclar ordenar y las va a sacar por nmea183,  nmea2000  y SeaTalk1. 

Como veo que comunicas raspi con rem072F por wifi , también verá las sentencias de GPS que lecentran a la raspi.

Como comento Tehani el Rem072F elegirá la mejor señal

Y por mucho que le pese a Pinguino, olvídate de SignalK.   Pinguino...
En tu caso no lo necesitarás para nada y lo único que conseguirás serán berrinches porque no es fácil de configurar.
Me edito: Si algún día quieres jugar con SignalK y ver sus relojes en la tablet o en tu casa, podrás hacerlo configurando OpenPlotter. Pero no te líes con esto desde el principio...
Aquí puedes leer una discusión sobre los pros y contras de SignalK: https://www.cruisersforum.com/forums/f13...ost3594574
Por otra parte, Navionics sólo acepta datos NMEA0183. Está bien la cartografía de esta gente, pero la app Boating es una KK.

Unos detalles más:
- Si usas un pincho GPS USB, piensa que estará conectado a la Raspi. Si la desconectas, adiós datos GPS.
- Y por esa misma razón, OpenCPN deberá ser quien decida qué datos GPS usará, ya que este pincho no estará conectado al Rem072 sino a la Raspi.
- Si algún día pones un Transpondedor AIS, sería él quien suministraría datos GPS de respaldo al Rem072, y por lo tanto, a todo el sistema. Con un pincho USB en la Raspi no funciona así (Hay que reconfigurar OpenCPN y podrías liarte).
- Si quieres un consejo, haz que el sistema completo sea independiente de la Raspi. Es decir, la Raspi sólo conectada por USB o por WiFi al Rem072. Y todo lo demás conectado sólo al Rem072. De esta manera, si la Raspi se cuelga, se recalienta, o lo que sea, no se quedará colgado todo.
- El Rem072, y todos los Ocenav, tienen un sistema de protección anti-cuelgues. De tal manera que si se produce alguno, reaccionan en menos de 50 milisegundos, y siguen funcionando como si tal cosa (El usuario ni se entera).

Mi configuración es asi. La central ocenav gestiona todas las entradas y salidas de losctres estándares (nmea183,  nmea2000  y seatalk).
La raspi lee los datos de la central ocenav como un periférico. Solo manda las sentencias para el track del autopiloto las cuales también las gestiona la central ocenav, pasandolas de nmea183 a seatalk.

Cuando era la raspi la que gestionaba las entradas y salidas no tenia más que problemas.  Así me he ahorrado unos cuantos convertidores de nmea183 a usb para quecla raspi pudiera leer datos.  
Con la central de ocenav funciona ininterrumpidamente sin problemas.

Esta configuración ofrece otra ventaja, que tanto la central de ocenav como la raspi funcionan como punto de acceso por WiFi.  De esta manera tengo un sistema redundante para otros aparatos como mobil o portátil.

Ya he comunicado en otro hilo mis problemas con la nueva Version de OpenPlotter para la Raspy. Se me colgaba en el momento más inoportuno. Algo que con el portatil via wifi podía solventar.

Mi intención es usar opencpn desde un portátil, no desde la raspberry.

En la raspberry he instalado un openplotter pero no usaré opencpn (instalé openplotter por facilidad ya que tiene todo el software que quiero), además tendrá conectados algunos sensores (esto es más para "jugar") y una pantalla pequeña donde se abrirá directamente al arrancar un navegador a pantalla completa con el KIP (necesita signalk) y así tener en el interior una pantalla tipo B&G Triton/Garmin GMI20/Raymarine i70s.

Quería aprovechar el gps usb que tengo, pero probablemente no valga la pena ya que complica el escenario.

También quiero configurar paneles de datos con grafana y demás para almacenar históricos, esto también es más por "jugar" que por necesidad.

Signalk puede hacer la misma función de multiplexor de datos que hace el rem072f, tengo claro que habrá diferencias de implementación y que el rem072f tiene cosas mucho más afinadas.

Debido a el rem072f ya me da una serie de funcionalidades llave en mano, buena reputación por el anterior gateway, cercanía con el creador y que ya tiene las interfaces físicas necesarias para mi (seatalk y nmea0183), después del replanteamiento, lo lógico sería dejar que él sea el que mezcle los datos de todos los canales.

Opencpn en el portátil estaría conectado al rem072f a través de red.

Signalk en la raspberry se alimentaría de los datos que mezcla el rem072f a través de una conexión de red y así estarían disponibles para los elementos que se conecten por signalk.

El conectar la salida de signalk con la el rem072f es por si hay algún evento que se genere en la raspberry (niveles de depósito, temperaturas, etc) que puedan ser distribuidos a otros dispositivos, como por ejemplo plotter con nmea2000. Como es algo que ahora mismo no tengo, plantearé el signalk como cliente del rem072f y ya esta. Además siempre podré conectarlo filtrándolo todo menos lo que no recibe el rem072f a través de sus conexiones.

Yo tengo claro que signalk ha venido a facilitar el desarrollo de aplicaciones en un mundo cerrado como es el de naútica, utilizar REST y JSON como core de conectividad hace que muchos desarrolladores puedan crear aplicaciones de forma mucho más sencilla y con una abstracción que hasta ahora no era posible. ¿consume más recursos? seguro, gracias a dios eso hoy en día no es un problema.

Si se montasen gateways multiplexores basados en signalk, con los filtros y cálculos que hace Tehani en sus dispositivos y creciesen el número de apps basadas en signalk, al final los fabricantes tradicionales acabarían implementando el protocolo y eso sería muy bueno para todos ya que pasaríamos de un protocolo cerrado a uno abierto.

Seguro que hay cosas mejorables en signalk y hay algunas que a mi no me gustan, pero sinceramente, creo que el futuro va por ahí.

(23-08-2022, 02:57 PM)josefu escribió:  Mi intención es usar opencpn desde un portátil, no desde la raspberry.

En la raspberry he instalado un openplotter pero no usaré opencpn (instalé openplotter por facilidad ya que tiene todo el software que quiero), además tendrá conectados algunos sensores (esto es más para "jugar") y una pantalla pequeña donde se abrirá directamente al arrancar un navegador a pantalla completa con el KIP (necesita signalk) y así tener en el interior una pantalla tipo B&G Triton/Garmin GMI20/Raymarine i70s.

Quería aprovechar el gps usb que tengo, pero probablemente no valga la pena ya que complica el escenario.

También quiero configurar paneles de datos con grafana y demás para almacenar históricos, esto también es más por "jugar" que por necesidad.

Signalk puede hacer la misma función de multiplexor de datos que hace el rem072f, tengo claro que habrá diferencias de implementación y que el rem072f tiene cosas mucho más afinadas.

Debido a el rem072f ya me da una serie de funcionalidades llave en mano, buena reputación por el anterior gateway, cercanía con el creador y que ya tiene las interfaces físicas necesarias para mi (seatalk y nmea0183), después del replanteamiento, lo lógico sería dejar que él sea el que mezcle los datos de todos los canales.

Opencpn en el portátil estaría conectado al rem072f a través de red.

Signalk en la raspberry se alimentaría de los datos que mezcla el rem072f a través de una conexión de red y así estarían disponibles para los elementos que se conecten por signalk.

El conectar la salida de signalk con la el rem072f es por si hay algún evento que se genere en la raspberry (niveles de depósito, temperaturas, etc) que puedan ser distribuidos a otros dispositivos, como por ejemplo plotter con nmea2000. Como es algo que ahora mismo no tengo, plantearé el signalk como cliente del rem072f y ya esta. Además siempre podré conectarlo filtrándolo todo menos lo que no recibe el rem072f a través de sus conexiones.

Yo tengo claro que signalk ha venido a facilitar el desarrollo de aplicaciones en un mundo cerrado como es el de naútica, utilizar REST y JSON como core de conectividad hace que muchos desarrolladores puedan crear aplicaciones de forma mucho más sencilla y con una abstracción que hasta ahora no era posible. ¿consume más recursos? seguro, gracias a dios eso hoy en día no es un problema.

Si se montasen gateways multiplexores basados en signalk, con los filtros y cálculos que hace Tehani en sus dispositivos y creciesen el número de apps basadas en signalk, al final los fabricantes tradicionales acabarían implementando el protocolo y eso sería muy bueno para todos ya que pasaríamos de un protocolo cerrado a uno abierto.

Seguro que hay cosas mejorables en signalk y hay algunas que a mi no me gustan, pero sinceramente, creo que el futuro va por ahí.

No todo es oro lo que reduce. Signal K ocupa mucha capacidad de la raspberry y hay quecdedicarle muchas horas que se las quitaras de la navegación.

SignalK no puedes conectarla con la Rem072F , ya que la Rem072F no lee signalk. Solo lo puedes hacer por la traducción que el plugin de signalk hace a nmea183.  Y no todas las sentencias de signalk se pueden traducir a nmea183. 
Nmea2000 tiene más sentencias pero ahora no te puedo decir que sentencias de signal k sectrafucen a nmea2000. 

Resumiendo, signal k Solo esta en openplotter.

(23-08-2022, 04:14 PM)gypsylyon escribió:  No todo es oro lo que reduce. Signal K ocupa mucha capacidad de la raspberry y hay quecdedicarle muchas horas que se las quitaras de la navegación.

SignalK no puedes conectarla con la Rem072F , ya que la Rem072F no lee signalk. Solo lo puedes hacer por la traducción que el plugin de signalk hace a nmea183.  Y no todas las sentencias de signalk se pueden traducir a nmea183. 
Nmea2000 tiene más sentencias pero ahora no te puedo decir que sentencias de signal k sectrafucen a nmea2000. 

Resumiendo, signal k Solo esta en openplotter.

Si, todo eso lo tengo claro.

Lo que comentaba es alimentar signalk con los datos mezclados del Rem072f (entrada nmea a signalk) y por otra parte enviar las sentencias que puedan ser traducidas a los protocolos nmea 0183 y/o 2000 (signalk enviando las sentencias propias generadas en la raspberry que puedan ser de utilidad en las redes nmea).

Para eso no necesitas ni raspberry ni signalK. Y como tampoco la vas a usar como plotter con más razón.
Con el rem072f te basta. Al final y al cabo el rem072f es el que va a mezclar y unificar todas las sentencias. A la raspberry solo le entraran las sentencias del rem072f, o sea que no va generar ninguna nueva.
A no ser quecutilices la raspi para conectarle otros dispositivos que se puedan leer con signalk. Por ejemplo algun sensor de presión y temperatura por i2c, o convertidores AD por i2c o SPI para leer el nivel de los tanques.
Aunque hoy en día tienes sistemas que te leen señales analógicas y las traducen a nmea2000 que las puedes conectar al Rem072F 

Por otra parte los gráficos que genereres con Grafena o con sognalK, te los vas a tener que currar.  Bajo mi opinión es algo complicado e inadecuado para el barco. Y solo con un tuchscreen sin teclado o ratón todavía más complicado.

En lo de jugar con la raspi , aquí es la única utilidad que le veo.

Tengo en casa una placa GY-91 (IMU MPU9250 y barómetro BMP280), algún sensor de temperatura y cosas por el estilo. Mi intención es ir añadiendo cosas poco a poco.

Respecto al grafana, lo utilizo en mi día a día para monitorizar sistemas. Éste tipo de herramientas son útiles para ver por ejemplo la tendencia del viento real, temperatura, presión atmosférica, consumo de baterías, etc. Además, tener esta información guardada te puede valer para lanzar alarmas.
El problema de estos software's es que son casi una hoja en blanco y normalmente es abrumador empezar con ellos.

Como he dicho, es más por cacharrear que uso real. En mis navegaciones actuales no son necesarios tantos datos.

Respecto a la pantalla, la intención es que sea sólo de información, es decir, no es para tocarla, es para que esté en marcha en la mesa de cartas mostrando los datos de viento, sog, gps, etc.

Opencpn manejarlo de forma táctil es un suplicio (aunque se puede), por lo que sólo me planteo usarlo con un ordenador completo (un portátil en mi caso). Para revisar los datos de grafana, lo ideal es verlo con un móvil/tablet o con un pc.

Conforme vaya montando cosas las iré mostrando, si luego queda un churro de sistema, pues lo desmontaremos.