Electrónica Proyecto OpenPlotter

[Moorea]

Así es el flujo de datos del gadget pool

Enviado desde mi SM-T230 mediante Tapatalk

[gypsylyon]

Simulador pulsos de corredera para Openplotter
Hola
Hoy os presento un proyecto parecido al de jiauka pero para Openplotter
Primero agradecer a jiauka su aportacion en su hilo sobre generacion de pulsos de corredera con arduino, ya que me ha servido de inspiración.
Tambien a Sailoog que me ha proporcionado la rutina para leer y escribir las sentencias NMEA en la Raspberry

Para los que ya tienen la Raspberry con Openplotter y una antena GPS (bien de pincho de USB u otra de otro equipo que pueda recibir la Raspi), con este script en python se generan pulsos para la corredera en funcion de la velocidad sobre el fondo de GPS.

Para ello se utiliza un pin GPIO de la Raspberry como salida. En el Script he utilizado el GPIO 17 pero se pude usar cualquiera que este libre.
Igual que describe jiauka en el esquema de hardware (adjunto como pdf) hay que habilitar la salida de GPIO con dos resistencias y un transistor para que pueda conectarse a los 12 voltios. Para ello utilizar solo la parte de R2, Q1 y R1. R2 (que en el esquema de jiauka va a D9) la conectais al pin de la Raspi (en el programa GPIO17).

Supongo que será necesario corregir la frecuencia (cambiar valor en la variable "frequency = 4.8" al principio del script) para calibrar el sistema y obtengamos la misa velocidad que el GPS. Las frecuencias que utilizan los trasductores de corredera son de 4 Hz, 4,8 Hz y 5,3 Hz. Tambien puedes poner valores intermedios hasta igualar la velocidad del tridata a la de GPS. Jiauka comentó que el utiliza unos unos 7000 por mn. Eso significa que la la variable frequency seria 1.9 en vez de 4.8.
Lo mejor es probarlo con una frecuencia y ver que es lo que da el instrumento (p.e. Tridata). Por ejemplo si los datos de jiauka corresponden, y si nosotros yusamos la frequency = 4,8 tiene que dar una velocidad 2,5 veces myor que la de GPS (4,8/1,9=2,52). O lo que es lo mismo si la velocidad GPS es 2 nudos el Tridata te va a dar 2 *2,5 = 5 nudos.
Entonces para calcular la frecuencia solo hay que dividir la velocidad que te da el tridata por la velocidad de GPS. Este valor lo divides de la frecuencia usada (p.e. 4,8). y el resultado es lo que hay que poner en frequency.

Yo lo he probado con la Raspberry3 y la útima version 7 de Openplotter de Sailoog, con un diodo viendo como destellean los pulsos.

Como no se ha podido probar este fin de semana y yo no tengo posibilidad de hacerlo hasta el verano, a ver si sale algún voluntario que lo quiera probar, ya que, si funciona, lo podriamos implementar en el proxima version 0.9.0. de Openplotter

Para arrancar el script en una ventana de consola escribir: python lectura_NMEA_B.py. Para cerrar el programa pulsar Control+C


Adjunto el script en python "lectura_NMEA_B.py" para simular los pulsos de corredera.Tambien el esquema de jiaula.
Para poderlo subir le he tenido que poner la extension .txt. En la Raspi se la cambiais a .py.

El cofrade o cofrades que la prueben que me comuniquen resultados y si funciona bien por privado o en este hilo

[celsitomieres]

Hola.
Como esta semana estoy ocioso voy a probar este proyecto y tengo una duda. Cuando dices que lo has probado con un diodo, ¿dónde pones el positivo del diodo? ¿Al punto 3, entre R1 y Q1?. Es por probarlo en casa.
Un saludo

Originalmente publicado por gypsylyon

Simulador pulsos de corredera para Openplotter
Hola
Hoy os presento un proyecto parecido al de jiauka pero para Openplotter
Primero agradecer a jiauka su aportacion en su hilo sobre generacion de pulsos de corredera con arduino, ya que me ha servido de inspiración.
Tambien a Sailoog que me ha proporcionado la rutina para leer y escribir las sentencias NMEA en la Raspberry

Para los que ya tienen la Raspberry con Openplotter y una antena GPS (bien de pincho de USB u otra de otro equipo que pueda recibir la Raspi), con este script en python se generan pulsos para la corredera en funcion de la velocidad sobre el fondo de GPS.

