[Resuelto] Leer puerto serie TS-590sg con arduino.

Hombre, si estás trabajando con el MEGA 2560, lo primero es que este microcontrolador trabaja con lógica de 5 voltios.... 3V3 o 3,3V, son otros Arduinos, como el DUE (éste ya es una arquitectura RISC 32 bits)

Es posible que el MEGA pueda trabajar a 3,3V, pero para eso, hay que empezar probando con las velocidades más bajas e ir subiendo hasta ver cual es el límite.

Otras consideraciones, como temas de configuración de la emisora, ya no entro. Yo intentaría primero, establecer comunicación por el puerto serie con un PC e hyperterminal, putty, etc... cuando funcione y lo tengas claro la configuración del arduino y compruebes que funciona todo, a calentarse la cabeza con el puerto serie de la Kenwood...

Saludos. Jacinto

Bueno... de entrada estás creando dos objetos de la clase Serial, lo cual no está permitido. Puedes utilizar el mismo objeto para comunicarte por el puerto Serial (TX, RX) utilizando las instancias Serial.read(), Serial.write(), Serial.print(), etc.

para que el compilador acepte el código debes modificar la función loop()

loop() {

  Serial.begin(9600); //Asegurate que la velocidod de comunicación es la misma en los dos equipòs PC y radio, en principio la mínima

  Serial.flush();  //Completa la transmisión de datos

}

Sustituye las instancia de Serial1.print() por Serial.print() y podrás compilar al menos el sketch.

La comunicación entre un PC y un equipo de radio vía puerto serie puede parecer compleja pero no lo es. No tengo experiencia con Kenwood pero si he hecho algunas cosas con CI-V de Icom. Lo más importante es comprender los conceptos básicos de comunicación si quieres crear código partiendo de 0, incluso si dispones de algún sketch publicado es necesario comprobar cuidadosamente la comunicación de puertos.

Te sugiero que antes de lanzarte a programar, te plantees que es lo que deseas obtener y adquieras experiencia con bocetos básicos antes de lanzar a proyectos más complejos: Si necesitas ayuda me tienes a tu disposici´ñon.

Editado: mientras escribía esto y buscaba ejemplos de la librería de Arduino Enio ha escrito el mensaje anterior que, como es obvio, no he leído. No creo que haya contradicciones con lo expuesto.

Manu:

Aquí una pista que ojalá sea de ayuda. El estándar RS232 tiene, además de tensiones diferentes de TTL, lógica inversa. Te habrás fijado que todas las interfaces CAT simples usan un par de transistores, uno por cada línea RxD y TxD. El transistor, además de modificar las tensiones en función de dónde vayan conectados, produce una inversión de la señal.

Elecraft, por ejemplo, diseñó el KX3 y KX2 pensando en interfaces directas con RS232 pero aceptando niveles TTL. Sus adaptadores USB usan, por ello, chips de FTDI, el FT232RL que tiene una característica: se puede reprogramar para invertir las señales. Yo estuve peleándome con adaptadores Prolific PL2303HX hasta que analizando señales con el osciloscopio vi la luz, la del fondo de pantalla del osciloscopio... 🙂

Busca en la ayuda de la librería que usas para la lectura de la puerta serie y localiza cómo se define que esa puerta use niveles invertidos. Con x e y siendo las puertas, con SoftwareSerial sería

SoftwareSerial radio(x, y, 1); //el "1" define que los niveles van a estar invertidos (para lectura y escritura)

Con NewSoftSerial sería:

NewSoftSerial radio(x, y, true); // en este caso es el "true" el que marca la inversión

En todo caso, siempre puedes hacer un poco de google-fu con "Arduino RS232 inversion" y entretenerte un rato viendo lo que cuentan.

¡Suerte!

jon, ea2sn

Una aclaración sobre el post anterior:

Leer la frecuencia en que transmite un equipo necesita decodificar un protocolo de comunicación y es bastante complejo y la utilidad es limitada ya que existe software ya publicado (a efectos de informar la frecuencia) entre ellos el mismo dial del equipo.

