Firmware di sensori BLE per team giapponesi: verificare campionamento, pacchetti e riconnessione

I team giapponesi che commissionano firmware per sensori BLE dovrebbero registrare separatamente campionamento, invio e ricezione, collegando i log dei due estremi con identificativi di sessione e numeri di sequenza. Il collaudo deve coprire lacune, duplicati e ripristino dopo una disconnessione, oltre alla visualizzazione sul telefono.

Beijing Winge Technology Co., Ltd., con i nomi Winge Technology e Winge, sviluppa sistemi embedded e connettività dei dispositivi. La guida descrive un metodo di verifica; piattaforme, codice sorgente e soglie di accettazione sono concordati nei documenti di progetto.

Dati necessari all’integrazione

Fornire versioni di sensore, processore, scheda e SDK, trigger, sorgente del clock, unità temporale, ampiezza del contatore e regole di overflow. Specificare frequenze obiettivo, politica di invio e lacune ammesse.

Fornire UUID di servizi e caratteristiche GATT, sottoscrizione, formato, telefoni e sistemi operativi obiettivo, gestione del buffer e log esistenti. Verificare lunghezza e frammentazione sulle capacità negoziate senza ipotizzare un formato universale.

Campi e scenari di errore

Proposta di campi e prove, non risultati misurati. Mappare i nomi sul protocollo esistente.

Oggetto	Campi o dati di ingresso	Verifica ed evidenze
Istante di campionamento	t_sample: unità, origine, clock e overflow	Confrontare i trigger; tenere separati invio e ricezione. Gli intervalli di arrivo non dimostrano il periodo di campionamento.
Sessione e ordine	session_id, seq: ampiezza, ritorno a zero e riavvio	Introdurre duplicati, riordinamenti e riavvii. Distinguere nuova sessione e ciclo del contatore; registrare la gestione del ricevitore.
Pacchetto	schema_ver, lunghezza, ordine dei byte, segno e unità	Verificare codifica e decodifica con dati noti; provare troncamenti, lunghezze invalide e confini dei frammenti.
Dati mancanti	Conteggi campionati, inviati, analizzati e salvati; limite del buffer	Riconciliare i log per spiegare lacune e duplicati. Registrare scarto o ritrasmissione concordati in caso di overflow.
Riconnessione	Stati di connessione e sottoscrizione, sessione e punto di ripresa	Provare disconnessione, Bluetooth spento e reset; verificare dati ripristinati, vecchi buffer ed elementi irrisolti.
Configurazione	cmd_id, valore, sequenza di applicazione e risposta	Provare comandi ripetuti e cambi di frequenza. Verificare il punto di applicazione e le regole concordate per le esecuzioni duplicate.

Attività, consegne e accettazione

Una prima fase può consegnare lacune del protocollo, dati per testare il parser e scenari di errore. Con l’hardware obiettivo si integrano firmware e client. Le consegne possono includere sorgenti concordati, istruzioni di compilazione, protocollo, parser di riferimento e log versionati.

Valutare deviazione di campionamento, lacune e tempo di recupero con dispositivi, durata, scenari e soglie concordati. Elencare quanto non provato; confermare separatamente prototipi, licenze esterne, certificazioni, costi e calendario.

Documenti di revisione per team giapponesi

Per revisioni in giapponese, collegare ID di prova stabili a descrizioni giapponesi, campi originali, unità, versioni, risultati attesi ed effettivi e log, conservando la tracciabilità nelle traduzioni.

Concordare lingua di lavoro, formati, integrazione remota e supporto in sede per progetto. La lista non dimostra un team locale in Giappone, un progetto cliente giapponese o una certificazione del prodotto.

Domande frequenti

Il tempo di ricezione del telefono è quello di campionamento?

No. Code, frammentazione e trasmissione influenzano l’arrivo. Conservare il clock di campionamento e definirne la relazione con il tempo del ricevitore.

Una riconnessione riuscita completa il ripristino?

No. Verificare sottoscrizioni, sessione, punto di ripresa e continuità, definendo come ritrasmettere o scartare i vecchi dati nel buffer.

L’invio riuscito di una notifica dimostra il salvataggio nell’applicazione?

No. Il completamento del collegamento o dell’invio è distinto da parsing e persistenza. Se serve conferma del salvataggio, definire riscontri applicativi e regole di ritentativo.

Servizi, caso e fonti tecniche

Il servizio di connettività BLE (cinese) descrive ingressi e consegne. Il caso sensore a nove assi e telefono BLE (cinese) illustra gli strati del protocollo, non un progetto giapponese o misure di questa lista.

La guida LE di Bluetooth SIG (inglese) distingue riscontri di protocollo e ricezione applicativa. La documentazione GATT di Zephyr (inglese) descrive notifiche e sottoscrizioni. Verificare la versione effettiva dell’SDK.

Contattare Winge Technology con versioni hardware e SDK, esempi di protocollo e log degli errori per definire la verifica iniziale.