[Tehani]

Con NMEA2000 te puedes ahorrar este pollo.

Quedo a la escucha...

[josefu]

No entiendo los colores que has puesto en la parte del Rem072. El Rem072 no tiene cables.

En principio, deberías conectarlo así:
AIS:                           REM
OUT1+ (Marrón)  ->  IN2-
OUT1-  (Azul)     ->    IN2+
Esto no es necesario para nada:
IN1+    (blanco)  <-   OUT2-
IN1-     (verde)    <-   OUT2+

Recuerda que la salida del AIS se puede (y se debe) conectar simultáneamente al Furuno y al Rem072. Cualquier otra combinación no te funcionará porque pasarás por un canal de baja velocidad.

Lo de los colores había puesto que "los colores del rem no son importantes" precisamente por eso, porque esos son los cables que yo he usado. De todas formas, lo importante es la conexión del REM que también esta puesta.

Ahora mismo lo tengo conectado así como dices y a través del wifi no recibo las sentencias AIS, sólo recibo las GPS. Además he puesto el Furuno en paralelo recibiendo del AIS y ahí si que veo los blancos AIS.

¿tengo que cambiar alguna configuración del rem?

[josefu]

Bueno, pues ya he cerrado todos los armarios y recogido todo.

El único problema es que no recibo los mensajes de AIS por la red wifi y sin embargo si los recibo en el Furuno (Tehani, luego me comentas).

He documentado las conexiones para que en el futuro no tenga que perder mucho tiempo en ver qué es cada cosa, lo pongo aquí por si alguien tiene algún equipo como los míos y le vale para algo:

   

[Tehani]

Bueno, pues ya he cerrado todos los armarios y recogido todo.

El único problema es que no recibo los mensajes de AIS por la red wifi y sin embargo si los recibo en el Furuno (Tehani, luego me comentas).

He documentado las conexiones para que en el futuro no tenga que perder mucho tiempo en ver qué es cada cosa, lo pongo aquí por si alguien tiene algún equipo como los míos y le vale para algo:

Si estás usando OpenCPN, es posible que no tengas bien configuradas las sentencias que transmite. Sólo tiene que transmitir XTE, RMB y opcionalmente APB por el puerto 2433. APB sólo es necesaria si el piloto es Simrad / B&G. Comprueba que OpenCPN, SignalK o quienquiera que sea no esté enviando VDM por la WiFi.
Para cualquier otra sentencia que añadas, tienes que pensar en que OpenCPN debe ser la fuente primaria de los datos contenidos en esa sentencia. Por ejemplo, un pincho GPS conectado a la raspi o PC, que lee directamente OpenCPN.
Si estás usando OpenPlotter y SignalK, con la iglesia hemos topado...

Has probado otras apps?. Instala SeaWi en el móvil. Esta app permite ver también blancos AIS. También Navionics Boating, aunque es una basura de app porque es muy limitada para otras cosas.
Haz la prueba con esas apps desconectando La raspi o PC de la WiFi, si no, seguirás sin saber qué pasa.

Por otra parte, te informo de que nunca verás la sentencia VDO porque contiene los datos del barco propio y eso es lo que el AIS envía por radio. Los dispositivos Ocenav filtran esta sentencia, y por eso, si no se tiene un Ocenav hay que configurar OpenCPN para que ignore VDO.

En https://ocenav.com/manuales/ tienes una guía y ejemplo de configuración de OpenCPN.

[josefu]

Si estás usando OpenCPN, es posible que no tengas bien configuradas las sentencias que transmite. Sólo tiene que transmitir XTE, RMB y opcionalmente APB por el puerto 2433. APB sólo es necesaria si el piloto es Simrad / B&G. Comprueba que OpenCPN, SignalK o quienquiera que sea no esté enviando VDM por la WiFi.
Para cualquier otra sentencia que añadas, tienes que pensar en que OpenCPN debe ser la fuente primaria de los datos contenidos en esa sentencia. Por ejemplo, un pincho GPS conectado a la raspi o PC, que lee directamente OpenCPN.
Si estás usando OpenPlotter y SignalK, con la iglesia hemos topado...

