DESARROLLO DE UN SISTEMA

DE TRANSMISIÓN DE VÍDEO
CON MÓDULOS WIFI

SEPTIEMBRE 2016

TRABAJO FIN DE GRADO PARA Pablo Méndez Blanco

LA OBTENCIÓN DEL TÍTULO DE
GRADUADO EN INGENIERÍA EN DIRECTOR DEL TRABAJO FIN DE GRADO:

TECNOLOGÍAS
TRABAJO FIN DEINDUSTRIALES
GRADO PARA Félix Moreno González
LA OBTENCIÓN DEL TÍTULO DE
GRADUADO EN INGENIERÍA EN
TECNOLOGÍAS INDUSTRIALES
 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Dedicatoria y agradecimientos

“You don’t need anyone’s permission to create something great”

Massimo Banzi, Co-Founder of Arduino

“No necesitas el pemiso de nadie para hacer grandes cosas”

Massimo Banzi, Co-Fundador de Arduino

Me gustaría dedicar este Trabajo Fin de Grado a mis padres por su apoyo incondicional y
por haberme educado para llegar a ser la persona que soy ahora. Quiero agradecer a mi hermana
que siempre haya estado para apoyarme y hacerme reír en los momentos en los que más lo
necesitaba.

Deseo agradecer a mi tutor, Félix Moreno, haberme dado la oportunidad de realizar este
proyecto con el que he podido poner en práctica y ampliar mis conocimientos en el campo de
la electrónica. Me gustaría mencionar también a Yago Torroja y Jorge Portilla, que también
permitieron que ampliara los conocimientos que poseía sobre Arduino y los
microcontroladores.

No puedo acabar sin antes dar las gracias a mis amigos de la ETSII, con los que he vivido
tantas experiencias durante estos años y las que están por llegar. Y no me olvidaré de Pablo
Pérez, con el que formamos un grupo para participar en Cybertech; gracias a él comencé mis
andanzas en el mundo de la electrónica y la automática y descubrí mi verdadera pasión.

¡Muchas gracias a todos!

Pablo Menéndez Blanco 1

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Resumen

El objetivo principal de este Trabajo Fin de Grado ha sido:

 desarrollar un sistema capaz de adquirir imágenes de una cámara de vídeo y enviarlas por
Wifi a un dispositivo receptor para posteriormente procesarlas y mostrarlas al usuario.

En esencia, se han utilizado dos módulos: la cámara OV7670, que extrae la información de
los píxeles mediante 8 bits, y el Nodemcu esp-12e, una placa de programación con Wifi
incorporado. Estos han sido elegidos por varios motivos: bajo coste, bajo consumo, tamaño
reducido y fácil programación.

Como objetivo secundario, se han analizado las capacidades y limitaciones de este sistema
de transmisión de imágenes:

 el formato, la resolución y el tamaño de imagen que se puede almacenar y transmitir,

 el tiempo empleado desde que se empieza a recibir el primer píxel de la imagen hasta que
se termina de mostrar la imagen completa,

 otros factores como el canal empleado para dicha transmisión.

Las imágenes se envían sin comprimir a un servidor, del cual se podrían cogen mediante
cualquier dispositivo con Wifi. Específicamente, se ha conseguido recibir y mostrar las
imágenes en el ordenador con Matlab y en el móvil con una aplicación desarrollada en Android
Studio.

Para empezar este proyecto, se estudiaron en profundidad ambos módulos y se detectaron

problemas y necesidades:

1) La placa se programaría mediante el entorno de desarrollo de Arduino, para lo cual se

descargó la librería necesaria. Sin embargo, las funciones de Arduino digitalRead() y
digitalWrite() podrían ralentizar el programa al utilizar instrucciones de más. Por ello se
investigó y se consiguió poder leer y escribir en los registros de las entradas de la placa,
acelerando así el programa.

Además, el orden de las entradas físicas de la placa no coincidían con el orden de los bits de
estos registros, pero se investigó más y se hicieron pruebas para estar seguro de la
correspondencia entre los bits de los registros y las entradas, y comprobar también cuáles se
podían emplear mediante este método.

Pablo Menéndez Blanco 3

Resumen

2) Haría falta una señal de reloj que introducir a la cámara para hacerla funcionar.

Se investigaron métodos para conseguir una señal de reloj, tanto por software (variar un pin
digital o utilizar PWM) como por hardware (construir un oscilador).

La opción con la que se obtuvieron mejores resultados fue el oscilador de Pierce, que es un
circuito compuesto básicamente de: un cristal de cuarzo, un inversor, un par de condensadores
y un par de resistencias, una de ellas funciona como filtro de paso bajo y evita sobreoscilaciones.

El cristal de cuarzo elegido fue uno de 10MHz, por lo que el circuito también oscila a la
misma frecuencia, habiendo ajustado la resistencia mencionada para evitar sobreoscilaciones.

Posteriormente, todos los componentes se soldaron en una placa perforada para tener un
circuito con todo fijo y que no hubiera problemas por falta de contacto entre componentes.

El resultado es una onda casi cuadrada de 10MHz y bastante estable. El pin del oscilador por
el que sale esta onda se conecta a la señal XCLK de la cámara, para proporcionarle la señal de
reloj que necesita.

3) Haría falta programar los registros de la cámara para configurar ésta, lo cual se debía
hacer mediante comunicación SCCB (semejante a la comunicación I2C) a través de dos
entradas de la cámara llamadas SIO_C (señal de reloj de la comunicación) y SIO_D (canal de
datos de la comunicación). Se estudió el funcionamiento de este tipo de comunicación y,
afortunadamente, se encontró un código que funcionó perfectamente. Por si acaso se decidió
analizar en el osciloscopio las señales que producía este código, para entender bien su
funcionamiento y poder hacer modificaciones si hacía falta.

4) La placa probablemente no tendría suficientes pines para leer todas las salidas de la
cámara. Se planteó cuántos pines harían falta y, efectivamente, se necesitaban 4 más de los
disponibles.

Se probó un DAC (convertidor digital-analógico), para convertir varias señales digitales de

la cámara en una señal analógica que leer con el pin analógico de la placa. Pero finalmente esta
opción fue descartada debido al tiempo que requiere la función analogRead() de Arduino y a
que este pin no era posible leerlo mediante registros.

Se decidió entonces utilizar los pines disponibles de la placa para leer las entradas más
importantes de la cámara:

- VSYNC: señal de salida que indica cuándo acaba una imagen y empieza a salir
información de la siguiente.

- HREF: señal de salida que indica cuando empieza a salir información de cada línea.

- PCLK: señal de salida que indica cuándo sale información de cada píxel (esta iría
también a 10MHz si no se prescala).

- Bits D de información 7 a 4 (los más significativos, de un total de 8)

4 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

- SIO_C y SIO_D: entradas para configurar la cámara mediante la ya mencionada

comunicación SCCB.

5) También sería necesario poder enviar grandes paquetes de información por Wifi, para
después poder descargar dicha información en el móvil.

Alguno de los programas de Wifi probados en la placa consistía en hacer que funcionara
como un servidor web o enviar la información a una página de una determinada forma que
impedía hacer envíos grandes.

La mejor opción fue el envío de la información a un servidor (concretamente el dominio

creado www.esp8266.netai.net alojado en el servidor www.000webhost.com). El programa de
la placa hacía un POST (una petición de envío de información) a un archivo .php, programado
para guardar la información en un archivo .json, el cual, al almacenar la información con una
determinada estructura, permitía que cualquier herramienta que solicitara la información de
dicho archivo, pudiera descargarla y ordenarla mediante librerías existentes en internet.

Como herramientas para la descarga de dicha información se probaron Matlab y Android,

ambas verdaderamente útiles para la visualización de imágenes.

Tras realizar estos análisis y comprobaciones, se dispuso a conectar todos los componentes
y realizar un programa con el que leer la información que extrae la cámara.

El programa comenzaba realizando la comunicación SCCB con la cámara para configurar la

frecuencia de reloj deseada, la resolución, el tamaño de la imagen y el formato de color.

Los cambios de las señales VSYNC, HREF y PCLK de la cámara se detectaban mediante
interrupciones.

La información de cada píxel sale en formato YCbCr, en el cual la Y indica la luminancia

(cantidad de blanco) y Cb y Cr son las crominancias (diferencia de azul y diferencia de rojo).
El orden en el que salen los bytes es: Cb12, Y1, Cr12, Y2, Cb34, Y3, Cr34, Y4… Por lo que hay un
valor de Y para cada píxel, pero los valores de Cb y Cr son compartidos por cada dos píxeles
consecutivos.

La información obtenida de los bits de la cámara se almacena en una matriz de 100x200

bytes, ya que se desea almacenar una imagen de 100x100 píxeles y cada píxel estaba compuesto
por 2 bytes de información.

Una vez el programa ha obtenido la información deseada de la imagen, realiza un POST al

archivo savepixelsYCr.php, enviándole la información (codificada en hexadecimal) de 2 en 2
líneas de la imagen, por lo que dicho archivo .php almacena todas las líneas repartidas en 50
archivos .json. Para acelerar la posterior descarga de la información, se ordena al servidor,
mediante otro POST al archivo joinlines.php, que junte la información de esos 50 archivos .json
en un solo archivo .json, creando así el archivo imageYCr001.json. La siguiente vez creará el
archivo imageYCr002.json, y así sucesivamente.

Pablo Menéndez Blanco 5

Resumen

Para obtener dicha información con Matlab, se utiliza la función urlread() y la librería
JSON.m (descargada de internet) para analizar la estructura de los mencionados archivos .json.
Una vez descodificada la información y obtenidos los colores en el formato YCbCr, estos se
convierten a RGB y se almacenan en una matriz de 100x100x3, correspondiendo las dos
primeras dimensiones al tamaño de la imagen y la tercera dimensión al color R, G o B. Dicha
matriz de colores se muestra por pantalla mediante la función imshow().

Para obtener la información con Android, se ha diseñado una aplicación en Android Studio,
en la que, mediante tareas asíncronas para no bloquear el hilo principal del programa, se realiza
la obtención de la información del mismo modo que antes, excepto que se usan funciones
propias de java y la librería JSON que ya incorpora Android. Además, los colores se guardan
en una variable de tipo Bitmap, a la cual se puede asignar un color a cada píxel. El bitmap se
muestra por pantalla mediante un imageView, componente visual que nos permite mostrar
imágenes en la aplicación.

Durante las pruebas realizadas, hubo que reducir la frecuencia de funcionamiento de la

cámara, ya que la señal de PCLK iba muy rápido, la placa no era capaz de atender a tantas
peticiones de interrupción y se reiniciaba. Se pasó de poder recibir 12.5 fps (imágenes por
segundo) a recibir 0.4 fps, tardando 2.5s por imagen.

Se han analizado también otros tiempos: la placa tarda en torno a 7s en enviar la información
de la imagen de 100x100 píxeles, Matlab tarda 3s en descargar y mostrar la imagen, mientras
que Android tarda el doble que Matlab. Así, se obtienen tiempos de entre 13 y 16s entre que se
empieza a coger la información del primer píxel de la imagen hasta que se consigue visualizar
dicha imagen completa. Estos tiempos impiden la visualización de imágenes en tiempo real.

Por ello, para líneas futuras se deben investigar:

- placas de desarrollo más veloces (como programar directamente un microcontrolador

ATmega de AVR o una FPGA — dispositivo con puertas lógicas programables)

- y métodos más rápidos de envío, almacenamiento y descarga de la información (una

posible solución más veloz es la conexión a internet cableada o Ethernet, siempre que la
aplicación a la que esté destinado lo permita)

Finalmente se ha conseguido visualizar imágenes, pero los colores obtenidos no se

corresponden con la realidad. Esto puede deberse a diversos motivos:

- Pueden haberse configurado erróneamente los registros. La cámara tiene 200 registros y
se ha podido encontrar poca información en cuanto a cómo configurarlos para obtener la
resolución deseada, por lo que se ha podido pasar por alto algún registro que hubiera que
modificar.

- También cabe la posibilidad de que la cámara se haya estropeado en algún momento

durante todas las pruebas realizadas y, cuando finalmente se ha empezado a capturar la
información de los píxeles, estos no proporcionan los colores reales.

6 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

De todas formas, la mayoría de problemas encontrados se han debido a la velocidad de

funcionamiento de la placa, el Nodemcu (el tiempo necesario para recoger la información de
los píxeles es mayor que el tiempo que tarda la cámara desde que extrae un byte de información
hasta que extrae el siguiente). Este problema se agrava al programar en el entorno de desarrollo
de Arduino, al no poder saber qué instrucciones ejecuta el programa cuando salta a la rutina de
servicio de la interrupción. Se hubiera deseado poder realizar partes del programa o incluso el
programa entero en un entorno en el que se pudieran ver las instrucciones resultantes tras la
compilación o incluso se pudieran programar las interrupciones en ensamblador, para tener un
mayor control del proceso y saber qué cambiar para hacer el programa más rápido y eficaz.

Palabras clave: Arduino, Matlab, Android, Wifi, Nodemcu, ESP8266, cámara OV7670,
servidor, PHP, JSON, captura de imágenes

Códigos UNESCO: 120323, 220301, 220307, 220917, 330413, 330703, 332508

Pablo Menéndez Blanco 7

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Índice general

Dedicatoria y agradecimientos ................................................................................................ 1

