Co to jest dozowanie?
Grupowanie odnosi się do buforowania zdarzeń czujnika w koncentratorze czujników i/lub sprzętowym FIFO przed zgłoszeniem zdarzeń za pośrednictwem warstwy HAL czujników . Lokalizacja, w której zdarzenia czujnika są buforowane (koncentrator czujnika i/lub sprzętowe FIFO) są na tej stronie określane jako „FIFO”. Gdy dozowanie zdarzeń czujnika nie jest aktywne, zdarzenia czujnika są natychmiast zgłaszane do warstwy HAL czujników, jeśli są dostępne.
Grupowanie może umożliwić znaczne oszczędności energii, budząc tylko główny procesor aplikacji (AP) z systemem Android, gdy wiele zdarzeń czujnika jest gotowych do przetworzenia, zamiast wybudzać go dla każdego pojedynczego zdarzenia. Potencjalne oszczędności energii są bezpośrednio skorelowane 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ń. Grupowanie wykorzystuje pamięć o niskim poborze mocy w celu zmniejszenia liczby wybudzeń AP o dużej mocy.
Dozowanie może nastąpić tylko wtedy, gdy czujnik posiada sprzętowe FIFO i/lub może buforować zdarzenia w koncentratorze czujnika. W obu przypadkach czujnik musi zgłosić maksymalną liczbę zdarzeń, które mogą być grupowane naraz za pośrednictwem SensorInfo.fifoMaxEventCount
.
Jeśli czujnik ma zarezerwowane miejsce w FIFO, czujnik musi zgłosić liczbę zarezerwowanych zdarzeń za pośrednictwem SensorInfo.fifoReservedEventCount
. Jeśli FIFO jest dedykowana dla czujnika, to SensorInfo.fifoReservedEventCount
jest rozmiarem FIFO. Jeśli FIFO jest współdzielone przez kilka czujników, ta wartość może wynosić zero. Częstym 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ą być opóźnione do maksymalnego opóźnienia raportu, zanim zostaną zgłoszone za pośrednictwem warstwy HAL.
- Punkt dostępowy jest w trybie wstrzymania, a czujnik nie jest czujnikiem wybudzonym. W takim przypadku zdarzenia nie mogą budzić AP i muszą być przechowywane do momentu obudzenia AP.
Jeśli czujnik nie obsługuje grupowania, a punkt dostępowy jest w stanie uśpienia, do punktu dostępowego zgłaszane są tylko zdarzenia czujnika wybudzenia, a zdarzenia bez wybudzenia nie mogą być zgłaszane do punktu dostępowego.
Parametry dozowania
Dwa parametry, które regulują 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, jak długo do zdarzenia należy zgłosić do warstwy HAL czujnika.
próbkowanie_okresu_ns
Znaczenie parametru sampling_period_ns
zależy od trybu raportowania określonego czujnika:
- Ciągłe:
sampling_period_ns
to częstotliwość próbkowania, czyli częstotliwość, z jaką generowane są zdarzenia. - Przy zmianie:
sampling_period_ns
ogranicza częstotliwość próbkowania zdarzeń, co oznacza, że zdarzenia są generowane nie szybciej niż co każdesampling_period_ns
nanosekund. Okresy mogą być dłuższe niżsampling_period_ns
, jeśli żadne zdarzenie nie jest generowane, a zmierzone wartości nie zmieniają się przez długie okresy. Aby uzyskać więcej informacji, zobacz tryb zgłaszania zmian . - Jednorazowy:
sampling_period_ns
jest ignorowane. Nie ma żadnego efektu. - Specjalne: Aby uzyskać szczegółowe informacje na temat wykorzystania
sampling_period_ns
dla czujników specjalnych, zobacz Typy czujników .
Aby uzyskać więcej informacji o wpływie sampling_period_ns
w różnych trybach, zobacz Tryby raportowania .
Dla czujników ciągłych i na zmianę:
- jeśli
sampling_period_ns
jest mniejszy niżSensorInfo.minDelay
, implementacja warstwy HAL musi dyskretnie zablokować ją domax(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
, implementacja warstwy HAL musi dyskretnie obciąć ją doSensorInfo.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 częstotliwości żądanej, o ile spełnia wymagania przedstawione w poniższej tabeli.
Jeśli żądana częstotliwość to | Wtedy rzeczywista częstotliwość musi być |
---|---|
poniżej minimalnej częstotliwości (<1/maxDelay) | między 90% a 110% minimalnej częstotliwości |
między minimalną a maksymalną częstotliwością | od 90% do 220% żądanej częstotliwości |
powyżej maksymalnej częstotliwości (>1/minDelay) | między 90% a 110% maksymalnej częstotliwości 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óźnione i przechowywane w sprzętowym FIFO, zanim zostaną zgłoszone przez HAL, gdy AP 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 pojawi się 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 AP jest przebudzony.
Gdy max_report_latency_ns>0
, zdarzenia czujnika nie muszą być zgłaszane zaraz po ich wykryciu. Mogą być tymczasowo przechowywane w FIFO i raportowane 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 jednocześnie. Zmniejsza to liczbę przerwań wysyłanych do punktu dostępowego i pozwala punktowi dostępowemu przełączyć się na tryb niższego poboru mocy (bezczynny), podczas gdy czujnik przechwytuje i grupuje dane.
Każde wydarzenie ma skojarzoną z nim sygnaturę czasową. Opóźnienie czasu zgłoszenia zdarzenia nie wpływa na sygnaturę czasową zdarzenia. Sygnatura czasowa musi być dokładna i odpowiadać czasowi, w którym zdarzenie fizycznie miało miejsce, a nie czasowi, w którym zostało zgłoszone.
Zezwolenie na tymczasowe przechowywanie zdarzeń czujnika w FIFO nie zmienia zachowania 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.
Pobudka i zdarzenia bez pobudki
Zdarzenia czujnika z czujników wybudzania muszą być przechowywane w jednej lub więcej FIFO wybudzania. Typowym projektem jest posiadanie pojedynczej, dużej, współdzielonej FIFO wybudzania, w której zdarzenia ze wszystkich czujników wybudzania są przeplatane. Alternatywnie, możesz mieć jeden FIFO budzenia na czujnik lub mieć dedykowane FIFO dla poszczególnych czujników budzenia i wspólne FIFO dla pozostałych czujników budzenia.
Podobnie zdarzenia czujnika z czujników niewybudzonych muszą być przechowywane w jednej lub więcej FIFO bez wybudzania.
We wszystkich przypadkach zdarzenia wybudzania czujnika i zdarzenia niewybudzania czujnika nie mogą być przeplatane w tym samym FIFO. Zdarzenia budzenia muszą być przechowywane w FIFO budzenia, a zdarzenia nie budzenia muszą być przechowywane w FIFO bez budzenia.
W przypadku budzenia FIFO, pojedyncza, duża, współdzielona konstrukcja FIFO zapewnia najlepsze korzyści w zakresie mocy. W przypadku FIFO bez wybudzania, pojedynczy, duży współdzielony FIFO i kilka małych zarezerwowanych FIFO ma podobne charakterystyki mocy. Aby uzyskać więcej sugestii dotyczących konfigurowania każdego FIFO, zobacz Priorytet alokacji FIFO .
Zachowanie poza trybem wstrzymania
Gdy AP jest przebudzony (nie jest w trybie wstrzymania), 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 porzucone ani utracone. Jeśli wewnętrzne FIFO zapełnią się przed upływem max_report_latency
, zdarzenia są zgłaszane w tym momencie, aby zapewnić, że żadne zdarzenie nie zostanie utracone.
Jeśli kilka czujników współdzieli tę samą FIFO i max_report_latency
jednego z nich, wszystkie zdarzenia z FIFO są zgłaszane, nawet jeśli max_report_latency
innych czujników jeszcze nie upłynął. Zmniejsza to liczbę zgłaszanych partii zdarzeń. Gdy konieczne jest zgłoszenie jednego zdarzenia, zgłaszane są wszystkie zdarzenia ze wszystkich czujników.
Na przykład, jeśli aktywowane są następujące czujniki:
- akcelerometr dozowany z
max_report_latency
= 20s - żyroskop dozowany 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 wstrzymania
Grupowanie jest szczególnie korzystne przy zbieraniu danych z czujników w tle bez usypiania punktu dostępowego. Ponieważ sterowniki czujników i implementacja HAL nie mogą utrzymywać blokady wybudzania*, punkt dostępowy może przejść w tryb wstrzymania nawet podczas zbierania danych z czujników.
Zachowanie czujników, gdy AP jest zawieszony, zależy od tego, czy czujnik jest czujnikiem wybudzania. Aby uzyskać więcej informacji, zobacz Czujniki budzenia .
Kiedy FIFO, które nie są wybudzone, zapełnia się, musi się zawijać i zachowywać jak bufor cykliczny, nadpisując starsze zdarzenia nowymi zdarzeniami, które zastępują stare. max_report_latency
nie ma wpływu na FIFO bez wybudzania w trybie wstrzymania.
Po zapełnieniu FIFO wybudzania lub po max_report_latency
jednego z czujników wybudzania, sprzęt musi wybudzić punkt dostępowy i zgłosić dane.
W obu przypadkach (wake-up i non-wake-up), gdy tylko AP wychodzi z trybu wstrzymania, tworzona jest partia z zawartością wszystkich FIFO, nawet jeśli max_report_latency
niektórych czujników jeszcze nie upłynęło. Minimalizuje to ryzyko ponownego wybudzenia punktu dostępowego wkrótce po powrocie do trybu wstrzymania, a tym samym minimalizuje zużycie energii.
*Jedynym godnym uwagi wyjątkiem sytuacji, w których kierowcy nie mogą wstrzymać blokady wybudzania, jest aktywacja czujnika wybudzenia z trybem ciągłego raportowania z max_report_latency
< 1 sekunda. W takim przypadku sterownik może wstrzymać blokadę wybudzania, ponieważ punkt dostępu nie ma czasu na przejście w tryb wstrzymania, ponieważ zostałby wybudzony przez zdarzenie wybudzenia przed przejściem w tryb wstrzymania.
Środki ostrożności podczas grupowania czujników budzenia
W zależności od urządzenia może minąć kilka milisekund, zanim AP całkowicie wyjdzie z trybu wstrzymania i zacznie opróżniać FIFO. W FIFO musi być przydzielona wystarczająca ilość miejsca nad głową, aby umożliwić urządzeniu wyjście z trybu wstrzymania bez przepełnienia FIFO budzenia. Żadne zdarzenia nie zostaną utracone, a max_report_latency
musi być przestrzegane.
Środki ostrożności, które należy podjąć podczas dozowania czujników niewybudzających się przy zmianie
Czujniki przy zmianie generują zdarzenia tylko wtedy, gdy zmienia się mierzona przez nie wartość. Jeśli zmierzona wartość zmienia się, gdy AP jest w trybie wstrzymania, aplikacje oczekują odebrania zdarzenia, gdy tylko AP się obudzi. Z tego powodu grupowanie zdarzeń czujnika, które nie są wybudzone przy zmianie, musi być wykonywane ostrożnie, jeśli czujnik współdzieli swoją FIFO z innymi czujnikami. Ostatnie zdarzenie wygenerowane przez każdy czujnik przy zmianie musi być zawsze zapisane poza współdzielonym FIFO, aby nigdy nie mogło zostać nadpisane przez inne zdarzenia. Gdy AP budzi się, po zgłoszeniu wszystkich zdarzeń z FIFO, należy zgłosić ostatnie zdarzenie przy zmianie czujnika.
Oto sytuacja, której należy unikać:
- Aplikacja rejestruje się w liczniku kroków bez wybudzenia (przy zmianie) i akcelerometrze bez wybudzenia (ciągły), oba współdzielą tę samą FIFO.
- Aplikacja otrzymuje zdarzenie licznika
step_count=1000 steps
kod>. - AP przechodzi w stan zawieszenia.
- Użytkownik przechodzi 20 kroków, powodując przeplatanie się zdarzeń licznika kroków i akcelerometru, przy czym ostatnie zdarzenie licznika kroków to
step_count = 1020 steps
. - Użytkownik nie porusza się przez długi czas, co powoduje, że zdarzenia akcelerometru nadal gromadzą się w FIFO, ostatecznie nadpisując każde zdarzenie
step_count
we współdzielonym FIFO. - AP budzi się i wszystkie zdarzenia z FIFO są wysyłane do aplikacji.
- Aplikacja odbiera tylko zdarzenia akcelerometru i uważa, że użytkownik nie chodził.
Zapisując ostatnie zdarzenie licznika kroków poza FIFO, HAL może zgłosić to zdarzenie, gdy AP się obudzi, 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
, gdy AP budzi się.
Wdrażanie grupowania
Aby oszczędzać energię, przetwarzanie wsadowe musi być realizowane bez pomocy punktu dostępowego, a punkt dostępowy musi mieć możliwość zawieszenia podczas przetwarzania wsadowego.
Jeśli przetwarzanie wsadowe jest wykonywane 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; a to nie powinno prowadzić do utraty wydarzeń.
Priorytet alokacji FIFO
Na platformach, na których sprzętowy FIFO i/lub rozmiar bufora koncentratora czujnika jest ograniczony, projektanci systemu mogą być zmuszeni do wyboru, ile FIFO zarezerwować dla każdego czujnika. Aby pomóc w tym wyborze, poniżej znajduje się lista możliwych zastosowań, w których dozowanie jest realizowane w różnych czujnikach.
Wysoka wartość: liczenie martwych pieszych o niskiej mocy
Docelowy czas dozowania: od 1 do 10 minut
Czujniki do partii:
- Detektor kroków budzenia
- Obudź się wektor rotacji gry przy 5 Hz
- Barometr budzenia przy 5 Hz
- Obudź nieskalibrowany magnetometr przy 5 Hz
Grupowanie tych danych pozwala na wykonywanie liczenia martwych pieszych, jednocześnie pozwalając AP przejść w stan zawieszenia.
Wysoka wartość: przerywana aktywność/rozpoznawanie gestów o średniej mocy
Docelowy czas dozowania: 3 sekundy
Czujniki do partii: 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 gromadzenia danych.
Średnia wartość: ciągła aktywność o średniej mocy/rozpoznawanie gestów
Docelowy czas dozowania: od 1 do 3 minut
Czujniki do partii: akcelerometr budzenia przy 50 Hz
Grupowanie tych danych umożliwia ciągłe rozpoznawanie dowolnych czynności i gestów bez konieczności utrzymywania punktu dostępowego w stanie czuwania podczas gromadzenia danych.
Średnia-wysoka wartość: redukcja obciążenia przerwania
Docelowy czas dozowania: < 1 sekunda
Czujniki do partii: dowolny czujnik wysokiej częstotliwości, zwykle bez wybudzania.
Jeśli żyroskop jest ustawiony na 240 Hz, nawet grupowanie zaledwie 10 zdarzeń żyroskopowych może zmniejszyć liczbę przerwań z 240 na sekundę do 24 na sekundę.
Średnia wartość: Ciągłe zbieranie danych o niskiej częstotliwości
Docelowy czas dozowania: od 1 do 10 minut
Czujniki do partii:
- Barometr budzenia przy 1 Hz
- Budzenie czujnika wilgotności przy 1 Hz
- Inne niskoczęstotliwościowe czujniki wybudzania z podobnymi częstotliwościami
Umożliwia tworzenie aplikacji monitorujących przy niskim poborze mocy.
Wartość średnio-niska: ciągła kolekcja z pełnymi czujnikami
Docelowy czas dozowania: od 1 do 10 minut
Czujniki do partii: Wszystkie czujniki budzenia, przy wysokich częstotliwościach
Pozwala na pełne zbieranie danych z czujnika podczas pozostawienia punktu dostępowego w trybie wstrzymania. Zastanów się tylko, czy przestrzeń FIFO nie jest problemem.