Has probado otras apps?. Instala SeaWi en el móvil. Esta app permite ver también blancos AIS. También Navionics Boating, aunque es una basura de app porque es muy limitada para otras cosas.
Haz la prueba con esas apps desconectando La raspi o PC de la WiFi, si no, seguirás sin saber qué pasa.

Por otra parte, te informo de que nunca verás la sentencia VDO porque contiene los datos del barco propio y eso es lo que el AIS envía por radio. Los dispositivos Ocenav filtran esta sentencia, y por eso, si no se tiene un Ocenav hay que configurar OpenCPN para que ignore VDO.

En https://ocenav.com/manuales/ tienes una guía y ejemplo de configuración de OpenCPN.

No estoy usando nada, estoy capturando en la red con el programa "ngrep" con mi portátil, no tengo ningún otro pc conectado (no hay raspberry todavía en el barco).

Veo que el REM072F envía las sentencias de rumbo magnético (con origen seatalk), veo las sentencias GPS (envíadas por el AIS a través de la conexión 2 del rem a 38400 bps), pero no veo las sentencias de blancos AIS que están llegando también por ahí. La conexión esta bien ya que si no no saldrían las de GPS.
En el Furuno veo las sentencias AIS y GPS que envía el em-trak, conectado en paralelo al REM.
En mi puerto hay otros barcos con AIS que he estado viendo en el Furuno.

Es como si el REM072F las filtrase o las considerase inválidas.

[Tehani]

No estoy usando nada, estoy capturando en la red con el programa "ngrep" con mi portátil, no tengo ningún otro pc conectado (no hay raspberry todavía en el barco).

Veo que el REM072F envía las sentencias de rumbo magnético (con origen seatalk), veo las sentencias GPS (envíadas por el AIS a través de la conexión 2 del rem a 38400 bps), pero no veo las sentencias de blancos AIS que están llegando también por ahí. La conexión esta bien ya que si no no saldrían las de GPS.
En el Furuno veo las sentencias AIS y GPS que envía el em-trak, conectado en paralelo al REM.
En mi puerto hay otros barcos con AIS que he estado viendo en el Furuno.

Es como si el REM072F las filtrase o las considerase inválidas.

Pues sí. Ya he visto el fallo.
Efectivamente, el Rem072 ignora las sentencias que no empiezan por "$" en los canales NMEA0183 de entrada por cable.
Y no entiendo qué ha pasado puesto que ha heredado el código del ATM105.
Bueno sí, supongo que como el hardware es diferente, las USARTS que se emplean han cambiado, y al copiar y pegar código del canal 1, se me pasó admitir también el "!".
El canal 1 no admite AIS puesto que siempre es de baja velocidad, eso está bien así.

Ya corrijo el entuerto, y gracias por reportar el problema.

Dentro de un rato colgaré otro post con el link para que descargues la actualización.

Gracias.

[josefu]

Pues sí. Ya he visto el fallo.
Efectivamente, el Rem072 ignora las sentencias que no empiezan por "$" en los canales NMEA0183 de entrada por cable.
Y no entiendo qué ha pasado puesto que ha heredado el código del ATM105.
Bueno sí, supongo que como el hardware es diferente, las USARTS que se emplean han cambiado, y al copiar y pegar código del canal 1, se me pasó admitir también el "!".
El canal 1 no admite AIS puesto que siempre es de baja velocidad, eso está bien así.

Ya corrijo el entuerto, y gracias por reportar el problema.

Dentro de un rato colgaré otro post con el link para que descargues la actualización.

Gracias.

Si has encontrado que es un bug, perfecto. 

Actualizaré y te comento.

[Tehani]

Si has encontrado que es un bug, perfecto. 

Actualizaré y te comento.

Ya está. Era una chorradabien tonta.
Tenemos que rehacer la web de Ocenav con todos los cambios de equipos y documentación, y como eso lleva tiempo, mejor lo paso por aquí.
 Este es el link para la descarga:

https://drive.google.com/file/d/1yMnwOPZ...sp=sharing

Las instrucciones para la actualización están en Readme.txt.

Yo lo he probado, y el fallo está corregido, ya dirás qué tal.

[josefu]

Actualizado y funcionando!

   

