Grupowanie

Co to jest dozowanie?

Batch oznacza buforowanie zdarzeń czujnika w koncentratorze czujników i/lub sprzęcie FIFO przed zgłoszeniem zdarzeń za pośrednictwem warstwy HAL czujników . Lokalizacje, w których buforowane są zdarzenia czujnika (koncentrator czujnika i/lub sprzętowy FIFO), są określane na tej stronie jako „FIFO”. Gdy grupowanie zdarzeń czujnika nie jest aktywne, zdarzenia czujnika są natychmiast zgłaszane do warstwy HAL czujników, jeśli są dostępne.

Batch może umożliwić znaczne oszczędności energii poprzez wybudzanie głównego procesora aplikacji (AP), na którym działa system Android, tylko wtedy, gdy wiele zdarzeń czujnika jest gotowych do przetworzenia, zamiast budzić go dla każdego pojedynczego zdarzenia. Potencjalna oszczędność energii jest bezpośrednio powiązana z liczbą zdarzeń, które koncentrator czujników i/lub FIFO mogą buforować: istnieje większy potencjał oszczędności energii, jeśli można połączyć więcej zdarzeń wsadowo. Batching wykorzystuje pamięć o niskim poborze mocy, aby zmniejszyć liczbę wybudzania punktu dostępowego o dużej mocy.

Łączenie wsadowe może nastąpić tylko wtedy, gdy czujnik posiada sprzętowe FIFO i/lub może buforować zdarzenia w koncentratorze czujników. W obu przypadkach czujnik musi zgłosić maksymalną liczbę zdarzeń, które można jednocześnie zebrać wsadowo za pomocą SensorInfo.fifoMaxEventCount .

Jeśli czujnik ma zarezerwowane miejsce w FIFO, czujnik musi zgłosić liczbę zarezerwowanych zdarzeń za pomocą SensorInfo.fifoReservedEventCount . Jeśli FIFO jest przypisane do czujnika, to SensorInfo.fifoReservedEventCount jest rozmiarem FIFO. Jeśli FIFO jest współdzielone przez kilka czujników, wartość ta może wynosić zero. Typowym przypadkiem użycia jest umożliwienie czujnikowi wykorzystania całego FIFO, jeśli jest to jedyny aktywny czujnik. Jeśli aktywnych jest wiele czujników, każdy czujnik ma zagwarantowane miejsce na co najmniej zdarzenia SensorInfo.fifoReservedEventCount w FIFO. Jeśli używany jest koncentrator czujników, gwarancja może być egzekwowana za pomocą oprogramowania.

Zdarzenia czujnika są grupowane w następujących sytuacjach:

  • Bieżące maksymalne opóźnienie raportu czujnika jest większe od zera, co oznacza, że ​​zdarzenia czujnika mogą zostać opóźnione aż do maksymalnego opóźnienia raportu, zanim zostaną zgłoszone przez warstwę HAL.
  • Punkt dostępu znajduje się w trybie wstrzymania, a czujnik nie jest czujnikiem wybudzania. W takim przypadku zdarzenia nie mogą budzić punktu dostępowego i muszą być przechowywane do momentu przebudzenia punktu dostępowego.

Jeśli czujnik nie obsługuje grupowania wsadowego, a punkt dostępowy jest uśpiony, do punktu dostępowego zgłaszane są tylko zdarzenia czujnika wybudzenia, a zdarzenia niezwiązane z wybudzeniem nie mogą być zgłaszane do punktu dostępowego.

Parametry dozowania

Dwa parametry regulujące zachowanie przetwarzania wsadowego 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, po jakim czasie zdarzenie musi zostać zgłoszone do warstwy HAL czujników.

próbkowanie_okres_ns

Znaczenie parametru sampling_period_ns zależy od trybu raportowania określonego czujnika:

  • Ciągły: sampling_period_ns to częstotliwość próbkowania, czyli częstotliwość generowania zdarzeń.
  • Przy zmianie: sampling_period_ns ogranicza częstotliwość próbkowania zdarzeń, co oznacza, że ​​zdarzenia są generowane nie szybciej niż co każdy sampling_period_ns nanosekund. Okresy mogą być dłuższe niż sampling_period_ns , jeśli nie jest generowane żadne zdarzenie, a zmierzone wartości nie zmieniają się przez długi czas. Aby uzyskać więcej informacji, zobacz tryb raportowania zmian .
  • Jednorazowo: sampling_period_ns jest ignorowany. Nie ma to żadnego efektu.
  • Specjalne: szczegółowe informacje na temat wykorzystania sampling_period_ns w przypadku czujników specjalnych można znaleźć w sekcji Typy czujników .

Aby uzyskać więcej informacji na temat wpływu sampling_period_ns w różnych trybach, zobacz Tryby raportowania .

