Foro Navegantes

Gracias por el interés. Así pues explicaré cómo funciona una comunicación en serie asíncrona, que es la que se usa tanto para NMEA0183 como para Seatalk.

En primer lugar, hay que decir que se llama asíncrona porque no existe una línea adicional de impulsos (clock) que sincronice emisor y recepctor. Entonces, es muy importante que tanto el emisor "transmita" como el receptor "lea" el contenido de la línea de datos en tiempos iguales y muy precisos. Esto es especialmente comprometido a velocidades altas.
La línea está en reposo a nivel alto (1), y el inicio del bloque de datos se determina siempre por un primer nivel 0 en la línea. A partir de ahí, los relojes internos de emisor y receptor hacen que los bits siguientes se transmitan y se capturen en los mismos instantes de tiempo.
Vaya lío no?. Pues no, porque existe un dispositivo hardware programable y especializado en hacer estas cosas. Se llama USART (Universal Synchronous Asinchronous Receiver Transmitter). Ejemplo: http://informatica.uv.es/~rmtnez/sbm/TEMA25-b&w.pdf
Este chip está integrado actualmente dentro de los microcontroladores (uC). La Raspi lleva un uC como procesador principal con dos USARTS.

La comunicación asíncrona puede funcionar sobre diferentes soportes físicos: RS232, RS422, RS485, Seatalk (este último no es un estándard de la industria). Los soportes físicos hacen recerencia a los niveles de tensión que se considerarán como 0 y 1 lógicos: si se hace con un solo cable (unipolar) como RS232, o con un par diferencial como en el caso de RS422 y RS485. No me extenderé demasiado aquí, sólo diremos que RS422 es el soporte estándard para NMEA0183 y usa dos líneas de datos con niveles complementarios: (0/1 y 1/0), y esto sirve para reducir por diferencias el posible ruido que produzca interferencias en las dos líneas a la vez.
Algunos dispositivos, de Garmin principalmente, utilizan RS232 en sus canales de comunicación. Seatalk también funciona sobre una línea unipolar (cable de color amarillo) con tensiones de 12v para el 1 lógico y de 0 a 2-3v para el 0 lógico. 

Una explicación detallada sobre niveles y cableados de RS232, RS422 y RS485 la tenéis aquí:
http://www.uco.es/electrotecnia-etsiam/p...Fisico.pdf

Hasta aquí hemos visto cómo enviar ceros y unos por uno o dos cables. En el caso de NMEA0183 esos cables son de una única dirección (simplex), es decir, el que "habla" siempre habla y el que "escucha" siempre escucha y no puede hablar por esos cables, tiene que usar otros para hacerlo. De ahí la maraña que se monta en instalaciones NMEA0183.
Seatalk funciona de manera distinta: Por el mismo cable, a veces "habla" un dispositivo y los demás "escuchan", otras veces "habla" otro dispositivo, y el resto recibe. A ese tipo de comunicación se le llama "half duplex". NMEA2000 se ubica también en este tipo de comunicación half duplex. La ventaja es la drástica reducción del cableado.

Bueno, y esos 0's y 1's que se envían por esos cables cómo se organizan?
Pues NMEA0183 utiliza bloques de 0/1 agrupados de 8 en 8 (bytes) en formato ASCII (basado en una tabla y legible por los humanos)
https://elcodigoascii.com.ar/
Y Seatalk (De NMEA2000 podemos hablar otro día) utiliza un formato de 9 bits en binario puro mucho más eficiente pero no traducible a texto. El noveno bit, cuando está a 1 indica que ese bloque de9 bits es el inicio del datagrama (sentencia seatalk). Los demás grupos de 9 bits tienen ese noveno bit a 0.
Problema: Las USARTS de la Raspberry no son capaces de configurarse con bloques de datos de 9 bits. Vale, eso lo sabíamos, por eso alguna librería Python maneja directamente un pin GPIO para leer los datos Seatalk. Pero, ¿qué comporta eso?.
1- Es necesario que la CPU atienda directamente la lectura de ese pin (La librería no sirve para enviar datos).
2- Además DEBE hacerlo en instantes de tiempo que coincidan con el punto central del tiempo de bit. Cualquier retraso o adelanto supondrá una lectura errónea.
3- La Raspberry utiliza un sistema operativo multitarea. Los cambios de tarea (hilos de programa) se suelen realizar cada milisegundo. Diréis: Qué rápido!!!. Pues no, no es suficiente para una lectura precisa de un bloque de 9 bits, y menos cuando va "cargada" ejecutando varios programas, plugins, etc.
4- Para hacer una lectura medianamente precisa de un pin es imprescindible programar el sistema de interrupciones de la Raspberry, y usar un timer hardware asociado. Poca gente programa a ese nivel.