Resumen .................................................................................................................................... 3
Capítulo 1 - Introducción ...................................................................................................... 11
1.1. Antecedentes ............................................................................................................ 11
1.2. Objetivos .................................................................................................................. 11
1.3. Metodología ............................................................................................................. 12
Capítulo 2 - Hardware ........................................................................................................... 13
2.1. Hardware empleado ................................................................................................. 13
2.1.1. Nodemcu esp-12e ........................................................................................... 13
2.1.1.1. Configuración de pines .................................................................... 14
2.1.1.2. Lectura inmediata de los pines ......................................................... 15
2.1.2. Cámara OV7670 ............................................................................................. 19
2.1.2.1. Configuración de pines del módulo: ................................................ 19
2.1.2.2. Funcionamiento ................................................................................ 21
2.1.2.3. Configuración ................................................................................... 22
2.1.2.4. Problema encontrado en cuanto al número de pines disponibles ..... 24
2.1.3. Otros ............................................................................................................... 27
2.2.3.1. Fuente de alimentación FAC-662B.................................................. 27
2.2.3.2. Convertidor a 3.3V para protoboard ................................................ 27
2.2. Hardware desarrollado ............................................................................................. 28
2.2.1. Señal de reloj .................................................................................................. 28
2.2.1.1. Solución adoptada: circuito oscilador mediante cristal de cuarzo ... 28
2.2.1.2. Soluciones descartadas ..................................................................... 39
2.3. Conexiones establecidas .......................................................................................... 46
Capítulo 3 – Software ............................................................................................................. 49
3.1. Herramientas software empleadas ........................................................................... 49
3.1.1. Arduino........................................................................................................... 49
3.1.2. LiveWire......................................................................................................... 49
3.1.3. Matlab............................................................................................................. 49

Pablo Menéndez Blanco 9

Resumen

3.1.4. Android........................................................................................................... 50
3.2. Software desarrollado .............................................................................................. 51
3.2.1. Comunicación SCCB para configurar la cámara ........................................... 51
3.2.1.1. ¿Qué es la comunicación SCCB? ..................................................... 51
3.2.1.2. Funcionamiento del SCCB............................................................... 51
3.2.1.3. Escribiendo en los registros de la cámara ........................................ 53
3.2.2. Proceso de obtención y visualización de las imágenes .................................. 55
3.2.2.1. Captura y almacenamiento de la imagen en Arduino ...................... 55
3.2.2.2. Envío de la imagen en Arduino ........................................................ 55
3.2.2.3. Procesamiento de la url en el servidor ............................................. 56
3.2.2.4. Unión de toda la información de la imagen en un solo archivo ....... 57
3.2.2.5. Descarga de la imagen con Matlab .................................................. 59
3.2.2.6. Descarga de la imagen con Android ................................................ 60
3.2.2.7. Extras añadidos ................................................................................ 64
Capítulo 4 - Pruebas y resultados ......................................................................................... 65
4.1. Conexión de la cámara con el oscilador .................................................................. 65
4.2. Conexión de la cámara con el Nodemcu ................................................................. 68
4.3. Imágenes obtenidas .................................................................................................. 70
Capítulo 5 - Conclusiones ...................................................................................................... 73
Capítulo 6 - Líneas futuras .................................................................................................... 75
Capítulo 7 - Planificación temporal y presupuesto ............................................................. 77
7.1. Estructura de Descomposición del Proyecto (EDP) ................................................ 77
7.2. Diagrama de Gantt ................................................................................................... 77
7.3. Presupuesto .............................................................................................................. 81
Índice de Figuras .................................................................................................................... 83
Índice de Tablas...................................................................................................................... 85
Índice de Códigos ................................................................................................................... 87
Bibliografía ............................................................................................................................. 89

10 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Capítulo 1 - Introducción

1.1. Antecedentes

Hoy en día las cámaras tienen innumerables aplicaciones. Además de poder plasmar
momentos inolvidables, se usan también en vigilancia, como detectores de movimiento y para
alertar de intrusos; en investigación científica, para ver lo que el ojo humano no puede apreciar;
en reconocimiento facial, para identificar ladrones o dar acceso a instalaciones protegidas;
control a distancia, para pilotar drones, etc.

Este último uso es uno de los más interesantes pues, con la industria de drones en aumento,
supone poder controlar helicópteros teledirigidos y pequeñas naves no tripuladas, en espacios
reducidos y de difícil acceso, sin necesidad de tenerlos a la vista. Para ello es imprescindible un
dispositivo de captura de imágenes de buena calidad, conectado a un procesador que lea la
información y sea capaz de enviarla a otro dispositivo que se encuentre lejos, para después
procesar dicha información y actuar en consecuencia.

1.2. Objetivos

Este Trabajo de Fin de Grado (TFG) tiene como objetivo principal:

 desarrollar un sistema capaz de adquirir imágenes de una cámara de vídeo y enviarlas por
Wifi a un dispositivo receptor para posteriormente procesarlas y mostrarlas al usuario.

Se utilizarán dos módulos: la cámara OV7670, que extrae la información de los píxeles
mediante 8 bits, y el Nodemcu esp-12e, una placa de programación con Wifi incorporado.

Las ventajas por las que se ha decidido lograr el objetivo principal anteriormente
mencionado mediante estos módulos son:

 Bajo coste

 Bajo consumo

 Tamaño reducido

 Fácil programación

Pablo Menéndez Blanco 11

Capítulo 1 - Introducción

Las imágenes se enviarán sin comprimir y serán recibidas por algún dispositivo con Wifi
como por ejemplo el móvil a través de una aplicación Android, para procesarlas y mostrarlas al
usuario.

Como objetivo secundario, es de suma importancia analizar las capacidades y limitaciones

de este sistema de transmisión de imágenes, como por ejemplo:

 el formato, la resolución y el tamaño de imagen que se pueda almacenar y transmitir,

 el tiempo empleado desde que se empieza a recibir el primer píxel de la imagen hasta que
se termina de mostrar la imagen completa,

 otros factores como el canal empleado para dicha transmisión.

Durante el desarrollo del proyecto y una vez alcanzado el objetivo, todos estos factores serán
analizados para sugerir posibles líneas de mejora u otras vías por las que se pueda alcanzar el
objetivo con mejores resultados.

1.3. Metodología

El procedimiento para alcanzar el objetivo de este TFG ha sido:

- Leer los correspondientes datasheets de los módulos (hojas de especificaciones del

fabricante).

- Investigar en internet otros proyectos similares.

- Identificar los componentes necesarios.

- Realizar los montajes y conexiones necesarios.

- Comprobar el correcto funcionamiento de dichos componentes mediante el osciloscopio.

- Realizar y probar diferentes programas de adquisición y envío de la información,

descartando los peores y mejorando los más útiles.

- Programar una aplicación para procesar la información y poder visualizarla.

12 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Capítulo 2 - Hardware

2.1. Hardware empleado

El proyecto en sí estuvo formado principalmente por dos módulos de bajo coste:

1) El nodemcu esp-12e

2) La cámara OV7670

De los cuales se pasará a hablar en adelante.

También se utilizaron otros dispositivos para alimentar estos módulos y para convertir la
tensión de alimentación a 3.3V, los cuales serán explicados en un apartado posterior.

2.1.1. Nodemcu esp-12e

Se trata de una placa de desarrollo de bajo coste creada por Espressif Systems y que
incorpora el chip ESP8266 (microprocesador Xtensa Tensilica LX106 con conexión Wi-Fi).

El ESP8266 es ampliamente usado para aplicaciones de internet de las cosas (IoT, Internet
of Things) que se refiere a la interconexión de objetos cotidianos mediante Internet.

Contiene protocolo TCP/IP para proporcionar conexión Wi-Fi. Puede albergar su propia
aplicación o servir como conexión entre cualquier microcontrolador e Internet.

Tiene gran capacidad de procesamiento y almacenamiento (160kB de RAM, 4MB de

memoria flash externa [1]) y puertos de entrada/salida que le permiten interactuar con otros
dispositivos. Todo ello está altamente integrado ocupando el área mínima de PCB y permitiendo
la mínima circuitería externa [2].

Está diseñado de forma que tiene un consumo mínimo y opciones de suspensión (sleep mode
y deep sleep mode).

El nodemcu esp-12e incorpora el chip CH340 para permitir la conexión serie entre la placa
y el ordenador y así poderse programar, ya sea directamente mediante comandos AT, mediante
el lenguaje de programación Lua de la plataforma de desarrollo NodeMCU o incluso mediante
el entorno de desarrollo (IDE) de Arduino.

Pablo Menéndez Blanco 13

Capítulo 2 - Hardware

2.1.1.1. Configuración de pines

Figura 1: Configuración de pines del nodemcu esp-12e

Los pines de los que dispone el Nodemcu se pueden apreciar en la Figura 1. Estos son:

- Pin Vin para alimentar el módulo por encima de 5V.

- Salidas con 3.3V (tensión a la que funciona internamente el módulo).

- Pines GND de masa

- 11 pines digitales (todos permiten PWM e I2C excepto el D0; además el D4 y D7-10
pueden funcionar como TX o RX permitiendo comunicación UART).

- 1 pin analógico que funciona solo como entrada.

- Pines MOSI, MISO, CS y SCLK para comunicación SPI.

- Pines para conectar un módulo de lectura de una tarjeta SD.

- Pin Enable de habilitación del módulo.

- Pin Reset para reiniciar el módulo.

14 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

2.1.1.2. Lectura inmediata de los pines

Un aspecto clave ha sido la posibilidad de leer los pines digitales del Nodemcu de manera
inmediata mediante los registros, ya que funciones de lectura y escritura de pines digitales como
digitalRead() y digitalWrite() proporcionados por las librerías de Arduino utilizan más
instrucciones de las realmente necesarias y pueden ralentizar el proceso.

Los registros para acceder al estado de los pines se encuentran en posiciones de memoria a
partir de la dirección 0x60000300.

Para poderse utilizar, dichas posiciones de memoria se declaran como está especificado en
el Código 1 (los códigos completos se encuentran en la web del Departamento de Electrónica).

#define PIN_OUT *(volatile uint32_t *)0x60000300

#define PIN_OUT_SET *(volatile uint32_t *)0x60000304
#define PIN_OUT_CLEAR *(volatile uint32_t *)0x60000308

#define PIN_DIR *(volatile uint32_t *)0x6000030C

#define PIN_DIR_OUTPUT *(volatile uint32_t *)0x60000310
#define PIN_DIR_INPUT *(volatile uint32_t *)0x60000314

#define PIN_IN *(volatile uint32_t*) 0x60000318

Código 1: declaración de posiciones de memoria para la lectura de los registros asociados a los pines
del nodemcu

Su funcionamiento es el siguiente [3]:

- PIN_OUT: posee el valor de todas las salidas a la vez y, por ello, escribir en él afecta a
todas las salidas a la vez. Escribir un ‘1’ en un bit pondrá el correspondiente pin a HIGH
y escribir un ‘0’ lo pondrá a LOW.

- PIN_OUT_SET: solo pone pines a HIGH. Escribir un ‘1’ en un bit pondrá el

correspondiente pin a HIGH, manteniendo el resto de pines como estén.

- PIN_OUT_CLEAR: solo pone pines a LOW. Escribir un ‘1’ en un bit pondrá el

correspondiente pin a LOW, manteniendo el resto de pines como estén.

- PIN_DIR: funciona como PIN_OUT, es decir, afecta a todos los pines a la vez. Indica si
un pin funciona como salida o como entrada. Escribir un ‘1’ en un bit hará que el
correspondiente pin funcione como salida y escribir un ‘0’ hará que funcione como
entrada.

- PIN_DIR_OUTPUT: funciona como PIN_OUT_SET, es decir, solo afecta a

determinados pines. Escribir un ‘1’ en un bit hará que el correspondiente pin funcione
como salida, manteniendo la función del resto de pines.

- PIN_DIR_INPUT: igual que PIN_DIR_OUTPUT pero hace que los pines funcionen
como entrada.

- PIN_IN: posee el valor de todas las entradas a la vez. Es solo de lectura.

Pablo Menéndez Blanco 15

Capítulo 2 - Hardware

Siempre hay que tener en cuenta el diagrama de la Figura 2 para cada pin.

PIN_DIR

PIN_OUT Patilla del pin

PIN_IN

Figura 2: Diagrama de configuración de pines en un microcontrolador

PIN_DIR establece la función de cada pin (entrada/salida), lo que significa que:

- PIN_IN poseerá siempre el estado de lo que haya conectado al pin.

- El estado del pin se podrá modificar mediante PIN_OUT siempre que dicho pin esté
configurado como salida.

- PIN_OUT no tiene por qué coincidir con PIN_IN en los pines configurados como entrada.

Como se puede ver, las posiciones de memoria son de 4 bytes, esto es, 32 bits. El orden de
estos coincide con la numeración de los GPIO (General Purpose IO), pero no coincide con la
numeración de los pines digitales D0 a D10 escritos en la placa. La correcta correspondencia
se puede ver en la Figura 3.

16 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Figura 3: Correspondencia de pines del Nodemcu

Por ello, al leer los registros mencionados, la correspondencia de los bits con los pines
digitales es de la siguiente forma:

- Bits 31 a 16: solo el bit 16 se corresponde con el pin digital D0. No proporcionan
información ya que no se pueden leer ni modificar.

- Bits 15 a 0: su correspondencia es la indicada en la Tabla 1, de acuerdo con la Figura 3.

Solo estos bits se pueden leer o modificar a través de los registros.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
D8 D5 D7 D6 D1 D2 D9 D4 D10 D3
(RX) (TX)
Tabla 1: Correspondencia de los bits 15 a 0 de los registros con las salidas digitales del Nodemcu

Pablo Menéndez Blanco 17

Capítulo 2 - Hardware

Se deduce por tanto lo siguiente:

- Todos los pines digitales del Nodemcu se pueden leer y modificar mediante registros,
excepto el pin digital D0.

