Wsad

Co to jest grupowanie?

Grupowanie odnosi się do buforowania zdarzeń czujnika w centrum czujników lub w FIFO sprzętowym przed raportowaniem zdarzeń za pomocą interfejsu HAL czujnika. Na tej stronie „FIFO” oznacza lokalizację, w której są buforowane zdarzenia czujnika (węzeł czujnika lub FIFO sprzętowe). Gdy grupowanie zdarzeń czujników jest nieaktywne, zdarzenia czujników są natychmiast zgłaszane do interfejsu HAL czujników, jeśli jest on dostępny.

Przetwarzanie w grupach może znacznie zmniejszyć zużycie energii, ponieważ główny procesor aplikacji (AP) obsługujący Androida będzie uruchamiany tylko wtedy, gdy wiele zdarzeń czujnika będzie gotowych do przetworzenia, a nie przy każdym pojedynczym zdarzeniu. Potencjalne oszczędności energii są bezpośrednio powiązane z liczbą zdarzeń, które hub czujników lub FIFO może buforować: większa oszczędność energii jest możliwa, jeśli można grupować więcej zdarzeń. Przetwarzanie w grupach wykorzystuje pamięć o niskim poborze mocy, aby zmniejszyć liczbę wybudzeń AP o wysokim poborze mocy.

Grupowanie może mieć miejsce tylko wtedy, gdy czujnik ma FIFO sprzętowe lub może buforować zdarzenia w centrum czujników. W obu przypadkach czujnik musi zgłaszać maksymalną liczbę zdarzeń, które można umieścić w jednym pakiecie za pomocą elementu SensorInfo.fifoMaxEventCount.

Jeśli czujnik ma miejsce zarezerwowane w FIFO, musi zgłaszać liczbę zarezerwowanych zdarzeń za pomocą elementu SensorInfo.fifoReservedEventCount. Jeśli FIFO jest przeznaczony dla czujnika, SensorInfo.fifoReservedEventCount to rozmiar FIFO. Jeśli kolejka FIFO jest współdzielona przez kilka czujników, ta wartość może wynosić 0. Typowym przypadkiem użycia jest zezwolenie czujnikowi na używanie całej kolejki FIFO, jeśli jest to jedyny aktywny czujnik. Jeśli jest aktywnych kilka czujników, każdy z nich ma zagwarantowaną przestrzeń dla co najmniej SensorInfo.fifoReservedEventCountzdarzeń w kolejce FIFO. Jeśli używasz koncentratora czujników, gwarancja może być egzekwowana za pomocą oprogramowania.

Zdarzenia czujnika są grupowane w tych sytuacjach:

  • Aktualny maksymalny czas opóźnienia raportu czujnika jest większy niż 0, co oznacza, że zdarzenia czujnika mogą być opóźnione do maksymalnego czasu opóźnienia raportu, zanim zostaną zgłoszone przez HAL.
  • AP jest w trybie zawieszenia, a czujnik nie jest czujnikiem aktywującym. W takim przypadku zdarzenia nie mogą aktywować punktu dostępu i muszą być przechowywane do momentu jego uruchomienia.

Jeśli czujnik nie obsługuje grupowania, a punkt dostępu jest w stanie uśpienia, do punktu dostępu są zgłaszane tylko zdarzenia aktywacji czujnika. Zdarzenia nieaktywności nie mogą być zgłaszane do punktu dostępu.

Parametry zbiorczego przetwarzania

2 parametry, które określają działanie grupowania, to sampling_period_ns i max_report_latency_ns. sampling_period_ns określa, jak często generowane jest nowe zdarzenie czujnika, a max_report_latency_ns określa, ile czasu ma na zgłoszenie tego zdarzenia do interfejsu HAL czujników.

sampling_period_ns

