[josefu]

Ayer me llego el Rem072F y estuve haciendo algunas pruebas en casa, a ver si este fin de semana puedo montarlo.

He re-hecho el esquema, centrándome sólo en el multiplexor para que no quede muy lioso y he pensado en conectarlo todo así:

   

1. La seta GPS de Furuno la desconectaré del plotter y la conectaré a la radio VHF.
2. La VHF, por la salida NMEA "lenta" pasará los datos de GPS al Navtex (también podría conectar el GPS directamente al Navtex)
3. Conectaré la VHF por la salida NMEA para el AIS con el Rem072F.
4. Conectaré el MDF de Furuno por NMEA "rápido" al Rem072F
5. La red seatalk a la conexión pertinente en el Rem072F

Mi mayor duda es el tercer punto, ya que no se si la Navicom saca por la salida para el AIS todos los datos NMEA que genera (datos del GPS recibidos por el otro canal NMEA y las sentencias generadas por ella). He estado mirando el manual pero no dice que sentencias salen.

Como también pensaba añadir un un emisor ais en el futuro (el em-trak B921), si veo que no salen los datos esperados, probablemente ya montaría una red NMEA2000 y conectaría ahí el AIS, eliminando la conexión para AIS de la VHF.

[Tehani]

Ayer me llego el Rem072F y estuve haciendo algunas pruebas en casa, a ver si este fin de semana puedo montarlo.

He re-hecho el esquema, centrándome sólo en el multiplexor para que no quede muy lioso y he pensado en conectarlo todo así:



1. La seta GPS de Furuno la desconectaré del plotter y la conectaré a la radio VHF.
2. La VHF, por la salida NMEA "lenta" pasará los datos de GPS al Navtex (también podría conectar el GPS directamente al Navtex)
3. Conectaré la VHF por la salida NMEA para el AIS con el Rem072F.
4. Conectaré el MDF de Furuno por NMEA "rápido" al Rem072F
5. La red seatalk a la conexión pertinente en el Rem072F

Mi mayor duda es el tercer punto, ya que no se si la Navicom saca por la salida para el AIS todos los datos NMEA que genera (datos del GPS recibidos por el otro canal NMEA y las sentencias generadas por ella). He estado mirando el manual pero no dice que sentencias salen.

Como también pensaba añadir un un emisor ais en el futuro (el em-trak B921), si veo que no salen los datos esperados, probablemente ya montaría una red NMEA2000 y conectaría ahí el AIS, eliminando la conexión para AIS de la VHF.

Josefu, voy a ahorrarte trabajo.

La radio NAVICOM no va a reenviar datos de GPS por su salida "lenta".
Por eso, conecta la salida NMEA0183 de la seta GPS al furuno tal como estaba, y en paralelo conecta esa misma seta también al REM072 y a la entrada GPS de la radio. Una salida NMEA0183 puede alimentar perfectamentea a varias entradas NMEA0183. (No al revés).

El manual de la radio no es demasiado explícito con las sentencias que salen y por dónde salen, pero se puede deducir que por la salida "lenta" salen los mensajes DSC y por la "rápida" sólo los datos AIS.

Total. Conecta la salida GPS a IN1- del REM072, y la del AIS a IN2-. IN1+ e IN2+ déjalas al aire de momento. Sólo se conectarán si el GPS o el AIS tienen salida diferencial.
Asegúrate de que el canal 2 del REM072 está configurado a 38400 baud.

[josefu]

Como comenté, a principios de semana me llego el rem072f y he estado probándolo en casa antes de montarlo en el barco.

Sería bueno que se unificasen los conceptos "server/client", "input/output" del dispositivo ya que en función del modo de configuración o las etiquetas, pone una cosa u otra. Para explicarme mejor, pongo algunas capturas:

- En las pegatinas que lleva el dispositivo pone lo siguiente:
UDP server: 40.0.20.1:1433
       client: 45.0.20.1:2433

   

   
- Cuando arranca y te conectas a él, pone lo siguiente:
Protocol: UDP
Address: 45.0.20.1
Input DataPort: 1443
Output DataPort: 2433

   


- Si lo pones en modo configuración, pone lo siguiente:
UDP output port: 1433
UDP input port: 2443

   

