Dosaggio

Che cos'è il batch?

Il batch si riferisce al buffering degli eventi del sensore in un hub di sensori e/o in una FIFO hardware prima di segnalare gli eventi tramite Sensors HAL . La posizione in cui gli eventi del sensore vengono memorizzati nel buffer (hub del sensore e/o FIFO hardware) è denominata "FIFO" in questa pagina. Quando il batch di eventi del sensore non è attivo, gli eventi del sensore vengono immediatamente segnalati all'HAL dei sensori quando disponibile.

Il batching può consentire risparmi energetici significativi riattivando il processore principale delle applicazioni (AP), che esegue Android, quando molti eventi del sensore sono pronti per essere elaborati, invece di riattivarlo per ogni singolo evento. Il potenziale risparmio energetico è direttamente correlato al numero di eventi che l'hub del sensore e/o la FIFO possono bufferizzare: c'è un maggiore potenziale di risparmio energetico se è possibile raggruppare più eventi. Il batch sfrutta l'uso della memoria a basso consumo per ridurre il numero di riattivazioni AP ad alta potenza.

Il batch può verificarsi solo quando un sensore possiede una FIFO hardware e/o può memorizzare gli eventi all'interno di un hub di sensori. In entrambi i casi, il sensore deve segnalare il numero massimo di eventi che possono essere raggruppati in batch contemporaneamente tramite SensorInfo.fifoMaxEventCount .

Se un sensore dispone di spazio riservato all'interno di una FIFO, il sensore deve segnalare il numero di eventi riservati tramite SensorInfo.fifoReservedEventCount . Se il FIFO è dedicato al sensore, SensorInfo.fifoReservedEventCount è la dimensione del FIFO. Se la FIFO è condivisa tra più sensori, questo valore può essere zero. Un caso d'uso comune consiste nel consentire a un sensore di utilizzare l'intera FIFO se è l'unico sensore attivo. Se sono attivi più sensori, a ciascun sensore è garantito lo spazio per almeno gli eventi SensorInfo.fifoReservedEventCount nella FIFO. Se viene utilizzato un hub sensore, la garanzia può essere applicata tramite software.

Gli eventi del sensore vengono raggruppati nelle seguenti situazioni:

• L'attuale latenza massima del rapporto del sensore è maggiore di zero, il che significa che gli eventi del sensore possono essere ritardati fino alla latenza massima del rapporto prima di essere segnalati tramite l'HAL.
• L'AP è in modalità di sospensione e il sensore è un sensore di non riattivazione. In questo caso, gli eventi non devono riattivare l'AP e devono essere memorizzati fino alla riattivazione dell'AP.

Se un sensore non supporta il batch e l'AP è inattivo, all'AP vengono segnalati solo gli eventi del sensore di riattivazione e gli eventi non di riattivazione non devono essere segnalati all'AP.

Parametri di dosaggio

I due parametri che regolano il comportamento del batch sono sampling_period_ns e max_report_latency_ns . sampling_period_ns determina la frequenza con cui viene generato un nuovo evento del sensore e max_report_latency_ns determina quanto tempo deve trascorrere prima che l'evento venga segnalato all'HAL dei sensori.

campionamento_periodo_ns

Il significato del parametro sampling_period_ns dipende dalla modalità di segnalazione del sensore specificato:

• Continuo: sampling_period_ns è la frequenza di campionamento, ovvero la frequenza con cui vengono generati gli eventi.
• Al cambiamento: sampling_period_ns limita la frequenza di campionamento degli eventi, il che significa che gli eventi vengono generati non più velocemente di ogni sampling_period_ns nanosecondi. I periodi possono essere più lunghi di sampling_period_ns se non viene generato alcun evento e i valori misurati non cambiano per lunghi periodi. Per maggiori dettagli, vedere Modalità di reportistica sulle modifiche .
• One-shot: sampling_period_ns viene ignorato. Non ha effetto.
• Speciale: per i dettagli su come sampling_period_ns viene utilizzato per sensori speciali, vedere Tipi di sensori .

Per ulteriori informazioni sull'impatto di sampling_period_ns nelle diverse modalità, vedere Modalità di reporting .

Per sensori continui e a cambio continuo:

• se sampling_period_ns è inferiore a SensorInfo.minDelay , l'implementazione HAL deve bloccarlo silenziosamente a max(SensorInfo.minDelay, 1ms) . Android non supporta la generazione di eventi a più di 1000 Hz.
• se sampling_period_ns è maggiore di SensorInfo.maxDelay , l'implementazione HAL deve troncarlo automaticamente in SensorInfo.maxDelay .

I sensori fisici a volte hanno limitazioni sulle velocità con cui possono funzionare e sulla precisione dei loro orologi. Per tenere conto di ciò, la frequenza di campionamento effettiva può differire dalla frequenza richiesta purché soddisfi i requisiti nella tabella seguente.

max_report_latenza_ns

max_report_latency_ns imposta il tempo massimo in nanosecondi, entro il quale gli eventi possono essere ritardati e archiviati nella FIFO hardware prima di essere segnalati tramite l'HAL mentre l'AP è attivo.

Un valore zero significa che gli eventi devono essere riportati non appena vengono misurati, saltando del tutto il FIFO o svuotando il FIFO non appena è presente un evento dal sensore.

Ad esempio, un accelerometro attivato a 50 Hz con max_report_latency_ns=0 attiverà gli interrupt 50 volte al secondo quando l'AP è attivo.

Quando max_report_latency_ns>0 , gli eventi del sensore non devono essere segnalati non appena vengono rilevati. Possono essere temporaneamente archiviati nella FIFO e riportati in batch, a condizione che nessun evento sia ritardato di oltre max_report_latency_ns nanosecondi. Ciò significa che tutti gli eventi dal batch precedente vengono registrati e restituiti contemporaneamente. Ciò riduce la quantità di interruzioni inviate all'AP e consente all'AP di passare a una modalità di alimentazione inferiore (inattiva) mentre il sensore sta acquisendo e raggruppando i dati.

Ad ogni evento è associato un timestamp. Il ritardo dell'ora in cui viene segnalato un evento non influisce sul timestamp dell'evento. Il timestamp deve essere accurato e corrispondere all'ora in cui l'evento si è verificato fisicamente, non all'ora in cui è stato segnalato.

Consentire la memorizzazione temporanea degli eventi del sensore nella FIFO non modifica il comportamento di invio degli eventi all'HAL; gli eventi di sensori diversi possono essere intercalati e tutti gli eventi dello stesso sensore sono ordinati nel tempo.

Eventi di risveglio e non risveglio

Gli eventi dei sensori dei sensori di sveglia devono essere memorizzati in uno o più FIFO di sveglia. Un progetto comune consiste nell'avere un FIFO di risveglio unico, grande e condiviso in cui gli eventi di tutti i sensori di risveglio sono intercalati. In alternativa, puoi avere un FIFO di risveglio per sensore o FIFO dedicati per particolari sensori di risveglio e un FIFO condiviso per il resto dei sensori di risveglio.

Allo stesso modo, gli eventi dei sensori dei sensori di non riattivazione devono essere archiviati in uno o più FIFO di non riattivazione.

In tutti i casi, gli eventi del sensore di riattivazione e gli eventi del sensore di non riattivazione non possono essere intercalati nella stessa FIFO. Gli eventi di riattivazione devono essere archiviati in una FIFO di riattivazione e gli eventi di non riattivazione devono essere archiviati in una FIFO di non riattivazione.

Per la FIFO sveglia, il design FIFO singolo, grande e condiviso offre i migliori vantaggi in termini di potenza. Per la FIFO senza riattivazione, la FIFO condivisa di grandi dimensioni e diversi FIFO riservati piccoli hanno caratteristiche di potenza simili. Per ulteriori suggerimenti su come configurare ogni FIFO, vedere Priorità di allocazione FIFO .

Comportamento al di fuori della modalità di sospensione

Quando l'AP è attivo (non in modalità di sospensione), gli eventi vengono archiviati temporaneamente in FIFO purché non siano ritardati di oltre max_report_latency .

Finché l'AP non entra in modalità di sospensione, nessun evento verrà eliminato o perso. Se le FIFO interne si riempiono prima della scadenza di max_report_latency , gli eventi vengono segnalati a quel punto per garantire che nessun evento venga perso.

