Re: Proyecto OpenPlotter
 

Como me ponen estas fotos :cunao::cunao::cunao:

Re: Proyecto OpenPlotter
 

Pues la verdad es que si. Cuando acabemos de implementar todo en lo que estamos trabajando openplotter será el producto más completo y versátil del mercado.

Es un plotter; es un sistema de domótica; es un receptor AIS y de VHF (ojo y proximamente emisor en forma experimental :) ); es un sistema de seguridad y control remoto de tu barco; puedes conectar todos los sensores imaginables; es un multiplexor; acepta, procesa y genera señales en los 3 formatos estándares de comunicación náutica NMEA 0183, Signal K, NMEA 2000; es un servidor y punto de acceso...

Y lo mejor de todo... gratis, divertido y didáctico... joer parece que fue ayer cuando lo único que intentábamos era poner en hora una lentiiiiiisima raspberry 1 con la hora del GPS :brindis:

Re: Proyecto OpenPlotter
 

La leche sería el tema de sonda propia......

Enviado desde mi SM-G928F mediante Tapatalk

Re: Proyecto OpenPlotter
 

Buenas tardes y :brindis::brindis:. Felicidades a los precursores del Proyecto, es una pasada.

Pregunta tonta a la cual no he logrado encontrarle respuesta:

Cómo hago para conectar los equipos en Nmea0183 a la RPi, es decir, debería tener tantos adaptadores Nmea-Usb como equipos tenga? o se puede conectar todo al mismo adaptador?. :nosabo:

Perdonen mi torpeza, uno no da para mucho:banghead:

Re: Proyecto OpenPlotter
 

Ademas creo que Openplotter tambien seria capaz de leer los sensores de profundidad y de viento. Esto lo veo interesante para los que tenemos electronica algo demode como la ST50 o la ST60. Respecto a la ST50 como ya no se fabrica, en caso de etropearse, hay que buscar de 2ª mano. Si la Raspberry lee los datos de los sensores, tendriamos tambien los datos en la Raspi

Re: Proyecto OpenPlotter
 

Si utilizas la Raspi con Openplotter como multiplexor, necesitas un adaptador NMEA-USB para cada equipo que quieras conectar, a no se que tengas un ploter que te mezcle ya los equpos. En este ultimo caso solo necesitarias uno, para que te lea los datos NMEA de salida del ploter.

Otra posibilidad es de utilizar un multiplexor comercial (p.e. de Shipmodul) que te multiplexe los equipos. Aunque siempre sera más economico utilizar la Raspi como multiplixeor con los adapatadores NMEA-USB

Re: Proyecto OpenPlotter
 

Ya me queda claro. Gracias!

:brindis:

Re: Proyecto OpenPlotter
 

Hola sailoog, enhorabuena por el trabajo que estais haciendo.
Acabo de ver el adaptador de CAN a USB y me pregunto si funcionaría con una red Seatalk NG, que es CAN Bus como la NMEA 2000 pero con sentencias propietarias de Raymarine. ¿Se conoce el formato y la codificación de estas?, ¿con el multiplexor se podrían transponer de N2K a STNG y viceversa?

Un saludo y una ronda para todos :brindis::brindis::brindis:. :capitan:teteluis

Re: Proyecto OpenPlotter
 

Tal como he comentado a capitanlamar no tengo acceso a ningun chisme de esos y no he hecho pruebas pero por lo que yo se son plenamente compatibles, es decir las sentencias (ahora llamadas PNG) son exactamente las mismas.

Raymarine se tuvo que acoger al estándar N2K para no quedarse fuera del mercado, pero como lo que a ellos les gusta es hacerte esclavo y dependiente de sus productos lo que hicieron es inventarse una conexión completamente diferente al estandar N2K, de hecho se inventaron 2, el seatalk 2 y el seatalk ng incompatibles entre ellos :nosabo:

Resumiendo, en teoría pelando un cable seatalk ng y conectando los cables CANH y CANL a nuestro CAN-USB Stick funcionaría sin problemas. Pero no lo he probado.

Re: Proyecto OpenPlotter
 

Dudas que tengo sobre el MNEA2000

En mi barco toda la electrónica es vieja, seatalk y NMEA183.
Empieza a dar problemas, el viento no saca seatalk, falla, etc, y esta ya muy vieja la pobre.

Entonces: ¿puedo poner sensores de viento corredera y sonda NMEA2000 y olvidarme de los instrumentos (pantallas)?

No se como esta el tema de instrumentación NMEA2000, pero si he de cambiar la veleta y poner lo mismo que tengo ahora pero con el nuevo NMEA me parece un atraso, y un gasto enorme. Si puedo poner solo el sensor, ver en la tablet el viento, y mas adelante si quiero poner una pantalla multifuncion, me parece mas lógico.

Un saludo

Re: Proyecto OpenPlotter
 

Claro. Deberás instalar una red NMEA 2000 y luego puedes conectar solo los aparatos que quieras, tanto sensores como ploters o pantallas. Para enviar los datos a la tablet o telefono necesitas algo que reciba la señal NMEA 2000 y la pueda enviar por wifi. En la tablet o telefono necesitas alguna aplicacion capaz de leer lo que le estes enviando.

OpenPlotter recibe N2K y te lo envía por wifi. No hay aplicaciones que puedan manejar NMEA 2000 asi que deberás convertir esa señal a otro formato que puedan entender estas aplicaciones y el mejor sin duda es Signal K. Aun no existen muchas aplicaciones pero en los proximos meses emoezarán a aparecer como churros incluido OpenCPN.

Re: Proyecto OpenPlotter
 

