Radiation Monitor – tragbare Signalstärkeanzeige für das Bluetooth-Band¶

Was ist Radiation Monitor?¶

SiFliSparks/RadiationMonitor ist ein tragbarer Anzeiger für die Signalstärke im Bluetooth-Band auf Basis von SF32LB52 und SiFli-SDK. Seine Firmware durchläuft 79 Frequenzpunkte von 2402 bis 2480 MHz und stellt die empfangenen Stärkewerte als LVGL-Balkendiagramm dar. KEY2 startet oder stoppt den Scan und blättert im gespeicherten Verlauf.

Das Projekt eignet sich zum Studium seines Scan-Pfads im Bluetooth-Band, der Echtzeit-Datenverarbeitung, der Frequenzvisualisierung und der Ein-Tasten-Bedienung. Es ist kein kalibrierter Spektrumanalysator und identifiziert nicht die Quelle des empfangenen Signals. Übertragungen im 2,4-GHz-Band in der Nähe und die Messbedingungen können das Diagramm beeinflussen. Ohne Kalibrierung und einen kontrollierten Vergleich sind seine Werte für regulatorische, Zertifizierungs- oder Präzisions-RF-Messungen ungeeignet.

Warum die SF32-Implementierung?¶

SF32LB52 kombiniert Dual-Mode-Bluetooth 5.3, eine Dual-Core-MCU und Display-Fähigkeiten; das Projekt nutzt SiFli-SDK und LVGL, um Frequenzabtastung, Glättung, Verlaufspufferung und Bildschirmaktualisierung auf dem Gerät zu halten. Damit ist diese Referenz ein nützliches frühes Experiment für ein RF-Visualisierungspanel, einen Störungsanzeiger im Feld oder eine Diagnose-Oberfläche für die Produktion.

Das Repository legt weder ein Kalibrierverfahren noch ein Unsicherheitsbudget noch rückführbare Messbedingungen fest. Die Ergebnisse müssen daher für das genaue Silizium, die SDK- und Firmware-Revision, das Board, die Antenne, das Gehäuse, das Board-Rauschen und das Timing neu validiert werden. Die Übertragung der Methode auf ein anderes SF32LB52-Board oder eine Produkt-Leiterplatte erfordert eine erneute Validierung; eine erfolgreiche Kompilierung begründet keine Messgleichwertigkeit.

Ergebnis, Umfang und Eintrittskriterien¶

Ergebnis: das 79-Punkte-Diagramm auf versionsgebundener SF32LB52-Hardware nachbauen, wiederholbares Starten/Stoppen prüfen, den tatsächlichen Glättungsalgorithmus und seine Tiefe anhand der festgelegten Quelle bestimmen, den dokumentierten Verlauf mit 10 Einträgen samt Wiederherstellung testen und dann genügend Nachweise sammeln, um zu entscheiden, ob Kalibrierung oder eigene Hardware eine Investition verdienen.

Diese Seite deutet die Balkenhöhe des RSSI nicht als Duty-Cycle, Durchsatz, Senderleistung, Protokollidentität oder regulatorische Spektralleistung. Sie behauptet auch nicht, dass das Repository ein vollständiges Produktionsdesign, eine Kalibriermethode oder eine ausdrückliche Softwarelizenz bereitstellt.

Halten Sie vor dem Start bereit:

• ein SF32LB52-Display-Board. Das README des Projekts nennt SF32LB52x und ein Ausgabeverzeichnis build_sf32lb52-lchspi-ulp_hcpu; die Liste der unterstützten Boards von SiFli nennt sf32lb52-lchspi-ulp für Huangshan Pi. Erfassen Sie die tatsächliche Board-Revision und prüfen Sie die Build-Konfiguration des Projekts;
• SiFli-SDK, SCons, einen Download-Pfad und die Aufzeichnung des seriellen Logs;
• eine steuerbare 2,4-GHz-Quelle oder mindestens zwei reproduzierbare Szenarien, etwa mit einem ausgewählten BLE-Advertiser, der ein- und ausgeschaltet wird;
• einen kalibrierten Spektrumanalysator oder ein Leistungsmessgerät sowie feste Bedingungen für Antenne, Abstand und Abschirmung, falls quantitative Genauigkeit gefordert ist;
• ein Testprotokoll für Bildschirmzustand, serielle Ausgabe, Board-Ausrichtung, Abstand, Versorgung und Umgebung.

Hardware- und Software-Spezifikationen¶

Hardware-Spezifikation¶

Software-Spezifikation¶

Unterstützte Referenzkonfiguration auswählen¶

