Pengelompokan

Apa itu pengelompokan?

Batching mengacu pada buffering kejadian sensor di hub sensor dan/atau FIFO perangkat keras sebelum melaporkan kejadian tersebut melalui Sensor HAL . Lokasi di mana peristiwa sensor di-buffer (hub sensor dan/atau FIFO perangkat keras) disebut sebagai "FIFO" di halaman ini. Ketika pengelompokan peristiwa sensor tidak aktif, peristiwa sensor segera dilaporkan ke Sensor HAL bila tersedia.

Batching dapat menghemat daya secara signifikan dengan hanya mengaktifkan prosesor aplikasi utama (AP), yang menjalankan Android, ketika banyak peristiwa sensor siap diproses, alih-alih membangunkannya untuk setiap peristiwa individual. Potensi penghematan daya berkorelasi langsung dengan jumlah peristiwa yang dapat disangga oleh hub sensor dan/atau FIFO: ada potensi penghematan daya yang lebih besar jika lebih banyak peristiwa dapat digabungkan. Batching memanfaatkan penggunaan memori berdaya rendah untuk mengurangi jumlah pengaktifan AP berdaya tinggi.

Batching hanya dapat terjadi ketika sensor memiliki FIFO perangkat keras dan/atau dapat melakukan buffering peristiwa dalam hub sensor. Dalam kedua kasus tersebut, sensor harus melaporkan jumlah maksimum peristiwa yang dapat dikumpulkan sekaligus melalui SensorInfo.fifoMaxEventCount .

Jika sensor memiliki ruang yang dicadangkan dalam FIFO, sensor harus melaporkan jumlah peristiwa yang dicadangkan melalui SensorInfo.fifoReservedEventCount . Jika FIFO didedikasikan untuk sensor, maka SensorInfo.fifoReservedEventCount adalah ukuran FIFO. Jika FIFO dibagikan ke beberapa sensor, nilai ini mungkin nol. Kasus penggunaan yang umum adalah mengizinkan sensor menggunakan seluruh FIFO jika itu satu-satunya sensor yang aktif. Jika beberapa sensor aktif, maka setiap sensor dijamin mendapat ruang untuk setidaknya peristiwa SensorInfo.fifoReservedEventCount di FIFO. Jika hub sensor digunakan, jaminan dapat diterapkan melalui perangkat lunak.

Peristiwa sensor dikumpulkan dalam situasi berikut:

  • Latensi laporan maksimum sensor saat ini lebih besar dari nol, yang berarti peristiwa sensor dapat ditunda hingga latensi laporan maksimum sebelum dilaporkan melalui HAL.
  • Titik Akses berada dalam mode tunda dan sensornya adalah sensor non-bangun. Dalam hal ini, kejadian tidak boleh membangunkan AP dan harus disimpan sampai AP terbangun.

Jika sensor tidak mendukung batching dan Titik Akses tertidur, hanya kejadian sensor saat bangun yang dilaporkan ke Titik Akses dan kejadian di luar bangun tidak boleh dilaporkan ke Titik Akses.

Parameter pengelompokan

Dua parameter yang mengatur perilaku batching 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 tersebut harus dilaporkan ke HAL Sensor.

sampling_period_ns

Arti dari parameter sampling_period_ns bergantung pada mode pelaporan sensor yang ditentukan:

  • Berkelanjutan: sampling_period_ns adalah laju pengambilan sampel, yang berarti laju terjadinya peristiwa.
  • Saat berubah: sampling_period_ns membatasi laju pengambilan sampel peristiwa, artinya peristiwa dihasilkan tidak lebih cepat dari setiap sampling_period_ns nanodetik. Periode bisa lebih lama dari sampling_period_ns jika tidak ada peristiwa yang dihasilkan dan nilai terukur tidak berubah dalam jangka waktu lama. Untuk detail selengkapnya, lihat mode pelaporan saat perubahan .
  • Sekali pakai: sampling_period_ns diabaikan. Itu tidak berpengaruh.
  • Khusus: Untuk 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 kontinu dan terus berubah:

  • jika sampling_period_ns kurang dari SensorInfo.minDelay , maka implementasi HAL harus secara diam-diam menjepitnya ke max(SensorInfo.minDelay, 1ms) . Android tidak mendukung pembuatan acara dengan kecepatan lebih dari 1000 Hz.
  • jika sampling_period_ns lebih besar dari SensorInfo.maxDelay , maka implementasi HAL harus memotongnya secara diam-diam menjadi SensorInfo.maxDelay .

