Electrónica Proyecto OpenPlotter

[sailoog.com]

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

[popolk]

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?

[dione]

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

Saludos

[ZEPELIN]

Idem
Saludos y

[Avante]

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?

[Capicua]

Originalmente publicado por sailoog.com

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?

[gilinas]

Originalmente publicado por Capicua

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:

• ARINC 825 (para la aviación)
• CANaerospace (para la aviación)
• CAN Kingdom
• CANopen (para automatización industrial)
• CCP / XCP
• DeviceNet (para automatización industrial)
• EnergyBus (para vehículos eléctricos)
• GMLAN (de General Motors)
• ISO 15765-4
• ISO 11783 o ISOBUS (para la agricultura)
• ISO 14229
• SAE J1939 (para vehículos pesados)
• ISO 11992 (para trailers pesados)
• MilCAN
• NMEA 2000 (para la industria marina)
• OSEK
• RV-C (para vehículos recreacionales)
• SafetyBUS p (para la automatización industrial)
• SmartCraft
• Smart Distributed System (SDS)
• VSCP (para la automatización de edificios)

Algunos de ellos pensados para recoger datos y controlar dispositivos en vehículos con motor térmico o eléctrico.

[sailoog.com]

Originalmente publicado por Capicua

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.

[Avante]

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

[dione]

Originalmente publicado por sailoog.com

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,

[Capicua]

Originalmente publicado por sailoog.com

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.

Tu aclaración realmente a mi me ha sido de mucha utilidad.

Originalmente publicado por sailoog.com

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

Respeto tu opinión, la de tantos otros.
No por esto debo dejar de decir lo que creo, que es que te equivocas.
Un modulo es mucho mas económico que los cables y las horas dedicadas a solucionar problemas generados por el envió de información de forma analógica. Esto hoy por hoy es anticuado y complicado. No que no se pueda hacer, les deseo surete y mucha paciencia.

Originalmente publicado por sailoog.com

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.

Lo voy a ver ...
Gracias.

Originalmente publicado por sailoog.com

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.

No me refería a la capacidad del procesador y del control de varios procesos al mismo tiempo y si al manejar diversos protocolos de comunicación sin que estos entren en conflicto. Y esto no lo se por que esto no es lo mio.

Originalmente publicado por sailoog.com

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.

No supongo nada, mucho menos de lo que desconozco.
Es bueno saber lo que dices, ya que de esta forma podremos buscar en las repositorios de arduino alguna biblioteca que sea compatible.

Originalmente publicado por sailoog.com

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.

A lo que me refiero no lo corriges por la obtención de valores medios. Este recurso, por su vez compromete la única ventaja que puede tener un conversor AD, su grado de presión dependiendo si es 8 , 16 .... Los Arduinos dada su estructura y dependiendo dle conversor AD a que se comparen, pueden ser un poco mas imprecisos, estoy hablando de valores insignificantes para nuestros intereses. 0,05 Cº

Por otro lado los Arduinos no solo son mas baratos que los cables, como también lo son mas baratos que el conversor analógico digital, están prontos y son confiables. Soportan una infinidad de sensores pre-configurados.
Un único arduino nano

Input Voltage (limits) 6-20 V
Digital I/O Pins 14 (of which 6 provide PWM output)
Analog Input Pins 8 DC Current per I/O Pin

Length 45 mm Width 18 mm Weigth 5 g

Originalmente publicado por sailoog.com

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.

Te lo agradezco y te informo.
Mi problema es que no tengo tiempo para dedicarme, mi trabajo no me lo permite. Esto de los protocolos me puede llevar tiempo, así que decidí y encargare dos arduinos nano, al primero lo voy hacer conmutar la distribución de carga de las baterías, medir temperaturas de las mismas cuando en carga, protecciones, etc . Y lo segundo medirá temperaturas de motor, flujo de circulación de agua, alarma vinculada, etc.
Solo después pensare en como integralo a OP para mi lo mas complicado.
( estudie bibliotecas , compativilidad ,etc)
El OP lo seguiré utilizando vía shipmodule