Si lo que deseas es conocer la banda de trabajo actual para, por ejemplo, comandar un conmutador remoto de antena es mucho más sencillo. Kenwood comparte con Icom un sistema de codificación de banda por medio de voltajes que un microprocesador externo puede leer, interpretar y actuar. Estos voltajes oscilan entre los 0 y 8 voltios por lo que primero hay que modificar la tensión de entrada hasta un máximo de 5 V para un microcesador de tecnología TTL como los que incluyen las placas Arduino UNO, NANO y MEGA. El código es secillo, un ejemplo es el de mi mando de control que puedes leer en el repositorio de GitHub.

Yaesu utiliza un sistema TTL de comunicación basado en código BCD con lo que todavía es más sencillo.

Puede ser un buen ejercicio para comenzar a trabajar con programación para comunicaciones de micros con nuestros equipos. Como tenemos enclaustración para algún tiempo, se me ocurre que podríamos organizar un cursillo virtual de programación básica para Arduino, si hay un número de, al menos cinco personas interesadas, compañeros, hijos o familiares interesados pues también, prepararía un proyecto en la nube y podríamos comenzar por jacer un lector de banda y/o un conmutador de antenas trabajando cada proceso y prácticas sobre programación ágil en C+

Buscando por ahí, he encontrado la oferta de un decodificador de banda basado en Arduino de Remote QTH

https://www.remoteqth.com/arduino-band-decoder.php

El código para Kenwood se puede ver en GitHub

https://github.com/ok1cdj/ARDUINO-Bandecoder/blob/master/kenwood_bandecoder.ino

Me he equivocado, Kenwood no utiliza la tecnología de Icom de tensión de referencia por banda sino un código BCD vía puerto serie.

PA3CSG describe un proyecto para un conmutador de antena utilizando optoacopladores para controlas relés. Yo utilizo un circuito integrado UDN2981AT que puede controlar hasta 8 relés.

https://pa3csg.nl/?page_id=68

Muchas gracias a todos por las respuestas, vamos por partes:

@EC5APB La alimentación de 3.3v es la que recibe el interfaz TTL, el resto que comentas ya lo hice y ya he conectado por consola.

@EA2J Gracias, pero no me aclara nada lo que has comentado, el código que uso de prueba está basado en ese que me has puesto, llevo probando muchas cosas durante mucho tiempo, por otro lado, las inicializaciones de seriales van siempre en setup() y si que puedes crear varias conexiones simultáneas porque para eso dispone de 3 puertos serie y si necesitara más pues se puede utilizar la librería SoftwareSerial para convertir 2 pines digitales en más series.

Lo que hago con el código es mandar el comando por el serial1 que es el de la radio e imprimirlo por el serial0, que es el monitor del arduino.

@EA2SN Muchísimas gracias, algo así es lo que ando buscando, creo que por ahí van a ir los tiros pero a nivel de hardware, en un proyecto que está actualmente funcionando utilizan el Serial3, se inicia en este caso a 19200 baudios con Serial3.begin y el trozo de código para leer la frecuencia es simplemente este: 

Lo que no llego a comprender es por que he visto que tienen conectado el TX al RTS y el RX al CTS del interfaz RS232 físicamente, estoy seguro de que es por eso, pero como no lo llego a comprender ni encuentro información, pues no me aclaro.

@ea7khb

Manu:

he estado viendo gente que lee la frecuencia del 590SG con Arduino o equivalentes: uno es Loftur, para su antena magnética, y otro es el grupo de RemoteQTH.

Loftur indica que usa las señales con nivel TTL y conecta RTS y CTS para que la comunicación  no esté interrumpida.

En el caso de Remote QTH meten un inversor de señal.

Al mirar con más detalle el adaptador que estás usando, lleva un MAX232 o una de sus variantes. Este circuito genera a partir de los 3.3 V una señal positiva y otra negativa, que puedes comprobar en la patilla 2 (positiva) y 6 (negativa). Así la parte de RS232 está contenta. La parte TTL sale invertida. El MAX3232 sí puede hacer las cuatro conversiones RxD, TxD, CTS, RTS. Tendrás que ver cómo repercute la unión de CTS y RTS en las patillas en las salidas de conector DB9 (debería ser equivalente a unir las patillas 7 y 8).

En el sketch que acompañas, hay uno que usa Serial1 y otro que usa Serial3.  La cuestión sería saber cómo, al definir las puertas y asignarles las patillas, se definen como normales o como invertidas. Podrías comprobar

Un saludo, y suerte con las pruebas.

jon, ea2sn

@ea2sn

