Bagikan melalui

Manajemen daya penerima GNSS untuk platform siaga modern

  • Artikel

Topik ini membahas manajemen daya Global Navigation Satellite System (GNSS) untuk platform modern yang mampu siaga.

PC Windows yang mengimplementasikan model daya siaga modern juga dapat berisi perangkat Global Navigation Satellite System (GNSS). Perangkat GNSS memungkinkan pengguna untuk mendapatkan informasi posisi presisi tinggi dari sistem navigasi satelit, seperti Global Positioning Systems (GPS) atau Global Orbiting Navigation Satellite System (GLONASS). Setelah platform perangkat keras memasuki siaga modern, perangkat GNSS harus memasuki mode operasi berdaya rendah di mana ia mengonsumsi daya tidak lebih dari 1 mW. Perangkat GNSS kemudian harus tetap dalam mode ini sampai platform keluar dari siaga modern.

Perangkat GNSS yang mendukung GPS dan Global Orbiting Navigation Satellite System (GLONASS) telah tersedia selama beberapa waktu, tetapi perangkat GNSS yang lebih baru mendukung sistem navigasi satelit seperti BeiDou Navigation Satellite System (BDS) dan Galileo.

Platform siaga modern biasanya dibangun di sekitar sirkuit terintegrasi System on a Chip (SoC). Windows mendukung opsi berikut untuk menambahkan perangkat GNSS ke platform seperti itu:

  • Menggabungkan modul broadband seluler (MBB) yang berisi perangkat GNSS terintegrasi. Metode ini umum dalam ponsel.
  • Pilih SoC yang berisi perangkat GNSS terintegrasi.
  • Gunakan bus berdaya rendah seperti I2C, SPI, atau UART untuk menyambungkan perangkat GNSS yang berdiri sendiri ke SoC.

Jika memungkinkan, integrator sistem harus memilih perangkat GNSS yang menerapkan mode tidur berdaya rendah di mana perangkat mengonsumsi daya tidak lebih dari 1 mW. Vendor perangkat GNSS harus menyediakan driver sensor lokasi yang menerjemahkan data lokasi dari perangkat GNSS ke formulir yang diperlukan oleh aplikasi klien. Aplikasi ini terhubung ke perangkat GNSS melalui WINDOWS Location API. Driver sensor lokasi untuk perangkat GNSS melacak informasi berikut:

  • Jumlah klien yang saat ini terhubung ke perangkat GNSS melalui API Lokasi.
  • Status radio hidup/mati untuk perangkat GNSS. Pengguna mengontrol sakelar ini melalui aplikasi Windows Pengaturan. Untuk informasi selengkapnya, lihat Mengintegrasikan manajemen radio.

Driver sensor lokasi menggunakan informasi ini untuk menentukan kapan perangkat GNSS menganggur sehingga dapat ditempatkan dalam mode daya rendah. Perangkat GNSS secara aktif digunakan hanya jika satu atau beberapa klien terhubung ke perangkat. Jika tidak, perangkat tidak aktif.

Untuk memperpanjang masa pakai baterai sistem, akses ke perangkat GNSS dibatasi selama siaga modern. Aplikasi layar kunci dapat mengakses informasi geofencing dan posisi selama siaga modern. Namun, aplikasi layar non-kunci dapat menggunakan API Lokasi untuk mendapatkan data lokasi dari perangkat GNSS hanya saat layar diaktifkan dan platform berinteraksi dengan pengguna. Tak lama setelah tampilan dimatikan dan platform memasuki siaga modern, aplikasi layar non-kunci apa pun yang memiliki koneksi ke perangkat GNSS secara otomatis terputus oleh Windows, dan aplikasi ditangguhkan.

Mode manajemen daya

Penerima GNSS diharapkan memiliki 4 mode manajemen daya seperti yang dijelaskan di bawah ini.

Mode Daya Penerima GNSS

Mode Daya Perangkat Deskripsi Status Daya Perangkat (Dx) Status Radio (seperti yang ditunjukkan kepada pengguna) Jumlah Klien yang Koneksi Konsumsi Daya Rata-rata (mW) Mekanisme Transisi

Aktif (akuisisi)

Penerima GNSS memperoleh perbaikan satelit.

D0

Di

>= 1

~200 mW

T/A

Aktif (Pelacakan 1 Hz)

Penerima GNSS telah memperoleh perbaikan satelit dan menyediakan data untuk satu atau beberapa aplikasi secara berkala.

D0

Di

>= 1

~100 mW (khusus perangkat)

T/A

tidur

Penerima GNSS tidak memiliki klien yang terhubung Perangkat keras penerima GNSS masih memiliki daya yang diterapkan untuk mempertahankan konteks pada perangkat dan mengurangi waktu latensi resume ke mode Aktif.

D3(D3hot)

Nonaktif atau aktif

0

<1 mW (khusus perangkat)

