IES El Burgo de Las Rozas

Diseño y construcción de un microsatélite (CanSat)

Trabajo de Investigación del Programa de Excelencia

“Lo importante no es la colonización

de Marte, sino la tecnología que se va a
inventar para llegar” – Pedro Duque
6/10/2017

Efrén Boyarizo
Carmen Méndez Martín
12/2017 (Revisión 2)

1
2
1. INTRODUCCIÓN .................................................................................................................... 5

1.1. ¿QUÉ ES UN CANSAT? ........................................................................................................... 5

1.2. LA BURGONETA ESPACIAL ....................................................................................................... 6

2. ELEMENTOS DE UN SATÉLITE Y COMPONENTES UTILIZADOS ............................................... 7

2.1. ORDENADOR DE A BORDO ....................................................................................................... 7

2.2. ALIMENTACIÓN DEL SISTEMA ................................................................................................... 8
2.2.1. Panasonic NCR18650................................................................................................... 8
2.2.2. LM2575........................................................................................................................ 9
2.2.3. Interruptor por luz ..................................................................................................... 11
2.3. SENSORES .......................................................................................................................... 11
2.3.1. u-blox NEO 6M (GPS) ................................................................................................. 11
2.3.2. MQ135 (CO2) ............................................................................................................. 12
2.3.3. GUVA-S12SD (UVC) .................................................................................................... 12
2.3.4. GY-91 (MPU9250 y BMP280 10DOF) ......................................................................... 13
2.3.5. BME280 (Humedad, presión, temperatura) .............................................................. 13
2.3.6. ADS1115 (ADC) .......................................................................................................... 14
2.3.7. DHT11/22 (Humedad) ............................................................................................... 14
2.3.8. Raspberry Pi Camera Module V2 ............................................................................... 14
2.4. TRANSMISORES................................................................................................................... 15
2.4.1. APC220 ...................................................................................................................... 15
2.4.2. ET600R ....................................................................................................................... 15
2.4.3. Radiobaliza ................................................................................................................ 16
2.5. CIRCUITO........................................................................................................................... 16

3. SOFTWARE CANSAT ........................................................................................................... 20

3.1. PROGRAMA PRINCIPAL ......................................................................................................... 22

3.2. GY-91 (BMP280) Y BME280 ............................................................................................ 23
3.3. GPS (NEO 6M) ................................................................................................................. 24
3.4. ADS1115 ......................................................................................................................... 26
3.5. GY-91 (MPU9250)........................................................................................................... 27
3.6. APC220 ........................................................................................................................... 28
3.7. DHT22............................................................................................................................. 28
3.8. RASPBERRY PI CAMERA ........................................................................................................ 28

4. ESTACIÓN BASE (GROUND STATION) ................................................................................. 30

4.1. HARDWARE........................................................................................................................ 30
4.2. SOFTWARE......................................................................................................................... 31
4.3. PROBLEMAS ....................................................................................................................... 33
3
5. RESULTADOS ...................................................................................................................... 34

5.1. FALLOS MECÁNICOS ............................................................................................................. 34

5.2. MISIÓN PRIMARIA ............................................................................................................... 35
5.3. MISIONES SECUNDARIAS ....................................................................................................... 36
5.3.1. Retransmisión en vivo................................................................................................ 36
5.3.2. Localización 3D .......................................................................................................... 36
5.3.3. Mapa topográfico...................................................................................................... 36
5.3.4. Determinar la posibilidad de vida.............................................................................. 37

6. RESULTADO DEL CONCURSO Y CONCLUSIONES .................................................................. 43

7. ANEXOS ............................................................................................................................. 45

7.1. PROTOCOLOS ..................................................................................................................... 45

7.1.1. Inter-Integrated Circuit (I2C) ...................................................................................... 45
7.1.2. Comunicación Serie (8N1) ......................................................................................... 47
7.2. IMÁGENES ......................................................................................................................... 48
7.3. CÓDIGO ............................................................................................................................ 50

8. BIBLIOGRAFÍA .................................................................................................................... 50

8.1. PROTOCOLOS ..................................................................................................................... 50

8.2. DATASHEETS ...................................................................................................................... 50
8.3. CÓDIGO ............................................................................................................................ 51
8.4. INVESTIGACIONES ................................................................................................................ 51
8.5. PRINCIPIOS FÍSICOS .............................................................................................................. 51
8.6. OTROS LINKS ...................................................................................................................... 51

9. AGRADECIMIENTOS ........................................................................................................... 51

4
 1. Introducción
1.1. ¿Qué es un CanSat?
Un CanSat, como su propio acrónimo indica, es un satélite del tamaño de
una lata de refresco de 330 cL, que asciende a una altura de 1 o 2 kilómetros
(mediante cuadricópteros, globos, cohetes…) y cae de manera controlada usando
paracaídas, parapentes o incluso sus propios motores (simulando un
cuadricóptero). Estos microsatélites, a través del concurso organizado por la
Agencia Espacial Europea, permiten a estudiantes europeos participar en un
proyecto real de ingeniería. Cada instituto puede presentar un equipo, formado por
6 estudiantes (flexible) y un profesor.
Los requisitos que el satélite ha de cumplir son los siguientes:
- Tamaño, 110x65 mm.
- Peso mínimo de 300 gr y máximo de 350 gr.
- Las baterías deben durar de forma continua durante al menos 4 horas.
- Resistente como mínimo 20 g de aceleración.
- Su velocidad de caída debe ser como mínimo de 8 m/s y como máximo de 12
m/s para un paracaídas normal, y alrededor de 6 m/s para un parapente.
- Debe medir al menos la temperatura y presión atmosférica, que corresponde
con la misión primaria común a todos los equipos.
- Enviar datos al menos cada segundo (no es necesaria una comunicación
bidireccional).
- El precio máximo es de 500 € por CanSat (sin incluir los materiales de la
estación base, viaje…).
Cumpliendo con los requisitos mínimos, el proyecto resulta sencillo. Para
incrementar la dificultad, cada equipo debe idear sus misiones secundarias y
cumplir con las mismas equipando en su CanSat los sensores necesarios. Por otro
lado, la divulgación (no incluida en los requisitos) supone una parte fundamental
del proyecto. Ya sea mediante charlas, merchandasing, aparición en las noticias,
redes sociales, o cualquier otro medio, los jueces valoran mucho la divulgación del
proyecto. También es importante animar a futuros participantes. Es en ambos
puntos (misiones secundarias y divulgación) donde de verdad se marca la
diferencia entre unos equipos y otros.

5
 Para acceder al concurso, primero es necesario enviar un documento en
