Foro Navegantes

(16-09-2019, 01:31 PM)viejomancebo escribió: [ -> ]Hola compañeros. 
Soy muy nuevo y estoy un poco perdido.
 Tengo montados en una mesa la rpi4 de 4g de ram. le he puesto open plotter v2, y lo voy actualizando. monitor, teclado y ratón. Por el momento por cable ratón y teclado. 
Estoy diseñando un circuito conectado al bus de la RPI. Sinceramente he leído tantos datos y en tantos foros ...Que no recuerdo donde encontré la información. En este circuito he puesto 8 conectores para sondas 1W, 4 entradas analógicas con el DS1115 Por I2C. El circuito ALTIMU 10,V5. 8 entradas digitales y dos salidas. y un microcontrolador de microchip el PIC24F16KL401-I/SO, con la intención de hacer un convertidor de Sea Talk a Nmea 0183. estas señales las entraría por el puerto serie de la RPI (pin 8 y 10). Nótese lo de la intención, ya que lo que es tiempo no me sobra.
Bueno después de este rollo, ¿existe un listado de todos los chips compatibles con openplotter v2?
Supongo que los chips I2C del Altimu 10 v5, cuando la v2 deje de ser beta estarán, ya que por el momento solo salen dos altímetros.
Perdonad si parece una queja. Nada mas lejos de mi intención. Vuestro trabajo me parece increíble y loable. ojala todos fuésemos así.
Joder que tostón. Lo que pido es la lista de chips compatibles y si es posible algún consejo de cual se adaptan mejor entre los que tengan la misma función.
He supuesto que la pregunta correspondería a este foro ya que es sobre openplotter v2. Si no es así me pasáis por la tabla.
Muchas gracias a todos.
Esto es lo que tengo por el momento. No será el final

Interesante proyecto.
Hace dos años me hice un Hat con dos MCP3008 (16 AD canales de entrada), 8 canales digitales de entrada optoaislados (LTV847) y 9 salidas de rele de 30A
Aqui puedes ver el resultado
https://foro.latabernadelpuerto.com/show...count=2000
https://foro.latabernadelpuerto.com/show...count=2001
La placa lleva dos fuentes de 12 a 5V, una para la raspi e integrados y otra para el Hub USB.  Lleva ya dos años funcionando sin problemas.

Con las salidas de Rele y una App llamada PiRalay enciendo y apago con el mobil tanto luces como aparatos.