Diinisiasi perangkat lunak. Ini adalah status suspensi selektif untuk radio GNSS yang terpasang langsung ke bus Universal Serial Bus (USB) atau perangkat komposit USB.

Daya dihapus

Penerima GNSS tidak memiliki klien yang terhubung, radio dimatikan dan semua daya dari penerima GNSS telah dihapus oleh entitas eksternal.

D3(D3cold)

Nonaktif atau aktif

0

0 mW

Perangkat lunak yang dimulai dan memerlukan koordinasi perangkat keras untuk menghapus daya.

Driver perangkat lunak untuk penerima GNSS juga perlu menangani manajemen radio seperti yang dijelaskan di bawah ini.

Persyaratan implementasi platform

Platform siaga modern memiliki beberapa opsi untuk mengintegrasikan penerima GNSS secara fisik. Penerima GNSS mungkin merupakan bagian dari perangkat mandiri yang terhubung ke SoC oleh bus komunikasi berdaya rendah. Penerima GNSS juga dapat diintegrasikan ke dalam radio mobile broadband (MBB) karena penerima GNSS umum dalam ponsel. Akhirnya, penerima GNSS dapat diintegrasikan ke SoC itu sendiri.

Beberapa opsi ini menghadirkan tantangan bagi integrator sistem saat menentukan implementasi mana yang akan dipilih untuk platform yang memerlukan fungsionalitas GNSS. Untuk platform siaga modern Windows, integrator sistem disarankan untuk mengintegrasikan GNSS dalam urutan prioritas berikut:

  1. Jika sistem dilengkapi dengan radio MBB, gunakan penerima GNSS yang terintegrasi ke dalam modul MBB.
  2. Jika sistem dilengkapi dengan SoC yang memiliki penerima GNSS onboard, gunakan penerima GNSS yang terintegrasi ke dalam SoC.
  3. Integrasikan penerima GNSS mandiri yang melekat pada SoC melalui bus komunikasi daya rendah (seperti UART, SPI, atau I2C).

Integrator sistem tidak boleh mengekspos penerima GNSS asing ke Windows. Di hadapan beberapa penerima GNSS yang terekspos ke sistem operasi, Windows TIDAK akan menggabungkan informasi lokasi dari semua perangkat GNSS.

Mekanisme manajemen daya perangkat lunak

Perangkat GNSS di platform Windows diharapkan dikelola oleh driver User-Mode Driver Framework (UMDF) yang menggunakan model Windows Sensor Class Extension dan mengimplementasikan antarmuka ISensorDriver. Driver GNSS ini disebut driver sensor lokasi dan diharapkan untuk mengelola penerima GNSS yang mendasar dan memberikan data ke permintaan aplikasi untuk informasi lokasi.

Gambaran umum dan model aplikasi

Driver sensor lokasi menggunakan jumlah klien aplikasi yang terhubung sebagai mekanisme utama untuk menentukan kapan perangkat GNSS dapat memasuki mode tidur atau daya yang dihapus. Driver sensor lokasi juga bertanggung jawab untuk berkomunikasi dengan pustaka manajer radio yang disediakan vendor GNSS yang memungkinkan pengguna mengontrol apakah radio GNSS diaktifkan atau dinonaktifkan. Driver sensor lokasi dapat menggunakan jumlah klien yang terhubung dan preferensi pengguna untuk status radio untuk memastikan perangkat GNSS berada dalam mode tidur berdaya rendah atau daya dihapus jika memungkinkan.

Aplikasi Microsoft Store mengelola masa pakai aplikasi latar depan dan latar belakang dan oleh karena itu memiliki pengaruh signifikan pada jumlah klien aplikasi yang terhubung ke driver sensor lokasi. Aplikasi latar depan meminta informasi lokasi melalui WINDOWS Location API. Ketika aplikasi latar depan dialihkan ke latar belakang oleh pengguna, model aplikasi Microsoft Store memastikan bahwa aplikasi klien terputus dari penerima GNSS.

Mekanisme model aplikasi ini memungkinkan driver sensor lokasi untuk dengan mudah melacak jumlah klien aplikasi yang terhubung. Setiap kali tidak ada klien aplikasi yang terhubung, driver sensor lokasi dapat mengubah perangkat GNSS ke mode tidur atau daya yang dihapus.

Ketika sistem memasuki siaga modern, Windows akan secara otomatis menangguhkan semua aplikasi latar depan yang mengakibatkan driver sensor lokasi mengamati jumlah transisi klien yang terhubung ke nol.

Mengintegrasikan manajemen radio

Driver sensor lokasi juga harus menerapkan antarmuka untuk berkomunikasi dengan pustaka manajer radio yang disediakan vendor. Pustaka manajer radio memungkinkan Windows mengekspos kontrol "aktif/mati" radio perangkat GNSS di aplikasi Windows Pengaturan.

Persyaratan implementasi driver sensor lokasi

Driver sensor lokasi harus menempatkan perangkat GNSS ke dalam status D3 berdaya rendah ketika perangkat GNSS tidak digunakan. Perangkat GNSS tidak digunakan ketika saat ini tidak ada klien yang terhubung atau GNSS telah dinonaktifkan melalui manajer radio.

