Radiation Monitor, détecteur portable du niveau de signal¶

Qu'est-ce que Radiation Monitor ?¶

SiFliSparks/RadiationMonitor est un afficheur portable du niveau de signal dans la bande Bluetooth, construit sur SF32LB52 et SiFli-SDK. Son firmware parcourt 79 points de fréquence de 2402 à 2480 MHz et affiche les niveaux de signal reçu sous forme de diagramme en barres LVGL. KEY2 démarre ou arrête le balayage et permet de parcourir l'historique enregistré.

Le projet est utile pour étudier le balayage de la bande Bluetooth, le traitement de données en temps réel, la visualisation des fréquences et l'interaction à un seul bouton. Ce n'est pas un analyseur de spectre étalonné et il n'identifie pas la source du signal reçu. Les émissions voisines à 2,4 GHz et les conditions de mesure peuvent influencer le diagramme. Sans étalonnage ni comparaison contrôlée, ses valeurs ne conviennent ni aux mesures réglementaires, ni à la certification, ni aux mesures RF de précision.

Pourquoi l'implémentation SF32 ?¶

Le SF32LB52 associe le Bluetooth 5.3 bimode, un MCU bicœur et des capacités d'affichage ; le projet utilise SiFli-SDK et LVGL pour garder sur l'appareil l'échantillonnage des fréquences, le lissage, la mise en mémoire tampon de l'historique et la mise à jour de l'écran. Cette référence constitue ainsi une expérience précoce utile pour un panneau de visualisation RF, un indicateur d'interférences de terrain ou une interface de diagnostic de production.

Le dépôt ne précise ni procédure d'étalonnage, ni budget d'incertitude, ni conditions de mesure traçables. Les résultats doivent donc être revalidés pour le silicium exact, la révision du SDK et du firmware, la carte, l'antenne, le boîtier, le bruit de la carte et le minutage. Transposer la méthode à une autre carte SF32LB52 ou à un circuit imprimé de produit exige une nouvelle validation ; une compilation réussie n'établit pas l'équivalence des mesures.

Résultat, portée et critères d'entrée¶

Résultat : reproduire le diagramme à 79 points sur du matériel SF32LB52 à version figée, vérifier un démarrage/arrêt répétable, établir l'algorithme et la profondeur de lissage réels par rapport à la source figée, tester l'historique documenté de 10 enregistrements et la récupération, puis recueillir assez de preuves pour décider si l'étalonnage ou du matériel sur mesure mérite un investissement.

Cette page n'interprète pas la hauteur d'une barre de RSSI comme un rapport cyclique, un débit, une puissance d'émetteur, l'identité d'un protocole ou une puissance spectrale réglementaire. Elle n'affirme pas non plus que le dépôt fournit une conception de production complète, une méthode d'étalonnage ou une licence logicielle explicite.

Avant de commencer, ayez :

• une carte d'affichage SF32LB52. Le README du projet cite SF32LB52x et un répertoire de sortie build_sf32lb52-lchspi-ulp_hcpu ; la liste des cartes prises en charge de SiFli cite sf32lb52-lchspi-ulp pour la Huangshan Pi. Consignez la révision réelle de la carte et vérifiez la configuration de compilation du projet ;
• SiFli-SDK, SCons, un chemin de téléchargement et la capture du journal série ;
• une source 2,4 GHz contrôlable ou au moins deux scènes répétables, par exemple un émetteur BLE qui diffuse des annonces, d'abord éteint puis allumé ;
• un analyseur de spectre étalonné ou un instrument de mesure de puissance, ainsi que des conditions fixes d'antenne/de distance/de blindage si la précision numérique fait partie du périmètre ;
• un relevé de test de l'état de l'écran, de la sortie série, de l'orientation de la carte, de la distance, de l'alimentation et de l'environnement.

Spécifications matérielles et logicielles¶

Spécification matérielle¶

Spécification logicielle¶

Choisir une configuration de référence prise en charge¶

Utilisez le commit de projet figé 670cf20, et non la branche mobile main. Le README du projet cite build_sf32lb52-lchspi-ulp_hcpu comme répertoire de sortie ; la liste des cartes prises en charge de SiFli cite sf32lb52-lchspi-ulp pour la Huangshan Pi / LCHSPI-ULP. Cela établit le nom de carte du SDK, et non la commande exacte du projet ni l'assemblage de carte testé. Le README ne précise ni révision de carte ni commande SCons complète ; confirmez donc la configuration de compilation du projet lors de la première reproduction, au lieu de supposer que toute carte SF32LB52x est prise en charge.

Étapes du projet¶

Architecture système et dépendances¶

flowchart LR
    E["Environnement 2,4 GHz\nplusieurs sources de signal"] --> A["Antenne et frontal RF\nétalonnage non établi"]
    A --> R["Chemin de balayage Bluetooth du SF32LB52\néchantillonnage à 79 points"]
    R --> S["Lissage selon la source du projet\nhistorique RSSI en tampon circulaire"]
    S --> U["Diagramme en barres LVGL\n2402–2480 MHz"]
    K["KEY2\ncourt : démarrer/arrêter, long : historique"] --> S
    L["Journal série et instrument de référence"] --> V["Relevé de validation"]
    R --> L
    U --> V

Les principaux domaines de défaillance sont l'entrée RF/l'antenne, le comportement du balayage et l'étalonnage, le traitement des données, le tampon d'historique, la machine d'états des boutons, la correspondance LVGL et l'alimentation. Une barre haute signifie seulement que l'implémentation a observé une valeur de réception relativement forte ; sans comparaison contrôlée, elle n'identifie ni un émetteur, ni une modulation, ni un état de conformité.

Étape 1 — Établir la base de balayage intacte¶

Objectif : prouver que le matériel et la source retenus produisent un affichage à 79 points répétable.