[Orzado]

Hola a todos, voy a instalar esta semana el openplotter en el barco y le quería montar un teclado inhalambrico con trackpad incluido.
Hay algún modelo que no sirva, alguna característica, funcionan con el bluetooth directo ....

gracias

[sailoog.com]

Originalmente publicado por Avante

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

- Lo que buscas es un receptor SDR AIS, en nuestra pagina tenemos uno a la venta que está probado y si lo quieres encontrar más barato apunta las especificaciones y busca directamente en las paginas asiáticas. Tambien te servirá para escuchar la VHF.

- Fuera de cobertura movil me temo que lo mejor que tenemos es la radio de toda la vida a no ser que tengas conexión de datos satelite $$$. Las opciones de datos que tienes disponibles en HF son weatherfax y navtex pero estas están fuera del rango de frecuencias del SDR. OpenCPN tiene un plugin para capturar audio porcedente de una radio HF y decodificar weatherfax, pero necesitarás un adaptador USB con entrada de audio para la raspberry y evidentemente una radio con salida de audio, las portatiles son muy baratas <50. De esto último no hay mucha información y aun nadie ha corroborado su funcionamiento en OP, puedes usar navigatrix que si que hay más info.

[sailoog.com]

Originalmente publicado por dione

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,

Para la recepción VHF necesitas un receptor SDR (el mismo que se usa para el AIS) y solo tienes que abrirlo y teclear la frecuencia deseada. Te aparcerá el típico grafico de cascada donde podrás ver si hay movimiento en las diferentes frecuencias. Puedes escuchar toda la banda marina, la FM, etc.

La transmisión es experimental, quizás demasiado yo no me procuparia mucho a no ser que se tenga algo en mente. No necesitas ningun SDR ya que es la misma raspberry la que hace de modulador y emisor conectando unicamente un alambre a un pin del GPIO para que haga de antena. La Pi tiene estos secretos escondidos . Si se usa hay que tener cuidado ya que la salida es bastante sucia y puede inutilizar todas las comunicaciones a bordo si no se usan filtros.

[gypsylyon]

Originalmente publicado por Capicua

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?

Me meto en la discusion ya que me siento aludido por el tema del conversor AD para la Raspi.

En primer lugar decir que mi experiencia con Arduino es cero, por lo que no puedo decir si el sistema que propones es mejor o peor.
Pero si tengo experiencia en sistemas inalambricos y te puedo decir que hay una gran diferencia entre sistemas fiables (mas caros) que otros sistemas y ladiferencia es grande. No te lo tomes a critica, ya he dicho que no tengo expriencia con arduino, pero un sistema barato como arduino, me pregunto si es fiable, constante y sin fallos de conexion para un velero o motora en condiciones marinas.
Mi lema es, cuanto mas sencillo, menos problemas. Y los cables son más sencillo y seguros que las conexiones por radio. Ademas en el barco hay muchas posibilidades de interferencia que pudieran afectar a la comunicacion de los módulus. pero no quiere decir que estoy en contra, solo que habria que probarlo. Y aqui tengo el mismo problema que tu. Tendria que empaparme en el Arduino y eso lleva mucho tiempo, que desgraciadamente no tengo.

La situacion actual es que disponemos de conversores AD de 10 0 12 bits que cuesta unos 3 Euros. El scrip de su lectura esta comprobado y pendiente de que Sailoog lo implemente en la proxima version.

Yo estoy terminado una placa de Hut para conectarla a la Raspi que disspondra de 16 kanales AD independientes y ajustables con proteccion de entrada para no quemar los IC. Las salidas y entradas digitales van a estar optoaisladas para manejar diferentes tensiones (tanto 12, 24 como 220 Voltios).

La idea es conectar los sensores por cable. Como estos ssensores solo manejan corrientes infimas, los cables a utilizar son baratos.