Aquí tenéis un ejemplo de transmisión del datagrama Seatalk donde se envía SOG:



Los puntos indican los instantes de tiempo donde el receptor debe realizar una captura del estado del GPIO. El bit de menos peso (valor) es el de la izquierda en cada bloque.
Como se puede ver, el primer bloque de datos de 9 bits contiene un valor 0x152 en hexadecimal. El 1 indica inicio de datagrama, y los siguientes bloques tienen este bit a 0.
El valor 52 indica que ese datagrama contiene datos de SOG.
Vamos a ampliar para ver cuánto dura 1 bit:



A simple vista se puede ver: aproximadamente 0,2 milisegundos. Exactamente 1/4800 = 0,20833 milisegundos.
Si el trabajo de leer bit a bit lo tiene que hacer la CPU y no la USART, eso supone que cada 0,208 milisegundos EXACTAMENTE, esa "pobre y cargada" CPU debe hacer una lectura e ir acumulando (desplazando) para formar el bloque de nueve bits. La USART añade lo que se llama una FIFO, que es una memoria donde se acumulan los últimos bloques de datos que llegan, y se guardan allí hasta que el procesador principal los puede leer de esa USART. Es decir, con la USART es prácticamente imposible perder un dato.
Y todo eso sin contar con la sincronización inicial (start bit), porque entre ese primer nivel 0 y el primer instante donde se debe capturar el primer bit válido debe transcurrir exactamente un tiempo equivalente a 1 bit y medio.
Una USART normalita divide el tiempo de bit en 16, 64 y hasta más a baudrates bajos como usa Seatalk (4800). Y realiza la captura justo en el centro de ese intervalo.

NO siento el rollaco, porque al que no le interese lo puede saltar...

(07-10-2022, 03:44 PM)Gralf escribió: [ -> ]Siento el error, efectivamente NO es st70, sino SL70RC plus. 

Respecto al AIS, en ppio no tengo idea de instalar uno.

Aunque que ese conversor ya integre NMEA 2000 no es mala idea, pensando en el futuro, dado que parece que van los tiros hacia ahí.

En cuanto a SignalK, no se por qué lo dices, si vas por el tema informática-trasteo, no me da miedo, yo soy de los que era capaz de instalar linux redhat del cd que regalaba PCActual , que venía repleto de shareware sin problemas, vamos, que la informática se me da muy bien; si es por otro motivo, me callo.

Las razones por las que ST no es buena idea, pues, aprender siempre está bien, me siento a leer.



Y por cierto, muchisimas gracias por tu respuesta.

Métele a esa desdichada Raspberry la gestión del GPIO para Seatalk con el añadido de SignalK y te quedará muerta muerta: RIP.
Y antes de que eso ocurra te servirá como calefactor para el barco.

Se nota que has sido profesor.
Una explicación fantástica.

Wow, impresionante, conste que es una explicación de 0, y la parte de cómo se transmiten los datos no es fácil de digerir para alguien, como yo, ajeno y muy ignorante en electrónica. Pero me ayuda a entender un poco mejor de lo que hablamos. Gracias.

El caso es que ST, entiendo que por ser un "lenguaje" propietario, complica las cosas en cuanto que "traducirlo" le supone un sobreesfuerzo a la CPU, que debe dedicar recursos que deja de dedicar a otros procesos, todo por culpa de esos 9 bits, cuando lo "normal" son 8, esto lo he leído por ahí. Y ese es el motivo de por qué no recomiendas pasarle ST a la raspi.

No se si esta es la idea....

(07-10-2022, 08:49 PM)Gralf escribió: [ -> ]

Wow, impresionante, conste que es una explicación de 0, y la parte de cómo se transmiten los datos no es fácil de digerir para alguien, como yo, ajeno y muy ignorante en electrónica. Pero me ayuda a entender un poco mejor de lo que hablamos. Gracias.

El caso es que ST, entiendo que por ser un "lenguaje" propietario, complica las cosas en cuanto que "traducirlo" le supone un sobreesfuerzo a la CPU, que debe dedicar recursos que deja de dedicar a otros procesos, todo por culpa de esos 9 bits, cuando lo "normal" son 8, esto lo he leído por ahí. Y ese es el motivo de por qué no recomiendas pasarle ST a la raspi.