Esto es un poco lioso y puede llevar a errores. Por lo que entiendo y corregidme si me equivoco el rem072f hace lo siguiente:
- Lee los paquetes UDP enviados al puerto 2443 de la IP de broadcast de la red
- Envía los paquetes UDP generados por él al puerto 1443 de la IP de broadcast de la red

Después de algunos pequeños detalles para poder configurarlo como cliente WiFi, que es cómo me interesa para el barco, lo configuré conectado a la red de mi casa. Una vez conectado, obtiene por DHCP la IP 192.168.88.113 (se la he fijado en el router para evitar cambios mientras lo pruebo).

La red de mi casa es 192.168.88.0/24 por lo que la IP de broadcast sería 192.168.88.255.

   

Como no tengo ningún GPS para conectar por sus puertos, decido usar la raspberry (IP 192.168.88.121) con openplotter y signalk para enviar las sentencias nmea por red de un gps usb que tengo por aquí y configuro un plugin para enviar tráfico nmea por udp a la ip de broadcast:

   


Veo que en el portátil (IP 192.168.88.108) sí que recibo las sentencias, utilizo la herramienta "ngrep" para capturar el tráfico de red:
   


Entonces supongo que ya debería estar y que el rem072f debería leer estas sentencias y distribuirlas por el puerto 1443 como esta configurado, pero si hago una captura de red, veo que no me llega nada:

   

Si configuro opencpn para recibir el tráfico del puerto 2443, veo que sí que me llegan sentencias:
   

Pero si lo configuro para que lea del rem072f como pone en el manual, no me llegan.

Tengo claro que el problema es que el rem072f no esta leyendo el stream de datos que envía la raspberry, pero ¿por qué? ¿no es así como hay que enviárselo?

Al principio pensé que había entendido al revés el tema de los puertos, pero los intercambié y seguía sin recibir datos.

¿qué estoy haciendo mal?

Supongo que es la configuración de signalk enviando datos al rem072f, pero si no es así ¿cómo los tendría que enviar?

[pinguino]

Llámame tiquismiquis pero me parece que tu estas enviando datos por el puerto 2443 mientras que el aparatito parece que los espera en el 2433 ¿no? Prueba con ese a ver si suena la flauta. Tal vez sea un bug de ese tipo. Al menos en las capturas yo siempre veo el 2433.

[josefu]

Llámame tiquismiquis pero me parece que tu estas enviando datos por el puerto 2443 mientras que el aparatito parece que los espera en el 2433 ¿no? Prueba con ese a ver si suena la flauta. Tal vez sea un bug de ese tipo.

Madre mía... Ya decía yo que no podía ser...

La dislexia! Seguro que no iba a funcionar.

[pinguino]

No te fustigues. Un servidor ha caído en fallos de esos taaaantas veces. 

[josefu]

Mi gozo en un pozo   

Pensaba que todo se debía a mi mala vista o falta de atención y resulta que no.

He cambiado los puertos por los que de verdad están configurados (1443 y 2433) y no veo que me lleguen datos por el 1443. Izquierda lo que se se envía al 1433 y derecha lo que se envía al 2433:

   

[josefu]

Por si acaso he vuelto a dejar el equipo con los puertos que viene de casa y en modo punto de acceso, pero nada.

Esperare la respuesta de Tehani a ver qué me dice.

[pinguino]

En  mi opinión el tema de la red esta Ok. Tehani es quien te confirmará cual es exactamente el comportamiento del equipo y que hace con los datos que recibe por UDP 2433. Tal vez no los re envíe para evitar bucles infinitos y solo envíe sus propios datos ... o cosas así.

[Tehani]

Como comenté, a principios de semana me llego el rem072f y he estado probándolo en casa antes de montarlo en el barco.

Sería bueno que se unificasen los conceptos "server/client", "input/output" del dispositivo ya que en función del modo de configuración o las etiquetas, pone una cosa u otra. Para explicarme mejor, pongo algunas capturas:

- En las pegatinas que lleva el dispositivo pone lo siguiente:
UDP server: 40.0.20.1:1433
       client: 45.0.20.1:2433



   
- Cuando arranca y te conectas a él, pone lo siguiente:
Protocol: UDP
Address: 45.0.20.1
Input DataPort: 1443
Output DataPort: 2433




- Si lo pones en modo configuración, pone lo siguiente:
UDP output port: 1433
UDP input port: 2443



