Electrónica Proyecto OpenPlotter

[sailoog.com]

sigo liado con el calculo de viento real. Voy avanzando pero son calculos realmente complicados, pasaros pos este post y veris que el asunto tiene miga http://foro.latabernadelpuerto.com/s...d.php?t=136261

creo que he dado con una formula que no he visto en ningún lado, o una variación de la estandar, que funciona sobre el papel tanto para calculos con corredera como con GPS. necesitará de que los testers la exprimais para corroborarlo.

Por otro lado sigo mirando de incorporar funcionalidades y he dado con dos posibles muy útiles. Una es un termometro para el motor conectado directamente a la raspberry muy muy barato, waterproof y con un rango de -55º/125º C igual que este pero aun mas barato: http://www.adafruit.com/products/642 Una vez conectado a openplotter se podrian establecer alarmas, enviar lecturas por wufi, etc.

El otro es un medidor de baterias, de esto existen varios circuitos que habría que adaptar pero tambien muy economicos y con lecturas desde openplotter

Por otro lado queria retomar el tema del seatalk y creo recordar que alguien habia encargado este para ver si funcionaba en openplotter: http://www.yappelectronics.co.uk/STU.htm alguna noticia?

[jdiazrv]

Creo que en el hilo del viento real se riza mucho el rizo. En todos las pag/foros de los desarrolladores de instrumentos o soft (raymarine, OCKAM, stratpath..) dejan claro que el cálculo del viento real es con los datos de la corredera NO con el GPS. Al viento calculado en base al GPS se le llama "ground wind" porque se calcula con la "speed over ground". El problema es que GWD es una sentencia de NMEA 2000 pero no de 0183, si no estoy equivocado.
Es cierto que la corredera puede no existir o estar rota, pero eso no cambia lo que es el TWD. Creo que no se trata de cual es más exacto sino que cada uno tiene un nombre.


Creo que la funcionalidad de monitor de baterías es muy interesante. Ya sabemos que además de viento y meteorología en un barco siempre hay que estar pendiente de los consumos de: gasoil, agua y baterias. gasoil y agua tienen buenos indicadores de nivel y sabemos lo que se está gastando, pero con las baterías es diferente.

[surgysea]

Me alegra saber como seguis tirando "palante" del carro, cuando aun encontramos algunas dificultades con la fases que ya parecen operativamente finalizadas.
En las ultimas veces que he arrancado open cpn he observado la siguiente incidencia:
1.- No puedo hacer zoom, o mejor dicho al hacerlo automaticamente vuelve al zoom inicial.(os intento subir un video)
2.- consigo, en la cascada de "echar un vistazo" del ais decoder, ver señales ais, pero que luego o se traducen en barcos vistos en open cpn. He montado la antena "do ti yourself" y he clibardo la antena siguiendo la explicacion de sailoog a traves de las sentencias ejecutadas en el terminal, en lugar de usar la aplicacion del openplotter. He comprobado que no pueo activar rtlsdr y el mensaje que aparece en su ventana dice al go asi como stopped aisdecoder..... os pongo una imagen


Alguien me puede dar una explicación?. Me estoy olvidando algo?

[surgysea]

otra pregunta tras calibrar el sdr me sale un error negativo -17. Hay que introducir el valor con signo negativo?

[sailoog.com]

Originalmente publicado por jdiazrv

Creo que en el hilo del viento real se riza mucho el rizo. En todos las pag/foros de los desarrolladores de instrumentos o soft (raymarine, OCKAM, stratpath..) dejan claro que el cálculo del viento real es con los datos de la corredera NO con el GPS. Al viento calculado en base al GPS se le llama "ground wind" porque se calcula con la "speed over ground". El problema es que GWD es una sentencia de NMEA 2000 pero no de 0183, si no estoy equivocado.
Es cierto que la corredera puede no existir o estar rota, pero eso no cambia lo que es el TWD. Creo que no se trata de cual es más exacto sino que cada uno tiene un nombre.


Creo que la funcionalidad de monitor de baterías es muy interesante. Ya sabemos que además de viento y meteorología en un barco siempre hay que estar pendiente de los consumos de: gasoil, agua y baterias. gasoil y agua tienen buenos indicadores de nivel y sabemos lo que se está gastando, pero con las baterías es diferente.

totalmente de acuerdo. algunas discrepancias son una cuestion de terminologia.

aunque fabricandes también dicen que siempre es un calculo aproximado.

