BLE-Sensor-Firmware für japanische Teams: Abtastzeit, Datenpakete und Wiederverbindung prüfen

Japanische Teams sollten bei der Beauftragung von BLE-Sensor-Firmware Abtast-, Sende- und Empfangszeit getrennt erfassen und die Protokolle beider Seiten über Sitzungskennungen und Sequenznummern zuordnen. Die Abnahme muss Datenlücken, Duplikate und die Wiederaufnahme nach Verbindungsabbrüchen abdecken; angezeigte Messwerte allein reichen nicht aus.

Beijing Winge Technology Co., Ltd. bietet unter Winge Technology und Winge Entwicklung für eingebettete Systeme und Geräteanbindung an. Dieser Leitfaden beschreibt eine Prüfmethode. Plattformen, Quellcodeumfang und Abnahmegrenzen werden in den Projektunterlagen vereinbart.

Eingaben für die Integration

Sensor-, Prozessor-, Platinen- und SDK-Versionen sowie Abtasttrigger, Taktquelle, Zeiteinheit, Zählerbreite und Überlaufregeln bereitstellen. Zielabtastraten, Sendestrategie und zulässige Datenlücken festlegen.

GATT-Service- und Characteristic-UUIDs, Abonnementablauf, Datenformat, Zieltelefone und Betriebssystemversionen, Pufferstrategie und vorhandene Protokolle bereitstellen. Paketlänge und Fragmentierung anhand der ausgehandelten Fähigkeiten prüfen, statt eine einheitliche Länge anzunehmen.

Datenfelder und Fehlerszenarien

Vorgeschlagene Feld- und Prüfliste, keine Messergebnisse. Feldnamen dem vorhandenen Protokoll zuordnen.

Gegenstand	Felder oder Eingaben	Prüfung und Nachweis
Abtastzeit	t_sample: Einheit, Bezugspunkt, Takt und Überlauf	Mit Triggeraufzeichnungen vergleichen; Sende- und Empfangszeiten getrennt halten. Ankunftsabstände belegen keine Abtastperiode.
Sitzung und Reihenfolge	session_id, seq: Breite, Umlauf und Neustartregeln	Duplikate, vertauschte Reihenfolge und Neustarts einspeisen. Neue Sitzungen vom Zählerumlauf unterscheiden; Empfängerverhalten protokollieren.
Datenpaket	schema_ver, Länge, Byte-Reihenfolge, Vorzeichen und Einheiten	Kodierung und Dekodierung mit bekannten Daten prüfen; abgeschnittene Pakete, ungültige Längen und Fragmentgrenzen testen.
Datenlücken	Anzahlen abgetastet, gesendet, geparst und gespeichert; Puffergrenze	Beide Protokolle auf Lücken und Duplikate abgleichen. Vereinbartes Verwerfen oder Nachsenden bei Pufferüberlauf dokumentieren.
Wiederverbindung	Verbindungs- und Abonnementstatus, Sitzung und Fortsetzungspunkt	Abbruch, ausgeschaltetes Bluetooth und Gerätereset testen; wiederhergestellte Daten, alte Puffer und offene Punkte prüfen.
Konfiguration	cmd_id, Wert, wirksame Sequenz und Antwort	Wiederholte Befehle und Ratenwechsel testen. Wirksamkeitszeitpunkt und vereinbarte Behandlung doppelter Ausführung prüfen.

Arbeitspakete, Ergebnisse und Abnahme

Ein erstes Arbeitspaket kann Protokolllücken, Parser-Testdaten und Fehlerszenarien liefern. Firmware und Client werden mit verfügbarer Zielhardware integriert. Vereinbarte Ergebnisse können Quellcode, Build-Anleitung, Protokoll, Parserreferenz und versionierte Testprotokolle umfassen.

Abtastabweichung, Datenlücken und Wiederherstellungszeit für vereinbarte Geräte, Dauer, Szenarien und Grenzwerte prüfen. Ungetestetes ausweisen; Prototypen, Fremdlizenzen, Zertifizierungsprüfungen, Kosten und Termine gesondert bestätigen.

Prüfunterlagen für japanische Teams

Für japanische Prüfunterlagen stabile Test-IDs mit japanischen Beschreibungen, Originalfeldern, Einheiten, Versionen, Soll- und Ist-Ergebnissen sowie Protokollen verknüpfen. So bleiben Nachweise bei Übersetzungen zuordenbar.

Arbeitssprache, Dateiformate, Fernintegration und Vor-Ort-Unterstützung je Projekt vereinbaren. Die Liste belegt weder ein Team vor Ort in Japan noch ein japanisches Kundenprojekt oder eine Produktzertifizierung.

Häufige Fragen

Ist die Empfangszeit am Telefon die Abtastzeit?

Nein. Warteschlangen, Fragmentierung und Übertragung beeinflussen die Ankunft. Die Abtastuhr des Geräts erhalten und ihre Zuordnung zur Empfängerzeit festlegen.

Ist nach erfolgreicher Wiederverbindung alles wiederhergestellt?

Nein. Abonnements, Sitzung, Fortsetzungspunkt und Datenkontinuität prüfen; Regeln zum Nachsenden oder Verwerfen alter Pufferdaten ausdrücklich festlegen.

Belegt erfolgreiches Senden einer Benachrichtigung die Speicherung in der Anwendung?

Nein. Verbindungs- oder Sendeabschluss ist von Parsing und dauerhafter Speicherung zu unterscheiden. Bei benötigtem Speichernachweis Anwendungsbestätigungen und Wiederholungsregeln definieren.

Leistungen, Fallbeispiel und technische Quellen

BLE-Geräteanbindung (Chinesisch) beschreibt Eingaben und Ergebnisse. Das Neunachsensensor-BLE-Fallbeispiel (Chinesisch) erläutert Protokollschichten, kein Japanprojekt oder Messergebnis dieser Prüfliste.

Der Bluetooth-SIG-LE-Leitfaden (Englisch) unterscheidet Protokollbestätigungen vom Anwendungsempfang. Die Zephyr-GATT-Dokumentation (Englisch) beschreibt Benachrichtigungs- und Abonnement-APIs. Die eingesetzte SDK-Version bleibt maßgeblich.

Winge Technology kontaktieren: Hardware- und SDK-Versionen, Protokollbeispiele und Fehlerprotokolle für den ersten Prüfumfang bereitstellen.