Con la implementación de NMEA2000 es otra opcion de preparar sensores para este bus. Por otra parte tambien dispondriamos de emisores-receptores inalambricos fiables para transmitir información inalambrica que se conectaria al interface SPI de la Raspi (como los conversores AD).

En resumen con las Raspberry , disponemos de un sistema extremadamente potente, relativamente simple, fiable, abierto, económico, con capcidad de desarrollarse, que se adapta a las necesidades de cada usuario, compatible con otros sistemas como arduino y más etc.

Si te funciona lo que tienes planteado, miramos si es posible de implementarlo en la Raspi.

Por otra parte el proyecto esta abierto a todo aquel que quiera aportar mejoras e innovaciones, pero estas deben ser realista

[gypsylyon]

Originalmente publicado por Avante

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?

Mirate este hilo
http://foro.latabernadelpuerto.com/s...d.php?t=148351

Con el mismo receptor SDR para recibir AIS puedes recibir los mapas del satelite NOAA.

Como estos receptores SDR son baratos, he dedicado uno a AIS y otro para la recepcion de NOAA

[Capicua]

Originalmente publicado por gypsylyon

Me meto en la discusion ya que me siento aludido por el tema del conversor AD para la Raspi.

No lo tomo como una discusión , creo que son dos liñas diferentes como correctamente lo plateado por sailoog.

Originalmente publicado por gypsylyon

En primer lugar decir que mi experiencia con Arduino es cero, por lo que no puedo decir si el sistema que propones es mejor o peor.

Mi experiencia practica no es tanta, me de delicado a leer al respecto, dado mi formación tengo algunas facilidades y otras son desventajas.

Originalmente publicado por gypsylyon

Pero si tengo experiencia en sistemas inalambricos y te puedo decir que hay una gran diferencia entre sistemas fiables (mas caros) que otros sistemas y ladiferencia es grande. No te lo tomes a critica, ya he dicho que no tengo expriencia con arduino, pero un sistema barato como arduino, me pregunto si es fiable, constante y sin fallos de conexion para un velero o motora en condiciones marinas.

Esto te lo puedo responder, son fiables. Hay infinidad de proyectos que han dado buenos resultados. Hay empresas que se dedica hacer la consolidación de los proyectos y los transforman en productos comerciables.
No te olvides que OP puede perfectamente avisarte que alguna de las informaciones enviadas por un modulo o hasta mismo el proprio modulo no esta presente y señalarlo alarmando. Por su vez el proprio modulo pude alarmar en los casos de datos fuera de premisas estabelecidas.

Originalmente publicado por gypsylyon

Mi lema es, cuanto mas sencillo, menos problemas. Y los cables son más sencillo y seguros que las conexiones por radio. Ademas en el barco hay muchas posibilidades de interferencia que pudieran afectar a la comunicacion de los módulus. pero no quiere decir que estoy en contra, solo que habria que probarlo. Y aqui tengo el mismo problema que tu. Tendria que empaparme en el Arduino y eso lleva mucho tiempo, que desgraciadamente no tengo.

Creo que no lo has entendido.
El arduino tiene un puerto serial por el cual se comunicaría como lo hace tu ST 50 de Raymarine (Seatalk) en nuestro caso puede ser cualquier otro protocolo dada la flexibilidad de OP.
La información trasmitida en forma digital es practicamente inmune a interferencias, chau a los provocado por cables larguísimos offset.
Serial: 0 (RX) and 1 (TX).*Used to receive (RX) and transmit (TX) TTL serial data. These pins are connected to the corresponding pins of the FTDI USB-to-TTL Serial chip.

Originalmente publicado por gypsylyon

La situacion actual es que disponemos de conversores AD de 10 0 12 bits que cuesta unos 3 Euros. El scrip de su lectura esta comprobado y pendiente de que Sailoog lo implemente en la proxima version.