Para ello se utiliza un pin GPIO de la Raspberry como salida. En el Script he utilizado el GPIO 17 pero se pude usar cualquiera que este libre.
Igual que describe jiauka en el esquema de hardware (adjunto como pdf) hay que habilitar la salida de GPIO con dos resistencias y un transistor para que pueda conectarse a los 12 voltios. Para ello utilizar solo la parte de R2, Q1 y R1. R2 (que en el esquema de jiauka va a D9) la conectais al pin de la Raspi (en el programa GPIO17).

Supongo que será necesario corregir la frecuencia (cambiar valor en la variable "frequency = 4.8" al principio del script) para calibrar el sistema y obtengamos la misa velocidad que el GPS. Las frecuencias que utilizan los trasductores de corredera son de 4 Hz, 4,8 Hz y 5,3 Hz. Tambien puedes poner valores intermedios hasta igualar la velocidad del tridata a la de GPS. Jiauka comentó que el utiliza unos unos 7000 por mn. Eso significa que la la variable frequency seria 1.9 en vez de 4.8.
Lo mejor es probarlo con una frecuencia y ver que es lo que da el instrumento (p.e. Tridata). Por ejemplo si los datos de jiauka corresponden, y si nosotros yusamos la frequency = 4,8 tiene que dar una velocidad 2,5 veces myor que la de GPS (4,8/1,9=2,52). O lo que es lo mismo si la velocidad GPS es 2 nudos el Tridata te va a dar 2 *2,5 = 5 nudos.
Entonces para calcular la frecuencia solo hay que dividir la velocidad que te da el tridata por la velocidad de GPS. Este valor lo divides de la frecuencia usada (p.e. 4,8). y el resultado es lo que hay que poner en frequency.

Yo lo he probado con la Raspberry3 y la útima version 7 de Openplotter de Sailoog, con un diodo viendo como destellean los pulsos.

Como no se ha podido probar este fin de semana y yo no tengo posibilidad de hacerlo hasta el verano, a ver si sale algún voluntario que lo quiera probar, ya que, si funciona, lo podriamos implementar en el proxima version 0.9.0. de Openplotter

Para arrancar el script en una ventana de consola escribir: python lectura_NMEA_B.py. Para cerrar el programa pulsar Control+C


Adjunto el script en python "lectura_NMEA_B.py" para simular los pulsos de corredera.Tambien el esquema de jiaula.
Para poderlo subir le he tenido que poner la extension .txt. En la Raspi se la cambiais a .py.

El cofrade o cofrades que la prueben que me comuniquen resultados y si funciona bien por privado o en este hilo

[gypsylyon]

Originalmente publicado por celsitomieres

Hola.
Como esta semana estoy ocioso voy a probar este proyecto y tengo una duda. Cuando dices que lo has probado con un diodo, ¿dónde pones el positivo del diodo? ¿Al punto 3, entre R1 y Q1?. Es por probarlo en casa.
Un saludo

Si solo conectas el LED no necesitas el transistor ni las otras resistencias. La conexion en este caso es el catodo (negativo) a la patilla de la Raspi y el anodo (positivo) a la de 3,3 V a traves de una resistencia de 370 Ohmios.

Si lo haces con el transistor, entonces, como tu comentas, el anodo del LED (positivo) al punto 3 entre r1 y el colector del transistor, pero poniendo una resistencia de 4 KOhmios y el catodo (negativo donde esta plano) a masa.
Lo unico que si el GPS es estático no veras nada ya que no hay velocidad. No te olvides de arracar antes Openplotter, ya que los datos los saca de los que OP genera

[JoseA]

Muy buenas!!!
Lo primero felicitar y agradecer a Sailoog su gran trabajo. Ha sido un gran y afortunado descubrimiento tanto la Raspberry como lo que puede hacer en un barco con el software apropiado. Con sólo grabar una imagen de OpenPlotter todo se reduce a ponerlo en marcha e ir probando cosillas.

El caso es que estaba en esas pruebas y no conseguía que OpenPlotter calculara viento real con los datos de mi barco, sin embarco sí con los de Diavolo, así que antes de molestar decidí remangarme y echar un vistazo al código fuente a ver si veía algo extraño.

Lo primero que impedía el cálculo del viento real era el cálculo del rumbo verdadero (heading_m), a su vez el problema estaba en Torrevieja, porque allí la declinación es cero si se redondea a una cifra decimal y entonces es como si no hubiera declinación así que la línea 129 del fichero calculate.py

if  conf.get('STARTUP', 'nmea_mag_var')=='1' and mag_var[0]:

pues no se producía una condición verdadera y por tanto no se calculaba rumbo verdadero.

Simplemente haciendo que el redondeo sea a 2 cifras se soluciona el problema y OpenPlotter calcula felizmente la diferencia entre rumbo magnético y verdadero en Torrevieja.