Se più sensori condividono la stessa FIFO e trascorre la max_report_latency di uno di essi, tutti gli eventi della FIFO vengono riportati, anche se la max_report_latency degli altri sensori non è ancora trascorsa. Ciò riduce il numero di segnalazioni di batch di eventi. Quando è necessario segnalare un evento, vengono segnalati tutti gli eventi di tutti i sensori.

Ad esempio, se sono attivati ​​i seguenti sensori:

• accelerometro in batch con max_report_latency = 20s
• giroscopio in batch con max_report_latency = 5s

I lotti dell'accelerometro vengono riportati contemporaneamente ai lotti del giroscopio (ogni 5 secondi), anche se l'accelerometro e il giroscopio non condividono la stessa FIFO.

Comportamento in modalità di sospensione

Il batch è particolarmente vantaggioso per la raccolta dei dati dei sensori in background senza mantenere l'AP attivo. Poiché i driver del sensore e l'implementazione HAL non possono mantenere un wake-lock*, l'AP può entrare in modalità di sospensione anche durante la raccolta dei dati del sensore.

Il comportamento dei sensori mentre l'AP è sospeso dipende dal fatto che il sensore sia un sensore di sveglia. Per maggiori dettagli, vedere Sensori di sveglia .

Quando una FIFO non attiva si riempie, deve avvolgersi e comportarsi come un buffer circolare, sovrascrivendo gli eventi più vecchi con i nuovi eventi che sostituiscono quelli vecchi. max_report_latency non ha alcun impatto sui FIFO non attivati ​​durante la modalità di sospensione.

Quando una FIFO di riattivazione si riempie, o quando scade il max_report_latency di uno dei sensori di riattivazione, l'hardware deve riattivare l'AP e riportare i dati.

In entrambi i casi (wake-up e non-wake-up), non appena l'AP esce dalla modalità di sospensione, viene prodotto un batch con il contenuto di tutte le FIFO, anche se max_report_latency di alcuni sensori non è ancora trascorsa. Ciò riduce al minimo il rischio che l'AP si debba riattivare subito dopo essere tornato in modalità di sospensione e, quindi, riduce al minimo il consumo energetico.

*Una notevole eccezione per i conducenti che non possono tenere un wakelock è quando un sensore di risveglio con la modalità di segnalazione continua viene attivato con max_report_latency < 1 secondo. In questo caso, il conducente può tenere un wakelock perché l'AP non ha il tempo di entrare in modalità di sospensione, poiché verrebbe svegliato da un evento di risveglio prima di raggiungere la modalità di sospensione.

Precauzioni da adottare durante il dosaggio dei sensori di sveglia

A seconda del dispositivo, potrebbero essere necessari alcuni millisecondi prima che l'AP esca completamente dalla modalità di sospensione e inizi a svuotare la FIFO. È necessario allocare spazio sufficiente nella FIFO per consentire al dispositivo di uscire dalla modalità di sospensione senza che la FIFO di riattivazione trabocchi. Nessun evento andrà perso e la max_report_latency deve essere rispettata.

Precauzioni da adottare durante il dosaggio dei sensori di cambio non-wake-up

I sensori al cambio generano eventi solo quando il valore che stanno misurando sta cambiando. Se il valore misurato cambia mentre l'AP è in modalità di sospensione, le applicazioni si aspettano di ricevere un evento non appena l'AP si riattiva. Per questo motivo, il batching degli eventi del sensore di cambio non riattivato deve essere eseguito con attenzione se il sensore condivide il suo FIFO con altri sensori. L'ultimo evento generato da ciascun sensore di cambio deve essere sempre salvato al di fuori della FIFO condivisa in modo che non possa mai essere sovrascritto da altri eventi. Quando l'AP si riattiva, dopo che tutti gli eventi dalla FIFO sono stati segnalati, deve essere segnalato l'ultimo evento del sensore di cambio.

Ecco una situazione da evitare:

1. Un'applicazione si registra al contapassi di non riattivazione (al cambio) e all'accelerometro di non riattivazione (continuo), condividendo entrambi lo stesso FIFO.
2. L'applicazione riceve un evento step_count=1000 steps >.
3. L'AP va in sospensione.
4. L'utente percorre 20 passi, provocando l'interlacciamento degli eventi del contatore di passi e dell'accelerometro, l'ultimo evento del contatore di passi è step_count = 1020 steps .
5. L'utente non si muove per molto tempo, facendo sì che gli eventi dell'accelerometro continuino ad accumularsi nella FIFO, alla fine sovrascrivendo ogni evento step_count nella FIFO condivisa.
6. AP si sveglia e tutti gli eventi della FIFO vengono inviati all'applicazione.
7. L'applicazione riceve solo gli eventi dell'accelerometro e pensa che l'utente non abbia camminato.

Salvando l'ultimo evento del contapassi al di fuori del FIFO, l'HAL può segnalare questo evento quando l'AP si riattiva, anche se tutti gli altri eventi del contapassi sono stati sovrascritti dagli eventi dell'accelerometro. In questo modo, l'applicazione riceve step_count = 1020 steps quando l'AP si riattiva.

Implementazione del dosaggio

Per risparmiare energia, il batching deve essere implementato senza l'ausilio dell'AP e l'AP deve poter essere sospeso durante il batching.

Se il batching viene eseguito in un hub sensore, il consumo energetico dell'hub sensore dovrebbe essere ridotto al minimo.

La latenza massima del report può essere modificata in qualsiasi momento, in particolare mentre il sensore specificato è già abilitato; e questo non dovrebbe comportare la perdita di eventi.

Priorità di assegnazione FIFO

Sulle piattaforme in cui la dimensione del buffer della FIFO hardware e/o dell'hub del sensore è limitata, i progettisti di sistema potrebbero dover scegliere la quantità di FIFO da riservare per ciascun sensore. Per aiutare in questa scelta, ecco un elenco di possibili applicazioni quando il dosaggio viene implementato sui diversi sensori.

Valore elevato: calcolo morto pedonale a bassa potenza

Tempo di dosaggio target: da 1 a 10 minuti

Sensori per batch:

• Rilevatore di passi di sveglia
• Vettore di rotazione del gioco di sveglia a 5 Hz
• Barometro della sveglia a 5 Hz
• Magnetometro di sveglia non calibrato a 5 Hz

La raccolta in batch di questi dati consente di eseguire il calcolo morto del pedone lasciando che l'AP vada in sospensione.

Valore elevato: riconoscimento di attività/gesti intermittenti di media potenza

Tempo di dosaggio target: 3 secondi

Sensori da inserire in batch: Accelerometro non-wake-up a 50 Hz

Il raggruppamento di questi dati consente di riconoscere periodicamente attività e gesti arbitrari senza dover mantenere l'AP attivo durante la raccolta dei dati.

Valore medio: Riconoscimento continuo di attività/gesti di media potenza

Tempo di dosaggio target: da 1 a 3 minuti

Sensori per batch: Accelerometro di sveglia a 50 Hz

La raccolta in batch di questi dati consente di riconoscere continuamente attività e gesti arbitrari senza dover mantenere l'AP attivo durante la raccolta dei dati.

Valore medio-alto: Interrompere la riduzione del carico

Tempo di dosaggio target: < 1 secondo

Sensori per batch: qualsiasi sensore ad alta frequenza, di solito non sveglia.

Se il giroscopio è impostato a 240 Hz, anche il batch di soli 10 eventi giroscopici può ridurre il numero di interruzioni da 240/secondo a 24/secondo.

Valore medio: raccolta continua di dati a bassa frequenza

Tempo di dosaggio target: da 1 a 10 minuti

Sensori per batch:

• Barometro della sveglia a 1 Hz
• Sensore di umidità di sveglia a 1 Hz
• Altri sensori di sveglia a bassa frequenza a velocità simili

Consente di creare applicazioni di monitoraggio a bassa potenza.

Valore medio-basso: Raccolta continua full-sensors

Tempo di dosaggio target: da 1 a 10 minuti

Sensori in batch: tutti i sensori di sveglia, ad alta frequenza

Consente la raccolta completa dei dati del sensore lasciando l'AP in modalità di sospensione. Considera solo se lo spazio FIFO non è un problema.