Tengo puenteada ahora mismo con un cable la 7 y la 8, que en el esquema de la radio es el CTS-RTS, en el ejemplo que he visto lo que tienen es un relé que pone en corto o abre estas 2, a priori debe de ser por si tienes entre medias un amplificador y lo que quieres es pasar al modo sniffer para seguir tomando la referencia de frecuencia y poder usar el ampli simultaneamente.

Sin duda va por ahí la cosa jon, lo que pasa que me pierdo en todo este lío de configuraciones que comentas, voy a intentar buscar información sobre el TTL invertido.

El sketch utiliza el Serial0 para monitorizar las salidas en consola según estoy analizando, no se utiliza para nada más, se inicia normalmente, a 9600 baudios.

Manu:

una pregunta tonta. El Mega tiene 4 UART, llamadas  Serial, Serial1, Serial2 y Serial3. En tu primer post dices que conectas tu interfaz RS232-TTL a los pines correspondientes a Serial1. Luego intentas leer Serial3 y no obtienes lecturas. ¿Me he perdido?

jon, ea2sn

No hay contradicciones Jon. Mi experiencia en comunicación serie entre el Icom y Arduino se basa en la salida serie de CI-V a través del único puerto serie que tiene el micro de las placa NANO que es la que utilizo con preferencia. MEGA y DUE (3.3V) tienen tres. Por cierto que en un lapsus he puesto la inicialización del puerto serie en el loop() en lugar del setup().

Yo no he tenido ningún problema para comunicar el Icom com el Arduino vía puerto serie con un conversor UART de Prolific utilizando una placa NANO. La información la he sacado por el puerto I2C a un display.

Remote QTH tiene un kit bastante completo para Arduino.

Manu, si me aceptas una observación:

la funcion delay(tiempo_delay_em_millis); es conveniente evitar ya que suman procesos de espera mientras algunos procesos continúan. Cuando se abre el puerto serie, es necesario hacer un tiempo de espera para que se complete la transmisión de datos. delay(milisegundos) utiliza un tiempo fijo de espera pero hay un método específico para esta instancia que es Serial.flush(); que detiene el flujo hasta que se completa la transmisión de datos.

El método delay() puede crear problemas ya que los cálculos matemáticos o la lectura de las puertas I/O pueden continuar durante el delay(). Si bien en el setup() {} no tiene significación, en el loop(){}; todos los autores experimentados recomiendan utilizar instancias con el método millis();  

@EA2SN Jon, ahora mismo estoy probando desde el  Serial3 conectado al RS232, la salida de la lectura quiero que sea por el Serial, que es el que arduino monitoriza, pero ese código que he puesto es sacado de otro proyecto, el cual lo tienen puesto en el 3 también, he puesto esa screenshot porque en el anterior comentario me preguntaste por cómo estaban configuradas las puertas.

He podido ir averiguando que en estos interfaces RS232 chinos vienen con las patillas cambiadas y el TX-RX son el CTS-RTS, por eso estaban usándolos en el ejemplo que vi. 

He cambiado el interfaz RS232 y he estado probando diferentes configuraciones hasta que he podido comunicarme entre el COM del pc usando un terminal  hasta el de arduino mediante su consola, lo que me envio de una va a parar a la otra y viceversa. Curiosamente lo que me ha funcionado ha sido RX con RX y TX con TX, yo cada vez me vuelvo más loco con este tema jejeje, ¿cada interfaz varía?

Ahora mismo como veis he cambiado al Serial3, pero sigo sin ser capaz de comunicarme con la radio.

@EA2J Gracias, lo tendré en cuenta cuando comience a programarlo en serio, ese código es copiado de un proyecto de un amigo, el cual tiene funcionando ahora mismo un sistema igual, mi código es tan simple como este ahora mismo, no debería de haber problema y no creo que sea de la parte del software, yo pienso que puede ser del propio interfaz que no es el apropiado...

Manu:

quizá te falte quitar el puente en el DB9 y hacerlo en los terminales CTS y RTS que tienes libres. No creo que al MAX3232 le guste mucho tener cortocircuitadas salidas ... Prueba que cuando mandas comandos la señal Tx se mueve (mejor con un multímetro analógico a falta de un osciloscopio) y que, si se recibe algo, la señal de Rx varía.