sin embargo... en este articulo explica que cuando la diferencia entre el rumbo verdadero y el rumbo efectivo es considerable debido a deriva o abatimiento, el calculo mas acertado es usando COG y SOG

http://davidburchnavigation.blogspot...rent-wind.html

resumiendo... mis conclusiones son que los dos metodos son validos y no enteramente exactos. en el caso de la corredera ocurre lo anterior y en el caso del GPS interviene la poca calidad de las lecturas de rumbo y velocidad de estos aparatos suficientes para mantener una navegacion aceptable pero no para calculos de precisión.

con tiempo expongo un poco mis experimentos a ver que opinas.

[sailoog.com]

Originalmente publicado por surgysea

Me alegra saber como seguis tirando "palante" del carro, cuando aun encontramos algunas dificultades con la fases que ya parecen operativamente finalizadas.
En las ultimas veces que he arrancado open cpn he observado la siguiente incidencia:
1.- No puedo hacer zoom, o mejor dicho al hacerlo automaticamente vuelve al zoom inicial.(os intento subir un video)
2.- consigo, en la cascada de "echar un vistazo" del ais decoder, ver señales ais, pero que luego o se traducen en barcos vistos en open cpn. He montado la antena "do ti yourself" y he clibardo la antena siguiendo la explicacion de sailoog a traves de las sentencias ejecutadas en el terminal, en lugar de usar la aplicacion del openplotter. He comprobado que no pueo activar rtlsdr y el mensaje que aparece en su ventana dice al go asi como stopped aisdecoder..... os pongo una imagen


Alguien me puede dar una explicación?. Me estoy olvidando algo?

3 cosas...

calibración: los valores negativos son posibles aunque no habituales no revistiendo mayor importancia. si, se pone en negativo. pregunta: has seguido los pasos sin recibir ningun error y obteniendo algun valor en cada parte?

tu cascada: las señales AIS que recibes son muy tenues, demasiado. estas lejos de los barcos?

opencpn: una cosa es el plugin de opencpn rtlsdr y otra openplotter, son dos maneras de recibir AIS con el sdr pero solo puedes usar una a la vez y es lo que te está pasando. Desactiva el plugin rtlsdr de opencpn y si puedes desactiva el plugin entero para que no te moleste mas. Reinicia y centrate en openplotter.
Si te salen desactivadas las opciones de AIS-SDR teniendo el pincho conectado significa que no te esta detectando el dispositivo debido seguramente a un problema de alimentacion, conecta un hub, introduce los valores de ppm y ganancia que obteniste, activa la recepcion en openplotter y deja opencpn escuchando en localhost 10110 unicamente.

[surgysea]

Originalmente publicado por sailoog.com

3 cosas...

calibración: los valores negativos son posibles aunque no habituales no revistiendo mayor importancia. si, se pone en negativo. pregunta: has seguido los pasos sin recibir ningun error y obteniendo algun valor en cada parte?

No me ha dado ningun error y he obtenido valore en todos los pasos

[/quote]tu cascada: las señales AIS que recibes son muy tenues, demasiado. estas lejos de los barcos?[/quote]
No estoy lejos de barcos como a a unas 5, 6millas y en alguna ocasion he conseguido ver barcos en open cpn

[/quote]
opencpn: una cosa es el plugin de opencpn rtlsdr y otra openplotter, son dos maneras de recibir AIS con el sdr pero solo puedes usar una a la vez y es lo que te está pasando. Desactiva el plugin rtlsdr de opencpn y si puedes desactiva el plugin entero para que no te moleste mas. Reinicia y centrate en openplotter.
Si te salen desactivadas las opciones de AIS-SDR teniendo el pincho conectado significa que no te esta detectando el dispositivo debido seguramente a un problema de alimentacion, conecta un hub, introduce los valores de ppm y ganancia que obteniste, activa la recepcion en openplotter y deja opencpn escuchando en localhost 10110 unicamente.[/quote]
Una vez hecho todo lo anterior, observo que las opciones de ais-sdr estan activas (siempre la estuvieron), tengo conectados gps y pincho de ais al hus autoalimentado, los valores introducidos de error y ganacia son los mismos, he activado la recepcion en open plotter y lo que me ocurre es lo siguiente:

1.- No puedo hacer zoom , ademas de no recibir datos ais .

2.- en openplotter al "echar un vistazo" la pantalla de la cascada se cierra inexperadamente al seguno de estar abierta

No se que informacion adicional puedo darte para guiarte