Driver sensor lokasi harus mempertahankan perangkat GNSS dalam status D3 setiap saat ketika perangkat GNSS telah dinonaktifkan melalui manajer radio. Persyaratan ini mencegah driver menggunakan antrean yang dikelola daya dan hanya meneruskan permintaan dari klien yang terhubung. Driver sensor lokasi harus menggunakan antrean yang tidak dikelola daya untuk I/O dan mengelola idle secara langsung menggunakan metode StopIdle dan ResumeIdle . Sensor lokasi harus terus menjadi pemilik kebijakan daya untuk tumpukan driver perangkat GNSS. Driver harus mengatur nilai bPowerManaged ke FALSE saat memanggil IWDFDevice::CreateIoQueue untuk membuat antrean I/O.

Seperti disebutkan di atas, driver menggunakan jumlah klien yang terhubung dan status radio dari manajer radio untuk menentukan apakah perangkat GNSS menganggur. Ketika perangkat GNSS diam, driver memanggil metode ResumeIdle yang menyebabkan kerangka kerja driver memulai transisi D3. Kerangka kerja driver akan menjalankan implementasi driver dari metode OnD0Exit .

Ketika perangkat GNSS harus diaktifkan kembali karena klien atau daya baru yang terhubung pada radio, driver memanggil metode StopIdle . Kerangka kerja driver akan menjalankan implementasi driver dari metode OnD0Entry . Perhatikan, driver harus menjalankan metode StopIdle dengan parameter WaitForD0 yang diatur ke FALSE.

Diagram status yang disediakan di bawah ini menggambarkan hubungan ini dan berfungsi sebagai panduan untuk pengembang driver kapan harus memanggil metode StopIdle dan ResumeIdle .

Karena driver bertanggung jawab untuk melacak apakah perangkat menganggur, driver harus langsung mengelola antrean I/O dan akses perangkat keras yang dihasilkan.

Driver sensor lokasi harus mengimplementasikan metode IPnpCallbackSelfManagedIo::OnSelfManagedIoSuspend dan IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart . Perhatikan bahwa kerangka kerja driver akan memanggil IPnpCallbackSelfManagedIo::OnSelfManagedIoInit saat perangkat dimulai, termasuk pada boot sistem. Panggilan berikutnya adalah ke panggilan balik IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart . Antarmuka ini harus didaftarkan ketika kerangka kerja driver memanggil metode CreateDevice.

IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart memberi sinyal driver sensor lokasi yang meminta ke driver dapat langsung berinteraksi dengan perangkat keras perangkat GNSS, termasuk permintaan dari ISensorDriver:: panggilan balik. Perhatikan bahwa kerangka kerja driver menjamin bahwa perangkat keras perangkat dapat diakses dalam metode OnD0Exit dan OnD0Entry .

Demikian pula, ketika metode IPnpCallbackSelfManagedIo::OnSelfManagedIoSuspend dipanggil oleh kerangka kerja, driver harus menyelesaikan semua permintaan ISensorDriver segera sebelum kembali dari OnSelfManagedIoSuspend. Driver tidak dapat mengakses perangkat keras perangkat jika melakukannya mungkin mencegah salah satu permintaan ini selesai dalam satu detik. Jika driver sensor lokasi memiliki permintaan tertunda ke perangkat keras perangkat GNSS, permintaan harus dibatalkan jika tidak dapat diselesaikan dengan cara lain tanpa melanggar batasan waktu ini.

Jika driver tidak berinteraksi langsung dengan perangkat keras atau semua permintaan perangkat keras yang luar biasa dijamin selesai dalam satu detik, driver harus menerapkan metode OnSelfManagedIoSuspend dengan menggunakan prosedur berikut:

  1. Atur bendera global yang menunjukkan perangkat tidak aktif.
  2. Panggil metode StopSynchronously pada antrean Windows Driver Frameworks (WDF).
  3. Hentikan pekerjaan asinkron lain yang mengakses perangkat keras perangkat GNSS.
  4. Panggil metode Mulai pada antrean WDF.
  5. Hapus bendera global yang ditetapkan di langkah 1.

Untuk contoh kode yang melakukan operasi ini, lihat implementasi OnSelfManagedIoSuspend dalam Sensor Geolocation Sample Driver (UMDF Versi 1).

Jika driver berinteraksi langsung dengan perangkat keras, maka permintaan yang terutang ke perangkat keras harus dibatalkan sebelum menghapus antrean I/O. Driver harus menerapkan metode OnSelfManagedIoSuspend dengan menggunakan prosedur berikut:

  1. Atur bendera global yang menunjukkan perangkat tidak aktif.
  2. Panggil metode Stop pada antrean WDF.
  3. Batalkan semua permintaan perangkat keras yang tertunda untuk memungkinkan semua utas panggilan balik ISensorDriver selesai.
  4. Panggil metode StopSynchronously pada antrean WDF.
  5. Hentikan pekerjaan asinkron lain yang mengakses perangkat keras perangkat GNSS.
  6. Panggil metode Mulai pada antrean WDF.
  7. Hapus bendera global yang ditetapkan di langkah 1.