No se si esta es la idea....

No es así. En realidad es mucho más fácil y eficiente para una CPU manejar datos binarios que parrafadas ASCII de NMEA0183.
Y por ende, muchísimo mejor que digerir las barrocas parrafadas ASCII JSON de SignalK.

En realidad, el contenido útil de los 9 bits de Seatalk son 8 bits. El noveno sólo sirve para detectar el primer bloque del datagrama. El procesado posterior se hace con bytes, ya sin el noveno bit.

Los entusiastas del engendro SignalK dicen "Las CPU's actuales como la de la raspi pueden con todo, interpretar cadenas SignalK es una nimiedad, y una red basada en Ethernet es muy rápida". 
Sí, pero nunca va bien que ejecuten basura de código. Y no porque una red sea rápida, hay que llenarla obligatoriamente de basura inútil. Eso lo digo yo...

Hace poco tuve una discusión con uno de los desarrolladores de SignalK. No entraré en detalles, pero poco a poco fue proponiendo algún recorte en esa forma barroca. Total, que la optimización de SignalK, si se hace, tardará porque han empezado bastante mal, y lo peor es que no sería compatible con lo que hay ahora.
Por mi parte, olvido ese tema y punto. No me gusta buscarme problemas por deporte.

Mi argumento básico es que desde los sensores se "hable" en un solo "idioma". SignalK es incompatible con esa idea.
En ese aspecto, eso es ir hacia atrás, puesto que los antiguos Seatalk, fastnet de B&G, Topline de NKE y el actual NMEA2000 permiten hacerlo con un coste muy bajo en hardware.

Y por supuesto, hay otros microcontroladores que no son los de la Raspberry ni del ESP8266, ni del ESP32 que sí tienen USARTS capaces de manejar longitudes de 9 bits e incluso más.
Existe una técnica de redes de controladores llamada "multiprocessor" que también emplea 9 bits por transferencia o bloque. Esto no es nuevo. (Me he puesto a explicar en qué consiste, pero lo he borrado porque creo que ya es pedir demasiado al torturado lector).

(07-10-2022, 09:59 PM)Tehani escribió: [ -> ]No es así. En realidad es mucho más fácil y eficiente para una CPU manejar datos binarios que parrafadas ASCII de NMEA0183.
Y por ende, muchísimo mejor que digerir las barrocas parrafadas ASCII JSON de SignalK.

En realidad, el contenido útil de los 9 bits de Seatalk son 8 bits. El noveno sólo sirve para detectar el primer bloque del datagrama. El procesado posterior se hace con bytes, ya sin el noveno bit.

Los entusiastas del engendro SignalK dicen "Las CPU's actuales como la de la raspi pueden con todo, interpretar cadenas SignalK es una nimiedad, y una red basada en Ethernet es muy rápida". 
Sí, pero nunca va bien que ejecuten basura de código. Y no porque una red sea rápida, hay que llenarla obligatoriamente de basura inútil. Eso lo digo yo...

Hace poco tuve una discusión con uno de los desarrolladores de SignalK. No entraré en detalles, pero poco a poco fue proponiendo algún recorte en esa forma barroca. Total, que la optimización de SignalK, si se hace, tardará porque han empezado bastante mal, y lo peor es que no sería compatible con lo que hay ahora.
Por mi parte, olvido ese tema y punto. No me gusta buscarme problemas por deporte.

Mi argumento básico es que desde los sensores se "hable" en un solo "idioma". SignalK es incompatible con esa idea.
En ese aspecto, eso es ir hacia atrás, puesto que los antiguos Seatalk, fastnet de B&G, Topline de NKE y el actual NMEA2000 permiten hacerlo con un coste muy bajo en hardware.

No creo que nadie discuta que procesar un mensaje JSON tiene mayor coste computacional que uno seatalk o nmea 2000. Tampoco es discutible que un protocolo basado en texto ayuda mucho a que se extienda, lo usen desarrolladores y hayan aplicaciones, de esto los claros ejemplos son HTTP y JSON.

Con esto quiero decir que ni un mensaje binario vale para las actuales y futuras apps donde el cloud es una realidad, ni un JSON vale para una red donde hablan sólo microcontroladores.