[surgysea]

Sailoog: ¿Puede que el problema del zoom sea una defectuosa instalacion de las cartas?
Adjunto un nuevo pantallazo de la cascada con alguna señal de mayor intensidad, pero sin recibir señales en open cpn, habiendo cumplido escrupulosamente las recomendaciones.

[surgysea]

se me olvidada

[jarmisen]

Originalmente publicado por sailoog.com

sigo liado con el calculo de viento real. Voy avanzando pero son calculos realmente complicados, pasaros pos este post y veris que el asunto tiene miga http://foro.latabernadelpuerto.com/s...d.php?t=136261

creo que he dado con una formula que no he visto en ningún lado, o una variación de la estandar, que funciona sobre el papel tanto para calculos con corredera como con GPS. necesitará de que los testers la exprimais para corroborarlo.

Por otro lado sigo mirando de incorporar funcionalidades y he dado con dos posibles muy útiles. Una es un termometro para el motor conectado directamente a la raspberry muy muy barato, waterproof y con un rango de -55º/125º C igual que este pero aun mas barato: http://www.adafruit.com/products/642 Una vez conectado a openplotter se podrian establecer alarmas, enviar lecturas por wufi, etc.

El otro es un medidor de baterias, de esto existen varios circuitos que habría que adaptar pero tambien muy economicos y con lecturas desde openplotter

Por otro lado queria retomar el tema del seatalk y creo recordar que alguien habia encargado este para ver si funcionaba en openplotter: http://www.yappelectronics.co.uk/STU.htm alguna noticia?

Buenas
Estoy contento con lo que comentas, Sailoog, sobre los sensores de temperatura para el motor, hace unas paginas lo propuse, pero me pareció que no era de interés.
He estado mirando el sensor y no entiendo como lo conectas a la raspi, pues a mi entender ese sensor es lo que llamamos en instrumentación una PT100 y no es mas que una RTD, pones un adaptador?.
Respecto al tema del SeaTalk yo tengo el circuito que comentas, que me monte yo, y puse comentarios y fotos en paginas anteriores. El problema que tengo es que me funciono durante un tiempo y podía ver siete u ocho parámetros en OpenCPN, el montaje era provisional como veras en las imágenes, quiero montarlo mas definitivo y probar a conectarlo, pero no tengo drivers para Linux y no se si lo detectara, me pondré con ello para poder aportar algo a este fantástico proyecto

[sailoog.com]

Originalmente publicado por surgysea

Una vez hecho todo lo anterior, observo que las opciones de ais-sdr estan activas (siempre la estuvieron), tengo conectados gps y pincho de ais al hus autoalimentado, los valores introducidos de error y ganacia son los mismos, he activado la recepcion en open plotter y lo que me ocurre es lo siguiente:

1.- No puedo hacer zoom , ademas de no recibir datos ais .

2.- en openplotter al "echar un vistazo" la pantalla de la cascada se cierra inexperadamente al seguno de estar abierta

No se que informacion adicional puedo darte para guiarte

1.- lo del zoom es cosa de opencpn y poco te puedo ayudar. que cartas son?

2.- lo del cierre inesperado de la cascada seguramente es la causa de tu problema con el AIS. sigo pensando que es una cosa de alimentación. cuantos amperios proporciona el adaptador del hub? vamos a abrir la cascada independientemente en una ventana terminal para ver que error devuelve:

- abre un terminal
- teclea cd .config/openplotter
- y luego python waterfall.py 49.6 -17 a
- se abrirá la cascada y si se cierra inesperadamente, en la ventana de terminal te devolverá un mensaje de error. copia y pega aqui todo el contenido de la ventana terminal y vemos.

[sailoog.com]

Originalmente publicado por jarmisen

Buenas
Estoy contento con lo que comentas, Sailoog, sobre los sensores de temperatura para el motor, hace unas paginas lo propuse, pero me pareció que no era de interés.
He estado mirando el sensor y no entiendo como lo conectas a la raspi, pues a mi entender ese sensor es lo que llamamos en instrumentación una PT100 y no es mas que una RTD, pones un adaptador?.
Respecto al tema del SeaTalk yo tengo el circuito que comentas, que me monte yo, y puse comentarios y fotos en paginas anteriores. El problema que tengo es que me funciono durante un tiempo y podía ver siete u ocho parámetros en OpenCPN, el montaje era provisional como veras en las imágenes, quiero montarlo mas definitivo y probar a conectarlo, pero no tengo drivers para Linux y no se si lo detectara, me pondré con ello para poder aportar algo a este fantástico proyecto

