VHF: Canal 77
"Se navega por los astros, por la mar, por la tierra, por las gentes, por los sentimientos...Se navega." — Altair

Anuncio

Colapsar

NORMAS DEL FORO: OBLIGATORIA SU LECTURA

Hola cofrade, has recalado en la Taberna del Puerto, algo más que un foro náutico. Eres bienvenido, participa, aprende y enséñanos; de eso se trata, de enriquecernos todos en nuestros conocimientos, y sobre todo de pasar un buen rato. No entres si vienes buscando conflictos, polémicas o cualquier otro fin que no sean los anteriormente descritos. Tenemos algunas normas y es obligatorio que las leas antes de empezar.

1/ Este es un foro náutico y aunque se permite hablar de otros temas, se ruega contención en el uso de los mismos, para ello existe un foro específico.

2/ Usa títulos claros y que describan el contenido del tema. De este modo será más fácil encontrarlos en el buscador para posteriores consultas además de que facilitas el trabajo de los que te vayan a responder. Títulos ambiguos como “ayuda”, “tengo un problema”, etc... no colaboran a este fin. Inserta tú tema en el foro adecuado, mira antes de lanzarlo por si alguien poco antes que tú ha puesto lo mismo; si es así no crees un tema nuevo, contesta al otro. Usa el buscador, es una gran herramienta. No escribas todo el texto con mayúsculas, se interpreta como que estás gritando. Todo esto facilita enormemente el trabajo de los que curramos aquí.

3/ No se permite el "spam" ni la publicidad de empresas o de actividades que conlleven lucro. Tampoco solicitud de ofertas de empresas o profesionales salvo en los foros de anuncios de compra-venta.

4/ No uses el foro como un chat salvo en aquellos temas habilitados a tal efecto, los cuales periódicamente serán eliminados. Las contestaciones reiterativas y/o automáticas, haciendo uso del sistema copi-pegui o cualquier otro no están permitidas.

5/ Respeta a los demás y a sus opiniones si quieres que las tuyas sean respetadas. Los insultos, la agresividad, el mal gusto y la mala educación no están permitidas en este foro. Aquí venimos a divertirnos, no a pelearnos. Se prohíbe insultar, ser agresivo, maleducado, soez, no respetar a los demás, intentar imponer nuestras ideas, empezar o dar pie a que empiecen peleas o trifulcas. Se exige orden y delicadeza a la hora de tratar ciertos asuntos, como por ejemplo, en lo que a la ortografía se refiere. Serán considerados como insultos y faltas de respeto el calificar a los Moderadores y/o Administradores como censores, dictadores, que coartan la libertad de expresión, que aplican un doble rasero, y expresiones similares.

6/ Nos gusta conocer con quién hablamos, así que, una pequeña presentación en el foro correspondiente que existe para tal fin siempre será bien recibida. No obstante, si alguien decide no presentarse, los demás usuarios se abstendran de reclamar dicha presentación y/o realizar crítica o petición alguna.

7/ Los temas políticos o que induzcan a la polémica innecesaria, mejor los dejas para otros foros de los muchos que hay para ello en la red. Se prohíbe hablar de política, de política económica, de política social, de nacionalismos, de antinacionalismos, de diferencias idiomáticas, de banderas nacionales, de exaltaciones patrióticas, de hechos diferenciales, de religión, de anti-religíon, de toros y del maltrato animal, y en general de todos los temas que se sabe de antemano van a ser polémicos y mucho más si no son náuticos. No contestes a estos temas o mensajes, informa a los administradores. No se tolerarán actitudes racistas, xenófobas, sexistas, denigrantes hacia otros colectivos o para con los demás, totalitarias o extremistas sean del signo que sea.

8/ El reenvío de mensajes que hayan sido modificados, o bien el envío de otros mensajes que muestren su descontento con esta modificación, pueden conducir al bloqueo de la cuenta. Esto también sucederá cuando un usuario insista en retomar algún tema o continuar sobre una conducta de la que se le ha alertado. En casos de que la mala conducta de un usuario continúe, se podrá proceder a su expulsión definitiva.

9/ Todos los temas y/o mensajes que fomenten la piratería sobre cualquier software u otro material protegido, o informen de cómo o dónde llevarla a cabo serán retirados inmediatamente del foro. No obstante, y debido a la imposibilidad por parte de los administrador de controlar todos los temas y mensajes , si alguien detecta cualquier incidencia de este tipo ruego lo comunique de forma inmediata a la administración, especificando el enlace al tema para poder ser retirado.

10/ Se prohíbe la reproducción total o parcial de textos u otros medios sujetos a Copyright y/o pertenecientes a otras webs, foros, etc... Sin embargo si que se podrán insertar enlaces a los mismos, pero siempre haciendo referencia a la página propietaria.

11/ La Taberna es un foro en lengua castellana o español, pero cada uno es libre de expresarse como quiera, allá él si la mayoría no lo entiende. Los usuarios se abstendrán de hacer ningún comentario indicando al que escribe en otra lengua su pertinencia o no. Tampoco se tolerará el uso del idioma como arma reivindicativa de ningún tipo.