He visto un blanco a 20 millas estando dentro del puerto, otro día cuándo salga a navegar verificaré a ver qué alcance tengo con la antena en el arco de popa.

[Tehani]

Ya que estamos, intentaré justificar por qué se ha colado este error.
(Es posible que os aburra, así que perdonadme este mensaje y lo saltáis...)

Partimos de la base de que el software está bien, puesto que es heradado del ATM105 que lleva unos 7 años rodando por ahí en más de 100 dispositivos.
Y claro, la mayor parte del software es heredado, pero las funciones de control del hardware no, porque se trata de un microcontrolador diferente. El microcontrolador que se instala en los ATM105 es el STM32F105RBT6, mientras el que se emplea en el Rem072 es el STM32F072CBT6. De ahí los nombres xxx105 y xxx072. El corazón del primero es una CPU ARM Cortex M1, y el del segundo es un ARM Cortex M0. Son primos, pero no hermanos.

Todos los equipos se prueban a fondo antes de ser enviados. Las pruebas son de hardware por si falla una soldadura o algún chip, y se hacen de esta manera:

1- Cuando se carga el software por primera vez, nos conectamos vía WiFi para saber el número que sale en el nombre de la SSID. Con ese número se calcula el password de la WiFi, se confeccionan las etiquetas y de paso, se comprueba que la comunicación entre el módulo WiFi y el host (CPU STM32F072) es correcta. WIFI OK.
(La carga de software es triple: Se carga el software del módulo WiFi ESP12F, el loader para actualizaciones y la aplicación en el STM32F072).

2- Se conecta al PC vía USB. El administrador de dispositivos reconoce el puerto serie y le asigna un número de COM. -> USB OK.

3- Se inyecta señal NMEA2000 desde un ATM105 y se comprueba la recepción y transmisión. El led verde parpadea en grupos de 3 destellos cortos de 0,1 Segundo cada 1,6 Segundos. Se comprueba la recepción y transmisión entre N2k y WiFi/USB usando OpenCPN con un fichero tipo VDR que contiene todos los datos incluyendo AIS y haciendo que OpenCPN envíe datos de piloto. (De hecho, la simple comprobación de los 3 destellos cortos es suficiente para comprobar N2k). -> N2K OK.
Aquí lógicamente, todos los canales NMEA0183 y Seatalk deberían transmitir lo que llega por N2k, pero estos canales se prueban en una fase posterior.

4- Se comprueba la señal que aparece en el bus seatalk con osciloscopio. Como la transmisión Seatalk se autocomprueba en recepción (digital looback), si se identifica transmisión correcta en el osciloscopio, la recepción también lo será. La recepción en Seatalk es OK si véis secuencias de 1 destello largo (0,3 segundos cada 1,6 segundos) en el led verde. -> Seatalk1 OK.

5- Se empareja el mando con el Rem072F, Se comprueban todos los botones mirando la salida Seatalk con el osciloscopio.

6- Se conecta una salida serie del PC a cada una de las entradas NMEA0183, se inyecta vía serie (RS232 -> RS422) el fichero VDR con un software llamado Hercules, y se comprueban la salidas del otro canal NMEA0183 y de Seatalk con el osciloscopio. Y aquí está el fallo: Aunque se ve señal en esas salidas, y el hardware funciona, no es posible identificar en el osciloscopio los datos AIS. La identificación del inicio las tramas (sincronización con $ o !) se hace a bajo nivel dentro de la interrupción de la USART del uC, y faltaba el reconocimiento del "!" correspondiente al AIS para el canal 2.

7- Los equipos se almacenan etiquetados en sus cajas con el software precargado, pero antes de despacharse se actualizan con el último software vía WiFi, con el fichero que he colgado en el link (como es el caso) .

[Tehani]

Las secuencias de destellos del led verde para la recepción de datos del Rem072F es la siguiente:

Toda la secuencia dura 1,6 segundos. Cada bit a 1 significa un destello de 0,1 segundos:

N2k: 0000 0000 0001 0101 (3 destellos cortos)
Seatalk1: 1110 0000 0000 0000 (1 destello largo de 0,3 segundos)
WiFi: 0000 0001 0100 0000 (2 destellos cortos)
USB: 0000 0110 0000 0000 (un destello medio de 0,2 segundos)
NMEA0183 (1 y 2) 0000 0000 0011 0011 (dos destellos de 0,2 segundos).