Esto es un poco lioso y puede llevar a errores. Por lo que entiendo y corregidme si me equivoco el rem072f hace lo siguiente:
- Lee los paquetes UDP enviados al puerto 2443 de la IP de broadcast de la red
- Envía los paquetes UDP generados por él al puerto 1443 de la IP de broadcast de la red

Después de algunos pequeños detalles para poder configurarlo como cliente WiFi, que es cómo me interesa para el barco, lo configuré conectado a la red de mi casa. Una vez conectado, obtiene por DHCP la IP 192.168.88.113 (se la he fijado en el router para evitar cambios mientras lo pruebo).

La red de mi casa es 192.168.88.0/24 por lo que la IP de broadcast sería 192.168.88.255.



Como no tengo ningún GPS para conectar por sus puertos, decido usar la raspberry (IP 192.168.88.121) con openplotter y signalk para enviar las sentencias nmea por red de un gps usb que tengo por aquí y configuro un plugin para enviar tráfico nmea por udp a la ip de broadcast:




Veo que en el portátil (IP 192.168.88.108) sí que recibo las sentencias, utilizo la herramienta "ngrep" para capturar el tráfico de red:



Entonces supongo que ya debería estar y que el rem072f debería leer estas sentencias y distribuirlas por el puerto 1443 como esta configurado, pero si hago una captura de red, veo que no me llega nada:



Si configuro opencpn para recibir el tráfico del puerto 2443, veo que sí que me llegan sentencias:


Pero si lo configuro para que lea del rem072f como pone en el manual, no me llegan.

Tengo claro que el problema es que el rem072f no esta leyendo el stream de datos que envía la raspberry, pero ¿por qué? ¿no es así como hay que enviárselo?

Al principio pensé que había entendido al revés el tema de los puertos, pero los intercambié y seguía sin recibir datos.

¿qué estoy haciendo mal?

Supongo que es la configuración de signalk enviando datos al rem072f, pero si no es así ¿cómo los tendría que enviar?

Bueno, es el tema eterno:

Como el Rem072F está recibiendo datos GPS por WiFi, entiende que esos datos ya están presentes en esa red, y por lo tanto no los reenvía.
Esto se hace para evitar bucles de datos, y opera de la misma manera también en todos los canales cableados: Seatalk, NMEA0183(1), NMEA0183(2), NMEA2000 y USB.

Es decir, por cada canal sale todo menos lo que le llega por ese canal.
Excepciones:
1- Se puede forzar a que la salida del canal 2 de NMEa0183 saque todos los datos, incluso los que le llegan por esa entrada (eso está en el setup).
2- Por el canal 1 de NMEA0183 nunca saldrán datos AIS porque opera siempre a baja velocidad (4800).
3- Por el canal 2 de NMEA0183 saldrán datos AIS cuando se configure a velocidad igual o superior a 38400. Lógicamente, eso cuando el AIS esté conectado a NMEA2000, no a esa entrada.

NOTA:
Para que varios dispositivos en la red WiFi puedan transmitir sus datos, y el resto los vea, es necesario el los dos puertos (entrada y salida) tengan el mismo número.

[Tehani]

Añado lo que he contestado a Josefu en un privado:

En lo que se refiere a los puertos, podríamos decir que son como los canales de radio. Para que un receptor oiga al emisor, se necesita que los dos usen el mismo canal. Un ejemplo al respecto: Si el GPS envía por el puerto 2443, el receptor deberá escuchar por ese puerto como entrada.
De la misma manera, es posible utilizar el mismo número de puerto como entrada y salida, pero he observado algún problema alguna vez y por eso establezco opciones de selección de puerto independientes para salida y entrada en las centrales Ocenav. No obstante, en tu caso, si hay alguien más que envía datos, y todos los demás tienen que recibirlos, es necesario unificar el número de puerto como salida y entrada.

Cuando los puertos de salida y entrada son distintos es el mismo caso en que una radio emitiera por un canal y recibiera por otro. En este caso, sólo se entenderá con otra radio que opere al revés.
Por ejemplo: Una radio emite por el 23 y recibe por el 24. La segunda radio debería emitir por el 24 y recibir por el 23. Pero si pones una tercera radio de ese tipo, qué pasa?. Pues que sólo podrá establecer comunicación completa con una de las dos anteriores, pero no con las dos.

[Tehani]

