Proyecto educativo · Misión 2026 
Cómo se construye y sobrevive a la estratosfera
El 26 de mayo de 2026, una sonda basada en ESP32 alcanzó los 25.527 metros transmitiendo telemetría por LoRaWAN. Esta es la otra mitad de la historia: el hardware, los sensores y el firmware que hicieron posible cada uno de esos datos.
Esta página cuenta cómo está hecha la sonda. Si buscas qué ocurrió durante el vuelo —la reconstrucción dato a dato, el reproductor interactivo y la física del ascenso y el burst—, está en Un globo sonda en la estratosfera, reconstruido dato a dato ↗.
Del sensor físico al análisis de datos
La sonda es el primer eslabón de una cadena más larga. Un dato nace en un sensor a bordo, viaja por radio de largo alcance hasta la nube, se procesa, se almacena y termina convertido en conocimiento. Cada bloque es una pieza estándar de la industria; el reto está en encajarlas para que funcionen a −52 °C y 25 km de altura.
& red
& análisis
Esta página se detiene en los dos primeros eslabones —los que van a bordo del globo—. Todo lo que ocurre a partir de Node-RED (el procesado, la reconstrucción de los tramos sin GPS y el reproductor de la misión) se cuenta en la página del vuelo.
Una placa que ya lo trae casi todo
El núcleo es una Heltec HTIT-Tracker V1.2: en una sola placa del tamaño de un pulgar integra el microcontrolador, la radio y el GPS. Elegir una placa integrada en lugar de cablear tres módulos sueltos reduce peso, puntos de fallo y consumo —tres cosas que importan mucho cuando el sistema tiene que volar con batería y sobrevivir a su propio aterrizaje.
Tres chips, una placa
- ESP32-S3 — el microcontrolador. Doble núcleo, mucha memoria y periféricos de sobra para leer sensores y gestionar la radio sin despeinarse.
- Semtech SX1262 — el transceptor LoRa. Es quien pone los datos en el aire a decenas de kilómetros con apenas unos milivatios.
- UC6580 — el receptor GNSS multiconstelación, con su antena de parche integrada. La posición y la altitud del vuelo salen de aquí… hasta que la normativa se interpone.
El software se construye con PlatformIO sobre el framework
Arduino, apoyándose en cuatro librerías: RadioLib 7.3.0 para la pila
LoRaWAN, TinyGPSPlus para interpretar las tramas del GPS, y los drivers
del MS5611 y el MAX31865 para los sensores.
Un detalle que cuesta descubrir: el TCXO
La radio no arrancaba de forma fiable hasta dar con un parámetro poco evidente. El SX1262 de esta placa usa un oscilador compensado en temperatura (TCXO) que necesita una tensión de alimentación concreta, y hay que declarársela al inicializar la radio. Con el valor por defecto la radio simplemente no sincroniza.
// La inicialización de la radio, con el TCXO declarado explícitamente radio.begin( 868.1, // frecuencia (MHz) 125.0, // ancho de banda (kHz) 9, // spreading factor 7, // coding rate SYNC_WORD_PRIVATE, 10, // potencia (dBm) 8, // preámbulo 1.8 // ← tensión del TCXO: el cambio clave );
Es el tipo de detalle que no aparece en los tutoriales y que puede costar días: todo el código es correcto, pero el hardware no responde porque el oscilador de referencia no arranca.
La placa expone los pines del ESP32-S3 directamente, así que quedan libres un segundo bus SPI y un bus I²C para colgar sensores externos sin tocar la radio ni el GPS. Sobre esa base se añaden los dos sensores que definen el perfil científico del vuelo: presión y temperatura.
Dos sensores, tres magnitudes críticas
Sobre el bus I²C libre va un sensor de presión; sobre el segundo bus SPI, uno de temperatura. Entre los dos aportan las tres magnitudes que definen el perfil científico del vuelo: presión atmosférica, temperatura exterior y temperatura interior de la caja.
MS5611 — la presión que salvó la altitud
El sensor barométrico MS5611 mide presión con un ADC de 24 bits. Es el sensor más importante del vuelo por una razón que se entiende del todo en la página del vuelo: cuando el GPS se congeló por encima de los 18 km, la presión siguió midiéndose sin interrupción, y fue ella quien permitió recuperar la altitud del apogeo mediante la fórmula hipsométrica.
La clave estuvo en elegir el sensor con rango suficiente. El BMP280 que se probó primero solo es fiable hasta unos 9 km de altitud equivalente; el MS5611 llega hasta los ~31 km. Sin ese margen no habría dato de presión en el tramo más interesante del vuelo, y la reconstrucción habría sido imposible.
Se configura en sobremuestreo máximo (OSR_ULTRA_HIGH): el sensor promedia internamente muchas conversiones
por lectura, reduciendo el ruido a costa de tardar algo más. Con un muestreo cada
3 segundos, ese tiempo extra sobra.
Además de la presión, este sensor aporta la temperatura interior de la caja —va montado dentro—, que resultó valiosa para comprobar cuánto protegía el aislamiento frente al frío exterior.
| Bus | I²C · 0x76 |
| SDA | 17 |
| SCL | 18 |
| Resolución | ADC 24-bit |
| Sobremuestreo | OSR_ULTRA_HIGH |
| Rango útil | ≈ 10–1200 hPa |
| Techo equiv. | ≈ 31 km |
| Aporta | presión + temp. interior |
El módulo GY-63 que lo aloja tiene un pin PS que no existe en el
BMP280: hay que llevarlo a 3V3 para forzar el modo I²C. Sin esa conexión, el
sensor sencillamente no responde.
MAX31865 + PT100 — los −52 °C de la tropopausa
La temperatura exterior se mide con una sonda PT100: una resistencia de platino cuyo valor cambia de forma muy predecible con la temperatura. Es el patrón industrial cuando se quiere precisión y un rango amplio, muy por encima de lo que da un sensor integrado barato —y aquí hacían falta ambas cosas, porque se esperaban temperaturas por debajo de −50 °C.
Leer una PT100 con exactitud no es trivial: la variación de resistencia es diminuta. De eso se encarga el MAX31865, un convertidor dedicado que compara la resistencia de la sonda contra una referencia de precisión de 430 Ω (el «431» serigrafiado en la placa) y entrega el valor ya digitalizado.
| Señal | Pin ESP32-S3 |
|---|---|
| CS | 4 |
| SCK | 5 |
| MISO (SDO) | 6 |
| MOSI (SDI) | 7 |
Un segundo bus SPI, por hardware. El bus SPI principal del ESP32-S3 ya lo ocupa la radio SX1262 (pines 8–14). El MAX31865 cuelga de un segundo controlador SPI físico del chip (HSPI), configurado sobre los pines 4–7. Así sensor y radio no se estorban jamás, y se conserva la velocidad del SPI por hardware.
PT100 en 2 hilos. El montaje final quedó en configuración de dos hilos. La de tres hilos compensa automáticamente la resistencia del cableado y es preferible cuando la sonda va lejos de la placa; en este caso, tras las pruebas se optó por la de dos hilos, más simple de cablear. Con un cable corto la diferencia es pequeña, y cualquier desviación residual es un desplazamiento sistemático fácil de corregir en calibración.
El mapa completo de conexiones
Con la radio, el GPS y los dos sensores, casi cada pin del ESP32-S3 tiene un trabajo asignado. Este es el reparto final —útil si alguien quiere replicar el montaje:
| GPIO | Función | Bloque |
|---|---|---|
| 1 | Lectura ADC de batería | Alimentación |
| 2 | Activación del divisor | Alimentación |
| 3 | VEXT CTRL (alimenta el GNSS) | GNSS |
| 4 | CS | MAX31865 |
| 5 | SCK | MAX31865 |
| 6 | MISO | MAX31865 |
| 7 | MOSI | MAX31865 |
| 8–14 | NSS · SCK · MOSI · MISO · RST · BUSY · DIO1 | LoRa SX1262 |
| 17 | SDA | MS5611 |
| 18 | SCL | MS5611 |
| 33 | RX (NMEA) | GNSS · UART1 |
| 35 | RST | GNSS |
No todos los pines son libres. Los GPIO 8–14 están ligados a la SX1262 interna, y los GPIO 19–20 son las líneas USB D−/D+: usarlos por error para I²C corrompe la comunicación con el equipo. El reparto de arriba esquiva esas trampas.
El GPS que se apaga a 18 km por ley
El reto técnico más peculiar del proyecto no es de hardware ni de software: es normativo.
Por un acuerdo internacional conocido como límite COCOM, los receptores GNSS civiles dejan de dar posición por encima de unos 18 km de altitud (combinado con alta velocidad). Es una salvaguarda histórica pensada para que un GPS comercial no pueda guiar un misil balístico. El chip UC6580 de la placa la aplica sin excepción.
El efecto durante el vuelo fue exactamente ese: al superar los 18 km, el receptor mantuvo un estado aparentemente «válido» pero congeló su última posición —justo en el tramo del apogeo y el burst—. El indicador que delató el bloqueo fue el número de satélites, que cayó a cero.
Cómo se recuperó la altitud y la trayectoria de ese tramo ciego —con la fórmula hipsométrica anclada a presión y una curva de Bézier para el recorrido horizontal— se cuenta en detalle en la página del vuelo.
La solución de hardware para el futuro
Aquí hay un matiz que descubrí investigando, y que merece contarse porque es contraintuitivo: en muchos módulos el techo de 18 km no es una barrera física, sino un parámetro de software. Los receptores u-blox modernos permiten seleccionar un «modelo dinámico» de vuelo; poniéndolo en modo aeronáutico se desbloquea la operación hasta los 50 km.
En un u-blox, basta con configurar dynModel = 6 (Airborne <1g) mediante
el comando UBX-CFG-NAV5 para elevar el techo a 50 km. El UC6580 de este
proyecto, en cambio, no tiene un comando equivalente documentado: por eso el plan de
evolución pasa por sustituirlo por un u-blox NEO-M9N.
Para este primer vuelo, la estrategia fue pragmática y con red de seguridad: usar el UC6580 para el seguimiento fiable de tierra a 18 km, y aceptar que el tramo alto se reconstruiría después con los datos de presión. Funcionó.
Como respaldo totalmente independiente del sistema principal, la sonda llevó también un rastreador SPOT por satélite, que reporta posición cada pocos minutos por su propia red y no depende ni del GPS de a bordo ni del enlace LoRa. Una segunda vía para no perder nunca el rastro del payload, sobre todo de cara a la recuperación.
Firmware modular: cada fichero, una responsabilidad
El código está escrito en C++ sobre Arduino y PlatformIO, dividido en módulos pequeños con una sola responsabilidad cada uno. Esta separación no es estética: permite cambiar el sensor de temperatura sin arriesgarse a romper la lógica de radio, y —de cara a la próxima versión— permitirá sustituir el GPS tocando un solo fichero.
setup() y loop(). Orquesta, no implementa.
Firmware completo, disponible en abierto
El firmware completo —arquitectura modular, drivers de sensores, buffer circular, protocolo adaptativo, gestión de sesión LoRaWAN y decoder de TTN— está publicado como repositorio abierto en GitHub, con las credenciales y los datos sensibles retirados.
Los ficheros .cpp están en src/, las
cabeceras .h en include/ y el decoder de TTN en la raíz del repositorio.
Las tarjetas de arriba permiten descargar directamente cada fichero mostrado.
El corazón: muestrear rápido, transmitir despacio
La decisión de diseño más importante del firmware es separar dos ritmos que no tienen por qué coincidir:
- Se muestrea cada 3 segundos. Leer sensores es barato: no gasta radio, no consume tiempo de aire y no tiene límite regulatorio.
- Se transmite cada 30 segundos. Emitir sí es caro: consume energía, ocupa espectro compartido y está limitado por normativa.
Entre ambos ritmos se interpone un buffer circular de 30 muestras, que guarda hasta 90 segundos de historia. Cada muestra es una fotografía completa del estado de la sonda en ese instante: posición, altitud, velocidad, las dos temperaturas, la presión y la batería.
Porque garantiza que nunca se pierde el hilo del vuelo aunque falle un envío. Si un uplink no sale, las muestras siguen en el buffer y se reintentan en el ciclo siguiente. Solo se descartan del buffer las muestras que se han transmitido con éxito. Y si el buffer se llenara del todo, sobrescribe siempre la muestra más antigua: se prefiere perder el pasado lejano antes que el presente.
El ciclo principal, paso a paso
El loop() es deliberadamente simple y siempre hace lo mismo, en este
orden:
Un paquete que se estira con la calidad del enlace
Aquí está la parte de la que estoy más satisfecho. LoRaWAN impone un límite estricto al tamaño de cada mensaje, pero ese límite no es fijo: depende de la calidad del enlace en cada momento. En vez de programar para el peor caso, el firmware pregunta cuánto espacio hay y lo aprovecha entero.
El problema: el espacio disponible cambia solo
La red LoRaWAN ajusta automáticamente la velocidad de transmisión según lo bien que se reciba al dispositivo. Con buena señal usa una velocidad alta, que permite mensajes grandes; con mala señal baja la velocidad para llegar más lejos, y entonces solo caben mensajes pequeños. La diferencia es enorme:
| Velocidad | Alcance | Máximo por mensaje | Mini-muestras que caben |
|---|---|---|---|
| DR5 / DR4 | Enlace bueno | 222 B | hasta 18 |
| DR3 | Enlace medio | 115 B | hasta 8 |
| DR2 | Enlace pobre | 51 B | hasta 2 |
La solución: dos tipos de muestra
La idea es sencilla y eficaz. No todas las magnitudes cambian al mismo ritmo ni necesitan la misma frecuencia. La temperatura y la presión evolucionan despacio; la posición, en cambio, interesa con el mayor detalle posible para dibujar la trayectoria. Así que cada paquete lleva:
- Una muestra completa (20 bytes) con absolutamente todo: posición, altitud, velocidad, las dos temperaturas, la presión y la batería. Siempre la más reciente.
- Tantas mini-muestras (11 bytes cada una) como quepan, con solo posición, altitud y velocidad. Son el rastro fino de la trayectoria entre envíos.
Estructura de cada uplink: una cabeza fija con el estado completo, y una cola variable con el rastro de posiciones.
sats
Los trucos de codificación
Cada campo está exprimido al máximo. Estas son las decisiones que permiten meter tanta información en tan poco espacio:
| Campo | Tamaño | Truco |
|---|---|---|
| Latitud / longitud | 3 B | Entero de 24 bits en vez de 32: se multiplican los grados por 100.000, lo que da ~1 m de precisión y ahorra un byte por coordenada. |
| fix + satélites | 1 B | Comparten byte: un bit indica si hay posición válida, los otros siete cuentan los satélites. |
| Altitud | 2 B | Metros enteros, sin decimales. Hasta 65.535 m: de sobra para un globo. |
| Velocidad | 2 B | En cm/s en lugar de m/s, para conservar dos decimales usando enteros. |
| Temperaturas | 2 B | Décimas de grado (×10) con signo, cubriendo de −3.276 a +3.276 °C. |
| Presión | 2 B | Décimas de hectopascal (×10). |
| Antigüedad (Δt) | 1 B | Segundos transcurridos desde la muestra hasta el envío. Permite reconstruir el instante exacto de cada lectura en tierra. |
Ese byte de antigüedad es lo que hace que el sistema funcione de verdad. Como las muestras viajan agrupadas y llegan todas juntas, sin él sería imposible saber a qué momento corresponde cada una. Con él, cada lectura lleva su propia marca de tiempo relativa y en tierra se reconstruye la secuencia real con precisión de segundo.
Solo viaja lo que aporta
Un último refinamiento: las mini-muestras sin posición válida se descartan del paquete. Si el GPS no tenía fix en ese instante, la mini-muestra solo contendría ceros, así que no se envía —pero sí se marca como procesada para que salga del buffer. El espacio ahorrado se aprovecha para enviar posiciones que sí existen.
El otro límite: cada cuánto se puede hablar
El tamaño del mensaje es solo la mitad de la historia. Hay un segundo límite, bastante más severo, que suele pillar por sorpresa a quien llega a LoRaWAN desde otras tecnologías: no se puede transmitir cuando uno quiera. Y no por falta de batería, sino por dos restricciones que se solapan.
1 · El ciclo de trabajo — el límite legal
La banda de 868 MHz es de uso libre pero compartido: no hay ningún operador repartiendo turnos, así que la normativa europea impone que cada aparato ocupe el aire solo una fracción minúscula del tiempo. En la sub-banda que usan los uplinks ese techo es del 1 %, y se traduce en una regla muy concreta: después de transmitir durante un tiempo, hay que callar 99 veces ese tiempo.
Con números: un mensaje que ocupe medio segundo de aire obliga a guardar silencio alrededor de 50 segundos antes del siguiente. No es una recomendación de buenas prácticas: es una condición legal de uso de la banda, y se aplica al dispositivo lo quiera o no su dueño.
2 · La política de uso justo — el límite de la red
Por encima de lo anterior está la red concreta que se utilice. Este proyecto emite a través de The Things Network, una red comunitaria y gratuita sostenida por estaciones que instalan voluntarios. Para repartir esa capacidad donada entre todos, TTN fija un presupuesto por dispositivo: 30 segundos de emisión al día y 10 mensajes de bajada.
Conviene leer bien la cifra, porque es más restrictiva de lo que parece: no son 30 segundos de conexión, sino 30 segundos de radio efectivamente emitiendo, acumulados a lo largo de 24 horas. Con mensajes de unas décimas de segundo, ese presupuesto da para unas pocas decenas de envíos diarios —del orden de uno cada veinte o treinta minutos si se quiere operar de forma continua.
La sonda transmitió cada 30 segundos durante más de dos horas: unos 270 mensajes, que suponen varias veces el presupuesto diario de uso justo consumido en una sola mañana. Es admisible como lo que fue —una misión puntual y acotada en el tiempo, planificada de antemano—, pero sería un abuso del recurso común si un dispositivo se quedara emitiendo a ese ritmo de forma permanente. Un sensor fijo en producción debe ir a cadencias de minutos u horas, no de segundos.
Y aquí encaja todo el diseño del protocolo. Si no se puede transmitir más a menudo, la única forma de ganar resolución es meter más información en cada transmisión. Eso es exactamente lo que hacen las mini-muestras: no aumentan el número de envíos —que es lo caro y lo limitado—, sino la cantidad de vuelo que cuenta cada envío. Mandar diez posiciones dentro de un mensaje consume muchísimo menos aire que mandar diez mensajes de una posición, porque cada mensaje arrastra su propia cabecera y su propio tiempo de preámbulo.
Es la pregunta natural al descubrir que la energía no fue problema. La respuesta es que la batería nunca fue el factor limitante. Emitir sí es, con diferencia, lo que más energía consume del sistema —la radio en transmisión gasta mucho más que todo lo demás junto—, pero el techo real no lo pone la batería: lo ponen el reglamento de la banda y el presupuesto de aire de la red. Se puede tener energía de sobra y aun así no tener derecho a hablar.
El decoder: la operación inversa
En el otro extremo, un decoder JavaScript alojado en The Things Network hace el camino contrario: recibe los bytes crudos, extrae la muestra completa, recorre las mini-muestras que vengan detrás y entrega un objeto legible con todos los campos en sus unidades naturales. Es la contraparte exacta del firmware —si uno cambia, el otro debe cambiar con él— y es lo que alimenta a Node-RED y, de ahí, a la base de datos y al dashboard.
// Salida del decoder para un uplink típico { "altitud" : 647, "lat" : 40.00418, "lon" : -3.57523, "fix" : true, "sats" : 18, "temp_ext" : 19.5, "temp_int" : 20.3, "presion" : 949.2, "batt_raw" : 889, "minis" : [ /* rastro de posiciones */ ], "n_minis" : 7 }
Antes del vuelo se asumía que la cobertura LoRa se perdería al ascender. Ocurrió lo contrario: a más altura, mejor enlace. Desde 20 km hay línea de visión directa a multitud de estaciones a la vez. La sonda solo dejó de transmitir en el descenso, al bajar de los 2,2 km y quedar de nuevo tapada por el terreno.
Tres medidas para un sistema que nadie puede reiniciar
Durante más de dos horas de vuelo no hay forma de intervenir. No hay botón de reinicio, ni consola, ni posibilidad de corregir nada. Todo lo que pueda fallar tiene que recuperarse solo. Estas son las tres defensas del sistema.
1 · Persistencia de la sesión de red
Unirse a la red LoRaWAN es un proceso costoso y delicado. Además, cada mensaje lleva un contador que la red vigila: si el dispositivo se reinicia y ese contador vuelve atrás, la red interpreta los mensajes como repeticiones sospechosas y los descarta. Un reinicio en pleno vuelo podría, por tanto, dejar la sonda emitiendo al vacío.
La solución fue guardar el estado completo de la sesión en memoria no volátil —la que sobrevive a un corte de alimentación— y actualizarlo después de cada envío correcto. Si el equipo se reinicia, recupera la sesión y continúa en el punto exacto donde estaba, sin volver a unirse y sin romper el contador.
El firmware distingue entre las credenciales de unión y la sesión activa, y las guarda por separado. Así, ante un problema, puede descartar la sesión y renegociarla desde cero sin perder los contadores de unión —que también deben crecer siempre—. Es una separación sutil que evita quedarse permanentemente fuera de la red.
2 · Watchdog por hardware
Un watchdog es un temporizador de guarda independiente del programa: si el software no le avisa periódicamente de que sigue vivo, asume que se ha quedado colgado y reinicia el chip. Aquí está configurado con un margen de 60 segundos, y el aviso es la primera instrucción de cada vuelta del bucle principal.
Si un sensor dejara de responder y bloqueara el programa —un riesgo real con buses I²C a temperaturas extremas—, el sistema se reinicia solo, recupera la sesión de la memoria no volátil y retoma la transmisión en menos de un minuto. Es lo que permite soltar el globo y no volver a tocarlo.
3 · Reintentos que no pierden datos
La tercera defensa ya la hemos visto: el buffer no se vacía hasta que el envío se confirma. Un uplink fallido no cuesta datos, solo retrasa su llegada. Y como el muestreo continúa incluso mientras el equipo intenta unirse a la red, el primer envío tras recuperar la conexión arrastra consigo todo el historial pendiente.
Cada una cubre un tipo distinto de fallo: la persistencia protege frente a reinicios, el watchdog frente a bloqueos, y el buffer frente a pérdidas de cobertura. Ninguna es complicada por separado; juntas convierten un prototipo de sobremesa en algo que puedes soltar a 25 km de altura.
El frío amenazaba la batería; el vuelo dijo lo contrario
La sonda se alimenta con una celda de litio recargable CR123A de 750 mAh. Sobre el papel, da para unas 14 horas a temperatura ambiente —de sobra para un vuelo de dos horas y cuarto.
El problema es que en la estratosfera la temperatura exterior cae hasta −52 °C, y la capacidad de una batería de litio se desploma con el frío. Una batería que a 20 °C rendiría sin problema puede quedarse en una fracción de su capacidad a esas temperaturas. Por eso el aislamiento térmico del compartimento de la batería no es opcional: es un requisito de diseño tan importante como cualquier elección de sensor.
Un aliado inesperado: la propia electrónica disipa calor al trabajar, lo que ayudó a mantener el interior templado. Y como la sonda mide las dos temperaturas, en los datos del vuelo se ve exactamente cuánto: el interior se mantuvo decenas de grados por encima del exterior durante todo el trayecto.
Un detalle de eficiencia
Medir la tensión de la batería consume corriente, porque el circuito divisor que permite leerla drena algo de energía de forma continua. Por eso el divisor solo se activa durante la medición —unos milisegundos cada 3 segundos— y se apaga inmediatamente después. Un detalle pequeño que, multiplicado por horas de vuelo, ahorra energía real.
Salud del sistema: la sonda también se cuenta a sí misma
Además de medir la atmósfera, la sonda informa de su propio estado. Es una distinción clásica en cualquier misión: por un lado están los datos científicos —lo que se quiere estudiar—, y por otro la telemetría de servicio, que responde a una pregunta muy distinta: «¿sigue el equipo en condiciones de trabajar?». En el panel de seguimiento esos indicadores tienen su propio bloque, Salud del Sistema, con tres semáforos:
| Indicador | Qué vigila | De dónde sale |
|---|---|---|
| Batería % y voltios | Autonomía restante y estado de la celda. | Viaja en el paquete, como lectura cruda del conversor |
| Señal LoRaWAN dBm | Calidad del enlace de radio con tierra. | La mide la estación que recibe · no ocupa ni un byte |
| Satélites recuento | Fiabilidad de la posición. Por debajo de 4, alerta. | Viaja en el paquete, compartiendo byte con el indicador de fix |
Un detalle bonito de eficiencia: la batería y los satélites tienen que viajar dentro del paquete, ocupando bytes preciosos. La potencia de señal, no —la mide la estación de tierra al recibir cada mensaje y la red la adjunta como metadato—. Es información de diagnóstico que llega gratis, sin gastar ni un byte de un presupuesto que va muy justo.
Hay otra decisión coherente con el resto del diseño: la sonda envía el número crudo que le da el conversor analógico-digital, no los voltios ya calculados. La conversión a tensión y a porcentaje se hace en tierra, en Node-RED. Así el firmware no gasta ciclos ni bytes en algo que puede resolverse abajo, y —más importante— el dato original queda guardado tal cual: si mañana se recalibra la curva de la batería, se puede recalcular todo el histórico sin haber perdido nada.
Este bloque no es decoración. El recuento de satélites fue precisamente lo que delató el bloqueo COCOM a 18 km: el receptor seguía declarando una posición «válida», pero los satélites habían caído a cero. Sin ese indicador de servicio, el congelamiento habría pasado desapercibido y los datos del apogeo se habrían dado por buenos.
El veredicto: sobraba batería
Y aquí llega el resultado que más tranquiliza. Pese a las temperaturas extremas, el consumo fue muy reducido y la batería aguantó con holgura todo el vuelo, con margen de sobra al aterrizar. El colapso de capacidad que se temía nunca llegó a materializarse.
Contribuyeron varias cosas a la vez: el aislamiento térmico, el calor que la propia electrónica disipa al trabajar, el divisor de batería que solo se enciende para medir, y una radio que —al contrario de lo que se suponía— tuvo enlace tan bueno en altura que no necesitó insistir. Para la próxima misión, ese margen abre la puerta a gastar energía en otras cosas: más sensores, muestreo más frecuente o vuelos más largos.
Lo que ese margen no permite es transmitir más a menudo. Ese límite no lo pone la batería, sino el reglamento de la banda de 868 MHz y el presupuesto de aire de la red —como se explica en «El otro límite: cada cuánto se puede hablar»—. Se puede tener energía de sobra y seguir sin poder hablar más.
La evolución completa de estos indicadores, minuto a minuto, se puede seguir en el reproductor de la misión ↗, que reconstruye el vuelo entero con todos los paneles funcionando en tiempo real.
Lo que voló y lo que viene después
El sistema que alcanzó los 25.527 m está plenamente operativo y validado en vuelo real. Pero un proyecto así nunca se da por cerrado: estas son las mejoras en marcha para la siguiente iteración.
- En vuelo Cadena completa operativa Join OTAA con persistencia de sesión, muestreo cada 3 s en buffer circular, protocolo adaptativo al enlace, watchdog de 60 s y telemetría de posición, presión y doble temperatura. Validado hasta 25.527 m.
- Siguiente GPS u-blox NEO-M9N Sustituir el UC6580 por un receptor con modo aeronáutico configurable (
dynModel=6), para tener posición real más allá de los 18 km y no depender de la reconstrucción. La arquitectura modular hace que el cambio afecte esencialmente a un solo fichero. - Siguiente Sensor inercial (IMU ICM-42688-P) Añadir aceleración y giro para caracterizar la rotación y las oscilaciones del ascenso con datos propios, en lugar de inferirlos de la trayectoria.
- Siguiente Calibración del PT100 y paso a 3 hilos Volver a la configuración de tres hilos y calibrar contra referencia para afinar la medida de temperatura exterior en el rango extremo.
Por Miguel · Trotero · trotero.com