unos:brindis:
y necesito un poco de ayuda
situacion
raspberry pi 2
openplotter 0.7.1
gps azul chino
AIS antena digitaltech
monitor chino 7"
todo conectado al mechero.

Todo Funciona.
Despues de una hora de navegacion la pantalla del monitor se pone negra y el gps se apaga junto con el led rojo.
Desenchufo la raspberry y vuelvo a enchufar y tampoco anda nada.
Despues de unos dias reanudo la navegacion y trabaja todo nuevamente pero a la hora u hora y media nuevamente se produce el corte.
Pregunta : Que puede ser???
Pruebo en mi casa con otro monitor y solamente el gps y ya hace 3 horas que funciona...
Hay alguien a quien le haya pasado algo parecido??:sip:

Re: Proyecto OpenPlotter
 

Si deja de funcionar así, imagino que puede ser por calentamiento de algún componente o fallo en la alimentación (puede que por consumo disminuya la tensión).

Re: Proyecto OpenPlotter
 

El 90% de incidencias son debidas a la alimentación (el otro 10% a fallos de openplotter pero esos es rarisimo :cunao: )

No nos cuentas como tienes enchufado todo, si usas un hub o no, que conversor de 12v a 5v usas, etc. Vigila también con los cables usb, los que son muy finos no aguantan ni 1A. Prueba a conectar lo mínimo, esperar una hora y conectarle mas cosas hasta que pete.

Re: Proyecto OpenPlotter
 

Gracias por las respuestas.
E ire revisando todo tal como lo indican.
De todos modos no habia usado hub , o sea todo conectado a la raspberry y el conversor de 12 a 5 v ni idea, uno comercial de los que van al mechero y tienen salida hembra para usb.

Lo que no tengo claro :confused:es si teniendo dos entradas usb libres en la raspberry me conviene usar de todos modos el hub.

Gracias de nuevo y si se les ocurre otra cosa....los tendre al tanto de mis experiencias.
Salud y:brindis:

Re: Proyecto OpenPlotter
 

No se trata de entradas libres, se trata de un tema de alimentación. La raspberry puede suministrar un máximo de 1 amperio para alimentar todo lo que tengas conectado a sus puertos USB. Si le conectas cosas que requieran un total superior de amperios, todo te empezará a fallar. Con un hub autoalimentado esto se soluciona ya que es este el que suministra la correiente y deja a la raspberry libre de esta tarea y con todos los amperios que necesite para su funcionamiento estable.

De todas formas por el comportamiento de tus errores yo apostaria por una cuestion de cables debiles o que el adaptador del mechero es falso, el mercado está lleno de estos fakes.

Re: Proyecto OpenPlotter
 

Estimados :brindis:

Sigo ya hace algún tiempo el proyecto dentro de mis posibilidades, diría que estas son pocas en función de la actividad profesional, como aquí dicen el gana pan. De esta forma me dedico a lo que preciso específicamente, en este momento instalando placas solares. Dada esta actividad descubro que estos sistemas los mas económicos no están dirigidos a la actividad náutica y como consecuencia no consiguen gerenciar dos o tres bancos de batería.

Dado este motivo pensé hacerme un programita para el Arduino en que con lectura por los puertos analógicos establezca algunas condiciones sea para conmutar los bancos o distribuir a través del separador de diodos, haciendo una lectura del estado del las baterías y colocando condicionantes que si no confirmadas las respuestas esperadas se pueda aislar el banco defectuoso, ademas acciona alguna alarma, etc.

Como veo que están trabajando en otra liña con la Pi y convertidores AD, siendo posible accionar llaves o conmutadores , en que ya hicieron la corredera originalmente con Arduino, creo que algún experto en Python podría hacer esto que sugiero. Destaco existe también posibilidad de hacer la lectura directamente del controlador MPPT por un puerto RS 485 en que se puede colocar un accesorio o vía adaptador usb-Rs 485 (RJ45) software gratuito tener una serie de datos que eventualmente son de gran utilidad y servirían para colocar las mismas condiciones . Aquí otro problema seria el protocolo desconocido, fuera que ya hay otro conversor Rs 485 .

Vean estos links

https://www.youtube.com/watch?v=dFuZywwpfaU


https://www.youtube.com/watch?v=r3LrWeYYtnQ
:brindis:

Re: Proyecto OpenPlotter
 

Gracias por la idea. Pero podrias especificar un poco má que es lo la Raspberry deberia hacer. Entiendo que si ya tienes un controlador MPPT, que te hace esa vigilancia, no hace falta la Raspi. A no ser que te refieras a que sea la Raspberry la que hiciera de controlador MPPT.