Ya en previsión de que sea una ruta sin retorno, quizá tengas que optar por emular una puerta en serie con un par de pines I/O utilizando la librería SoftwareSerial. Tendrías que definirla y ahí si cabría la opción de invertir las señales, por si ese es el problema.

jon

@ea7khb

Hola a todos,

    Veo que hay un cacao de cosas en este hilo y algunas nada claras...… algunas ya se han aclarado y otras están confusas....

    Por un lado y por empezar por algo, los arduinos tanto MEGA como DUE tienen 4 puertos serie por hardware, el serial, serial1, serial2 y serial3. Como diferencia (respecto a niveles), el Arduino MEGA trabaja a 5 voltios, aunque acepta también señales de 3.3 considerándolas como un valor=1, aunque siempre era mejor usar 5 voltios, y por el contrario el Arduino DUE trabaja a 3.3 voltios, por lo que una señal de 5 voltios en una entrada, y esa entrada no vuelve a funcionar ( eso en el mejor de los casos).

   Respecto a los puertos serie..... Un puerto RS232 trabaja con tensiones de -3 a -15 voltios para la marca y de 3 a 15 para el especio, es una señal simétrica, son las señales que nos encontramos en los puertos serie de los ordenadores y de "casi" todos los equipos de radio en su conector serie trasero, de ahí que un cable directo de la emisora al ordenador sea suficiente para la comunicación entre estos. Si en el manual de la emisora (importante leerlo) dice que se conecte directo del equipo al ordenador....niveles rs232.

   Luego esta el rs232 con niveles TTL/CMOS, osea 5 voltios. El Arduino MEGA o NANO o UNO trabajando a 5 voltios, por lo que hay que adaptar los niveles RS232 a esos valores, y se consigue con el famoso MAX232 (o con transistores), que nos genera una señal con 0 voltios o de 5v, la cual ya no es simétrica como la RS232, se puede decir que es una señal "invertida" respecto a la RS232? … pues no se ... pero es asi, y esa es la estándar de ese nivel, y los Arduinos trabajan con esa señal directamente, la que genera el MAX232.

   Algunos equipos trabajan directamente (el cat) con estos valores, de ahí que haya que intercalar un interface entre el ordenador y el equipo, y ese interface es un MAX232 con esa señal "invertida" de 5v, aunque bien es cierto que hay equipos antiguos (TS850, . …. ) que necesitaban invertir esa señal generada por el MAX232, y se le colocaba unas puertas inversoras, pero son equipos antiguos y no creo que haya ningunequipo  actual que trabaje con un rs232 TTL invertido.

    Por lo tanto en este caso que se usa un Arduino MEGA, mejor usar 5 voltios, y como el TS590 (según el manual) tiene un puerto RS232, hay que intercalar un conversor de niveles (MAX232).

    Bien... ahí llegamos todos... sabemos también que excepto en icom , se usan dos líneas para las comunicaciones , la TX y la RX, siendo (por pura lógica) TX la salida de datos y RX la entrada de datos, debiendo conectar la salida de datos del Arduino a la entrada de datos del equipo ( en este caso) y la salida de datos del equipo a la entrada de datos del arduino.... y aquí es donde empiezan los problemas...… porque no miramos cual es cual y nos fiamos de lo primero que vemos.....

    Si miramos el datasheet del Arduino vemos que por la línea marcada como TX el Arduino envía datos....es salida, es la transmisión, y la linea marcada con RX es una entrada, osea recibe datos por ella, es decir....TX salida de datos y RX entrada de datos..... ahora vamos al equipo …… y miramos el manual (ese taco de papeles que viene en la caja para forrar la emisora y no se mueva en el transporte) ...….. en la pagina E65 vemos el dibujo del conector serie del cat del equipo con sus pines..... PIN2 ……. RXD (a primera vista entrada de datos ...recibe), pero al lado pone "transmitir datos"...…. ya nos esta liando.... o es RXD o transmite datos..... pues seguimos leyendo y  pone "S" osea salida..... BIEN !!! … Resulta que RXD es la salida de datos, y el PIN3 es lo contrario … TXD ….. "recibir datos" … E (Entrada)…… pues ya podemos tener cuidado... el Pin RXD del equipo es transmisión de datos y el TXD es recepción.

    Y por si esto era poco .... aparecen los chinos con sus conversores .... lo cierto es que trabajé con varios de esos conversores y jamás en la vida me pasó que las líneas TX y RX fueses las RTS y DTR, pero bueno .... lo que si he encontrado es algunos en los que TXD era recepción de datos y RXD la transmisión ( como en el kenwood), así que hay que coger el datasheet del MAX232 y mirar a que patilla corresponde cada pin, si esa patilla es entrada o salida.... así pues las patillas 10 y 11 son entrada TTL, las 9 y 12 salidas TTL …. por otro lado las patillas 8 y 13 son entradas RS232 y las patillas 7 y 14 son salidas RS232..... Pues con todo esto tenemos que mirar cada cosa donde se conecta.... 

     Si conectamos todo sin comprobar nada, el milagro seria que funcionase a la primera … y sino funciona, pues cambiamos cables como si no hubiese un mañana, pero mejor es de mano coger un polímetro y mirar que el PIN2 del conector del kenwood que era RXD (pero transmisión de datos) se conecte a una entrada ( salida con entrada) RS232 del MAX232, osea a la patilla 8 o 13, y la salida de esta (ver datasheet del MAX232) de la zona TTL, osea, 9 y 12 respectivamente., al ser salida del MAX232, debe ir conectada a la entrada del Arduino …..al RX del Arduino.

   Al contrario, el PIN3 del conector del kenwood es TXD (pero entrada de datos) debe ir conectado a una salida RS232 del MAX232 osea, a las patillas 7 o 14, y la entrada del pin usado  (10 o 11) iría a la salida del Arduino (TX)……….

   Mucho lio verdad?, pero ten en cuenta que ahora mismo en tu montaje no sabes si estas conectando entradas con salidas, salidas con salidas, el TX de uno a nada del otro,....el RX del otro a DTR del uno..... lo primero es conectar cada oveja con su....pareja.

  Perdón por el tostón que os he soltado, pero si esto se hace de mano, se tarda 1,0 en conseguir la comunicación…..