Znaczenie parametru sampling_period_ns zależy od trybu raportowania wybranego czujnika:

  • Ciągły: sampling_period_ns to częstotliwość próbkowania, czyli szybkość generowania zdarzeń.
  • W przypadku zmiany: sampling_period_ns ogranicza częstotliwość próbkowania zdarzeń, co oznacza, że zdarzenia są generowane nie szybciej niż co sampling_period_ns nanosekund. Okresy mogą być dłuższe niż sampling_period_ns, jeśli nie generuje się żadne zdarzenie i mierzone wartości nie zmieniają się przez długi czas. Więcej informacji znajdziesz w sekcji Tryb raportowania „w przypadku zmiany”.
  • Jednorazowy: sampling_period_ns jest ignorowany. Nie ma to żadnego efektu.
  • Szczegóły dotyczące sposobu używania wartości sampling_period_ns w przypadku czujników specjalnych znajdziesz w artykule Typy czujników.

Więcej informacji o tym, jak sampling_period_ns wpływa na różne tryby raportowania, znajdziesz w sekcji Tryby raportowania.

W przypadku czujników ciągłych i zmianowych:

  • Jeśli sampling_period_ns jest mniejsza niż SensorInfo.minDelay, implementacja HAL musi w sposób cichy ograniczyć ją do max(SensorInfo.minDelay, 1ms). Android nie obsługuje generowania zdarzeń z częstotliwością większą niż 1000 Hz.
  • Jeśli sampling_period_ns jest większa niż SensorInfo.maxDelay, implementacja HAL musi w sposób cichy skrócić ją do SensorInfo.maxDelay.

Fizyczne czujniki mają czasem ograniczenia dotyczące szybkości działania i dokładności zegarów. Aby to uwzględnić, rzeczywista częstotliwość próbkowania może różnić się od żądanej częstotliwości, o ile spełnia wymagania podane w tabeli poniżej.

Jeśli żądana częstotliwość to:

Wtedy rzeczywista częstotliwość musi być

poniżej minimalnej częstotliwości (<1/maxDelay);

od 90% do 110% minimalnej częstotliwości

w zakresie minimalnej i maksymalnej częstotliwości

od 90% do 220% żądanej częstotliwości

powyżej maksymalnej częstotliwości (>1/minDelay)

90–110% maksymalnej częstotliwości i poniżej 1100 Hz.

max_report_latency_ns

max_report_latency_ns określa maksymalny czas w nanosekundach, przez który zdarzenia mogą być opóźniane i przechowywane w FIFO sprzętowym, zanim zostaną zgłoszone przez HAL, gdy AP jest aktywny.

Wartość 0 oznacza, że zdarzenia muszą być zgłaszane, gdy tylko zostaną zmierzone, albo pomijanie kolejki FIFO, albo opróżnianie kolejki FIFO, gdy tylko pojawi się jedno zdarzenie z czujnika.

Na przykład akcelerometr aktywowany z częstotliwością 50 Hz z max_report_latency_ns=0 będzie wywoływać przerwania 50 razy na sekundę, gdy punkt dostępu jest aktywny.

Gdy max_report_latency_ns>0, zdarzenia czujnika nie muszą być zgłaszane od razu po wykryciu. Mogą być one tymczasowo przechowywane w FIFO i zgłaszane w partiach, o ile żadne zdarzenie nie jest opóźnione o więcej niż max_report_latency_ns nanosekund. Oznacza to, że wszystkie zdarzenia od poprzedniej partii są rejestrowane i zwracane od razu. Pozwala to zmniejszyć liczbę przerw w składaniu danych do AP i pozwala AP przełączyć się w tryb oszczędzania energii (nieaktywność), gdy czujnik rejestruje i zbiera dane.

Z każdym zdarzeniem jest powiązana sygnatura czasowa. Opóźnienie raportowania zdarzenia nie ma wpływu na jego sygnaturę czasową. Musi być ona dokładna i odpowiadać czasowi wystąpienia zdarzenia, a nie czasowi jego zgłoszenia.

Zezwalanie na tymczasowe przechowywanie zdarzeń czujnika w FIFO nie zmienia sposobu przesyłania zdarzeń do HAL; zdarzenia z różnych czujników mogą być przeplatane, a wszystkie zdarzenia z tego samego czujnika są uporządkowane czasowo.