El Arduino tiene 10 bits de resolución (1024) idéntica al AD de 10 bits, solo tiene 8 entradas analógicas. Pero reúne una serie de otras ventajas en un único dispositivo, PWM entradas digitales, el puerto serial. Que pesa 5 g y cuesta 5 Euros ya esta instalada en una placa y como dicho basta recubrirlo con epoxi y lo utilizas abajo del agua si quieres.

Originalmente publicado por gypsylyon

Yo estoy terminado una placa de Hut para conectarla a la Raspi que disspondra de 16 kanales AD independientes y ajustables con proteccion de entrada para no quemar los IC. Las salidas y entradas digitales van a estar optoaisladas para manejar diferentes tensiones (tanto 12, 24 como 220 Voltios).

Dos cables de comunicación digital

Originalmente publicado por gypsylyon

La idea es conectar los sensores por cable. Como estos ssensores solo manejan corrientes infimas, los cables a utilizar son baratos.

No se cuales son los sensores que pretendes utilizar , PTC, NTC , Termopares independiente del que quieras utilizar , mínimamente tendrá unos 3 a 4 metros de cable, que si baratos con una pobre aisalsión a interferencias electro magnéticas.

Muchos transductores producen señales de salida de milivoltios o de microvoltios. La amplificación de estas señales de bajo nivel directamente en un dispositivo AD , también amplifican el ruido de las conexiones e/o inducidos en a la señal original. Cuando la señal es pequeña, incluso un pequeño ruido puede perturbar la señal llevando datos erróneos de las medidas. La forma de corrección simple para reducir la relación señal/ruído es amplificar la señal tan cerca a la fuente como sea posible. De esta forma se amplia la señal sobre el nivel de ruidos antes de que el ruido en las conexiones pueda corromper la señal y mejore la relación señal/ruído de los conversores AD.

En resumen cables baratos con tensiones ínfimas son el problema.
Mi propuesta comunicación digital serial TTL , cables cortos solo dos.

Originalmente publicado por gypsylyon

En resumen con las Raspberry , disponemos de un sistema extremadamente potente, relativamente simple, fiable, abierto, económico, con capcidad de desarrollarse, que se adapta a las necesidades de cada usuario, compatible con otros sistemas como arduino y más etc.
[/quote]
Esto no tengo dudas. Digo mas es mucho mas potente Raspberry si la conectas a un arduino que solo viene a complementarla . Es lo mejor de los dos mundos digital y analógico. No compiten se complementan.

[caribdis]

Pido humildemente consejo, unas rondas por delante.

Sobre el tema de la informática a bordo:

-a) quiero llevar a bordo un pequeño equipo de trabajo personal, Pc con windows, monitor, teclado y ratón, escaner e impresora A4. Que sea windows es casi obligado por los programas que utilizo.

-b) por otro lado veo que se pueden obtener muy buenos rendimientos para la electrónica de a bordo a precios económicos con las Raspberry

El programa de navegación es viaje y condiciones duras. La cuestión es ¿teniendo optimizada una opción a), sería posible prescindir de la b) o es conveniente llevar la electrónica en entornos más asépticos que el guirigai windows?

Como me parece que me vais a aconsejar llevar dos sistemas paralelos, intento desglosar las necesidades de las dos opciones y proponer algunos ejemplos:

a)
-Mini Pc barebone de bajo consumo
-Disco duro SSD
-teclado y ratón
-Monitor duro
-Impresora A4 barata
-Escaner A4 barato

b)
-Raspberri Pi
-USB GPS
-USB wifi
-Convertidor 12V-5V
-Convertidor USB-Nmea
-?

Perdonadme pero no le metido todavía el diente al tema openplotter y lo tengo muy verde.

En principio, menos para el monitor, me decanto por equipos de gran consumo, seguramente poco fiables, pero baratos de reponer. Parece que la informática está planteada siempre así, en poco tiempo las tecnologías se superan y en muy poco tiempo te encuentras con equipos más baratos y de más prestaciones que los que compraste seis meses atrás...y lo que verdaderamente tiene calidad tiene precios desorbitados que hace que dificilmente compensen en relación calidad precio..