Con este espaciado de bits se intentó que los canales pudieran ser identificados aunque se conectara todo a la vez, pero en la práctica es un lío.
Si tenéis algún problema con un canal, lo mejor es desconectar los demás y observar el led para ese canal.
Me falta añadir toda esta docu en el manual...

En el ATM105 hay un led para cada canal y la identificación es más fácil.

[josefu]

Para futuras versiones, si lo crees oportuno, yo añadiría lo siguiente:

- Poder actualizar sin tener que acceder físicamente al equipo (en mi caso esta detrás de un panel atornillado). Entiendo que lo haces por seguridad, para que el usuario no pueda cargar un fichero cuando quiera, pero bueno, hay opciones para evitarlo. También es verdad que probablemente las actualizaciones no sean tan habituales. 

- Una ventana de debug vía web que te mostrase lo que entra/sale por cada canal: algo activable y que por ejemplo guarde los últimos 100 registros o 60 segundos

[Tehani]

En el manual de tu furuno (Especificaciones SP3) dice lo siguiente:

4.5 Datos de entrada IEC 61162-1 (NMEA 0183 Ver1.5/2.0) 
Posición del barco propio: GGA>RMC>RMA>GLL 
Velocidad del barco: RMC>RMA>VTG>VHW 
Demora (Verdadera): HDT>HDG*1>HDM*1>VHW 
Demora (Magnética): HDM>HDG*1>HDT*1>VHW 
Rumbo: RMC>RMA>VTG 
Profundidad del agua: DPT>DBT>DBS>DBK 
Viento: MWV>VWT>VWR 
Temperatura del agua: MTW SP - 4 
Hora: ZDA

No he visto pantallas o referencias a visualización de tipo dashboard, pero estas especificaciones hacen sospechar que es capaz de representar datos de heading, viento, corredera, profundidad y temperatura del agua. (Lo que entrega el bus Seatalk).
El Rem072F traduce los datagramas Seatalk a las sentencias anteriores en negrita.

Para que este plotter disponga de esos datos, tienes que hacer que el Rem072 "los mezcle o multiplexe" con los del AIS y GPS.
Para eso, haz lo que te dije:
- Conecta el AIS sólo a la entrada del canal 2 del Rem072F. Obtenemos así datos GPS y AIS.
- Conecta la entrada del Plotter Furuno (38400) a la salida del canal 2 de NMEA0183 del rem072. Así, el Plotter tendrá también los datos de seatalk en formato NMEA.
- Habilita la salida de todos los datos por el canal 2 del Rem072F en el setup. Es "legal" hacerlo porque el canal 2 se conectará a dos equipos diferentes en entrada y salida, y no aparecerán bucles de datos.
- Como tu Furuno es antiguo, te recomiendo que actives el cálculo de la declinación actualizada según el modelo geomagnético mundial de 2020 de la NOAA, en el setup del Rem072. Esto hará que se rellene el campo de declinación de la sentencia RMC que tu AIS deja vacío, antes de ser reenviada al plotter y a todos los demás (WiFi, Seatalk, USB).

El Rem072F será pequeño, pero casi tan matón como su hermano ATM105... (Perdonadme, es amor de padre).

[Tehani]

Para futuras versiones, si lo crees oportuno, yo añadiría lo siguiente:

- Poder actualizar sin tener que acceder físicamente al equipo (en mi caso esta detrás de un panel atornillado). Entiendo que lo haces por seguridad, para que el usuario no pueda cargar un fichero cuando quiera, pero bueno, hay opciones para evitarlo. También es verdad que probablemente las actualizaciones no sean tan habituales. 

- Una ventana de debug vía web que te mostrase lo que entra/sale por cada canal: algo activable y que por ejemplo guarde los últimos 100 registros o 60 segundos

Lo de la actualización sin pulsar el botón lo he valorado muchas veces. Es la batalla entre la seguridad y simplicidad con seguridad.

