Requisitos y Restricciones - Carvaa-7/Challenge1_IoT GitHub Wiki

Requisitos y Restricciones de Diseño

Restricción	Descripción	Cómo se abordó
Microcontrolador único	Todo el procesamiento (sensores, fusión, servidor web, alarma) corre en un solo ESP32	Arquitectura multitarea con FreeRTOS: sensores en core 0, servidor web + lógica en core 1, sin `delay()` bloqueante en el loop principal
Alimentación mixta 3.3V/5V	BME280/BH1750 son de 3.3V; HC-SR04, HX711 y LCD funcionan mejor/requieren 5V	Uso de divisor de voltaje 1kΩ/2kΩ en el ECHO del HC-SR04; alimentación segregada por nivel de voltaje según componente
GPIOs limitados y con restricciones de boot	El ESP32 tiene pines "strapping" (GPIO0, 2, 12) y pines de solo-entrada (34-39)	Distribución de pines organizada por zona física de la placa, evitando strapping pins en señales activas durante el arranque, y aprovechando pines de solo-entrada para señales que solo se leen (ECHO, DOUT del HX711)
Capacidad de la celda de carga (1kg)	La celda soporta hasta ~1.5kg antes de riesgo de daño permanente	Se eligió un modelo a escala de laboratorio (tanque 14cm⌀ × 8cm) con tope operativo al 80% de llenado (~NIVEL_MAX_CM), protegiendo la celda

Uso de componentes ya adquiridos por el equipo desde el Challenge #1 (evitando recompra), incluyendo transistores 2N2222 y diodos 1N4007 disponibles, que se evaluaron como alternativa antes de decidir usar un módulo relé dedicado.
Se descartó el uso del sensor de flujo YF-S201 (ya comprado) al confirmar que no es una variable exigida por la rúbrica del Challenge #2, priorizando el tiempo de desarrollo en lo evaluado.

Carcasa diseñada en 5 zonas funcionales independientes (ventana de luz para BH1750, rejilla de ventilación tipo "radiation shield" para BME280, panel frontal para LCD/LEDs/buzzer sin botones físicos, compartimento sellado para ESP32/electrónica, compartimento aparte para el HX711 junto a la celda de carga para minimizar longitud de cable analógico).
El diseño modular de pines (agrupados por lado físico de la placa) facilita escalar el sistema agregando sensores adicionales sin reorganizar todo el cableado.
El prototipo opera a escala de laboratorio, representando el comportamiento de un cuerpo de agua real como el embalse de Tominé; escalar a un despliegue real requeriría ajustar las constantes físicas (área, altura máxima) pero no la lógica de sensado/fusión.

Cronograma ajustado dependiente de la impresión 3D de la carcasa (a cargo de un tercero externo al equipo), lo que obligó a paralelizar: desarrollo y prueba de firmware en banco abierto mientras se esperaba el modelado/impresión, y ensamblaje final una vez recibida la carcasa.