Pengelompokan

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Apa yang dimaksud dengan pengelompokan?

Pengelompokan mengacu pada buffering peristiwa sensor di hub sensor dan/atau FIFO hardware sebelum melaporkan peristiwa melalui Sensor HAL. Lokasi tempat peristiwa sensor di-buffer (hub sensor dan/atau FIFO hardware) disebut sebagai "FIFO" di halaman ini. Jika pengelompokan peristiwa sensor tidak aktif, peristiwa sensor akan segera dilaporkan ke Sensors HAL jika tersedia.

Pengelompokan dapat menghemat daya secara signifikan dengan hanya mengaktifkan prosesor aplikasi utama (AP), yang menjalankan Android, saat banyak peristiwa sensor siap diproses, bukan mengaktifkannya untuk setiap peristiwa. Potensi penghematan daya berkorelasi langsung dengan jumlah peristiwa yang dapat di-buffer oleh hub sensor dan/atau FIFO: ada potensi penghematan daya yang lebih besar jika lebih banyak peristiwa yang dapat dikelompokkan. Pengelompokan memanfaatkan penggunaan memori daya rendah untuk mengurangi jumlah pengaktifan AP daya tinggi.

Pengelompokan hanya dapat terjadi jika sensor memiliki FIFO hardware dan/atau dapat melakukan buffering peristiwa dalam hub sensor. Dalam kedua kasus tersebut, sensor harus melaporkan jumlah maksimum peristiwa yang dapat dikelompokkan sekaligus melalui SensorInfo.fifoMaxEventCount.

Jika sensor memiliki ruang yang dicadangkan dalam FIFO, sensor harus melaporkan jumlah peristiwa yang dicadangkan melalui SensorInfo.fifoReservedEventCount. Jika FIFO dikhususkan untuk sensor, SensorInfo.fifoReservedEventCount adalah ukuran FIFO. Jika FIFO digunakan bersama oleh beberapa sensor, nilai ini mungkin nol. Kasus penggunaan umum adalah mengizinkan sensor menggunakan seluruh FIFO jika sensor tersebut adalah satu-satunya sensor yang aktif. Jika beberapa sensor aktif, setiap sensor akan dijamin ruangnya untuk setidaknya SensorInfo.fifoReservedEventCount peristiwa dalam FIFO. Jika hub sensor digunakan, jaminan dapat diterapkan melalui software.

Peristiwa sensor dikelompokkan dalam batch pada situasi berikut:

• Latensi laporan maksimum sensor saat ini lebih besar dari nol, yang berarti peristiwa sensor dapat tertunda hingga latensi laporan maksimum sebelum dilaporkan melalui HAL.
• AP berada dalam mode penangguhan dan sensornya adalah sensor non-wake-up. Dalam hal ini, peristiwa tidak boleh mengaktifkan AP dan harus disimpan hingga AP aktif kembali.

Jika sensor tidak mendukung pengelompokan dan AP sedang tidur, hanya peristiwa sensor bangun yang dilaporkan ke AP dan peristiwa non-bangun tidak boleh dilaporkan ke AP.

Parameter pengelompokan

Dua parameter yang mengatur perilaku pengelompokan adalah sampling_period_ns dan max_report_latency_ns. sampling_period_ns menentukan seberapa sering peristiwa sensor baru dihasilkan, dan max_report_latency_ns menentukan berapa lama hingga peristiwa harus dilaporkan ke Sensors HAL.

sampling_period_ns

Arti parameter sampling_period_ns bergantung pada mode pelaporan sensor yang ditentukan:

• Terus-menerus: sampling_period_ns adalah frekuensi sampling, yang berarti kecepatan peristiwa dibuat.
• Saat berubah: sampling_period_ns membatasi frekuensi pengambilan sampel peristiwa, yang berarti peristiwa dihasilkan tidak lebih cepat dari setiap sampling_period_ns nanodetik. Periode dapat lebih lama dari sampling_period_ns jika tidak ada peristiwa yang dihasilkan dan nilai yang diukur tidak berubah dalam jangka waktu yang lama. Untuk mengetahui detail selengkapnya, lihat mode pelaporan on-change.
• Satu kali: sampling_period_ns diabaikan. Tindakan ini tidak berpengaruh.
• Khusus: Untuk mengetahui detail tentang cara sampling_period_ns digunakan untuk sensor khusus, lihat Jenis Sensor.

Untuk informasi selengkapnya tentang dampak sampling_period_ns dalam berbagai mode, lihat Mode pelaporan.

Untuk sensor berkelanjutan dan saat berubah:

• jika sampling_period_ns kurang dari SensorInfo.minDelay, implementasi HAL harus diam-diam membatasinya ke max(SensorInfo.minDelay, 1ms). Android tidak mendukung pembuatan peristiwa dengan frekuensi lebih dari 1.000 Hz.
• jika sampling_period_ns lebih besar dari SensorInfo.maxDelay, implementasi HAL harus secara otomatis memotongnya menjadi SensorInfo.maxDelay.

Sensor fisik terkadang memiliki batasan pada kecepatan yang dapat dijalankan dan akurasi jamnya. Untuk memperhitungkannya, frekuensi pengambilan sampel yang sebenarnya dapat berbeda dengan frekuensi yang diminta selama memenuhi persyaratan dalam tabel di bawah.

Jika frekuensi yang diminta adalah	Kemudian, frekuensi sebenarnya harus
di bawah frekuensi minimum (<1/maxDelay)	antara 90% dan 110% dari frekuensi minimum
antara frekuensi min dan maks	antara 90% dan 220% dari frekuensi yang diminta
di atas frekuensi maksimum (>1/minDelay)	antara 90% dan 110% dari frekuensi maksimum, dan di bawah 1.100 Hz

max_report_latency_ns

max_report_latency_ns menetapkan waktu maksimum dalam nanodetik, sehingga peristiwa dapat tertunda dan disimpan di FIFO hardware sebelum dilaporkan melalui HAL saat AP aktif.

Nilai nol menunjukkan bahwa peristiwa harus dilaporkan segera setelah diukur, baik dengan melewati FIFO sepenuhnya, atau mengosongkan FIFO begitu satu peristiwa dari sensor muncul.

Misalnya, akselerometer yang diaktifkan pada 50 Hz dengan max_report_latency_ns=0 akan memicu interupsi 50 kali per detik saat AP aktif.

Jika max_report_latency_ns>0, peristiwa sensor tidak perlu dilaporkan segera setelah terdeteksi. Peristiwa tersebut dapat disimpan sementara di FIFO dan dilaporkan dalam batch, selama tidak ada peristiwa yang tertunda lebih dari max_report_latency_ns nanodetik. Artinya, semua peristiwa sejak batch sebelumnya dicatat dan ditampilkan sekaligus. Hal ini mengurangi jumlah interupsi yang dikirim ke AP dan memungkinkan AP beralih ke mode daya yang lebih rendah (tidak ada aktivitas) saat sensor mengambil dan mengelompokkan data.

Setiap peristiwa memiliki stempel waktu yang terkait dengannya. Menunda waktu saat peristiwa dilaporkan tidak memengaruhi stempel waktu peristiwa. Stempel waktu harus akurat dan sesuai dengan waktu terjadinya peristiwa secara fisik, bukan waktu peristiwa dilaporkan.

Mengizinkan peristiwa sensor disimpan sementara di FIFO tidak mengubah perilaku pengiriman peristiwa ke HAL; peristiwa dari sensor yang berbeda dapat diselang-seling dan semua peristiwa dari sensor yang sama diurutkan berdasarkan waktu.

Peristiwa bangun dan non-bangun

Peristiwa sensor dari sensor wake-up harus disimpan dalam satu atau beberapa FIFO wake-up. Desain umum adalah memiliki satu FIFO wake-up besar bersama tempat peristiwa dari semua sensor wake-up diselang-seling. Atau, Anda dapat memiliki satu FIFO wake-up per sensor atau memiliki FIFO khusus untuk sensor wake-up tertentu dan FIFO bersama untuk sensor wake-up lainnya.

Demikian pula, peristiwa sensor dari sensor non-wake-up harus disimpan di satu atau beberapa FIFO non-wake-up.

Dalam semua kasus, peristiwa sensor wake-up dan peristiwa sensor non-wake-up tidak dapat disisipkan dalam FIFO yang sama. Peristiwa wake-up harus disimpan dalam FIFO wake-up, dan peristiwa non-wake-up harus disimpan dalam FIFO non-wake-up.

Untuk FIFO bangun, desain FIFO tunggal yang besar dan bersama memberikan manfaat daya terbaik. Untuk FIFO non-wake-up, satu FIFO bersama besar dan beberapa desain FIFO yang dicadangkan kecil memiliki karakteristik daya yang serupa. Untuk saran selengkapnya tentang cara mengonfigurasi setiap FIFO, lihat Prioritas alokasi FIFO.

Perilaku di luar mode penangguhan

Saat AP aktif (tidak dalam mode penangguhan), peristiwa disimpan untuk sementara di FIFO selama tidak tertunda lebih dari max_report_latency.