Gracias por tu respuesta.:brindis:
Veo que el proyecto va muy bien y con mucho suceso.
Este final de semana analizando mi situación particular concluí que algunos sistemas tiene que ser descentralizados y autónomos por un problema de seguridad . Lo que no significa que no tengan una verificación por un sistema central la PI. Lo que no me parece es que si por algún motivo no deseado la PI para que los subestimas también lo hiciesen, bueno no me gustaría! Y es lo que sucedería si todo es comandado por el OpenPlotter.
Observo que en mi caso es mejor integrar subsistemas inteligentes, primero por lo antes dicho de la seguridad y por considerar que un arduino nano es barato , bueno en mi opinión estos sub sitemas también le darían plus al OpenPlotter . La ideá es que la raspberry y el arduino se complementen para hacer un sistemas mais seguro. Desde que sailoog lo haga claro, yo solo doy la idea.
Ej:
Si utilizamos un Arduino nano ( E$ 5,00) para hacer el conteo de pulsos del sensor flujo refrigerante que tu amablemente has compartido, y este por su vez acciona una alarma sonora y luminosa. Todavía con las entradas disponibles analógicas la utilizamos para fijar limites de temperatura , presión de aceite , etc ( Llamemos esto como modulo del motor ) y por su vez que todos estos datos se le informe a la PI…. Litros minuto, temperaturas, etc . Que todos estos datos sean enviados para OpenPlotter sea para presentarlos numéricamente y que también sean utilizados para generar alarme por fallas de lecturas hechas por el arduino, o mismo por falta de estas informaciones. Creo yo que estaríamos con un sistema realmente muy potente y seguro.
Cuidado yo creo que la substitución de la corredera a partir del GPS hecha por la PI es y esta perfecta, ya que si no tenemos corredera bien nos arreglamos. Lo mismo vale para la estación meteorológica, temperatura de la nevera e otras funcionalidades que se han dado a OpenPlotter. No se si me explico, muchas veces he tenido que hacer varias horas a motor por falta de viento. Y mi gran preocupación es si me quedo sin el motor por falta de refrigeración , será que va alarmar , y el bendito rotor de goma . Quien no ha pensado por esto? Es como la alarma de sentina, yo creo esencial una cigarra independiente solo para ella. Esta es solo mi opinión muy, pero muy personal, no quiero polemizar, claro.
Voy a lo mio.
Efectivamente tengo un regulador MPPT y el problema de estos reguladores es que solo administran un único banco de baterías. En general nosotros en la náutica tenemos dos o tres bancos de baterías, mínima mente dos, motor e servicio.
La idea inicial era colocar la PI para administrar la carga , conmutar bancos de batería en función da algunos parámetros predefinidos. Hoy por hoy creo que no se justifica que la PI haga esto, creo que es mejor hacerlo independiente con otro modulo ( arduino nano). Básicamente los parámetros los fijaría a partir de tensiones de referencia de las baterías y del panel solar. Para sofisticar lo podríamos medir las temperatura de cada batería en el momento de la carga , variación de la tensión en función del tiempo. Hay que detectar cuando una batería esta con defecto y observando algunos parámetros aislarla . Siempre podemos dar partida del motor haciendo un puente desde las baterías de servicio. No?
Ej practico. Dos baterías motor y servicio.
Como el cargado MPPT tiene que estar conectado directamente a un banco de baterías es de donde retira su alimentación (consumo 60mA) este estaría conectado a las baterías de servicio. Varios motivos ….
1º Mediría la tensión de la batería del motor, servicio y suministrada por las placas solares.
2º Establecería condiciones tales como:
PV> 15 V y TM < 12V habilite caga de batería motor , hasta TM > 13,80 V
TS> 14,4 V y TM < 12V Habilite carga de batería del motor Tm > 13,80V
3º Curva de incremento TM , si no es creciente en 10 minutos desligue carga batería motor , espere 1 hora repita , verificar temperatura batería, repita .
4º Condición de temperatura de baterías , alarmas etc

PD. Me gustaron los medidores de flujo. Solo saber si la de agua la resolución mínima seria suficiente, habla de 2 o 3 litros minuto.

También seria una pegada colocar los datos que da el modulo de MPPT via Rs 485 (Modbus) en el OpenPlotter

Re: Proyecto OpenPlotter
 

Sin duda es una forma valida de verlo, sin embargo yo concibo OP bajo otras premisas. Dudo que sea más barato tener multiples modulos autonomos en vez de uno solo por baratos que sean (el cableado de datos y alimentación o el wifi de cada modulo te saldrán mas caros al final). Estamos en el mar y todos sabemos que el entorno es agresivo y cualquier electronica debe ir muy bien protegida, no es lo mismo proteger 5 modulos que 1. La instalación sería mas compleja, "keep simple". Prefiero navegar con varias SD, otra raspberry de respeto y un ejercito de baratos sensores de repuesto que además tener que duplicar varios modulos independientes.

En fin, al final se trata de una decisión del usuario y cualquier estrategia es buena. Por ello OP es compatible con cualquiera de las dos. Puedes montar tanto un sistema centralizado como un sistema formado por modules independientes, porque ser una cosa si lo puedes ser todo? :) por ello OP dispone de la posibilidad de comunicarse de todas las maneras posibles, en la capa hardware y en la capa software mediante todos los protocolos existentes (NMEA 0183, NMEA 2000, Signal K)

:brindis:

Re: Proyecto OpenPlotter
 

El proyecto OpenPlotter está creciendo rápidamente y hace ya un tiempo desde la última versión estable asi que aquí está nuestra última compilación en Raspbian:

http://www.sailoog.com/es/blog/desca...otter-rpi-v080

Ya no cabe en una tarjeta de 4GB debido a la incorporación de nuevos paquetes asi que deberéis usar una de 8GB. Aunque la imagen es más grande (~4.8GB), los archivos comprimidos son mas pequeños debido a un proceso de optimización.

Ya estamos trabajando en la v0.9.0 cuyo principal objetivo será el de integrar completamente Signal K y N2K.

Gracias a todos por vuestro apoyo y contribuciones!!!

:velero:

Re: Proyecto OpenPlotter
 

Hola. Una ronda para todos/as:brindis:
Me bajo la nueva versión 08 en zip de Mega y cuando quiero descomprimirla sale un archivo grandisimo unos 180 GB.
No se si os pasa lo mismo? alguien la bajo?

Re: Proyecto OpenPlotter
 

Descargada la última versión e instalada, este fin de semana a probarla en el barco!!

Saludos

Re: Proyecto OpenPlotter
 

Idem
Saludos y:brindis:

