Electrónica Proyecto OpenPlotter

[sailoog.com]

Originalmente publicado por Diavolo

:brin dis:
Voy a contar mas cosas que a lo mejor pueden ser interesantes.
Cuando estabamos haciendo pruebas con Pinguino en el Barco con la conexion a casa a través de TCP con Kplex, Yo cometía un error en casa en el server no poniendo "direction=in", el caso es que los barcos que recibia en el receptor de casa, automaticamente eran enviados al barco con la conexion 3G, de esto me di cuenta cuando Olaje, que tambien tiene sus barcos, al conectarse a mi servidor, a mi me aparecian sus barcos, y su equipo de viento, y todo, ahora no ocurre. Si no se pone en el servidor "direction=in" automaticamente es "direction=both" Lo mismo ocurria con el programita de Gilinas en UDP, pero este a lo bestia, en el servidor UDP de Kplex, no identifiqué nada, pues se convirtió en bidireccional, y la factura subió. Por supuesto que en el lado contrario hay que poner "direction=out" (barco)

Segun me comentan de localizatodo, el envío de datos tanto por TCP o UDP es el mismo, quizas TCP un poco mas, pero inapreciable, todo el aumento que he tenido ha sido por la bidireccionalidad.

Por lo que tengo que echarle un vistazo al archivo .kplex.conf que genera openplotter antes de ponerlo en el barco.

Tengo que hacer mas pruebas sobre openplotter, como el arranque al inicio de kplex, el persist=fromstart, ya que se corta la luz en casa, p.e. y kplex del barco se para, no se si openplotter lo vuelve a ejecutar cuando no hay una conexion.

Iré probando.

no te preocupes que openplotter define siempre in o out y nunca both para evitar esto. incluso en el caso de las entradas/salidas serie cuando un mismo dispositivo tiene que hacer las dos cosas crea dos instancias una de entrada y otra de salida, asñi incluso puedes usar baudios diferentes.

las entradas tcp siempre las define con persist=yes, retry=20, keepalive=yes. Con esto es suficente creo para volver a levantar una conexion cortada, 20 son los segundos entre intento de reconexión y es mejor que los 5 segundos por defecto demasiado agresivos.

Gracias a los maltratos que estas infringiendo a kplex se han conseguido mejorar el mismo kplex y por extensión openplotter asi que no pares de reportar cualquier tipo de nueva tortura a la que se te ocurra someterlos y sus resultados

Gracias!!!!

en proximo post añado tus fallos y mejoras al log de versión.

[sailoog.com]

OpenPlotter RPI v0.2.0


Fallos

- Definir una dirección en las entradas TCP debe ser obligatorio
- En salidas TCP la ip debe mantenerse. Ahora cambia a "todas direcciones". No debe ser obligatoria, si no hay nada cambia a "todas direcciones".


Mejoras

- Añadir información con la IP adquirida para cuando openplotter se conecta a red como cliente y tener acceso a NMEA y escritorio remoto via wifi
- Filtros de sentencias en kplex
- Cambiar definición "todas direcciones" a localhost porque se refiere a todas las direcciones que definen la maquina local.
- incorporar sistema de etiquetas de NMEA-0183 v4 de kplex para compatibilidad con localizatodo e identificación de conexiones (name=xx, srctag=yes)
........

Originalmente publicado por sailoog.com

...entradas/salidas serie cuando un mismo dispositivo tiene que hacer las dos cosas crea dos instancias una de entrada y otra de salida, asñi incluso puedes usar baudios diferentes.

Ojo con esto. Aunque kplex no se queja yo lo he probado y no funciona.

Si defino el mismo dispositivo usb-serie /dev/ttyUSB0 para entrada de AIS a 38400 y salida de NMEA a 4800.... kplex no se queja pero aunque la salida a 4800 funciona bien los datos de AIS no entran. O si entran lo hacen de modo ilegible (4800).

Compruébalo antes de implementarlo definitivamente o puedes tener informes de error con ese asunto.

[sailoog.com]

Originalmente publicado por pinguino

Ojo con esto. Aunque kplex no se queja yo lo he probado y no funciona.

Si defino el mismo dispositivo usb-serie /dev/ttyUSB0 para entrada de AIS a 38400 y salida de NMEA a 4800.... kplex no se queja pero aunque la salida a 4800 funciona bien los datos de AIS no entran. O si entran lo hacen de modo ilegible (4800).

Compruébalo antes de implementarlo definitivamente o puedes tener informes de error con ese asunto.

Ya lo comprobé y funcionó aunque creo recordar que usé 4800 y 9600 e igual no le dio tiempo a colapsar. Opencpn no lo soportó pero kplex si aunque siempre me quedó la duda de si las dos conexiones se había adaptado a una de ellas de manera silenciosa. Aunque ahora pienso que no porque se hubiera parado el flujo en alguna de ellas al estar las otras partes definidas a una velocidad....

De cualquier forma tambien se me ocurre ahora que es un poco de lógica no? si intento echar agua por dos tubos y este agua tiene que salir por un solo tubo igual de ancho que cada uno de los dos por donde echo agua pues lo logico es que se desborde no? igual con un recordatorio de esto seria sufiviente no? deberia de mantenerse esta posibilidad precisamente para facilitar lo contrario, aumentar el ancho del tubo de salida para que pueda absorver los dos de entrada.

ademas ya es demasiado tarde, ya está implementado en la ultima imagen