Archivo de la etiqueta: Comunicaciones

Análisis: Kits Aprendizaje XBee de Digi

La gente de Digi en Logroño me ha dejado para probar dos kits de aprendizaje para que los pruebe y de paso me sirvan para preparar la parte de comunicación inlambrica del curso Arduino avanzado en http://www.aprendiendoarduino.com/arduino-avanzado-2016/.

Los kits que he probado son:

Se trata de unos kits de aprendizaje de los famosos módulos RF XBee que fabrica Digi para comunicación inalámbrica y que pueden adquirirse en digi-key electronics http://www.digikey.es/

En la caja de ambos kits viene todo el hardware y el enlace a la web donde se encuentran los tutoriales y guías para el uso de los kits.

Veamos por separado cada uno de los kits.

Digi Wireless Connectivity Kit

Aunque el uso que voy a hacer los los módulos va a ser siempre con Arduino, me decidí empezar con este kit que no tiene Arduino ni posibilidad de conectar con un microcontrolador directamente, porque me parecía más sencillo y me quería centrar en aprender la tecnología ZigBee y manejar los módulos XBee de Digi, y no me equivoqué.

Luego con el siguiente kit (XBee Arduino Compatible Coding Platform) y los conocimientos adquiridos, me resultó más fácil manejar los módulos XBee con Arduino.

El hardware de este kit es muy sencillo, se compone de dos módulos XBee serie 1 o XBee 802.15.4 que son unos módulos muy sencillos de Xbee, dos placas de desarrollo para los módulos con conectores grove y dos cables micro USB para conectar las placas de desarrollo al ordenador.

wireless_connectivity_kit_500x316

Este hardware puede comprarse en digi-key en el siguiente enlace: http://www.digikey.es/product-detail/es/digi-international/XKB2-AT-WWC/602-1551-ND/5305247 y tiene un coste de 59$ (aproximadamente 53€).

En la web de digi-key hay un kit nuevo http://www.digikey.es/product-detail/es/digi-international/XKB2-A2T-WWC/602-1902-ND/6010111 que usa los módulos XBee S2C 802.15.4

En mi caso el que he probado es el que lleva los módulos Serie 1:

También hay otros kits disponibles: http://www.digikey.es/en/product-highlight/d/digi-intl/xbee-arduino-coding-platform

Sobre el hardware, decir que es muy sencillo y útil para el aprendizaje, pero luego solo se podría reutilizar los módulos RF, porque las placas de desarrollo no les veo mucha salida salvo para hacer las prácticas propuestas en el kit. A estas placas de desarrollo les añadiría una salida accesible del puerto serie con un selector a 3.3 o 5 V para poder conectarlas a una Raspberry Pi o un Arduino y poder seguir usándolas y aprender la integración con otros dispositivos, ya que sino están limitadas al uso con el ordenador.

Para usar este hardware Digi pone a disposición de los compradores del kit y del resto del mundo un tutorial que va contando paso a paso cómo montar los módulos, como instalar el software necesario para configurar y manejar los Xbee, explica cómo funcionan los módulos y en cada apartado propone ejercicios prácticos para usarlo con el kit adquirido.

Este completo tutorial es accesible desde: http://www.digi.com/resources/documentation/Digidocs/90001456-13/Default.htm

PDF del tutorial: http://www.digi.com/resources/documentation/digidocs/pdfs/90001456-13.pdf

Este tutorial es la gran aportación de Digi para aprender a manejar sus módulos RF desde cero y te guia paso a paso como si de un curso online fuera.

El tutorial comienza con ejemplos muy sencillos y hace una guía paso a paso para aprender el manejo los módulos. Los puntos más importantes que se ven son:

Este tutorial es perfecto para aprender a manejar los módulos de una forma muy didáctica, aunque en algunos aspectos se queda corto en la explicación (al menos para los más curiosos) y hay que hacer un acto de fe que con esa configuración funciona, pero en algún caso sin explicar bien porqué. Esa falta de información puede llevar a error en un par de casos a la hora de hacer funcionar la práctica, pero pensando un poco es sencillo resolverlo.

Otro defecto de este tutorial, al menos para mi, es que los ejercicios más interesantes los hace con Java para crear una aplicación en el ordenador que se conecte a los módulos e interactúe con ellos, pero yo añadiría esos mismos ejercicios con algún otro lenguaje como python con .NET.

El objetivo de este kit junto con el manual es aprender a manejar los módulos RF de XBee para la conexión de dispositivos y sensores y lo cumple a la perfección. Además por aprox. 53€ después de aprender a usarlos puedes reutilizar los módulos XBee en cualquier proyecto.

Para mis cursos en www.aprendiendoarduino.com uso como base este tutorial para enseñar como manejar los módulos Xbee.

XBee Arduino Compatible Coding Platform

El segundo kit de aprendizaje de Digi que he probado, comencé a usarlo cuando ya había probando a fondo el anterior (Wireless Connectivity Kit) y conocía bien el uso de los módulos RF de XBee, lo que me facilitó mucho el uso de este kit, puesto que la parte más teórica del funcionamiento de los módulos de XBee no viene en el tutorial de este kit.

El hardware de este kit es muy completo y trae entre otras cosas:

Todo el contenido del kit está en http://docs.digi.com/display/XBeeArduinoCodingPlatform/Kit+contents

wirelessgamekit

Este hardware puede comprarse en digi-key en el siguiente enlace por 99$ (aproximadamente 89,11€): http://www.digikey.es/product-detail/en/digi-international/XKB2-AT-WWG/602-1550-ND/5271212

La verdad es que es un buen precio por el kit teniendo en cuenta que tenemos 3 módulos XBee.

Datasheets:

Sobre el hardware, decir que es muy completo y que todos los materiales que vienen pueden ser reutilizados para otros proyectos.

Para usar este hardware Digi pone a disposición de los compradores del kit y del resto del mundo un tutorial que va contando paso a paso diversos proyectos enfocados al juego, tanto con Arduino como interacción con el ordenador.

El tutorial es accesible desde: http://docs.digi.com/display/XBeeArduinoCodingPlatform/XBee+Arduino+Compatible+Coding+Platform

Este tutorial empieza haciendo una breve descripción del kit y luego explica la instalación del software XCTU y un primer ejemplo. Luego ya entra de lleno en los proyectos.

El kit incluye cinco proyectos con processing para demostrar la interacción con software y otros 5 proyectos con Arduino, para hacer circuitos inalámbricos con los módulos XBee.

Este tutorial se centra en los proyectos que son muy didácticos, pero apenas trata la parte más teórica del funcionamiento de XBee. En algunos proyectos hay enlaces a los aspectos de cómo funcionan los módulos XBee, pero están un poco escondidos y no son accesibles desde el menú lateral.

Los proyectos me gustan, pero de nuevo hay que hacer un acto de fe que las configuraciones que nos dan funcionan, aunque no se explica porque los parámetros que funcionan son esos y no otros.

Al final de cada proyecto hay un apartado llamado “Learn More” y en muchos casos apunta al tutorial del anterior kit (Wireless Connectivity Kit), lo que confirma mi idea que antes de empezar con este kit, es recomendable leer el tutorial del kit anterior si quieres conocer bien el manejo de los módulos XBee.

Después de los proyectos y para finalizar hay varios apartados de información adicional, especialmente interesantes el de troubleshooting y XBee buying guide.

Proyectos Usando Processing

Los proyectos propuestos en este tutorial para interacción de XBee con software, en este caso con processing, son:

Todo el código está disponible en:

Estos proyectos no están actualizados a la última versión 3 de processing, lo que provoca que aparezca algún pequeño error en el código fácilmente solucionable.

Estos 5 proyectos son básicamente iguales y nos enseñan cómo interactuar hardware y software de forma inalámbrica. Nos da la configuración de los dos módulos, uno conectado al ordenador y otro a unos botones, potenciómetros, etc… y nos da el software a ejecutar. Luego simplemente es ver como interactua.

Los dos primeros proyectos demuestra el pin pairing y cómo funciona la librería de XBee en processing y por lo tanto en ese caso el módulo XBee debe estar en modo API. El cuarto proyecto es igual que el segundo pero en lugar de usar un módulo, usa dos módulos. En el tercer proyecto añade un tercer módulo y la entradas analógicas con un potenciómetro y el envío de lecturas cada 100 ms. El último proyecto mezcla lo aprendido en los anteriores y monta un controlador de juegos inalámbrico.

Una mejora que podría incluir el código de processing es sacar por pantalla lo recibido por el módulo XBee, que serviría para hacer debug y aprender un poco más del modo API. Sería sencillo añadir esa funcionalidad por nuestra parte.

También sería interesante añadir a este kit algún ejemplo con lenguajes de programación más usados como python o .NET.

Proyectos Usando Arduino

Los proyectos propuestos en este tutorial para uso de XBee con Arduino son:

Los 4 primeros proyectos son muy parecidos trabajando la comunicación inalámbrica con Arduino, la librería de XBee y los conceptos de cambio de estado de pin y las entradas y salidas de los módulos XBee. El último ejemplo introduce otros conceptos como el de coordinador y RSSI o indicador de fuerza de señal recibida.

Al contrario que tutorial del anterior kit, no se habla casi nada de la parte de cómo funcionan los módulos XBee y cómo interactúan con Arduino. Hay un apartado de trabajando con Arduino http://docs.digi.com/display/XBeeArduinoCodingPlatform/Working+with+Arduino donde se ven unas nociones básicas de Arduino y otra de como instalar la librería xbee-arduino en http://docs.digi.com/display/XBeeArduinoCodingPlatform/Installing+the+xbee-arduino+library, pero no está actualizado a las nuevas versiones del IDE de Arduino, aunque en el enlace al repositorio de github de la librería si lo explica: https://github.com/andrewrapp/xbee-arduino

Un aspecto que sería muy interesante es documentar la librería xbee-arduino explicando que hace cada método de los disponibles, porque sino no nos queda más remedio que ponerse a leer el código de la librería y averiguarlo por tu cuenta.

El código de los ejercicios está disponible en https://github.com/digidotcom/XBeeArduinoCodingPlatform para descargar o hacer fork.