Atencion, ahí va tocho dominical...

claro que interesaba, intento apuntar todas vuestras sugerencias y cuando tengo un rato investigo formas de implementarlas y es cuando he dado con ese sensor y ahora recuerdo que tambien apuntaste a él. Se está haciendo muy dificil el buscar algo en este hilo por sus dimensiones y dependo solo de mis notas donde no siempre apunto todo. Es por eso que habia apuntado solo lo de la confirmación pendiente del funcionamiento del circuito de yapp, os pido disculpas si no hago a veces referencias a las fuentes de las cosas, es muy complicado guardar referencia de todo lo que se usa, recordádmelo cuando se me pase porque es importante . Pero luego vamos con lo de yapp, ahora lo del sensor termometro motor. La conexión seria esta:



y las librerias python para llamarlas desde openplotter pueden ser estas:
https://github.com/timofurrer/w1thermsensor

el datasheet para mas informacion http://www.adafruit.com/datasheets/DS18B20.pdf

Seatalk....

Lo que recuerdo de tu montaje es que usaba el mismo software y hardware de yapp y que usaba un micro para la traducción del nmea ¿si? la pregunta que hacía de la corroboración de su funcionamiento en linux te la traslado tambien a ti. si ese circuito funciona se podría recomendar a la gente para usar con openplotter e incluso coger los esquemas y encargar fabricar unas cuantas si se juntan varios interesados para que salga economico.


por otro lado y aprovechando que tienes traza con esto de la circuiteria te comento lo que me ronda la cabeza ultimamente....

las últimas menciones que he hecho del sensor de temperatura del motor, del sensor de baterias y la recuperación del seatalk tiene que ver con algo que ahora introduzco:

Por un lado tenemos un IMU que conectar a los pins I2C y de alimentación del puerto de expansion de la raspberry (GPIO). Los sensores I2C se pueden conectar en paralelo unos a otros y si queremos conectar alguno más ya estarán ocupados. Ni hablar de los pins de masa y voltaje que son usados por todos los extras que quieras conectar al GPIO. Como solución enseguida pensé en los HAT (Hardware Attached on Top) que son, por decirlo de una forma que se entienda como un segundo piso de la reaspberry donde añadir circuitos y normalmente conectados al puerto GPIO.

Una foto de un HAT:



una foto de un proto HAT o placa para diseñar prototipos:



y luego pensé... un HAT solo para duplicar conexiones I2C...? vamos a añadirle más cositas.... y empecé a buscar esquemas fácilmente aplicables y el resultado es el siguiente.

Un HAT para raspberry con:

Conversor de 12V a 5V, 3A para alimentar a la raspberry via GPIO y una salida de 5V para alimentar un HUB.


Un circuito monitor conectado a la entrada de 12V de las baterias del buque.



Un conector para atornillar directamente los cables que vienen del IMU y un par de conectores mas para añadir mas sensores I2C.

Un conector para atornillar el sensor de temperatura del motor y la resistencia que necesita.

Todos de este tipo:


Un conversor de seatalk a RS232:


Un conversor de RS232 a TTL para conectar directamente al GPIO de la raspberry. Este tendría dos entradas de manera que si no estamos conectando nada seatalk podamos conectar cualquier cosa NMEA por RS232:


y creo que no me dejo nada. Todas las conexiones he comprobado que cuadran en el GPIO y no se pisan y el precio de los componentes es miserable ya que no hay ninguno especial.

La traducción de seatalk a NMEA lo realizaría openplotter, al contrario del circuito de yapp en el que lo realiza un micro en el mismo circuito.

Resumiendo, el OpenPlotter HAT tendría:

• Conversor 12V a 5V-3A para alimentar la raspberry y un HUB
  
• Monitor baterias
• Monitor temperatura motor
• Conversor seatalk a NMEA o entrada NMEA
• Conector IMU y sensores I2C extras.

Que os parece? se me escapa algo? le cabría algo mas? o algo menos?

Si algo así tirara palante y una vez creado y probado el prototipo se podría crear un crowfounding para su fabricación en serie y que salga realmente económico.

[Salat]

Siento estar tan desconectado pero últimamente voy muy liado.
Sailoog me parece un proyectazo.
Si puedo ayudar en algo al crowdfunding cuenta conmigo.
Un abrazo