En cuanto a electrónica dedicada, quiero llevar radar, vhf dsc, sonda, un plotter de 5" en bañera, gps de mano, BLU y transponder AIS.

¿Qué me aconsejais? ¿sobre qué precios anda lo descrito en la opción openplotter? ¿monitor, teclado y ratón son compartibles entre las dos opciones a) y b)? ¿mejor todo por cable o mejor todo inalámbrico?

Un saludo

[Velero Simbad]

Originalmente publicado por caribdis

Pido humildemente consejo, unas rondas por delante.

Sobre el tema de la informática a bordo:

-a) quiero llevar a bordo un pequeño equipo de trabajo personal, Pc con windows, monitor, teclado y ratón, escaner e impresora A4. Que sea windows es casi obligado por los programas que utilizo.

-b) por otro lado veo que se pueden obtener muy buenos rendimientos para la electrónica de a bordo a precios económicos con las Raspberry

El programa de navegación es viaje y condiciones duras. La cuestión es ¿teniendo optimizada una opción a), sería posible prescindir de la b) o es conveniente llevar la electrónica en entornos más asépticos que el guirigai windows?

Como me parece que me vais a aconsejar llevar dos sistemas paralelos, intento desglosar las necesidades de las dos opciones y proponer algunos ejemplos:

a)
-Mini Pc barebone de bajo consumo
-Disco duro SSD
-teclado y ratón
-Monitor duro
-Impresora A4 barata
-Escaner A4 barato

b)
-Raspberri Pi
-USB GPS
-USB wifi
-Convertidor 12V-5V
-Convertidor USB-Nmea
-?

Perdonadme pero no le metido todavía el diente al tema openplotter y lo tengo muy verde.

En principio, menos para el monitor, me decanto por equipos de gran consumo, seguramente poco fiables, pero baratos de reponer. Parece que la informática está planteada siempre así, en poco tiempo las tecnologías se superan y en muy poco tiempo te encuentras con equipos más baratos y de más prestaciones que los que compraste seis meses atrás...y lo que verdaderamente tiene calidad tiene precios desorbitados que hace que dificilmente compensen en relación calidad precio..

En cuanto a electrónica dedicada, quiero llevar radar, vhf dsc, sonda, un plotter de 5" en bañera, gps de mano, BLU y transponder AIS.

¿Qué me aconsejais? ¿sobre qué precios anda lo descrito en la opción openplotter? ¿monitor, teclado y ratón son compartibles entre las dos opciones a) y b)? ¿mejor todo por cable o mejor todo inalámbrico?

Un saludo

Yo se poco de esto, pero el Open va con todo, así que métete con el, el Maxsea si cambias de ordenado, si es de 32 o 64 bits, si llevas XP o W8 o W10 etc ... ya no te vale y tienes que comprar de nuevo, creo que si no hacen algo rápido se van a quedar sin clientes.
Yo gaste poco, un DEll Latitude 630, de ocasion 100€, tiene la ventaja de que lleva puerto serie y te olvidas los convertidores y el Opencpn, que es gratis, también tengo instalados el Maxsea Time Cero y el 10.3, cuando se joda el ordenador se termino el Time, la verda es que viene bien por la cartografia, la Navionics y la Jespesen, pero para los que hemos empezado en esto con la navegacion de estima SIN gps cualquier cosa nos parece un lujo asiatico, la cartografia CM93 actualizada con el Google es mas que suficiente

Originalmente publicado por caribdis

Pido humildemente consejo, unas rondas por delante.

Este creo que no es el hilo mas adecuado para esta consulta ya que se centra en Openplotter y no en "la informática a bordo" y podria desviar el tema. No obstante te veo muy indeciso y es que parece que pides cosas muy dispares.

Originalmente publicado por caribdis