Semua driver sensor lokasi harus secara sinkron membersihkan antrean I/O dalam implementasinya dari metode OnSelfManagedIoFlush .

Mode tidur dan daya yang dihapus

Perangkat GNSS dapat mendukung mode tidur dan mode daya yang dihapus ketika perangkat memiliki konteks lokal yang dipertahankan dan masih dapat menanggapi permintaan melalui bus komunikasi tanpa sinyal eksternal. (Biasanya, perangkat dalam mode penghapusan daya tidak dapat merespons permintaan bus.) Driver sensor lokasi harus ditulis untuk memahami apakah perangkat yang mendasar mampu melepas daya mode. Driver sensor lokasi harus mengaktifkan D3cold hanya jika perangkat yang mendasar mampu melepas daya mode dan driver mampu menyimpan/memulihkan konteks dan menginisialisasi ulang perangkat. Jika tidak, sensor lokasi harus terus menggunakan D3 sebagai status diamnya, tetapi tidak mengaktifkan D3cold. Hal ini memungkinkan bus dan driver filter yang mendasar untuk menempatkan perangkat dalam mode daya rendah tidur dan bukan mode daya yang dilepaskan.

Ketika driver sensor lokasi menunjukkan bahwa ia mendukung D3cold dan memulai transisi D3, bus dan driver filter yang mendasar bertanggung jawab untuk menghapus daya dari perangkat. Mekanisme ini dapat diimplementasikan oleh ACPI dalam kasus perangkat GNSS yang terhubung dengan UART. Atau, mekanisme dapat diaktifkan dengan kombinasi driver hub USB dan driver ACPI dalam kasus perangkat GNSS yang dijumlahkan USB.

Jika perangkat GNSS berada di SoC, driver kepemilikan dan firmware dari vendor SoC yang diterapkan di driver yang mendasarinya bertanggung jawab untuk menghapus daya dari perangkat GNSS. Jika perangkat GNSS mengonsumsi lebih dari 1 mW dalam mode daya tidurnya, driver GNSS, firmware platform, dan perangkat keras harus direkayasa untuk menempatkan perangkat dalam mode daya yang dihapus ketika semua klien terputus.

Deteksi diam

Driver sensor lokasi untuk perangkat GNSS harus mengalihkan perangkat ke mode daya tidur jika memungkinkan. Jika aplikasi meminta interval laporan yang panjang, driver sensor lokasi harus mengalihkan perangkat GNSS ke mode daya tidur hingga perbaikan berikutnya diminta. Driver sensor lokasi harus mengalihkan perangkat GNSS ke mode daya aktif dengan waktu yang memadai untuk triangulasi perbaikan dan menyediakan data lokasi kepada aplikasi.

Misalnya, asumsikan interval laporan terpendek yang diminta adalah 30 menit dan perangkat memerlukan satu menit untuk menghangatkan dan memperoleh perbaikan lokasi. Dalam skenario ini, driver sensor lokasi harus:

  • Segera setelah memberikan informasi lokasi, panggil ResumeIdle yang akan mengalihkan perangkat GNSS ke mode tidur (D3).
  • Persiapkan timer untuk kedaluwarsa 28 menit di masa depan. (TimerExpiration = ReportInterval – WarmUpTime).
  • Ketika timer kedaluwarsa, panggil StopIdle yang akan mentransisikan perangkat GNSS ke D0.
  • Ketika perangkat telah memperoleh perbaikan, berikan informasi lokasi ke aplikasi. Perhatikan Driver sensor lokasi harus mengonfigurasi D3cold dengan hati-hati.

Jika perangkat memerlukan daya berkelanjutan untuk mencapai latensi resume untuk WarmUpTime, D3cold tidak boleh diaktifkan. D3cold dapat diaktifkan secara dinamis pada runtime dengan mengubah nilai ExcludeD3Cold dalam struktur WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS.

Ketika perangkat GNSS yang terpasang USB beralih ke mode tidur (D3) dengan D3cold dinonaktifkan, perangkat akan beralih ke status suspensi USB yang menghemat chipset dan daya prosesor yang signifikan. Jika driver sensor lokasi memungkinkan D3cold dan transisi ke mode tidur (D3), platform yang mendasar dapat menghilangkan daya dari perangkat bahkan ketika terpasang melalui bus USB.

Konfigurasi perangkat keras yang didukung

Windows mendukung empat konfigurasi perangkat keras fisik untuk perangkat GNSS. Bus konektivitas membedakan setiap konfigurasi perangkat keras.

GNSS tersambung ke SoC melalui UART