Dla czujników ciągłych i zmiennych:

  • jeśli sampling_period_ns jest mniejszy niż SensorInfo.minDelay , wówczas implementacja HAL musi po cichu ograniczyć go 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ększy niż SensorInfo.maxDelay , wówczas implementacja HAL musi dyskretnie obciąć go do SensorInfo.maxDelay .

Czujniki fizyczne mają czasami ograniczenia dotyczące szybkości działania i dokładności ich 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 poniższej tabeli.

Jeśli żądana częstotliwość wynosi

Zatem rzeczywista częstotliwość musi być

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

pomiędzy 90% a 110% częstotliwości minimalnej

pomiędzy częstotliwością minimalną i maksymalną

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

powyżej częstotliwości maksymalnej (>1/minOpóźnienie)

od 90% do 110% częstotliwości maksymalnej i poniżej 1100 Hz

max_report_latency_ns

max_report_latency_ns ustawia maksymalny czas w nanosekundach, o który zdarzenia mogą być opóźniane i przechowywane w sprzętowym FIFO przed raportowaniem przez warstwę HAL, gdy punkt dostępowy jest w stanie czuwania.

Wartość zero oznacza, że ​​zdarzenia muszą być zgłaszane natychmiast po ich zmierzeniu, albo całkowicie pomijając FIFO, albo opróżniając FIFO, gdy tylko wystąpi jedno zdarzenie z czujnika.

Na przykład akcelerometr aktywowany przy 50 Hz z max_report_latency_ns=0 będzie wyzwalał przerwania 50 razy na sekundę, gdy punkt dostępowy nie będzie aktywny.

Gdy max_report_latency_ns>0 , zdarzenia czujnika nie muszą być zgłaszane natychmiast po ich wykryciu. Można je tymczasowo przechowywać w FIFO i raportować partiami, 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 jednocześnie. Zmniejsza to liczbę przerwań wysyłanych do punktu dostępowego i umożliwia przełączenie punktu dostępowego w tryb niższego poboru mocy (bezczynność), podczas gdy czujnik przechwytuje i grupuje dane.

Każde wydarzenie ma przypisany znacznik czasu. Opóźnienie czasu raportowania zdarzenia nie ma wpływu na sygnaturę czasową zdarzenia. Znacznik czasu musi być dokładny i odpowiadać godzinie, w której zdarzenie fizycznie miało miejsce, a nie godzinie jego zgłoszenia.

Zezwolenie na tymczasowe przechowywanie zdarzeń czujnika w FIFO nie modyfikuje zachowania przesyłania zdarzeń do warstwy HAL; zdarzenia z różnych czujników można przeplatać, a wszystkie zdarzenia z tego samego czujnika są uporządkowane w czasie.

Zdarzenia budzące i nie budzące

Zdarzenia czujników z czujników wybudzenia muszą być przechowywane w jednym lub większej liczbie FIFO wybudzania. Powszechnym projektem jest posiadanie jednego, dużego, wspólnego FIFO budzenia, w którym przeplatają się zdarzenia ze wszystkich czujników budzenia. Alternatywnie możesz mieć jedno FIFO wybudzania na czujnik lub mieć dedykowane FIFO dla poszczególnych czujników wybudzenia i wspólne FIFO dla pozostałych czujników wybudzenia.

Podobnie zdarzenia czujników z czujników niebudzących muszą być przechowywane w jednym lub większej liczbie FIFO niebudzących.

We wszystkich przypadkach zdarzenia czujnika wybudzenia i zdarzenia niebędące czujnikiem wybudzenia nie mogą być przeplatane w tym samym FIFO. Zdarzenia budzące muszą być przechowywane w FIFO budzącym, a zdarzenia nie budzące muszą być przechowywane w FIFO nie budzącym.

W przypadku FIFO wybudzania, pojedyncza, duża, współdzielona konstrukcja FIFO zapewnia najlepsze korzyści w zakresie mocy. W przypadku FIFO bez wybudzania, pojedyncze, duże wspólne FIFO i kilka małych zarezerwowanych projektów FIFO mają podobną charakterystykę mocy. Aby uzyskać więcej sugestii dotyczących konfigurowania każdego FIFO, zobacz Priorytet alokacji FIFO .

Zachowanie poza trybem zawieszenia

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

Dopóki punkt dostępowy nie przejdzie w tryb zawieszenia, żadne zdarzenie nie zostanie porzucone ani utracone. Jeśli wewnętrzne FIFO zapełnią się przed upływem max_report_latency , zdarzenia są raportowane w tym momencie, aby mieć pewność, że żadne zdarzenie nie zostanie utracone.