Re: Proyecto OpenPlotter
 

Espero unirme en breve a los que ya disfrutáis de este proyecto :brindis: Hay alguna opción estandarizada de recibir datos meteo fuera de cobertura móvil?

Re: Proyecto OpenPlotter
 

Como antes dicho no se trata de polemizar y sin dudas si sos tu quien lo dices y " tu " concibes OP menos aun.
Mismo así creo que se trata de un trabajo colaborativo en que muchos aquí y en otros sitios colaboran con ideas, algunas buenas y otras solo ideas.

Me quedan dudas de lo que afirmas del cableado o bien no te he entendido o no es bien así. O tal vez le falte capacidad a la PI para procesar tanta información.
Reitero la idea es no polemizar, yo lo veo así .
Analicemos las informaciones mas básicas que eventualmente podemos querer del motor y de forma rápida y sin sofisticar mucho yo diría que mínimamente, a mi me gustaría saber que hay flujo de agua salada y que la temperatura del motor esta dentro de un rango predefinido. Porque? Bueno porque tengamos flujo de agua salada no significa que tengamos refrigeración del motor. Observa que para el ejemplo estoy dejando de lado flujo de combustible, presión de acetite, etc. En esta configuración mínima, TM , S. de flujo precisaríamos 4 hilos para llevar información +,- , Temp, Pulso. Detalle ha ser considerado. No se sabe hoy por hoy cual será el comportamiento del un conversor A/D, bajo la influencia de las posibles interferencias. Ademas que habría que cubrir todas las posibilidades de múltiplos usuarios. Les regalo el peludo de blindar la comunicación, pero les vale intentarl…. Radio, VHF, HF , repley del alternador , encendido de heladera, ruido del pwm del Piloto, pwm del conversor chino 12 /5V y por hay va. :cagoento:

A mi me queda claro que son justamente los motivo que tu das, los que justifica un modulo que comunique en forma serial bajo algún protocolo.
El problema de marinisación de un arduino nano se resume a un tubete de epoxi. Por otro lado el ejercito de sensores , SD , etc para mi es la misma. Los sensores porque no serian los mismo?

Lo que me gustaria.
En mi caso para el Motor y tal vez el de otros, un único arduino nano podría informar:
Temperatura del refrigerante.
Temperatura del agua de la salida escape.
Presión de aceite.
Flujo de refrigerante.
Flujo de diésel.
Corriente que esta entregando el alternador.
Conmutar los bancos de baterías.
Alarmar en algunos casos.
Mandar de forma serial toda la información por dos hilos comunes a OP.
Detalle el tamaño de el cableado seria mínima dada la proximidad de todos los elementos, la alimentación seria directa del motor

La esposa le pregunta al marido , querido que querés comer? El marido le responde que una unos tapas de jamón ibérico, queso …. . La esposa le responde, te pregunte que querías comer, no lo que te gustaría comer, preferís arroz con huevo o huevo con arroz. :cunao:

Cuanto te refieres a la comunicación vía, NMEA 0183, NMEA 2000, Signal K. Estos protocolos tienen reservadas sentencias que incorporen los medidores de flujo o la temperatura del motor, etc. Creo que no, y de ser así se complica. No?:nosabo:

:brindis:

Re: Proyecto OpenPlotter
 

Sobre el bus CAN, al cual se tiene acceso mediante OpenPlotter mediante un barato conversor CAN-USB, existen multitud de protocolos:

• ARINC 825 (para la aviación)
• CANaerospace (para la aviación)
• CAN Kingdom
• CANopen (para automatización industrial)
• CCP / XCP
• DeviceNet (para automatización industrial)
• EnergyBus (para vehículos eléctricos)
• GMLAN (de General Motors)
• ISO 15765-4
• ISO 11783 o ISOBUS (para la agricultura)
• ISO 14229
• SAE J1939 (para vehículos pesados)
• ISO 11992 (para trailers pesados)
• MilCAN
• NMEA 2000 (para la industria marina)
• OSEK
• RV-C (para vehículos recreacionales)
• SafetyBUS p (para la automatización industrial)
• SmartCraft
• Smart Distributed System (SDS)
• VSCP (para la automatización de edificios)

Algunos de ellos pensados para recoger datos y controlar dispositivos en vehículos con motor térmico o eléctrico.

Re: Proyecto OpenPlotter
 

No te preocupes, tengo bastante claro las diferencias entre una polémica y una discusión asi que puedes hablar con total libertad que aquí nadie se va a enfadar :)

También me viene al pelo tu mensaje para explicar como se toman las decisiones en un proyecto abierto, libre y colaborativo como este porque seguro que a alguien le interesa.

En primer lugar existe un lugar donde el código de un proyecto es expuesto publicamernte (repositorio), en nuestro caso es este: https://github.com/sailoog/openplotter
Ahí es donde reside la copia original (master) y diferentes copias del original que se usan para probar codigo nuevo y que será incorporado al master una vez se compruebe que no tiene fallos, estas copias dentro del mismo repositorio se llaman branches: https://github.com/sailoog/openplotter/branches
En este repositorio solo yo tengo permiso de hacer cambios con lo cual solo yo tengo la última palabra sobre la dirección que debe llevar el proyecto. Ahora viene lo bueno, cualquier persona puede hacer una copia de mi repositorio y entonces solo esa persona tendrá permisos para cambiar su copia, en nuestro caso estas son las copias que se han hecho de openplotter: https://github.com/sailoog/openplotter/network/members
Estas personas pueden cear sus propias branches dentro de su repositorio y añadir funcionalidades al programa. En cualquier momento esta persona puede enviar los cambios que ha hecho en su repositorio al repositorio original, el mio, para que yo decida si incluyo sus nuevas funcionalidades (pull request). En esta página esto se ve claramente: https://github.com/sailoog/openplotter/network
Las modificaciones que se han incorporado al repositorio original quedan incorporadas como ramas de este, pero lo mas importante que refleja esta gráfica es que hay ramas que no se han incorporado al repositorio original y siguen su curso independientemente.