Selama AP tidak memasuki mode penangguhan, tidak ada peristiwa yang akan dihapus atau hilang. Jika FIFO internal penuh sebelum max_report_latency berlalu, peristiwa akan dilaporkan pada saat itu untuk memastikan tidak ada peristiwa yang hilang.

Jika beberapa sensor menggunakan FIFO yang sama dan max_report_latency salah satunya telah berlalu, semua peristiwa dari FIFO akan dilaporkan, meskipun max_report_latency sensor lainnya belum berlalu. Hal ini mengurangi frekuensi batch peristiwa dilaporkan. Jika satu peristiwa harus dilaporkan, semua peristiwa dari semua sensor akan dilaporkan.

Misalnya, jika sensor berikut diaktifkan:

• akselerometer yang dikelompokkan dengan max_report_latency = 20 detik
• giroskop yang dikelompokkan dengan max_report_latency = 5 detik

Batch akselerometer dilaporkan pada saat yang sama dengan batch giroskop dilaporkan (setiap 5 detik), meskipun akselerometer dan giroskop tidak memiliki FIFO yang sama.

Perilaku dalam mode penangguhan

Pengelompokan sangat bermanfaat untuk mengumpulkan data sensor di latar belakang tanpa membuat AP tetap aktif. Karena driver sensor dan penerapan HAL tidak diizinkan untuk menahan wake-lock*, AP dapat memasuki mode penangguhan bahkan saat data sensor sedang dikumpulkan.

Perilaku sensor saat AP ditangguhkan bergantung pada apakah sensor tersebut adalah sensor wake-up. Untuk mengetahui detail selengkapnya, lihat Sensor bangun.

Saat FIFO non-wake-up terisi penuh, FIFO tersebut harus digabungkan dan berperilaku seperti buffering melingkar, menimpa peristiwa lama dengan peristiwa baru yang menggantikan peristiwa lama. max_report_latency tidak berdampak pada FIFO non-wake-up saat dalam mode penangguhan.

Saat FIFO bangun terisi penuh, atau saat max_report_latency salah satu sensor bangun berlalu, hardware harus membangunkan AP dan melaporkan data.

Dalam kedua kasus tersebut (wake-up dan non-wake-up), segera setelah AP keluar dari mode penangguhan, batch akan dihasilkan dengan konten semua FIFO, meskipun max_report_latency dari beberapa sensor belum berlalu. Hal ini meminimalkan risiko AP harus aktif kembali segera setelah kembali ke mode penangguhan, sehingga meminimalkan konsumsi daya.

*Salah satu pengecualian penting dari driver yang tidak diizinkan untuk menahan kunci layar saat aktif adalah saat sensor bangun dengan mode pelaporan berkelanjutan diaktifkan dengan max_report_latency < 1 detik. Dalam hal ini, driver dapat menahan kunci layar aktif karena AP tidak memiliki waktu untuk masuk ke mode penangguhan, karena akan diaktifkan oleh peristiwa pengaktifan sebelum mencapai mode penangguhan.

Tindakan pencegahan saat mengelompokkan sensor bangun

Bergantung pada perangkat, mungkin perlu waktu beberapa milidetik agar AP keluar dari mode penangguhan sepenuhnya dan mulai menghapus FIFO. Head room yang memadai harus dialokasikan di FIFO agar perangkat dapat keluar dari mode penangguhan tanpa FIFO wake-up yang meluap. Tidak ada peristiwa yang akan hilang, dan max_report_latency harus dihormati.

Langkah-langkah pencegahan saat mengelompokkan sensor non-wake-up on-change

Sensor saat berubah hanya menghasilkan peristiwa saat nilai yang diukurnya berubah. Jika nilai yang diukur berubah saat AP dalam mode penangguhan, aplikasi akan menerima peristiwa segera setelah AP aktif. Oleh karena itu, pengelompokan peristiwa sensor saat perubahan non-wake-up harus dilakukan dengan hati-hati jika sensor berbagi FIFO dengan sensor lain. Peristiwa terakhir yang dihasilkan oleh setiap sensor on-change harus selalu disimpan di luar FIFO bersama sehingga tidak akan pernah ditimpa oleh peristiwa lain. Saat AP aktif, setelah semua peristiwa dari FIFO dilaporkan, peristiwa sensor saat perubahan terakhir harus dilaporkan.

Berikut adalah situasi yang harus dihindari:

1. Aplikasi mendaftar ke penghitung langkah non-wake-up (saat berubah) dan akselerometer non-wake-up (terus-menerus), yang keduanya berbagi FIFO yang sama.
2. Aplikasi menerima peristiwa penghitung langkah step_count=1000 stepscode>.
3. AP akan ditangguhkan.
4. Pengguna berjalan 20 langkah, menyebabkan peristiwa penghitung langkah dan akselerometer saling tumpang-tindih, peristiwa penghitung langkah terakhir adalah step_count = 1020 steps.
5. Pengguna tidak bergerak dalam waktu yang lama, sehingga peristiwa akselerometer terus terakumulasi di FIFO, yang pada akhirnya menimpa setiap peristiwa step_count di FIFO bersama.
6. AP akan aktif dan semua peristiwa dari FIFO akan dikirim ke aplikasi.
7. Aplikasi hanya menerima peristiwa akselerometer dan menganggap bahwa pengguna tidak berjalan.

Dengan menyimpan peristiwa penghitung langkah terakhir di luar FIFO, HAL dapat melaporkan peristiwa ini saat AP aktif, meskipun semua peristiwa penghitung langkah lainnya ditimpa oleh peristiwa akselerometer. Dengan cara ini, aplikasi akan menerima step_count = 1020 steps saat AP aktif.

Menerapkan pengelompokan

Untuk menghemat daya, pengelompokan harus diterapkan tanpa bantuan AP, dan AP harus diizinkan untuk ditangguhkan selama pengelompokan.

Jika pengelompokan dilakukan di hub sensor, penggunaan daya hub sensor harus diminimalkan.

Latensi laporan maksimum dapat diubah kapan saja, terutama saat sensor yang ditentukan sudah diaktifkan; dan hal ini tidak akan menyebabkan hilangnya peristiwa.

Prioritas alokasi FIFO

Pada platform dengan ukuran buffer FIFO hardware dan/atau hub sensor yang terbatas, desainer sistem mungkin harus memilih jumlah FIFO yang akan dicadangkan untuk setiap sensor. Untuk membantu pilihan ini, berikut adalah daftar kemungkinan aplikasi saat pengelompokan diterapkan pada berbagai sensor.

Nilai tinggi: Dead reckoning pejalan kaki berdaya rendah

Waktu pengelompokan target: 1 hingga 10 menit

Sensor untuk batch:

• Detektor langkah bangun
• Vektor rotasi game bangun pada 5 Hz
• Barometer bangun tidur pada 5 Hz
• Mengaktifkan magnetometer yang tidak dikalibrasi pada 5 Hz

Dengan mengelompokkan data ini, Anda dapat melakukan dead reckoning pejalan kaki sekaligus membiarkan AP ditangguhkan.

Nilai tinggi: Pengenalan aktivitas/gestur intermiten daya sedang

Waktu pengelompokan target: 3 detik

Sensor untuk batch: Akselerometer non-wake-up pada 50 Hz

Dengan mengelompokkan data ini, Anda dapat mengenali aktivitas dan gestur arbitrer secara berkala tanpa harus membuat AP tetap aktif saat data dikumpulkan.

Nilai sedang: Pengenalan aktivitas/gestur berkelanjutan dengan daya sedang

Waktu pengelompokan target: 1 hingga 3 menit

Sensor untuk batch: Akselerometer bangun pada 50 Hz

Dengan mengelompokkan data ini, Anda dapat terus mengenali aktivitas dan gestur arbitrer tanpa harus membuat AP tetap aktif saat data dikumpulkan.

Nilai sedang-tinggi: Pengurangan beban interupsi

Target waktu pengelompokan: < 1 detik

Sensor untuk batch: sensor frekuensi tinggi, biasanya non-wake-up.

Jika giroskop disetel pada 240 Hz, bahkan pengelompokan hanya 10 peristiwa giroskop dapat mengurangi jumlah interupsi dari 240/detik menjadi 24/detik.

Nilai sedang: Pengumpulan data frekuensi rendah yang berkelanjutan

Target waktu pengelompokan: 1 hingga 10 menit

Sensor untuk batch:

• Barometer bangun tidur pada 1 Hz
• Sensor kelembapan aktivasi pada 1 Hz
• Sensor aktivasi frekuensi rendah lainnya dengan kecepatan yang serupa

Memungkinkan pembuatan aplikasi pemantauan dengan daya rendah.

Nilai sedang-rendah: Pengumpulan sensor penuh berkelanjutan

Target waktu pengelompokan: 1 hingga 10 menit

Sensor untuk batch: Semua sensor pengaktifan, pada frekuensi tinggi

Mengizinkan pengumpulan data sensor secara penuh sambil membiarkan AP dalam mode penangguhan. Hanya pertimbangkan jika ruang FIFO tidak menjadi masalah.