Dalam konfigurasi ini, radio GNSS adalah perangkat mandiri yang terhubung ke UART di SoC. Radio GNSS mungkin memiliki satu atau beberapa GPIO antara radio dan SoC untuk tujuan transisi antara mode daya aktif dan tidur atau untuk menangani reset dan kondisi pengurutan power-up.

Jika radio GNSS mengonsumsi kurang dari 1 mW dalam mode daya tidurnya, radio GNSS mungkin terhubung ke rel daya sistem apa pun yang memenuhi spesifikasi perangkat.

Perangkat GNSS harus dideklarasikan di namespace ACPI dan GPIO untuk manajemen daya harus dikontrol oleh metode kontrol _PS3 dan _PS0 di bawah perangkat di namespace ACPI. Metode _PS3 dan _PS0 dijalankan oleh driver ACPI sebagai respons terhadap transisi D3 dan D0 yang dimulai oleh driver sensor lokasi. Integrator sistem harus menyatakan GPIO sebagai bagian dari wilayah operasi GPIO di namespace ACPI.

Jika penerima GNSS mengonsumsi lebih dari 1 mW dalam mode daya tidurnya, penerima GNSS harus terhubung ke rel listrik yang dapat dinyalakan dan dimatikan menggunakan GPIO yang dikendalikan oleh firmware ACPI pada SoC. Dalam konfigurasi ini, driver sensor lokasi harus mengaktifkan D3cold. GPIO untuk mengontrol rel daya yang dapat dialihkan harus diekspos di wilayah operasi GPIO ACPI. Integrator sistem harus menjelaskan sumber daya daya untuk rel daya yang dapat dialihkan, termasuk metode _OFF dan _ON, serta referensi ke sumber daya daya di bawah perangkat GNSS di namespace.

Driver Windows ACPI akan mengevaluasi metode _OFF ketika driver sensor lokasi beralih ke D3. Ketika driver sensor lokasi beralih ke D0, driver Windows ACPI akan mengevaluasi metode _ON di bawah sumber daya daya. Implementasi metode _OFF dan _ON harus mengalihkan GPIO yang mengontrol rel daya yang dapat dialihkan dan menerapkan penundaan pengurutan daya yang diperlukan.

GNSS terintegrasi ke dalam SoC

Jika perangkat GNSS diintegrasikan secara fisik ke dalam SoC, implementasi komunikasi dan manajemen daya khusus untuk SoC itu sendiri.

Perangkat GNSS masih harus dijumlahkan melalui ACPI, meskipun komunikasi ke penerima GNSS yang mendasar dapat terjadi melalui driver transportasi yang disediakan oleh vendor SoC. Dalam konfigurasi ini, driver sensor lokasi masih harus menerapkan transisi D3 untuk memasuki mode tidur atau daya yang dihapus ketika semua klien terputus. Transisi D3 memastikan bahwa alat dan diagnostik manajemen daya OS Windows dapat dengan mudah mengamati status daya perangkat GNSS.

Integrator sistem yang berencana memanfaatkan radio GNSS yang terintegrasi ke dalam sistem SoC harus berkonsultasi erat dengan vendor SoC untuk dukungan firmware, driver, dan manajemen daya.

GNSS terintegrasi ke dalam radio MBB yang terpasang USB sebagai perangkat komposit USB

Perancang sistem dapat memilih untuk mengintegrasikan modul MBB yang terpasang USB yang berisi penerima GNSS yang disematkan. Dalam konfigurasi perangkat keras ini, driver sensor lokasi berkomunikasi dengan penerima GNSS yang disematkan langsung melalui bus USB sebagai satu fungsi dalam perangkat komposit USB.

Catatan Sistem dengan perangkat GNSS pada modul MBB memerlukan pertimbangan integrasi yang cermat. Hubungi perwakilan Microsoft Anda untuk meninjau perangkat keras, perangkat lunak, dan desain firmware untuk solusi ini.

Dalam konfigurasi ini, perangkat GNSS adalah bagian terintegrasi dari modul MBB. Radio GNSS dapat berbagi komponen pemrosesan, catu daya, dan antena RF dengan radio MBB. Radio GNSS diekspos langsung ke perangkat lunak sebagai satu antarmuka pada perangkat komposit USB. Driver sensor lokasi berkomunikasi dengan radio GNSS langsung melalui bus USB menggunakan antarmuka driver USB yang diterapkan di dalam driver sensor lokasi.

Manajemen daya perangkat keras GNSS didorong oleh komunikasi dalam band ke modul GNSS. Modul GNSS dan driver sensor lokasi harus mendukung mekanisme in-band untuk menyalakan dan mematikan radio GNSS. Mekanisme ini tidak boleh bergantung pada penggunaan GPIO apa pun dari SoC ke modul MBB+GNSS.

Demikian pula, modul GNSS dan driver sensor lokasi harus mendukung transisi perangkat ke status D3 sedemikian rupa sehingga perangkat komposit USB dapat memasuki status USB suspend (selective suspend). Semua fungsi pada perangkat komposit USB harus ditangguhkan agar perangkat komposit ditangguhkan. Perangkat GNSS harus dalam mode Tidur (D3) agar fungsi GNSS dan seluruh perangkat komposit USB berada dalam status ditangguhkan.