Con esto intento mostrar que en caso de conflicto en la concepción del proyecto yo tengo siempre la última palabra en añadir cosas pero si no se llega a un consenso no puedo impedir que esa persona siga desarrollando esa concepción diferente del proyecto libremente. Todo queda reflejado y no hay dudas de la autoria de cada parte. Es una selección natural ya que si resulta que esa persona estaba en lo cierto y su concepción era la mas adecuada, la gente empezará a replicar su repositorio y evolucionar a partir de él y no del mio. Por lo tanto cualquier desarrollador de proyectos libres tendrá especial cuidado en analizar objetivamente cualquier cambio sugerido si no quiere que versiones mejores de su programa le pasen por delante. En el caso de OpenPlotter esto aun no ha pasado, las únicas inyecciones de código que se han rechazado han sido las que contenían errores y las ramas independientes que existen no han sido propuestas para incorporación al repositorio principal por las razones que sus autores hayan creído convenientes. Yo podría en cualquier momento "reclamar" esas modificaciones y añadirlas al repositorio principal clicando un solo botón aunque no hayan sido sugeridas.

Espero que esta explicación os sirva para entender porque algunos locos nos empeñamos en "regalar" nuestro trabajo. La calidad de un producto constantemente auditado por cientos de personas tiene que ser obligadamente muy alta y a la vez esa dinámica de desarrollo nos permite a simples desarrolladores individuales plantearnos grandes proyectos que sería imposible emprender por cuenta propia.

La mayoría de softwares propietarios y cerrados no durarían ni un solo dia en un entorno libre donde no hay trampas posibles. Si el famoso software de los motores volkswagen que engañó a medio mundo hubiera sido libre y abierto, jamas hubiera llegado a instalarse en un coche, hubiera ahorrado a sus creadores millones de euros en responsabilidades civiles y lo que es más importante, no solo mediría con más exactitud las emisiones sino que además probablemente habría versiones personalizadas que te enviarían datos a tu movil o te harían el cafe por la mañana :)

En cuanto al contenido de tu propuesta, algunas aclaraciones:

Como ya te comenté en mi último mensaje, tu propuesta de modulos independientes me parece tan valida como la de un solo modulo central y por eso en este momento OpenPlotter es compatible con ambas. Dependerá de las caracteristicas de cada barco o preferencias del usuario. Personalmente prefiero la simplicidad y emplear los menos dispositivos posibles y si me puedo ahorrar los arduino pues me los ahorraré.

De hecho creo que lo que estás buscando es algo como esto: https://bitbucket.org/R_P_Ryan/enginemonitor/wiki/Home en su momento crecé varios emails con el autor para asegurar la compatibilidad con openplotter y consensuamos el usar Signal K como comunicación pero por alguna misteriosa razón el tipo desapareció del mapa y no concluyó la implementación.

La Raspberry tiene capacidad para todo lo que enumeras y además para ejecutar opencpn, decodificar AIS, actuar como servidor y bailar una sardana :) y tengo mis dudas sobre la capacidad de un arduino nano para gestionar todos los sensores que necesitas y además generar la información en el protocolo escogido.

Al contrario de lo que supones, N2K y Signal K no solo contiene sentencias para manejar flujos, temperaturas de varios motores a la vez, etc. sino que SK también tiene sentencias para manejar sensores personalizados que no bubieran sido contemplados en su concepción.

En cuanto a las posibles interferencias que puedan haber en los convertidores AD ya han sido contempladas y existirán controles para realizar medias de mediciones y correctores o offsets.

Si decides trabajar en algunos de estos módulos independientes que comentas cuenta con toda la ayuda que necesites por mi parte para asegurar la plena compatibilidd con openplotter.

:brindis:

Re: Proyecto OpenPlotter
 

Dos preguntas rápidas,

- A fecha de hoy (he visto temas en el foro, pero de hace dos años), cuál es el mejor sistema para recibir AIS a través de una Raspberry con OpenP (por <50€)

- Ídem sobre cómo recibir datos meteo fuera de cobertura móvil (hago travesía de "zona1" en dos meses)

Lo anterior teniendo en cuenta que no me importa tener que configurar el equipo, pero sin saber de programación

Gracias :brindis:

Avante

Re: Proyecto OpenPlotter
 

Hola, ya probada la nueva versión 0.8 en navegación, con conexión al plotter y receptor ais, con grabación de ruta del barco y de los barcos ais, descarga de archivos Grib y sin ningún problema, funcionando correctamente.
Hay funcionalidades nuevas, que no he probado, como la recepción y transmisión VHF ¿Cómo funciona?

Saludos,

Re: Proyecto OpenPlotter
 

Tu aclaración realmente a mi me ha sido de mucha utilidad. :cid5::cid5:

Respeto tu opinión, la de tantos otros.
No por esto debo dejar de decir lo que creo, que es que te equivocas.
Un modulo es mucho mas económico que los cables y las horas dedicadas a solucionar problemas generados por el envió de información de forma analógica. Esto hoy por hoy es anticuado y complicado. No que no se pueda hacer, les deseo surete y mucha paciencia.


Lo voy a ver ...
Gracias.