Antes no había wifi y los sensores iban cableados, ahora todos con tarjeta WiFi para poder conectar por ethernet y enviando mensajes a servicios web con un JSON, además de que los configuras mediante http.

Los sensores IOT, ya hoy en día, se comunican con buses tipo mqtt con mensajes JSON (parecido o igual a signalk) y esto permite una flexibilidad y potencia de abstracción superior. Desde luego esto tiene un coste computacional y de energía. 

Hacer ciertas cosas con una raspberry es matar moscas a cañonazos, además de poco eficiente, pero hay otras cosas que no puedes hacer si no tienes un "pc".

Yo creo que lo ideal es la mezcla de las dos cosas: hay cosas que se hacen mejor con microcontroladores y otras con microprocesadores. No hay por qué pelearse. 

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.

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.

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.

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

hablas de aunar NMEA y ST en NMEA2000? es este el cometido de los multiplexores?, es que ahora si que empieza a hacerse un poco "complicado" seguiros, par ami, aunque sigo atentamente la conversación, porque como ya dije, aprender siempre es interesante, y os lo agradezco.

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

(08-10-2022, 10:34 AM)Gralf escribió: [ -> ]hablas de aunar NMEA y ST en NMEA2000? es este el cometido de los multiplexores?, es que ahora si que empieza a hacerse un poco "complicado" seguiros, par ami, aunque sigo atentamente la conversación, porque como ya dije, aprender siempre es interesante, y os lo agradezco.

No, no se refiere a eso.  Se refiere a la forma de enviar los datos de nmea2000.  Por ejemplo  por wifi en lugar de por cable.
Lo de los multiplexores es una necesidad para nmea183,  ya que como comento Tehani, hay un aparato que emite y otro que escucha. Es decir sólo dos aparatos. Si la señal es buena puede haber dos o tres aparatos que escuchan, pero tienen que tener el mismos hardware, o todos rs232 o todos rs422.
Los multiplexores convertidores es otra solución para hacer compatibles los estándares entre sí.  Aunque su vida está contada en cuanto vaya desapareciendo SeaTalk1 y nmea183.  Con SeaTalk1 hace años que no se fabrica ningún producto y raymarine ya no da apoyo. Cada vez hay más aparatos que no ofrecen nmea183 de salida. Sólo un canal de entrada  nmea183 y nmea2000. 
Como sabéis yo tengo uno de esos convertidores multiplexores, cuyo papá,  por asi decirlo , es tehani.
En cuanto se estropee algún aparato de SeaTalk1,  lo substituire por nmea2000 y probablemente ya no necesitaré el conversor.

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

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

(08-10-2022, 12:29 PM)gypsylyon escribió: [ -> ]Los multiplexores convertidores es otra solución para hacer compatibles los estándares entre sí.  

Que los standares se hagan compatibles entre si mediante convertidor..... Qué quiere exactamente decir?
El convertidor "traduce" 

1. las tres a una de ellas?
   
2. Las tres a otra única?
   
3. O que hace?
   

La salida del conversor? Se le puede dar a las raspi, entiendo? O el problema de sobrecarga de la CPU va a seguir estando igualmente ahí?

(08-10-2022, 02:53 PM)Gralf escribió: [ -> ]Que los standares se hagan compatibles entre si mediante convertidor..... Qué quiere exactamente decir?
El convertidor "traduce" 

1. las tres a una de ellas?
   
2. Las tres a otra única?
   
3. O que hace?
   

La salida del conversor? Se le puede dar a las raspi, entiendo? O el problema de sobrecarga de la CPU va a seguir estando igualmente ahí?

Un conversor, "gateway" en lenguaje un poco técnico, libera de trabajo a la raspi o a lo que sea que se conecte.
Así, la raspi se limita a leer de un solo sitio (WiFi, USB) todos los datos ya convertidos por el gateway a NMEA0183.

El Kid de la cuestión es que algunos gateways sólo leen seatalk pero no envían datos en Seatalk, otros sólo hacen una conversión de nmea2000 a NMEA0183 por USB (Actisense NGW-1). Otro de Raymarine bastante antiguo sólo entre NMEA0183 y Seatalk.
Otros no tienen WiFi. Otros llamados multiplexores sólo concentran datos de varias fuentes NMEA0183, pero no traducen nada.
Por si esto fuera poco, no todos los conversores traducen todos los datos entre un bus y otro.

En fin, un corolario de opciones, y bastante liante para un usuario normal.