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...

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

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.

(08-10-2022, 09:35 AM)Tehani escribió:  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.

(08-10-2022, 09:35 AM)Tehani escribió:  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.

(08-10-2022, 11:54 AM)Tehani escribió:  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.

(08-10-2022, 07:02 PM)Gralf escribió:  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

(08-10-2022, 09:02 AM)gypsylyon escribió:  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).

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.

(08-10-2022, 08:24 PM)josefu escribió:  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.

(08-10-2022, 09:21 PM)magallanesxix escribió:  
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.

(08-10-2022, 12:34 PM)vecino escribió:  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.

(08-10-2022, 08:02 PM)josefu escribió:  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".

(09-10-2022, 12:29 PM)Tehani escribió:  ...
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

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.