[North Side]

Me quito el sombrero sailoog. Aquí sigo para lo que pueda ayudar. No me importaría comprar los componentes que me falten y testear lo que necesites.

Saludos.

[surgysea]

SIN PALABRAS

Sailoog, no se si te será de ayuda, pero respecto a lo de leer datos Seatalk directamente desde opencpn usando el conversor simple que muestras en tu largo post......



Este circuito, o mejor aún, su versión unidireccional de solo entradad de datos Seatalk...


...... es realmente fácil de construir.

Lo difícil es, o era, implementar la conversión por software de los datos seatalk "captados" por el interfaz en datos entendibles por OpenCpn.

He aquí la posible buena nueva. Dándole la milmillonésima vuelta a este asunto tras leer tu (largo) post encontré esta breve mención a un port de Opencpn que YA incluye la comprensión de las sentencias Seatalk que este sencillo interfaz puede captar.

en concreto lo comentan en el mensaje Nº 6

http://www.cruisersforum.com/forums/...-a-132043.html

Tras ello, me fui a la página de github de donde se obtiene el código fuente....

https://github.com/JONA-GA

Probé a compilarlo... y voilá... En las opciones de conexión por puerto serie tenemos para elegir tanto NMEA0183 como NMEA2000 y Seatalk.

No se si realmente funciona pero si lo hace seria un puntazo. Podría compilarse tanto para Raspberry como para cualquier otro sistema sin problemas.

Yo lo tengo compilado para arquitectura amd64 y si alguno quiere bajarse el paquete Deb para comprobarlo lo podéis hacer desde este enlace.

https://mega.co.nz/#!ZAZ3EaoK!dM10gO...uli5cEbEEmODKk

Ojalá funcione y nos permita implementar la obtención de datos Seatalk a coste casi cero.

[sailoog.com]

Originalmente publicado por pinguino

Sailoog, no se si te será de ayuda, pero respecto a lo de leer datos Seatalk directamente desde opencpn usando el conversor simple que muestras en tu largo post......



Este circuito, o mejor aún, su versión unidireccional de solo entradad de datos Seatalk...


...... es realmente fácil de construir.

Lo difícil es, o era, implementar la conversión por software de los datos seatalk "captados" por el interfaz en datos entendibles por OpenCpn.

He aquí la posible buena nueva. Dándole la milmillonésima vuelta a este asunto tras leer tu (largo) post encontré esta breve mención a un port de Opencpn que YA incluye la comprensión de las sentencias Seatalk que este sencillo interfaz puede captar.

en concreto lo comentan en el mensaje Nº 6

http://www.cruisersforum.com/forums/...-a-132043.html

Tras ello, me fui a la página de github de donde se obtiene el código fuente....

https://github.com/JONA-GA

Probé a compilarlo... y voilá... En las opciones de conexión por puerto serie tenemos para elegir tanto NMEA0183 como NMEA2000 y Seatalk.

No se si realmente funciona pero si lo hace seria un puntazo. Podría compilarse tanto para Raspberry como para cualquier otro sistema sin problemas.

Yo lo tengo compilado para arquitectura amd64 y si alguno quiere bajarse el paquete Deb para comprobarlo lo podéis hacer desde este enlace.

https://mega.co.nz/#!ZAZ3EaoK!dM10gO...uli5cEbEEmODKk

Ojalá funcione y nos permita implementar la obtención de datos Seatalk a coste casi cero.

no me jodas! si funciona acabas de ahorrar meses de trabajo. me lo estudio a fondo...


en efecto yo estaba pensando en el circuito solo de entrada y no solo por costes o complejidad de la programacion, mas que nada por coherencia, está genial poder leer de una instrumentación muy extendida y no hay mas remedio, pero es un sistema propietario y de los peores que no respetan ni los estandares propietarios y crean los suyos propios, a eso se llama ir en contra de la ciencia y solo a favor del beneficio. Así que nada de enviar datos a raymarine, por suerte los pilotos automaticos si no me equivoco la mayoria tienen entrada NMEA no?

Originalmente publicado por sailoog.com

no me jodas! si funciona acabas de ahorrar meses de trabajo. me lo estudio a fondo...


en efecto yo estaba pensando en el circuito solo de entrada y no solo por costes o complejidad de la programacion, mas que nada por coherencia, está genial poder leer de una instrumentación muy extendida y no hay mas remedio, pero es un sistema propietario y de los peores que no respetan ni los estandares propietarios y crean los suyos propios, a eso se llama ir en contra de la ciencia y solo a favor del beneficio. Así que nada de enviar datos a raymarine, por suerte los pilotos automaticos si no me equivoco la mayoria tienen entrada NMEA no?