Zdarzenia aktywujące i nieaktywujące

Zdarzenia czujników z czujników aktywacji muszą być przechowywane w co najmniej 1 kole priorytetowej aktywacji. Typowym rozwiązaniem jest posiadanie jednej dużej współdzielonej kolejki aktywacji FIFO, w której zdarzenia ze wszystkich czujników są przeplatane. Możesz też utworzyć jeden kolejkowy FIFO na każdy czujnik lub dedykowane kolejki FIFO dla poszczególnych czujników i współdzieloną kolejkę FIFO dla pozostałych czujników.

Podobnie zdarzenia z niebudzących czujników muszą być przechowywane w co najmniej 1 FIFO niebudzącej.

W żadnym przypadku zdarzenia związane z czujnikiem aktywacji i nieaktywności nie mogą być przeplatane w tym samym kolejku FIFO. Zdarzenia aktywujące muszą być przechowywane w kole FIFO aktywacji, a zdarzenia nieaktywne – w kole FIFO nieaktywnej.

W przypadku metody FIFO z budzenie najlepszym rozwiązaniem jest pojedyncza, duża i wspólna metoda FIFO. W przypadku FIFO bez funkcji budzenia pojedyncza duża współdzielona pamięć FIFO i kilka małych rezerwowanych pamięci FIFO mają podobne charakterystyki zużycia energii. Więcej sugestii dotyczących konfigurowania poszczególnych kolejek FIFO znajdziesz w artykule Priorytet alokacji FIFO.

Działanie poza trybem zawieszenia

Gdy AP jest aktywny (nie w trybie zawieszenia), zdarzenia są tymczasowo przechowywane w FIFO, o ile nie są opóźnione o więcej niżmax_report_latency.

Dopóki AP nie wejdzie w tryb zawieszenia, żadne zdarzenie nie zostanie usunięte ani utracone. Jeśli wewnętrzne kolejki FIFO zostaną zapełnione przed upływem czasu max_report_latency, zdarzenia są raportowane w tym momencie, aby zapewnić, że żadne zdarzenie nie zostanie utracone.

Jeśli kilka czujników korzysta z tego samego FIFO, a max_report_latency jednego z nich upłynie, wszystkie zdarzenia z FIFO zostaną zgłoszone, nawet jeśli max_report_latency innych czujników jeszcze nie upłynęło. Dzięki temu zmniejsza się liczba raportów dotyczących partii zdarzeń. Jeśli musi zostać zgłoszone jedno zdarzenie, wszystkie zdarzenia ze wszystkich czujników są zgłaszane.

Jeśli na przykład są aktywne te czujniki:

  • akcelerometr grupowany z wartością max_report_latency = 20 s
  • zbiorczy pomiar żyroskopu z wartością max_report_latency = 5 s

Partie danych z akcelerometru są raportowane w tym samym czasie, w jakim są raportowane partie danych z żyroskopu (co 5 sekund), nawet jeśli akcelerometr i żyroskop nie mają wspólnej kolejki FIFO.

Działanie w trybie zawieszenia

Gromadzenie danych w partiach jest szczególnie przydatne do zbierania danych z czujników w tle bez utrzymywania AP w stanie aktywnym. Ponieważ sterowniki czujników i implementacja HAL nie mogą utrzymywać blokady aktywacji*, AP może przejść w tryb zawieszenia nawet wtedy, gdy zbierane są dane z czujnika.

Sposób działania czujników podczas zawieszenia AP zależy od tego, czy dany czujnik jest czujnikiem aktywacji. Więcej informacji znajdziesz w artykule Czujniki budzenia.

Gdy kolejka FIFO bez funkcji budzenia się zapełni, musi się owinąć i zachowywać jak bufor pętla, zastępując nowymi zdarzeniami starsze. max_report_latency nie ma wpływu na kolejki FIFO bez funkcji budzenia w trybie zawieszenia.