Sensor fisik terkadang memiliki keterbatasan pada kecepatan kerjanya dan keakuratan jamnya. Untuk memperhitungkan hal ini, frekuensi pengambilan sampel sebenarnya dapat berbeda dari frekuensi yang diminta asalkan memenuhi persyaratan pada tabel di bawah.

Jika frekuensi yang diminta adalah

Maka frekuensi sebenarnya harusnya

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 maksimal (>1/mntDelay)

antara 90% dan 110% dari frekuensi maksimal, dan di bawah 1100 Hz

max_report_latency_ns

max_report_latency_ns menetapkan waktu maksimum dalam nanodetik, dimana peristiwa dapat ditunda dan disimpan dalam FIFO perangkat keras sebelum dilaporkan melalui HAL saat AP aktif.

Nilai nol menandakan bahwa kejadian harus dilaporkan segera setelah diukur, baik melewatkan FIFO sama sekali, atau mengosongkan FIFO segera setelah ada satu kejadian dari sensor.

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

Ketika max_report_latency_ns>0 , kejadian 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 kejadian sejak batch sebelumnya dicatat dan dikembalikan sekaligus. Hal ini mengurangi jumlah interupsi yang dikirim ke Titik Akses dan memungkinkan Titik Akses untuk beralih ke mode daya yang lebih rendah (idle) saat sensor menangkap dan mengelompokkan data.

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

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

Peristiwa bangun dan tidak bangun

Peristiwa sensor dari sensor bangun harus disimpan dalam satu atau lebih FIFO bangun. Desain yang umum adalah memiliki FIFO bangun bersama yang besar dan tunggal, tempat kejadian dari semua sensor bangun disisipkan. Alternatifnya, Anda dapat memiliki satu FIFO pengaktifan per sensor atau memiliki FIFO khusus untuk sensor pengaktifan tertentu dan FIFO bersama untuk sensor pengaktifan lainnya.

Demikian pula, kejadian sensor dari sensor non-bangun harus disimpan dalam satu atau lebih FIFO non-bangun.

Dalam semua kasus, kejadian sensor bangun dan kejadian sensor tidak bangun tidak dapat disisipkan dalam FIFO yang sama. Peristiwa bangun harus disimpan dalam FIFO bangun, dan kejadian tidak bangun harus disimpan dalam FIFO tidak bangun.

Untuk FIFO bangun, desain FIFO bersama yang tunggal dan besar memberikan manfaat daya terbaik. Untuk FIFO non-bangun, FIFO bersama tunggal yang besar dan beberapa desain FIFO cadangan 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 sementara di FIFO selama tidak tertunda lebih dari max_report_latency .

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

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

Misalnya, jika sensor berikut diaktifkan:

  • accelerometer dikumpulkan dengan max_report_latency = 20s
  • giroskop dikumpulkan dengan max_report_latency = 5s

Kumpulan akselerometer dilaporkan pada waktu yang sama dengan kumpulan giroskop dilaporkan (setiap 5 detik), meskipun akselerometer dan giroskop tidak menggunakan FIFO yang sama.

Perilaku dalam mode penangguhan

Batching sangat bermanfaat untuk mengumpulkan data sensor di latar belakang tanpa membuat AP tetap aktif. Karena driver sensor dan penerapan HAL tidak diperbolehkan untuk mengaktifkan penguncian layar saat aktif*, Titik Akses dapat memasuki mode penangguhan bahkan saat data sensor sedang dikumpulkan.

