![]() |
|
|
|
| VHF: Canal 77 |    | ![]() |
![]() |
![]() |
![]() |
![]() |
|
|
|
#1
|
||||
|
||||
|
Podría ser un bug de opencpn 4.0.
A mi, en Linux no me funciona la salida de opencpn en localhost:10110. En cambio la salida 0.0.0.0:10110 sí que funciona aunque solo en mi propia máquina. En tu captura veo que envías a 10.42.233.49:10110 que supongo es la IP local de tu pc. Pues bien, si envio a mi IP local tampoco me funciona. He intentado hacerlo funcionar en otras IPes como 1.1.1.1 o 0.0.0.1 o 255.255.255.255, y no funciona en ninguna. Así que o se trata de un bug o de alguna característica especifica de opencpn (que no comprendo) que han añadido ahora. Prueba a enviar a 0.0.0.0:10110 y ver si otros dispositivos de la red pueden leer en esa IP... aunque no lo creo. O intenta correr una distribución Linux en modo Live-USB y ver como se comporta opencpn con ella. Es para ir despejando dudas. Por otro lado, usando UDP si funciona. Solo que te toca crear una conexión especifica para cada dispositivo que necesite datos NMEA0183. Pero al menos me funciona. Lo digo por que como usuario de uindous no puedes aprovechar las ventajas de kplex. Yo sin embargo, sí uso kplex para multiplexar, y localhost:10110 funciona perfectamente, así que descarto que sea un problema del sistema operativo. Mas bien me da la impresión de ser un bug de opencpn 4.0. ¿Podéis comprobarlo los demás? Editado por ... en 16-03-2015 a las 11:42. |
|
#2
|
||||
|
||||
|
Hace dias realizando pruebas de OpenPlotter me di cuenta de comportamientos extraños de ese tipo que comenta pinguino y no solo en la version 4 de opencpn, tambien en la 3.2.
sospecho que opencpn crea una conexión TCP cliente siempre. a no ser que la IP sea 0.0.0.0 que entonces la conexión creada será server. puede que este sea el motivo del problema de ruebnsprim ya que opencpn tarda entre 7 y 10 segundos en intentar reconectar un cliente que ha perdido la conexión. en la imagen que adjunta se ve que funciona bien pero va perdiendo la conexión hasta que la vuelve a recuperar para volverla a perder. creo que usando 0.0.0.0 en el ordenador del GPS se le le solucionará porque será un server y se mantendrá abierto esperando otras conexiones de los otros ordenadores que apunten a él. la verdad es que si que es rara este gestion que hace opencpn de las conexiones pero intentando aplicar una interfaz grafica de kplex a OpenPlotter me he dado cuenta de las combinaciones posibles y lo complejo del tema y seguramente habrán optado por esta estrategia para simplificarlo. |
|
#3
|
||||
|
||||
|
gracias a todos..
![]() ![]() ![]() ![]() Probe a poner la >IP de 0.0.0.0 y el programa en su version 4.0. simplemente se apaga y deja de funcionar, he intentado tambien cambiar las IP que me decis y tampoco va . Actualmente lo tengo en funcionamiento ,con el mismo corte de transmision de datos, cada 7 seg en la version 3.2. que por lo menos transmiote algo , ya que la 4.0 nada de nada. Un abreazo a todos y seguiremos intentandolo o llamaremos a los creadores de este fantastico programa |
|
#4
|
||||
|
||||
![]() ![]() ![]() EL PROBLEMA CONTINUA¡¡¡¡¡ Sigo recibiendo la señal a borbotones de paquetes de 7 seg aprox... Espoerare a ala nueva version del open para ver si ya viene mejorada la conexion de red. Gracias y si teneis alguna opcion de ultima hoar os la agradeceria |
![]() |
Ver todos los foros en uno |
| Herramientas | |
| Estilo | |
|
|