Gdy kolejka FIFO do budzenia się zapełni lub gdy max_report_latency jednego z czujników budzenia się kończy, sprzęt musi obudzić AP i przekazać dane.

W obu przypadkach (w trybie aktywnym i nieaktywnym) gdy tylko AP wyjdzie z trybu zawieszenia, wygenerowany zostanie pakiet ze wszystkimi FIFO, nawet jeśli czas max_report_latency niektórych czujników jeszcze nie upłynął. Pozwala to zminimalizować ryzyko, że punkt dostępu będzie musiał ponownie się obudzić zaraz po przejściu do trybu zawieszenia, a tym samym zminimalizować zużycie energii.

*Wyjątkiem od zasady, że sterowniki nie mogą blokować funkcji aktywacji, jest sytuacja, gdy czujnik aktywacji w trybie ciągłego raportowania jest włączony przez max_report_latency < 1 sekundę. W tym przypadku sterownik może zablokować blokadę aktywacji, ponieważ AP nie ma czasu na przejście do trybu zawieszenia, ponieważ zostanie ono wybudzone przez zdarzenie aktywacji przed przejściem do trybu zawieszenia.

Środki ostrożności podczas zbiorczego tworzenia czujników aktywacji

W zależności od urządzenia przejście AP z trybu zawieszenia do trybu normalnego i rozpoczęcie czyszczenia FIFO może zająć kilka milisekund. W kolejce FIFO musi być zarezerwowana wystarczająca ilość miejsca, aby urządzenie mogło wyjść z trybu zawieszenia bez przepełnienia kolejki FIFO aktywacji. Nie wolno tracić zdarzeń. Należy przestrzegać zasad: max_report_latency.

Środki ostrożności podczas grupowania czujników niewybudzających przy zmianie

Sensory reagujące na zmiany generują zdarzenia tylko wtedy, gdy zmienia się wartość, którą mierzą. Jeśli zmierzona wartość zmienia się, gdy punkt dostępu jest w trybie zawieszenia, aplikacje oczekują, że otrzymają zdarzenie, gdy tylko punkt dostępu wyjdzie z trybunu uśpienia. Z tego powodu grupowanie zdarzeń czujnika bez budzenia w przypadku zmian musi być wykonywane ostrożnie, jeśli czujnik udostępnia kolejkę FIFO innym czujnikom. Ostatnie zdarzenie wygenerowane przez każdy czujnik zmiany musi być zawsze zapisywane poza współdzielonym kolejką FIFO, aby nie mogło zostać zastąpione przez inne zdarzenia. Gdy punkt dostępu się budzi, po zgłoszeniu wszystkich zdarzeń z FIFO należy zgłosić ostatnie zdarzenie czujnika zmiany.

Oto sytuacja, której należy unikać:

  1. Aplikacja rejestruje się w liczniku kroków bez funkcji budzenia (przy zmianie) i w przyspieszaczu bez funkcji budzenia (ciągłym), które dzielą ten sam stos FIFO.
  2. Aplikacja odbiera zdarzenie licznika kroków step_count=1000 stepscode>.
  3. AP przechodzi w stan zawieszenia.
  4. Użytkownik pokonuje 20 krok, co powoduje przeplatanie zdarzeń związanych ze licznikiem kroków i z akcelerometrem. Ostatnie zdarzenie związane ze licznikiem kroków to step_count = 1020 steps.
  5. Użytkownik przez długi czas nie porusza się, przez co zdarzenia akcelerometru nadal gromadzą się w FIFO, ostatecznie zastępując wszystkie zdarzeniastep_count w wspólnym FIFO.
  6. AP się budzi i wszystkie zdarzenia z FIFO są wysyłane do aplikacji.
  7. Aplikacja otrzymuje tylko zdarzenia akcelerometru i myśli, że użytkownik nie chodził.

Dzięki zapisaniu ostatniego zdarzenia licznika kroków poza kolejką FIFO HAL może zgłaszać to zdarzenie, gdy AP się budzi, nawet jeśli wszystkie inne zdarzenia licznika kroków zostały zastąpione zdarzeniami akcelerometru. Dzięki temu aplikacja otrzymujestep_count = 1020 steps, gdy AP się budzi.