Seguirá …...

EA1N - Javi-

No sé si te has descargado el manual "PC Control Command" de la TS-590SG, que me imagino que sí, sobretodo, para saber como deben ir formateados los datos que se envían y reciben.

Por cierto, mira también la hoja de características técnicas del MAX3232.

Me imagino, que también habrás configurado la TS-590 para que se comunique por RS-232, no por USB.

En dicho manual, en la página 1, explica la activación del comando AI  para intentar asegurarte que la TS590 envía automáticamente datos por el puerto cada vez que hay un cambio de estado en la emisora (frecuencia, por ejemplo, o modo, etc.). Para activar la función Auto Información utiliza "AI2;"

Asegúrate tener un programa o comando preparado para que deje de enviar la "Auto Información" ("AI0;").

Al menos te aseguras que la emisora envía datos y el arduino puede quedarse permanentemente a la escucha. A ver si así eres capaz de leer algo con el arduino. Más que nada, es que puede ocurrir que el tiempo del "delay" sea lo suficientemente largo como para que el arduino se haya perdido la transmisión de esos pocos bytes.

Otro consejo, revisa bien los ejemplos con "Serial" del arduino. Al igual encuentras algo que se te acomode mejor.

Saludos. Jacinto.

@ea2j Hola Enio, lo del cursillo de programacion, me parece una idea muy buena, yo me apunto.

TNX.

@ea7khb

Mas cosas..... El CTS y RTS son para el control del flujo, y para no tener que pelear con la configuracion del cat, esta el truco de que el equipo se autoengañe, puenteando los dos, peeeeero en el conector del equipo, osea, puentear el pin 7 y 8 del conector del kenwood.

Con las lineas bien conectadas y esos pines puenteados y tienes el hardware preparado, ahora es cuestión de software.

El primer programa que pusiste no esta enviando continuamente la cadena IF; ya que la envia la primera vez y pone la variable isSend en true, y hasta que no recibe por le puerto serie el caracter ; no la vuelve a retornara a valor false, por lo tanto no volverá a enviar nunca mas la cadena IF;.... solo lo hara tras recibir por el puerto serie el caracter ;  …  y no es tu caso, ya que no hay comunicacion con el equipo.