- No se ha encontrado ningún registro con el que poder leer el pin analógico A0.

- Por ello, se tendrán que seguir utilizando las funciones digitalRead() y digitalWrite() de
Arduino para el pin digital D0, y las funciones analogRead() y analogWrite() de Arduino
para el pin analógico A0.

18 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

2.1.2. Cámara OV7670

Se trata de un módulo como el de la Figura 4, con un

sensor de imagen CMOS, fabricado por OmniVision,
formado por un encapsulado con la funcionalidad completa
de una cámara y con procesador de imagen.

Es capaz de proveer imágenes en distintos formatos

(YUV, RGB, GRB y Raw RGB) y en distintas resoluciones
(VGA, QVGA, CIF, QCIF).
Figura 4: Cámara OV7670
Puede obtener un máximo de 30 imágenes por segundo en
VGA con control completo del usuario respecto a calidad de imagen, formato y salida de datos.

Todas las funciones del procesador de imagen (control de exposición, gamma, balance de
blancos, saturación de color, control de tono y más) son programables a través de una
comunicación SCCB (compatible con comunicación I2C).

El chip incorporado también es capaz de mejorar la calidad de la imagen reduciendo o

eliminando ruido, defectos, manchas, brillos, etc. para producir una imagen limpia y estable.

2.1.2.1. Configuración de pines del módulo:

Como se muestra en la Figura 5, la cámara posee 18

pines (colocados en dos filas de 9). Estos son:

- 3v3: pin de alimentación a 3.3V

- GND: pin de masa

Figura 5: Configuración de pines de la
- SIO_C: señal de reloj de la comunicación SCCB cámara OV7670

- SIO_D: señal de datos de la comunicación SCCB

- VSYNC: señal de sincronización vertical (indica el final de salida de información de la

imagen anterior y el comienzo de la siguiente)

- HREF: señal de sincronización horizontal (indica el final de salida de información de la

línea anterior y el comienzo de la siguiente)

- XCLK: señal de reloj de entrada (indica una base de tiempos al módulo)

- PCLK: señal de reloj de salida (indica el comienzo de salida de información del siguiente
píxel)

- D[7-0]: 8 bits de datos (máxima cantidad de información que se puede extraer en cada
momento)

Pablo Menéndez Blanco 19

Capítulo 2 - Hardware

- Reset: señal de reset (restablece todos los registros a sus valores por defecto y reinicia el
módulo)

- PWDN: señal de power down (apaga el módulo)

20 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

2.1.2.2. Funcionamiento

El funcionamiento de las salidas digitales más importantes de la cámara se puede ver en la

Figura 6.

Figura 6: Temporización de las salidas más importantes de la cámara

VSYNC indica el comienzo de una imagen.

HREF se pone a HIGH cuando empieza a salir información de una fila y a LOW cuando ésta
acaba. Este proceso se repite hasta haber sacado la información de todas las filas.

Mientras HREF está a LOW, la información que sale por los pines D[7-0] no es válida.

Figura 7: Temporización ampliado de las salidas más importantes de la cámara

Como se puede apreciar en la Figura 7, los cambios se producen por defecto por flanco de
bajada de la señal de reloj de salida (PCLK).

Como los pines D[7-0] son 8, por cada ciclo de dicho reloj se puede obtener 1 Byte de
información.

Cuando HREF se pone a HIGH, empieza a salir información de los píxeles de una fila (2
Bytes por pixel) hasta llegar al último pixel de la fila.

Pablo Menéndez Blanco 21

Capítulo 2 - Hardware

2.1.2.3. Configuración

Para configurar los distintos modos de operación de la cámara se utilizan los registros.

Los registros son dispositivos digitales donde se almacena información de manera temporal.
Están constituidos por flip-flops o biestables, cada uno de los cuales almacena un bit con el
valor ‘0’ o ‘1’. Lo más común es que los registros estén constituidos por 8 biestables, es decir,
almacenan 8 bits, este es el caso de los registros de la cámara OV7670.

Los registros de la cámara en cuestión nos permiten configurar opciones como:

- la frecuencia de reloj de salida,

- el formato de colores de los píxeles,

- la resolución de la imagen,

- y el modo en que actúan las distintas señales.

Un ejemplo de ello se puede ver en la Figura 8.

Figura 8: Ejemplo de configuración de un registro de la cámara OV7670 (obtenido del datasheet)

Al igual que el resto de registros, el registro 0x12 posee 8 bits (numerados del 7 al 0).

Este registro se puede utilizar para:

- Reiniciar todos los registros escribiendo un ‘1’ en el bit 7.

- Seleccionar la resolución CIF, QVGA o QCIF escribiendo un ‘1’ en el bit 5, el 4 o el 3,

respectivamente.

- Seleccionar el formato de color (YUV o RGB) según lo que se escriba en los bits 2 y 0.

22 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

- Habilitar la barra de color escribiendo un ’1’ en el bit 1.

Como se puede ver en la Figura 8, el valor por defecto del registro 0x12 (es decir, cuando se
reinicia el módulo) es 0x00. Esto significa que por defecto no está configurada ninguna de las
resoluciones mencionadas y el color se extrae en el formato YUV.

Cabe mencionar que todos los registros tienen un valor por defecto, de forma que la cámara
ya viene configurada para funcionar de un determinado modo nada más encenderla.

La configuración del resto de registros se puede ver en el datasheet del fabricante.

Los registros de la cámara OV7670 se configuran mediante comunicación SCCB a través de

sus dos pines SIO_C y SIO_D. Dicha comunicación será explicada posteriormente dentro del
Capítulo 3 – Software en el apartado 3.2.1. Comunicación SCCB para configurar la cámara

Pablo Menéndez Blanco 23

Capítulo 2 - Hardware

2.1.2.4. Problema encontrado en cuanto al número de pines disponibles

Los pines de la cámara que hay que leer son: VSYNC, HREF, PCLK y D[7-0]. Y hay que escribir
en los pines SIO_C y SIO_D para configurar los registros. Así que en total son 11 para leer y 2
para escribir.

El Nodemcu solo tiene 11 entradas digitales y 1 analógica, en total 12.

Se deduce por tanto que la placa de programación no tiene suficientes entradas para manejar
todos los pines de la cámara.

Aunque se consideró utilizar algún dispositivo para convertir varias señales digitales en una
sola analógica y poder leerla con el pin analógico del Nodemcu (comentado al final de este
apartado), esta opción fue descartada debido a la gran cantidad de tiempo que tarda en ejecutarse
la función analogRead() de Arduino.

Por todo ello se decidió:

- utilizar los pines necesarios del Nodemcu para escribir en SIO_C y SIO_D y leer VSYNC,
HREF y PCLK

- utilizar los pines digitales D9 y D10, que poseen las funciones RX y TX de comunicación
con el ordenador por USB, para depurar el programa

- y conectar los pines sobrantes a los pines más importantes D[7-…] de la cámara

Solución no adoptada: DAC

Mediante un DAC (conversor digital a analógico) podemos convertir varias señales digitales
de la cámara en una sola señal analógica que poder leer con el Nodemcu.

Figura 9: Representación de un DAC (conversor digital-analógico) [4]

El problema que podría presentar la conversión podría ser un retraso temporal entre las
señales digitales a convertir y la señal analógica a obtener. Este retraso temporal sería debido a
capacitancias de los componentes del circuito, sobre todo de los cables.

Existen diferentes arquitecturas para construir un DAC. Se probó la red R-2R [5]. El circuito
básico es el de la Figura 10.

24 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Figura 10: Esquema del DAC R-2R [5]

Las señales digitales se conectan a las entradas a0 (Bit menos significativo) a an-1 (bit más
significativo).

En función del código digital, la señal analógica Vout tendrá un valor comprendido entre 0 y
Vref, ya que estos son los dos únicos valores que pueden presentar las entradas digitales (0
cuando estén a LOW y Vref cuando estén a HIGH).

Para un determinado código digital C y una red R-2R con N bits de valor 0V o Vref, el valor
de la señal analógica será:
𝑉𝑟𝑒𝑓
𝑉𝑜𝑢𝑡 = C · 2𝑁

La ventaja de esta arquitectura es su sencillez, necesitando solo dos tipos de resistencias (o

incluso un solo tipo, si R se forma mediante una pareja de resistencias 2R en paralelo, o si 2R
se forma con una pareja de resistencias R en serie).

Pruebas

Para hacer pruebas, hacemos un montaje para 2 bits cogiendo solo resistencias de 2R=5.6kΩ.

Manteniendo un bit a 0V e introduciendo una señal digital en el otro bit, observamos en el

osciloscopio los cambios de Vout al variar dicha señal digital:

Figura 11: Señal analógica del DAC (vista en el osciloscopio)

Como habíamos previsto, sí se producen retrasos. Vout necesita 2us para cambiar
completamente de estado.

Pablo Menéndez Blanco 25

Capítulo 2 - Hardware

Estos retrasos se deben a las capacitancias del circuito. En un circuito RC la constante de

tiempo viene determinada por τ=R·C. Así que se podrán disminuir estos retrasos si se eligen
resistencias de menor valor, aunque siendo conservadores, ya que las corrientes aumentarán.

Como ya se ha mencionado antes, esta opción fue descartada debido a la gran cantidad de
tiempo que tarda en ejecutarse la función analogRead() de Arduino.

26 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

2.1.3. Otros

Durante la realización de este TFG se han utilizado: una fuente de alimentación del
laboratorio y un convertidor a 3.3V encajable en protoboard.

2.2.3.1. Fuente de alimentación FAC-662B

Se conecta a un enchufe, el cual proporciona una

tensión trifásica de 230V, se ajusta para obtener una
tensión continua y constante de 6.3V y se conecta al
convertidor.

Es un aparato grande (210 x 185 x 280 mm) y

bastante pesado (6.6kg) [6], por lo que solo se utilizó
para las pruebas a realizar. Posteriormente se
sustituiría por una pila o una batería.
Figura 12: Fuente de alimentación FAC-662B

2.2.3.2. Convertidor a 3.3V para protoboard

Se trata del módulo de la Figura 13, que como

se puede ver ya viene preparado para encajar en
una protoboard.

Se debe alimentar por el jack con una tensión

de entre 6V y 12V, aunque también se puede
alimentar por USB.

Posee dos reguladores de voltaje AMS1117:

uno para convertir la tensión de entrada a 3.3V y
otro para convertirla a 5V. De esta forma se puede
elegir qué tensión se proporciona en las líneas roja Figura 13: Convertidor a 3.3V encajado en protoboard
y azul del borde de la protoboard.

Como ya se ha comentado, se alimentó a 6.3V y se aprovechó la conversión a 3.3V para

alimentar la cámara y el circuito oscilador.

Pablo Menéndez Blanco 27

Capítulo 2 - Hardware

2.2. Hardware desarrollado

2.2.1. Señal de reloj

La cámara empleada necesita una señal de reloj de entre 10 y 48MHz para poder funcionar,
por lo que se consideraron distintas soluciones para generar dicha señal.

La solución finalmente adoptada fue un circuito oscilador mediante un cristal de cuarzo.

2.2.1.1. Solución adoptada: circuito oscilador mediante cristal de cuarzo

Fundamentación teórica

Como se muestra en la Figura 14, un circuito oscilador está compuesto básicamente por un
amplificador, de ganancia A y fase α, y una red de realimentación, de ganancia F y fase β.

V1 Amplificador V2
A, α

Realimentación
F, β

Figura 14: Diagrama de un circuito oscilador

Para que el circuito oscile deben cumplirse las dos siguientes condiciones [7]:

1) F x A ≥ 1 (la ganacia global de lazo cerrado debe ser mayor o igual que 1)

2) α + β = 2π (el cambio de fase debe ser de 360°)

Dentro de los circuitos osciladores probados, el oscilador Pierce (Figura 15) es con el que se
han conseguido los resultados deseados.

28 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

RF

Inversor RS

Cristal
C1 C2

Figura 15: Esquema eléctrico del circuito oscilador Pierce

El oscilador Pierce utiliza un cristal de cuarzo, cuyo circuito equivalente es el de la Figura

16:
Cristal

C L R

C0
Figura 16: Circuito equivalente de un cristal de cuarzo

Los valores de C y L vienen determinados por las características mecánicas del cristal; R es
la resistencia de resonancia del circuito oscilador, y C0 representa la capacitancia de los cables
y electrodos. C0 es mucho más grande que C y es afectada por el resto de capacitancias del
circuito final.

Al conectar el cristal en paralelo, la frecuencia de resonancia será:

1 𝐶
𝑓𝑝𝑎𝑟 = 2𝜋√𝐿𝐶 √1 + 𝐶
𝑝 +𝐶0

Conectando una capacitancia (Cp>C0) en paralelo con el cristal, la influencia de C0 se reduce

y la frecuencia queda como:
1
𝑓𝑝𝑎𝑟 = 2𝜋√𝐿𝐶

𝐶 ·𝐶
En el oscilador Pierce, Cp está formado por C1 y C2. Así: 𝐶𝑝 = 𝐶 1+𝐶2 .
1 2

C1 y C2 forman un divisor de voltaje capacitivo y determinan la ganancia de realimentación:

Pablo Menéndez Blanco 29

Capítulo 2 - Hardware

𝐶1
F=
𝐶2

La estabilidad del oscilador de cristal depende de Cp, el cual debe ser igual a CL, carga
capacitiva recomendada por el fabricante del cristal.

El oscilador Pierce también utiliza un inversor CMOS que trabaja en su zona lineal como
amplificador. El inversor proporciona un cambio de fase de 180°. Para que se cumpla la segunda
condición de oscilación, el oscilador de cristal también debe proporcionar un giro de 180°. Si
C1=C2, la corriente por ambos condensadores es idéntica y desfasada 180°, por lo que el cristal
también provee 180° de cambio de fase.