-a) quiero llevar a bordo un pequeño equipo de trabajo personal, Pc con windows, monitor, teclado y ratón, escaner e impresora A4. Que sea windows es casi obligado por los programas que utilizo.

Aquí pides cosas bastante raras para tratarse de un sistema para largas navegaciones. ¿Escaner e impresora? Yo que me compré una láser por que los cartuchos de tinta se secaban de no usarlos por semestres. Al menos con la láser pueden pasar años y no pierdes lo invertido en toner, pero lo cierto es que apenas tengo necesidad de imprimir nada.

¿Cual es exactamente el software que necesitas en windows? ¿Se trata de herramientas de altos requerimientos o simplemente son programas antiguos sin contrapartida en Linux? ¿Necesitan un procesador i7 o te podrias apañar con un ordenador USB-stick (windows) de unos 150 €:



O puede que te sea suficiente incluso una simple tableta windows de 99 €, parece mentira que lo diga yo, pero la he probado y funciona realmente bien a pesar de sus especificaciones y acepta todos los programas de windows:

Originalmente publicado por caribdis

-b) por otro lado veo que se pueden obtener muy buenos rendimientos para la electrónica de a bordo a precios económicos con las Raspberry

El programa de navegación es viaje y condiciones duras. La cuestión es ¿teniendo optimizada una opción a), sería posible prescindir de la b) o es conveniente llevar la electrónica en entornos más asépticos que el guirigai windows?

Ese es el problema, que las opciones son infinitas y cada una te decanta por diferentes derroteros. Por ejemplo ¿cual es el presupuesto que tienes para el sistema?

Originalmente publicado por caribdis

Perdonadme pero no le metido todavía el diente al tema openplotter y lo tengo muy verde.

En principio, menos para el monitor, me decanto por equipos de gran consumo, seguramente poco fiables, pero baratos de reponer. Parece que la informática está planteada siempre así, en poco tiempo las tecnologías se superan y en muy poco tiempo te encuentras con equipos más baratos y de más prestaciones que los que compraste seis meses atrás...y lo que verdaderamente tiene calidad tiene precios desorbitados que hace que dificilmente compensen en relación calidad precio..

En cuanto a electrónica dedicada, quiero llevar radar, vhf dsc, sonda, un plotter de 5" en bañera, gps de mano, BLU y transponder AIS.

Una buena opcion podria ser una Raspberry con openplotter para la gestion de los datos NMEA0183. Sobre todo por su versatilidad y por que si los demás sistemas fallan ella sola puede sacarte de un apuro pues puede hacer todo lo que cualquier ordenador excepto usar software de windows. Pero al menos puedes plotear consultar meteo, AIS, GPS, navegar por Internet, imprimir y escanear documentos Etc.

Esta serviría los datos por wifi a otros dispositivos que podrían ser un barebone windows o una tableta windows (bien sea de 99 € o de 1.500 €) y un teléfono Android que aguante el agua y puedas llevar en el bolsillo del traje de agua. Una tableta windows con la potencia que requieras cogida con velcros adhesivos a la mesa de cartas y que eventualmente puedas cambiar de sitio podria ser una buena idea. Los velcros adhesivos solucionan lo de una fijación excelente en múltiples sitios a gusto del usuario y el momento. Nada de ordenadores portátiles que usen ventiladores para refrigerar, descartados de base.

Nota para los fabricantes...:

Modo pataleta ON.

A ver si os ponéis las pilas y hacéis algún dispositivo que sea capaz de combinarse con montajes personalizados. En un mundo como el de ahora con Raspberrys,ordenadores de todo tipo, teléfonos y tabletas con infinidad de aplicaciones y arduinos para casi cualquier cosa que se te ocurra es una puñetera vergüenza que no fabriquéis algún dispositivo que al menos pudiera comunicarse con datos NMEA0183 por una red wifi cualquiera. Basta ya de recurrir solamente a protocolos exclusivos... los tiros no irán por allí. No volveré a gastar nada en vuestras marcas a menos que abráis un poco las puertas.