Pongo un caso verídico: Un usuario que cambió el nombre de la WiFi y el password. Se olvidó del password después de 2 años y preocupado se puso en contacto conmigo.
Le dije que no había ningún problema, al pulsar el botón de setup al arrancar, el ATM105 (y también el Rem072) recupera su SSID y password de fábrica para entrar en el setup, y una vez allí, presenta el SSID y password que puso el usuario en su día y que siguen siendo válidos para el funcionamiento normal.

Esta útil característica no se puede conseguir de ninguna otra manera, y siempre acabo aparcando el tema puesto que las actualizaciones son cada vez menos frecuentes. Por supuesto, en el caso del Rem072 ya partimos de una última versión del ATM105 super-rodada. Esto ha sido la excepción que confirma la regla.

En cuanto a la ventana de debug vía Web, no es algo que pueda hacer yo. De hecho, OpenCPN tiene el plugin VDR justamente para hacer eso. Graba ficheros de texto con las sentencias que recibe y envía.
El prototipo ATM200 que hice algunos años atrás, permitía grabar los datos seleccionados por el usuario en tarjeta microSD en formato excel. De hecho era muy útil porque permitía grabar los datos MMSI, velocidad y rumbo de los blancos AIS próximos que tuvieran una velocidad superior a 0.5 nudos (servía como caja negra).
El usuario podía establecer cada cuántas horas cerrar fichero y abrir uno nuevo y el tiempo de muestreo en segundos. Los nombres de los ficheros se generaban automáticamente según día, hora y minuto de creación.
Se interesó un agente de seguros, pero se aparcó porque no tuvo demanda.
Ahora muchos AIS tiene su slot para tarjetas SD y es menos interesante que lo tengan también los gateways Ocenav. Las escuelas náuticas certifican las horas de navegación así.

[josefu]

Lo de la actualización sin pulsar el botón lo he valorado muchas veces. Es la batalla entre la seguridad y simplicidad con seguridad.

Pongo un caso verídico: Un usuario que cambió el nombre de la WiFi y el password. Se olvidó del password después de 2 años y preocupado se puso en contacto conmigo.
Le dije que no había ningún problema, al pulsar el botón de setup al arrancar, el ATM105 (y también el Rem072) recupera su SSID y password de fábrica para entrar en el setup, y una vez allí, presenta el SSID y password que puso el usuario en su día y que siguen siendo válidos para el funcionamiento normal.

Esta útil característica no se puede conseguir de ninguna otra manera, y siempre acabo aparcando el tema puesto que las actualizaciones son cada vez menos frecuentes. Por supuesto, en el caso del Rem072 ya partimos de una última versión del ATM105 super-rodada. Esto ha sido la excepción que confirma la regla.

No es incompatible el botón con lo comentado. El botón debería estar siempre, como el "reset" de fábrica de cualquier dispositivo.

En cuanto a la ventana de debug vía Web, no es algo que pueda hacer yo. De hecho, OpenCPN tiene el plugin VDR justamente para hacer eso. Graba ficheros de texto con las sentencias que recibe y envía.
El prototipo ATM200 que hice algunos años atrás, permitía grabar los datos seleccionados por el usuario en tarjeta microSD en formato excel. De hecho era muy útil porque permitía grabar los datos MMSI, velocidad y rumbo de los blancos AIS próximos que tuvieran una velocidad superior a 0.5 nudos (servía como caja negra).
El usuario podía establecer cada cuántas horas cerrar fichero y abrir uno nuevo y el tiempo de muestreo en segundos. Los nombres de los ficheros se generaban automáticamente según día, hora y minuto de creación.
Se interesó un agente de seguros, pero se aparcó porque no tuvo demanda.
Ahora muchos AIS tiene su slot para tarjetas SD y es menos interesante que lo tengan también los gateways Ocenav. Las escuelas náuticas certifican las horas de navegación así.

Yo me refería más a una ventana para ver qué ocurre en cada uno de los puertos, nada de guardar, sería en ram, por eso lo de que este limitado por número de mensajes y/o minutos, además de que no este activado siempre, sólo cuando es necesario.
Es una forma de ver qué te están enviando los puertos y descartar problemas.

Pero ya te digo, es simplemente una observación, una vez montado el equipo, lo normal es no tocarlo más.