Jeśli kilka czujników korzysta z tego samego FIFO i upłynie max_report_latency jednego z nich, raportowane będą wszystkie zdarzenia z FIFO, nawet jeśli max_report_latency pozostałych czujników jeszcze nie upłynął. Zmniejsza to liczbę raportowań partii zdarzeń. Gdy konieczne jest zgłoszenie jednego zdarzenia, raportowane są wszystkie zdarzenia ze wszystkich czujników.

Na przykład, jeśli aktywowane są następujące czujniki:

  • akcelerometr wsadowy z max_report_latency = 20s
  • żyroskop wsadowy z max_report_latency = 5s

Partie akcelerometru są raportowane w tym samym czasie, co partie żyroskopu (co 5 sekund), nawet jeśli akcelerometr i żyroskop nie mają tego samego FIFO.

Zachowanie w trybie zawieszenia

Batch jest szczególnie korzystny przy zbieraniu danych z czujników w tle bez utrzymywania punktu dostępowego w stanie czuwania. Ponieważ sterowniki czujników i implementacja HAL nie mogą utrzymywać blokady wybudzenia*, punkt dostępowy może przejść w tryb wstrzymania nawet podczas zbierania danych z czujnika.

Zachowanie czujników, gdy AP jest zawieszony, zależy od tego, czy czujnik jest czujnikiem wybudzenia. Aby uzyskać więcej informacji, zobacz Czujniki budzenia .

Kiedy zapełnia się FIFO, które nie jest wybudzane, musi się zawijać i zachowywać jak bufor cykliczny, zastępując starsze zdarzenia nowymi zdarzeniami zastępującymi stare. max_report_latency nie ma wpływu na FIFO nieaktywne w trybie zawieszenia.

Kiedy zapełni się FIFO wybudzania lub kiedy upłynie max_report_latency jednego z czujników wybudzenia, sprzęt musi obudzić punkt dostępowy i zgłosić dane.

W obu przypadkach (pobudzeniu i braku wybudzenia), gdy tylko punkt dostępowy wyjdzie z trybu wstrzymania, tworzona jest partia z zawartością wszystkich FIFO, nawet jeśli nie upłynął jeszcze max_report_latency niektórych czujników. Minimalizuje to ryzyko konieczności ponownego wybudzenia punktu dostępowego wkrótce po powrocie do trybu wstrzymania, a tym samym minimalizuje zużycie energii.

*Jedynym godnym uwagi wyjątkiem, w przypadku którego kierowcy nie mogą trzymać blokady budzenia, jest aktywacja czujnika budzenia z trybem ciągłego raportowania przy max_report_latency < 1 sekunda. W takim przypadku sterownik może utrzymać blokadę wybudzania, ponieważ punkt dostępowy nie ma czasu na przejście w tryb wstrzymania, ponieważ zostałby obudzony przez zdarzenie wybudzania przed przejściem w tryb wstrzymania.

Środki ostrożności podczas dozowania czujników budzenia

W zależności od urządzenia całkowite wyjście punktu dostępowego z trybu wstrzymania i rozpoczęcie opróżniania FIFO może zająć kilka milisekund. W FIFO należy przydzielić wystarczającą ilość wolnego miejsca, aby umożliwić urządzeniu wyjście z trybu wstrzymania bez przepełnienia FIFO wybudzania. Żadne zdarzenia nie zostaną utracone i należy przestrzegać wartości max_report_latency .

Środki ostrożności podczas dozowania czujników, które nie budzą się po zmianie

Czujniki on-change generują zdarzenia tylko wtedy, gdy zmienia się mierzona wartość. Jeśli zmierzona wartość zmieni się, gdy punkt dostępowy znajduje się w trybie wstrzymania, aplikacje oczekują otrzymania zdarzenia zaraz po przebudzeniu punktu dostępowego. Z tego powodu grupowanie zdarzeń czujnika , które nie powodują wybudzenia po zmianie, musi być przeprowadzane ostrożnie, jeśli czujnik dzieli swoje FIFO z innymi czujnikami. Ostatnie zdarzenie wygenerowane przez każdy czujnik zmiany musi być zawsze zapisane poza współdzielonym FIFO, aby nigdy nie mogło zostać zastąpione przez inne zdarzenia. Kiedy punkt dostępowy się obudzi, po zgłoszeniu wszystkich zdarzeń z FIFO, należy zgłosić ostatnie zdarzenie czujnika w przypadku zmiany.

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

  1. Aplikacja rejestruje się w liczniku kroków bez wybudzenia (w przypadku zmiany) i akcelerometrze w stanie bez wybudzenia (w trybie ciągłym), oba współdzielą to samo FIFO.
  2. Aplikacja odbiera zdarzenie licznika kroków step_count=1000 steps code>.
  3. AP przechodzi w stan zawieszenia.
  4. Użytkownik przechodzi 20 kroków, co powoduje przeplatanie się zdarzeń licznika kroków i akcelerometru, przy czym ostatnie zdarzenie licznika kroków to step_count = 1020 steps .
  5. Użytkownik nie porusza się przez długi czas, co powoduje dalsze gromadzenie się zdarzeń akcelerometru w FIFO, ostatecznie nadpisując każde zdarzenie step_count we współdzielonym FIFO.
  6. AP budzi się i wszystkie zdarzenia z FIFO są wysyłane do aplikacji.
  7. Aplikacja odbiera tylko zdarzenia z akcelerometru i uważa, że ​​użytkownik nie chodził.