¿Para cuando un plotter externo con entrada HDMI común y soporte táctil USB? ¿Una pantalla de datos NMEA0183 que pueda leer desde un punto wifi a voluntad del usuario? ¿De verdad os costaria tanto implementarlo.... con los precios que trabajáis?

Al menos DigitalYacht piensa ya en Raspberrys cuando diseña algunos dispositivos.

Modo pataleta OFF.

Un teclado con touchpad que sea recargable para poder conectarlo eventualmente a la raspberry o a la tableta, pc, barebone windows.

Y como monitor sin duda una TV led con entrada HDMI (mejor si tiene dos, una para la raspberry y otra para windows.

Lo demás ya a gusto del usuario, aunque yo recomiendo huir de protocolos propietarios y comprar dispositivos con salida directa en NMEA0183.

Originalmente publicado por caribdis

¿Qué me aconsejais? ¿sobre qué precios anda lo descrito en la opción openplotter? ¿monitor, teclado y ratón son compartibles entre las dos opciones a) y b)? ¿mejor todo por cable o mejor todo inalámbrico?

En realidad planteas tantas cuestiones y muchas poco concretas, es dificil responderte a todas.

Céntrate en:

-Objetivos
-necesidades
-Presupuesto

[caribdis]

Si, es cierto, me falta bastante información acerca de las posibilidades de las Raspberri y de cómo funciona Openplotter con Windows..

Si veis que este tema no cuadra en este hilo abro otro sobre informática a bordo.

Objetivos:
-Gestionar cartas y navegación con un dispositivo no dedicado (precio excesivo) que sea fiable y flexible
-Tener un ordenador a bordo que permita un uso no demasiado complejo de los programas que usamos normalmente en un Pc. No estoy demasiado habituado a hacerlo todo en android y para los programas que uso normalmente no siempre es posible utilizarlos en android

Necesidades:
-Para navegación, un sistema que permita visualizar cartas y a ser posible multiplexar cartas, gps, radar, AIS..
-Como ordenador, uso normalmente el programa de modelado 3d Rhino 3d, que tiene estos requerimientos:
https://www.rhino3d.com/es/system_requirements
http://www.simplyrhino.co.uk/support...erating-system
A pesar de que habla de un mínimo de 8 GB de RAM y 64 bits, yo lo tengo instalado con 2 GB y 32 bits en Windows XP y Windows 7 y el programa va perfectamente

Presupuesto:
-No quiero (en principio) pasar por un sistema completo de electrónica integrada tipo Garmin, Simrad, B&G, Raymarine...puedo prescindir de sonar integrado, piloto mecánico e instrumentos de viento, pero sí que me gustaría integrar radar y AIS
-Para la informática de trabajo, modelado 3d y otros, me bastaría con un equipo de gran consumo, nada especialmente potente ni profesional, porque no me fío mucho de la resistencia de los equipos al medio marino, y porque a la velocidad con que aumentan potencias y prestaciones, si haces una inversión importante, me parece que en poco tiempo se ve superada por opciones mucho más económicas.

Gracias por vuestro consejo y perdón si desvío el tema, vuelvo a repetir que si queréis abro un hilo diferente

Un saludo

[Xeneise]

Caribdis creo que tienes que darte una vuelta por este hilo:http://foro.latabernadelpuerto.com/s...d.php?t=148749
Si los programas que usas existen en Linux, miniPc a 12 v con Navigatrix es lo tuyo

Originalmente publicado por caribdis

Si, es cierto, me falta bastante información acerca de las posibilidades de las Raspberri y de cómo funciona Openplotter con Windows..

Si veis que este tema no cuadra en este hilo abro otro sobre informática a bordo.

Objetivos:
-Gestionar cartas y navegación con un dispositivo no dedicado (precio excesivo) que sea fiable y flexible
-Tener un ordenador a bordo que permita un uso no demasiado complejo de los programas que usamos normalmente en un Pc. No estoy demasiado habituado a hacerlo todo en android y para los programas que uso normalmente no siempre es posible utilizarlos en android