No me refería a la capacidad del procesador y del control de varios procesos al mismo tiempo y si al manejar diversos protocolos de comunicación sin que estos entren en conflicto. Y esto no lo se por que esto no es lo mio.



No supongo nada, mucho menos de lo que desconozco.
Es bueno saber lo que dices, ya que de esta forma podremos buscar en las repositorios de arduino alguna biblioteca que sea compatible.


A lo que me refiero no lo corriges por la obtención de valores medios. Este recurso, por su vez compromete la única ventaja que puede tener un conversor AD, su grado de presión dependiendo si es 8 , 16 .... Los Arduinos dada su estructura y dependiendo dle conversor AD a que se comparen, pueden ser un poco mas imprecisos, estoy hablando de valores insignificantes para nuestros intereses. 0,05 Cº

Por otro lado los Arduinos no solo son mas baratos que los cables, como también lo son mas baratos que el conversor analógico digital, están prontos y son confiables. Soportan una infinidad de sensores pre-configurados.
Un único arduino nano

Input Voltage (limits) 6-20 V
Digital I/O Pins 14 (of which 6 provide PWM output)
Analog Input Pins 8 DC Current per I/O Pin

Length 45 mm Width 18 mm Weigth 5 g


Te lo agradezco y te informo.
Mi problema es que no tengo tiempo para dedicarme, mi trabajo no me lo permite. Esto de los protocolos me puede llevar tiempo, así que decidí y encargare dos arduinos nano, al primero lo voy hacer conmutar la distribución de carga de las baterías, medir temperaturas de las mismas cuando en carga, protecciones, etc . Y lo segundo medirá temperaturas de motor, flujo de circulación de agua, alarma vinculada, etc.
Solo después pensare en como integralo a OP para mi lo mas complicado.
( estudie bibliotecas , compativilidad ,etc)
El OP lo seguiré utilizando vía shipmodule :brindis:

Respuesta: Proyecto OpenPlotter
 

Hola a todos, voy a instalar esta semana el openplotter en el barco y le quería montar un teclado inhalambrico con trackpad incluido.
Hay algún modelo que no sirva, alguna característica, funcionan con el bluetooth directo ....

gracias

Re: Proyecto OpenPlotter
 

- Lo que buscas es un receptor SDR AIS, en nuestra pagina tenemos uno a la venta que está probado y si lo quieres encontrar más barato apunta las especificaciones y busca directamente en las paginas asiáticas. Tambien te servirá para escuchar la VHF.

- Fuera de cobertura movil me temo que lo mejor que tenemos es la radio de toda la vida a no ser que tengas conexión de datos satelite $$$. Las opciones de datos que tienes disponibles en HF son weatherfax y navtex pero estas están fuera del rango de frecuencias del SDR. OpenCPN tiene un plugin para capturar audio porcedente de una radio HF y decodificar weatherfax, pero necesitarás un adaptador USB con entrada de audio para la raspberry y evidentemente una radio con salida de audio, las portatiles son muy baratas <50. De esto último no hay mucha información y aun nadie ha corroborado su funcionamiento en OP, puedes usar navigatrix que si que hay más info.

Re: Proyecto OpenPlotter
 

Para la recepción VHF necesitas un receptor SDR (el mismo que se usa para el AIS) y solo tienes que abrirlo y teclear la frecuencia deseada. Te aparcerá el típico grafico de cascada donde podrás ver si hay movimiento en las diferentes frecuencias. Puedes escuchar toda la banda marina, la FM, etc.

La transmisión es experimental, quizás demasiado :) yo no me procuparia mucho a no ser que se tenga algo en mente. No necesitas ningun SDR ya que es la misma raspberry la que hace de modulador y emisor conectando unicamente un alambre a un pin del GPIO para que haga de antena. La Pi tiene estos secretos escondidos :). Si se usa hay que tener cuidado ya que la salida es bastante sucia y puede inutilizar todas las comunicaciones a bordo si no se usan filtros.

Re: Proyecto OpenPlotter
 

Me meto en la discusion ya que me siento aludido por el tema del conversor AD para la Raspi.

En primer lugar decir que mi experiencia con Arduino es cero, por lo que no puedo decir si el sistema que propones es mejor o peor.
Pero si tengo experiencia en sistemas inalambricos y te puedo decir que hay una gran diferencia entre sistemas fiables (mas caros) que otros sistemas y ladiferencia es grande. No te lo tomes a critica, ya he dicho que no tengo expriencia con arduino, pero un sistema barato como arduino, me pregunto si es fiable, constante y sin fallos de conexion para un velero o motora en condiciones marinas.
Mi lema es, cuanto mas sencillo, menos problemas. Y los cables son más sencillo y seguros que las conexiones por radio. Ademas en el barco hay muchas posibilidades de interferencia que pudieran afectar a la comunicacion de los módulus. pero no quiere decir que estoy en contra, solo que habria que probarlo. Y aqui tengo el mismo problema que tu. Tendria que empaparme en el Arduino y eso lleva mucho tiempo, que desgraciadamente no tengo.

La situacion actual es que disponemos de conversores AD de 10 0 12 bits que cuesta unos 3 Euros. El scrip de su lectura esta comprobado y pendiente de que Sailoog lo implemente en la proxima version.

Yo estoy terminado una placa de Hut para conectarla a la Raspi que disspondra de 16 kanales AD independientes y ajustables con proteccion de entrada para no quemar los IC. Las salidas y entradas digitales van a estar optoaisladas para manejar diferentes tensiones (tanto 12, 24 como 220 Voltios).

La idea es conectar los sensores por cable. Como estos ssensores solo manejan corrientes infimas, los cables a utilizar son baratos.