La resistencia (RF) en paralelo obliga al inversor a trabajar en su zona lineal. Normalmente

sirve un valor entre 1MΩ y 10MΩ.

Para circuitos osciladores, se pueden usar inversores con Schmitt trigger (que mantienen el
valor de salida a ‘0’ o ‘1’ completamente) o inversores sin Schmitt trigger. Sin embargo, la
ganancia de los inversores con Schmitt trigger es mucho mayor y por ello son más sensibles a
cambios en el circuito oscilador y menos estables que los inversores sin Schmitt trigger.

El circuito oscilador incorpora además una resistencia RS conectada a la salida del inversor
y al punto de unión entre el cristal y C2. Junto con C2, RS forma un filtro de paso bajo para
evitar oscilaciones de muy alta frecuencia. Se pueden conseguir resultados aceptables eligiendo
1 1
un valor cercano a la reactancia capacitiva de C2: RS = XC = 𝑤𝐶 = 2𝜋𝑓𝐶 .
2

El efecto de Rs puede verse en la Figura 17 y la Figura 18:

Figura 17: efecto de Rs en el oscilador Pierce (sin carga)

30 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Figura 18: efecto de Rs en el oscilador Pierce (con carga)

Valores mayores de Rs ralentizan la tasa de cambio y disminuyen la ganancia.

Realización práctica

El circuito finalmente construido es el de la Figura 19.

RF=2.2MΩ

SN74HC04 RS=98Ω

Cristal
C1=33pF 10MHz C2=33pF

Figura 19: Esquema eléctrico del circuito oscilador finalmente construido

Los componentes utilizados son:

1) Un inversor SN74HC04 (sin Schmitt trigger), de tipo “through hole” (con patillas) para
montar en protoboard.

Sus características más interesantes para este proyecto

son:

- es un circuito integrado compuesto por 6 inversores

- puede alimentarse entre 2 y 6V (acorde a los 3.3V de

la cámara) Figura 20: Inversor SN74HC04

Pablo Menéndez Blanco 31

Capítulo 2 - Hardware

- tiempo máximo de cambio de estado: 139ns/V a 4.5V (típico: 1.67ns/V), 625ns/V a 2V

El encapsulado tiene la configuración de pines de la Figura 21:

Figura 21: Configuración de pines del inversor SN74HC04

Se alimenta a 3.3V y se utiliza el inversor situado entre 1A y 1Y.

También se consideraron otros circuitos integrados como:

- el 74HCT04, más rápido pero solo alimentable entre 4.5 y 5.5V

- el 74AC04, más rápido pero no funcionó

- el 74ACT04, también más rápido pero solo alimentable entre 4.5 y 5.5V

2) Una resistencia RF de 2.2MΩ en paralelo con el inversor para, como ya se ha dicho,

obligar al inversor a trabajar en su zona lineal.

3) Un cristal de cuarzo de encapsulado mediano HC-49/U

Sus características, según el datasheet de Multicomp, son:

- frecuencia de 10MHz

- capacitancia de carga (CL): entre 8 y 32pF

- resistencia equivalente en serie (Rs): 40-50Ω

Figura 22: Cristal de cuarzo de
encapsulado mediano HC-49/U
- shunt capacitance (C0): 5pF maximum

4) Dos condensadores de 33pF conectados a cada terminal del cristal y a tierra, obteniendo
𝐶 ·𝐶
una capacitancia de carga: CL = 𝐶 1+𝐶2 = 16.5pF (correctamente comprendido entre 8 y 32pF)
1 2

32 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

5) Una resistencia RS conectada a la salida del inversor y al punto de unión entre el cristal y
C2. RS junto con C2 forma un filtro de paso bajo para evitar oscilaciones de muy alta frecuencia.
Se pueden conseguir resultados aceptables eligiendo un valor cercano a la reactancia capacitiva
1 1 1
de C2: XC = 𝑤𝐶 = 2𝜋𝑓𝐶 = 2𝜋·10𝑀·33𝑝 = 482 Ω
2

Montaje y pruebas

Se realizó el montaje y se probaron distintos valores de RS, observando en el osciloscopio la

señal de reloj resultante.

Se probó primero sin RS y posteriormente valores mayores para obtener una señal lo más
cuadrada posible. En la figuras 23-28, se muestran ejemplos para distintos valores de RS:

- RS=0Ω (Figura 23 y Figura 24)

- RS=280Ω (Figura 25 y Figura 26)

- RS=470Ω (Figura 27 y Figura 28).

Se eligió el valor de 470Ω para RS por obtenerse una señal lo más parecida posible a una onda
cuadrada y ser un valor cercano a la reactancia capacitiva de C2 (482Ω, calculado al final del apartado
anterior).

Finalmente se probó con un oscilador de 20MHz (Figura 29), pero como se puede apreciar en la
Figura 30 la señal obtenida no era buena.

Pablo Menéndez Blanco 33

Capítulo 2 - Hardware

Figura 23: Montaje del circuito oscilador (f=10MHz y RS=0Ω)

Figura 24: Señal de reloj obtenida (f=10MHz y RS=0Ω)

34 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Figura 25: Montaje del circuito oscilador (f=10MHz y RS=280Ω)

Figura 26: Señal de reloj obtenida (f=10MHz y RS=280Ω)

Pablo Menéndez Blanco 35

Capítulo 2 - Hardware

Figura 27: Montaje del circuito oscilador (f=10MHz y RS=470Ω)

Figura 28: Señal de reloj obtenida (f=10MHz y RS=470Ω)

36 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Figura 29: Montaje del circuito oscilador (f=20MHz y RS=0Ω)

Figura 30: Señal de reloj obtenida (f=20MHz y RS=0Ω)

Pablo Menéndez Blanco 37

Capítulo 2 - Hardware

Soldadura

Finalmente, se soldaron todos los componentes del oscilador probado en una placa perforada
para tener un circuito con todo fijo y que no hubiera problemas por falta de contacto entre
componentes.

El resultado se puede apreciar en la Figura 31. Los componentes finalmente utilizados fueron
los que dieron mejores resultados:

 Un inversor SN74HC04

 Una resistencia RF de 2.2MΩ

 Un cristal de cuarzo de 10MHz

 Dos condensadores de 33pF

 Una resistencia RS de 470Ω

Además, se soldó también:

 Una tira de pines hembra a la izquierda de la placa para la tensión de 3.3V y otra a la
derecha para la línea de GND (0V)

 Un pin a la salida del inversor para insertar un cable con el que conectar el oscilador a la
cámara

 Un interruptor con el que cortar la alimentación del inversor en cualquier momento

Figura 31: Circuito oscilador soldado (cable morado = señal de reloj)

38 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

2.2.1.2. Soluciones descartadas

i) Señal de reloj mediante generador de ondas

El generador de ondas del laboratorio es el

APG-2005 de la marca Gwinstek.

Características:

- Frecuencias entre 0.1Hz y 5MHz

- Ciclos de trabajo entre 1% y 99% Figura 32: Generador de ondas del laboratorio

- Señales senoidales, cuadradas y triangulares

Además de ser un aparato grande, solo puede generar ondas cuadradas de hasta 5MHz, por
lo que no sirve para este proyecto.

Pablo Menéndez Blanco 39

Capítulo 2 - Hardware

ii) Señal de reloj variando un pin digital

Mediante un sencillo programa como el del Código 2, en el que se varía continuamente una
salida digital del Nodemcu, y utilizando los registros de estado de los pines, se consigue una
frecuencia de 175Khz (tanto si funciona el nodemcu a 80MHz como si funciona a 160MHz).

char pin = D1;

uint32_t data = 0x00000020;

void setup() {
pinMode(D1, OUTPUT);
digitalWrite(D1, LOW);
}

void loop() {
PIN_OUT_SET = data;
PIN_OUT_CLEAR = data;
}
Código 2: Variar un pin digital continuamente

Analizando la señal obtenida en el osciloscopio:

Se observa que ésta está más tiempo a LOW que a HIGH, por lo que se deduce que el
programa se ralentiza en el momento de tener que repetir el loop. En efecto, se requieren varios
ciclos de reloj entre que termina el loop y éste vuelve a empezar, ya que el programa necesita
sacar la dirección de retorno de la pila, saltar a dicha dirección, devolver dicha dirección a la
pila y saltar a la localización en memoria de la función loop.

Por ello se decide introducir las dos instrucciones que cambian el estado del pin
(“PIN_OUT_SET = data” y “PIN_OUT_CLEAR = data”) dentro de un bucle infinito
“while(1)”. Así, se consiguen tiempos en HIGH y en LOW muy parecidos y una frecuencia de
6.6MHz.

Sin embargo, se observa también en el osciloscopio (Figura 33) que este programa deja de
funcionar durante 230ms cada 3.25s.

Figura 33: Imagen de osciloscopio: interrupciones en el programa

40 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Se deduce que esto es debido a las interrupciones internas que el programa debe atender.

Para solucionarlo, se intentan usar las funciones “cli()” y “noInterrupts()”, pero estas no
eliminan todas las interrupciones (Figura 34), las cuales se siguen produciendo durante 220ms
cada 8.5s.

Figura 34: Imagen de osciloscopio: interrupciones tras usar la función noInterrupts() en el programa

Por lo tanto, la frecuencia resultante es menor de 10Mhz e inestable.

Pablo Menéndez Blanco 41

Capítulo 2 - Hardware

iii) Señal de reloj mediante PWM

La frecuencia del PWM en el Nodemcu va desde 100Hz hasta 1kHz. No es suficiente y,

debido a la poca información con respecto a este módulo, no se pueden conseguir frecuencias
superiores.

La frecuencia del PWM en un Arduino es de 490 o 980Hz (dependiendo del pin digital
utilizado), muy lejos de los megahercios deseados.

Profundizando un poco más, averiguamos que para generar PWM, los pines digitales utilizan
los timers a los que están asociados, además de un prescalado para obtener la frecuencia deseada
[8].

Arduino Uno, Mini y Nano disponen de tres temporizadoras.

- Timer0, con una frecuencia de 62500Hz, y prescalados de 1, 8, 64, 256 y 1024.

- Timer1, con una frecuencia de 31250Hz, y prescalados de 1, 8, 64, 256, y 1024.

- Timer2, con una frecuencia de 31250Hz, y prescalados de 1, 8, 32, 64, 128, 256, y 1024.

Arduino Mega añade tres temporizadores más

- Timer3, 4 y 5, con una frecuencia de 31250Hz, y preescalados de 1, 8, 64, 256, and 1024.

Por defecto, los timers utilizan el prescalado de 64, obteniendo así las frecuencias
mencionadas al principio (62500/64=980 y 31250/64=490, apreciables en la Figura 35 y la
Figura 36).

Figura 35: PWM en Arduino de 976MHz Figura 36: PWM en Arduino de 490MHz

Si no utilizáramos prescalado, la máxima frecuencia que podríamos obtener sería 62500Hz,

aún muy inferior al megahercio.

Profundizando un poco más:

La arquitectura de un timer es, por norma general, parecida a la de la Figura 37.

42 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Figura 37: Arquitectura del Timer0 de 8 bits del ARmega328P

Tomando como ejemplo el timer0 del ATmega328P (microcontrolador del Arduino UNO),
un timer posee un registro de cuenta (TCNT) al que suma 1 en cada ciclo de reloj, contando así
desde 0 hasta 255 (si fuera de 16 bits contaría hasta 65535). Cuando el registro llega al máximo
valor (llamado TOP), vuelve a 0 y sigue contando.

Mediante el generador de ondas se puede obtener una señal PWM en OCnA u OCnB, de
forma que se pone a HIGH cuando el contador es 0 y a LOW cuando el contador alcanza un
determinado valor indicado en OCRnA u OCRnB, variando así el ciclo de trabajo (Figura 38).

Figura 38: Ciclo de trabajo del PWM obtenido en OCnx según el valor de OCRnx

Al tener un reloj de 16MHz, la frecuencia de este PWM (sin prescalado) será:

16M/256=62500Hz

Pablo Menéndez Blanco 43

Capítulo 2 - Hardware

Si pudiéramos reducir el TOP, aumentaríamos la frecuencia del PWM generado.

Ésta no es la única opción de PWM. Todas las opciones se muestran en la Figura 39.

Figura 39: Opciones de PWM del Timer0 del ATmega328P

Estábamos usando el modo 3, cuyo TOP es fijo (0xFF=255). Si usamos el modo 7 podremos
variar el TOP del timer. Así, indicaremos el TOP en el registro OCRnA y el ciclo de trabajo en
el registro OCRnB, obteniendo el PWM en OCnB.

La máxima frecuencia se obtiene con OCR0A=1 (TOP) y OCR0B=0, de forma que el timer
solo cuenta de 0 a 1 (Figura 40).

Figura 40: PWM de máxima frecuencia del Timer0 del ATmega328P

Se obtiene así una señal de 8MHz (casi los 10MHz deseados), aunque nada cuadrada (ya
que en cuanto la señal sube ya tiene que volver a bajar).

44 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

iv) Señal de reloj mediante la salida del reloj del nodemcu

A los pines del nodemcu se les pueden asignar distintas funciones según la Figura 41.

Figura 41: Funciones de los pines del nodemcu

Observamos que para el pin 0 (que corresponde al pin digital D3) se puede obtener la señal
CLK_OUT (señal de reloj del nodemcu) mediante la función 4. La manera de obtenerlo es
añadiendo el Código 3.

pinMode(0, FUNCTION4)
Código 3: Asignar función a un pin del nodemcu

Se obtiene así la señal periódica de la Figura 42, poco cuadrada y de 26MHz.