Perhatikan Perangkat GNSS dan driver harus mendukung penangguhan selektif jika tidak, pengontrol host USB pada SoC tidak dapat memasuki mode daya rendah dan akan mencegah penghematan daya selama siaga modern.

Dalam konfigurasi ini, perangkat GNSS dijumlahkan melalui USB dan driver komposit USB, tetapi dijelaskan di namespace ACPI. Dalam konfigurasi ini tidak ada dukungan untuk komunikasi GPIO antara perangkat GNSS pada modul MBB dan SoC. Perangkat GNSS harus tetap dijumlahkan ke Windows melalui ACPI selama seluruh waktu platform tetap dalam status daya sistem S0, bahkan jika radio dinonaktifkan oleh pengguna. Perangkat GNSS tidak boleh hilang dari bus USB selama bagian sistem apa pun tepat waktu.

GNSS terintegrasi ke dalam radio MBB yang terpasang USB menggunakan layanan perangkat

Perancang sistem dapat memilih untuk mengintegrasikan modul MBB yang terpasang USB yang berisi penerima GNSS yang disematkan. Dalam konfigurasi perangkat keras ini, driver sensor lokasi berkomunikasi dengan penerima GNSS yang disematkan melalui antarmuka layanan perangkat broadband seluler dibandingkan dengan perangkat GNSS yang diekspos sebagai fungsi USB mandiri sebagai bagian dari perangkat komposit yang mewakili seluruh modul MBB.

Catatan Konfigurasi ini tidak disarankan. Integrator sistem yang memilih metode integrasi perangkat GNSS ini harus menghubungi perwakilan Microsoft mereka untuk memvalidasi implementasi yang benar. Mengekspos perangkat GNSS sebagai bagian dari perangkat komposit USB yang mewakili modul MBB lebih disukai.

Dalam konfigurasi ini, perangkat GNSS adalah bagian terintegrasi dari modul MBB. Radio GNSS dapat berbagi komponen pemrosesan, catu daya, dan antena RF dengan radio MBB. Radio GNSS diekspos secara tidak langsung ke perangkat lunak melalui antarmuka layanan perangkat yang dapat diakses menggunakan antarmuka WINDOWSIMbnDeviceServices COM. Driver sensor lokasi berkomunikasi dengan radio GNSS melalui antarmuka IMbnDeviceServices.

Manajemen daya perangkat keras GNSS didorong oleh komunikasi dalam band melalui antarmuka layanan perangkat ke modul MBB. Perangkat keras GNSS harus mendukung mekanisme dalam pita melalui antarmuka layanan perangkat untuk mematikan radio dan menempatkan perangkat GNSS dalam mode daya rendah. Mekanisme ini harus dapat diakses oleh driver sensor lokasi melalui antarmuka layanan perangkat.

Dalam konfigurasi ini, perangkat GNSS harus dijumlahkan oleh ACPI dan dijelaskan di namespace ACPI sebagai anak dari modul broadband seluler. Perangkat GNSS tidak akan memiliki sumber daya perangkat keras yang dijelaskan di bawah perangkat di namespace ACPI.

Driver sensor lokasi masih harus melakukan serangkaian panduan implementasi manajemen daya yang sama seperti yang dijelaskan di bagian persyaratan implementasi driver sebelumnya.

Dalam konfigurasi ini tidak ada dukungan untuk komunikasi GPIO antara perangkat GNSS pada modul MBB dan SoC. Semua manajemen daya dan komunikasi radio dilakukan secara fisik melalui bus USB dan diekspos ke driver sensor lokasi melalui antarmuka layanan perangkat. Perangkat GNSS harus tetap dijumlahkan ke Windows melalui ACPI untuk semua sistem tepat waktu, bahkan jika radio dinonaktifkan oleh pengguna.

Saat menerapkan konfigurasi perangkat keras ini, integrator sistem didorong untuk bermitra erat dengan vendor modul MBB untuk memastikan perangkat GNSS diekspos dengan benar di namespace ACPI.

Membangunkan kekhawatiran

Tidak ada kekhawatiran bangun untuk perangkat GNSS. Perangkat GNSS tidak diharapkan mendukung membangunkan SoC dari status berdaya rendah.

Pengujian dan validasi

Vendor perangkat GNSS, vendor modul MBB, dan integrator sistem harus mengikuti rekomendasi ini untuk menguji dan memvalidasi implementasi manajemen daya perangkat GNSS dan komponen perangkat lunak terkait. Untuk informasi selengkapnya, lihat Panduan Pengujian Global Navigation Satellite System (GNSS).

Manajemen daya sensor lokasi

Integrator sistem harus memvalidasi bahwa driver sensor lokasi untuk perangkat GNSS melakukan transisi manajemen daya dan memasuki status D3 ketika semua klien telah terputus atau radio telah dinonaktifkan.