Con la implementación de NMEA2000 es otra opcion de preparar sensores para este bus. Por otra parte tambien dispondriamos de emisores-receptores inalambricos fiables para transmitir información inalambrica que se conectaria al interface SPI de la Raspi (como los conversores AD).

En resumen con las Raspberry , disponemos de un sistema extremadamente potente, relativamente simple, fiable, abierto, económico, con capcidad de desarrollarse, que se adapta a las necesidades de cada usuario, compatible con otros sistemas como arduino y más etc.

Si te funciona lo que tienes planteado, miramos si es posible de implementarlo en la Raspi.

Por otra parte el proyecto esta abierto a todo aquel que quiera aportar mejoras e innovaciones, pero estas deben ser realista

Re: Proyecto OpenPlotter
 

Mirate este hilo
http://foro.latabernadelpuerto.com/s...d.php?t=148351

Con el mismo receptor SDR para recibir AIS puedes recibir los mapas del satelite NOAA.

Como estos receptores SDR son baratos, he dedicado uno a AIS y otro para la recepcion de NOAA

Re: Proyecto OpenPlotter
 

No lo tomo como una discusión , creo que son dos liñas diferentes como correctamente lo plateado por sailoog.

Mi experiencia practica no es tanta, me de delicado a leer al respecto, dado mi formación tengo algunas facilidades y otras son desventajas.

Esto te lo puedo responder, son fiables. Hay infinidad de proyectos que han dado buenos resultados. Hay empresas que se dedica hacer la consolidación de los proyectos y los transforman en productos comerciables.
No te olvides que OP puede perfectamente avisarte que alguna de las informaciones enviadas por un modulo o hasta mismo el proprio modulo no esta presente y señalarlo alarmando. Por su vez el proprio modulo pude alarmar en los casos de datos fuera de premisas estabelecidas.


Creo que no lo has entendido.
El arduino tiene un puerto serial por el cual se comunicaría como lo hace tu ST 50 de Raymarine (Seatalk) en nuestro caso puede ser cualquier otro protocolo dada la flexibilidad de OP.
La información trasmitida en forma digital es practicamente inmune a interferencias, chau a los provocado por cables larguísimos offset.
Serial: 0 (RX) and 1 (TX).*Used to receive (RX) and transmit (TX) TTL serial data. These pins are connected to the corresponding pins of the FTDI USB-to-TTL Serial chip.



El Arduino tiene 10 bits de resolución (1024) idéntica al AD de 10 bits, solo tiene 8 entradas analógicas. Pero reúne una serie de otras ventajas en un único dispositivo, PWM entradas digitales, el puerto serial. Que pesa 5 g y cuesta 5 Euros ya esta instalada en una placa y como dicho basta recubrirlo con epoxi y lo utilizas abajo del agua si quieres.


Dos cables de comunicación digital


No se cuales son los sensores que pretendes utilizar , PTC, NTC , Termopares independiente del que quieras utilizar , mínimamente tendrá unos 3 a 4 metros de cable, que si baratos con una pobre aisalsión a interferencias electro magnéticas.

Muchos transductores producen señales de salida de milivoltios o de microvoltios. La amplificación de estas señales de bajo nivel directamente en un dispositivo AD , también amplifican el ruido de las conexiones e/o inducidos en a la señal original. Cuando la señal es pequeña, incluso un pequeño ruido puede perturbar la señal llevando datos erróneos de las medidas. La forma de corrección simple para reducir la relación señal/ruído es amplificar la señal tan cerca a la fuente como sea posible. De esta forma se amplia la señal sobre el nivel de ruidos antes de que el ruido en las conexiones pueda corromper la señal y mejore la relación señal/ruído de los conversores AD.

En resumen cables baratos con tensiones ínfimas son el problema.
Mi propuesta comunicación digital serial TTL , cables cortos solo dos.

En resumen con las Raspberry , disponemos de un sistema extremadamente potente, relativamente simple, fiable, abierto, económico, con capcidad de desarrollarse, que se adapta a las necesidades de cada usuario, compatible con otros sistemas como arduino y más etc.
[/quote]
Esto no tengo dudas. Digo mas es mucho mas potente Raspberry si la conectas a un arduino que solo viene a complementarla . Es lo mejor de los dos mundos digital y analógico. No compiten se complementan.

:brindis:

Re: Proyecto OpenPlotter
 

Pido humildemente consejo, unas rondas por delante.

Sobre el tema de la informática a bordo:

-a) quiero llevar a bordo un pequeño equipo de trabajo personal, Pc con windows, monitor, teclado y ratón, escaner e impresora A4. Que sea windows es casi obligado por los programas que utilizo.

-b) por otro lado veo que se pueden obtener muy buenos rendimientos para la electrónica de a bordo a precios económicos con las Raspberry

El programa de navegación es viaje y condiciones duras. La cuestión es ¿teniendo optimizada una opción a), sería posible prescindir de la b) o es conveniente llevar la electrónica en entornos más asépticos que el guirigai windows?

Como me parece que me vais a aconsejar llevar dos sistemas paralelos, intento desglosar las necesidades de las dos opciones y proponer algunos ejemplos:

a)
-Mini Pc barebone de bajo consumo
-Disco duro SSD
-teclado y ratón
-Monitor duro
-Impresora A4 barata
-Escaner A4 barato

b)
-Raspberri Pi
-USB GPS
-USB wifi
-Convertidor 12V-5V
-Convertidor USB-Nmea
-?

Perdonadme pero no le metido todavía el diente al tema openplotter y lo tengo muy verde.