Necesidades:
-Para navegación, un sistema que permita visualizar cartas y a ser posible multiplexar cartas, gps, radar, AIS..
-Como ordenador, uso normalmente el programa de modelado 3d Rhino 3d, que tiene estos requerimientos:
https://www.rhino3d.com/es/system_requirements
http://www.simplyrhino.co.uk/support...erating-system
A pesar de que habla de un mínimo de 8 GB de RAM y 64 bits, yo lo tengo instalado con 2 GB y 32 bits en Windows XP y Windows 7 y el programa va perfectamente

Presupuesto:
-No quiero (en principio) pasar por un sistema completo de electrónica integrada tipo Garmin, Simrad, B&G, Raymarine...puedo prescindir de sonar integrado, piloto mecánico e instrumentos de viento, pero sí que me gustaría integrar radar y AIS
-Para la informática de trabajo, modelado 3d y otros, me bastaría con un equipo de gran consumo, nada especialmente potente ni profesional, porque no me fío mucho de la resistencia de los equipos al medio marino, y porque a la velocidad con que aumentan potencias y prestaciones, si haces una inversión importante, me parece que en poco tiempo se ve superada por opciones mucho más económicas.

Gracias por vuestro consejo y perdón si desvío el tema, vuelvo a repetir que si queréis abro un hilo diferente

Un saludo

Pues el plan que te dije antes se adapta bien a eso.

Para navegación la raspberry Pi funciona perfectamente. Con la TV como pantalla interna tienes un plotter estupendo y enviando los datos por red inalambrica puedes usar un teléfono Android con opencpn fuera como plotter en la mano. Yo lo hago y es extremadamente útil.

Como equipo windows una tableta de gama media para rhino3D (aunque juraría que seria capaz de correr incluso en la de 99 €) que eventualmente puede hacer de plotter recibiendo los datos NMEA0183 por la red inalamrica y que eventualmente puede usar la TV como monitor para trabajos profesionales con mas comodidad.

Un teclado y ratón inalambricos para usar donde haga falta, bien sea en Raspberry Pi o en la tableta windows.

Y luego añadir los origenes de datos NMEA0183 que te hagan falta. GPS, Corredera, Sonda, Viento, AIS Etc.

[caribdis]

¿Cual sería la ventaja de una tableta con respecto a un barebone? Doy por supuesto que si quiero trabajar con un programa de modelado 3d preferiré hacerlo en un monitor de al menos, al menos 17 pulgadas..

Un saludo y gracias por la ayuda

Originalmente publicado por caribdis

¿Cual sería la ventaja de una tableta con respecto a un barebone? Doy por supuesto que si quiero trabajar con un programa de modelado 3d preferiré hacerlo en un monitor de al menos, al menos 17 pulgadas..

Un saludo y gracias por la ayuda

Digamos que el "barebone" seria la Raspberry ya que es la que mas trabajaría en navegación.

¿Por que Windows en una tableta....? Por que lo he probado y es muy versátil. De hecho estoy escribiendo esto desde una tableta Windows (la de 99 €) usando el teclado sin cables y conectada a mi TV (que también uso con el sistema Linux) de 22 pulgadas.

¿Qué la quieres a lo grande?... Teclado y TV

¿tal vez mas portable?.... Con velcros la puedes fijar a la mesa de cartas o en un mamparo o incluso fuera bajo la capota.

¿Vas a la cafetería a por WIFI?... mucho mas fácil de transportar, mas aguante de batería. Mas de estado sólido. Menos consumo al cargar.

Le pones una funda y vale incluso al exterior... aunque yo fuera solo uso el Teléfono de m bolsillo.

Por cierto Windows 10 funciona muy bien en dispositivos táctiles y esto lo digo siendo un Linuxero de pro. Si te haces un dispositivo windous solo te recomendaría que fuera uindous 10.