Kasus pengujian dasar adalah:

  • Amati transisi driver sensor lokasi ke D3 dalam waktu 10 detik dari layar yang dimatikan untuk siaga modern.
  • Amati transisi driver sensor lokasi ke D3 dalam waktu 10 detik dari radio yang dimatikan di aplikasi Windows Pengaturan.
  • Amati transisi driver sensor lokasi ke D0 segera setelah keluar dari siaga modern dan meluncurkan aplikasi yang menggunakan API Lokasi.

Cara term mudah untuk mengamati transisi status Dx dari driver sensor lokasi adalah dengan menggunakan Windows Performance Toolkit untuk dibandingkan dengan perangkat sensor Windows lainnya. Metode ini menggunakan instrumentasi Windows untuk memvalidasi D3 IRP bertransisi melalui tumpukan driver perangkat yang terdiri dari perangkat GNSS. Manajer daya Windows mencakup instrumentasi Event Tracing for Windows (ETW) bawaan, termasuk instrumentasi untuk IRP daya perangkat (Dx). Untuk melihat informasi ini dalam mode manual, dapatkan dan instal Windows Performance Toolkit (WPT) pada sistem yang sedang diuji.

Mulai jejak XPerf mode pengguna dengan menggunakan perintah berikut:

  1. Buka Perintah Administrator.

  2. Telusuri ke folder \%ProgramFiles%\Windows Kits\8.0\Windows Performance Toolkit\ .

  3. Mulai Xperf: xperf.exe -start power_session -on Microsoft-Windows-Kernel-Power

  4. Transisi sistem ke siaga modern dengan menggunakan tombol daya.

  5. Tunggu 120 detik.

  6. Transisi sistem dari siaga modern menggunakan tombol daya.

  7. Tunggu 60 detik.

  8. Jalankan perintah berikut untuk menghentikan pengelogan peristiwa: xperf.exe -stop power_session

  9. Konversi file jejak biner menjadi format .csv dan yang dapat dibaca manusia: xperf.exe –i \user.etl > power.txt

  10. Buka file power.txt di editor teks dan cari ID perangkat keras perangkat GNSS. ID perangkat keras perangkat GNSS dapat ditentukan dari tab Detail properti perangkat di Manajer Perangkat di bawah Jalur Instans Perangkat. Dalam contoh di bawah ini, jalur instans perangkat perangkat GNSS adalah ACPI\MST0731\2&daba3ff&0.

  11. D3 IRP untuk perangkat GNSS ditunjukkan oleh peristiwa jenis Microsoft-Windows-Kernel-Power/IRP/Stop dengan jalur instans perangkat perangkat GNSS dan nilai peristiwa terakhir 3 untuk status D3. Output peristiwa di bawah ini dari file power.txt menunjukkan awal D3 IRP.

    Microsoft-Windows-Kernel-Power/Irp/Start , 7605393, "Unknown" ( 4), 256, 0, , , , , 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\MSFT0731\2&daba3ff&0", 3

  12. Kejadian ini harus dicatat di dekat awal file output power.txt. Parameter 0x868e2728 dalam contoh di atas adalah penunjuk ke struktur IRP D3. Dengan menemukan peristiwa berikutnya dengan penunjuk IRP yang sama ini, tampilan IRP D3 yang mengalir melalui tumpukan driver yang terdiri dari perangkat GNSS dapat ditemukan. Perhatikan bahwa pointer IRP akan menjadi sistem dan spesifik seumur hidup boot.

  13. Microsoft-Windows-Kernel-Power/Irp/Start , 7605393, "Unknown" ( 4), 256, 0, , , , , 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\ATML1000\2&daba3ff&0", 3

  14. Microsoft-Windows-Kernel-Power/Driver/Start , 7605416, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0, "\Driver\gpsdrv"

  15. Microsoft-Windows-Kernel-Power/Driver/Stop , 7605515, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0

  16. Microsoft-Windows-Kernel-Power/Driver/Start , 7608351, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x857ffb90, "\Driver\ACPI"

  17. Microsoft-Windows-Kernel-Power/Driver/Stop , 7608416, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x857ffb90

  18. Microsoft-Windows-Kernel-Power/Driver/Start , 7608424, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0, "\Driver\sensdrv"

Memvalidasi perangkat GNSS kembali ke D0 saat layar diaktifkan adalah proses serupa. Peristiwa Microsoft-Windows-Kernel-Power/IRP/Start untuk perangkat GNSS akan dicatat dengan status target 0 (D0). D0 IRP akan mengalir melalui driver yang terdiri dari tumpukan perangkat GNSS dengan cara yang sama dengan D3 IRP.

Daftar periksa manajemen daya GNSS