Perilaku sensor saat Titik Akses ditangguhkan bergantung pada apakah sensor tersebut merupakan sensor bangun. Untuk lebih jelasnya, lihat Sensor bangun .

Ketika FIFO non-bangunan terisi, ia harus membungkus dan berperilaku seperti buffer melingkar, menimpa peristiwa lama dengan peristiwa baru menggantikan yang lama. max_report_latency tidak berdampak pada FIFO yang tidak aktif saat berada dalam mode penangguhan.

Ketika FIFO bangun terisi, atau ketika max_report_latency dari salah satu sensor bangun berlalu, perangkat keras harus membangunkan Titik Akses dan melaporkan datanya.

Dalam kedua kasus (wake-up dan non-wake-up), segera setelah AP keluar dari mode penangguhan, batch diproduksi dengan konten semua FIFO, bahkan jika max_report_latency dari beberapa sensor belum berlalu. Hal ini meminimalkan risiko Titik Akses harus segera aktif kembali setelah kembali ke mode tunda dan, oleh karena itu, meminimalkan konsumsi daya.

*Satu pengecualian bagi pengemudi yang tidak diperbolehkan menahan penguncian layar saat aktif adalah ketika sensor bangun dengan mode pelaporan berkelanjutan diaktifkan dengan max_report_latency < 1 detik. Dalam hal ini, pengemudi dapat menahan penguncian layar saat aktif karena Titik Akses tidak punya waktu untuk memasuki mode penangguhan, karena akan dibangunkan oleh peristiwa pengaktifan sebelum mencapai mode penangguhan.

Tindakan pencegahan saat mengelompokkan sensor bangun

Tergantung pada perangkatnya, mungkin diperlukan waktu beberapa milidetik agar Titik Akses keluar dari mode penangguhan sepenuhnya dan mulai membilas FIFO. Ruang kepala yang cukup harus dialokasikan di FIFO agar perangkat dapat keluar dari mode penangguhan tanpa FIFO bangun meluap. Tidak ada peristiwa yang hilang, dan max_report_latency harus dipatuhi.

Tindakan pencegahan saat mengelompokkan sensor non-wake-up on-change

Sensor on-change hanya menghasilkan peristiwa ketika nilai yang diukurnya berubah. Jika nilai terukur berubah saat AP berada dalam mode penangguhan, aplikasi berharap untuk menerima kejadian segera setelah AP aktif. Oleh karena itu, pengelompokan peristiwa sensor non-bangun saat perubahan harus dilakukan dengan hati-hati jika sensor berbagi FIFO-nya dengan sensor lain. Peristiwa terakhir yang dihasilkan oleh setiap sensor on-change harus selalu disimpan di luar FIFO bersama sehingga tidak dapat ditimpa oleh peristiwa lain. Saat AP aktif, setelah semua kejadian dari FIFO dilaporkan, kejadian terakhir pada sensor perubahan harus dilaporkan.

Inilah situasi yang harus dihindari:

  1. Aplikasi mendaftar ke penghitung langkah non-bangun (on-change) dan akselerometer non-bangun (kontinu), keduanya berbagi FIFO yang sama.
  2. Aplikasi menerima peristiwa penghitung langkah step_count=1000 steps kode>.
  3. AP akan ditangguhkan.
  4. Pengguna berjalan 20 langkah, menyebabkan peristiwa penghitung langkah dan akselerometer disisipkan, peristiwa penghitung langkah terakhir adalah step_count = 1020 steps .
  5. Pengguna tidak bergerak dalam waktu lama, menyebabkan kejadian akselerometer terus terakumulasi di FIFO, yang pada akhirnya menimpa setiap kejadian step_count di FIFO bersama.
  6. AP bangun dan semua kejadian dari FIFO dikirim ke aplikasi.
  7. Aplikasi hanya menerima kejadian akselerometer dan menganggap pengguna tidak berjalan.