Figura 42: Señal CLK_OUT del Nodemcu

Algo parecido se obtiene para la señal CLK_XTAL mediante la función 4 del pin 3 (D9).

Esta opción no se tuvo en cuenta por haberse conseguido al final cuando ya se había
implementado la señal de reloj del apartado 2.2.1.1. Solución adoptada: circuito oscilador
mediante cristal de cuarzo. De todas formas, mediante la solución adoptada se obtiene una señal
de mejor calidad y fiabilidad.

Pablo Menéndez Blanco 45

Capítulo 2 - Hardware

2.3. Conexiones establecidas

El diagrama de conexiones es el de la Figura 43. Se han realizado las siguientes conexiones:

- XCLK de la cámara con la salida del circuito oscilador, para proporcionar a la cámara
la señal de reloj que necesita para funcionar.

- D0 y D8 del Nodemcu con SIO_C y SIO_D de la cámara, respectivamente, para la

comunicación SCCB.

- D1-4 del Nodemcu con D[7-4] de la cámara (en este orden), para leer los bits más
significativos de cada píxel, ya que, como se ha comentado, el Nodemcu no tiene suficientes
pines.

- D5 del Nodemcu con PCLK de la cámara, para saber cuándo leer cada píxel

- D6 del Nodemcu con VSYNC de la cámara, para saber cuándo empieza cada imagen

- D7 del Nodemcu con HREF de la cámara, para saber cuándo empieza y acaba cada fila
de la imagen

- Se han unido todos los GND para que todos los módulos tengan la misma referencia de
tensión

- El Nodmcu se alimenta por USB mientras se realizan las pruebas

- La cámara y el circuito oscilador se alimentan a 3.3V

46 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

SIO_C
D7
D6
D5
D4

PCLK
VSYNC
HREF
SIO_D

GND

XCLK

GND GND

Figura 43: Conexiones

Pablo Menéndez Blanco 47

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Capítulo 3 – Software

3.1. Herramientas software empleadas

3.1.1. Arduino

Arduino es una platforma de código abierto basada en software y hardware de fácil uso.
Permite la programación de microcontroladores: leer y escribir en sus entradas para controlar
leds, motores, sensores y otros dispositivos; comunicarse por bluetooth, wifi, etc, consiguiendo
realizar grandes proyectos de forma sencilla y barata. Para dicha programación se utiliza el
Entorno de Desarrollo de Arduino (IDE, Integrated Development Environment), que utiliza un
lenguaje parecido a C [9].

Mediante este software se ha programado el Nodemcu de este proyecto, habiendo tenido que
descargar la librería thinger.io para poder manejar dispositivos con capacidad de comunicación
a distancia como el ESP8266 (chip incorporado en el Nodemcu) [10].

3.1.2. LiveWire

LiveWire es una herramienta software para el diseño y simulación de circuitos electrónicos.

Posee símbolos de todo tipo de interruptores, componentes pasivos, fuentes de alimentación,
conectores, semiconductores y circuitos integrados. Además, permite el diseño de circuitos
impresos [11].

Se ha usado este programa para diseñar los circuitos del oscilador de cristal incluidos en este
TFG.

3.1.3. Matlab

Matlab es una herramienta de software matemático de altas prestaciones para cálculo

numérico y visualización. Utiliza un lenguaje de programación propio (lenguaje M) que permite
operaciones de vectores y matrices, funciones y programación orientada a objetos. Posee una
interfaz capaz de mostrar los datos representados en 2D y 3D [12].

En este proyecto se ha utilizado Matlab (además de Android) para visualizar las imágenes
obtenidas de la cámara.

Pablo Menéndez Blanco 49

Capítulo 3 – Software

3.1.4. Android

Android es un sistema operativo basado en Linux diseñado principalmente para móviles.

Hoy en día, se encuentra en teléfonos móviles, tablets y relojes inteligentes. La programación
se realiza mediante Android Studio (desde 2014, antes mediante Eclipse) [13]. Android Studio
es un entorno de desarrollo integrado que permite a millones de programadores la creación de
aplicaciones, de forma gratuita, para su uso y difusión en teléfono móviles [14].

El entorno de programación de Android Studio se ha empleado en este trabajo para la

creación de una aplicación Android con la que poder visualizar las imágenes de la cámara en el
móvil.

50 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

3.2. Software desarrollado

3.2.1. Comunicación SCCB para configurar la cámara

3.2.1.1. ¿Qué es la comunicación SCCB?

La comunicación SCCB (Serial Camera Control Bus) es un bus de comunicación entre varios
dispositivos, parecido al I2C. La transferencia de datos se realiza siempre entre un maestro (el
dispositivo que empieza la comunicación) y un esclavo (el que responde).

El bus suele estar formado por tres líneas: una que actúa como reloj (SIO_C), otra que aporta
los datos (SIO_D) y una tercera de habilitación (SCCB_E).

SCCB_E
SIO_C
Dispositivo maestro SIO_D Dispositivo esclavo

Dispositivo esclavo

Dispositivo esclavo

Figura 44: Esquema de la comunicación SCCB (3 cables)

El bus trabaja con lógica positiva, es decir, una tensión alta es un ‘1’ y una tensión baja es
un ‘0’.

En nuestro caso, la comunicación SCCB posee solo dos cables (no hay señal de habilitación):

SIO_C
Dispositivo maestro SIO_D Dispositivo esclavo

Figura 45: Esquema de la comunicación SCCB (2 cables)

Este tipo de comunicación se utiliza en la cámara OV7670 para modificar los registros y así
poder configurar opciones como la frecuencia de la señal de reloj de salida, el tamaño de la
imagen, etc.

3.2.1.2. Funcionamiento del SCCB

Para poder comenzar la comunicación deben estar ambas señales a nivel alto. Entonces se
pone a ‘0’ SIO_D y después SIO_C tras un tiempo característico T (un cuarto del periodo del

Pablo Menéndez Blanco 51

Capítulo 3 – Software

ciclo de reloj que se va a establecer). Esto indica el comienzo de la comunicación maestro-

esclavo.

Figura 46: Comienzo de la comunicación SCCB

La señal SIO_C cambia repetidamente de ‘0’ a ‘1’ y viceversa, simulando una señal de reloj.

A mitad de camino entre un flanco de bajada y un flanco de subida de SIO_C, se escribe en

SIO_D el bit a transmitir.

Un ciclo de escritura se compone de 3 fases, cada una de ellas está formada por 9 bits: 8 bits
del dato a transmitir y un noveno bit de “acknowledge” (reconocimiento de que la información
ha sido recibida).

Figura 47: Fases de la comunicación SCCB

Fase 1) En la primera fase se transmite la dirección del esclavo con el que el maestro desea
comunicar.

Fase 2) En la segunda fase se transmite la dirección del registro que se quiere modificar.

Fase 3) En la tercera y última fase, se transmite el dato que se quiere escribir en dicho
registro.

Para terminar la comunicación, se pone SIO_D a ‘0’, después SIO_C a ‘1’ y finalmente
SIO_D a ‘1’, cada una de estas acciones separadas por un tiempo T, quedando ambas señales a
nivel alto y permitiendo que comience la comunicación otra vez en cualquier momento.

52 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Figura 48: Fin de la comunicación SCCB

3.2.1.3. Escribiendo en los registros de la cámara

Se ha descargado de internet un código que funciona según lo explicado y con el cual se ha

conseguido modificar los registros. Se utilizan los pines D0 y D8 del Nodemcu como SIO_C y
SIO_D, respectivamente.

Se ha utilizado la dirección 0x42 para escribir, ya que esta es la dirección de la cámara para
comunicación SCCB (según el datasheet de la cámara OV7670; 0x43 sería para leer),

Según la resolución, tamaño de imagen y frecuencia de reloj que deseemos utilizar hay que
escribir en unos registros u otros. Para saber en cuáles escribir se mira el datasheet, en el cual
aparece una tabla con los 202 registros que posee la cámara y una explicación de para qué sirve
cada bit de cada registro (para algunos bits no aparece información y están reservados para la
configuración de fábrica).

Para conseguir imágenes en resolución QQVGA (120x160 píxeles) hay que modificar los
siguientes registros:

Registro Dirección Dato Explicación

CLKRC 0x11 0x80+PRESCALE-1 Para usar un reloj
externo y prescalarlo
entre 1 y 32 veces

COM7 0x12 0x00 Para no seleccionar otra

resolución y sí el formato
YUV

COM3 0x0C 0x04 Para habilitar el

escalado de la imagen

COM14 0x3E 0x10|0x08|0x02 Para habilitar la

disminución de la
resolución, permitir

Pablo Menéndez Blanco 53

Capítulo 3 – Software

ajustar dicha resolución y

dividir la señal de reloj
entre 4 (obteniendo 160
columnas en vez de 640)

SCALING_XSC 0x70 0x3A Para ajustar el factor de

escalado horizontal

SCALING_YSC 0x71 0x35 Para ajustar el factor de

escalado vertical

SCALING_DCWCTR 0x72 0x22 Para muestrear la

imagen entre 4
verticalmente

SCALING_PCLK_DIV 0x73 0xF2 Para ajustar la señal de

reloj a la resolución
elegida

SCALING_PCLK_DELAY 0xA2 0xA2 Para ajustar la señal de

reloj si el nuevo tamaño
de imagen no es divisor
del tamaño de imagen
original

Tabla 2: Modificación de registros de la cámara OV7670 para la resolución QQVGA

En cualquier momento podemos reiniciar todos los registros a su valor por defecto
escribiendo 0x80 en el registro COM7 (0x12).

54 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

3.2.2. Proceso de obtención y visualización de las imágenes

3.2.2.1. Captura y almacenamiento de la imagen en Arduino

En el programa realizado en el entorno de Arduino, se utilizan interrupciones para:

- detectar flancos de bajada de VSYNC de la cámara mediante el pin D6 del Nodemcu,

para saber cuándo empieza una imagen

- detectar flancos de HREF de la cámara mediante el pin D7 del Nodemcu, para saber
cuándo empieza y acaba cada línea de la imagen y poder saber el valor de HREF en cada
momento, ya que solo se debe coger información cuando HREF está a HIGH

- detectar flancos de subida de PCLK de la cámara mediante el pin D5 del Nodemcu, para
saber cuándo coger la información de los bits D[7-0], siempre que HREF esté a HIGH

Por defecto, la información de la cámara sale en formato YCbCr, también conocido como
YUV, en el cual la Y indica la luminancia (cantidad de blanco) y Cb y Cr son las crominancias
(diferencia de azul y diferencia de rojo). Es una forma de codificar RGB.

En el formato YCbCr los bytes de información se reciben en el siguiente orden:

Cb12, Y1, Cr12, Y2, Cb34, Y3, Cr34, Y4 …

De esta forma, hay un valor de Y para cada píxel, pero los valores de Cb y Cr son
compartidos por cada dos píxeles consecutivos.

Se guarda dicha información para una imagen de 100x100 píxeles, correspondiente a la

cuadrícula superior izquierda de la imagen completa. Como hay 4 bytes por cada dos píxeles,
se almacena una matriz de 100x200 bytes.

3.2.2.2. Envío de la imagen en Arduino

La información se sube al servidor www.000webhost.com, específicamente al dominio

creado www.esp8266.netai.net. En este servidor están guardados varios archivos en formato
.php programados para crear archivos en los que guardar la información recibida en formato
.json.

 PHP es un lenguaje de programación ejecutado por servidores para generar páginas web.

 Json es una forma de gestionar gran cantidad de información de forma sencilla y eficaz.
Sirve para el intercambio de datos, almacenándolos con una sintaxis estructurada que
puede ser leída por cualquier lenguaje de programación.

Pablo Menéndez Blanco 55

Capítulo 3 – Software

El arduino se conecta al wifi al principio del programa y se mantiene conectado. Cuando el

nodemcu tiene una imagen que enviar, tiene que conectarse al servidor y realizar un POST con
la información, lo cual equivale a enviar una url escrita del siguiente modo:

www.esp8266.netai.net/savepixelsYCr.php?line=0&number=2&data1=F0A2...&data2=C2
7B...

La url está compuesta de la siguiente forma:

- ‘www.esp8266.netai.net/’ es el dominio del servidor

- ‘savepixelsYCr.php’ es el archivo .php que se encuentra en el servidor y que se encarga

de almacenar la información recibida en un archivo .json.

- Después se escribe el símbolo ‘?’, tras el cual vienen las variables que podrá utilizar el
archivo .php:

o ‘line’ es una variable tras la cual se indica el número de la primera fila que se envía.

o ‘number’ es una variable tras la cual se indica cuántas filas se envían en la url.

o ‘data1’ y ‘data2’ son las variables tras las que se indica la información de la primera
y segunda fila enviada. Dicha información se envía en hexadecimal (un byte de 0 a
255 se convierte en dos caracteres entre ‘00’ y ‘FF’).

- Tras cada variable viene su valor precedido del símbolo ‘=’.

- Las parejas de variables y sus valores se separan mediante el símbolo ‘&’.

Como una url solo puede tener un máximo de 2000 caracteres, solo se pueden enviar unas
pocas filas de la imagen en cada url. Por ello se ha decidido enviar la información de 2 en 2
filas (el arduino tarda unos 8-10 segundos en enviar toda esta información y se ha comprobado
que enviar más filas en una misma url apenas influye en este tiempo, pero es más cómodo enviar
estas filas de 2 en 2 por ser divisor de 100).

3.2.2.3. Procesamiento de la url en el servidor

El archivo .php mencionado en la url anterior crea un archivo .json llamado dataYCr001.json
en el que guarda los valores de las variables recibidas de la url como se puede ver en el Código
4.

