Radiation Monitor: detector portátil de intensidad de señal¶

¿Qué es Radiation Monitor?¶

SiFliSparks/RadiationMonitor es un visor portátil de intensidad de señal en la banda Bluetooth, basado en SF32LB52 y SiFli-SDK. El firmware recorre 79 puntos de frecuencia entre 2402 y 2480 MHz y representa los valores recibidos en un gráfico de barras LVGL. KEY2 inicia o detiene el barrido y permite consultar el historial guardado.

El proyecto permite estudiar el barrido de la banda Bluetooth, el procesamiento de datos en tiempo real, la visualización de frecuencias y la interacción con un solo botón. No es un analizador de espectro calibrado ni identifica el origen de la señal recibida. Las transmisiones cercanas en 2,4 GHz y las condiciones de medida pueden influir en el gráfico. Sin calibración ni una comparación en condiciones controladas, sus valores no son adecuados para mediciones reglamentarias, de certificación o de RF de precisión.

¿Por qué la implementación con SF32?¶

SF32LB52 integra Bluetooth 5.3 de modo dual, una MCU de doble núcleo y capacidades de pantalla. El proyecto usa SiFli-SDK y LVGL para procesar localmente el muestreo de frecuencias, el suavizado, el historial y las actualizaciones de pantalla. Es un punto de partida útil para experimentar con un panel de visualización de RF, un indicador de interferencias en campo o una interfaz de diagnóstico de producto.

El repositorio no especifica un procedimiento de calibración, un presupuesto de incertidumbre ni condiciones de medida trazables. Por ello, vuelva a validar los resultados para las revisiones concretas del silicio, el SDK y el firmware, así como para la placa, la antena, la carcasa, el ruido de la placa y la temporización. Trasladar el método a otra placa SF32LB52 o a una PCB de producto exige una nueva validación; una compilación correcta no demuestra que las mediciones sean equivalentes.

Resultado, alcance y criterios de entrada¶

Resultado: reproducir el gráfico de 79 puntos en hardware SF32LB52 con versiones fijadas, comprobar que el inicio y la detención sean repetibles, confirmar el algoritmo y la profundidad reales del suavizado frente al código fijado, probar el historial documentado de 10 registros y la recuperación, y reunir evidencia suficiente para decidir si merece la pena invertir en calibración o hardware propio.

Esta página no interpreta la altura de una barra RSSI como ciclo de trabajo, caudal, potencia de transmisión, identidad del protocolo ni potencia espectral reglamentaria. Tampoco afirma que el repositorio proporcione un diseño de producción completo, un método de calibración o una licencia de software explícita.

Antes de empezar, tenga preparado:

• una placa de pantalla SF32LB52. El README del proyecto identifica SF32LB52x y el directorio de salida build_sf32lb52-lchspi-ulp_hcpu; la lista de placas compatibles de SiFli identifica Huangshan Pi como sf32lb52-lchspi-ulp. Registre la revisión real de la placa y verifique la configuración de compilación del proyecto;
• SiFli-SDK, SCons, una ruta de descarga y la captura del registro serie;
• una fuente de 2,4 GHz controlable o, como mínimo, dos escenarios repetibles, por ejemplo un anunciante BLE seleccionado apagado y encendido;
• si se necesita precisión numérica, un analizador de espectro calibrado o un instrumento de potencia, además de condiciones fijas para la antena, la distancia y el apantallamiento;
• un registro del estado de pantalla, la salida serie, la orientación de la placa, la distancia, la alimentación y el entorno.

Especificaciones de hardware y software¶

Especificación de hardware¶

Especificación de software¶

Elegir una configuración de referencia admitida¶

Use el commit fijado del proyecto 670cf20, no la rama main, que puede cambiar. El README del proyecto nombra build_sf32lb52-lchspi-ulp_hcpu como directorio de salida; la lista de placas compatibles de SiFli identifica Huangshan Pi / LCHSPI-ULP con el destino SCons sf32lb52-lchspi-ulp. Esto confirma el nombre del destino del SDK, no el comando exacto del proyecto ni el montaje de placa probado. El README no especifica una revisión de placa ni un comando SCons completo; confirme la configuración de compilación durante la primera reproducción y no presuponga que se admiten todas las placas SF32LB52x.

Etapas del proyecto¶

Arquitectura del sistema y dependencias¶

flowchart LR
    E["Entorno de 2,4 GHz\nvarias fuentes de señal"] --> A["Antena y front-end de RF\ncalibración no establecida"]
    A --> R["Ruta de escaneo Bluetooth del SF32LB52\nmuestreo de 79 puntos"]
    R --> S["Suavizado según el código del proyecto\nbúfer circular del historial RSSI"]
    S --> U["Gráfico de barras de LVGL\n2402–2480 MHz"]
    K["KEY2\npulsación corta: iniciar/detener; larga: historial"] --> S
    L["Registro serie e instrumento de referencia"] --> V["Registro de validación"]
    R --> L
    U --> V

Los principales dominios de fallo son la entrada RF/antena, el comportamiento del barrido y la calibración, el procesamiento de datos, el búfer del historial, la máquina de estados del botón, la asignación de LVGL y la alimentación. Una barra alta solo indica que la implementación observó un valor recibido relativamente fuerte; sin una comparación controlada, no identifica el transmisor, la modulación ni el estado de conformidad.

Etapa 1 — Establecer la base de barrido sin modificar¶

Objetivo: demostrar que el hardware y el código elegidos producen una visualización repetible de los 79 puntos.