A la hora de hacer los ejercicios, si algo no funciona, es imposible hacer troubleshooting porque no se proporciona una forma de mandar por puerto serie todo lo que le llega de Arduino. Un poco de debug es necesario no solo para ver que puede estar fallando sino para aprender cómo funciona la comunicación entre Arduino y XBee.

Este kit tiene 3 módulos pero sólo es posible hacer ejemplos de comunicación multipunto, pero no es posible hacer esquemas de comunicación mesh, puestos que los módulos del kit no tienen esa funcionalidad.

En este tutorial apenas se ofrece parte teórica, lo que hace que si no hubiera hecho el anterior tutorial me hubiera costado un poco más entender el funcionamiento de los módulos XBee o hacer un acto de fe de que las configuraciones funcionan, pero la parte de la explicación de las conexiones y los proyectos es muy buena.

Los puntos más interesantes del tutorial son:

El objetivo de este kit junto con el manual es aprender más sobre cómo los módulos XBee pueden integrarse fácil y rápidamente con otros elementos (como Arduino o software) para conseguir conectividad inalámbrica y en mi opinión se consigue.

Conclusión

La gran ventaja de uso de los módulos RF XBee frente a otros es la sencillez de uso gracias al potente programa de configuración XCTU. Esto permite aplicar tecnología inalámbrica de forma rápida y sencilla a nuestros proyectos. La desventaja es el precio, son más caros que otros módulos equivalentes como los nRF24.

Con estos kits de aprendizaje se consigue aprender cómo funcionan los módulos XBee y cómo manejarlos. Los tutoriales disponibles en general están muy bien para aprender como si de un curso online se tratara.

Con estos kits he aprendido mucho, pero para los curiosos que nos gusta llegar más al fondo se quedan un poco cortos y he usado este documento http://www.hmangas.com/Electronica/Datasheets/Shield%20XBee%20Arduino/XBee-Guia_Usuario.pdf para profundizar y aclarar algunos conceptos.

Agradecer a Digi Logroño y en especial al Carlos que me hayan prestado este material y poder ampliar mi conocimiento sobre la tecnología XBee y así poder incluirla en mis cursos.

Más información de XBee en mis cursos y talleres de www.aprendiendoarduino.com y en el apartado XBee del curso avanzado de Arduino http://www.aprendiendoarduino.com/arduino-avanzado-2016/

Si quieres saber cuándo publicaré en la web los próximos cursos de XBee y donde los impartiré presencialmente, puedes enterar a través de mi twitter @jecrespom o en la lista de correo de #aprendiendoarduino http://list.aprendiendoarduino.com/mailman/listinfo/aprendiendoarduino.com.noticias

Arduino Web Server

Crear un servidor web sencillo que saque por el puerto serie y también devuelva al navegador que le ha llamado la petición http que le ha llegado.

Luego añadir el valor leído en la entrada analógica A0.

Por último leer línea a línea la petición, esto es útil cuando hay que analizar el http request y que Arduino devuelva una cosa u otra en función de la petición que llegue.

Tutorial webserver: http://playground.arduino.cc/Code/WebServerST

Solución: https://github.com/jecrespo/Aprendiendo-Arduino/tree/master/Ejercicio26-EthernetServer

Otro ejemplo similar muy bien explicado: https://wngeek.wordpress.com/2013/07/24/185/

Al igual que hemos hecho un web server podríamos implementar un telnet server escuchando por el puerto 23. Ejemplos:

Web Embebida con Arduino

Crea una web embebida en Arduino con un botón que al pulsarlo desde el navegador encienda un led y al volver a pulsarlo apague un led.

Al recibir un get Arduino muestra una web para encender o apagar el led en función del estado del led.

Cuando pulso el botón de la web, el navegador manda un post con la instrucción de encender o apagar el led, Arduino la ejecuta y devuelve el estado en que queda el led y te da la opción de volver a la página anterior.

NOTA: Aquí además de programar arduino, se usan conceptos de HTML

Solución: https://github.com/jecrespo/Aprendiendo-Arduino/tree/master/Ejercicio27-Boton

Otro tutorial similar: http://diymakers.es/crear-servidor-web-con-arduino/

Webserver con Ajax

Crear una web embebida que controle el encendido y apagado de un led tanto manualmente pulsando un botón como automáticamente al sobrepasar un umbral que pasamos a Arduino como parámetro mediante la web con una entrada numérica. Podría asemejarse a un termostato donde la entrada es una sonda de temperatura y su valor lo comparo con la temperatura que le paso como parámetro.

La web mostrará el estado de varias entradas analógicas, un botón para encender manualmente el led y una entrada numérica para enviar el dato del umbral.

web_ajax

NOTA: aquí se usa programación en javascript para ajax.

Ajax es una técnica muy eficaz para estos casos porque para mostrar los datos actualizados dinámicamente no es necesario cargar la web completamente, sino que sólo manda los datos que se actualizan en la web que son unos pocos bytes.

Mediante Ajax podemos actualizar los datos de la web embebida en Arduino sin necesidad de cargar toda la web, sino solo mandando los datos actualizados, economizando los datos mandados a través de la red.

Ajax:

Solución: https://github.com/jecrespo/Aprendiendo-Arduino/tree/master/Ejercicio42-Ajax

Web Embebida en Linux

Otra técnica para tener una web embebida en Arduino es usar los Arduino Yun o Tian que tiene un procesador MIPS con un linux embebido y usar un servidor web linux para servir las páginas. Luego mediante las librerías bridge o ciao se puede comunicar el microntrolador de Arduino con el procesador MIPS.

En este caso la web está en un servidor web del sistema operativo openWRT basado en linux y al interactuar con él la librería bridge se encarga de comunicar internamente linux con el microcontrolador del Arduino Yun.

Ejemplo para controlar los leds de un neopixel mediante una web en un Arduino Yun: https://github.com/jecrespo/NeoPixel

Neopixel: https://www.adafruit.com/category/168

Control del coche: https://github.com/jecrespo/Coche_AprendiendoArduino

Ethernet Shield

El Arduino ethernet shield nos da la capacidad de conectar un Arduino a una red ethernet. Es la parte física que implementa la pila de protocolos TCP/IP.

Está basada en el chip ethernet Wiznet W5100. El Wiznet W5100 provee de una pila de red IP capaz de soportar TCP y UDP. Soporta hasta cuatro conexiones de sockets simultáneas. Usa la librería Ethernet para leer y escribir los flujos de datos que pasan por el puerto ethernet. Me permitirá escribir sketches que se conecten a internet usando la shield.

Datasheet de W5100: https://www.sparkfun.com/datasheets/DevTools/Arduino/W5100_Datasheet_v1_1_6.pdf

Librería ethernet: http://arduino.cc/en/Reference/Ethernet

El shield provee un conector ethernet estándar RJ45. La ethernet shield dispone de unos conectores que permiten conectar a su vez otras placas encima y apilarlas sobre la placa Arduino.

Arduino usa los pines digitales 10, 11, 12, y 13 (SPI) para comunicarse con el W5100 en la ethernet shield. Estos pines no pueden ser usados para e/s genéricas.

El botón de reset en la shield resetea ambos, el W5100 y la placa Arduino.

La shield contiene varios LEDs para información:

  • ON: indica que la placa y la shield están alimentadas
  • LINK: indica la presencia de un enlace de red y parpadea cuando la shield envía o recibe datos
  • 100M: indica la presencia de una conexión de red de 100 Mb/s (de forma opuesta a una de 10Mb/s)
  • RX: parpadea cuando el shield recibe datos
  • TX: parpadea cuando el shield envía datos

El jumper soldado marcado como “INT” puede ser conectado para permitir a la placa Arduino recibir notificaciones de eventos por interrupción desde el W5100, pero esto no está soportado por la librería Ethernet. El jumper conecta el pin INT del W5100 al pin digital 2 de Arduino.

El slot SD en la shield usa la librería http://arduino.cc/en/Reference/SD para manejarlo. El propio chip W5100 incluye el manejo de tarjetas SD.

Para usar la Ethernet Shield solo hay que montarla sobre la placa Arduino. Para cargar los sketches a la placa con el shield, conectarla al ordenador mediante el cable USB como se hace normalmente. Luego conectar la Ethernet a un ordenador, a un switch o a un router utilizando un cable ethernet standard (CAT5 o CAT6 con conectores RJ45). La conexión al ordenador puede requerir el uso de un cable cruzado (aunque muchos ordenadores actuales, pueden hacer el cruce de forma interna).

Un tutorial sencillo para comenzar con el shield ethernet en: http://www.artinteractivo.com/arduino-ethernet

Para cualquier duda sobre el ethernet Shield consultar: http://arduino.cc/en/Main/ArduinoEthernetShield

Puntos a recordar del Ethernet Shield:

  • Opera a 5V suministrados desde la placa de Arduino
  • El controlador ethernet es el W5100 con 16K de buffer interno. No consume memoria.
  • El shield se comunica con el microcontrolador por el bus SPI, por lo tanto para usarlo siempre debemos incluir la libreria SPI.h: http://arduino.cc/en/Reference/SPI
  • Soporta hasta 4 conexiones simultáneas
  • Usar la librería Ethernet para manejar el shield: http://arduino.cc/en/Reference/Ethernet
  • El shield dispone de un lector de tarjetas micro-SD que puede ser usado para guardar ficheros y servirlos sobre la red. Para ello es necesaria la librería SD: http://arduino.cc/en/Reference/SD
  • Al trabajar con la SD, el pin 4 es usado como SS.

Arduino UNO se comunica con W5100 y la tarjeta SD usando el bus SPI a través del conector ICSP. Por este motivo los pines 10, 11, 12 y 13 en el UNO y los 50, 51, 52 y 53 en el Mega no podrán usarse. En ambas placas los pines 10 y 4 se usan para seleccionar el W5100 y la tarjeta SD. El Ethernet y el SD no pueden trabajar simultáneamente y debemos tener cuidado al usar ambos de forma conjunta.

Para conectar el shield, se deben seguir estas instrucciones: http://arduino.cc/en/Guide/ArduinoEthernetShield

El esquemático lo podéis encontrar en: http://arduino.cc/en/uploads/Main/arduino-ethernet-shield-06-schematic.pdf

Arduino Ethernet Shield 2

Arduino Ethernet Shield es una placa que aparece en la web de arduino.cc como retirado, pero sigue estando disponible como clones o versiones derivadas.

Por otra parte arduino.org a sacado el Arduino Etherner Shield 2 con el nuevo Wiznet 5500 http://www.arduino.org/products/shields/arduino-ethernet-shield-2

Este Shield usa la librería ethernet2: http://www.arduino.org/learning/reference/Ethernet-two-Library

Data sheet de W5500: https://www.sos.sk/productdata/15/26/12/152612/W5500_datasheet_v1.0.2_1.pdf

Mejoras de W5500: https://feilipu.me/2014/11/16/wiznet-w5500-ioshield-a/

Power over Ethernet

El Ethernet shield es compatible con PoE gracias a un módulo adicional que extrae la energía eléctrica del cable ethernet, anteriormente inyectada desde el switch.

Las características del módulo PoE:

  • IEEE802.3af compliant
  • Low output ripple and noise (100mVpp)
  • Input voltage range 36V to 57V
  • Overload and short-circuit protection
  • 9V Output
  • High efficiency DC/DC converter: typ 75% @ 50% load
  • 1500V isolation (input to output)

Data sheet: http://arduino.cc/en/uploads/Main/PoE-datasheet.pdf

Más información sobre el Power Over Ethernet:

Como funciona PoE:

http://www.bb-elec.com/Learning-Center/All-White-Papers/Ethernet/Power-over-Ethernet-PoE.aspx

Phantom Feeding:

Alimentación sobre cables libres:

WIZnet W5100

El integrado W5100 se conecta al arduino mediante SPI.

Para saber todo sobre el W5100 revisar: http://www.ermicro.com/blog/?p=1773

Básicamente el Wiznet W5100 implementa una pila TCP con todas las funciones del estándar IEEE 802.3 (Ethernet capa física y de enlace de datos) dentro del chip; esto hace que el chip Wiznet W5100 sea buena opción para integrar el sistema embebido en internet. La programación del chip de Wiznet W5100 es también fácil ya que sólo tenemos que escribir y leer desde y hacia los registros internos W5100 con el fin de utilizar el construir funciones de los protocolos TCP/IP.

El Wiznet W5100 actuará como un dispositivo esclavo SPI controlado por microcontrolador ATMega328 como el SPI Maestro. Necesita el protocolo SPI al menos cuatro señales, MOSI (Master Out Serial In), MISO (Master In Serial Out), SCK (señal de reloh proporcionada por el maestro) y CS (the SPI slave chip select). El chip W5100 también proporciona el pin de interrupción.

Especificaciones:

¿Es posible hacer pings con arduino?

Sí, pero por supuesto con una librería: http://playground.arduino.cc/Code/ICMPPing

¿Soporta Arduino IPv6?

El shield oficial de arduino basado en el WizNet 5100 implementa la pila de protocolos IPv4, por lo que está shield no puede ser utilizada para implementar la pila IPv6.

Para implementar la pila IPv6, es necesario usar un shield basado en hardware que permita la gestión de la funciones de las capas de IP y ethernet. Shields basados en el chip MicroChip ENC28J60 son adecuados para la implementación de IPv6. Esto requiere la implementación de una gestión de los estados TCP, resultando un código de arduino más complejo.

Datasheet Chip ethernet IPv6:

Más información sobre IPv6: https://sites.google.com/site/ghoelzl/ipv6

IPv6WebServer: https://sites.google.com/site/ghoelzl/ipv6ethershield/ipv6_http_server

Y aun más… http://www.tweaking4all.com/hardware/arduino/arduino-enc28j60-ethernet/

Y otro ejemplo: http://www.fut-electronics.com/wp-content/plugins/fe_downloads/Uploads/Ethernet-Module-ENC28J60-Arduino.pdf

Librerías:

Protocolo HTTP

Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo de comunicación que permite las transferencias de información en la WWW. Se trata de un protocolo de capa 7 de aplicación.

En arduino con la librería ethernet solo trabajamos con la capa de aplicación, todas las otras capas de TCP/IP ya están implementadas por Hardware, ya sea con la ethernet shield o el módulo WiFi. Aunque si queremos realizar algunas funciones de capas inferiores, podemos hacerlo con los comandos adecuados comunicándonos con el chip ethernet o wifi via SPI.

Veamos algunos protocolos de la capa de aplicación que serán los que tengamos que implementar en nuestro arduino directamente o usando la librería adecuada:

HTTP es un protocolo muy importante puesto que es el que se va a usar para comunicar Arduino con cualquier elemento de la WWW o de una intranet. En el IoT es uno de los protocolos más usados y sobre todo si queremos obtener o mandar datos a servidores o usar las APIs que nos ofrecen algunos servicios para obtención de información, por ejemplo, para obtener el tiempo meteorológico y con esos datos que arduino actúe de una forma u otra.

Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo usado en cada transacción de la World Wide Web. HTTP fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force.

HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador web) se lo conoce como “user agent” (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL).

HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de “sesión”, y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

Una transacción HTTP está formada por un encabezado seguido, opcionalmente, por una línea en blanco y algún dato. El encabezado especificará cosas como la acción requerida del servidor, o el tipo de dato retornado, o el código de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se envíe información descriptiva en la transacción, permitiendo así la autenticación, cifrado e identificación de usuario. Ejemplos de encabezados: HTTP_ACCEPT y HTTP_USER_AGENT.

Más información sobre HTTP:

Para intercambio de archivos por HTTP usamos: http://es.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions

Líneas de encabezado o headers, son muy importantes y dan información adicional de la conexión y el comportamiento puede cambiar en función de ellas:

Métodos de petición

Lo más importante para comunicar arduino por HTTP con otros dispositivos, ya sean servidores, ordenadores, otros Arduinos, etc… es conocer los métodos GET y POST del protocolo HTTP. HTTP define 8 métodos que indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de forma dinámica, depende de la aplicación del servidor. A menudo, el recurso corresponde a un archivo o la salida de un ejecutable que residen en el servidor.

GET

GET: Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que causen efectos ya que transmite información a través de la URI agregando parámetros a la URL. La petición puede ser simple, es decir en una línea o compuesta de la manera que muestra el ejemplo.

Ejemplo:

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png

Ejemplo con parámetros:

/index.php?page=main&lang=es

POST

POST: Envía los datos para que sean procesados por el recurso identificado. Los datos se incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.

Más información:

Entender los métodos get y post:

Un explicación muy buena de HTTP también se puede encontrar en:  http://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html

HTTP request

Un cliente HTTP debe formar una petición HTTP al servidor de una forma determinada para que sea entendida por el servidor. Cuando Arduino trabaja como cliente hay que programar esta petición correctamente.

Formación de un HTTP request, esta petición habrá que programar en Arduino:

Trama en HTTP, fijaros en el uso de cr (retorno de carro – carriage return – ASCII 13) y lf (line feed – nueva linea – ASCII 10): http://www1.ju.edu.jo/ecourse/abusufah/cpe532_Spr06/notes/BookOnLine/HTTP%20Request%20Message.htm

HTTP/1.1 se definió en el estándar RFC2616,que es la más usada actualmente. En junio de 2014 RFC2616 se retiró y HTTP/1.1 se redefinió en RFCs 7230, 7231, 7232, 7233, 7234, and 7235, HTTP/2 está en proceso de definición.

Y cuando usar GET o POST?: http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist

HTTP response

Después de recibir e interpretar el servidor un HTTP request, el servidor debe responder con un mensaje de respuesta:

Para cumplir con el protocolo HTTP, arduino debe implementar estas respuestas cuando lo uso como servidor web.

Veamos esto gráficamente:

Ejercicio: Ver las tramas HTTP con las funciones de depuración del navegador y también con wireshark, un web sniffer on-line y algún plugin para el navegador.

WireShark: https://www.wireshark.org/

Chrome plugin Sniffer: http://5ms.ru/sniffer/

on-line: http://web-sniffer.me/

Listado de web sniffers: http://scraping.pro/web-sniffers-review/

TCP/IP

El modelo TCP/IP describe un conjunto de guías generales de diseño e implementación de protocolos de red específicos para permitir que un equipo pueda comunicarse en una red. TCP/IP provee conectividad de extremo a extremo especificando como los datos deberían ser formateados, direccionados, transmitidos, enrutados y recibidos por el destinatario.

Más información: https://es.wikipedia.org/wiki/Modelo_TCP/IP

La importancia del modelo TCP/IP es que es el modelo usado para acceder a Internet o a redes internas (Intranet) de ordenadores. Arduino va a permitir conectarse a Internet o a una red interna mediante TCP/IP y poder realizar múltiples operaciones o usarse como pasarela para conectar a Internet dispositivos que no tienen esa capacidad. La implementación de la pila de protocolos de TCP/IP en Arduino se hace mediante un shield o HW adicional que nos da la capa de acceso a red (ethernet o WiFi), internet (IP) y transporte. La capa de aplicación deberemos implementarla dentro de Arduino ya sea directamente o mediante una librería.

En el caso del protocolo TCP/IP la pila OSI se simplifica:

Capa de Aplicación. Invoca programas que acceden servicios en la red. Interactúan con uno o más protocolos de transporte para enviar o recibir datos, en forma de mensajes o bien en forma de flujos de bytes.
Capa de Transporte. Provee comunicación extremo a extremo desde un programa de aplicación a otro. Regula el flujo de información. Puede proveer un transporte confiable asegurándose que los datos lleguen sin errores y en la secuencia correcta. Coordina a múltiples aplicaciones que se encuentren interactuando con la red simultáneamente de tal manera que los datos que envíe una aplicación sean recibidos correctamente por la aplicación remota, esto lo hace añadiendo identificadores de cada una de las aplicaciones. Realiza además una verificación por suma, para asegurar que la información no sufrió alteraciones durante su transmisión.
Capa Internet. Controla la comunicación entre un equipo y otro, decide qué rutas deben seguir los paquetes de información para alcanzar su destino. Conforma los paquetes IP que será enviados por la capa inferior. Desencapsula los paquetes recibidos pasando a la capa superior la información dirigida a una aplicación.
Capa de Interfaz de Red. Emite al medio físico los flujos de bit y recibe los que de él provienen. Consiste en los manejadores de los dispositivos que se conectan al medio de transmisión.

Más información en: http://www.uca.edu.sv/investigacion/tutoriales/tcp-ip.html

Los elementos de red (switches, routers, etc…) no llegan hasta la última capa y se podría representar así la comunicación entre dos dispositivos.

Algunos elementos de la red de comunicación pueden llegar a capas superiores a la de red e incluso hasta la capa de aplicación como los firewalls para detectar ataques en capas superiores. Es el caso de firewalls de estado y de aplicación. Un cortafuegos de aplicación puede filtrar protocolos de capas superiores tales como FTP, TELNET, DNS, DHCP, HTTP, TCP, UDP y TFTP (GSS). Por ejemplo, si una organización quiere bloquear toda la información relacionada con una palabra en concreto, puede habilitarse el filtrado de contenido para bloquear esa palabra en particular. No obstante, los cortafuegos de aplicación resultan más lentos que los de estado.

Conexión y desconexión

El proceso de establecimiento de una conexión TCP se denomina “three way handshake” Durante el establecimiento de la conexión, se configuran algunos parámetros tales como el número de secuencia con el fin de asegurar la entrega ordenada de los datos y la robustez de la comunicación.

Aunque es posible que un par de entidades finales comiencen una conexión entre ellas simultáneamente, normalmente una de ellas abre un socket en un determinado puerto TCP y se queda a la escucha de nuevas conexiones. Es común referirse a esto como apertura pasiva, y determina el lado servidor de una conexión. El lado cliente de una conexión realiza una apertura activa de un puerto enviando un paquete SYN inicial al servidor como parte de la negociación en tres pasos. En el lado del servidor (este receptor también puede ser una PC o alguna estación terminal) se comprueba si el puerto está abierto, es decir, si existe algún proceso escuchando en ese puerto, pues se debe verificar que el dispositivo de destino tenga este servicio activo y esté aceptando peticiones en el número de puerto que el cliente intenta usar para la sesión. En caso de no estarlo, se envía al cliente un paquete de respuesta con el bit RST activado, lo que significa el rechazo del intento de conexión. En caso de que sí se encuentre abierto el puerto, el lado servidor respondería a la petición SYN válida con un paquete SYN/ACK. Finalmente, el cliente debería responderle al servidor con un ACK, completando así la negociación en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento de conexión. Es interesante notar que existe un número de secuencia generado por cada lado, ayudando de este modo a que no se puedan establecer conexiones falseadas (spoofing).

Más información:

La fase de finalización de la conexión utiliza una negociación en cuatro pasos (four-way handshake), terminando la conexión desde cada lado independientemente. Sin embargo, es posible realizar la finalización de la conexión en 3 fases; enviando el segmento FIN y el ACK en uno solo. Cuando uno de los dos extremos de la conexión desea parar su “mitad” de conexión transmite un segmento con el flag FIN en 1, que el otro interlocutor asentirá con un ACK. Por tanto, una desconexión típica requiere un par de segmentos FIN y ACK desde cada lado de la conexión.

Una conexión puede estar “medio abierta” en el caso de que uno de los lados la finalice pero el otro no. El lado que ha dado por finalizada la conexión no puede enviar más datos pero la otra parte si podrá.

Es importante conocer este apartado porque a pesar que esta negociación la hace el shield de Ethernet o Wifi y no se programa en Arduino, sirve para saber qué está pasando cuando Arduino actúa como cliente o servidor y poder hacer depuración cuando tenemos errores.

Todo este proceso o cualquier otro podemos verlo con una analizado de protocolos como wireshark https://www.wireshark.org/

Ver con el wireshark el proceso de 3 way handshaking:

Direccionamiento IP

TCP/IP utiliza un identificador denominado dirección internet o dirección IP, cuya longitud es de 32 bytes. La dirección IP identifica tanto a la red a la que pertenece una computadora como a ella misma dentro de dicha red.

  • Longitud de 32 bits.
  • Identifica a las redes y a los nodos conectados a ellas.
  • Especifica la conexión entre redes.
  • Se representan mediante cuatro octetos, escritos en formato decimal, separados por puntos.

Existen ciertas direcciones en cada clase de dirección IP que no están asignadas y que se denominan direcciones privadas. Las direcciones privadas pueden ser utilizadas por los hosts que usan traducción de dirección de red (NAT) para conectarse a una red pública o por los hosts que no se conectan a Internet. En una misma red no pueden existir dos direcciones iguales, pero sí se pueden repetir en dos redes privadas que no tengan conexión entre sí o que se conecten mediante el protocolo NAT. Las direcciones privadas son:

  • Clase A: 10.0.0.0 a 10.255.255.255 (8 bits red, 24 bits hosts).
  • Clase B: 172.16.0.0 a 172.31.255.255 (16 bits red, 16 bits hosts). 16 redes clase B contiguas, uso en universidades y grandes compañías.
  • Clase C: 192.168.0.0 a 192.168.255.255 (24 bits red, 8 bits hosts). 256 redes clase contiguas, uso de compañías medianas y pequeñas además de pequeños proveedores de internet (ISP).

Clases de direcciones IP:

Clases Número de Redes Número de Nodos Rango de Direcciones IP
A 127 16,777,215 1.0.0.0 a la 127.0.0.0
B 4095 65,535 128.0.0.0 a la 191.255.0.0
C 2,097,151 255 192.0.0.0 a la 223.255.255.0

Subredes en IP:

  • Las Subredes son redes físicas distintas que comparten una misma dirección IP.
  • Deben identificarse una de otra usando una máscara de subred.
  • La máscara de subred es de cuatro bytes y para obtener el número de subred se realiza un operación AND lógica entre ella y la dirección IP de algún equipo.
  • La máscara de subred deberá ser la misma para todos los equipos de la red IP.

El enrutamiento sirve para alcanzar redes distantes. Las direcciones IP se agrupan en clases. Ahora bien para cada clase se pueden contar con un número determinados de subredes. Las subredes son redes físicas independientes que comparten la misma dirección IP (es decir aquella que identifica a la red principal). La pregunta entonces es ¿cómo se logra que equipos que comparten el mismo identificador de red pero se sitúan en redes físicas diferentes podrán comunicarse usando compuertas? La solución a este problema es determinando una máscara de dirección.

Supóngase que la dirección IP de  una equipo es 148.206.257.2. La máscara de subred es 255.255.255.0. El equipo por tanto está en la subred 148.206.257.0

Una dirección IP dinámica es una IP asignada mediante un servidor DHCP (Dynamic Host Configuration Protocol) al usuario. La IP que se obtiene tiene una duración máxima determinada. El servidor DHCP provee parámetros de configuración específicos para cada cliente que desee participar en la red IP. Entre estos parámetros se encuentra la dirección IP del cliente.

Las IP dinámicas son las que actualmente ofrecen la mayoría de operadores. El servidor del servicio DHCP puede ser configurado para que renueve las direcciones asignadas cada tiempo determinado.

Más información de DHCP: http://es.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

Protocolo de Mensajes de Control de Internet ICMP (Internet Control Message Protocol)

  • Reporta sobre destinos inalcanzables.
  • Control de flujo de datagramas y congestión.
  • Controla los requerimiento de cambio de rutas entre compuertas.
  • Detecta rutas circulares o excesivamente largas.
  • Verifica la existencia de trayectorias hacia alguna red y el estatus de la misma.

La función de la dirección IPv6 es exactamente la misma que la de su predecesor IPv4, pero dentro del protocolo IPv6. Está compuesta por 128 bits y se expresa en una notación hexadecimal de 32 dígitos. IPv6 permite actualmente que cada persona en la Tierra tenga asignados varios millones de IPs, ya que puede implementarse con 3.4×10E38 hosts direccionables. La ventaja con respecto a la dirección IPv4 es obvia en cuanto a su capacidad de direccionamiento.

IPv6 admite 340.282.366.920.938.463.463.374.607.431.768.211.456 (340 sextillones de direcciones) —cerca de 6,7E17 (670 mil billones) de direcciones por cada milímetro cuadrado de la superficie de La Tierra.

Su representación suele ser hexadecimal y para la separación de cada par de octetos se emplea el símbolo “:”. Un bloque abarca desde 0000 hasta FFFF. Algunas reglas de notación acerca de la representación de direcciones IPv6 son:

Los ceros iniciales se pueden obviar.

Ejemplo: 2001:0123:0004:00ab:0cde:3403:0001:0063 -> 2001:123:4:ab:cde:3403:1:63

Los bloques contiguos de ceros se pueden comprimir empleando “::”. Esta operación sólo se puede hacer una vez.

Más información en: http://es.wikipedia.org/wiki/IPv6

Más información sobre el direccionamiento IP en: http://es.wikipedia.org/wiki/Direcci%C3%B3n_IP

Ethernet: http://es.wikipedia.org/wiki/Ethernet

Dirección MAC

En las redes, la dirección MAC (siglas en inglés de media access control; en español “control de acceso al medio”) es un identificador de 48 bits (6 bloques hexadecimales) que corresponde de forma única a una tarjeta o dispositivo de red. Se conoce también como dirección física, y es única para cada dispositivo. Está determinada y configurada por el IEEE (los últimos 24 bits) y el fabricante (los primeros 24 bits) utilizando el organizationally unique identifier. La mayoría de los protocolos que trabajan en la capa 2 del modelo OSI usan una de las tres numeraciones manejadas por el IEEE: MAC-48, EUI-48, y EUI-64, las cuales han sido diseñadas para ser identificadores globalmente únicos. No todos los protocolos de comunicación usan direcciones MAC, y no todos los protocolos requieren identificadores globalmente únicos.

Las direcciones MAC son únicas a nivel mundial, puesto que son escritas directamente, en forma binaria, en el hardware en su momento de fabricación.

En Arduino es importante poner la dirección MAC correcta para evitar problemas.

En el caso del shield ethernet, la MAC no está incluida en el integrado que implementa la pila de protocolos TCP/IP, sino que se debe configurar y eso lo hace Arduino desde el setup().

Más información en: http://es.wikipedia.org/wiki/Direcci%C3%B3n_MAC

Tutorial TCP/IP: http://www.uca.edu.sv/investigacion/tutoriales/tcp-ip.html