En principio, menos para el monitor, me decanto por equipos de gran consumo, seguramente poco fiables, pero baratos de reponer. Parece que la informática está planteada siempre así, en poco tiempo las tecnologías se superan y en muy poco tiempo te encuentras con equipos más baratos y de más prestaciones que los que compraste seis meses atrás...y lo que verdaderamente tiene calidad tiene precios desorbitados que hace que dificilmente compensen en relación calidad precio..

En cuanto a electrónica dedicada, quiero llevar radar, vhf dsc, sonda, un plotter de 5" en bañera, gps de mano, BLU y transponder AIS.

¿Qué me aconsejais? ¿sobre qué precios anda lo descrito en la opción openplotter? ¿monitor, teclado y ratón son compartibles entre las dos opciones a) y b)? ¿mejor todo por cable o mejor todo inalámbrico?

Un saludo

:brindis:

Re: Proyecto OpenPlotter
 

Yo se poco de esto, pero el Open va con todo, así que métete con el, el Maxsea si cambias de ordenado, si es de 32 o 64 bits, si llevas XP o W8 o W10 etc ... ya no te vale y tienes que comprar de nuevo, creo que si no hacen algo rápido se van a quedar sin clientes.
Yo gaste poco, un DEll Latitude 630, de ocasion 100€, tiene la ventaja de que lleva puerto serie y te olvidas los convertidores y el Opencpn, que es gratis, también tengo instalados el Maxsea Time Cero y el 10.3, cuando se joda el ordenador se termino el Time, la verda es que viene bien por la cartografia, la Navionics y la Jespesen, pero para los que hemos empezado en esto con la navegacion de estima SIN gps cualquier cosa nos parece un lujo asiatico, la cartografia CM93 actualizada con el Google es mas que suficiente :sip:

:brindis:

Re: Proyecto OpenPlotter
 

Este creo que no es el hilo mas adecuado para esta consulta ya que se centra en Openplotter y no en "la informática a bordo" y podria desviar el tema. No obstante te veo muy indeciso y es que parece que pides cosas muy dispares.

Aquí pides cosas bastante raras para tratarse de un sistema para largas navegaciones. ¿Escaner e impresora? :nosabo: Yo que me compré una láser por que los cartuchos de tinta se secaban de no usarlos por semestres. Al menos con la láser pueden pasar años y no pierdes lo invertido en toner, pero lo cierto es que apenas tengo necesidad de imprimir nada.

¿Cual es exactamente el software que necesitas en windows? ¿Se trata de herramientas de altos requerimientos o simplemente son programas antiguos sin contrapartida en Linux? ¿Necesitan un procesador i7 o te podrias apañar con un ordenador USB-stick (windows) de unos 150 €:



O puede que te sea suficiente incluso una simple tableta windows de 99 €, parece mentira que lo diga yo, pero la he probado y funciona realmente bien a pesar de sus especificaciones y acepta todos los programas de windows:



Ese es el problema, que las opciones son infinitas y cada una te decanta por diferentes derroteros. Por ejemplo ¿cual es el presupuesto que tienes para el sistema?

Una buena opcion podria ser una Raspberry con openplotter para la gestion de los datos NMEA0183. Sobre todo por su versatilidad y por que si los demás sistemas fallan ella sola puede sacarte de un apuro pues puede hacer todo lo que cualquier ordenador excepto usar software de windows. Pero al menos puedes plotear consultar meteo, AIS, GPS, navegar por Internet, imprimir y escanear documentos Etc.

Esta serviría los datos por wifi a otros dispositivos que podrían ser un barebone windows o una tableta windows (bien sea de 99 € o de 1.500 €) y un teléfono Android que aguante el agua y puedas llevar en el bolsillo del traje de agua. Una tableta windows con la potencia que requieras cogida con velcros adhesivos a la mesa de cartas y que eventualmente puedas cambiar de sitio podria ser una buena idea. Los velcros adhesivos solucionan lo de una fijación excelente en múltiples sitios a gusto del usuario y el momento. Nada de ordenadores portátiles que usen ventiladores para refrigerar, descartados de base.

Nota para los fabricantes...:

Modo pataleta ON.

A ver si os ponéis las pilas y hacéis algún dispositivo que sea capaz de combinarse con montajes personalizados. En un mundo como el de ahora con Raspberrys,ordenadores de todo tipo, teléfonos y tabletas con infinidad de aplicaciones y arduinos para casi cualquier cosa que se te ocurra es una puñetera vergüenza que no fabriquéis algún dispositivo que al menos pudiera comunicarse con datos NMEA0183 por una red wifi cualquiera. Basta ya de recurrir solamente a protocolos exclusivos... los tiros no irán por allí. No volveré a gastar nada en vuestras marcas a menos que abráis un poco las puertas.

¿Para cuando un plotter externo con entrada HDMI común y soporte táctil USB? ¿Una pantalla de datos NMEA0183 que pueda leer desde un punto wifi a voluntad del usuario? ¿De verdad os costaria tanto implementarlo.... con los precios que trabajáis?

Al menos DigitalYacht piensa ya en Raspberrys cuando diseña algunos dispositivos.

Modo pataleta OFF.

Un teclado con touchpad que sea recargable para poder conectarlo eventualmente a la raspberry o a la tableta, pc, barebone windows.

Y como monitor sin duda una TV led con entrada HDMI (mejor si tiene dos, una para la raspberry y otra para windows.

Lo demás ya a gusto del usuario, aunque yo recomiendo huir de protocolos propietarios y comprar dispositivos con salida directa en NMEA0183.

En realidad planteas tantas cuestiones y muchas poco concretas, es dificil responderte a todas.

Céntrate en:

-Objetivos
-necesidades
-Presupuesto

:brindis: