BermejaSat #1: Domando la placa — Instalación y primer contacto con el hardware

Introducción

Tras doce entradas del Proyecto Peridotita mirando Sierra Bermeja desde el espacio con datos de satélites ya existentes, damos un giro: en vez de analizar datos que otros han capturado, vamos a construir nosotros mismos el instrumento que los captura. Nace así BermejaSat, nuestro proyecto de ingeniería aeroespacial en miniatura dentro del desafío europeo CanSat de la ESA — un satélite real, con sus subsistemas de energía, sensores y comunicaciones, comprimido dentro del volumen de una lata de refresco.

Antes de hablar de sensores de presión o de radio LoRa, hay un paso previo que no suele aparecer en los tutoriales pero que es donde de verdad se pierde (o se gana) la primera sesión con el alumnado: conseguir que el ordenador y la placa se hablen. Esta primera entrada documenta ese primer contacto, incluyendo el tropiezo que nos encontramos y cómo lo resolvimos — porque diagnosticar un fallo de hardware con método es tan parte de la ingeniería como escribir el código que funciona a la primera.

🔬 El hardware de partida

Para esta fase inicial, de aprendizaje y familiarización con el entorno, trabajamos con dos familias de placas basadas en el microcontrolador ESP32, con conectividad LoRa integrada — la tecnología de radio de largo alcance que usará el CanSat para transmitir sus datos durante el descenso:

• LILYGO LoRa V1.3 (868 MHz, con pantalla OLED) — nuestra placa de pruebas inicial para esta entrada.
• Heltec WiFi LoRa 32 (V3.2) — la familia de placas sobre la que construiremos el CanSat definitivo.

Paso 1: Instalar el entorno de programación (Arduino IDE)

Todo el firmware de BermejaSat se programa en C++ sobre Arduino IDE, el entorno estándar para microcontroladores de este tipo. Así se prepara un ordenador desde cero:

1. Descargar e instalar Arduino IDE (versión 2.x) desde la web oficial de Arduino.
2. Ir a Archivo → Preferencias y, en el campo “URLs adicionales de gestor de tarjetas”, añadir: https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json
3. Ir a Herramientas → Placa → Gestor de tarjetas, buscar esp32 (de Espressif Systems) e instalarlo.
4. En Herramientas → Placa, seleccionar “ESP32 Dev Module” (válido como opción genérica para todas las placas de esta familia).
5. En Herramientas → Gestor de bibliotecas, instalar:
   • Adafruit SSD1306 (y aceptar instalar también Adafruit GFX Library y Adafruit BusIO, que son dependencias necesarias).
6. Conectar la placa por USB y, en Herramientas → Puerto, seleccionar el puerto que aparece.

Con esto, el ordenador ya es capaz de compilar y enviar programas a la placa. El siguiente paso es comprobarlo con algo visual.

Paso 2: Primer sketch — solo la pantalla

El objetivo de esta primera prueba es deliberadamente modesto: encender la pantalla OLED integrada y mostrar un contador. Nada de sensores ni de radio todavía — el objetivo es que el alumnado se acostumbre al ciclo escribir → compilar → subir → comprobar, que van a repetir decenas de veces a lo largo del proyecto.

#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

#define OLED_SDA 21
#define OLED_SCL 22
#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 64

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, -1);

int contador = 0;

void setup() {
  Serial.begin(115200);
  Wire.begin(OLED_SDA, OLED_SCL);

  if (!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) {
    Serial.println("No se ha encontrado la pantalla OLED :(");
    while (true) delay(1000);
  }

  display.clearDisplay();
  display.setTextSize(2);
  display.setTextColor(SSD1306_WHITE);
  display.setCursor(0, 0);
  display.println("Hola,");
  display.println("BermejaSat!");
  display.display();
  delay(2000);
}

void loop() {
  contador++;
  display.clearDisplay();
  display.setTextSize(1);
  display.setCursor(0, 0);
  display.println("Funcionando...");
  display.setTextSize(3);
  display.setCursor(20, 25);
  display.println(contador);
  display.display();
  delay(1000);
}

⚠️ El tropiezo: “WAITING TO RECEIVE”

La primera vez que subimos el código, el Monitor Serie mostraba el contador avanzando con normalidad — la placa, el microcontrolador y el código funcionaban perfectamente. Pero la pantalla física seguía mostrando, congelada, el mensaje “WAITING TO RECEIVE” del firmware de demostración de fábrica.

Esto nos dio una lección útil para transmitir al alumnado: una pantalla OLED tiene su propia memoria interna, y sigue mostrando lo último que se escribió en ella hasta que alguien vuelve a escribir de verdad sobre ese contenido. Si el código nunca consigue “hablarle” correctamente al chip de la pantalla (por ejemplo, por usar los pines equivocados), la imagen antigua se queda congelada indefinidamente — sin que eso signifique que el resto del programa haya fallado.

La causa concreta: existen varias variantes de placas “LoRa V1.3” circulando con distinto cableado interno hacia la pantalla. Nuestro primer intento asumió una combinación de pines (con un pin de reset dedicado) que no correspondía a nuestra unidad exacta.

Diagnóstico con un escáner I2C

En vez de probar combinaciones de pines a ciegas, construimos una herramienta de diagnóstico: un pequeño programa que recorre sistemáticamente varias combinaciones conocidas de pines de comunicación (protocolo I2C) y pregunta a cada una si hay algún dispositivo respondiendo:

#include <Wire.h>

struct ParPines {
  int sda;
  int scl;
  const char* nombre;
};

ParPines candidatos[] = {
  {21, 22, "21/22 (estandar ESP32 / LILYGO V1.3 segun ficha oficial)"},
  {4, 15,  "4/15 (clon TTGO V1.0 tipo randomnerdtutorials)"},
  {5, 4,   "5/4  (otra variante vista en algunos clones)"},
  {2, 15,  "2/15 (otra variante vista en algunos clones)"}
};

const int numCandidatos = 4;

void probarPines(int sda, int scl, const char* nombre) {
  Serial.println("----------------------------------------");
  Serial.print("Probando SDA=");
  Serial.print(sda);
  Serial.print(" SCL=");
  Serial.print(scl);
  Serial.print("  ->  ");
  Serial.println(nombre);

  Wire.end();
  Wire.begin(sda, scl);
  delay(50);

  int encontrados = 0;
  for (byte direccion = 1; direccion < 127; direccion++) {
    Wire.beginTransmission(direccion);
    byte error = Wire.endTransmission();
    if (error == 0) {
      Serial.print("  >>> DISPOSITIVO ENCONTRADO en 0x");
      if (direccion < 16) Serial.print("0");
      Serial.println(direccion, HEX);
      encontrados++;
    }
  }

  if (encontrados == 0) {
    Serial.println("  (nada en esta combinacion)");
  }
}

void setup() {
  Serial.begin(115200);
  delay(1500);
  Serial.println("Iniciando escaneo multi-pin...");
}

void loop() {
  for (int i = 0; i < numCandidatos; i++) {
    probarPines(candidatos[i].sda, candidatos[i].scl, candidatos[i].nombre);
  }
  Serial.println("==========================================");
  Serial.println("Vuelta completa. Repitiendo en 8 segundos.");
  Serial.println("==========================================");
  delay(8000);
}

Este pequeño ejercicio de “preguntar en vez de suponer” tiene, además, valor pedagógico por sí mismo: es una introducción muy concreta a cómo funciona la depuración sistemática de hardware, una habilidad que el alumnado usará una y otra vez a lo largo del proyecto.

La solución

Confirmando el modelo exacto de la placa a partir de su etiqueta física (LILYGO LoRa V1.3, 868 MHz, referencia de fábrica Q310) y contrastándolo con la documentación oficial del fabricante, identificamos la configuración correcta: la pantalla se comunica por los pines GPIO21 (SDA) y GPIO22 (SCL), sin necesidad de un pin de reset dedicado. Al corregir esos dos valores en el sketch, la pantalla mostró de inmediato “Hola, BermejaSat!” seguido del contador — problema resuelto.

Conclusión pedagógica

Esta primera entrada no trata sobre un sensor concreto ni sobre un resultado científico, sino sobre algo igual de importante en un proyecto de ingeniería real: la primera hora con hardware nuevo casi nunca sale a la primera, y eso es parte normal del proceso. Documentar el fallo, diagnosticarlo con una herramienta (el escáner I2C) en vez de con conjeturas, y llegar a una causa concreta y verificable es exactamente el método que seguiremos cuando lleguemos a los sensores de presión y temperatura, y más adelante a la telemetría por radio LoRa durante el descenso real del CanSat.

En la próxima entrada: lectura del sensor de presión y temperatura (la misión primaria oficial de CanSat) y primer envío de datos por radio LoRa entre dos placas.

---