Zapisując ostatnie zdarzenie licznika kroków poza FIFO, warstwa HAL może zgłosić to zdarzenie po przebudzeniu punktu dostępowego, nawet jeśli wszystkie inne zdarzenia licznika kroków zostały nadpisane przez zdarzenia akcelerometru. W ten sposób aplikacja otrzymuje step_count = 1020 steps po wybudzeniu punktu dostępowego.

Zaimplementuj przetwarzanie wsadowe

Aby oszczędzać energię, dozowanie musi być realizowane bez pomocy punktu dostępowego, a punkt dostępowy musi mieć możliwość zawieszenia się podczas dozowania.

Jeśli dozowanie odbywa się w koncentratorze czujników, należy zminimalizować zużycie energii przez koncentrator czujników.

Maksymalne opóźnienie raportu można zmienić w dowolnym momencie, w szczególności gdy określony czujnik jest już włączony; i nie powinno to skutkować utratą wydarzeń.

Priorytet alokacji FIFO

Na platformach, na których sprzętowy FIFO i/lub rozmiar bufora koncentratora czujników jest ograniczony, projektanci systemów mogą być zmuszeni wybrać, ile FIFO ma zostać zarezerwowane dla każdego czujnika. Aby pomóc w dokonaniu wyboru, poniżej znajduje się lista możliwych zastosowań, gdy w różnych czujnikach realizowane jest dozowanie.

Wysoka wartość: Zliczanie zgonów pieszych przy małej mocy

Docelowy czas dozowania: 1 do 10 minut

Czujniki do partii:

  • Detektor stopni budzenia
  • Wektor rotacji gry pobudki przy 5 Hz
  • Barometr budzenia przy 5 Hz
  • Obudź nieskalibrowany magnetometr przy 5 Hz

Grupowanie tych danych umożliwia obliczanie liczby ofiar śmiertelnych pieszych, jednocześnie pozwalając punktowi dostępowemu na zawieszenie.

Wysoka wartość: przerywana aktywność/rozpoznawanie gestów o średniej mocy

Docelowy czas dozowania: 3 sekundy

Czujniki do wsadu: Akcelerometr bez wybudzania przy 50 Hz

Grupowanie tych danych umożliwia okresowe rozpoznawanie dowolnych działań i gestów bez konieczności utrzymywania punktu dostępowego w stanie czuwania podczas zbierania danych.

Wartość średnia: ciągła aktywność/rozpoznawanie gestów o średniej mocy

Docelowy czas dozowania: 1 do 3 minut

Czujniki do wsadu: Akcelerometr budzenia przy 50 Hz

Grupowanie tych danych umożliwia ciągłe rozpoznawanie dowolnych działań i gestów bez konieczności utrzymywania punktu dostępowego w stanie czuwania podczas zbierania danych.

Wartość średnio-wysoka: Przerwanie redukcji obciążenia

Docelowy czas dozowania: < 1 sekunda

Czujniki do wsadu: dowolny czujnik wysokiej częstotliwości, zwykle bez wybudzenia.

Jeśli żyroskop jest ustawiony na 240 Hz, nawet zestawienie zaledwie 10 zdarzeń żyroskopowych może zmniejszyć liczbę przerwań z 240/sekundę do 24/sekundę.

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

Docelowy czas dozowania: 1 do 10 minut

Czujniki do partii:

  • Barometr budzenia przy 1 Hz
  • Budzenie czujnika wilgotności przy 1 Hz
  • Inne czujniki budzenia o niskiej częstotliwości z podobnymi częstotliwościami

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

Wartość średnio-niska: Ciągłe zbieranie danych z pełnych czujników

Docelowy czas dozowania: 1 do 10 minut

Czujniki do wsadu: wszystkie czujniki wybudzenia, przy wysokich częstotliwościach

Umożliwia pełne gromadzenie danych z czujnika, pozostawiając punkt dostępowy w trybie zawieszenia. Rozważ tylko, czy przestrzeń FIFO nie stanowi problemu.