Verwenden Sie den festgelegten Projekt-Commit 670cf20 und nicht den beweglichen Branch main. Das README des Projekts nennt build_sf32lb52-lchspi-ulp_hcpu als Ausgabeverzeichnis; die Liste der unterstützten Boards von SiFli nennt sf32lb52-lchspi-ulp für Huangshan Pi / LCHSPI-ULP. Das legt den Boardnamen im SDK fest, nicht den genauen Projektbefehl oder die getestete Board-Bestückung. Das README gibt weder eine Board-Revision noch einen vollständigen SCons-Befehl an; bestätigen Sie daher die Build-Konfiguration des Projekts bei der ersten Reproduktion, statt anzunehmen, dass jedes SF32LB52x-Board unterstützt wird.

Projektphasen und Entscheidungspunkte¶

Systemarchitektur und Abhängigkeiten¶

flowchart LR
    E["2,4-GHz-Umgebung\nmehrere Signalquellen"] --> A["Antenne und RF-Frontend\nKalibrierung nicht festgelegt"]
    A --> R["Bluetooth-Scan-Pfad des SF32LB52\n79-Punkte-Abtastung"]
    R --> S["Glättung laut Projektquelle\nRSSI-Verlauf im Ringpuffer"]
    S --> U["LVGL-Balkendiagramm\n2402–2480 MHz"]
    K["KEY2\nkurz: Start/Stopp, lang: Verlauf"] --> S
    L["Serielles Log und Referenzgerät"] --> V["Validierungsprotokoll"]
    R --> L
    U --> V

Die wesentlichen Fehlerdomänen sind RF-Eingang/Antenne, Scan-Verhalten und Kalibrierung, Datenverarbeitung, Verlaufspuffer, Zustandsautomat der Tasten, LVGL-Zuordnung und Versorgung. Ein hoher Balken bedeutet nur, dass die Implementierung einen relativ starken Empfangswert beobachtet hat; ohne kontrollierten Vergleich identifiziert er weder einen Sender noch eine Modulation noch einen Konformitätszustand.

Phase 1 — Die unveränderte Scan-Basis herstellen¶

Ziel: Nachweisen, dass die gewählte Hardware und Quelle eine wiederholbare 79-Punkte-Anzeige erzeugen.

1. Legen Sie die Commits von Repository und SiFli-SDK, die Board-Revision, die Antenne und den Display-Anschluss fest; bauen und laden Sie sauber herunter.
2. Starten Sie das Gerät bei unveränderter RF-Umgebung und erfassen Sie sein anfängliches Diagramm, die serielle Ausgabe und den Zustand von KEY2.
3. Drücken Sie KEY2 kurz, um den Scan zu starten. Bestätigen Sie Abdeckung und die X-Achsen-Referenzen bei 2402, 2441 und 2480 MHz.
4. Verwenden Sie einen kontrollierten BLE-Advertiser oder eine andere wiederholbare Quelle und erfassen Sie die Messwerte bei ein- und ausgeschalteter Quelle sowie bei verändertem Abstand und veränderter Board-Ausrichtung.
5. Setzen Sie zurück und wiederholen Sie; prüfen Sie, dass das 79-Punkte-Array und das Diagramm nicht verschoben sind und keine veralteten Daten behalten.

Aufzubewahrende Nachweise: Revisionen von Quelle/SDK/Board, Build-/Download-Logs, Beschreibung der Umgebung, Quelleneinstellungen, Abstand/Ausrichtung, serielles Log, Bildschirmaufnahmen und Reset-Ergebnis.

Abnahmekriterium für Kontrollpunkt 1: Bei zwei unabhängigen Starts werden 79 Punkte gescannt und angezeigt. Änderungen der kontrollierten RF-Umgebung schlagen sich im Diagramm reproduzierbar in der jeweiligen Richtung nieder; Display-Indizes und Frequenzbeschriftungen sind geprüft.

Phase 2 — Verarbeitung, Verlauf und Wiederherstellung validieren¶

Ziel: Nachweisen, dass die Benutzeroberfläche einen nachvollziehbaren Datenpfad darstellt und nicht bloß zufällige Balken anzeigt.

Abnahmekriterium für Kontrollpunkt 2: Glättung, Verlaufstiefe, Tastenzustand und Reset-Verhalten entsprechen der Quelle; abnormale Zustände sind sichtbar und bleiben nicht unbemerkt.

Phase 3 — Eine reproduzierbare Quellbasis aufbauen¶

Ziel: Das Image aus Phase 2 in einer sauberen Umgebung reproduzieren.