donde se relata a grosso modo el proyecto y el equipo. La selección es realizada
en cada país por un grupo designado por la Agencia Espacial Europea y en caso
de que no haya concurso nacional por la misma ESA. En el caso de España, 2017
fue el primer año en el que se organizó el concurso nacional, haciendo más sencillo
participar en el concurso. El objetivo del concurso nacional es seleccionar al mejor
proyecto de cada país para así presentarlo al concurso europeo.
1.2. La Burgoneta Espacial
La Burgoneta Espacial, ganadora de la fase nacional
y la europea, fue bautizada así en relación a la zona donde
se localiza el instituto. El equipo lo conformaron el profesor
Francisco Viñas y los estudiantes: Samuel Nevado, Pablo
Tomás Campos, Fernando Celaya, Jaime Pérez, Enrique
Teja, Fernando Bermúdez y Efrén Boyarizo.
Además de la misión primaria, la Burgoneta Espacial tuvo tres misiones
secundarias:
- Determinar la habitabilidad del planeta en donde se lance, mediante mediciones
como: temperatura, CO2 (y otros gases potencialmente dañinos), humedad,
presión atmosférica, radiación UV y la existencia de un campo magnético similar
al de la tierra (cinturón de Van Allen).
- Realizar un mapa topográfico de la zona para decidir un buen lugar de aterrizaje
para futuras misiones.
- Transmitir en vivo toda la información (incluido el video de caída) para crear así
una recreación de la trayectoria, gráficas en tiempo real y evitar la pérdida de
datos en el caso de que resulte imposible recuperar los datos físicamente.
Para difundir el proyecto de La Burgoneta Espacial se:
- Creó un blog (https://burgosat.tk), en donde se publicó toda la información, así
como links importantes y el progreso del proyecto.
- Crearon perfiles en las redes sociales, como Instagram, en donde se publicaron
fotos y videos además de interactuar con la comunidad.
- Desarrolló una aplicación móvil para Android, la cual integraba el blog, el canal
de YouTube y la cuenta de Instagram. Además, incluyó una función especial: el
envío de notificaciones a todos los usuarios que la tuvieran instalada, haciendo
6
 sencillo notificar a los usuarios el momento del lanzamiento, además de hacer
tarea fácil entrar al video en directo (con un simple click).
- Como el presupuesto del proyecto fue escaso, para ganar un poco de
presupuesto, se decidió hacer camisetas y venderlas, permitiendo así financiar
la construcción del satélite para la fase nacional.
Como La Burgoneta Espacial ganó el concurso nacional de Caesaraugusta,
el proyecto no terminó, construyéndose así un segundo prototipo en el que se
intentó solucionar los fallos del anterior modelo. En este documento solo se relata
la construcción del segundo CanSat además de los problemas que se intentaron
solucionar.

2. Elementos de un satélite y componentes utilizados

Todos los componentes se adquirieron en placas independientes de manera
que no hiciera falta diseñar el circuito de forma completa, facilitando además el
reemplazo de los componentes defectuosos. Para la conexión entre los
componentes y la placa principal se emplearon conectores de tamaño 22 CAE
(AWG) y separación de 2,54 mm.
2.1. Ordenador de a bordo
La parte principal de todo sistema informático es siempre la unidad de
procesamiento central. Esta se encarga de recoger los datos de los sensores,
procesarlos (en caso de que sea necesario) y de realizar las acciones pertinentes
con los resultados obtenidos. En el caso de un CanSat, estos pasos se
corresponden con recoger los valores de los sensores, convertir los datos a valores
numéricos entendibles, enviar los datos inalámbricamente y almacenarlos en un
medio.
Para la CPU la elección fue un SBC
(todos los componentes necesarios para
hacer funcionar el ordenador se
encuentran en una única placa), fabricada
por la Fundación Raspberry Pi. El modelo
fue la Raspberry Pi Zero W, cuyas características son las siguientes:
- Un procesador Broadcom BCM2835 ARM de un núcleo a 1GHz.
- 512Mb de RAM DDR2.

7
- Conectividad Wi-Fi y Bluetooth.
- Puertos de entrada y salida (GPIO, General Purpose Input and Output pins).
- Su tamaño, de tan solo 60x30mm.
Aunque estas prestaciones puedan resultar un tanto escasas cuando las
comparamos con los dispositivos móviles que usamos a diario, para un CanSat son
más que suficientes.
Para el modelo nacional se utilizaron dos ordenadores de a bordo, la
Raspberry Pi y un Arduino Nano con un microcontrolador Atmega 328P. Esto fue
debido a la sencillez de programar en Arduino, ya que su comunidad crea y
comparte programas que hacen funcionar los sensores.
Dado que el Arduino no fue capaz de procesar todos los datos de los
sensores debido a su limitada memoria, se emplearon ambos ordenadores en
conjunto, distribuyendo así las tareas. Al tener la necesidad de utilizar la Raspberry
Pi como ordenador de a bordo debido a la cámara, se decidió eliminar el Arduino al
ser el potencial de la Raspberry Pi más que suficiente para completar todas las
necesidades del CanSat. Esto ocasionó que se tuviese que añadir al circuito un
conversor de analógico a digital además de dedicar más tiempo al proyecto. Por
tanto, la versión de Alemania solo equipó un ordenador, la Raspberry Pi Zero W,
reduciendo costes, uso de espacio, consumo y aumentando la velocidad de
transmisión a dos datos por segundo.
2.2. Alimentación del sistema
Debido a la gran cantidad de componentes, el consumo del CanSat para el
primer prototipo supuso un gran reto. Si bien se consiguió que funcionara durante
al menos 4 horas seguidas, la temperatura interior del CanSat fue tan excesiva que,
hasta que no ventiló a la mitad de la caída, los sensores no midieron correctamente.
Este exceso de temperatura fue producido en conjunto por el transmisor de video y
el regulador de voltaje. El objetivo de la versión de Alemania fue prevenir esto
mediante varias modificaciones.
2.2.1. Panasonic NCR18650
Las baterías escogidas fueron las Panasonic NCR18650 de tecnología Litio-
Ion con una capacidad de 3400 mAh y voltaje de 3,6 V. Los motivos por los que se
usaron son los siguientes:

8
 La tecnología es un tanto antigua, pero sigue siendo
muy utilizada hoy en día debido a su alta capacidad (tres
veces superior a las de tipo LiPo), y sobre todo a que
son mucho menos peligrosas que las LiPo, que, aunque
muchos dispositivos las usen debido a su caída de
voltaje mínima (lo que resulta muy cómodo para
alimentar equipos electrónicos con un elevado
consumo), un cambio de temperatura brusco o simplemente un golpe fuerte,
puede provocar una la reacción química de la pila.
 Son a fecha de este documento las baterías con mayor capacidad (3400mah),
en relación a su tamaño. Y es por esto que una variante de estas baterías es
usada por la compañía Tesla Motors en sus automóviles eléctricos.
 Su voltaje normal de 3,6 V es excelente para alimentar el transmisor de video,
ya que dos en serie dan 7,2 V que superan el voltaje mínimo de 7 V para
alimentar el transmisor de video.
2.2.2. LM2575
El uso de estas baterías conlleva el problema de ajustar el voltaje a 5V, ya
que la mayoría de los componentes del CanSat dependieron de un voltaje fijo con
variaciones de máximo ±10%. Para conseguir ese voltaje, en Zaragoza se utilizó el
regulador de voltaje lineal LM7805 de uso muy simple. Pero, al basarse la
regulación del voltaje en una resistencia variable, la energía sobrante se disipa en
forma de calor. Para calcular cuanta energía se pierde, se toma el regulador como
una resistencia:
P = ΔV ⋅ I = (7,2 V – 5 V) ⋅ 1 A = 2,2 W η = VOUT / VIN = 5 V / 7,2 V = 0,7 = 70%
Esto supone que al regular el voltaje se pierden 2,2 W en forma de calor con
un rendimiento del 70%. No muy eficiente si se tiene en cuenta que las baterías al
estar cargadas, tienen un voltaje superior, ergo la eficiencia es peor. Tras investigar,
se concluyó que la mejor forma de reducir el consumo y el calor era cambiando el
regulador de voltaje y el apagado selectivo del transmisor de video.
El regulador de voltaje escogido para el segundo CanSat fue el
LM2575, un regulador conmutado ajustable de 1ª, que, a diferencia del
anterior, requiere de un circuito más complejo, pero añade las siguientes
mejoras:
9
 Protección contra polaridad inversa. Muy útil si uno no tiene cuidado.
 Un voltaje mucho más limpio de interferencias (las oscilaciones producidas por
los transmisores pueden contaminar la alimentación produciendo oscilaciones
en la alimentación nada convenientes).
El LM2575 puede venir
con voltaje fijo, o como en
este caso con el voltaje
ajustable. Si es esta última, el
regulador dependerá de la
combinación de dos
resistencias para ajustar el
voltaje de salida. Una relación
de 1/3 es aproximadamente la
necesaria para dar 5 V. Para el CanSat se utilizaron dos combinaciones diferentes,
pero la que más se ajustó fue con R1=330 Ω y R2=1K Ω.
Respecto a la eficiencia de este
regulador, resulta bastante compleja de
calcular debido a que su eficiencia no varía
linealmente (afectan muchos factores, como la
calidad de los componentes). La única manera
es calcularlo empíricamente. En la siguiente
tabla se muestra aproximadamente un
rendimiento del 82% para 5 V y 1 A.
Aunque la tabla indica una eficiencia
similar a la del LM7805, en pruebas reales la bajada de consumo fue mucho más
significativa, dado que el CanSat no siempre consume la misma cantidad de
energía. Más pruebas quedaron pendientes de realizarse, pero dada su
irrelevancia, se decidió utilizar el LM2575 debido a su disipación térmica mucho
menor, además de un mejor consumo.

10
 2.2.3. Interruptor por luz
Para reducir el consumo del transmisor
de video se diseñó un circuito el cual cerraba la
alimentación usando dos Mosfets conectados a
dos LDR. La circuito tuvo la función de cortar la
alimentación del transmisor de video en la
oscuridad. Precisamente el momento en el que el CanSat esperaba dentro del
cohete para ser lanzado podría extenderse mucho, y al ser inútil el transmitir el
video, el transmisor se apagaba con la oscuridad dentro del cohete, ahorrando en
produciendo el apagado selectivo del transmisor de video (al ser el componente
con mayor consumo) y suponiendo un ahorro enorme de energía.
2.3. Sensores
2.3.1. u-blox NEO 6M (GPS)
Para una localización 3-D del CanSat la mejor opción fue
un dispositivo GPS (Global Position System), que basándose en
una constelación de satélites obtiene una localización más o
menos precisa.
Una de las marcas más famosas que manufactura estos dispositivos a un
tamaño y costo reducido es u-blox. El modelo escogido fue el u-blox NEO-6M, un
GPS de muy bajo coste, pero cuyas prestaciones no tienen nada que envidiar a sus
hermanos mayores (excepto el soporte para las nuevas constelaciones). Este GPS
es muy sencillo de usar, y la única comunicación que hay es a través de un puerto
serie (anexo 7.2.2). Tal y como viene de fábrica el GPS es perfectamente funcional:
envía toda la información (incluyendo la irrelevante posición de cada satélite) una
vez por segundo. El GPS se modificó para que enviase la localización 3-D corregida
y la velocidad dos veces por segundo para facilitar el uso del GPS desde el
Software. Además de estos cambios, para el modelo de Alemania se sustituyó la
antena que venía de fábrica por una de menor tamaño, menor peso, mayor
ganancia y mejores soldaduras del cable.

11
 2.3.2. MQ135 (CO2)
El MQ135 es un sensor muy utilizado para
detectar gases perjudiciales, aunque su bajo coste
se contrapone con su elevada dificultad a la hora de
medir precisamente. Cada sensor tiene una
resistencia interna diferente, que se tiene que
determinar en condiciones especiales. El fabricante
del sensor adquirido no proporcionó ninguna información sobre las resistencias, por
lo que la primera opción fue calcular las partículas por millón (ppm) utilizando la
siguiente fórmula proveniente del datasheet:
PPM = Rs/Ro
Rs = 1024*(Resistencia Pull-Down)/(voltaje de salida) - (Resistencia Pull-
Down)
Ro = Resistencia del sensor a 100ppm de NH3 en aire limpio
Esta es la manera oficial de obtener medidas exactas, pero resultó imposible
calibrarlo al no poder determinar la resistencia Pull-Down que el sensor
incorporaba. Como última opción se decidió ir con el método simple que algunos
usuarios recomiendan: usar un multiplicador. Dado que el voltaje de salida es más
o menos directamente proporcional a la cantidad de partículas por millón, una
simple multiplicación basta para obtener una medida aproximada. Para calibrarlo,
se aumenta o disminuye el multiplicador. Una primera opción fue buscar alguna
estación en Madrid que midiese las ppm de CO2, pero sorprendentemente, ninguna
de las listadas en toda la comunidad indica valores diarios. Como último recurso el
sensor se calibró usando la media global.
2.3.3. GUVA-S12SD (UVC)
Para el primer prototipo se adquirió un sensor capaz de abarcar desde el
rango A hasta el C. La primera idea fue elaborar un filtro para eliminar los rangos A
y B. Este primer filtro, obtenido a partir de un cristal tintado, supuestamente
bloqueaba los rangos UVA y UVB, aunque debido a la falta de presupuesto para
adquirir una lámpara de UVC, se tuvo que confiar en que los valores enviados por
el sensor coincidían con el rango UVC sin bloquearlo parcialmente. Así fue el filtro
presentado a la fase nacional, que más tarde se comprobó que bloqueaba el rango
A y parcialmente el B.
12
 Para la fase europea se decidió presentar otro prototipo del sensor de UVC,
esta vez, en vez de bloquear los rangos UVA y UVB bloquearía el UVC en uno de
los dos sensores. De esta forma calculando la diferencia entre los valores de cada
sensor se obtendría un valor aproximado de UVC. Para comprobar el
funcionamiento, varios miembros del equipo visitaron un laboratorio donde
intentaron durante varios días obtener un filtro que solo bloquease lo necesitado. Al
final, anecdóticamente, resultó que un film transparente que andaba por allí
bloqueaba aproximadamente el espectro necesitado.
Los sensores usados para la versión final fueros
los sensores UV de Adafruit, los cuales marcan el rango
de UV en base a su voltaje, es decir, alimentando el
sensor con un voltaje regulado de 5 V, el voltaje de salida
multiplicado por 10 indica el índice de UV.
2.3.4. GY-91 (MPU9250 y BMP280 10DOF)
Este sensor diseñado para ser parte de un
controlador de vuelo se implementó en el primer modelo y
se mantuvo para el segundo. Aunque el modelo adquirido
fue una copia china, este funcionó excelentemente. El GY-
91 incorpora dos sensores en una única placa: el MPU9250
(incorpora además el magnetómetro AK8963) y el BMP280 de Bosch. Gracias al
protocolo I²C usado (anexo 7.2.1), ambos sensores van conectados a la misma
línea y con la misma alimentación.
2.3.5. BME280 (Humedad, presión, temperatura)
El BME280, de la misma serie de que el BMP280 de
además de sensor de temperatura y presión uno de humedad,
usando el mismo protocolo I²C. Desafortunadamente el sensor
adquirido resultó ser el BMP que se ofertaba como BME con
descuento, aun así, se instaló en el CanSat añadiendo además como cambio de
última hora el DHT22 (mucho menos preciso).

13
 2.3.6. ADS1115 (ADC)
El ADS1115 es un conversor de analógico a
digital que usa el protocolo I²C, muy conveniente, ya
que el protocolo usado por los demás sensores es el
mismo y permite conectar todos los sensores a una
misma línea simplificando el circuito.
Dado que el Arduino incorpora un ADC (conversor de analógico a digital), la
primera versión no necesitó uno externo. Pero, para la segunda versión, eliminar el
Arduino supuso la necesidad de añadir un ADC externo debido a la ausencia de
uno en la Raspberry Pi (con solo salidas y entradas digitales). Las ventajas y
características de este ADC son:

 Gran velocidad obteniendo mediciones.

 Mayor resolución de 16 bits a diferencia de 10 bit en Arduino.
 Sin necesidad de voltaje de referencia, facilitando el diseño del
circuito, a diferencia de otros ADC.
 Un consumo mucho menor respecto a otros ADC del mercado.
2.3.7. DHT11/22 (Humedad)
Ambos DHT son muy usado por su bajo coste. Aunque la
precisión deja mucho que desear incluso en el más preciso
DHT22. Su uso se limitó a detectar la presencia de humedad,
ya que la temperatura se recogió del BMP280. El único
problema grave con este sensor es el tiempo de recogida de
datos, siendo uno por cada dos segundos. Respecto a su funcionamiento interno,
no se invirtió tiempo en investigarlo debido a la gran disponibilidad de librerías.
2.3.8. Raspberry Pi Camera Module V2
La Fundación Raspberry además de ordenadores, vende
también cámaras. Estas se conectan a través del puerto CSI
presente en las Raspberry Pi. Estas cámaras permiten al usuario
realizar videos y tomar fotografías en alta calidad de manera sencilla.
Para el CanSat, se utilizó la segunda versión con un sensor Sony
IMX219 de 8 megapíxeles que alcanza a tomar video a 1080p 30
fotogramas por segundo y un filtro IR. Estas cámaras vienen con una tuerca que

14
permite ajustar la distancia focal, la cual se ajustó para conseguir la mayor
profundidad de campo, o lo que es lo mismo, mayor campo de enfoque.
Su uso es relativamente sencillo, se conecta a la Raspberry y se activa la
cámara en los ajustes. Por sencillas que parezcan estas cámaras, incorporan
múltiples herramientas en las que se pueden ajustar todas las opciones (discutidas
con más detalle en el apartado de software).
Para el CanSat se decidió tomar videos de 5 minutos a 1080p y 30
fotogramas por segundo para así tener la mayor cantidad posible de imágenes, sin
saturar la memoria RAM y procesador.
2.4. Transmisores
2.4.1. APC220
Este transmisor se usa para
comunicaciones de puerto serie a larga distancia.
Su alcance es de máximo 1000 m con velocidad
de 2400 bps usando las antenas helicoidales que
vienen en el kit. Para el CanSat se necesitó un
alcance de máximo 2 km, por lo que se tuvo que
elaborar una antena monopolo de longitud ¼ de onda. La ventaja de esta antena
es la sencillez y facilidad de adquisición (uno mismo la puede hacer en casa), que,
además, al ser flexible ocupa menos espacio. La antena que el CanSat equipó fue
hecha a partir de un trozo de cable metálico con longitud de 17,23 cm. Para recibir
se invirtió en una antena Yagi de 433 MHz. Costosa, pero con mucha ganancia. En
pruebas reales se comprobó que el alcance superaba los 2 km con tan solo 20 mW
de potencia.
Para transmitir datos se usó la frecuencia de 433 MHz debido a que es la
frecuencia legal más baja y más usada, lo que supone un menor coste del
equipamiento.
2.4.2. ET600R
Este transmisor fabricado por Eachine es usando
en hobbies para FPV (vista en primera persona). Su uso
es tan simple como conectar video analógico al transmisor
y sintonizar la frecuencia en el receptor. La frecuencia

15
escogida para este transmisor fue 5705 MHz. Hay varias razones por las que se
decidió usar tan elevada frecuencia:

 El video a diferencia de los datos, contiene mucha más información.

Es decir, frecuencias tan bajas como 433 MHz requieren compresión,
lo que eleva el precio del equipamiento.
 Los primeros transmisores asequibles transmiten a 1,2 GHz, pero no
todas las frecuencias son legales para uso libre. Las frecuencias de
1,2 y 1,4 GHz son ilegales por razones propias. La siguiente opción
fue usar un transmisor de 2,4 GHz, pero al estar tan extendida
globalmente es inevitable sufrir interferencias. La siguiente banda
legal es 5,8 GHz, y al ser la más popular tiene la ventaja de un coste
muy reducido del equipamiento.
La frecuencia de 5,8 GHz tiene menor penetración que otras frecuencias,
requiriendo mayor potencia para transmitir. El transmisor que equipó el CanSat
transmitió a una potencia de 600 mW a diferencia de los 20 mW del APC220. Esto
supuso un consumo mucho mayor de energía, además de una gran disipación
térmica. Estas potencias son ilegales en muchos países, por lo que se solicitó
permiso a la organización. Aunque afirmaron que su uso está prohibido, al ser la
ocasión especial y por un corto periodo de tiempo no debería haber problema
alguno.
2.4.3. Radiobaliza
Aunque en un principio se planeó incluir una baliza que transmitiría una señal
a 315MHz, se tuvo que descartar debido a problemas de espacio.
2.5. Circuito
Para conectar los
componentes, se necesitó de un
circuito. Las primeras versiones se
realizaron en una protoboard
conectada a una Raspberry Pi 1 B+,
que junto a jumpers conformaban un
circuito. Como este no era viable, se
decidió diseñar una PCB (placa de
fibra de vidrio con un circuito impreso encima). En un primera fase se intentó diseñar
16
con un programa llamado Fritzing, y posteriormente con KiCad,
desafortunadamente su aprendizaje requiere de tiempo y dedicación.
Como última opción, se elaboró un primer circuito a mano, resolviendo las
conexiones de cabeza, cuyas medidas se escanearon posteriormente para elaborar
el circuito con un programa de edición de fotografía llamado GIMP.
Las conexiones son las siguientes para el modelo de Alemania:

 Las dos baterías van en serie para aumentar el voltaje a 7,4 V, necesario para
el transmisor.
 Para regular el voltaje a 5 V se usó un LM2575. La Raspberry Pi, el APC220,
MQ135 y sensores de UVC fueron conectados a 5 V, el resto se alimentaron del
regulador de 3,3 que incluye la Raspberry Pi.
 El interruptor por luz se posicionó entre medias de la alimentación y el
transmisor.
 Todos los sensores que utilizan el protocolo I2C, van conectados en serie a las
mismas conexiones.
 El GPS va conectado al pin de recepción (RX) del puerto serie de Hardware y
el APC220 en la salida (TX). De esta forma se aprovecha el único puerto por
Hardware que hay evitando tener que recrear uno por Software (elevado uso de
CPU).
 El DHT va conectado a un pin digital cualquiera. El más conveniente fue el pin
23.

17
 La cámara va conectada directamente a la Raspberry Pi mediante su propio
cable diseñado por la fundación Raspberry.
 El transmisor de vídeo va conectado a la salida de video analógica de la
Raspberry Pi. Dado que la alimentación de la Raspberry pasa a través del
regulador, a no ser que se conecte el retorno directamente de la Raspberry Pi
al transmisor (negativo del video) se pueden producir interferencias en el video.
Se conectó el negativo del video al negativo del interruptor lumínico.
Para la elaboración del circuito se tuvo en cuenta los pines de cada sensor
además de los cambios que tuvieran que hacerse eléctricamente (cambio de
dirección del BME280). El circuito final es el siguiente:

3,3V 7,2V

5V GND / NC

I2C Serie

Analógico

Notas sobre el circuito:

 El circuito impreso se elaboró a mano usando una PCB

de revelado fotosensible a doble cara y atacador.
 El BMP280 fue alimentado en el pin SDO con 3,3 V
para cambiar la dirección evitando conflictos con el GY-
91.
 El circuito tiene la mayor superficie posible de masas
para evitar interferencias.
 Las conexiones antes del transmisor de datos son para
unos deep switches que lo desconectan en caso de que
se necesite reprogramarlo.
 El DHT, que no aparece en la imagen, iría por la cara
posterior conectado a la izquierda del APC220.

18
 El transmisor de video y los sensores de UV, fueron conectados mediante
cables a la placa.
 El cable azul es la masa del video conectada al negativo del transmisor de video
para prevenir interferencias.
 El circuito que corta la corriente del transmisor de video fue añadido a la placa,
pero desafortunadamente falló momentos antes del lanzamiento, por lo que se
decidió desactivar haciendo un puente. El circuito constó de dos Mosfets y dos
LDR, los cuales activaban el paso de corriente cuando la luz era detectada.
El resultado final es el siguiente:

Respecto a los componentes, se tuvo en cuenta lo siguiente:

 En un principio no se tenía planeado colocar el DHT22, pero como no hubo

ninguna otra opción para medir humedad, se colocó encima del APC220.
 El GY-91 fue configurado para que la brújula funcionase cuando estuviera
horizontal, por lo que se colocó de tal forma.
 El núcleo de ferrita (en blanco) usado en el regulador de voltaje tuvo que ser
aislado primero con una funda de cinta aislante y por fuera con un trozo de
chapa metálica. Esto evitaba interferencias con el transmisor de video, datos y
sobretodo GPS.
 El cable que conecta a la cámara con la Raspberry Pi fue asegurado haciendo
una U debajo del MQ135, además de ser forrado en una funda aislante. Esto
prevenía la desconexión del cable, así como posibles daños.

19
 Los últimos pasos son soldar los cables del transmisor de video y baterías.
Con eso la placa ya estaría terminada.
Para un mayor detalle de como montar el CanSat, puedes visitar el canal de
YouTube en donde encontrarás dos animaciones: https://goo.gl/drFxu1

3. Software CanSat
La Raspberry Pi como ordenador precisa de un sistema operativo. El mejor
de todos los que hay disponibles es una versión de la distribución Debian
GNU/Linux llamada Raspbian. Este S.O. viene con una gran cantidad de
herramientas preinstaladas entre ellas la utilidad para la cámara y un entorno de
desarrollo en Python que permite la utilización de los pines GPIO. Gracias al
software, la Raspberry Pi resulta muy atractiva para desarrolladores.
El primer paso en la elaboración del software es poner en funcionamiento de
manera individual cada sensor. Debido a la plataforma escogida (Linux), las
llamadas librerías (software que permite al usuario acceder de forma sencilla a las
funciones del sensor) escasean. Esto forzó a usar el Arduino para la primera
versión, pero para la segunda versión, se decidió dedicar más tiempo y crear
librerías propias, o modificar las ya existentes.
El software del CanSat está diseñado para aprovechar la capacidad del
ordenador a bordo de ejecutar varios programas al mismo tiempo (multitasking). El
motivo de este diseño es debido a los problemas encontrados al portar el código
desde Arduino. A diferencia de Arduino, en Python un error significa la terminación
del proceso. Para solucionar este problema se utilizaron dos métodos:
1. Captar todos los errores e ignorarlos con la siguiente función:

try:
…
catch:
pass

Aprovechando el apartado de captar errores (catch), se puede incorporar

además los comandos que inician el sensor, de tal manera que, si el sensor se
desconecta, el programa intentará de manera indefinida reconectarlos lo que

20
 brinda la posibilidad de reconectar los sensores en caliente. Para evitar aún más
errores, dentro de la función catch se volvió a incluir una función try.
2. Independencia entre sensores, teniendo un programa único para cada sensor.
De esta manera si uno falla, no ocasionará ningún problema a los demás
programas. Aprovechando la capacidad de multitasking se puede además
mejorar la velocidad (hasta un cierto límite), ya que, si fuese un único programa,
tendría que ir sensor por sensor recogiendo los datos, ralentizando la recogida
de datos
Las desventajas de este diseño vienen a la hora de hacer que todos los
programas cumplan un objetivo conjunto. La solución más sencilla es un
programa encargado de controlar a los demás. Para la Burgoneta Espacial, el
programa encargado de recoger, enviar y guardar los datos fue también el
encargado de iniciar, controlar el estado y reiniciar los programas
independientes. Para transferir la información al programa principal se necesitó
de una base de datos (lugar en donde los datos se almacenan de forma que
sean accesibles al mismo tiempo desde diferentes localizaciones). Como no se
necesitó nada extraordinario, se utilizaron documentos .txt como simple forma
de almacenamiento temporal de datos. Este fue el sistema escogido debido a
que los archivos son fáciles de acceder, no requieren de ningún programa
externo y ocupan poco espacio en el disco. Un total de 7 documentos se usaron
como base de datos. El siguiente esquema corresponde al funcionamiento del
software del CanSat:

21
 3.1. Programa Principal
El programa principal se encargó de:

 Comprobar el estado de los sensores.

 Iniciar los programas individuales en base al estado de cada sensor.
 Controlar el estado de cada programa individual.
 Recopilar los datos desde la base de datos.
 Enviar la información procesada al transmisor de datos.
 Guardar todos los datos en un archivo.
El programa principal consta de tres partes, la primera de ellas entra en
acción cuando se enciende la Raspberry Pi. Este programa .sh está programado
para iniciarse automáticamente una vez el S.O. se inicia. Como algunos módulos
del programa pueden ocasionar problemas con el inicio, el programa esperará
hasta que se haya completado el inicio. Una vez hecho esto, ejecutará en un loop
la segunda parte escrita en Python de tal forma que si el proceso termina ejecutará
la tercera parte del programa. Esta tercera y última parte se encarga de limpiar los
procesos terminando todos aquellos con el nombre de “python” (para un reinicio
limpio). La segunda parte ejecutada realiza lo siguiente:
1. Importa las librerías necesarias: utilidades del sistema, operaciones complejas
de matemáticas y puerto serie.
2. El programa llama a la tercera parte la cual contiene una clase encargada de
comprobar sensor por sensor si se encuentran conectados y funcionando. Para
comprobar el estado de cada sensor se usaron los siguientes métodos:
a. Para los que usan el protocolo I2C, basta con leer las direcciones que hay
disponibles, ya que si un sensor no aparece en el listado es porque no
funciona.
b. Para el DHT, una simple lectura digital del pin al que está conectado
basta para determinar si funciona.
c. El GPS se comprueba leyendo a través del puerto serie. Si se recibe
algún dato es porque hay algo conectado que manda información.
3. Una vez realizadas las comprobaciones, la clase devuelve al programa principal
un numero comprendido por 7 dígitos, cada uno correspondiente a cada sensor.
Si el dígito es “1”, entonces el sensor funciona y por lo tanto se puede proceder
con el inicio del programa encargado del sensor. Por el contrario, si el dígito es
22
 “0”, el sensor presenta algún problema. En este último caso, el programa del
sensor no se iniciará, evitando así problemas en el inicio (si se inicia el programa
del sensor sin estar conectado conlleva a un bucle infinito en el que el programa
principal nunca completa el inicio). Esta línea es también enviada por el
transmisor de datos para ser recibida en la estación base.
4. El segundo paso es decidir que programas iniciar, y ejecutarlos en segundo
plano. Esto se realiza mediante el módulo subprocess de Python, el cual permite
la ejecución de otro programa en segundo plano sin interferir en el bucle del
programa principal. La ventaja de este módulo es la posibilidad de ejecutar
varios programas desde uno solo, además de que, si el servicio finaliza sin
haberlo autorizado, el módulo lo reiniciará. Es este módulo el que permite una
redundancia mucho mayor del sistema. Aun así, cada programa independiente
tiene la capacidad de recuperarse de un error por sí mismo.
5. Tras iniciar los programas independientes, esperará hasta que todos se inicien
correctamente. Y, por último, el programa pasa a un bucle, en donde realiza lo
siguiente:
a. Desde la base de datos, recoge los datos de cada sensor, siempre que
hayan dado positivo en el chequeo inicial. En caso contrario, pondrá los
valores como “0”.
b. Agrupa todos los datos que se van a enviar (exceptuando algunos datos
debido al límite del ancho de banda): localizador, hora, latitud, longitud,
altura GPS, velocidad horizontal, roll, pitch, yaw, humedad, temperatura,
presión, altura barométrica, velocidad vertical, CO2 ppm, UV1, UV2 y el
voltaje de la batería.
c. Comprueba la longitud de la variable a enviar, y le añade al final el número
que indica los dígitos totales de la variable a enviar.
d. Envía la variable a través del puerto serie.
e. Crea otra variable que une todos los datos recogidos de los sensores.
f. Guarda la variable en el documento de texto.
g. Espera 0.5 segundos para realizar de nuevo el bucle.
3.2. GY-91 (BMP280) y BME280
La librería del sensor barométrico y de temperatura fue modificada a partir
de la librería de Adafruit. Las modificaciones fueron las siguientes:

23
 Cambio de la dirección I2C, para cada uno de los sensores, creando dos
programas idénticos a excepción de la base de datos y la dirección I2C.
 Ampliación de los datos para incluir también velocidad vertical, que se calcula
usando el reloj del sistema (se almacena el tiempo y altura anterior, y calculando
los incrementos de alturas y tiempo se obtiene la velocidad vertical).
 Seguridad y la base de datos.
La rutina del programa es la siguiente:

 Los datos se recopilan en una única variable.

 El documento de la base de datos se borra entero.
 Se suben los datos al documento.
 Espera 0,5 s para iniciar de nuevo.
3.3. GPS (NEO 6M)
El GPS, fabricado por u-blox, envía la información a través del puerto serie.
Para ello, usa un sistema de comandos llamado NMEA (concretamente NMEA 0183
V2.1, creado por la National Marine Electronics Association). Este sistema tiene la
siguiente estructura:

Como se puede apreciar en la imagen, los comandos que el GPS envía

vienen encabezados por un identificador (address) que indica el tipo de datos. Los
datos vienen separados por comas. Y al final de la línea hay un checksum el cual

24
no sirve a ningún propósito, dado que el canal por donde circula la información tiene
muy poca probabilidad de que se produzcan errores.
Una vez conocido el sistema a usar, el siguiente paso fue determinar qué
datos son los relevantes: hora, latitud, longitud, altura y velocidad horizontal. Para
ello, las líneas relevantes son:
GGA – datos esenciales arreglados que proveen una localización 3D y datos
precisos.
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
Hora Latitud Longitud Satélites Altura

VTG – Velocidad arreglada.

$GPVTG,054.7,T,034.4,M,005.5,N,010.2,K*48
Velocidad (Km/h)
Como se puede ver, las coordenadas que usa el sistema NMEA no son las usadas
por Google Earth, por lo que hizo falta convertir de grados y minutos en un único
número a solo grados. La conversión es la siguiente:
Latitud:

4807.038,N → 48º 07.038' Norte = 40º + 07.038/60 Norte = 40.1173º * (1) =

40.1173º
Longitud:
01131.000,W → 11º 31' Oeste = 11º + 31/60 Oeste = 1.233333º * (-1) = -
1.233333º
En función de la dirección hay que multiplicar los grados por 1 (Norte y Este)
ó -1 (Sur y Oeste).
La rutina del programa encargado del GPS es la siguiente:
1. Comienza importando las funciones necesarias del sistema.
2. Inicializa todos los servicios a usar.
3. Comienzo del bucle:
a. Lee los datos del puerto serie hasta el final de línea.
b. Si los datos leídos empiezan con “$GPGGA”, entonces:
i. Separa los datos en variables independientes

25
 ii. Si la latitud no contiene datos, entonces eso indica que el GPS no
recibe aún señal, por lo que hace los datos “0” (en caso de que no
haya datos anteriores).
iii. Si la variable latitud contiene datos, entonces procesa los datos.
c. Si los datos leídos empiezan con “$GPVTG”, entonces:
i. Extrae la velocidad, y la convierte a metros por segundo
d. Junta los datos en una variable.
e. Borra la base de datos.
f. Sube los datos a la base de datos.
El GPS de u-blox de por defecto viene configurado para retransmitir toda la
información cada segundo. Como mucha de esa información es irrelevante, se
desactivó a través del software u-center para que solo enviase las dos líneas
anteriormente mencionadas, evitando ralentizaciones (distinciones entre las líneas
relevantes). Además, se aumentó la velocidad a 2 datos por segundo (un cálculo
cada 0.5 segundos).
3.4. ADS1115
Dado que los sensores analógicos fueron conectados a este ADC, se
encuentran agrupados bajo esta categoría. El programa que pone a funcionar el
ADC fue modificado a partir del escrito por Adafruit para que realizase las tareas
necesarias, aunque se necesitó un análisis superficial de su funcionamiento.
El ADS1115 envía las lecturas en números de 16 bits, por lo que el voltaje
se indica en números desde el 0 hasta el 65536 (216). Para obtener mediciones se
un rango de voltaje, de tal forma que ajustando ese rango se obtiene una mayor o
menor resolución. En la siguiente tabla se muestra el rango de voltajes a los que se
puede ajustar (FSR), además de la resolución correspondiente (LSB):

26
 Como el voltaje de salida del MQ135 puede alcanzar los 5V, el rango de
voltajes se ajustó a ±6.144 V. Como del sensor se recibe un número desde 0 hasta
65536 y se necesita el voltaje, hizo falta realizar la conversión con el siguiente
, ,
multiplicador: = 0,0001875. Este valor es el que se utiliza para obtener el

voltaje, ya que cada bit corresponde a 187.5 𝜇𝑉 como muestra la tabla anterior.
Una vez se tienen los voltajes, el siguiente paso es convertir el voltaje al valor
necesitamos de cada sensor:

 En el caso del MQ135, como se explicó anteriormente (2.3.2), se usó

el multiplicador de 4882,814.
 Los sensores de UV son mucho más sencillos, para obtener el índice
de UV basta con multiplicar el voltaje por 10.
 Como sobraba un pin analógico se decidió emplear en monitorear el
voltaje de la batería obteniendo así un porcentaje aproximado de la
energía restante. El procesado del porcentaje se realizaba en la
estación base. El CanSat solo enviaba el voltaje.
3.5. GY-91 (MPU9250)
El programa para controlar y obtener datos desde el MPU9250 es uno de los
más complicados. No solo por los cálculos que realiza para obtener los movimientos
de Roll, Pitch y Yaw, sino también por la complejidad del sensor en sí mismo.
Afortunadamente, un usuario de GitHub llamado Zenju Daisuke publicó su trabajo
sobre este sensor. No solo ponía el sensor en funcionamiento, sino que, además,
calculaba los tres movimientos necesarios. Los cambios realizados al código fueron
los siguientes:

 Como se explicó anteriormente, el sensor vino con el orden de los

datos alterado. Un simple cambio de orden en la recogida de datos
bastó para solucionar el problema.
 Se añadió la integración de la base de datos, así como la seguridad
del programa.
Una vez realizado los cambios, el sensor no volvió a dar problemas y
funcionó perfectamente en el lanzamiento, aunque seguimos a la espera de
recuperar los datos al completo que incluye mucha información recogida por el
MPU9250.

27
 3.6. APC220
El APC220 es el componente más sencillo de utilizar. La única dificultad se
encuentra a la hora de configurar la frecuencia y potencia. Para esto, hay que
conectarlo usando el adaptador que viene en el kit, y con el programa RF Magic se
ajustó la frecuencia a 434,88 MHz con la máxima potencia de 20mW. Lo único que
hay que hacer para comunicarse es mandar la información a través del puerto serie.
Lo complicado quizás de este sensor es la implementación de un sistema de
seguridad para determinar que los datos recibidos se encuentran al completo y que
no han sido alterados. Aunque el fabricante establece que el propio transceptor
tiene mecanismos internos para evitar alteraciones de los datos, en pruebas reales
se demostró que algún que otro cambio o pérdida se producían. Para evitarlo, se
desarrolló un sistema de seguridad que verificaba los datos (4.2) en la estación
base, dependiendo solo de que el CanSat contara el número de dígitos y lo añadiera
al final de cada línea.
El problema con este transmisor fue la cantidad de datos que pudo mandar
(ancho de banda), ya que, para un mayor alcance, la velocidad en el aire se tuvo
que bajar al mínimo (2400 baudios = 240 caracteres por segundo) sacrificando el
envío de los datos del segundo BMP280 y los datos completos del MPU9250
(magnetómetro, giróscopo y acelerómetro). Esto significó que al no recuperar el
CanSat se tuvo que trabajar con la información limitada que se recibió. A diferencia
de la velocidad en el aire, la velocidad del puerto serie se mantuvo en 9600bps
debido a que el GPS necesitó de esa velocidad.
3.7. DHT22
Este sensor de humedad y temperatura es tan barato y conocido que hay
millones de programas escritos para él. La librería usada fue la de Adafruit. El
programa se adaptó para que recogiese los datos cada 2 segundos (tiempo mínimo
entre medidas) y subiese sólo la humedad a la base de datos.
3.8. Raspberry Pi Camera
Para usar la cámara, hay dos opciones:

 Mediante una herramienta del sistema que pone todas las utilidades de la
cámara a través de un comando ejecutado en el terminal.
 Una completa integración de la cámara en Python, que pone todas las
utilidades en comandos ejecutados en Python.
28
 Si bien en un principio se decidió ir con la segunda opción, esta demostró
ser la errónea. Por algún motivo, tras varias horas de estar encendido, el programa
escrito en Python bloqueaba el sistema por completo, teniendo como única opción
que reiniciar el sistema manualmente. En cambio, la integración de la cámara a
través del terminal demostró ser muy estable en las pruebas. Por lo que se decidió
integrar el comando raspivid en Python.
Al igual que los programas independientes, el comando fue ejecutado
usando subprocess. El script encargado de la cámara se ejecutó de forma
independiente al programa principal. La línea que grababa y mostraba lo que la
cámara veía fue la siguiente:
“sudo raspivid -w 1920 -h 1080 -v -t 300000 -fps 30 -o /home/pi/Videos/" +
data + ".h264 –g"
sudo – Concede permisos de administrados al comando
raspivid – Comando a ejecutar
-w 1920 – indica la anchura del video a 1920 píxeles
-h 1080 – indica la altura del video a 1080 píxeles (Full HD)
-v – Saca toda la información de lo que está ocurriendo con la cámara
incluyendo una visualización en la pantalla, enviado a través de la salida de video
de la Raspberry Pi al transmisor de video.
-t 300000 – Graba un video por 5 minutos (300000ms = 300s = 5m)
-fps 30 – graba el video a 30 fotogramas por segundo
-o /home/pi/Videos/" + data + ".h264 – guárdalo en el directorio
/home/pi/Videos/ con nombre de la variable data y extensión .h264
-g – Una opción nueva que permite a fotogramas muy similares (como todos
negros) incluirse en uno solo ahorrando muchísimo espacio.
La integración de este comando en Python permitió también la opción de guardar
los videos con nombres diferentes. El nombre fue un número guardado en un
documento, recordando así el último nombre usado tras apagar el sistema. Muy
conveniente para no sobrescribir ningún dato de video.

29
 4. Estación base (Ground Station)
Para recibir los datos enviados por el CanSat se decidió desarrollar una
aplicación para Windows, de tal forma que procesara los datos en tiempo real
dibujando varios elementos con estos. Esta aplicación fue la parte del proyecto que
más tiempo consumió.
Para desarrollar la aplicación se utilizó el sencillo, pero no tan simple,
entorno de desarrollo llamado Processing. Este entorno usa su propio set de
comandos basados en Java, aunque también se puede programar en Java de
forma directa. Processing es fantástico para desarrollar interfaces gráficas debido
a su simplicidad de comandos gráficos, pero puede quedar escaso de utilidades si
se necesita ir más profundo. La aplicación pasó por muchas versiones, pero en este
documento solo se describe la última de ellas.
4.1. Hardware
La estación base constó de varias partes que juntas hicieron posible la
retransmisión de los datos de forma visual. El siguiente esquema describe el
funcionamiento general de la estación base:

Los datos se reciben por un canal diferente al del video. Es por eso que dos
antenas y dos receptores son necesarios. Para los datos se usó una antena tipo
Yagi de 433 MHz que iba conectada al receptor/transmisor APC220 (el mismo que
30
equipó el CanSat). El video fue transmitido por el CanSat en analógico a una
frecuencia de 5.8 GHz. Para recibir en un principio estaba planeado usar una
antena helicoidal, pero debido a las interferencias que la antena Yagi producía
(ambas iban colocadas una junto a la otra para apuntar bien), se hizo un cambio de
última hora sustituyéndola por una de tipo parche, también directiva. La antena fue
conectada al RC832, un receptor de 5.8 GHz con salida de video analógica.
El APC220 usa el protocolo serie como comunicación, para ello se conectó
a un FTDI (conversor de UART a USB), que conectado al ordenador permite extraer
los datos a través de un puerto COM (comunicación).
El RC832 fue conectado a una captura de video (EasyCap) que junto a un
decodificador de vídeo permitió ver en el ordenador el video enviado por la cámara
del CanSat.
4.2. Software
La parte más complicada de la estación base fue la aplicación escrita en
Java que se encargó de recoger los datos, procesarlos y dibujar una interfaz gráfica
sencilla (7.2.1). En este documento no se describe el funcionamiento al completo
ya que el código se encuentra comentado en el repositorio oficial. El funcionamiento
general del programa es el siguiente:
1. Los datos se reciben en el módulo de puerto serie de Java, el cual copia en una
variable todos los datos hasta el final de línea (“/n”). Esta variable es después
descompuesta en un array (conjunto) de variables tipo string (texto).
2. Para comprobar los datos, el programa compara el tamaño del array (número
de variables en el conjunto) con el que debería ser, además cuenta los
caracteres de la variable recibida y lo compara con el último número. Por último,
el identificador, o el primer dato debe coincidir con “@527” (datos) o “@173”
(diagnóstico de los sensores) usado para identificar los datos enviados por La
Burgoneta Espacial y no otro CanSat. Como se sabe que todos los datos han
de ser numéricos, una segunda comprobación convierte las variables de string
a float (numéricas), de tal forma que, si se convierte un dato no numérico, este
inducirá a error, momento en el que el programa cancelará el procesado de
datos (en este caso, se usarán los valores anteriores para continuar las
gráficas). Por último, una tercera comprobación va todavía más profundo. Como

31
 los datos del giróscopo oscilan entre 180 y -180, comprobar que el valor se
encuentra entre dichos valores da todavía más fiabilidad al test.
3. Una vez comprobados los datos el programa los utilizará para continuar las
gráficas, dibujar los velocímetros, el estado de los sensores, la capacidad de la
batería, la altitud, además de un horizonte artificial y una brújula.
4. Para una correcta localización temporal, el programa obtendrá la hora y fecha
desde el reloj del ordenador y la dibujará. Esto permite a futuros espectadores
localizar temporalmente el lanzamiento.
5. El programa además de lo descrito anteriormente consta de dos módulos:
a. El primero de ellos es una barra de progreso que permite al espectador
saber en qué fase del descenso se encuentra la retransmisión.
b. El segundo módulo más llamativo fue la integración de Google Earth a la
estación base, dibujando una trayectoria en tiempo real de la caída del
CanSat. El código original fue escrito y publicado por Andrew Herman.
Teniendo el concepto en mente, el código fue rescrito y adaptado
completamente para hacerlo más simple además de añadir varios
detalles más como la línea de la trayectoria, los colores, el icono de la
lata y el nombre indicando la velocidad horizontal.
El funcionamiento interno es el siguiente:
o Recoge los datos recibidos desde el GPS del CanSat. La latitud,
longitud y altura son importados a una variable que añade los datos a
los anteriores en el formato correcto y la velocidad horizontal
especifica el nombre.
o Cambia el ángulo de rotación de la cámara que observa la trayectoria
en 5 grados.
o Guarda toda la información en un formato concreto (para que la
aplicación Google Earth pueda interpretar) en un documento de
extensión .kml.
o Ejecuta el archivo a través de un terminal oculto usando el .exe de
Google Earth, lo que resulta en una importación en tiempo real de la
trayectoria que Google Earth dibuja sustituyendo la anterior. El ciclo
se repite cada vez que se recibe una línea nueva.

32
 Para decodificar el video proveniente de la capturadora EasyCap, se usó el
reproductor de video Media Player Classic, el cual permite reproducir el video en
directo desde una capturadora y guardarlo en un archivo.
La siguiente y última parte de la estación base consiste en la captura,
creación y retransmisión del video en directo. Para la realización de dichas tareas
se usó un programa llamado Open Broadcaster Software (OBS). Este programa
permite capturar ventanas de forma independiente, aplicar filtros tales como recorte
o color de fondo, y crear una pantalla independiente (pudiendo tener varias
intercambiables) la cual se retransmite a sitios web como YouTube.
Para retransmitir el video, OBS capturó:
1. El programa hecho en Java, que fue recortado en diferentes partes aplicando
filtros de transparencia.
2. Google Earth, recortando la ventana a solo la trayectoria.
3. La cámara web, que fue intercambiada manualmente por el vídeo recibido
del CanSat en los momentos en los que no se recibía nada.
4. Media Player Classic recortando la ventana a solo la reproducción del video
recibido.
Todas las partes se pusieron en orden en la aplicación ajustando la
resolución a 1920x1080 píxeles. Que junto a la imagen de fondo y el logo
conformaron lo que los espectadores visualizaron el día del lanzamiento (7.2.2).
4.3. Problemas
En las horas previas al lanzamiento se tuvieron varios problemas con la
retransmisión. Investigando se llegó a la conclusión de que el ancho de banda de
la conexión a Internet era inferior al esperado, ya que, al estar conectado con el
móvil en roaming la velocidad se vio reducida. La solución fue disminuir la calidad
del video enviado de 1080p a 720p, manteniendo la resolución de 1080p en la
creación del vídeo. Además de esto, se tuvo que reducir el bitrate (cantidad de bits
por segundo del vídeo).
Aunque el vídeo si se transmitía bien tras estos ajustes, seguía habiendo
pequeños parones. Tras analizar el espectro, se determinó que en un espacio tan
reducido como el hangar, y con tanta gente usando sus teléfonos como módem,
ocasionaba que las Wi-Fi transmitieran unas encima de otras, reduciendo
notablemente la velocidad. La solución fue cambiar la banda de Wi-Fi de 2,4GHz a
33
la menos ocupada de 5GHz. Con estos ajustes el video se retransmitió sin problema
alguno.

5. Resultados
De todos son conocidas las luces y sombras de los programas en Marte y la
suerte que las distintas misiones han corrido. Nuestro CanSat no iba a ser una
excepción y además de los fallos mecánicos que se explican a continuación, la mala
suerte quiso que el CanSat no pudiese recuperarse al caer sobre una zona
edificada ajena al aeropuerto.
Es ya evidente que los datos no se pudieron recuperar al completo lo que
deja, una lección muy importante: el coste de las misiones espaciales es alto, por
lo que cuando una situación como esta se presenta lo poco que se puede hacer es
aprovechar los datos y sacarles el máximo partido obteniendo la mayor cantidad de
parámetros y conclusiones posibles.
Siguiendo la lección, uno debe en este tipo de situaciones obtener una
conclusión, y hacer valer la inversión en el proyecto. Por muy lejos que estas se
encuentren de la realidad, al menos se sabe algo más sobre lo desconocido.

5.1. Fallos mecánicos

He de admitir que aun estando el CanSat diseñado para evitar el mayor
número posible de errores, sufrimos de igual manera fallos críticos en el día del
lanzamiento.
Dadas las condiciones climáticas del día del lanzamiento, se tuvo que
encapsular el CanSat. Usando un plástico flexible transparente, se dejó solo un
pequeño agujero para la entrada de aire del MQ135, así como para la antena GPS.
Esto supuso un enorme sacrificio en la precisión de los sensores.
El segundo de los errores fue la fiabilidad de los portapilas. Antes del
lanzamiento se realizaron múltiples pruebas de aceleración, y aun pasándolas la
aceleración del cohete provocó la desconexión de las mismas. El problema de los
portapilas fue, que al no saber bien la orientación del CanSat en el interior del
cohete se colocaron los muelles en la parte equivocada, provocando su compresión
durante el ascenso que desplazó las pilas desconectándolas de la chapa metálica

34
en el polo contrario. Afortunadamente, el CanSat estaba programado para
reiniciarse solo, perdiendo la mitad de los datos y un tercio del video.
El tercer error está basado en la hipótesis de que las tapas en de los
portapilas en el interior del CanSat saltaron al chocar lateralmente con el edificio
(probablemente debido al descuido de no soldar el plástico con super-glue),
provocando una pérdida de energía permanente. Esto trajo consigo la
consecuencia de no poder descargar los datos remotamente del CanSat, al ir este
equipado con Wi-Fi.
5.2. Misión primaria
Temperature & Altitude
La misión primaria de medir
250 38
temperatura fue un fracaso. El 200 37,5
150
CanSat equipó dos sensores de 37
100
temperatura. El primero de ellos 50 36,5

en orientación horizontal y el 0 36
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52
segundo junto a la entrada de aire.
Altitude Temperature
El error de no cambiar los datos
enviados al cercano a la única entrada de aire supuso malas mediciones de
temperatura. Confié además en la recuperación del CanSat, ya que la temperatura
de ambos sensores se guardaba. De los datos recibidos, la temperatura obtenida
fue demasiado alta, aunque cabe mencionar la disminución de la misma durante el
descenso. Muy probablemente indicando que la temperatura exterior es menor a la
interna del CanSat.
Por otro lado, la presión obtuvo buenas mediciones. Las mediciones del
barómetro coincidieron con las
del GPS, aun estando el Altura de GPS y barómetro
400 995
CanSat cerrado
990
300
herméticamente. La conclusión
MILIBARES

985
METROS

200 980
que se puede obtener es que la
975
presión es mucho más 100
970

susceptible que la temperatura 0 965

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52
a los cambios, ya que la LÍNEA RECIBIDA (0,5S)

regulación del medio interno es Altura GPS Altura Barómetro Presión

mucho más rápida.

35
 5.3. Misiones secundarias
5.3.1. Retransmisión en vivo
Esta parte del proyecto fue todo un éxito. Si bien nuestro proyecto no tuvo la
misma repercusión que un lanzamiento de la NASA, los más de 300 espectadores
durante la retransmisión fueron más de los esperados. Y junto con las más de 2000
visualizaciones posteriores, esta parte del proyecto fue un rotundo éxito.
El video fue mucho más entendible que el anterior. De hecho, muchos
espectadores se dieron cuenta del fallo en las baterías. Cabe destacar la trayectoria
en directo, que fue muy bien recibida.
5.3.2. Localización 3D
Las mediciones del GPS fueron muy precisas,
llegando hasta decímetros de precisión. Esto se sabe
tanto por el número de satélites que usó para el
cálculo de la posición (8 durante todo el descenso)
como por la ausencia de obstáculos que puedan
reflejar la señal. Esta precisión sirvió de ayuda para
determinar las alturas incluso con más precisión que
el barómetro, ya que este es mucho más preciso por
lo general que el GPS. La Burgoneta Espacial fue el
único CanSat capaz de mandar la información del GPS de forma precisa,
permitiendo una localización exacta del punto de caída, que por mala suerte fue el
porche de un almacén sin ningún método de acceso.
5.3.3. Mapa topográfico
Elaborar un mapa topográfico 3D con las imágenes recibidas resultó
imposible debido a la mala calidad del video recibido provocada por el sellamiento
hermético colocado en frente del objetivo de la cámara. Aun sabiendo el fracaso de

36
esta misión, se decidió intentar hacer una reconstrucción de la zona en 2D. Para
ello se extrajo fotograma a fotograma del video recibido, y desechamos los de mala
calidad se obtuvieron unas 20 imágenes, con ayuda del mapa desde Google Earth,
se fue ajustando la perspectiva a mano con Gimp reconstruyendo gran parte del
mapa. Aunque la calidad de las imágenes no fue la deseada, estas pueden servir
para determinar un buen lugar de aterrizaje para futuras misiones.
Como dato anecdótico, en la reconstrucción del mapa se determinó la
aparición de nuevas construcciones en la zona no presentes en el mapa de Google
Earth.
5.3.4. Determinar la posibilidad de vida
La misión más importante de La Burgoneta Espacial fue la de determinar la
posibilidad del planeta de sustentar vida basándose única y exclusivamente en los
datos recolectados por el CanSat.
Gravedad
La primera de las propiedades a determinar fue la aceleración de la gravedad
en la superficie del planeta. Esta es elemental en muchos aspectos para el
desarrollo de la vida, pero también esencial para la habitabilidad humana.
Se tenía previsto calcular la aceleración de la gravedad en los segundos
previos a la apertura del paracaídas, que corresponden con una caída libre.
Desafortunadamente, el CanSat se reinició en el ascenso, perdiendo el único
momento evidente. Tras mucho pensar e investigar se decidió calcular la gravedad
de una manera más enrevesada.
Lo primero que hay que tener en cuenta son las fuerzas que se aplicaron en
el CanSat durante su descenso:

37
 Como se puede apreciar, solo dos fuerzas afectaron al CanSat de manera
directa durante su descenso (despreciando todas las demás al ser mínimas o estar
en la normal del movimiento). La primera de las fuerzas es la de rozamiento, para
calcularla se puede usar la ecuación experimental de resistencia aerodinámica:

En donde Fr es la fuerza de rozamiento, v la velocidad en m/s a través del fluido, S

la superficie en m2 en contacto con el fluido de forma frontal y Cr el coeficiente de
rozamiento del objeto.

La densidad del fluido (en este caso atmósfera) no fue recogida por el
CanSat, al igual que la superficie y coeficiente de rozamiento (marcadas en rojo).
Pero al ser una ecuación experimental, y ser dependiente de la densidad, se puede
replicar el lanzamiento en otro fluido y obtener el coeficiente. En pruebas antes del
lanzamiento se determinó un coeficiente aproximado de 1,3 para los 0,1 m2 de
superficie (incluye también la base del CanSat). Lo único que queda entonces por
determinar es la densidad de la atmósfera.
Para calcular la densidad, se puede emplear la ecuación barométrica
obtenida a su vez de la ley de los gases ideales y las constantes moleculares:

En donde P es presión en Pa, 𝜌 la densidad en Kg/m3, g gravedad en m/s2 y h la

altura en m

Con esta ecuación se puede obtener la densidad, pero requiere además

de la gravedad, el incremento de presión y la altura real. Sabiendo que el CanSat
descendió 175,4 m en 27 segundos momento en el que la presión aumentó 1624
Pa, queda por saber la densidad y la gravedad.

38
Para resolver el problema, hay que fijarse en las alturas enviadas por el CanSat:

Vertical Speed & Altitude

250 8
7
200
6

150 5
4
100 3
2
50
1
0 0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51

Series1 Series2

Como se puede apreciar la velocidad fue aproximadamente constante de 6,5 m/s

(las variaciones entran dentro de la imprecisión del GPS), lo que significa que el
descenso fue controlado. La no disminución o aumento de la velocidad implica que
la fuerza de reacción (rozamiento) fue equivalente a la fuerza de la gravedad,
siendo esa la velocidad equilibrio. Ahora sí, sabiendo que la masa del CanSat fue
de 0,3 Kg se puede convertir a una aceleración la fuerza y realizando un sistema
de ecuaciones se resuelven las dos incógnitas (gravedad y densidad de la
atmósfera):
𝐹 =𝐹 =𝑚·𝑔;

1 ∆𝑃
·𝜌·𝑣 ·𝑆·𝐶 =𝑚· ;
2 𝜌 · ∆ℎ
1 𝑚 1624 𝑃𝑎
· 𝜌 · 6,5 · 0,1 𝑚 · 1,3 = 0,3 𝐾𝑔 · ;
2 𝑠 𝜌 · 175,4 𝑚
𝜌 = 1,006 Kg/m3
∆𝑃 1624 𝑃𝑎
𝑔= = = 9,21 𝑚/𝑠
𝜌 · ∆ℎ 1,006 𝐾𝑔
𝑚 · 175,4 𝑚
Ambas son similares a las de la Tierra de 𝜌 =1,2 Kg/m3 y 𝑔 =9,8 m/s2, lo que
indica que son adecuadas para sustentar vida, pero sobre todo , correctas para ser
habitado el planeta por humano.

39
 Atmósfera
Una vez obtenida la densidad de la atmósfera (en la superficie), usando la
ley de los gases ideales, con la presión media de 98273 Pa, la temperatura
registrada de 310 K y la constante correcta, se puede calcular la masa molar de la
atmósfera:
·
, · , · 𝐾𝑔 𝑔
·
𝑚 = = = 0,0264 𝑚𝑜𝑙 = 26,4 𝑚𝑜𝑙
𝑔
La masa molar es similar también a los 28.7 𝑚𝑜𝑙 de media en la Tierra.
Una vez que tenemos la masa molar, junto a la temperatura podemos
determinar aproximadamente qué gases pueden componer la mezcla del aire en el
planeta (si es que es una mezcla). De la tabla periódica el Hidrógeno, Nitrógeno,
Oxígeno, Flúor, Cloro y todos los gases nobles son gases a la temperatura de 37ºC
registrada por el CanSat. La mezcla es mucho más difícil de determinar, pero desde
luego, la probabilidad de que haya Oxígeno en la atmósfera es alta. Para futuras
misiones sería bueno incluir un sensor de oxígeno para determinar el porcentaje en
la atmósfera.
Volviendo a la masa molar, sabiendo que la mayoría de los elementos
dañinos para el ser humando tienen una mayor masa molar, exceptuando el flúor y
cloro. En cualquier caso, su masa molar en estado gaseoso es mucho mayor a la
obtenida, asegurando que su concentración es poca en la mezcla o que incluso no
se encuentran presentes.
El sensor de CO2 midió también gases contaminantes como hidrocarburos.
Su medición media de 303,51 ppm nos indica que la concentración de estos gases
no es nula. Como a partir de este punto no se puede determinar ningún dato fiable,
podemos suponer que gran parte de medición corresponde con CO2 al ser este uno
de los compuestos más comunes en otros planetas, y, sobre todo, que el sensor es
más sensible a este gas. Si el CO2 se encuentra presente, entonces es probable
que se produzca el efecto invernadero en el planeta, muy importante para la vida.
HASTA AQUÍ
Agua
El agua es vital para la vida. Cuando se descubre un planeta nuevo, la
primera pregunta es siempre la misma, ¿hay agua líquida en la superficie? El

40
CanSat incorporó un sensor de humedad, cuyo objetivo fue el de medir la presencia
en la atmósfera y no la cantidad. Las mediciones de 5,5% de humedad relativa
implican que en la atmósfera si existe vapor de agua, pero al no saber exactamente
las propiedades del aire, no se puede determinar la concentración. Una vez
conocido la presencia del agua, lo relevante no es su estado gaseoso, sino el
líquido. Usando la temperatura de 37 ºC y presión de 982 hPa se puede aproximar
el estado predominante del agua en la superficie del planeta:

Para el planeta visitado, el punto se situa dentro del triángulo triple de los
tres estados, indicando que, aunque su mayor concentración sea en forma líquida,
también puede presentarse en forma de vapor y sólida, que confirma el sensor de
humedad. El planeta es muy probable que tenga presencia de agua líquida, lo que
lo convierte en un muy buen candidato habitable.
Campo magnético
Otro factor muy importante para la vida es la presencia de un campo
magnético en el planeta. Como sucede en la Tierra, el campo magnético atrapa a
partículas cargadas provenientes del Sol (Viento Solar) en el llamado cinturón de
Van Allen. Esto es muy importante, ya que su ausencia provocaría la extinción de
la biología tan y como la conocemos. El CanSat equipó un magnetómetro para
determinar la intensidad del campo magnético en tres ejes. Desafortunadamente la
intensidad del campo magnético no se obtuvo debido al límite de datos enviados.

41
Aun así, si se recibieron datos de la brújula, obtenidos a partir de la intensidad del
campo magnético. Y al mostrar esta una determinación por una dirección concreta,
indica que en este planeta en cuestión si existe un campo magnético, del que se
desconoce su intensidad.
Radiación UV
La radiación UV es un factor muy importante para la habitabilidad humana
en la superficie. Las mediciones de radiación UV del sensor sin protección (UVA +
UVB + UVC) mostraron picos de 1,4 en el índice UV, lo cual es insignificantes al
encontrarse estas dentro del rango bajo (un día soleado en la tierra puede alcanzar
10 o incluso más en el índice de UV).

UV
1,6
1,4
1,2
1
0,8
0,6
0,4
0,2
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55

UV UVA+UVB UVC

El UVC es el espectro más dañino al ser las ondas más energéticas. El

CanSat calculó el UVC haciendo la diferencia entre el sensor sin filtro y con filtro.
Las mediciones de UVC fueron de aproximadamente 0,5 en el índice de radiación
UV que es igual a aproximadamente 12 mW/m2. Poca información hay sobre los
valores máximos de radiación UVC, pero la media en la Tierra en pleno día soleado
es de 200 mW/m2. Según un estudio de 26 personas expuestas a grandes dosis de
radiación UVC, alrededor de 1400 mW/m2 serían dosis letales a largo plazo. Si bien
los estudiantes sufrieron quemaduras entre otros síntomas, después de dos a
cuatro días se recuperaron. Esto demuestra que dosis de alrededor y más de 1400
son cancerígenas para el ser humano, pero no letales si es durante un pequeño
periodo de tiempo. Por lo que, según las medidas obtenidas por el CanSat, el
planeta presenta algún tipo de protección contra la radiación UVC en la atmósfera,
haciendo posible la habitabilidad sin una capa protectora.
42
 Conclusión
Esto es lo máximo que se pudo concluir a partir de los datos recibidos, que,
aunque no son suficientes para determinar la habitabilidad del planeta, sí que son
indicadores que este planeta es de momento un muy buen candidato para sustentar
vida, ergo futuras misiones a este planeta es muy probable que ocurran.

6. Resultado del concurso y conclusiones

En ningún momento se tuvo claro la posibilidad de presentar el prototipo el
día del lanzamiento, ni mucho menos ganar el concurso. La semana anterior, no
había ningún prototipo montado, teniendo inacabado el diseño de la lata y el
software de la estación base. El tiempo disponible para desarrollar el CanSat fue
escaso, ya que se perdió mucho tiempo ideando el proyecto. Una mayor dedicación
habría supuesto un diseño más elaborado al permitir la realización de la muy
importante fase prueba-error, cuya ausencia mostró más tarde sus consecuencias.
Al no tener el CanSat montado, la tensión durante los primeros días del
concurso y el ajustado horario conllevaron a múltiples errores:

 El mal montaje de los portapilas. El diagnóstico del sistema enviado tras el

reinicio indicó el perfecto funcionamiento de todos los sensores, lo que implica
que el CanSat se reinició debido a la desconexión de las pilas durante el
ascenso, perdiendo así una gran suma de datos importantes. Los muelles se
colocaron en la parte incorrecta, lo que provocó la desconexión del polo opuesto
durante el ascenso al comprimirse estos debido al peso de las pilas. Aunque se
puede considerar un problema, el reinicio fue satisfactorio sirviendo como
demostración del correcto diseño del Software.
 El fallo mecánico del circuito de apagado selectivo para el transmisor de video,
obligando a la permanentemente conexión del transmisor de video, acortando
la vida útil del CanSat y generando una gran cantidad de calor en el interior del
CanSat, que a su vez provocó las malas mediciones del sensor de temperatura.
 Mal encaje de la tapa inferior y mala distribución de los componentes en el
interior provocando tensión en la tapa superior. Esto hizo que el tamaño fuese
más de lo permitido. Ambos se solucionaron acortando los muelles.

43
 El descuido de no pegar las tapas de los portapilas, desconectando las pilas en
el momento del aterrizaje haciendo imposible recuperar los datos
inalámbricamente mediante Wi-Fi.
Otros problemas vinieron a raíz de sellar herméticamente el CanSat para
evitar cortocircuitos con la lluvia:

 Nula regulación del medio interno del CanSat, provocando las malas mediciones
del sensor de temperatura y humedad.
 La mala calidad de la cámara de video al poner el plástico por encima de esta.
Respecto a los aciertos, cabe mencionar:

 El software de la estación base, que demostró ser fiable y funcionar de manera

correcta. Un posterior análisis del video retransmitido a través de YouTube
demostró que todo, a excepción de unos pequeños errores con las unidades y
la primera gráfica, funcionó de manera correcta.
 Respecto al hardware del CanSat, todos los sensores funcionaron
perfectamente y el diseño demostró ser robusto y resistente. El único problema
fue el DHT22, cuyas mediciones no coinciden con las medidas por otros
equipos. El calor pudo ser el responsable de tan bajas mediciones, pero hasta
que no se recuperen los datos del CanSat, no hay forma de averiguar qué lo
provocó.
 De los datos recibidos cabe mencionar que desde el reinicio se recibieron todos
los datos enviados por el CanSat exceptuando una única línea, demostrando el
correcto funcionamiento de las antenas.
Como puntos negativos destacan:

 El lugar de aterrizaje. Aunque a fecha de este documento no se ha recuperado

el CanSat, se espera poder recuperarlo en algún momento, no por los datos,
sino más bien como recompensa del trabajo realizado. La tarjeta SD en donde
se guardó la información es resistente tanto al agua como al calor.
 Las conclusiones presentadas al jurado. Cabe mencionar que lo redactado en
este documento es una revisión mucho más exhaustiva, y las conclusiones
presentadas al concurso no fueron las mismas. Se cometieron errores debido al
poco margen de tiempo, presentando así información incorrecta o mal
explicada.

44
 Aunque el jurado no expuso los motivos que nos llevaron a ganar, a mi
parecer fueron los siguientes:
- Un modelo robusto que sobrevivió las condiciones medioambientales del día.
Así como a la pérdida de energía en el lanzamiento.
- La ayuda que ofrecimos a otros equipos, aunque supusiera darles ventaja
además de agradecer a aquellos equipos que nos ayudaron.
- La recuperación hábil de datos aún sin recuperar físicamente el CanSat.
- El intento en la presentación de llegar a conclusiones coherentes en el tiempo
que se tuvo la noche anterior, así como el intento de hacer un mapa topográfico
con las fotos recibidas del CanSat aun sabiendo el fracaso de la misión.
- La innovadora idea de retransmitir el momento en vivo haciendo accesible el
proyecto a cualquiera.
- La increíble precisión del lugar de aterrizaje, al ser el único equipo cuyo GPS
funcionó de manera correcta. Esto es debido a que todos vienen con un límite
de aceleración, si lo sobrepasan se apagan. Tuvimos la suerte de que el GPS
escogido se reiniciaba tras la aceleración, lo que nos dio una gran ventaja sobre
aquellos que se apagaron permanentemente.
Los datos que recibimos se encuentran en un documento disponible en
nuestra web (https://burgosat.tk), y los videos relevantes en el canal de YouTube
(https://goo.gl/drFxu1). En caso de necesidad de algún dato concreto, contacte al
correo: efren@boyarizo.es

7. Anexos
7.1. Protocolos
7.1.1. Inter-Integrated Circuit (I2C)
El I2C es un protocolo muy usado para la comunicación entre pequeños
componentes. Necesita tan solo dos cables (SDA y SCL) para comunicarse (a parte
de la alimentación). Funciona de la siguiente manera:

45
  Hay un maestro quien controla todos los sensores y por lo tanto controla el
SCL que corresponde con el reloj, que transmite los pulsos correspondientes
con la frecuencia del envío de datos. De esta manera se sincronizan el
cliente y maestro para recibir y enviar la información, lo que permite el uso
de varias velocidades para componentes conectados a una misma línea.
 Por el cable SDA se manda la información. Cada componente usa una
codificación diferente para los datos, normalmente detallada en el datasheet.
El funcionamiento del protocolo se explica mejor con un ejemplo: se quiere
recibir un número de un sensor, correspondiente con el voltaje. Para ello, lo primero
es bajar el voltaje del cable de datos, que indica el principio de una comunicación.
Acto seguido, el voltaje varía en base a si es un 1 o 0, siempre sincronizado con las
oscilaciones del reloj.
El primer dato que se envía es la dirección, como si fuese la calle en la que
vive el sensor. Esta dirección es un número de 7 bits que se convierte a
hexadecimal para ser leído con mayor facilidad por el usuario. En el caso del GY-
91, el MPU9250 tenía la dirección 0x68 (los dos primeros dígitos no tienen utilidad
alguna para el usuario y los dos últimos indican en hexadecimal la dirección).
Después de la dirección se indica con un 1 que se va a leer. Acto seguido se baja
el SCL y se vuelve a subir indicando el comienzo de la transferencia de datos, es
aquí donde el sensor nos mandará el dato en binario. Al ser un único número, el
byte se convierte a decimal para ser leíble. Este es un ejemplo muy simple, y en la
realidad cada sensor incorpora una forma diferente para obtener la información.

46
 En los datasheet se puede encontrar información muy detallada de cómo
manejar el protocolo para un sensor concreto. Afortunadamente, la comunidad de
Arduino ofrece una posibilidad mucho más sencilla, el uso de librerías. Estas
librerías incorporan todas las funciones del sensor de manera que sean mucho más
accesibles al usuario.
7.1.2. Comunicación Serie (8N1)
El protocolo serie consta dos cables (además de la alimentación), uno para
transmitir y el otro para recibir información. A diferencia del protocolo I2C, en este
la velocidad se tiene que ajustar manualmente en ambos componentes, pero a
cambio permite trasmitir información al mismo tiempo en ambas direcciones sin
necesidad de identificaciones o secuencias de peticiones. Como aspecto negativo
se sacrifica la posibilidad de conectar más de un dispositivo (suele usarse solo para
comunicación entre dos dispositivos). La versión 8N1 usado en el CanSat (y la
mayoría de Arduinos), consta de un funcionamiento relativamente sencillo.
Imaginemos que se quiere enviar la letra O en mayúsculas y la letra K también en
mayúsculas. El primer paso es convertirlos a binario:
O → 01001111
K → 01001011
Para enviar la información solo se tiene que añadir dos caracteres, uno que
indica el inicio de cada byte que es siempre un 0 y otro que finaliza el byte y es
siempre un 1. En el osciloscopio se vería de la siguiente forma:

47
 Cuando la línea está en reposo, en esta versión el voltaje se mantiene alto.
La mayoría de los microprocesadores actuales incorporan en su interior lo que se
denomina un puerto serie por hardware. Esto no es más que un pequeño módulo
añadido al procesador para hacer el protocolo mucho más sencillo- de usar y sin
consumir muchos recursos, los microcontroladores y el CPU de la Raspberry Pi
incorporan lo que se denomina puerto serie por hardware. Esto no es más que un
módulo integrado en el interior del circuito integrado que se encarga de manejar el
protocolo liberando al CPU de esta tarea. Algunos incluso poseen un búfer en
donde se almacena los datos recibidos hasta que son solicitados.
El puerto serie se puede recrear por Software, pero requiere que el
procesador esté atento en todo momento para leer la información, lo que provoca
una carga innecesaria si se posee puerto serie por hardware.
7.2. Imágenes

48
49
 7.3. Código
Por problemas de espacio y formato, este anexo se encuentra en el
repositorio oficial de la Burgoneta en GitHub:
https://github.com/efrenbg1/Burgosat

8. Bibliografía
Protocolos
Serie: https://learn.sparkfun.com/tutorials/serial-communication
NMEA: http://www.gpsinformation.org/dale/nmea.htm
I2C: https://www.luisllamas.es/arduino-i2c/

Datasheets
ADS1115: http://www.ti.com/lit/ds/sbas444c/sbas444c.pdf
BMP280: https://cdn-shop.adafruit.com/datasheets/BST-BMP280-DS001-
11.pdf
BME280: https://cdn-shop.adafruit.com/datasheets/BST-BME280_DS001-
10.pdf
MPU9250: https://www.invensense.com/wp-content/uploads/2015/02/PS-
MPU-9250A-01-v1.1.pdf
MQ135: https://www.olimex.com/Products/Components/Sensors/SNS-
MQ135/resources/SNS-MQ135.pdf
APC220:
http://image.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf
Raspberry Pi Zero: https://cdn-
learn.adafruit.com/downloads/pdf/introducing-the-raspberry-pi-zero.pdf
u-blox NEO 6: https://www.u-
blox.com/sites/default/files/products/documents/NEO-6_DataSheet_(GPS.G6-HW-
09005).pdf
DHT22:
https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf
UV: https://cdn-shop.adafruit.com/datasheets/1918guva.pdf
LM2575: https://www.onsemi.com/pub/Collateral/LM2575-D.PDF
50
 LM7805: https://www.sparkfun.com/datasheets/Components/LM7805.pdf

Código
MPU9250: https://github.com/d-zenju/mpu9250
BMP280 y BME280: https://learn.adafruit.com/using-the-bmp085-with-
raspberry-pi/using-the-adafruit-bmp-python-library
ADS1115: https://learn.adafruit.com/raspberry-pi-analog-to-digital-
converters/ads1015-slash-ads1115
DHT11/22: https://learn.adafruit.com/dht-humidity-sensing-on-raspberry-pi-
with-gdocs-logging/software-install-updated
Raspberry Pi Camera:
https://www.raspberrypi.org/documentation/usage/camera/raspicam/raspivid.md
Google Earth kml:
https://developers.google.com/kml/documentation/?hl=es-419

Investigaciones
https://www.ncbi.nlm.nih.gov/pubmed/17205632

Principios físicos
https://es.wikipedia.org/wiki/Ley_de_los_gases_ideales
https://en.wikipedia.org/wiki/Drag_(physics)
http://hyperphysics.phy-astr.gsu.edu/hbasees/Kinetic/barfor.html

Otros links
https://processing.org/
https://stackoverflow.com/

9. Agradecimientos
Me gustaría agradecer a todos aquellos que ayudaron de alguna manera u otra a
hacer posible este proyecto. Especialmente a:
51
 Carmen Méndez Martín por ser la directora del proyecto y ayudándome en
todo.
 Mis compañeros por haber trabajado tan duro. Nada habría sido posible sin
su trabajo. Y por dejarme realizar este trabajo de un proyecto conjunto.
 Francisco Viñas, dedicando muchas horas de su tiempo libre en hacer
posible este proyecto.
 Ventura que sacrificó su cuadricóptero por el bien de este proyecto.
 Eugenio que corrió en el último momento para comprar componentes
minutos antes de que cerraran la tienda.
 Enrique que se quedó con nosotros en aquellas interminables tardes
ayudando en lo necesario.
 Javier Machón, por dejarnos en las clases de lengua probar el CanSat y
corregirme ortografía y sintaxis del proyecto.
 También quiero agradecer a la dirección del centro por mostrar ese apoyo,
que consiguió que saliésemos adelante.
 Gracias a todas las empresas, asociaciones y especialmente al
ayuntamiento por apoyarnos, aun siendo un equipo tan pequeño y poco
conocido.

52
 Pero sobre todo agradecer a la Agencia Espacial Europea por dedicar tiempo
y esfuerzo a organizar este tipo de proyectos que impulsan a muchos estudiantes,
confiando siempre en la posibilidad de un futuro mejor.
También quiero agradecer personalmente a aquellos programadores que
compartieron su código a través de internet. Zenju Daisuke por el código del
MPU9250 y a Andrew Herman por el ejemplo de integración de Google Earth en
Processing. Y especialmente a la comunidad de stackoverflow y Processing fórum
por esas soluciones a cualquier duda existente.

53