Arquitectura sin la capa de marketing.
Cómo está construido realmente el prototipo, las decisiones que hay detrás y los límites de lo que se ha medido. Es un sistema de desarrollo, no un producto de automoción certificado. Las matemáticas del rumbo se derivan en la página de visión general; esta página es el registro del hardware y de su estado.
Construido por un solo ingeniero en Tekkera Electronix — Ibrahim Najjar. Las protoboards, las placas, el firmware, el procesado de señal y la carcasa salieron todos de las mismas manos.
Cuatro micrófonos INMP441, un ESP32-S3
La matriz no se reparte entre dos controladores. A un INMP441 se le puede indicar qué ranura de una trama estéreo I²S debe escribir, de modo que cada par opuesto comparte una línea de datos — un micrófono en la ranura izquierda, su opuesto en la derecha — y ambos pares funcionan en un solo dominio de reloj.
| Este / Oeste | I²S0 maestro · datos GPIO 4 |
|---|---|
| Norte / Sur | I²S1 esclavo · datos GPIO 14 |
| Relojes compartidos | BCLK GPIO 6 · WS GPIO 5 · encaminados internamente por la matriz de GPIO |
| Formato de muestreo | 44.1 kHz · ranuras estéreo de 32-bit · datos de micrófono de 24-bit |
| Entrada del DSP | Los 16 bits más altos de cada muestra, hacia la cadena de correlación |
| Comprobación de arranque | El bucle de retorno y la calibración confirman que ambos buses están activos y alineados |
INMP441 E [L] ─┐
INMP441 O [R] ─┴─ DATA4 → I²S0 MAESTRO ─┐
BCLK6 / WS5
INMP441 N [L] ─┐ │ matriz GPIO interna
INMP441 S [R] ─┴─ DATA14 → I²S1 ESCLAVO ←┘
Por qué no se resta una corrección fija de la cadena
Cada par opuesto lo captura el mismo controlador I²S, así que los dos nunca comparten controlador entre pares. Restar un desfase de cadena supuesto entre controladores a cualquiera de los dos ejes inyecta un retardo que no es un retardo. Este montaje midió aproximadamente 9° de error de rumbo por una corrección de ese tipo y la eliminó. Dos periféricos en un mismo dominio de reloj evitan el problema en lugar de compensarlo.
Primero la detección, después la dirección
El clasificador decide si una ventana contiene o no una sirena; solo las ventanas que lo superan se envían a la estimación de dirección. Ese orden es lo que mantiene la cadena de rumbo alejada del audio irrelevante.
Clasificador de audio
- Exportación de audio de Edge Impulse con características de energía de banco de filtros mel
- Entrenado con grabaciones de ambulancias al borde de la carretera con tráfico, viento y desplazamiento Doppler, no con muestras limpias de estudio
- La confianza de la clasificación condiciona la ruta de aviso
- Arduino/PlatformIO en el nodo de techo para ejecutar el modelo exportado
- Las pruebas de falsos positivos en condiciones reales siguen pendientes como tarea del conjunto de datos
Estimación de dirección
- Dos ejes de retardo, este–oeste y norte–sur, sobre una cruz de 190 mm
- Una muestra a 44.1 kHz son 22.68 µs, equivalentes a 2.35° cerca de la perpendicular
- La interpolación 8× sobre la estimación de retardo da un paso teórico de 0.29° en la rejilla de retardo
- 0.29° es resolución, no exactitud medida
La temperatura y lo que no corrige
Corregir la velocidad del sonido cambia un modelo de distancia o de retardo, pero ambos ejes llevan el mismo factor d/c y se cancela en cuanto se combinan con atan2. Por eso el diseño no afirma que la compensación de temperatura mejore la exactitud del rumbo. La derivación, con todos los símbolos explicados, está en la página de visión general.
No está confirmado qué estimador se entrega
El rumbo basado en retardo descrito arriba es el enfoque de diseño documentado. El estimador tal como está hoy en el repositorio público combina la energía por canal con atan2 y un filtro de deriva, y la cadena gcc_phat no aparece en ningún punto de ese árbol; sus canales son delantero–izquierdo, delantero–derecho, trasero–izquierdo y trasero–derecho en lugar de la cruz norte–este–sur–oeste. Cuál de los dos entrega la versión actual debería confirmarse antes de afirmar ninguno de los dos como un hecho.
El rail de alimentación del micrófono forma parte de la cadena de señal
El nodo de techo aloja un módulo de radio, un convertidor conmutado y cuatro micrófonos digitales dentro de una carcasa pequeña. La protección de la batería, la conversión y el filtrado se diseñaron en conjunto, y no como algo secundario. La cadena, en orden:
- Celda LiFePO₄ 26650 — todo el nodo funciona con una sola celda.
- Módulo USB-C TP5000 — carga con el perfil LiFePO₄, no con uno de Li-ion.
- BMS 1S — el negativo de la batería va solo a B−; el retorno protegido del sistema se toma de P−.
- Convertidor elevador MT3608 — eleva hasta un rail de alimentación regulado de 5 V.
- Filtro π — 220 µF de almacenamiento, 10 µH en serie, 100 nF cerámico.
- AMS1117-3.3 — el rail de alimentación del micrófono, con una disposición de ESR documentada.
- Perla de ferrita y 100 nF — 100 Ω en cada rama de micrófono, no una sola vez en la alimentación.
- Adaptador de 12 V a 5 V — una alimentación independiente para la unidad de cabina.
Dos formas de equivocarse con esto
En este nodo el MT3608 es un convertidor elevador, no un convertidor reductor: la celda queda por debajo del rail de 5 V, así que un componente reductor nunca regularía. Y el retorno protegido debe venir del terminal P− del BMS — tomarlo de B− puentea la protección de descarga y anula el circuito de protección.
Controlador en tiempo real junto a una interfaz Linux
La E/S sensible al tiempo se separa de la interfaz más completa. La lectura de sensores y el enlace de radio se quedan en un microcontrolador; el renderizado, las cámaras y la aplicación viven en la Pi, y ambos se comunican por un enlace UART estructurado.
Controlador ESP32-S3
- Firmware ESP-IDF v5
- Mensajes ESP-NOW procedentes del nodo de techo
- Interfaces de LoRa, GPS, radar, audio, microSD y MPU6050
- Mensajes UART estructurados hacia la Raspberry Pi
- Placa de cabina fabricada; montaje y puesta en marcha completa en curso
Aplicación para Raspberry Pi
- Interfaz pygame de ocho páginas
- Avisos de sirena, navegación vectorial sin conexión y diagnósticos del sistema
- Cámaras frontal y orientada al conductor
- Indicadores OBD-II, control multimedia mediante MPRIS y vista de cámara trasera
- Gestionada como servicio de Linux con systemd
Corrección de sensores
Un DS18B20 conectado a la Raspberry Pi no se enumeró durante el desarrollo, así que el AHT21 es la fuente de reserva actual. El sitio no afirma contar con dos sensores de temperatura validados de forma independiente.
Un canal de posición directo
Un demostrador aparte, transportado por el propio vehículo de emergencia. Emite un mensaje de posición compacto que los nodos SirenSense cercanos pueden situar en su mapa, de modo que un aviso puede indicar una dirección y una distancia, y no solo un rumbo.
| Controlador | ESP32-S3 |
|---|---|
| Radio | SX1278 · 433 MHz LoRa |
| Posición | Receptor GNSS BN-880 |
| Interfaz local | Pantalla OLED de estado |
| Paquete | Carga útil protegida con AES-128 |
| Acceso al canal | Jitter tipo ALOHA, de 800 a 1500 ms |
| Estado de montaje | Unidad de demostración en placa perforada construida; placa diseñada |
| Alcance urbano | 4 km objetivo de diseño — aún no caracterizado en campo |
El alcance de radio no se ha caracterizado en una prueba de campo urbana controlada. La cifra anterior es una estimación de ingeniería, y cualquier mejora del tiempo de respuesta que implique lo es por el mismo motivo.
Sin saltos silenciosos del prototipo al producto
Un estado claro es una característica de ingeniería, no un descargo de responsabilidad. Estas etiquetas describen el proyecto tal como está hoy y solo cambian cuando la prueba correspondiente está completa.
| Placa y carcasa del nodo de techo | Construidas y demostradas |
|---|---|
| Captura sincronizada de cuatro canales | Implementada, con comprobaciones de bucle de retorno y calibración al arrancar |
| Clasificación de sirenas con TinyML | Prototipo funcional; ampliación del conjunto de datos en curso |
| Cadena de dirección | Rumbo basado en retardo derivado e implementado como el diseño documentado. El estimador del repositorio público toma actualmente la dirección de la energía por canal con atan2. No está confirmado cuál de los dos entrega la versión actual |
| Exactitud del rumbo en campo | No caracterizada — no se afirma ninguna cifra única garantizada |
| Placa de cabina | Fabricada; montaje final y puesta en marcha completa en curso |
| Interfaz de Raspberry Pi | Software funcional; validación en Pi 5 y en el vehículo pendiente |
| Transpondedor | Unidad de demostración en placa perforada construida; placa de producción y pruebas de alcance pendientes |
| Resistencia a la intemperie | IP67 objetivo de estanqueidad — no certificado de forma independiente |
| V16 Pro | Una evolución sustancialmente más capaz del concepto de baliza V16 de la DGT española. No certificado por la DGT; no sustituye reglamentariamente a un dispositivo V16 certificado |
La implementación es pública
El código fuente, los archivos de la placa y la documentación que resumen las secciones anteriores.