12/ No se permiten insultos ni difamaciones a empresas, profesionales o particulares. Tampoco acusaciones de ningún tipo, que no estén probadas o demostradas judicialmente o por lo medios legales adecuados. Este no es un medio para presentar denuncias, para ello, existen los juzgados, consumo, etc...

13/ No se permite la inserción de hilos o mensajes con el fin de generar exclusivamente tráfico a otras web o canales, bien sea mediante enlaces, mediante árticulos, ficheros o datos parciales, o por cualquier otro método.

14/ Cualquier incumplimiento de estas normas, puede ser motivo de amonestación y/o expulsión del autor, de borrado o cierre de temas o mensajes, o de cualquier otra medida que la administración decida para intentar hacer que éstas sean cumplidas. Los temas pueden ser movidos o unidos sin previo aviso a criterio de los administradores.

15/ Si estás de acuerdo con ellas este es tú sitio; si no te gustan, no te apetece cumplirlas, las consideras restrictivas, censoras o que coartan tu libertad de expresión, no entres, no intervengas, y no te quejes cuando te sean aplicadas las medias correctoras adecuadas. No luches por cambiarlas a tu conveniencia, no puedes.

16/ Baja Voluntaria del foro.

Ni éste ni ningún otro Foro tiene previsto un sistema de Bajas voluntarias y automáticas. Simplemente con dejar de participar en él, y editar el Perfil de usuario para que dejen de aparecer los datos que crean no deben verse es sufiente.

No obstante, si alguien quiere que se le borre su cuenta, deberá enviar un e-mail desde el enlace "contáctanos" que se encuentra en la parte inferior del foro usando el e-mail con el que está registrado en la Taberna ya que es la única forma de comprobar la autenticidad del que se quiere dar de baja.
Así se evita que alguien pueda coger los datos de tu cuenta y pedir que se borre la misma.

Por otro lado advertir que los mensajes del usuario aparecerán, una vez borrada la cuenta, como realizados por un "invitado" ya que las intervenciones en un Foro público, son públicas. Es decir, desde el momento en que se publican dejan de pertenecer al usuario. Por otro lado, como siempre hay contestaciones a los mensajes, si algunos son borrados, el hilo deja de tener sentido.

En cualquier caso, si existe algún o algunos mensajes en el que aparezcan datos personales que el usuario no quiere que sigan apareciendo, ANTES de pedir la baja, podrá reportarnos estos mensajes, usando la opción "reportar mensajes" y nosotros eliminaremos esos datos personales.

Se entiende que una vez borrada la cuenta, esta acción es irreversible, con lo cual no se podrá volver atrás.


Estas normas pueden ser modificadas sin previo aviso, por lo que se recomienda consultarlas regularmente...



Bueno, y eso es todo, pasa, busca asiento por donde puedas y pide lo que guste...
Ver más
Ver menos

Proyecto OpenPlotter

Colapsar
Este tema está cerrado
X
X
 
  • Filtrar
  • Tiempo
  • Mostrar
Limpiar Todo
nuevos mensajes

  • Re: Proyecto OpenPlotter

    Originalmente publicado por ZEPELIN Ver Mensaje
    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 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
    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.

    Comentario


    • Re: Proyecto OpenPlotter

      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





      MMSI 205801910 Call OR8019
      Ham Call CX6AAT , PY2ZP ,PW2A

      Comentario


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

        Comentario


        • Originalmente publicado por gypsylyon Ver Mensaje
          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
          Editado por última vez por Capicua; 24/05/2016, 05:43:46.
          MMSI 205801910 Call OR8019
          Ham Call CX6AAT , PY2ZP ,PW2A

          Comentario


          • Re: Proyecto OpenPlotter

            Originalmente publicado por Capicua Ver Mensaje
            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)

            Comentario


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

              Comentario


              • Re: Proyecto OpenPlotter

                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?

                Comentario


                • Re: Proyecto OpenPlotter

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

                  Saludos

                  Comentario


                  • Re: Proyecto OpenPlotter

                    Idem
                    Saludos y

                    Comentario


                    • Re: Proyecto OpenPlotter

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

                      Comentario


                      • Re: Proyecto OpenPlotter

                        Originalmente publicado por sailoog.com Ver Mensaje
                        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?

                        Editado por última vez por Capicua; 30/05/2016, 02:36:48.
                        MMSI 205801910 Call OR8019
                        Ham Call CX6AAT , PY2ZP ,PW2A

                        Comentario


                        • Re: Proyecto OpenPlotter

                          Originalmente publicado por Capicua Ver Mensaje

                          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:

                          Algunos de ellos pensados para recoger datos y controlar dispositivos en vehículos con motor térmico o eléctrico.
                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                          El mar es de TODOS.
                          Lo que es de TODOS, NO ES MÍO.


                          "No hay nada como el MAR"
                          Tinico N'Hielo

                          Comentario


                          • Re: Proyecto OpenPlotter

                            Originalmente publicado por Capicua Ver Mensaje
                            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.

                            Comentario


                            • 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

                              Avante

                              Comentario


                              • Re: Proyecto OpenPlotter

                                Originalmente publicado por sailoog.com Ver Mensaje
                                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,

                                Comentario

                                Trabajando...
                                X