Wdrażanie zbiorczego przetwarzania

Aby oszczędzać energię, grupowanie musi być implementowane bez pomocy punktu dostępowego, a punkt dostępowy musi mieć możliwość zawieszenia podczas grupowania.

Jeśli grupowanie jest wykonywane w czujniku, należy zminimalizować zużycie energii przez ten czujnik.

Maksymalny czas oczekiwania na raport można zmienić w dowolnym momencie, w szczególności wtedy, gdy wybrany czujnik jest już włączony. Nie powinno to spowodować utraty zdarzeń.

Priorytet alokacji FIFO

Na platformach, na których rozmiar FIFO sprzętowego lub rozmiar bufora koncentratora czujników jest ograniczony, projektanci systemów mogą musieć wybrać, ile FIFO zarezerwować dla każdego czujnika. Aby ułatwić Ci wybór, podajemy listę możliwych zastosowań w przypadku zbiorczego przetwarzania danych z różnych czujników.

Wysoka wartość: oszczędne obliczanie pozycji pieszego

Docelowy czas grupowania: 1–10 minut

Czujniki do użycia w zbiorze:

  • Detektor kroków do budzenia
  • Wektor rotacji gry aktywującej o częstotliwości 5 Hz
  • Barometr pobudki o częstotliwości 5 Hz
  • Wybudzanie nieskalibrowanym magnetometrem o częstotliwości 5 Hz

Przetwarzanie tych danych w partiach umożliwia wykonywanie szacowania pozycji pieszego, gdy AP jest zawieszony.

Wysoka wartość: umiarkowana aktywność/rozpoznawanie gestów o zmiennej intensywności

Docelowy czas grupowania: 3 sekundy

Czujniki do grupowania: akcelerometr bez funkcji budzenia o częstotliwości 50 Hz

Gromadzenie tych danych umożliwia okresowe rozpoznawanie dowolnych czynności i gestów bez konieczności utrzymywania AP w stanie aktywnym podczas zbierania danych.

Średnia wartość: średnia moc ciągłej aktywności/rozpoznawania gestów

Docelowy czas grupowania: 1–3 minuty

Czujniki do grupowania: akcelerometr wybudzeniowy o częstotliwości 50 Hz

Gromadzenie tych danych umożliwia ciągłe rozpoznawanie dowolnych czynności i gestów bez konieczności utrzymywania AP w stanie aktywnym podczas zbierania danych.

Średnia–wysoka wartość: zmniejszenie obciążenia przez przerwy

Docelowy czas grupowania: < 1 sekunda

Czujniki do grupowania: dowolny czujnik o wysokiej częstotliwości, zwykle niewybudzający.

Jeśli żyroskop jest ustawiony na 240 Hz, nawet grupowanie tylko 10 zdarzeń z użyciem żyroskopu może zmniejszyć liczbę przerw od 240 na sekundę do 24 na sekundę.

Średnia wartość: ciągłe gromadzenie danych o niskiej częstotliwości

Docelowy czas grupowania: 1–10 minut

Czujniki do użycia w zbiorze:

  • Barometr pobudki o częstotliwości 1 Hz
  • Czujnik wilgotności w trybie wybudzania o częstotliwości 1 Hz
  • inne czujniki budzenia o niskiej częstotliwości o podobnych częstotliwościach.

Umożliwia tworzenie aplikacji monitorujących przy niskim poborze mocy.

Wartość średnio-niska: ciągłe gromadzenie danych ze wszystkich czujników

Docelowy czas grupowania: 1–10 minut

Czujniki do zbiorczego przetwarzania: wszystkie czujniki aktywacji o wysokiej częstotliwości.

Umożliwia pełne zbieranie danych z czujników, gdy AP jest w trybie zawieszenia. Rozważ to tylko wtedy, gdy miejsce w kolejce FIFO nie stanowi problemu.