1. Erfassen Sie Projekt-Commit, SDK-Commit, Host-Betriebssystem, Versionen von SCons/Compiler und das tatsächliche Board-Argument.
2. Entfernen Sie die Build-Ausgabe, konfigurieren Sie neu und bauen Sie erneut; sichern Sie Images, Speicher-/Partitionsausgabe und vollständige Logs.
3. Flashen Sie mit dem erzeugten Download-Skript und erfassen Sie Port, Baudrate und Ergebnis.
4. Wiederholen Sie dies auf einem zweiten Rechner oder in einem sauberen Verzeichnis und führen Sie die zentralen Prüfungen von Phase 2 erneut aus.

Abnahmekriterium für Kontrollpunkt 3: Das Projekt erzeugt ein im Verhalten gleichwertiges Image ohne nicht versionierte Board-Dateien, generierte Dateien oder veraltete Build-Artefakte.

Phase 4 — Eine kontrollierte Mess- oder UI-Anpassung vornehmen¶

Ziel: Eine Produktrichtung testen, ohne die ursprüngliche Basis zu verlieren.

Mögliche Änderungen sind Rohwert-Logging, ausdrückliche 1-MHz-Beschriftungen, Peak-Hold, ein anderer Verlaufsselektor, ein Kalibrier-Offset oder der Host-Export relativer Trends. Ändern Sie jeweils nur eine Klasse und bewahren Sie das ursprüngliche Image auf.

Definieren Sie bei einer Kalibrierung Referenzquelle, Frequenz, Eingangspegel, Antenne/Kabel, Abstand, Ausrichtung, Temperatur und Unsicherheit. Ein einziger globaler Offset reicht selten aus, um Frequenzgang, Board-Streuung und Gehäuseeffekte auszugleichen.

Abnahmekriterium für Kontrollpunkt 4: Die Änderung besteht die ursprünglichen Regressionstests für 79 Punkte, Start/Stopp, Verlauf, Reset und kontrollierte Quelle; jede Genauigkeitsaussage nennt das verwendete Referenzgerät und die Messbedingungen.

Phase 5 — Prüfung der Produktreife¶

Das Team muss beantworten:

• Braucht das Produkt nur relative Störungstrends oder rückführbare absolute RF-Leistung samt Messunsicherheit?
• Ist die Bluetooth-Scan-Implementierung des Projekts für das Ziel-Silizium und das SDK als unterstützt dokumentiert, und welche Grenzen gelten für Parallelbetrieb?
• Wie stark beeinflussen Antenne, Gehäuse, Display-Rauschen, DC/DC-Betrieb, Akkuladestand und Temperatur die Messergebnisse?
• Kann das Produkt während des Scans die erforderliche Bluetooth-Kommunikation aufrechterhalten, oder müssen sich die Funktionen gegenseitig ausschließen?
• Erfüllt die gemessene Latenz eines 79-Punkte-Scans mit quellengeprüfter Glättung die UI-Anforderung?
• Wie werden Vertrieb und kommerzielle Rechte geklärt, wenn RadiationMonitor und eingebundener Code keine ausdrückliche Lizenz auf oberster Ebene haben?

Abnahmekriterium für Kontrollpunkt 5: Für Messziel, Kalibrierplan, Strategie für den Funk-Parallelbetrieb, Lizenzierung sowie Hardware- und Softwareverantwortung sind Verantwortliche benannt und eine Entscheidung zum Fortfahren, Zurückstellen oder Stoppen ist dokumentiert.

Übergabe an das Produktdesign¶

Übernehmen Sie das Ziel-SF32-Gerät, Board/Antenne, die Bluetooth-Scan-Implementierung und alle aus der festgelegten Quelle bestätigten Modus-/API-Einschränkungen, die Frequenz-/Datendefinition, Roh- und geglättete Aufzeichnungen, das UI-Aktualisierungsbudget, den Kalibrieraufbau, Tests des Versorgungsrauschens, den Wiederherstellungspfad und die Grenze des Produktionstests. Fahren Sie fort mit SF32LB52x, SF32LB52-DevKit-ULP, dem Hardware-Design-Leitfaden SF32LB52x und den RF-Leistungstests im SiFli-SDK.

Maßgebliche Quellen¶

• SiFliSparks/RadiationMonitor
• Upstream-README auf main
• Festgelegter Referenz-Commit 670cf20
• Projektkatalog von SiFli Sparks
• OpenSiFli/SiFli-SDK
• Vom SiFli-SDK unterstützte Boards
• RF-Testleitfaden des SiFli-SDK
• Hardware-Überblick SF32LB52x
• Schnellstart SiFli-SDK für SF32LB52x

Zuletzt aktualisiert: 2026-10-21