Dengan menyimpan kejadian penghitung langkah terakhir di luar FIFO, HAL dapat melaporkan kejadian ini ketika AP bangun, bahkan jika semua kejadian penghitung langkah lainnya ditimpa oleh kejadian akselerometer. Dengan cara ini, aplikasi menerima step_count = 1020 steps saat AP aktif.

Menerapkan pengelompokan

Untuk menghemat daya, batching harus dilaksanakan tanpa bantuan AP, dan AP harus dibiarkan ditangguhkan selama batching.

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

Latensi laporan maksimum dapat diubah kapan saja, khususnya saat sensor yang ditentukan sudah diaktifkan; dan ini tidak boleh mengakibatkan hilangnya peristiwa.

Prioritas alokasi FIFO

Pada platform di mana ukuran buffer FIFO perangkat keras dan/atau hub sensor terbatas, perancang sistem mungkin harus memilih berapa banyak FIFO yang akan dicadangkan untuk setiap sensor. Untuk membantu dalam pilihan ini, berikut adalah daftar kemungkinan aplikasi saat batching diterapkan pada sensor yang berbeda.

Nilai tinggi: Perhitungan kematian pejalan kaki berdaya rendah

Target waktu pengelompokan: 1 hingga 10 menit

Sensor yang akan dikumpulkan:

  • Detektor langkah bangun
  • Vektor rotasi permainan bangun pada 5 Hz
  • Barometer bangun pada 5 Hz
  • Magnetometer bangun yang tidak dikalibrasi pada 5 Hz

Pengelompokan data ini memungkinkan dilakukannya perhitungan kematian pejalan kaki sambil membiarkan Titik Akses ditangguhkan.

Nilai tinggi: Aktivitas intermiten/pengenalan gerakan dengan daya sedang

Target waktu pengelompokan: 3 detik

Sensor yang akan dikumpulkan: Akselerometer non-bangun pada 50 Hz

Pengelompokan data ini memungkinkan pengenalan aktivitas dan gerakan sewenang-wenang secara berkala tanpa harus membuat AP tetap aktif saat data dikumpulkan.

Nilai sedang: Aktivitas berkelanjutan/pengenalan gerakan berkekuatan sedang

Target waktu pengelompokan: 1 hingga 3 menit

Sensor yang akan dikumpulkan: Akselerometer bangun pada 50 Hz

Pengelompokan data ini memungkinkan pengenalan aktivitas dan gerakan sewenang-wenang secara terus-menerus tanpa harus membuat AP tetap aktif saat data dikumpulkan.

Nilai sedang-tinggi: Pengurangan beban interupsi

Target waktu pengelompokan: <1 detik

Sensor yang akan dikumpulkan: sensor frekuensi tinggi apa pun, biasanya non-bangun.

Jika giroskop diatur pada 240 Hz, bahkan dengan mengumpulkan 10 peristiwa gyro saja dapat mengurangi jumlah interupsi dari 240/detik menjadi 24/detik.

Nilai sedang: Pengumpulan data frekuensi rendah secara terus menerus

Target waktu pengelompokan: 1 hingga 10 menit

Sensor yang akan dikumpulkan:

  • Barometer bangun pada 1 Hz
  • Sensor kelembaban bangun pada 1 Hz
  • Sensor bangun frekuensi rendah lainnya dengan kecepatan yang sama

Memungkinkan pembuatan aplikasi pemantauan dengan daya rendah.

Nilai sedang-rendah: Pengumpulan sensor penuh berkelanjutan

Target waktu pengelompokan: 1 hingga 10 menit

Sensor yang akan dikumpulkan: Semua sensor bangun, pada frekuensi tinggi

Memungkinkan pengumpulan data sensor secara penuh sambil membiarkan Titik Akses dalam mode penangguhan. Hanya pertimbangkan jika ruang FIFO tidak menjadi masalah.