Integrator sistem, vendor radio GNSS, dan vendor SoC harus menggunakan daftar periksa berikut untuk memastikan bahwa desain manajemen daya sistem mereka kompatibel dengan Windows 8 ke atas.

  • Integrasikan perangkat GNSS ke platform modern berkemampuan siaga dalam urutan preferensi konfigurasi berikut:

    1. Terintegrasi bersama dengan modul MBB (untuk sistem yang dilengkapi dengan MBB), terhubung melalui USB.
    2. Terintegrasi ke SoC (untuk sistem yang memiliki GNSS pada SoC).
    3. Mandiri di luar SoC yang tersambung ke UART, I2C, atau bus berdaya rendah lainnya.

  • Pilih perangkat GNSS yang memiliki konsumsi daya rata-rata tidur (radio mati) kurang dari 1 mW, termasuk antarmuka koneksi bus apa pun.

  • Jika perangkat GNSS memiliki konsumsi daya rata-rata tidur (radio mati) yang lebih besar dari 1 mW, integrator sistem dan vendor perangkat GNSS harus mendukung penghapusan daya sepenuhnya dari perangkat GNSS ketika tidak ada klien aplikasi yang terhubung atau radio dimatikan oleh pengguna.

  • Pastikan bahwa vendor perangkat GNSS menyediakan driver sensor lokasi yang menerapkan manajemen daya runtime berdasarkan jumlah klien yang terhubung dan status radio GNSS.

  • Pastikan vendor perangkat GNSS menyediakan pustaka manajer radio yang mengekspos radio GNSS di aplikasi Windows Pengaturan.

    Driver sensor lokasi harus menerapkan antarmuka privat untuk mengomunikasikan status radio on/off antara pustaka manajer radio yang disediakan vendor dan driver sensor lokasi yang disediakan vendor.

  • Jika GNSS adalah perangkat mandiri di luar SoC yang terhubung melalui UART, I2C, atau bus berdaya rendah lainnya, integrator sistem dan vendor perangkat GNSS harus:

    1. Dokumentasikan GPIO apa pun antara perangkat GNSS dan SoC itu sendiri.
    2. Mengekspos GPIO apa pun untuk manajemen daya sebagai bagian dari wilayah operasi GPIO di namespace ACPI.

  • Jika GNSS adalah perangkat mandiri di luar SoC yang terhubung melalui UART, I2C, atau bus berdaya rendah lainnya dan konsumsi daya rata-rata perangkat GNSS dalam mode daya tidur lebih besar dari 1 mW, integrator sistem dan vendor perangkat GNSS harus:

    1. Sediakan sumber daya daya ACPI dan metode kontrol _ON/_OFF untuk menjelaskan domain daya GNSS.
    2. Berikan metode _PR0 dan _PR3 di bawah perangkat GNSS di namespace ACPI yang merujuk ke sumber daya ACPI yang dijelaskan.
    3. Pastikan bahwa driver sensor lokasi melakukan transisi D3 dan mengaktifkan D3cold pada driver.

  • Jika GNSS adalah bagian dari modul MBB, integrator sistem dan vendor perangkat GNSS harus:

    1. Mengekspos perangkat GNSS sebagai bagian dari perangkat komposit USB.
    2. Berikan driver sensor lokasi yang berkomunikasi ke perangkat GNSS langsung melalui bus USB.
    3. Pastikan radio menyala/mati dan semua manajemen daya perangkat GNSS dapat dilakukan dalam pita melalui bus USB. Tidak ada GPIO yang dapat digunakan untuk mengubah radio GNSS atau status daya dalam konfigurasi perangkat keras ini.
    4. Pastikan bahwa perangkat USB yang menjelaskan modul MBB atau perangkat komposit USB yang menjelaskan radio MBB dan GNSS memasuki status ditangguhkan USB selama siaga modern.
    5. Driver sensor lokasi HARUS memasuki mode D3 (tidur) ketika semua klien terputus atau radio telah dimatikan bahkan jika berkomunikasi ke perangkat melalui antarmuka layanan perangkat.
    6. Jika perangkat GNSS dikontrol melalui antarmuka layanan perangkat broadband seluler (yang tidak disarankan), perangkat GNSS harus dijelaskan di namespace ACPI sistem tanpa sumber daya perangkat keras. Perangkat GNSS harus digambarkan sebagai anak dari modul broadband seluler di namespace ACPI.

  • Uji dan validasi bahwa perangkat GNSS dan driver sensor lokasi melakukan manajemen daya dengan benar. Harap validasi kasus pengujian berikut minimal:

    • Amati transisi driver sensor lokasi ke D3 dalam waktu 10 detik dari layar yang dimatikan untuk siaga modern.
    • Amati transisi driver sensor lokasi ke D3 dalam waktu 10 detik dari radio yang dimatikan di aplikasi Windows Pengaturan.
    • Amati transisi driver sensor lokasi ke D0 segera setelah keluar dari siaga modern dan meluncurkan aplikasi yang menggunakan API Lokasi.

  • Validasi konsumsi daya perangkat GNSS dalam status tidur (D3) dan pastikan bahwa rata-rata kurang dari 1 mW.