{"info":{"f":"0","n":"2","lines":[" F0A2…"," C27B…"]}}

Código 4: Archivo dataYCr001.json
Para entenderlo, estructuramos correctamente esta línea (Código 5).

56 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

{
"info":{
"f":"0",
"n":"2",
"lines":[
"F0A2…",
"C27B…"
]
}
}
Código 5: Archivo dataYCr001.json estructurado

La estructura de este archivo .json funciona de la siguiente forma:

- La información se guarda en objetos englobados por llaves: el objeto ‘info’ contiene los
objetos ‘f’, ‘n’ y ‘lines’:

o ‘f’ guarda el valor de la variable ‘line’ de la url.

o ‘n’ guarda el valor de la variable ‘number’ de la url.

o ‘lines’ guarda los valores de las variables ‘data1’ y ‘data2’ de la url en un vector
englobado por corchetes y separados por comas.

- Los nombres de los objetos se escriben entre comillas por ser cadenas de caracteres.

- Los valores de los objetos se pueden escribir entre comillas si son cadenas de caracteres,
o sin comillas si se quiere que sean interpretados como números enteros.

- Los valores de los objetos se separan de estos con dos puntos.

- Los objetos se separan entre sí mediante comas.

3.2.2.4. Unión de toda la información de la imagen en un solo archivo

Como hay que enviar la información correspondiente a 100 filas y estas se envían de 2 en 2,
se crean 50 archivos en el servidor:

dataYCr001.json con la información de las líneas 1 y 2

dataYCr002.json con la información de las líneas 3 y 4

dataYCr003.json con la información de las líneas 5 y 6

…………………………………………………………

dataYCr050.json con la información de las líneas 99 y 100

Pablo Menéndez Blanco 57

Capítulo 3 – Software

Para que la herramienta posteriormente utilizada (Matlab, Android o cualquier otra) pueda
descargar la información de manera más rápida, se decidió juntar la información de todas las
filas en un solo archivo.

Una vez enviada la información de todas las filas, el arduino hace un POST incluyendo el
nombre del archivo joinlinesYCr.php, el cual lee los archivos desde el dataYCr001.json hasta
el dataYCr050.json y almacena toda la información en otro archivo .json llamado
imageYCr001.json. El siguiente archivo se llamara automáticamente imageYCr002.json, ya
que el anterior ya existe, el siguiente imageYCr003, y así sucesivamente.

En este nuevo archivo .json, la información se guarda como se puede ver en el Código 6.

{"info":{"height":"100","width":"100","type":"hex","lines":["F0A2…","C27B…","…",…
,"…"]}}
Código 6: Archivo imageYCr001.json

El anterior código lo estructuramos correctamente para verlo mejor, quedando lo que se

puede apreciar en el Código 7.

{
"info":{
"height":"100",
"width":"100",
"type":"hex",
"lines":[
"F0A2…",
"C27B …",
"…",
… (información del resto de líneas)
"…"
]
}
}
Código 7: Archivo imageYCr001.json estructurado

La estructura de dicho archivo .json incluye lo siguiente:

o ‘height’ y ‘width’ guardan el tamaño de la imagen.

o ‘type’ indica en qué formato está codificada la información

o ‘lines’ incluye un vector con la información de las 100 filas

58 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

3.2.2.5. Descarga de la imagen con Matlab

Cuando escribimos en el navegador http://www.esp8266.netai.net/imageYCr001.json, éste

nos muestra la información de dicho archivo. Por ello, en Matlab podemos leer dicha
información mediante el Código 8:

url = 'http://www.esp8266.netai.net/imageYCr001.json'
data = urlread(url)
Código 8: Lectura de una url con Matlab

Posteriormente utilizamos la librería del archivo JSON.m (descargada de MathWorks) para

obtener los objetos del archivo .json (Código 9).

jsonobj = JSON.parse(data);
Código 9: Utilización de la librería JSON.m

De esta forma podemos acceder a la información de cada objeto del archivo .json mediante
punteros. Podemos ver un ejemplo de ello en el Código 10 (obtención de la altura de la imagen).

jsonobj.info.height
Código 10: Acceso a los objetos del archivo .json mediante punteros

Como los valores “height” y “width” correspondientes al tamaño de la imagen están

guardados como cadenas de caracteres, debemos usar el Código 11 para obtener dichos números
enteros.

height=str2num(jsonobj.info.height);
width=str2num(jsonobj.info.width);
Código 11: Transformar una String en un número entero

La información de cada fila se obtiene mediante el Código 12.

for j=1:height
s=char(jsonobj.info.lines(1,j));
Código 12: Obtención de una cadena de caracteres del archivo .json

La información de los píxeles de cada fila se guarda en la variable “s” en formato YCbCr y
en hexadecimal. Por ser valores de 0 a 255, en “s” están guardadas parejas de caracteres de “00”
a “FF” de los valores de Y, Cb y Cr en el orden ya mencionado: Cb12, Y1, Cr12, Y2, Cb34, Y3,
Cr34, Y4… Por lo tanto, debemos usar el Código 13 para transformar dichas parejas de caracteres
a decimal.

Pablo Menéndez Blanco 59

Capítulo 3 – Software

for k=1:2:width
ind=4*(k-1)+1;
cb=hex2dec(s(ind:ind+1));
y1=hex2dec(s(ind+2:ind+3));
cr=hex2dec(s(ind+4:ind+5));
y2=hex2dec(s(ind+6:ind+7));
Código 13: Obtención del valor YCbCr de cada píxel

Se obtienen así las luminancias y crominancias de cada píxel. Para cada par de píxeles: los
valores del primer píxel son y1-cb-cr, y los del segundo píxel son y2-cb-cr

Las fórmulas para transformar YCbCr en RGB son:

R = Y + 1.14*Cr

G = Y - 0.396*Cb - 0.581*Cr

B = Y + 2.029*Cb

Los valores obtenidos se guardan en una matriz de 100x100x3, correspondiendo las dos
primeras dimensiones al tamaño de la imagen y la tercera dimensión al color R, G o B.

Una vez se ha conseguido la información de todos los píxeles de la imagen, esta se muestra
mediante la función del Código 14, siendo “píxeles” la matriz de 3 dimensiones mencionada.

imshow(pixels)
Código 14: Función para crear una imagen a partir de una matriz de 3 dimensiones

El tiempo transcurrido entre mostrar una imagen y otra son unos 4-5s

3.2.2.6. Descarga de la imagen con Android

Se ha diseñado una aplicación en Android Studio para descargar las imágenes del servidor
en el móvil y poder visualizarlas.

La aplicación consulta la url http://www.esp8266.netai.net/imageYCr001.json mediante el

método GET (Código 15), es decir, envía la url y lee la respuesta de la página web. Se obtiene
así una “String” con todo el código JSON del archivo imageYCr001.json.

60 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

String response="";
DefaultHttpClient client = new DefaultHttpClient();
HttpGet httpGet = new HttpGet(url);
try {
HttpResponse execute = client.execute(httpGet);
InputStream content = execute.getEntity().getContent();

BufferedReader buffer = new BufferedReader(new InputStreamReader(content));

String s = "";
while ((s = buffer.readLine()) != null) {
response+=s;
}

} catch (Exception e) {
e.printStackTrace();
}
return response;

Código 15: Lectura de una url con Android

Posteriormente, la “String” mencionada se decodifica mediante el Código 16. Obteniendo un

objeto general que incluye los objetos que nos interesan: “height”, “width” y “lines”, este último
incluye un vector con las cadenas de caracteres de la información de cada línea de la imagen.

jsonObject = new JSONObject(jsonString);

Código 16: Utilización de la librería JSON de Android

Para obtener los objetos que nos interesan, se utiliza el Código 17. Al igual que en el anterior
apartado, hay que convertir los valores de “height” y “width” a enteros. Esto se hace mediante
el método “Integer.parseInt()”.