Yo diría que si... o al menos la opción aparece para elegirla..

Mira la captura.

[sailoog.com]

Originalmente publicado por pinguino

Yo diría que si... o al menos la opción aparece para elegirla..

Mira la captura.

pero... espera un momento... estoy revisando el codigo de la version estable opencpn 4 y eso siempre ha estado ahí y no le hemos visto nunca?

[Camelot]

Sobre el monitor de baterías seria interesante habilitar para varios bancos de baterías, al menos 3 ... creo yo.

Otra cosa que se podría pensar es en una caja para todo esto, ya que las vende por ahí económicas son bastante sencillas, y no tienen la opción de entradas y salidas de cables, con lo cual se han de hacer agujeros y al final es una chapuza. Si se diseña la placa se tendría que poder montar todo en una caja, y que exteriormente estén los conectores para los diferentes cables de los sensores de baterías temperaturas etc.

Lo de poner conectores con tornillo tipo regleta, si tienes que desmontar el bicho y llevártelo a casa, es un problema, ya que has de desconectar todos los cables, apuntarte los colores, y poner regletas para que no se crucen.
¿no es mejor algún tipo de conector enchufable?.. tipo regleta enchufable, que la desenchufas, los cables quedan en el barco, y al volver, vuelves a enchufar, y no puede haber error de conexión.
Puedes tener uno de los enchufes en casa para pruebas...

He recibido el BerryImu, como esta semana he estado en el varadero, no he tenido tiempo ni de mirarlo, a ver si le meto mano...

Un saludo

Por cierto, tengo en casa unos conversores DC-DC como el de la imagen que pones (exactamente el mismo) y los compre, ya que los uso en el barco en algún componente que va a 5V. Son muy baratos (creo que 1,5 euros cada uno) y van muy bien.

Originalmente publicado por sailoog.com

pero... espera un momento... estoy revisando el codigo de la version estable opencpn 4 y eso siempre ha estado ahí y no le hemos visto nunca?

¿Seguro....?

Lo digo por que la versión de este chaval me sale como Opencpn 4.1.0 a diferencia de la "oficial" 4.0.0.

¿Puede que se esté implementado justo ahora?

¡Que ganas de probar!

[sailoog.com]

Originalmente publicado por pinguino

¿Seguro....?

Lo digo por que la versión de este chaval me sale como Opencpn 4.1.0 a diferencia de la "oficial" 4.0.0.

¿Puede que se esté implementado justo ahora?

¡Que ganas de probar!

si si, en el codigo aparecen las tres opciones nmea 1083, seatalk y nmea 2000. acabo de instalar un opencpn 4.0.0 en un 386 desde repsitorio y me sale la casilla protocolo pero en gris (desactivada) y con nmea 1083 seleccionado. No puedo seleccionar nada porque no tengo nada que enchufarle y no tengo nada seleccionable en puerto supongo.

[sailoog.com]

como has creado tu /home/bobo/NMEA1083 ?

edito: ups pues igual tienes razón, acabo de leer en la documentacion de opencpn:

Protocol: For future use, as only NMEA 0183 works, for now.

Lo raro es que esté en el codigo de 4.0.0 y no esté activado aun

Originalmente publicado por sailoog.com

como has creado tu /home/bobo/NMEA1083 ?

Es un archivo fifo. Funciona muy bien con kplex, para simular puertos físicos.

[jarmisen]

Que pasada,
Lo primero tengo que disculparme, el sensor de temperatura es una pasada, mi confusión viene dada por que en mi trabajo los utilizamos habitualmente, pero estos son vulgares resistencias y ésta es un medidor de temperatura con salida digital.
Respecto al conversor Seatalk tengo el código fuente de la programación del chip, por si es necesario,
El montajillo con los dos transistores “Seatalk NMEA Seatalk” lo estuve probando y viendo los datos en el hyperterminal pero no conseguí ver nada, salían datos pero ilegibles para mi, si queréis que haga alguna prueba la haré. Seria una pasada que solo con esto se pueda ver los datos del Seatalk.
Lo del conversor de 12 a 5V es una buena idea, se tiene que ahorrar mucho en perdidas, el que he comprado da 6A y tiene un rendimiento del 94%.