![]() |
|
|
|
| VHF: Canal 77 |    | ![]() |
![]() |
![]() |
![]() |
![]() |
|
#1501
|
||||
|
||||
|
En el salón de Miami he conocido a unos chicos que hacen unos sensores (movimiento, gas, agua, baterías...) Conectados a un módulo central por Bluetooth. Se llaman Dokensip.
Lo he visto interesante y con cosas compartidas a este proyecto. ![]() |
| Los siguientes cofrades agradecieron este mensaje a Salat | ||
Loquillo (15-02-2016) | ||
|
#1502
|
||||
|
||||
|
Pues la verdad es que tienen una pinta estupenda, lo unico habria que saber el precio
|
|
#1503
|
||||
|
||||
|
Cita:
el de EEUU lleva 400 en poco tiempo y tiene pinta de ser kilométrico también. Solo puedo agradeceros a todos el interés y la colaboración, ojalá os estéis divirtiendo tanto como yo y sintáis este proyecto vuestro.Dime donde te has encallado con la creación de cuentas. Esto es lo único que tengo al respecto en la documentación como borrador https://sailoog.gitbooks.io/openplot.../accounts.html Yo también estoy encallado con la documentación por falta de tiempo y tengo a los traductores parados El problema con la creación de la cuenta de twitter es que twitter cambia la manera de hacerlo a menudo y según el pais las intrucciones varian algo. Miraré la manera mas facil de documentarlo cuando llegue a esa parte.Para lo de raymarine sigue los consejos que te da gypsylyon que se ha agenciado el post 1500 y bien merecido ![]() |
| 2 Cofrades agradecieron a sailoog.com este mensaje: | ||
gypsylyon (16-02-2016), ManelvallsVila (15-02-2016) | ||
|
#1504
|
||||
|
||||
|
Cita:
Ojeando sus características he caído en la cuenta de que no habíamos pensado en la captación de humos y gases y he encontrado unos sensores para ello que parece que funcionan muy bien y que cuestan la friolera de 4 euros. Se conectarían directamente a los pines de la raspberry y funcionarían igual que los detectores de movimiento, de apertura de puertas y de presencia de agua con los que ya cuenta openplotter, de hecho ya se podrían usar. Cuando investigue un poco más y haga pruebas publicaré los modelos compatibles. El resto de características de ese proyecto ya las tiene openplotter o las tendrá en breve. Otra cosa que hace tiempo que investigué y que me ha recordado es la implementación de aplicaciones de geo-fencing a openplotter que es la definición de áreas virtuales sobre un mapa y la detección de objetos que entran o salen de ellas. Esto sumado a los nuevos plugins de representación de objetos sobre OpenCPN que se están desarrollando me han hecho desempolvar antiguos proyectos. Tengo algunas ideas de aplicación que creo que serían la bomba pero no daremos más pistas no? ![]() Pese a ser un arduo defensor de la tecnología libre como ya sabéis, me alegra que existan este tipo de proyectos propietarios porque le dan aun más valor a openplotter en este caso y a la tecnología libre en general. Cuanto más actores de una y otra parte haya en la nueva era en la que entramos mejor que mejor, me explico... A mi entender estamos viviendo una nueva revolución industrial y OpenPlotter es una killer app más de otras muchas que invadirán la escena en los próximos años. Estas empresas propietarias con tanta inversión en infraestructura y en marketing deberían empezar a preguntarse si sigue siendo el camino adecuado. De momento existe mercado para ambas filosofías ya que mucha gente prefiere la facilidad y comodidad de un producto propietario, mas caro y dependiente de terceros a otro más barato, técnicamente mejor y sin dependencias pero que le exigirá cierta inversión de tiempo y la adquisición de ciertas habilidades. Pero esto está cambiando rápidamente. Hace no muchos años podías sobrevivir particular y profesionalmente sin conocimientos de informática a nivel de usuario y hoy en dia no saber usar un ordenador casi es sinónimo de analfabetismo. Dentro de también poco tiempo no tener nociones básicas de programación y otras habilidades tecnológicas también lo será y una vez rota esta barrera las demandas del mercado van a cambiar y mucho. Me alegra muchísimo que esta empresa y otras empresas del Pais Vasco últimamente se estén lanzando internacionalmente, pero algunas en mi humilde opinión han interpretado mejor el momento actual y están haciéndose un hueco en este nuevo escenario con mucho más éxito. Personalmente me introduje en este tipo de aventuras desarrollando e investigando en la fabricación de drones y en sus aplicaciones náuticas. Tras un año desarrollando afortunadamente me di cuenta que ya iba un poco tarde y me puede retirar a tiempo antes de invertir más tiempo y seguramente dinero en algo en lo que otros ya habían hecho mucho camino y uno de ellos era esta empresa vasca que es una muestra de lo que hablo http://erlerobotics.com Siento la chapa pero este tema me fascina y ya habréis notado que cada vez que puedo meto cuchara jejeje Editado por sailoog.com en 15-02-2016 a las 14:47. |
|
#1505
|
||||
|
||||
|
Cita:
Ah y gracias Sailog por lo del 1500 (eso era un coche no?) |
|
#1506
|
||||
|
||||
|
Cita:
Pero no prohíbe que puedas llevar cualquier tipo de artefacto no homologado siempre que no infrinja cualquier otra norma (armas , explosivos...) ni represente un peligro para la seguridad. Otra cosa es que reconozcan a OpenPlotter un peligro para su seguridad y la de sus empresas amigas ![]() |
| Los siguientes cofrades agradecieron este mensaje a sailoog.com | ||
ManelvallsVila (15-02-2016) | ||
|
#1507
|
||||
|
||||
|
Cita:
Lo comento porque con el sensor de temperatura y uno de flujo de liquidos podemos vigilar la refrigeracion del motor. A quien no se le ha olvidado abrir la valvula de entrada de agua salada de refrigeración de motor? A mi me paso una vez, y por esas cosas de la vida, no avisó el sensor de temperatura original del motor, con lo que no sonó la alarma. Me di cuenta cuando salia vapor de agua del motor (aunque primero parecia humo - vaya susto). Ahora tiene instalado un sensor mecanico con microrruptor (comercial) en la entrada de agua salada despues de la valvula. De esta manera si no entra agua o se obstruye la entrada avisa antes de que se caliente el agua del motor. Si se dispusiera de este sensor, junto con el sensor de temperatura de motor y otro de temperatura del agua de escape conectados a la raspi podemos hacer una vigilancia perfecta del motor. Podria hacer un script en Python que relacione estos tres sensores para que accione una determinada alarma segun lo que ocurra. Otra aplicación de este sensor de flujo seria su utilizacion en el circuito de combustible para medir el flujo de gasoil. Asi podriamos saber la cantidad de gasoil que fluye y dar alarma antes de que se pare el motor, si baja el flujo (por el moquillo u obstruccion) y tambien calcular el consumo del gasoil por hora y total. Yo tambien me pondre a buscar estos sensores para ver que precios tienen y como los podemos conectar a la Raspi. Editado por gypsylyon en 17-02-2016 a las 16:28. Razón: correccion |
|
#1508
|
||||
|
||||
|
yo tengo un microinterruptor conectado al grifo de la entrada de agua de motor, que mediante un rule activa una alarma luminosa y sonora.
Pero si abro el grifo, y se tapona la entrada, no avisa. ![]() |
|
#1509
|
||||
|
||||
|
Si que existen, adafruit tiene algunos. No es un tema que tenga muy investigado pero me parece una buena idea. Seguro que hay cosas industriales baratas y fuertes.
|
|
#1510
|
||||
|
||||
|
Múltiples sensores de temperatura DS18B20 implementados
![]() Ahora puedes definir sensores ilimitados y controlar motor, neveras, etc. en multiples puntos. http://www.sailoog.com/es/blog/prueb...otter-v070beta He reprogramado algunas partes importantes y ahora se podrán añadir nuevas magnitudes provenientes de sensores, interruptores, arduinos, etc. más facilmente. Esta es la hoja de ruta aproximada: Documentación básica. Multiples sensores DS18B20 Soprte para ADC Más documentación Panel de instrumentos e interruptores virtuales remoto. Otras funcionalidades solicitadas ![]() |
| 2 Cofrades agradecieron a sailoog.com este mensaje: | ||
ManelvallsVila (17-02-2016), RIGLOS (18-02-2016) | ||
|
#1511
|
||||
|
||||
|
Cita:
http://www.futurlec.com/Flow_Sensor.shtml#GASFLOWMETER Hay sensores para agua y diesel. Todos son digitales por sensor Hall. La tension de alimentacion va de 2,4 V a 26 V, y la salida es de pulsos, con lo que se puede leer directamente con la Raspi. El precio en relacion a la calidad es de los mejores que he visto. Si os parece bien serian un buen complemento para la Raspi. Tendriamos controlado la refrigeracion del motor y el flujo de gasoil pudiendo conocer el consumo por hora, el consumo por cada vieje y el consumo total. Se podrian montar alarmas de reserva de gasoil con bastante esactitud. Calcular y mostrar el numero de horas de navegacion en funcion del consumo y la cantidad de combustible restante, etc. Respecto al flujo de entrada agua salada poner una alarma si baja de un determinado nivel, de esta manera sabriamos que hay un problema en el circuito de refrigeracion antes de que se caliente el motor. He mirado tambien los sensores de arduino, pero me parecen flojos para el ambiente marino. A ver que os parecen estos sensores |
| 2 Cofrades agradecieron a gypsylyon este mensaje: | ||
ManelvallsVila (18-02-2016), Xeneise (20-02-2016) | ||
|
#1512
|
||||
|
||||
|
Cita:
http://www.futurlec.com/Flow_Sensor.shtml#GASFLOWMETER Hay sensores para agua y diesel. Todos son digitales por sensor Hall. La tension de alimentacion va de 2,4 V a 26 V, y la salida es de pulsos, con lo que se puede leer directamente con la Raspi. El precio en relacion a la calidad es de los mejores que he visto. Si os parece bien serian un buen complemento para la Raspi. Tendriamos controlado la refrigeracion del motor y el flujo de gasoil pudiendo conocer el consumo por hora, el consumo por cada vieje y el consumo total. Se podrian montar alarmas de reserva de gasoil con bastante esactitud. Calcular y mostrar el numero de horas de navegacion en funcion del consumo y la cantidad de combustible restante, etc. Respecto al flujo de entrada agua salada poner una alarma si baja de un determinado nivel, de esta manera sabriamos que hay un problema en el circuito de refrigeracion antes de que se caliente el motor. He mirado tambien los sensores de arduino, pero me parecen flojos para el ambiente marino. Aunque se podria utilizar para medir el consumo de agua dulce del barco Los sensores de futurlec para gasoil, probablementeno NO serian aptos para motores de gran potencia ya que solo miden hasta 30 l /h. Para estos motores valdria este otro sensor http://www.conrad.com/ce/en/product/...f=searchDetail que puede medir hasta 6000 l/hora. Aunque tambien sirve para agua, no creo que sea adecuado para medir la enrada de refrigeracion ya que el racor es de 1/4 de pulgada (=8mm) Para medir el flujo de combustible necesitariamos 2 sensores uno en la linea de alimentación y otro en la de retorno para medir la diferencia que seria el consumo. Y otro sensor para la entrada de de agua salada. A ver que os parecen estos sensores. Editado por gypsylyon en 19-02-2016 a las 10:08. Razón: Correccion |
|
#1513
|
||||
|
||||
|
Que buena pinta! y no son muy caros. Cuando dices de pulsos a que te refieres? con que interface/libreria de la raspi se puede leer? algún ejemplo?
Cita:
|
|
#1514
|
||||
|
||||
|
Cita:
Mounting Method : Horizontal to Vertical Range of Flow Rate : 2.0 – 60.0 L/min. Calibration(horizontal mounting) : Flow rate (lpm) Resolution(pulse/liter) 2.0 – 3.0 290 3.0 – 6.0 315 6.0 – 60.0 330 Accuracy : +/- 10% Calibration(vertical mounting) : Flow rate (lpm) Resolution(pulse/liter) 2.0 – 3.0 305 3.0 – 6.0 330 6.0 – 60.0 330 Accuracy : +/- 10% Es decir con uno de los GPIO de la Raspi contamos el numero de PPS y conocemos el número de litros/min. Lo que no se es si el voltaje de salida sera proporcional al voltaje de entrada (2,4 a 26 voltios). De todas maneras podriamos alimentarlo con 12 voltios y la salida reducirla con un divisor de tension a 3,3 Voltios. Aqui tienes un ejemplo de como se programa: #!/usr/bin/env python import RPi.GPIO as GPIO import time, sys FLOW_SENSOR = 23 GPIO.setmode(GPIO.BCM) GPIO.setup(FLOW_SENSOR, GPIO.IN, pull_up_down = GPIO.PUD_UP) global count count = 0 def countPulse(channel): global count count = count+1 print count flow = count / 330 # 6.0 – 60.0 l/m 330 pulsos por litro print(flow) GPIO.add_event_detect(FLOW_SENSOR, GPIO.FALLING, callback=countPulse) while True: try: time.sleep(1) except KeyboardInterrupt: print '\ncaught keyboard interrupt!, bye' GPIO.cleanup() sys.exit() |
| 2 Cofrades agradecieron a gypsylyon este mensaje: | ||
sailoog.com (20-02-2016), Xeneise (20-02-2016) | ||
|
#1515
|
||||
|
||||
|
Cita:
)Sea cual sea el tipo de comunicación que usa un sensor (I2C, 1W, SPI, pulsos...) puede ir conectado a cualquier pin o grupo de pins. Es por programación que tu le indicas como ha de comportarse ese pin o grupo de pins. Lo que pasa es que para guardar una cierta compatibilidad entre diferentes hats o placas de ampliación de la raspberry que se conectan al puerto GPIO, se establece y recomienda que por ejemplo el pin GPIO4 siempre sea usado para sensores 1W o que los pines GPIO2 y GPIO3 sean siempre usados como conexiones I2C. Dicho esto, OpenPlotter usa en estos momentos los pines reservados como I2C para sesnores IMU, temperatura del aire, presión y humedad; el pin 1W para multiples conexiones de sensores de temperatura y los pines SPI para los sensores analogicos. El resto de pines no están reservados y se usan para proposito general. Son los que usamos para conectar interruptores y para activar zumbadores, relés etc. Para este tipo de sensores por pulsos no hay pines reservados y se usan los de proposito general. Con estos sensores por pulsos no solo podriamos controlar sensores de flujo como los que propones, también podriamos controlar las revoluciones del motor, la velocidad del viento, la cadena que estamos largando... Por todo esto es por lo que digo que se merece tener su propia "pestaña" en OpenPlotter tal como la tienen los sensors I2C, 1W, SPI e interruptores. Son los sensores más faciles de programar ya que tan solo se trata de contar las veces que se cierra un interruptor pero son los mas dificiles de contextualizar dado el numero de magnitudes diferentes que pueden medir y sus respectivas unidades. Pero lo vamos a intentar no? ![]() De entrada yo añadiría al código que propones el factor tiempo para obtener, a parte de las vueltas que da cualquier eje, cuanto tarda en dar cada vuelta. A esto lo podemos llamar revoluciones y puede aplicarse por igual a cualquier tipo de sensor. Para poder programar un interface que sirviera para todo tipo de sensor debemos de aplicar otra variable esta mas complicada. En el caso del sensor de flujo que propones sabemos que el valor 330 son los pulsos/vueltas que tiene que dar para que pase un litro; y en el caso de un contador de cadena sabemos que por ejemplo 10 serían las vueltas que tiene que dar el molinete para largar un metro. A partir de aquí se me plantean estas dudas... Como ostias llamamos a esta variable que nos sirva para la calibración de una manera generica y que se entienda? es decir cuando el usuario se encuentre un campo donde deberá introducir este valor para diferentes sensores, como carajo le llamamos? Y mi otra gran duda es que en el caso del sensor de flujo, al tratarse de liquidos entiendo que cuanto más rapido fluye, este valor cambia y por eso tenemos: Flow rate (lpm) Resolution(pulse/liter) 2.0 – 3.0 290 3.0 – 6.0 315 6.0 – 60.0 330 Y aquí la liamos porque ya no tenemos solo una variable a aportar por el usuario, son tres. Como programo un interface generico para eso? supongo que encontraremos la manera pero está jodido no? ![]() |
|
#1516
|
||||
|
||||
|
Cita:
De todas maneras no lo veo muy claro lo hacer algo tan general. A lo mejor es hora de sentarse a definir que queremos hacer con Openplotter (ISO 9000). No creo que una Raspi pueda gestionar un monton de aplicaciones a la vez. Respecto al uso de las entradas digitales, pienso que habria que decidirse por limitar las aplicaciones y desrrollar el script adecuado para cada una ellas. De esta manera no tendrias el problema de como llamar a la variable. Por ejemplo en el caso del flujo de agua salada, se podria hacer por motores. Esto significa que habria que crear una base de datos con las caracteristicas de cada motor ( RPM, Potencia, Temperatura motor, caudal agua salada, etc). Como no serian muchas variables supongo que no necesitaria mcho espacio. De esta manera con elegir en el programa el tipo de motor se utilizarian las constantes respectivas. Probablemente habria que hacer los mismo con los sensores de flujo. Otra posibilidad, para evitar la base de datos, seria crear un cuadro de dialogo con un numero determinado de vaiables ( RPM, Potencia, Temperatura motor, caudal agua salada, etc) donde introducir las caracteristicas de cada motor o sensor. Estas se pueden guardar en un fichero. Incluso se podria poner el nombre del barco para que aparezca en el monitor. Respecto al factor tiempo, por su puesto estoy totalmente de acuerdo contigo, y ademas es necesario. Por ejemplo para el flujo de gasoil o gasolina, estos cuentan en pulsos por minuto o por segundo. de esa manera obtenemos litros por minuto. Luego esto habria que acumularos en otras variables para obtener el consumo total, el consumo por trip, el consumo por hora, la media del consumo por hora, el consumo instantaneo, etc Cita:
Si diera menos de 6 litros al ralenti, habria que introducir en el calculo las revoluciones del motor y esto no seria dificil. Eso si seria necesario leer las RPM del motor y conseguir la grafica de flujo de agua salada del motor segun RPM. Como veo viene trabajo. Asi que resumiendo. Mi propuesta es la de definir que aplicaciones querempos para Openplotter, desarrollarlas y sacar la version definitiva. Para ello podriamos habrir una ventana de tiempo para que los cofrades vayan proponiendo lo que les gustaria tener en Openplotter. Cuando acabe este tiempo seleccionar lo que es viable y lo que no para luego desarrollarlo. Por su puesto sin dejar de navegar para ello ![]() Que piensas? |
|
#1517
|
||||
|
||||
|
Cita:
Si tenemos un flujo de: 2 a 3 l/m serian 580 a 870 p/m o 9,6 a 14,5 p/seg 3 a 6 l/m serian 945 a 1890 p/m o 15,75 a 31,5 p/seg mas de 6 a partir de 1980 p/m 0 mas de 33 p/seg Contando los pulsos por segundo podriamos filtrar los litros por minuto y apicar el correspondiente valor if pulsos < 9,6 alarma=1 # No hay suficiente agua de refrigeración elseif pulsos >9,6 or < 15,75 calibracion=290 elseif pulsos > 15,75 or < 33 calibracion = 315 eseif pulsos > 33 calibracion = 330 Mejor seria hacerlo cada 5 segundos para disminuir el error. Esto deberia funcionar No? Que opinas? Asi no ahorrariamos el pregutar el flujo de cada bomba segun revoluciones Editado por gypsylyon en 21-02-2016 a las 01:03. Razón: correccion |
|
#1518
|
||||
|
||||
|
Buen dia a todos,
Esto avanza rápidamente y faltan manos. Hay un gran trabajo por hacer y aun somos pocos redactando y traduciendo la documentación: https://www.gitbook.com/book/sailoog...tation/details Para participar en la redacción se necesita un nivel aceptable de inglés ya que es el idioma en el que se escribe el original para facilitar las traducciones. Para participar en las traducciones se necesita un nivel medio de inglés (simplemente entender lo que se lee). En este enlace están las instrucciones para participar y una especie de hola de estilo. https://www.dropbox.com/s/p5fhhgso5y...20doc.pdf?dl=0 ![]() P.D.1. Esta tarde intento contestar gypsylyon P.D.2. v36317 Léete el documento please ya que han cambiado algunos pasos. |
|
#1519
|
||||
|
||||
|
Cita:
Lo leo y comentamos... Ánimo... Enviado desde mi A0001 mediante Tapatalk |
|
#1520
|
||||
|
||||
|
Hoy he probado el openploter navegando, al dar al botón de grabar el track se me cierra opencnp
Enviado desde mi E2303 mediante Tapatalk |
|
#1521
|
||||
|
||||
|
Este fin de semana he tenido tiempo de bricolear y he montado el prototipo del anemómetro para la Raspberry. Como sabeis he utilizado unos sensores de viento de tipo hilo caliente y con un convertido AD se leen los datos en la Raspi.
En estos links podeis seguir el desarrollo para que no tengais que buscar. http://foro.latabernadelpuerto.com/s...postcount=1366 http://foro.latabernadelpuerto.com/s...postcount=1407 http://foro.latabernadelpuerto.com/s...postcount=1415 http://foro.latabernadelpuerto.com/s...postcount=1438 http://foro.latabernadelpuerto.com/s...postcount=1448 A continuacion algunas fotos del prototipo. He utilizado componentes estandares que se encuentran en las tiendas de electronica. En un extremo de la placa del circuito estan los cuatro sensores de viento (una para cada cuadrante) que se parecen a una torre. Luego la linea de 4 potis como divisores de tension para limitar esta a la entrada del Convertidor analogico digital a 3,3,V. Finalmente el Convertidor AD MCP3008 de 10 bits y los inevitables puentes. En el extremo opuesto a "la torre" van a quedar todas las conexiones al cable. En otra foto las conexiones hecha con alambre. Se podria hacer mas pequeño de tal manera que usando componentes SMD se podrian introducir en "la torre" de los sensores de tal manera que su tamño seria 3 cm x 3cm por 4 cm(alto). Eso hubiera requerido hacer una caja a medida (p.e. impresora 3D que no tengo) y diseñar una placa de circuito impreso a dos caras. Pero eso es futuro. Ahora montarla en la caja (9cm x 6cm x 5 cm) y probarlo en la intenperie. Editado por gypsylyon en 19-03-2016 a las 18:29. |
|
#1522
|
||||
|
||||
|
Cita:
Esperando permisos. |
|
#1523
|
||||
|
||||
|
Hola a todos;
Respecto a tema sensores; acabo de descubrir éste sensor de viento que lo tiene todo y creo apto para la pi y openplotter. me viene bien pues mi mastil rota y no sirve cualquiera... http://www.sailtimerwind.com/ Como caracteristicas: Wireless (easy to install). Solar-powered renewable energy; can run day & night indefinitely. Submersible. Innovative wind cup blades maintain equal accuracy when sailing heeled over. The best features, and also the lowest price on the market: on sale for US $ 349.99. The first masthead anemometer with a digital compass right in the wind direction arrow. That means you even get wind direction while docked or swinging at anchor, when GPS heading is not available. With new features in app updates, the Wind Instrument actually becomes more useful over time. 2016 version shown above adds an off-switch for storage, new antenna arrangement for tall masts, and incredibly thin tail electronics with solar panels 40% thinner and rest of trailing edge just 3.5 mm (0.13"). Full details. The only masthead anemometer that works with rotating masts. No base unit required. For sailboats of all sizes, from keelboats to centerboard racing dinghies and even small multihulls (no 12-volt battery required). Small vertical design rather than the common horizontal structure, to deter large seabirds. Masthead mount or portable with small adapter for 1/4" tripod / Gorillapod / GoPro mount. Also works in the winter: our advanced battery continues to hold power and accept a charge down to -40 degrees (C/F). We made the first-ever masthead anemometer that transmits to mobile devices, and this is our newest version. Designed to work with third-party apps and hardware using the industry-standard NMEA 0183 format. Accessory for plugging in to on-board wired marine electronics. Wind direction equally sensitive all the way around; no dead band at the end of the rotation as in wind direction sensors with potentiometers. Transmits every second: twice as fast as our previous version. Amazing mounting options to raise the anemometer after your boat is in the water, without having to lower or climb the mast. 349 dolares...jeje |
|
#1524
|
||||
|
||||
|
glup (el precio)
|
|
#1525
|
||||
|
||||
|
Hola, y unos
para celebrar este proyecto y a sus impulsores por el trabajo realizado.Ya tengo mi frambuesa tuneada, y funcionando con Openplotter, a la espera que me llegue el conversor NMEA a usb y receptor TDT, que espero que no tarden. Mi equipo instalado en el barco es el siguiente: Equipo de viento ST60 Piloto automático ST4000+ Plotter Garmin Emisora Northstar Explorer y actualmente conectados a través NMEA. Pretendo conectar la frambuesa a través de NMEA-USB, para poder tener todos los datos en Openplotter y visualizarlos mediante escritorio remoto o la TV del barco que es de bajo consumo (que es una prioridad para mí) Tengo que decir que nunca había tocado programación ni cualquier otro sistema operativo que no fuera el habitual para mí, pero después de leer este hilo dos veces y tomar apuntes, me he decidido a montar este sistema que me parece perfecto, por el desarrollo que ha tenido este último año. Os iré contando y preguntando... ![]() ![]() ![]() |
![]() |
Ver todos los foros en uno |
|
|