1. Fije los commits del repositorio y SiFli-SDK, la revisión de la placa, la antena y la conexión de pantalla; compile desde cero y grabe el firmware.
2. Con un entorno RF estable, inicie el dispositivo y registre el gráfico inicial, la salida serie y el estado de KEY2.
3. Pulse KEY2 brevemente para iniciar el barrido. Compruebe la cobertura y las referencias del eje X en 2402, 2441 y 2480 MHz.
4. Use un anunciante BLE controlado u otra fuente repetible y registre las condiciones con la fuente apagada y encendida, la distancia y la orientación de la placa.
5. Reinicie y repita la prueba; compruebe que el arreglo de 79 puntos y el gráfico no estén desplazados ni conserven datos obsoletos.

Evidencia que se debe conservar: revisiones de código/SDK/placa, registros de compilación/descarga, descripción del entorno, configuración de la fuente, distancia/orientación, registro serie, capturas de pantalla y resultado del reinicio.

Criterio de salida del punto de control 1: dos arranques independientes barren y muestran 79 puntos; los cambios en el escenario controlado producen variaciones repetibles en la misma dirección; se han comprobado los índices de pantalla y las etiquetas de frecuencia.

Etapa 2 — Validar el procesamiento, el historial y la recuperación¶

Objetivo: demostrar que la interfaz representa una ruta de datos explicable, no una animación accidental.

Criterio de salida del punto de control 2: el suavizado, la profundidad del historial, el estado del botón y el comportamiento tras el reinicio coinciden con el código; los estados anómalos se pueden observar y no pasan inadvertidos.

Etapa 3 — Crear una base de código reproducible¶

Objetivo: reconstruir desde un entorno limpio la imagen validada en la Etapa 2.

1. Registre el commit del proyecto y del SDK, el sistema operativo anfitrión, las versiones de SCons y del compilador, y el argumento real de placa.
2. Elimine los archivos de compilación, vuelva a configurar y compile; conserve las imágenes, la salida de memoria/particiones y los registros completos.
3. Grabe el firmware con el script de descarga generado y registre el puerto, la velocidad en baudios y el resultado.
4. Repita la compilación en otro ordenador o directorio limpio y vuelva a ejecutar las comprobaciones principales de la Etapa 2.

Criterio de salida del punto de control 3: el proyecto genera una imagen equivalente en comportamiento sin depender de archivos de placa no versionados, archivos generados ni resultados de compilación obsoletos.

Etapa 4 — Aplicar un cambio controlado de medición o interfaz¶

Objetivo: probar una dirección de producto sin perder la base original.

Entre los cambios posibles están registrar valores sin procesar, añadir etiquetas explícitas por cada 1 MHz, retener picos, cambiar el selector del historial, añadir un desplazamiento de calibración o exportar tendencias relativas al anfitrión. Cambie una sola categoría cada vez y conserve la imagen original.

Si añade calibración, defina la fuente de referencia, frecuencia, nivel de entrada, antena/cable, distancia, orientación, temperatura e incertidumbre. Un desplazamiento global rara vez basta para compensar la respuesta en frecuencia, las variaciones entre placas y los efectos de la carcasa.

Criterio de salida del punto de control 4: el cambio supera las regresiones originales de 79 puntos, inicio/detención, historial, reinicio y fuente controlada; toda afirmación de precisión identifica el instrumento de referencia y las condiciones.

Etapa 5 — Revisión de preparación para producto¶

El equipo debe responder:

• ¿El producto necesita solo tendencias relativas de interferencia o valores absolutos de potencia trazables con su incertidumbre?
• ¿Está documentada como compatible con el silicio y el SDK de destino la implementación de escaneo Bluetooth del proyecto, y qué límites de concurrencia se aplican?
• ¿Cuánto varía el resultado por la antena, la carcasa, el ruido de pantalla, el funcionamiento del DC/DC, el nivel de batería y la temperatura?
• ¿El producto puede mantener la comunicación Bluetooth necesaria mientras barre o las funciones deben ser mutuamente excluyentes?
• ¿La latencia medida del barrido de 79 puntos con el suavizado verificado en el código satisface los requisitos de la interfaz?
• ¿Cómo se resolverán los derechos de distribución y comerciales si RadiationMonitor y el código incorporado no tienen una licencia explícita de nivel superior?

Criterio de salida del punto de control 5: hay responsables asignados para el objetivo de medición, el plan de calibración, la estrategia de concurrencia de radio, las licencias, el hardware y el software, y se registra una decisión de continuar, aplazar o detener.

Traspaso a la fase de diseño del producto¶

Traslade el dispositivo SF32 objetivo, la placa/antena, la implementación de escaneo Bluetooth y las restricciones de modo/API confirmadas en el commit fijado, la definición de frecuencia/datos, los registros sin procesar y suavizados, el presupuesto de actualización de la interfaz, el montaje de calibración, las pruebas de ruido de alimentación, la ruta de recuperación y el alcance de las pruebas de producción. Continúe con SF32LB52x, SF32LB52-DevKit-ULP, la guía de diseño de hardware SF32LB52x y las pruebas de rendimiento RF de SiFli-SDK.

Fuentes de referencia¶

• SiFliSparks/RadiationMonitor
• README upstream de main
• Commit de referencia fijado 670cf20
• Catálogo de proyectos de SiFli Sparks
• OpenSiFli/SiFli-SDK
• Lista de placas compatibles con SiFli-SDK
• Guía de pruebas RF de SiFli-SDK
• Descripción de hardware SF32LB52x
• Inicio rápido de SiFli-SDK para SF32LB52x

Última actualización: 2026-10-21