Ahora abro OpenCPN a ver cómo me muestra el viento real y ¡decepción!, con un viento de proa me debería coincidir la dirección del viento real con el rumbo verdadero del barco pero aparece desfasado como se ve en la siguiente captura


Vuelvo a mirar el código del fichero calculate.py y no consigo ver el problema. Ya dudo si lo que muestra OpenCPN es correcto y yo estoy equivocado.

Ya no os aburro más... aquí os dejo un enlace (sobre todo dirigido a Sailoog) para que pueda hacer las pruebas que estime oportunas con los datos de mi barco a ver si encuentra el fallo, ¡en el programa o en mi cabeza!

jabeque.mypi.co puerto 10110

en esta dirección os deberían aparecer unas sentencias $GPRMC, $IIHDM y $WIMWV (que es lo único que proporciona mi Nasa Clipper Wind)

[sailoog.com]

Originalmente publicado por JoseA

Muy buenas!!!
Lo primero felicitar y agradecer a Sailoog su gran trabajo. Ha sido un gran y afortunado descubrimiento tanto la Raspberry como lo que puede hacer en un barco con el software apropiado. Con sólo grabar una imagen de OpenPlotter todo se reduce a ponerlo en marcha e ir probando cosillas.

El caso es que estaba en esas pruebas y no conseguía que OpenPlotter calculara viento real con los datos de mi barco, sin embarco sí con los de Diavolo, así que antes de molestar decidí remangarme y echar un vistazo al código fuente a ver si veía algo extraño.

Lo primero que impedía el cálculo del viento real era el cálculo del rumbo verdadero (heading_m), a su vez el problema estaba en Torrevieja, porque allí la declinación es cero si se redondea a una cifra decimal y entonces es como si no hubiera declinación así que la línea 129 del fichero calculate.py

if  conf.get('STARTUP', 'nmea_mag_var')=='1' and mag_var[0]:

pues no se producía una condición verdadera y por tanto no se calculaba rumbo verdadero.

Simplemente haciendo que el redondeo sea a 2 cifras se soluciona el problema y OpenPlotter calcula felizmente la diferencia entre rumbo magnético y verdadero en Torrevieja.





Ahora abro OpenCPN a ver cómo me muestra el viento real y ¡decepción!, con un viento de proa me debería coincidir la dirección del viento real con el rumbo verdadero del barco pero aparece desfasado como se ve en la siguiente captura


Vuelvo a mirar el código del fichero calculate.py y no consigo ver el problema. Ya dudo si lo que muestra OpenCPN es correcto y yo estoy equivocado.

Ya no os aburro más... aquí os dejo un enlace (sobre todo dirigido a Sailoog) para que pueda hacer las pruebas que estime oportunas con los datos de mi barco a ver si encuentra el fallo, ¡en el programa o en mi cabeza!

jabeque.mypi.co puerto 10110

en esta dirección os deberían aparecer unas sentencias $GPRMC, $IIHDM y $WIMWV (que es lo único que proporciona mi Nasa Clipper Wind)

1000 gracias JoseA!!

Ahora no tengo tiempo pero como el script calculate.py tiene que sufrir grandes transformacionesen la versión v0.9.0, aprovecharé para incluir tus correcciones. De mientras podriamos hacer alguna prueba para solucionar el segundo problema:

Te ocurre eso usando datos de corredera o GPS? podrías ver si hay diferencia?
Has probado si te ocurre lo mismo estando en movimiento?
Las unidades que intervienen en los cálculos son las correctas? A veces los instrumentos proporcionan los datos en unidades no habituales en el pais y encontramos errores al intentar operar grados con m/s en vez de nudos o cosas así.

Gracias de nuevo.

[JoseA]

Te ocurre eso usando datos de corredera o GPS? podrías ver si hay diferencia?
Has probado si te ocurre lo mismo estando en movimiento?
Las unidades que intervienen en los cálculos son las correctas? A veces los instrumentos proporcionan los datos en unidades no habituales en el pais y encontramos errores al intentar operar grados con m/s en vez de nudos o cosas así.

- La corredera es Seatalk y no la tengo conectada a la Raspberry, no puedo ver si hay diferencia
- Sólo lo he probado con el barco parado
- Sí, las unidades son todas en nudos

De todas formas la semana que viene iré al barco y lo probaré en movimiento

Si quieres probar tú mismo sólo tienes que poner como entrada en el kplex la siguiente entrada TCP jabeque.mypi.co (puerto 10110)

Muchas gracias por tu atención y sobre todo por tu gran trabajo

¡¡A por la v 0.9.0!!