1. Figez les commits du dépôt et de SiFli-SDK, la révision de la carte, l'antenne et la connexion de l'écran ; compilez et téléchargez proprement.
2. Avec une scène RF stable, démarrez l'appareil et consignez son diagramme initial, la sortie série et l'état de KEY2.
3. Appuyez brièvement sur KEY2 pour démarrer le balayage. Confirmez la couverture et les repères de l'axe X à 2402, 2441 et 2480 MHz.
4. Utilisez un émetteur d'annonces BLE contrôlé ou une autre source répétable, et consignez source éteinte, source allumée, distance et changements d'orientation de la carte.
5. Réinitialisez et répétez, en vérifiant que le tableau de 79 points et le diagramme ne sont pas décalés et ne conservent pas de données périmées.

Preuves à conserver : révisions de la source/du SDK/de la carte, journaux de compilation/téléchargement, description de l'environnement, réglages de la source, distance/orientation, journal série, captures d'écran et résultat de la réinitialisation.

Critère de sortie du point de contrôle 1 : deux démarrages indépendants balayent et affichent 79 points ; les changements de scène contrôlée sont répétables en direction ; les indices d'affichage et les étiquettes de fréquence ont été vérifiés.

Étape 2 — Valider le traitement, l'historique et la récupération¶

Objectif : prouver que l'interface représente un chemin de données explicable et non une animation accidentelle.

Critère de sortie du point de contrôle 2 : le lissage, la profondeur de l'historique, l'état des boutons et le comportement à la réinitialisation correspondent à la source ; les états anormaux sont observables et non silencieux.

Étape 3 — Construire une base source reproductible¶

Objectif : reproduire l'image de l'étape 2 dans un environnement propre.

1. Consignez le commit du projet, le commit du SDK, le système d'exploitation hôte, les versions de SCons/du compilateur et l'argument de carte réel.
2. Supprimez la sortie de compilation, reconfigurez et recompilez ; enregistrez les images, la sortie mémoire/partitions et les journaux complets.
3. Flashez avec le script de téléchargement généré et consignez le port, la vitesse en bauds et le résultat.
4. Répétez sur un second ordinateur ou dans un répertoire propre, puis rejouez les contrôles essentiels de l'étape 2.

Critère de sortie du point de contrôle 3 : le projet produit une image équivalente en comportement, sans fichiers de carte non suivis, fichiers générés ni produits périmés.

Étape 4 — Effectuer une adaptation contrôlée de la mesure ou de l'interface¶

Objectif : tester une orientation produit sans perdre la base d'origine.

Les modifications envisageables comprennent la journalisation des valeurs brutes, des étiquettes explicites tous les 1 MHz, le maintien des crêtes, un autre sélecteur d'historique, un décalage d'étalonnage ou l'export vers l'hôte de tendances relatives. Ne changez qu'une classe à la fois et conservez l'image d'origine.

En cas d'ajout d'un étalonnage, définissez la source de référence, la fréquence, le niveau d'entrée, l'antenne/le câble, la distance, l'orientation, la température et l'incertitude. Un seul décalage global suffit rarement à compenser la réponse en fréquence, la dispersion entre cartes et les effets du boîtier.

Critère de sortie du point de contrôle 4 : la modification réussit les non-régressions d'origine sur les 79 points, le démarrage/arrêt, l'historique, la réinitialisation et la source contrôlée ; chaque affirmation de précision nomme son instrument de référence et ses conditions.

Étape 5 — Revue de maturité produit¶

L'équipe doit répondre aux questions suivantes :

• Le produit n'a-t-il besoin que de tendances relatives d'interférences, ou d'une puissance absolue traçable avec incertitude ?
• L'implémentation du balayage Bluetooth du projet est-elle documentée comme prise en charge sur le silicium cible et le SDK, et quelles limites de concurrence s'appliquent ?
• Dans quelle mesure l'antenne, le boîtier, le bruit de l'écran, le fonctionnement du DC/DC, le niveau de batterie et la température déplacent-ils le résultat ?
• Le produit peut-il maintenir la communication Bluetooth requise pendant le balayage, ou ces fonctions doivent-elles être mutuellement exclusives ?
• La latence mesurée d'un balayage à 79 points avec un lissage vérifié dans la source répond-elle à l'exigence d'interface ?
• Comment résoudre la distribution et les droits commerciaux alors que RadiationMonitor et le code intégré n'ont pas de licence explicite de niveau supérieur ?

Critère de sortie du point de contrôle 5 : l'objectif de mesure, le plan d'étalonnage, la stratégie de concurrence radio, les licences, le matériel et la responsabilité logicielle ont des responsables nommés et une décision de poursuivre/différer/arrêter.

Transfert vers la conception produit¶

Reportez le composant SF32 cible, la carte/l'antenne, l'implémentation du balayage Bluetooth et toutes les contraintes de mode/d'API confirmées à partir de la source figée, la définition des fréquences et des données, les relevés bruts et lissés, le budget de rafraîchissement de l'interface, le montage d'étalonnage, les tests de bruit d'alimentation, le chemin de récupération et la limite du test de production. Poursuivez avec le SF32LB52x, le SF32LB52-DevKit-ULP, le guide de conception matérielle du SF32LB52x et les tests de performances RF de SiFli-SDK.

Sources de référence¶

• SiFliSparks/RadiationMonitor
• README amont sur main
• Commit de référence figé 670cf20
• Catalogue de projets SiFli Sparks
• OpenSiFli/SiFli-SDK
• Cartes prises en charge par SiFli-SDK
• Guide de test RF de SiFli-SDK
• Présentation matérielle du SF32LB52x
• Démarrage rapide de SiFli-SDK pour SF32LB52x

Dernière mise à jour: 2026-10-21