Más cosas:
Si una app de un dispositivo móvil usa un puerto de forma permanente (Es el caso de apps para navegación como iRegatta, OpenCPN, iSailor, NKE, SailTracker, SeaWi, etc, etc), ese puerto no podrá usarse por otra app en ese mismo dispositivo móvil. Antes habrá que cerrar la que lo tenga en uso para liberarlo.

[gypsylyon]

Como comenté, a principios de semana me llego el rem072f y he estado probándolo en casa antes de montarlo en el barco.

Sería bueno que se unificasen los conceptos "server/client", "input/output" del dispositivo ya que en función del modo de configuración o las etiquetas, pone una cosa u otra. Para explicarme mejor, pongo algunas capturas:

- En las pegatinas que lleva el dispositivo pone lo siguiente:
UDP server: 40.0.20.1:1433
       client: 45.0.20.1:2433



   
- Cuando arranca y te conectas a él, pone lo siguiente:
Protocol: UDP
Address: 45.0.20.1
Input DataPort: 1443
Output DataPort: 2433




- Si lo pones en modo configuración, pone lo siguiente:
UDP output port: 1433
UDP input port: 2443



Esto es un poco lioso y puede llevar a errores. Por lo que entiendo y corregidme si me equivoco el rem072f hace lo siguiente:
- Lee los paquetes UDP enviados al puerto 2443 de la IP de broadcast de la red
- Envía los paquetes UDP generados por él al puerto 1443 de la IP de broadcast de la red

Después de algunos pequeños detalles para poder configurarlo como cliente WiFi, que es cómo me interesa para el barco, lo configuré conectado a la red de mi casa. Una vez conectado, obtiene por DHCP la IP 192.168.88.113 (se la he fijado en el router para evitar cambios mientras lo pruebo).

La red de mi casa es 192.168.88.0/24 por lo que la IP de broadcast sería 192.168.88.255.



Como no tengo ningún GPS para conectar por sus puertos, decido usar la raspberry (IP 192.168.88.121) con openplotter y signalk para enviar las sentencias nmea por red de un gps usb que tengo por aquí y configuro un plugin para enviar tráfico nmea por udp a la ip de broadcast:




Veo que en el portátil (IP 192.168.88.108) sí que recibo las sentencias, utilizo la herramienta "ngrep" para capturar el tráfico de red:



Entonces supongo que ya debería estar y que el rem072f debería leer estas sentencias y distribuirlas por el puerto 1443 como esta configurado, pero si hago una captura de red, veo que no me llega nada:



Si configuro opencpn para recibir el tráfico del puerto 2443, veo que sí que me llegan sentencias:


Pero si lo configuro para que lea del rem072f como pone en el manual, no me llegan.

Tengo claro que el problema es que el rem072f no esta leyendo el stream de datos que envía la raspberry, pero ¿por qué? ¿no es así como hay que enviárselo?

Al principio pensé que había entendido al revés el tema de los puertos, pero los intercambié y seguía sin recibir datos.

¿qué estoy haciendo mal?

Supongo que es la configuración de signalk enviando datos al rem072f, pero si no es así ¿cómo los tendría que enviar?

El rem072f envía datos por el puerto 1443. Es decir tienes que poner este puerto 1443 como entrada de datos en opencpn.
El rem072f recibe datos porcel puerto 2433, osea este puerto 2433 lo tienes que poner como salida en opencpn.

[Tehani]

Para hacer pruebas en casa puedes usar también la conexión USB.
Así verás lo que le llega al Rem072 por WiFi. Lo que le llegue lo reenviará por USB.

Cuando lo conectes en el barco, con todas las entradas NMEA0183, NMEA2000 y Seatalk, verás que todos esos datos los tendrás en la WiFi y USB, y viceversa.

[josefu]

El esquema ha variado (otra vez):

   

Como el AIS tengo que ponerlo y me hace falta un GPS, finalmente he decidido comprar ya el AIS (un em-trak B921) que incluye GPS y que además tiene dos puertos NMEA 0183 que retransmiten la información que les llega. Así ya puedo conectarlo todo y si por lo que sea la AIS no hace lo que se espera, siempre puedo montar ya una red NMEA 2000 y conectarlo por ahí.

Ya tengo montado el Rem072F y conectado a la red seatalk, a ver si esta tarde puedo dejar ya conectados también la VHF y el Navtex y así ya sólo me faltaría conectar el AIS.