[Tehani]

En definitiva, para poder integrar toda la electrónica, es necesario que el gateway reciba y envíe en todos los protocolos (idiomas).
Y eso, sólo lo hacen 2 gateways en el mundo.

Gypsy podrá hablar de los dos, puesto que compró uno, lo instaló, y desde hace bastante montó el otro.
Por cierto, me regaló el viejo...

[gypsylyon]

Recojo el testigo. 
Primero me compre un miniplex . Con el tuve un montón de problemas porque el firmware estaba contaminado. Estuve hablando con los desarrolladores y conseguí cargarle uno nuevo y funcionó. Pero.... no traducía todas las sentencias. Por ejemplo faltaba la información del ángulo de timon. 
Entonces andábamos en LTP y alguien preguntó si conocíamos el ocenav. No lo conocía pero me informe y me gustó mucho sus prestaciones. Me puse en contacto con su creador, tehani, le explique mis necesidades y me convenció para comprarlo. Le compré la central con el mando .
Funcionó a la primera y desde entonces sigue funcionando. Y ya ha pasado unos 8 años.

Que yo sepa es el único convertidor ( o gateway) que traduce todo con todo y además bidireccional.
Desde entonces es la central de comunicaciones.
El mando una maravilla

[Gralf]

bien, me queda ahora conocer 100% cómo está conexionada la electrónica de mi barco y decidir que quiero hacer, con eso podría plantearos un croquis y sobre ello estudiar la situación y ver opciones.

decir que en mi barco el chartplotter no está en la bañera, cosa que me gustaría y motivo principal de este thread, en bañera tengo los st de seatalk con la corredera, sonda, viento etc.
la idea es ponerme al lado, que tengo un sitio estupenda para situarla, una tablet que por wifi conecte con la raspi para tener un chartplotter decente y sobre todso, a la vista sin tener que entrar al puente.

Si a ello le puedo añadir funcionalidad conectandole, el viento y resto de sensores, pues mejor que mejor.

si escogiera esta opción, vía muiltiplexador, pues igual que este ya incorporara NMEA2000, parece que sería una estupenda manera de en un futuro próximo conectar nueva electrónica.

[josefu]

En definitiva, una estructura de datos como NMEA2000 es encapsulable y exportable "hacia arriba" usando otros protocolos y seguridad de red.
Los paquetes SignalK, donde apenas un 10% del contenido es información útil, no es exportable hacia el entorno de los sensores, piloto, etc. Y tampoco resulta fiable.

Si lo que te molesta es la verbosidad del protocolo, para eso hay soluciones como protobuf.

En electrónica marina a día de hoy el estándar para los fabricantes es  nmea 2000 (canbus), pero ya todos o casi todos los plotters y otros equipos tiene wifi o ethernet. Un chip wifi o ethernet es más barato que uno de canbus simplemente por la escala de fabricación.

Tienes una tecnología de conexión barata (ethernet), en la que no vas a tener problemas de ancho de banda y a la que se pueden conectar también nuestros queridos móviles directamente. Estoy seguro que en el futuro no muy lejano no habrá canbus y habrá ethernet, esto propiciará un nuevo protocolo de conexión diferente a nmea 2000, sólo falta ver qué eligen los fabricantes y cuál será su interoperabilidad.

En cuanto a la conveniencia de que esos mensajes sean en formato texto y legibles por los humanos, qué queréis que os diga, no he visto a ningún usuario que prefiera leer tramas json a leer los datos en relojes de tipo analógico, o a lo sumo en displays numéricos.
Así que no me parece esto una razón de peso.

No he hablado de usuarios, he hablado de desarrolladores.

Un protocolo abierto y fácil de entender hace que proliferen aplicaciones sobre un estándar abierto y no controlado por los fabricantes, esto siempre será beneficioso para el usuario.
El día que los fabricantes cambien de nmea 2000 a otra cosa y firmen los mensajes y sólo acepten mensajes firmados por fabricantes de electrónica marina (raymarine, simrad/b&g y furuno) entonces se acabó la historia. Si hay un protocolo abierto con una aceptación considerable y con apps que ya lo usan, los fabricantes pueden considerar darle soporte por obligación.
Hablo de signalk porque es el que hay ahora mismo.