Practicamente todos los chips que se conectan tanto por I2C como por SPI los puedes usar con la raspi. La cuestion es que exista la biblioteca adecuada para controlarlo.
Uno de los chips que mas se usan es el MCP3008 y el MCP3208. Es un convertidor AD de 8 canales. El primero de 10 bits y e segundo de 12bits. Su formato es de PDIP o SOIC.
Hay versiones de 2 y 4 canales tambien.  La conexion con la Raspi es por SPI, siendo la transferencia de datos mas rapida que con el DS1115 (https://ww1.microchip.com/downloads/en/D...21298c.pdf)
La primera vez que lo use con la raspi no habia biblioteca y la rutina que escribi controlaba los GPIO como SPI interface. Luego cuando salio la biblioteca se simplifico su uso.
Para lecturas de voltaje, como baterias o aforadores, te vale el de 10 bit, si quieres hacer mediciones de intensidad, es mejor el de 12bits
Aqui tienes el esquema de conexion
https://foro.latabernadelpuerto.com/show...tcount=377
Para medir intensidades yo uso el LMP860 que conecto a un canal AD del MCP3008. Pero para medir carga y descarga es mejor usar el MCP3208 de 12 bits.
TAmbies puedes usar el ACS712 que mide por efecto Hall (https://www.luisllamas.es/arduino-intens...co-acs712/). Tienes modelos de 5A,20A y 30A y valen tanto para continua como para alterna.

Con el MCP4822 tienes un conversor DA de 2 canales y 12 bit que tambien se conecta por SPI (http://ww1.microchip.com/downloads/en/de...02249b.pdf)

Si no te quieres complicar la vida haciendote tu circuito impreso, esto es una solucion
https://foronavegantes.net/thread-1497.html

Para el Can Bus tienes el MCP2562 (http://ww1.microchip.com/downloads/en/de...05167c.pdf), o mejor el MAX14882 queesta optoaislado (https://www.maximintegrated.com/en/produ...14882.html)
Para RS485/422 el MAXM22511(https://www.maximintegrated.com/en/produ...22511.html)
Yo creo que aqui tienes una buena paleta para empezar

ES curioso. Instale el modulo de Pypilot en mi Rpi 3 en casa y no me funciona. Sin embargo lo he instalado en mi Rpi 4 en el barco y ha funcionado correctamente permitiéndome configurar el IMU sin problemas. Supongo que el error que impide al modulo iniciar se puede deber al hecho de que haya o no un IMU conectado y que no inicie si no lo encuentra.

Por cierto Sailoog, creo que hay un error en la asignacion de localhost a OpenPlotter.local. Creo que lo asignaste a OpenPotter.local. Compruebalo.

(17-09-2019, 07:24 AM)pinguino escribió: [ -> ]ES curioso. Instale el modulo de Pypilot en mi Rpi 3 en casa y no me funciona. Sin embargo lo he instalado en mi Rpi 4 en el barco y ha funcionado correctamente permitiéndome configurar el IMU sin problemas. Supongo que el error que impide al modulo iniciar se puede deber al hecho de que haya o no un IMU conectado y que no inicie si no lo encuentra.

Por cierto Sailoog, creo que hay un error en la asignacion de localhost a OpenPlotter.local. Creo que lo asignaste a OpenPotter.local. Compruebalo.

De momento desarrollo solo en RPi4 y al final depuraré en RPi3 las cosas que no funcionen. Entiendo que en la RPi3 no tenias ningún IMU conectado no? Eso debería de funcionar asi que debe haber algún error. Cuando puedas prueba de ejecutar la app desde el terminal tecleando openplotter-pypilot y veremos el error.

He revisado la app openplotter-network que es el único sitio donde puede que haya un HarryPotter pero no hay nada. Que estas usando como base para instalar OP2? no habrás sido tu al asignar el nombre de red?

Recuerdo que inicie openplotter-pypilot tambien desde terminal y mostraba un error de falta de algun archivo... no recuerdo cual. Cuando este en casa te lo confirmo.
Respecto a lo de la red... no he tocado nada. Me he limitado a instalar openplotter-network y utilizarlo como cualquier otro usuario.
Lo unico que he "tuneado" en mi instalacion es OpenCpn cuya compilacion oficial para arm no funciona bien en la Rpi en cuestiones de sonido y para las alarmas es bastante importante. Hay que compilarlo con los extras de cmake -DOCPN_ENABLE_PORTAUDIO=OFF -DOCPN_ENABLE_SNDFILE=OFF -DOCPN_ENABLE_SYSTEM_CMD_SOUND=ON ..
si queremos que el sonido se oiga bien y ademas podremos usar mpv para que opencpn reproduzca sonidos mp3.
En las alarmas AIS, por ejemplo, es mucho mas util el beep que pones tu en los sonidos de openplotter que la campana que suena tan mal en la opencpn oficial que apenas se distingue si hay ruido de fondo.

(16-09-2019, 01:31 PM)viejomancebo escribió: [ -> ]Lo que pido es la lista de chips compatibles y si es posible algún consejo de cual se adaptan mejor entre los que tengan la misma función.

Esto es difícil de contestar ya que algunos de los antiguos soportados aun se tienen que añadir y si no hay demanda saltaran de la lista y ademas se incorporarán bastantes nuevos.
De momento lo único que puedo asegurar son:

- Todas las IMUs de siempre: https://docs.sailoog.com/openplotter-v1-...2c-sensors
- BME280: pressure, temperature, humidity
- MS5607-02BA03: pressure, temperature
- MCP2515: NMEA 2000
- DS18B20: temperature
- MCP3424: analog to digital
- MCP23017: expansion entradas y salidas digitales
- DS1115: depende si su autor quiere portarlo a OP2
- MCP3008: depende si su autor quiere portarlo a OP2

Muchos de ellos pueden funcionar por I2C o SPI. Para poco volumen de datos te recomiendo I2C y dejar los escasos SPI para grandes volúmenes de datos como NMEA 2000.
Como indicas siempre hay varias opciones para hacer la misma cosa y el criterio que se usa para decidir siempre es en función de la disponibilidad de hardware open-source del mercado que contenga esos chips. Muy raro seria ver un chip soportado del que no existan placas open-source.

(17-09-2019, 09:18 AM)pinguino escribió: [ -> ]Recuerdo que inicie openplotter-pypilot tambien desde terminal y mostraba un error de falta de algun archivo... no recuerdo cual. Cuando este en casa te lo confirmo.
Respecto a lo de la red... no he tocado nada. Me he limitado a instalar openplotter-network y utilizarlo como cualquier otro usuario.
Lo unico que he "tuneado" en mi instalacion es OpenCpn cuya compilacion oficial para arm no funciona bien en la Rpi en cuestiones de sonido y para las alarmas es bastante importante. Hay que compilarlo con los extras de cmake -DOCPN_ENABLE_PORTAUDIO=OFF -DOCPN_ENABLE_SNDFILE=OFF -DOCPN_ENABLE_SYSTEM_CMD_SOUND=ON ..
si queremos que el sonido se oiga bien y ademas podremos usar mpv para que opencpn reproduzca sonidos mp3.
En las alarmas AIS, por ejemplo, es mucho mas util el beep que pones tu en los sonidos de openplotter que la campana que suena tan mal en la opencpn oficial que apenas se distingue si hay ruido de fondo.

Lo unico que hace openplotter-network es usar el hostname de tu maquina:


Asi que me temo que ese HarryPotter debe de venir de otro lado.

Lo del sonido es una putada pero no podemos distribuir opencpn compilado, tenemos que usar los packages oficiales o seria incontrolable. Lo que si se puede hacer es añadir esas modificaciones a opencpn para que se añadan a las versiones arm, has reportado eso a opencpn?

(17-09-2019, 09:47 AM)Sailoog escribió: [ -> ]Lo unico que hace openplotter-network es usar el hostname de tu maquina:

Código:

hname=`hostname -f`

hlname="${hname}.local"

Asi que me temo que ese HarryPotter debe de venir de otro lado.

Lo del sonido es una putada pero no podemos distribuir opencpn compilado, tenemos que usar los packages oficiales o seria incontrolable. Lo que si se puede hacer es añadir esas modificaciones a opencpn para que se añadan a las versiones arm, has reportado eso a opencpn?

Tienes razón con lo de potter, era error mio de cuando varié la memoria para compilar Opencpn. Se ve que toque algo en la config del raspi-config sin darme cuenta.

Respecto a lo de openCpn,,,, esta mas que informado. De hecho son muchos los que lo han avisado pero ellos insisten en que el error solo es al pulsar el botón de comprobar el sonido pero que en un uso normal no pasa. NO es cierto. Pero supongo que se compila en arm para todas las placas arm y que añadiria mas problemas el tener que compilar específicamente para Rpi por separado.

Yo tengo el paquete correcto y lo usare en mis compilaciones pero si lanzan una actualización se perderán los beneficios. Afortunadamente OpenCpn se actualiza muy de tarde en tarde.

(17-09-2019, 09:58 AM)pinguino escribió: [ -> ]Tienes razón con lo de potter, era error mio de cuando varié la memoria para compilar Opencpn. Se ve que toque algo en la config del raspi-config sin darme cuenta.

Respecto a lo de openCpn,,,, esta mas que informado. De hecho son muchos los que lo han avisado pero ellos insisten en que el error solo es al pulsar el botón de comprobar el sonido pero que en un uso normal no pasa. NO es cierto. Pero supongo que se compila en arm para todas las placas arm y que añadiria mas problemas el tener que compilar específicamente para Rpi por separado.

Yo tengo el paquete correcto y lo usare en mis compilaciones pero si lanzan una actualización se perderán los beneficios. Afortunadamente OpenCpn se actualiza muy de tarde en tarde.

Si es algo que solo pasa en RPi entiendo que no se aplique la modificación pero me extrañaría mucho y supongo que afecta a todos los arm en debian. Veré que puedo hacer...

A mí el convertidor seatalk1 a USB australiano me tardó mes y medio.
Eso sí, va de fábula.

(17-09-2019, 09:36 AM)Sailoog escribió: [ -> ]Esto es difícil de contestar ya que algunos de los antiguos soportados aun se tienen que añadir y si no hay demanda saltaran de la lista y ademas se incorporarán bastantes nuevos.
De momento lo único que puedo asegurar son:

- Todas las IMUs de siempre: https://docs.sailoog.com/openplotter-v1-...2c-sensors
- BME280: pressure, temperature, humidity
- MS5607-02BA03: pressure, temperature
- MCP2515: NMEA 2000
- DS18B20: temperature
- MCP3424: analog to digital
- MCP23017: expansion entradas y salidas digitales
- DS1115: depende si su autor quiere portarlo a OP2
- MCP3008: depende si su autor quiere portarlo a OP2

Muchos de ellos pueden funcionar por I2C o SPI. Para poco volumen de datos te recomiendo I2C y dejar los escasos SPI para grandes volúmenes de datos como NMEA 2000.
Como indicas siempre hay varias opciones para hacer la misma cosa y el criterio que se usa para decidir siempre es en función de la disponibilidad de hardware open-source del mercado que contenga esos chips. Muy raro seria ver un chip soportado del que no existan placas open-source.

Muchas gracias. Me pongo con ello.

(17-09-2019, 09:36 AM)Sailoog escribió: [ -> ]- MCP3008: depende si su autor quiere portarlo a OP2

Que autor?

El script que te pase para leer el MCP3008, y que sigue en githup,
Funciona en la Raspi 4 también.




Gesendet von meinem CLT-L29 mit Tapatalk

(18-09-2019, 10:12 AM)gypsylyon escribió: [ -> ]Que autor?

El script que te pase para leer el MCP3008, y que sigue en githup,
Funciona en la Raspi 4 también.




Gesendet von meinem CLT-L29 mit Tapatalk

Scripts para el MCP3008 hay muchos y el autor de esa parte fue e-sailing que deberia hacer una app para ello en el nuevo formato de OP2. Por lo que se ahora está portando la app serial para familiarizarse con el nuevo sistema y no hemos hablado de esta parte aun.

hasta pronto robert,te fuiste el dia de mi cumpleaños,nunca lo olvidare,se te echará de menos por estos lares....a rañala...

Hola, tengo una duda. La versión de openplotter 1.2 funciona con una raspberry pi 4. Es por comprarla y utilizarla con la versión estable hasta que la última versión de openplotter esté finalizada.

Saludos

No. No funciona. La 4 requiere Raspbian buster y la 1.2 se creó sobre jessie.