Electrónica Proyecto OpenPlotter

[sailoog.com]

Originalmente publicado por Capitanlanmar

Sailoog,
¿Significa que podemos meter datos de Nmea2000/NG al openplotter?
¿Alguien ha conectado un plotter raymarine classic (C80 en mi caso) a través de esta conexión?
Mis sensores son todos SEATALK por ahora.

Gracias nuevamente

Exacto. Y no solo meter datos a OpenPlotter o a otros programas, también enviar datos a tu red NMEA 2000 desde OpenPlotter aunque en esto hay que ser extremadamente cuidadoso ya que una red N2K no es como las antiguas seatalk o NMEA 0183 ya que existen muchos más sensores interrelacionados entre si e inyectar datos en una red N2K puede crear situaciones peligrosas si son erróneos (piloto automático, sensores del motor, etc.).

Resumiendo, ahora recibe perfectamente y en un futuro también enviará con las futuras actualizaciones del firmware.

Desconozco las redes NG pero por lo que yo se son compatibles con el protocolo 2000 y lo único que cambian son las conexiones no?

[Capitanlanmar]

La verdad es que es una conexión del plotter que jamás he utilizado. Tampoco tengo cable ni sé cuáles son los pins.

El manual del C80 tampoco habla de los datos disponibles en esa salida.

Lo que está claro es que estos, aunque viejos, son los aparatos más extendidos.

Habrá que estudiar un poco...

Salud

[Bokaseka]

Casi me vuelvo loco con un hub usb que tenia igualico al que tiene sailloog en su webshop, pero parece que no tiene el chip requerido para entenderse con la raspberry. Sailoog, en tu tienda lo tienes agotado, ¿para cuando tendrás stock? ¿puedo comprarlo en algún sitio alternativo que me asegure que lleva ese chip?. Muchas gracias.

[sailoog.com]

Originalmente publicado por Bokaseka

Casi me vuelvo loco con un hub usb que tenia igualico al que tiene sailloog en su webshop, pero parece que no tiene el chip requerido para entenderse con la raspberry. Sailoog, en tu tienda lo tienes agotado, ¿para cuando tendrás stock? ¿puedo comprarlo en algún sitio alternativo que me asegure que lleva ese chip?. Muchas gracias.

Pues ya que sacas el tema... tengo un cabreo que no veas. Comerciar con China es una verdadera lotería, incluso un proveedor fiable te la puede jugar en cualquier momento, la última remesa de hubs también tenia el chip equivocado Esto te puede pasar con cualquier cosa pero sobre todo con pinchos wifis, hubs, SDR...

Cuando te pasa algo así puedes pelear y tras numerosos tramites puedes conseguir casi el 100% de lo pagado pero si le sumas los gastos de aduanas que no te los quita nadie ni nadie te los devuelve y el tiempo invertido es una verdadera putada...

Así que tardaré en tener hubs otra vez ya que tengo que empezar de nuevo el duro trabajo de buscar otro proveedor "fiable". Si te corre prisa te aconsejo que lo compres en cualquier pagina especializada de raspberry que hay muchas y que desconfíes de los excesivamente baratos porque tienes una probabilidad alta de que te manden basura.

[Capicua]

Estimados

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

[gypsylyon]

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.

[Capicua]

Originalmente publicado por gypsylyon

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.
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

[sailoog.com]

Originalmente publicado por Capicua

Gracias por tu respuesta.
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

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)

[sailoog.com]

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!!!

[popolk]

Hola. Una ronda para todos/as
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?

[dione]

Originalmente publicado por sailoog.com

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.

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,

[Capicua]

Originalmente publicado por sailoog.com

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)

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.

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.

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?

[gilinas]

Originalmente publicado por Capicua

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?

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.

[sailoog.com]

Originalmente publicado por Capicua

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.

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.

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?

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.

[gypsylyon]

Originalmente publicado por Capicua

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.

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.

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?

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