Lo que sí me parece obvio es que los desarrolladores especializados en Java, han continuado desarrollando cosas inapropiadas para esa herramienta porque no conocen otra cosa.
Un usuario medio quiere fiabilidad. Y eso no es posible con "pulpos" de conexiones y arduinos / raspis con software "DIY".

Supongo que te refieres a Javascript no ha Java, Signalk esta hecho con Javascript. Cada lenguaje de programación tiene un ámbito de uso y lo que es incorrecto es usar uno en concreto para todo.

Ya lo he comentado en otros mensajes, Signalk usa NodeJS, que es un servidor de aplicaciones que te permite usar Javascript para programar. Las apps hechas con este servidor de aplicaciones normalmente usan Javascript cómo "lenguaje pegamento", pero el trabajo "duro" se suele hacer con bindings a bibliotecas en C, no creo que nadie discuta el rendimiento de C. Si SignalK hace esto, pues no lo sé, seguro que las operaciones de red si.

Estoy de acuerdo que el DIY en algunos escenarios no es lo más apropiado, de hecho, yo te he comprado un gateway precisamente por eso. Tus equipos tienen un ámbito y cumplen perfectamente en su ámbito.

De todas formas, tampoco soy yo el abogado de SignalK, cada uno que use lo que quiera o le venga mejor. Lo que tengo claro es que entre SignalK y "SignalK" que sacará seguro la industria, me quedo con el abierto.


Volviendo a la temática del hilo, mi recomendación es que hoy en día lo mejor es usar un gateway para "mezclar" protocolos  y equipos  viejos con nuevos y un PC para el resto de cosas si no tienes un plotter moderno y chulo.

[gypsylyon]

bien, me queda ahora conocer 100% cómo está conexionada la electrónica de mi barco y decidir que quiero hacer, con eso podría plantearos un croquis y sobre ello estudiar la situación y ver opciones.

decir que en mi barco el chartplotter no está en la bañera, cosa que me gustaría y motivo principal de este thread, en bañera tengo los st de seatalk con la corredera, sonda, viento etc.
la idea es ponerme al lado, que tengo un sitio estupenda para situarla, una tablet que por wifi conecte con la raspi para tener un chartplotter decente y sobre todso, a la vista sin tener que entrar al puente.

Si a ello le puedo añadir funcionalidad conectandole, el viento y resto de sensores, pues mejor que mejor.

si escogiera esta opción, vía muiltiplexador, pues igual que este ya incorporara NMEA2000, parece que sería una estupenda manera de en un futuro próximo conectar nueva electrónica.

La opcion de nmea2000 pienso hoy en dia indispensable. El gateway de ocenav lo he tenido 6 años solo con nmea183 y SeaTalk1.  El año pasado le puse la red nmea2000 con un transponder AIS y un gps nmea2000.  Es decir ahora el ocenav gestiona los estándares. Los blancos AIS se ven en cualquier dispositivo. Como plotter uso opencpn en la raspi controlando el autopiloto de raymarine por seatalk a través de ocenav.
Respecto a llevar tablet o mobil en la bañera , pues al final me compre un plotter baratillo de 7 pulgadas. Los problemas con tablet es el sol y el agua. Con mobil el formato es muy pequeño . Por otra parte como se usa para otras cosas pues no siempre está operativo como plotter. Otro problema es la bateria, así que lo tienes que tener cargándose.  
Para pequeñas travesias puede valer pero largas es una maravilla ver todo en el plotter fuera.
También para aproximarse al puertobo el fondeo es muy útil.

Después de bastante bricolajevelectronico  durante muchos años mi conclusión es de tener aparatos fiables, dedicados ( no aparatos de multifuncion), simples de manejar y plug and play.

Asi que mi configuración ahora es.
Central ocenav como central decgestion de datos de SeaTalk1,  nmea183  y nmea2000. 
Plotter interno opencpn en raspberry con sensores temperatura, presion(barometro) y 4 entradas analógicas  ( para conectar a motor y leer rpm, presión aceite, temperatura refrigeracion y salida alternador).
Radio vhf con nmea183,  transponder AIS con nmea2000, radar jbc con nmea183,.
DisplayS st50 de profundidad y velocidad más autopiloto st6000  por SeaTalk1. 
Un gyrocompas , regalo de tehani,  conectado a la raspi por usb.
En el pedestal st50 tridata, st50 viento y autopiloto st7000 por SeaTalk1. 
Nuevo un plotter onwa dec7 pulgadas con nmea183. 
Ocenav simplifica todo. Conexion a red SeaTalk1, conexión a Red nmea2000.  La conexión a datos nmea183 Sun problemas con tres canales de entrada y dos de salida. Más la conexión Wi-Fi  como punto de acceso.

Antes tenía también openplotter con signalk en la raspi, pero se comía muchos recursos haciendo que openplotter funcionara muy lento. Ahora solo openplotter leyendo los datos que le envía ocenav por nmea183 y por wifi para salida de datos de la raspi.  Para lectura de sensores, que van en un hut de la casa joy-it llamado Explorer700,  he escrito un script en Python, que vuelca los datos a un puerto UDP y los lee opencpn. También los vuelco al puerto de entrada de ocenav.

De todas maneras cada armador con su barco es un mundo. Está ha sido mi solución

[josefu]

Pero precisamente estamos hablando de la raspberry.  Yo tengo una 4 con 8gb y en el momento que arranca signalK se come los recursos de la raspi. Entonces resulta dificil manejar OpenCPN, ya que se vuelve muy lento. Así que tienes dos opciones si quieres navegar con opencpn, una es la de dedicar una raspi para openplotter con signalk y la otra raspi solo para opencpn. Y segunda opción prescindir de signalk y por ende openplotter.

Yo he optado por la segunda. Para ello he tenido que invertir tiempo en escribir un script en Python para leer los sensores por I2C, 1Wire y SPI. El ahorro de recursos es impresionante.
Baja del 90% de ocupación a no pasar del 25%..

Puede que signalk sea una opción pero bastante limitada para la raspi. Tampoco me puedo imaginar signalk en otrso dispositivos controlados por microprocesadores.
Por ahora el futuro en nautica es nmea2000.

Yo tengo una raspberry 3 y tengo claro que no la usaría para opencpn, no me adapto a su velocidad, para mí es lenta. Volvemos a lo de antes, cada cosa tiene su ámbito, que puedas usarlar como plotter no significa que sea lo más recomendable.

Los problemas de cpu estarán más provocados por plugins no muy bien hechos (no lo sé) que por el propio signalk. De todas formas, si me equivoco, no tengo ningún problema en reconocerlo.

Por curiosidad, ¿qué datos recoges con este script?

Mi intención es simplemente leer un bme280 para la temperatura ambiente y barómetro, algún sensor de temperatura para el motor y también tengo un sensor MPU9250, iré probando.

Luego quiero leer los tanques de agua y gasoil, pero aquí no tengo claro si usaré algo hecho por mí o si compraré ya algo hecho (probablemente nmea 2000).

[magallanesxix]

Madremíadelamorhermoso!!!!

Leo el título y entro a ver si se habla de como puedo aprovechar algún "parato" de los que no uso y me encuentro con esto.
seré pardillo 

Saludos.

[gypsylyon]

Yo tengo una raspberry 3 y tengo claro que no la usaría para opencpn, no me adapto a su velocidad, para mí es lenta. Volvemos a lo de antes, cada cosa tiene su ámbito, que puedas usarlar como plotter no significa que sea lo más recomendable.

Los problemas de cpu estarán más provocados por plugins no muy bien hechos (no lo sé) que por el propio signalk. De todas formas, si me equivoco, no tengo ningún problema en reconocerlo.

Por curiosidad, ¿qué datos recoges con este script?

Mi intención es simplemente leer un bme280 para la temperatura ambiente y barómetro, algún sensor de temperatura para el motor y también tengo un sensor MPU9250, iré probando.

Luego quiero leer los tanques de agua y gasoil, pero aquí no tengo claro si usaré algo hecho por mí o si compraré ya algo hecho (probablemente nmea 2000).

Son los sensores que lleva el hut explorer700 de joy-it.

https://www.joy-it.net/en/products/RB-Explorer700

Lleva el BMP180 como sensor de presión atmosférica y temperatura, el PCF8591 que es un convertidor AD de 4 canales por I2C, 1Wire Interface para sensor temperatura DS18B20, el DS3231 chip de RTC por I2C , y más posibilidades.

Tengo también un MPU9250 pero con el Gyrocompas que me regalo tehani no lo necesito.

[Gralf]

Madremíadelamorhermoso!!!!

Leo el título y entro a ver si se habla de como puedo aprovechar algún "parato" de los que no uso y me encuentro con esto.
seré pardillo 

Saludos.

[Tehani]

Me recuerdas cuando los compañeros (normalmente los más jóvenes) ante cualquier comentario sobre eficiencia que hago, me dicen: "Pero si tenemos memoria de sobra, y si es por cpu pues ponemos una más potente".

Y yo siempre les contesto: "Eso, matar moscas a cañonazos".

Pues sí, y eso unido a lo que se llama "productividad" es lo que está provocando que los desarrolladores no se preocupen por optimizar el software existente antes de añadir nuevas características.
Así que el resultado es un parche sobre parche. O plugins y más plugins.
Y siempre con la necesidad creciente de hardware más potente para hacer cualquier chorrada.
Mi culpa: Ser de la antigua escuela. Empecé programando en ensamblador con el 8085, Z80 y 6502 allá por los principios de los 80.

[Tehani]

Si lo que te molesta es la verbosidad del protocolo, para eso hay soluciones como protobuf.

En electrónica marina a día de hoy el estándar para los fabricantes es  nmea 2000 (canbus), pero ya todos o casi todos los plotters y otros equipos tiene wifi o ethernet. Un chip wifi o ethernet es más barato que uno de canbus simplemente por la escala de fabricación.

Tienes una tecnología de conexión barata (ethernet), en la que no vas a tener problemas de ancho de banda y a la que se pueden conectar también nuestros queridos móviles directamente. Estoy seguro que en el futuro no muy lejano no habrá canbus y habrá ethernet, esto propiciará un nuevo protocolo de conexión diferente a nmea 2000, sólo falta ver qué eligen los fabricantes y cuál será su interoperabilidad.


No he hablado de usuarios, he hablado de desarrolladores.

Un protocolo abierto y fácil de entender hace que proliferen aplicaciones sobre un estándar abierto y no controlado por los fabricantes, esto siempre será beneficioso para el usuario.
El día que los fabricantes cambien de nmea 2000 a otra cosa y firmen los mensajes y sólo acepten mensajes firmados por fabricantes de electrónica marina (raymarine, simrad/b&g y furuno) entonces se acabó la historia. Si hay un protocolo abierto con una aceptación considerable y con apps que ya lo usan, los fabricantes pueden considerar darle soporte por obligación.
Hablo de signalk porque es el que hay ahora mismo.


Supongo que te refieres a Javascript no ha Java, Signalk esta hecho con Javascript. Cada lenguaje de programación tiene un ámbito de uso y lo que es incorrecto es usar uno en concreto para todo.

Ya lo he comentado en otros mensajes, Signalk usa NodeJS, que es un servidor de aplicaciones que te permite usar Javascript para programar. Las apps hechas con este servidor de aplicaciones normalmente usan Javascript cómo "lenguaje pegamento", pero el trabajo "duro" se suele hacer con bindings a bibliotecas en C, no creo que nadie discuta el rendimiento de C. Si SignalK hace esto, pues no lo sé, seguro que las operaciones de red si.

Estoy de acuerdo que el DIY en algunos escenarios no es lo más apropiado, de hecho, yo te he comprado un gateway precisamente por eso. Tus equipos tienen un ámbito y cumplen perfectamente en su ámbito.

De todas formas, tampoco soy yo el abogado de SignalK, cada uno que use lo que quiera o le venga mejor. Lo que tengo claro es que entre SignalK y "SignalK" que sacará seguro la industria, me quedo con el abierto.


Volviendo a la temática del hilo, mi recomendación es que hoy en día lo mejor es usar un gateway para "mezclar" protocolos  y equipos  viejos con nuevos y un PC para el resto de cosas si no tienes un plotter moderno y chulo.

Te propongo una conversación en privado para tratar todos esos temas. Así el señor Magallanesxix no se quejará...

En cuanto a las conexiones Seatalk, NMEA2000, NMEA0183 y WiFi, puede ser buen momento para explicar un poco las características de los procesadores que utilizo y por qué son tan eficientes, con muy bajo consumo y con la potencia de procesado suficiente:

1- Son procesadores ARM de 32 bits y se potencia al máximo sus recursos hardware (DMA, interrupciones, timers, etc). El consumo total, incluyendo el módulo WiFi y de radio no supera los 90 mA a 12v (1 Watio), por eso pueden alimentarse directamente desde la red Seatalk o NMEA2000. A ese bajo consumo contribuye también la fuente conmutada de estos equipos.

2- Estos microcontroladores tienen integrados (embebidos según la moda actual) los siguientes periféricos:
- 2 controladores de bus CAN (NMEA2000) por lo que prescindo del MCP2515. (Josefu, sólo encontrarás un MCP2551 que es el adaptador de señales de línea o "transceiver").    Toda la gestión del bus CAN y NMEA2000 corre íntegramente con software "de la casa". Sin librerías externas.
- Controlador USB 2.0 (Sin chip FTDI o Prolific). La gestión directa del USB también es software "de la casa".
- 4 (Rem072), 5 (ATM105/115) o 6 (ATM200) USARTS programables con capacidad para trabajar con 9 bits de datos, óptimas para Seatalk entre otras cosas.
Estas USARTS se emplean para lo siguiente:
- Una para la comunicación bidireccional con el ESP12F (Módulo WiFi).
- Una para las comunicaciones bidireccionales con Seatalk.
- 2 (Rem072) o 3 (ATM105/115) para canales NMEA0183 por cable. 2 de ellos bidireccionales.
- 1 (ATM200) para conexión al GPS/GNSS interno.
- ATM105/115/200: 2 canales I2c que ya manejan a los BMP180 y BME280 (Temperatura, presión y humedad), y BNO055: giróscopo de 9 ejes. Toda esa información sale por NMEA0183 y NMEA2000. El procesador del Rem072 también tiene I2c, pero no se ha cableado en placa.
- ATM105/115/200: Varios canales SPI. Uno es para la radio del control remoto, otro para una posible expansión Ethernet, otro para lector / grabador de tarjetas SD. El Rem072 tampoco los tiene cableados en placa.

3- Todo el software, desde el control del hardware hasta la propia aplicación ha sido escrito "en casa". No hay parches ni software de terceros. Claro, eso ha supuesto unos cuantos miles de horas de trabajo...

4- No usan sistema operativo. No necesitan cargar software desde ningún dispositivo externo, y el arranque es instantáneo (milisegundos). Utilizan watchdog para reiniciar ante cualquier tipo de cuelgue.

5- El hecho de controlar la flash de programa permite actualizaciones "in situ".

[vecino]

...
Mi culpa: Ser de la antigua escuela. Empecé programando en ensamblador con el 8085, Z80 y 6502 allá por los principios de los 80.

Yo también

[gypsylyon]

Yo también de la antigua escuela. Pero no con el Intel 8085 si no con el Motorola MD68000. También tuve un Z80 y un comodoro. Mi primera experiencia con algo parecido a un PC fue un servidor de Unix alla por los 80.
Por eso he probado la rutina o script de Python para leer SeaTalk1 con la raspberry vía gpio.  Funciona pero hay un gran  problema. No filtra bien la información que lee. 
Le he metido información de 1Wire y de nmea183 y curiosamente generaba sentencias seatalk las cuales evidentemente son falsas. 
Es decir que no se puede estar seguro de la fiabilidad de la información que entra por este canal.

Esta claro que se puede corregir este error y veré de hacerlo.
Mientras tanto si no se corrige no recomiendo utilizarlo.

[Gralf]

Hola, soy nuevo aquí, encantado de conversar con vosotros, intentaré ser lo más participativo posible.

Os cuento, mi barco dispone de la siguiente equipación

• radar chartplotter raymarine SL70RC plus
  
• gps raymarine 112lp ó 120
  
• radar sl70 raytheon
  
• st60 tridata 
  
• st60 viento
  
• radio VHF IC M421
  
• piloto raymarine ST1000+
  
• sonda corredera termometro (no se marca ni modelo)
  

como llevo un tiempo leyendo sobre la rapsberry pi, su intalacion y cómo conectar los aparatos existente...., pues he llegado a un punto, en que estoy lleno de datos y configuraciones, pero no sabría por donde empezar, sobre todo porque me quedan muchas dudas, que pasaré a comentar, por si me podeis ayudar.

1- pues para empezar, decir que se que podemos dar a la Rpi datos de Seatalk y NMEA0183, según he visto en varios foros y videos de Youtube, creo que esto lo tengo mas menos claro, para ST usamos el amarillo y el gris, que pasamos a un octoacoplador del que sacaremos 3 cables que van a 3 pines GPIO de la Rpi. como en la imagen



para NMEA pues los adpatadores USB RS232 que sse conectan de este modo


fuente

en el caso del cableado, "pinchar seatalk parece sencillo, me voy al tridata y conecto a la entrada amarilla y a la gris, junto con el los cables que estén allí ya, como ST se comunica mediante un BUS, pues con hacer esto en uno de los aparatos, ya todos estarían conectados.

pero en cuanto a NMEA, qué hay que hacer? pelar cables? o lo que haceis es desconectar un aparato y "empatar cable"? lo cual supone desconectar ese aparato definitivamente.....
esta es una de mis multiples dudas, pero para empezar a aclarar conceptos, igual no es mala idea aclarar para proseguir.


bueno, siento el tocho, y doy gracias por adelantado.

vuelvo a la carga con fuerzas renovadas, tras estar ausente por motivos que no vienen al cuento.

aunque no he podido atender demasiado mi barco al igual que otras actividades de mi vida diaria, si que he podido leer, ver videos y dar vueltas a la cabecita.

y llego, como no, lleno de dudas, pero dudas que querría resolver, antes de proseguir con este proyecto.


Antes de nada, respecto de la electrónica de mi barco, he descubierto hoy, dado que me he atrevido a ver las tripas de varios de los aparatos de los que dispongo, os comento

La 

primera novedad, es que dispongo de este aparato, un raymarine E85001 Interface




que por lo leído en su manual, es un 

SeaTalk is the language used by Raymarine products to share information. This is unique to Raymarine. The PC/SeaTalk/NMEA Interface, by providing conversion between SeaTalk, RayTech PC and NMEA 0183 data formats, allows operation with other manufacturer's equipment and with PCs.

The PC/SeaTalk/NMEA Interface provides:
• Connection of SeaTalk to a PC running RayTech
• Conversion of NMEA 0183 data format to SeaTalk
• Conversion of SeaTalk to NMEA 0183 format

• Operation of the Raymarine Main Alarm when an alarm condi-
tion exists on the SeaTalk bus

vamos que es un conversor bideireccional nmea 0183 - seatalk, si no me equivoco, si es así, por favor, corregidme-

adjunto otra foto, del cableado actual del mismo bridge 


como podeis comprobar, en la hilera superior, hay dos cables conectados , el marron al amarillo de SEATALK y el blanco al blanco de SEATALK
en la hilera inferior, hay un cable negro al blanco SEATALK y uno blanco al amarillo de SEATALK, así mismo, tenemos un cable rojo al rojo al NMEA out + y uno negro al NMEA out -

la verdad no entiendo muy bien el sentido de este aparato en mi barco, dado que todo es raymarine, entiendo que los raymarines hablan todos SEATALK, o no? 
Aunque despues de estudiar un poco más, he llegado a la conclusión de que el aparato se usa para mandar la señal del GPS a la radio, que tras leer su manual, solo acepta entrada de posición en NMEA, os parece razonable?

me gustaría antes de nada aclarar las dudas sobre este "parato" para poder entender un poco mejor mi instalación. Por cierto, aparte de las preguntas ya presentadas, por qué creeis que hay cables en las dos hileras SEATALK?

[gypsylyon]

Por la lista de aparatos que tienes, el coonversor nmea183  a SeaTalk1 sirve para que la radio se conecte con los dispositivos ray marine y pueda obtener información de gps o del MOB. 
Pero también te puede servir para conectarte a una raspberry pi con opencpn  o un portátil u utro aparato que trabaje en nmea183 como un receptor GPS o un AIS.