imageComponents.height=Integer.valueOf(jsonObject.getJSONObject("info").getString("
height"));
imageComponents.width=Integer.valueOf(jsonObject.getJSONObject("info").getString("
width"));
JSONArray jsonArray = jsonObject.getJSONObject("info").getJSONArray("lines");
for(int i=0; i<imageComponents.height; i++){
imageComponents.lines[i]=jsonArray.getString(i);
}
Código 17: Acceso a los objetos del archivo .json mediante la librería JSON de Android

Del mismo modo que en el anterior apartado, la información de cada línea se guarda en una
variabe “s”, de la cual se obtienen los valores Y, Cb y Cr de cada par de píxeles (Código 18).
Para transformar cada par de caracteres de hexadecimal a decimal, se utiliza otra vez el método
“Integer.parseInt()”, pero ahora indicándole 16 como segundo parámetro para que sepa que la
cadena introducida como primer parámetro se encuentra en hexadecimal.

Pablo Menéndez Blanco 61

Capítulo 3 – Software

String s=imageComponents.lines[j];
for(int k=0; k<WIDTH; k+=2) {
int ind=4*k;
cb = Integer.parseInt(s.substring(ind,ind+2), 16);
y1 = Integer.parseInt(s.substring(ind+2,ind+4), 16);
cr = Integer.parseInt(s.substring(ind+4,ind+6), 16);
y2 = Integer.parseInt(s.substring(ind+6,ind+8), 16);
Código 18: Obtención del valor YCbCr de cada píxel

Se utilizan las mismas fórmulas que antes para transformar YCbCr en RGB:

R = Y + 1.14*Cr

G = Y - 0.396*Cb - 0.581*Cr

B = Y + 2.029*Cb

Se obtiene cada color mediante el método “Color.argb()”, en el que se introducen valores de

transparencia y los valores de RGB. Se guarda el valor de cada píxel en una variable Bitmap
que guardara la información RGB para los 100x100 píxeles que constituyen la imagen (Código
19).

int color1 = Color.argb(127, r1, g1, b1);

int color2 = Color.argb(127, r2, g2, b2);
bitmap.setPixel(k, j, color1);
bitmap.setPixel(k+1, j, color2);
Código 19: Guardado de los valores de RGB en una variable Bitmap

Posteriormente, la imagen se muestra asignando el Bitmap a un imageView, componente

visual que nos permite mostrar imágenes en la aplicación (Código 20).

imageView.setImageBitmap(bitmap);
Código 20: Obtención del valor YCbCr de cada píxel

Todos estos pasos se realizan en diferentes tareas asíncronas (llamada asyncTask) para no
bloquear el hilo principal del programa.

El resultado se puede ver en la Figura 49.

62 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Figura 49: Captura de pantalla de la aplicación Android

Pablo Menéndez Blanco 63

Capítulo 3 – Software

3.2.2.7. Extras añadidos

Decir al Nodemcu si tiene que capturar y enviar una imagen

Se ha añadido un archivo sendYesOrNo.json en el que se escribe “YES” o “NO” para indicar

al Nodemcu cuándo se desea que capture una imagen y la envíe. Esto se escribe mediante el
archivo sendYesOrNo_write.php, haciendo un POST con la siguiente url:

http://www.esp8266.netai.net/sendYesOrNo_write.php?answer=YES

Si no se desea que el Nodemcu capture una imagen y la envíe se debe escribir “NO” en vez
de “YES” al final de la url (cualquier otra cosa también impide que el Nodemcu capture
imágenes y las envíe).

El Nodemcu leerá dicho archivo .json mediante un GET con la url

http://www.esp8266.netai.net/sendYesOrNo.json. Si en dicho archivo pone “YES”, el
Nodemcu cogerá la información de una imagen y la enviará. Si por el contrario pone “NO” (o
cualquier otra cosa), el Nodemcu seguirá leyendo el archivo .json hasta leer “YES”.

En la aplicación Android se puede dar la orden de escribir “Yes” o “No” en dicho archivo
.json tan solo haciendo click en el cuadrito pequeño para poner un click (Figura 50).

Figura 50: Captura de pantalla de la aplicación Android

64 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Capítulo 4 - Pruebas y resultados

4.1. Conexión de la cámara con el oscilador

Conectando el pin de entrada XCLK de la cámara con la señal saliente del circuito oscilador
de 10MHz y midiendo con el osciloscopio las señales PCLK, HREF y VSYNC de la cámara,
se comprobó el correcto funcionamiento de la cámara.

Siendo la frecuencia del XCLK de 10MHz, se observó:

 PCLK con respecto a XCLK (Figura 51): ambas presentan la misma frecuencia (10MHz)
ya que el prescalado es 1. PCLK aparece un poco retrasada con respecto a XCLK.

 VSYNC con respecto a HREF (Figura 52): VSYNC es un pulso pequeño (ya que solo
indica cuándo empieza una imagen), comparado con HREF, que está compuesto por muchos
pulsos representantes de cada fila de la imagen (Figura 53). Como indicaba el datasheet, HREF
no da pulsos cerca del momento en que VSYNC da cada pulso. Contando el número de
cuadrículas y sabiendo el tiempo que representa cada una, sabemos que entre dos pulsos de
VSYNC hay 80ms, por lo que se obtiene una imagen cada 80 ms, lo que se corresponde con
1/0.08 = 12.5 fps (imágenes por segundo).

Con la misma frecuencia en XLCK (10MHz), se tuvo que prescalar la señal de salida PCLK,
ya que el nodemcu no era lo suficientemente rápido y se reiniciaba (dicho problema se explicará
en el siguiente apartado). Se eligió el mayor prescalado posible (32), ya que otros daban también
problemas, obteniendo una frecuencia de 10MHz/32 = 312.5kHz. Se observó:

 PCLK con respecto a XCLK (Figura 54Figura 51): XCLK es 32 veces más rápido. La
frecuencia resultante exacta es 312.488kHz. La señal se ve más cuadrada ya que ahora los
tiempos de subida y bajada de las señales son ínfimos en comparación con el tiempo en HIGH
o LOW

 VSYNC con respecto a HREF (Figura 55Figura 52): VSYNC se sigue viendo como un
pulso pequeño comparado con HREF, que está compuesto por muchos pulsos representantes
de cada fila de la imagen (Figura 56Figura 53). Ahora el tiempo entre dos pulsos de VSYNC es
2.5s, por lo que se obtiene una imagen cada 2.5s, lo que se corresponde con 1/2.5 = 0.4 fps.
Obtenemos el mismo resultado si dividimos el resultado de antes (12.5fps) entre 32.

Pablo Menéndez Blanco 65

Capítulo 4 - Pruebas y resultados

Figura 51: Señales de la cámara mediadas en el osciloscopio (XCLK en amarillo, PCLK en azul)

Figura 52: Señales de la cámara mediadas en el osciloscopio (HREF en amarillo, VSYNC en azul)

Figura 53: Figura 52 ampliada (HREF en amarillo, VSYNC en azul)

66 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Figura 54: Señales de la cámara mediadas en el osciloscopio, prescalado de 32 (XCLK en amarillo, PCLK en azul)

Figura 55: Señales de la cámara mediadas en el osciloscopio, prescalado de 32 (HREF en amarillo, VSYNC en azul)

Figura 56: Figura 55 ampliada (HREF en amarillo, VSYNC en azul)

Pablo Menéndez Blanco 67

Capítulo 4 - Pruebas y resultados

4.2. Conexión de la cámara con el Nodemcu

Se realizan las siguientes conexiones:

- D0 y D8 del Nodemcu con SIO_C y SIO_D de la cámara, respectivamente, para la

comunicación SCCB.

- D1-4 del Nodemcu con D[7-4] de la cámara (en este orden), para leer los bits más
significativos de cada píxel, ya que, como se ha comentado, el Nodemcu no tiene suficientes
pines.

- D5 del Nodemcu con PCLK de la cámara, para saber cuándo leer cada píxel

- D6 del Nodemcu con VSYNC de la cámara, para saber cuándo empieza cada imagen

- D7 del Nodemcu con HREF de la cámara, para saber cuándo empieza y acaba cada fila
de la imagen

Como se ha comentado en el capítulo de Software, se utilizan interrupciones para detectar

los cambios de PCLK, VSYNC y HREF.

Además, como se ha comentado en el apartado anterior, cuando la frecuencia de PCLK es

10MHz (igual que la frecuencia del oscilador, por ser el prescalado igual a 1), el Nodemcu no
es lo suficientemente rápido para atender todas las interrupciones que provoca PCLK, da un
error y se reinicia.

El error que aparece entonces en la pantalla es el de la Figura 57. El Nodemcu se resetea,

supuestamente porque con cada interrupción se activa un contador del watchdog (“mecanismo
de seguridad que provoca un reset del sistema en caso de que éste se haya bloqueado” [15]). El
contador mencionado se va decrementando con cada ciclo de reloj. Como se produce otra
interrupción antes de que acabe la rutina de servicio de la anterior interrupción, dicha rutina
tarda mucho en acabar, el contador llega a cero y entonces el watchdog resetea el Nodemcu.

Figura 57: Error: el timer del watchdog se desborda y provoca un reset

Debido a este error se decidió prescalar la señal de reloj de PCLK, para que el Nodemcu
tuviera tiempo de atender todas las peticiones de interrupción de PCLK.

Se probó con pequeños prescalados pero seguía produciéndose el mismo error, solo que más
tarde, por lo que se decidió utilizar el mayor prescalado posible (32) para no tener problemas.

Las señales obtenidas con este prescalado ya se han comentado en el apartado anterior
(Figura 54, Figura 55 y Figura 56).

68 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

En las funciones que atienden las interrupciones de HREF y PCLK, existen contadores para
contar el número de filas y bytes, respectivamente, que extrae la cámara. Dividiendo el número
de bytes entre el número de filas y entre 2 (2B/píxel), se puede obtener el número de columnas.
Estas cantidades se muestran por pantalla (Figura 58) y así se puede comprobar que la cámara
está bien configurada y que se cogen los 100x100 píxeles de la parte superior izquierda de la
imagen.

Figura 58: Comprobación de filas y columnas (resolución QQVGA)

Pablo Menéndez Blanco 69

Capítulo 4 - Pruebas y resultados

4.3. Imágenes obtenidas

En resolución VGA (480x640), es decir, la configuración por defecto, las imágenes

obtenidas son todas muy parecidas, tanto si la cámara está tapada tal que debería obtenerse una
imagen completamente negra (Figura 59), como si se destapa y se le pone un papel blanco
delante (Figura 63).

Figura 59: Imagen obtenida con Matlab para la resolución VGA 480x640 con la cámara tapada

Figura 60: Imagen obtenida con Matlab para la resolución VGA 480x640 con una hoja blanca delante

70 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Configurando la cámara en formato QQVGA (120x160) como se ha indicado en el apartado

3.2.1.3 – Escribiendo en los registros de la cámara, se han obtenido imágenes también bastante
rosas, igual que antes, tanto si la cámara está tapada (Figura 61), como si se destapa y se le pone
un papel blanco delante (Figura 62). Estas imágenes son ligeramente distintas a las anteriores
pero siguen sin ser en absoluto lo deseado.

Figura 61: Imagen obtenida con Matlab para la resolución QQVGA 120x160 con la cámara tapada

Figura 62: Imagen obtenida con Matlab para la resolución QQVGA 120x160 con una hoja blanca delante

Pablo Menéndez Blanco 71

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Capítulo 5 - Conclusiones

Es importante explorar los posibles motivos por los que no se ha conseguido obtener
imágenes reales:

- El error puede haber estado en el planteamiento de configuración de la cámara. Con tantos

registros que configurar y tan poca información proporcionada para hacer funcionar la cámara,
es posible que se haya pasado por alto algún registro que hubiera que modificar.

- Sin embargo, también cabe la posibilidad de que la cámara se haya podido estropear en
algún momento durante todas las pruebas realizadas y, cuando finalmente se ha empezado a
capturar la información de los píxeles, estos no proporcionan los colores reales.

Hay que destacar que, después de todas las pruebas realizadas y la cantidad de problemas
encontrados, existe la posibilidad de que la placa de programación utilizada (el Nodemcu esp-
12e) no fuera la mejor elección.

Los problemas encontrados se han debido principalmente a la velocidad de ejecución del

Nodemcu (el tiempo necesario para recoger la información de los píxeles es mayor que el
tiempo que tarda la cámara desde que extrae un byte de información hasta que extrae el
siguiente). Por ello se ha tenido que reducir la velocidad de la cámara considerablemente.

Este problema se agrava al programar en el entorno de desarrollo de Arduino, al no poder

saber qué instrucciones ejecuta el programa cuando salta a la rutina de servicio de la
interrupción. Se hubiera deseado poder realizar partes del programa o incluso el programa
entero en un entorno en el que se pudieran ver las instrucciones resultantes tras la compilación
o incluso se pudieran programar las interrupciones en ensamblador, para tener un mayor control
del proceso y saber qué cambiar para hacer el programa más rápido y eficaz. Esto aún no es
posible, ni para el Nodemcu ni para el chip con wifi ESP8266 que incorpora, siendo el entorno
de Arduino la mejor herramienta para programarlos aun así.

De todas formas, se puede decir que el proceso de aprendizaje ha sido amplio, pues se han
desarrollado conocimientos en diferentes disciplinas:

- Electrónica Analógica: al tener que construir un circuito oscilador para obtener una señal
de reloj.

- Electrónica Digital: se ha profundizado en el microcontrolador de Arduino y se ha

averiguado todo lo posible sobre el microprocesador del Nodemcu para poder aplicarlo.

- Programación: se han aprovechado los conocimientos de C, Matlab y Android y se ha

aprendido a programar en PHP para poder utilizar el servidor.

Pablo Menéndez Blanco 73

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Capítulo 6 - Líneas futuras

Mientras que la cámara es de muy buena calidad, la placa de programación utilizada ha sido
el factor limitante. Por ello, es importante investigar otros métodos de obtención de la
información de la cámara. Utilizar otra placa por ejemplo:

- utilizar un microcontrolador que programar directamente, como por ejemplo un

ATmega de AVR

- utilizar una FPGA (dispositivo con puertas lógicas programables) y programarla en

VHDL podría acelerar la obtención de la información de la cámara

En cualquiera de estas opciones habría que asegurarse de:

 que funcione a gran velocidad, en torno a 50MHz sería lo adecuado,

 que tenga memoria suficiente y rápida para almacenar, si es posible, la información de

una imagen completa (esto sería: 640x480x2 = 615k, luego 700KB mínimo de memoria
SRAM sería lo recomendable para poder crear cadenas de caracteres que enviar),

 y buscar un método para conseguir conexión a internet y poder recibir las imágenes en
dispositivos lejanos. Ejemplos de cómo lograr esto podrían ser:

- seguir utilizando un módulo ESP8266, ya que la parte de comunicación Wifi no ha

dado problemas

- utilizar conexión Ethernet (cableada), la cual aumentaría la velocidad de

transmisión de datos. Sin embargo, esta opción solo serviría para aplicaciones en
posiciones fijas, como por ejemplo cámaras de seguridad.

Una vez conseguidas imágenes, si el tiempo entre que se empieza a recoger información de
la cámara hasta que se recibe en el dispositivo destinado a procesarla es muy pequeño, se podrán
conseguir imágenes a intervalos de tiempo muy reducidos, permitiendo visualizar imágenes en
tiempo real, para por ejemplo pilotar un dron e incluso aplicar algoritmos de detección de
movimiento y previsión de trayectorias.

Pablo Menéndez Blanco 75

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Capítulo 7 - Planificación temporal y presupuesto

7.1. Estructura de Descomposición del Proyecto (EDP)

La EDP (Figura 63) se ha descompuesto primero en los componentes principales de este
proyecto: el Nodemcu, la cámara OV7670 y el móvil. Estos a su vez se descomponen en bloques
fundamentales: la investigación, el Wifi, la señal de reloj, los registros y el programa a utilizar
finalmente (cada uno dentro de su componente respectivo). Además, el Wifi, la señal de reloj y
los registros se dividen en tareas que hay que realizar para poder completar el proyecto.

El cuarto componente es la documentación, que se divide en los capítulos entregables de este

TFG.

7.2. Diagrama de Gantt

En el diagrama de Gantt (Figura 64) se puede ver la planificación temporal de este proyecto,
desde que se comenzó en febrero hasta la fecha prevista de entrega en junio.

Es importante mencionar que este diagrama se empezó a pensar en febrero pero, al haberse
investigado poco aún sobre los módulos que había que utilizar, se decidió aplazar hasta tener
una idea más amplia de lo que iba a necesitar el proyecto. Así, la planificación temporal se
realizó a principios de marzo, cuando ya se sabía que habría que construir un circuito oscilador.

De todas formas las fechas son orientativas y, aunque al principio se acercaron a cómo se
fue desarrollando el proyecto, después no fue posible debido a trabajos, exámenes finales y
problemas que fueron surgiendo, por lo que se tuvo que retrasar la fecha de finalización y
entrega hasta julio. Fue la documentación de este trabajo lo que más tiempo llevó y lo que más
se retrasó, realizando una extensa mayoría en julio, y compaginándolo con más pruebas para
intentar conseguir imágenes reales, lo que finalmente no fue posible.

Cabe destacar el acierto con el tiempo necesario a investigar sobre los módulos pues, aunque
ya se sabía lo que hacía falta, fue sumamente necesario seguir investigando para no cometer
errores.

Pablo Menéndez Blanco 77

Capítulo 7 - Planificación temporal y presupuesto

Figura 63: Estructura de Descomposición del Proyecto (EDP)

78 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

TFG Inicio Duración Fin

Investigación sobre los módulos 08/02/2016 82 30/04/2016
Probar Wifi 20/02/2016 45 05/04/2016
probar métodos y programas 20/02/2016 30 21/03/2016
averiguar limitaciones 21/03/2016 10 31/03/2016
seleccionar el mejor método 31/03/2016 5 05/04/2016
Señal de reloj 14/03/2016 31 14/04/2016
investigación 14/03/2016 14 28/03/2016
montaje 28/03/2016 5 02/04/2016
pruebas 28/03/2016 7 04/04/2016
soldadura 04/04/2016 5 09/04/2016
conexión a la cámara 09/04/2016 5 14/04/2016
comprobación 09/04/2016 5 14/04/2016
Conexión de los módulos 14/04/2016 4 18/04/2016
pruebas y lecturas en osciloscopio 14/04/2016 4 18/04/2016
Registros 18/04/2016 12 30/04/2016
investigación 18/04/2016 7 25/04/2016
programación 25/04/2016 5 30/04/2016
pruebas 27/04/2016 3 30/04/2016
Programa para enviar
información 30/04/2016 10 10/05/2016
planteamiento 30/04/2016 4 04/05/2016
programación 30/04/2016 10 10/05/2016
pruebas 05/05/2016 5 10/05/2016
Recepción de imágenes 10/05/2016 16 26/05/2016
programa en Matlab 10/05/2016 5 15/05/2016
solución de problemas 15/05/2016 2 17/05/2016
programa en Android 17/05/2016 2 19/05/2016
mejorar detalles 19/05/2016 7 26/05/2016
Documentación 10/05/2016 41 19/06/2016
redacción 10/05/2016 40 19/06/2016
entrega 19/06/2016 1 20/06/2016
Tabla 3: Tareas del diagrama de Gantt (representado en la Figura 64)

Pablo Menéndez Blanco 79

Capítulo 7 - Planificación temporal y presupuesto

Figura 64: Diagrama de Gantt

80 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

7.3. Presupuesto

Para realizar el presupuesto se supone el salario de un recién titulado en el Grado de

Ingeniería en Tecnologías Industriales en una empresa. Este sueldo se estima en unos 600€ para
media jornada (20 horas semanales), obteniendo un salario de 7.5€/hora.

El tiempo dedicado a este proyecto ronda las 420h, por lo que el salario establecido ha sido:
3150€.

A este salario hay que añadirle los gastos de material. En la Tabla 4 se indican los costes de
módulos, cables, el convertidor y la protoboard utilizada. Se compraron un par de cada módulo
para tener de reserva por si alguno se estropeaba, lo cual ocurrió con una de las cámaras. En la
Tabla 5 se muestran los costes de fabricación del circuito oscilador, a los cuales hay que
sumarles los costes de los componentes que también se compraron para realizar pruebas pero
que al final sobraron (Tabla 6). Hay que destacar que el precio de condensadores y resistencias
son muy pocos céntimos y por ello no se han incluido.

Todos los componentes suman en total: 19.51+0.74+1.76 = 22.01€.

Por lo tanto, el precio final total estimado es 3172€.

Componente Precio por unidad (€/ud) Unidades (ud) Precio total (€)
Nodemcu esp12-e 3.88 2 7.76
Cable usb 0.72 2 1.44
Cámara OV7670 3.58 2 7.16
Pack de cables 2 1 2
Protoboard pequeña 0.4 1 0.4
Convertidor a 3.3V 0.75 1 0.75
Total 19.51
Tabla 4: Presupuesto de los componentes básicos

Componente Precio por unidad (€/ud) Unidades (ud) Precio total (€)
Cristal de cuarzo 10MHz 0.19 1 0.19
Inversor SN74HC04 0.25 1 0.25
Placa perforada 0.3 1 0.3
Total 0.74
Tabla 5: Presupuesto de los componentes del circuito oscilador

Componente Precio por unidad (€/ud) Unidades (ud) Precio total (€)
Cristal de cuarzo 20MHz 0.16 1 0.16
Cristal de cuarzo 16MHz 0.21 1 0.21
Cristal de cuarzo 2MHz 1.16 1 1.16
Inversor SN74AC04 0.23 1 0.23
Total 1.76
Tabla 6: Presupuesto de los componentes sobrantes utilizados en pruebas

Pablo Menéndez Blanco 81

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Índice de Figuras

Figura 1: Configuración de pines del nodemcu esp-12e ....................................................................... 14

Figura 2: Diagrama de configuración de pines en un microcontrolador ............................................... 16
Figura 3: Correspondencia de pines del Nodemcu ................................................................................ 17
Figura 4: Cámara OV7670 .................................................................................................................... 19
Figura 5: Configuración de pines de la cámara OV7670 ...................................................................... 19
Figura 6: Temporización de las salidas más importantes de la cámara ................................................. 21
Figura 7: Temporización ampliado de las salidas más importantes de la cámara ................................. 21
Figura 8: Ejemplo de configuración de un registro de la cámara OV7670 (obtenido del datasheet) .... 22
Figura 9: Representación de un DAC (conversor digital-analógico) [4]............................................... 24
Figura 10: Esquema del DAC R-2R [5] ................................................................................................ 25
Figura 11: Señal analógica del DAC (vista en el osciloscopio) ............................................................ 25
Figura 12: Fuente de alimentación FAC-662B ....................................................................................... 27
Figura 13: Convertidor a 3.3V encajado en protoboard ........................................................................ 27
Figura 14: Diagrama de un circuito oscilador ....................................................................................... 28
Figura 15: Esquema eléctrico del circuito oscilador Pierce .................................................................. 29
Figura 16: Circuito equivalente de un cristal de cuarzo ........................................................................ 29
Figura 17: efecto de Rs en el oscilador Pierce (sin carga)..................................................................... 30
Figura 18: efecto de Rs en el oscilador Pierce (con carga) ................................................................... 31
Figura 19: Esquema eléctrico del circuito oscilador finalmente construido.......................................... 31
Figura 20: Inversor SN74HC04 ............................................................................................................ 31
Figura 21: Configuración de pines del inversor SN74HC04 ................................................................. 32
Figura 22: Cristal de cuarzo de encapsulado mediano HC-49/U .......................................................... 32
Figura 23: Montaje del circuito oscilador (f=10MHz y RS=0Ω) ........................................................... 34
Figura 24: Señal de reloj obtenida (f=10MHz y RS=0Ω) ...................................................................... 34
Figura 25: Montaje del circuito oscilador (f=10MHz y RS=280Ω) ...................................................... 35
Figura 26: Señal de reloj obtenida (f=10MHz y RS=280Ω) ................................................................. 35
Figura 27: Montaje del circuito oscilador (f=10MHz y RS=470Ω) ...................................................... 36
Figura 28: Señal de reloj obtenida (f=10MHz y RS=470Ω) ................................................................. 36
Figura 29: Montaje del circuito oscilador (f=20MHz y RS=0Ω) ........................................................... 37
Figura 30: Señal de reloj obtenida (f=20MHz y RS=0Ω) ...................................................................... 37
Figura 31: Circuito oscilador soldado (cable morado = señal de reloj)................................................. 38
Figura 32: Generador de ondas del laboratorio ..................................................................................... 39
Figura 33: Imagen de osciloscopio: interrupciones en el programa ...................................................... 40
Figura 34: Imagen de osciloscopio: interrupciones tras usar la función noInterrupts() en el programa 41
Figura 35: PWM en Arduino de 976MHz ............................................................................................. 42
Figura 36: PWM en Arduino de 490MHz ............................................................................................. 42
Figura 37: Arquitectura del Timer0 de 8 bits del ARmega328P ........................................................... 43
Figura 38: Ciclo de trabajo del PWM obtenido en OCnx según el valor de OCRnx ............................ 43
Figura 39: Opciones de PWM del Timer0 del ATmega328P ............................................................... 44
Figura 40: PWM de máxima frecuencia del Timer0 del ATmega328P ................................................ 44

Pablo Menéndez Blanco 83

Figura 41: Funciones de los pines del nodemcu .................................................................................... 45
Figura 42: Señal CLK_OUT del Nodemcu ........................................................................................... 45
Figura 43: Conexiones........................................................................................................................... 47
Figura 44: Esquema de la comunicación SCCB (3 cables) ................................................................... 51
Figura 45: Esquema de la comunicación SCCB (2 cables) ................................................................... 51
Figura 46: Comienzo de la comunicación SCCB .................................................................................. 52
Figura 47: Fases de la comunicación SCCB ......................................................................................... 52
Figura 48: Fin de la comunicación SCCB ............................................................................................. 53
Figura 49: Captura de pantalla de la aplicación Android ...................................................................... 63
Figura 50: Captura de pantalla de la aplicación Android ...................................................................... 64
Figura 51: Señales de la cámara mediadas en el osciloscopio (XCLK en amarillo, PCLK en azul) .... 66
Figura 52: Señales de la cámara mediadas en el osciloscopio (HREF en amarillo, VSYNC en azul).. 66
Figura 53: Figura 52 ampliada (HREF en amarillo, VSYNC en azul).................................................. 66
Figura 54: Señales de la cámara mediadas en el osciloscopio, prescalado de 32 (XCLK en amarillo,
PCLK en azul) ....................................................................................................................................... 67
Figura 55: Señales de la cámara mediadas en el osciloscopio, prescalado de 32 (HREF en amarillo,
VSYNC en azul).................................................................................................................................... 67
Figura 56: Figura 55 ampliada (HREF en amarillo, VSYNC en azul).................................................. 67
Figura 57: Error: el timer del watchdog se desborda y provoca un reset .............................................. 68
Figura 58: Comprobación de filas y columnas (resolución QQVGA) .................................................. 69
Figura 59: Imagen obtenida con Matlab para la resolución VGA 480x640 con la cámara tapada ....... 70
Figura 60: Imagen obtenida con Matlab para la resolución VGA 480x640 con una hoja blanca delante
............................................................................................................................................................... 70
Figura 61: Imagen obtenida con Matlab para la resolución QQVGA 120x160 con la cámara tapada . 71
Figura 62: Imagen obtenida con Matlab para la resolución QQVGA 120x160 con una hoja blanca
delante ................................................................................................................................................... 71
Figura 63: Estructura de Descomposición del Proyecto (EDP) ............................................................ 78
Figura 64: Diagrama de Gantt ............................................................................................................... 80

84 Escuela Técnica Superior de Ingeniero Industriales (UPM)

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Índice de Tablas

Tabla 1: Correspondencia de los bits 15 a 0 de los registros con las salidas digitales del Nodemcu .... 17
Tabla 2: Modificación de registros de la cámara OV7670 para la resolución QQVGA ....................... 54
Tabla 3: Tareas del diagrama de Gantt (representado en la Figura 64) ................................................. 79
Tabla 4: Presupuesto de los componentes básicos ................................................................................ 81
Tabla 5: Presupuesto de los componentes del circuito oscilador .......................................................... 81
Tabla 6: Presupuesto de los componentes sobrantes utilizados en pruebas .......................................... 81

Pablo Menéndez Blanco 85

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Índice de Códigos

Código 1: declaración de posiciones de memoria para la lectura de los registros asociados a los pines
del nodemcu .......................................................................................................................................... 15
Código 2: Variar un pin digital continuamente ..................................................................................... 40
Código 3: Asignar función a un pin del nodemcu ................................................................................. 45
Código 4: Archivo dataYCr001.json ..................................................................................................... 56
Código 5: Archivo dataYCr001.json estructurado ................................................................................ 57
Código 6: Archivo imageYCr001.json .................................................................................................. 58
Código 7: Archivo imageYCr001.json estructurado ............................................................................. 58
Código 8: Lectura de una url con Matlab .............................................................................................. 59
Código 9: Utilización de la librería JSON.m......................................................................................... 59
Código 10: Acceso a los objetos del archivo .json mediante punteros.................................................. 59
Código 11: Transformar una String en un número entero ..................................................................... 59
Código 12: Obtención de una cadena de caracteres del archivo .json ................................................... 59
Código 13: Obtención del valor YCbCr de cada píxel .......................................................................... 60
Código 14: Función para crear una imagen a partir de una matriz de 3 dimensiones ........................... 60
Código 15: Lectura de una url con Android .......................................................................................... 61
Código 16: Utilización de la librería JSON de Android........................................................................ 61
Código 17: Acceso a los objetos del archivo .json mediante la librería JSON de Android .................. 61
Código 18: Obtención del valor YCbCr de cada píxel .......................................................................... 62
Código 19: Guardado de los valores de RGB en una variable Bitmap ................................................. 62
Código 20: Obtención del valor YCbCr de cada píxel .......................................................................... 62

Pablo Menéndez Blanco 87

 Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Bibliografía

[1] «wikipedia,» [En línea]. Available: https://en.wikipedia.org/wiki/ESP8266 . [Último acceso:

Junio 2016].

[2] «ElectroniLab,» [En línea]. Available: http://electronilab.co/tienda/nodemcu-board-de-

desarrollo-con-esp8266-wifi-y-lua/.

[3] «ESP8266 Comunity Forum,» [En línea]. Available:

http://www.esp8266.com/viewtopic.php?f=13&t=273. [Último acceso: Abril 2016].

[4] «Wikipedia,» [En línea]. Available: https://en.wikipedia.org/wiki/Digital-to-

analog_converter#DAC_types. [Último acceso: Junio 2016].

[5] «Wikipedia,» [En línea]. Available: https://en.wikipedia.org/wiki/Resistor_ladder. [Último

acceso: Junio 2016].

[6] «RadioMuseum,» [En línea]. Available:

http://www.radiomuseum.org/r/promax_fuente_alimentacion_fac_662_b.html.

[7] «Texas instruments,» [En línea]. Available: http://www.ti.com/lit/an/szza043/szza043.pdf.

[Último acceso: Abril 2016].

[8] L. Llamas, «Luis Llamas: Ingenieía, informática y diseño,» [En línea]. Available:
http://www.luisllamas.es/2015/08/salidas-analogicas-pwm-en-arduino/. [Último acceso: Junio
2016].

[9] «Arduino.cc,» [En línea]. Available: https://www.arduino.cc/en/Guide/Introduction. [Último

acceso: Julio 2016].

[10] T. LTD, «Github,» [En línea]. Available: https://github.com/thinger-io/Arduino-Library. [Último

acceso: Julio 2016].

[11] «New Wave Concepts,» [En línea]. Available: http://www.new-wave-

concepts.com/ed/livewire.html. [Último acceso: Julio 2016].

[12] «Wikipedia,» [En línea]. Available: https://es.wikipedia.org/wiki/MATLAB. [Último acceso: julio

2016].

[13] «Wikipedia,» [En línea]. Available: https://es.wikipedia.org/wiki/Android. [Último acceso: julio

2016].

[14] «Wikipedia,» [En línea]. Available: https://es.wikipedia.org/wiki/Android_Studio. [Último

acceso: julio 2016].

Pablo Menéndez Blanco 89

Bibliografía

[15] «Wikipedia,» [En línea]. Available:

https://es.wikipedia.org/wiki/Perro_guardi%C3%A1n_(electr%C3%B3nica). [Último acceso:
julio 2016].

[16] «Farnell,» [En línea]. Available: http://uk.farnell.com/gw-instek/afg-2005/function-generator-

1ch-arb-dds/dp/2100020. [Último acceso: Julio 2016].

90 Escuela Técnica Superior de Ingeniero Industriales (UPM)