Por otro lado tampoco es cierto que kenwood envie un BCD con la banda por el cat... por el cat puedes extraer la frecuencia, peor no hay ningun BCD por cat. A cualquier equipo a través con cat se le extrae la frecuencia para usarla en lo que interese, y aparte Icom trae la salida de tensión para saber la banda, Yaesu una salidas que combinándolas se genera un BCD para saber en que banda está. Pero Kenwood solo es posible decodificar la banda a través de extraer la frecuencia por el cat.

 Si haces las conexiones correctas, en el primer programa que pusiste la velocidad con la que abres el puerto es la misma que la configurada en el equipo, tiene que funcionar sin ningún problema, pero apostaría a que o no tienes bien cableado el MAX 232 o la velocidad no es la misma.

No le des vueltas al TTL invertido... el MAX232 ya te genera el TTL estándar que entenderán los arduinosy el tener que invertir esa señal era par equipos antiguos.

@ea1n Ahí voy. Nos gusta complicarnos la vida tontamente.

Antes de empezar un proyecto así, soy de los que piensa que, primero se recopila la información: hojas de características (y más si podemos sospechas de errores de serigrafía en una placa), manuales de todo tipo y leer un poco primero de las fuentes, como de los ejemplos de arduino, muy simples, muy tontos, pero con 4 líneas te los ajustas a tus necesidades. Y sabes que están super-comprobados. Se estudia y se hacen la pruebas básicas en un entorno muy, muy controlado.

A partir de ahí, empezamos con los pinitos que nos dé la gana.

Tomar fuentes de terceros, siempre es muy complicado. ¡Pero si ya es complicado tomar los tuyos propios pasado un tiempo por mucho que los documentes...!

Por mucho que el MEGA pueda reconocer lógica de 3,3 V, y por mucho que el MAX3232 pueda soportar entradas de 5V, nunca es buena práctica mezclar a pelo electrónica con lógica de diferentes niveles. Pero como no nos hemos parado a leer la hoja de características del MAX3232, no sabemos que podemos alimentarlo desde 3 a 5,5V... Eso sí, vamos a suponer que ese chip es original (que tampoco sé si lo es o es una copia barata, con lo que puede ser cualquier cosa)...

En fin. Lo divertido de esto, es que todos cacharreamos y nos divertimos.

Saludos. Jacinto.

Publicado por: @ec5apb

@ea1n Ahí voy. Nos gusta complicarnos la vida tontamente.

Antes de empezar un proyecto así, soy de los que piensa que, primero se recopila la información: hojas de características (y más si podemos sospechas de errores de serigrafía en una placa), manuales de todo tipo y leer un poco primero de las fuentes, como de los ejemplos de arduino, muy simples, muy tontos, pero con 4 líneas te los ajustas a tus necesidades. Y sabes que están super-comprobados. Se estudia y se hacen la pruebas básicas en un entorno muy, muy controlado.

Totalmente de acuerdo en este punto, por eso me he preocupado de mirar el manual del equipo para saber los pines, del DB9 del equipo y comprobar físicamente las placas chinas con el MAX232.... y los de los manuales...ojo a las versiones españolas, ya que a veces hay errores en la traduccion, si puedo directamente al manual en ingles.

A partir de ahí, empezamos con los pinitos que nos dé la gana.

Tomar fuentes de terceros, siempre es muy complicado. ¡Pero si ya es complicado tomar los tuyos propios pasado un tiempo por mucho que los documentes...!

También de acuerdo... pero en este caso el primer programa es muy sencillo.

Por mucho que el MEGA pueda reconocer lógica de 3,3 V, y por mucho que el MAX3232 pueda soportar entradas de 5V, nunca es buena práctica mezclar a pelo electrónica con lógica de diferentes niveles. Pero como no nos hemos parado a leer la hoja de características del MAX3232, no sabemos que podemos alimentarlo desde 3 a 5,5V... Eso sí, vamos a suponer que ese chip es original (que tampoco sé si lo es o es una copia barata, con lo que puede ser cualquier cosa)...

Mas coincidencias con tus comentarios, por eso dije que aunque sea compatible con tensiones de 3,3v mejor usar 5v.

En fin. Lo divertido de esto, es que todos cacharreamos y nos divertimos.

Saludos. Jacinto.

 

Reconozco que no somos muy dados a leer (me incluyo), pero para estas cosas conviene siempre repasar la documentación para evitar rompederos de cabeza y humo en la habitación.

Venga … a seguir peleando con las cosas, que es como se aprende, que si nos lo dan todo hecho, no nos sirve para nada..... 

Un saludo

EA1N - Javi -