馃帳 Pilot / kontroler AI-Speaker z mikrofonem - jak dzia艂a i jak diagnozowa膰 problemy

Jak dzia艂a nasz pilot z mikrofonem

Ma to na celu wyja艣nienie jak technicznie dzia艂a nasz pilot radiowy.
Opis ten mo偶e by膰 pomocny przy diagnozowaniu problem贸w oraz w przypadku gdyby kto艣 chcia艂 doda膰 do bramki w艂asny kontroler lub mikrofon.

Za艂o偶enia wst臋pne

Zak艂adamy, 偶e:

  1. posiadasz nasz pilot radiowy z mikrofonem :slight_smile:
  2. przeczyta艂e艣 opis jak ten pilot dzia艂a http://ai-speaker.com/docs/ais_remote_index
  3. w razie problem贸w przeczyta艂e艣 FAQ http://ai-speaker.com/docs/ais_remote_faq_index

Wprowadzenie

Czym jest kontroler AI-Speker

Jest to uniwersalny kontroler kt贸ry dzi臋ki wbudowanemu mikrofonowi i fizycznym klawiszom pozwala na obs艂ugiwanie wszystkich funkcji w systemie Asystent domowy.

Z czego fizycznie si臋 sk艂ada kontroler

Z nadajnika (pilot) i odbiornika radiowego (klucz USB).
Transmisja odbywa si臋 na cz臋stotliwo艣ci 2,4 GHz (cz臋stotliwo艣膰 taka jak WiFi ale inny protok贸艂).
Dzi臋ki temu mamy:

  • du偶y zasi臋g dzia艂ania,
  • nie trzeba trafia膰 w odbiornik,
  • bardzo ma艂e zu偶ycie energii - podczas u偶ywania pobiera mniej ni偶 10 mA pr膮du z baterii. Gdy nie jest u偶ywana, tylko mikroamper (czyli prawie nie pobiera 偶adnego pr膮du).

Czym jest kontroler w Asystencie domowym

3 urz膮dzeniami:

  • klawiatur膮 bezprzewodow膮
  • 偶yroskopow膮 mysz膮 z czujnikiem po艂o偶enia
  • kart膮 audio z mikrofonem radiowym

Jak to dzia艂a w systemie

Po w艂o偶eniu klucza USB system wykonuje tzw. Plug and Play i Jolka m贸wi 鈥淒odano urz膮dzenie鈥︹.
Technicznie po w艂o偶eniu klucza kontrolera do portu USB, system go zasila i wykrywa urz膮dzenie - proces ten nazywa si臋 USB enumeration. Wyja艣nimy poni偶ej jak to dzia艂a.

Tryb hosta USB

Gdy urz膮dzenie USB jest pod艂膮czone do bramki, jak pokazano na zdj臋ciu poni偶ej

Rys.1. Bramka w trybie hosta USB
image

wtedy bramka jest w trybie hosta USB (wbudowany host USB lub jako OTG) - w zale偶no艣ci od tego do kt贸rego portu pod艂膮czono urz膮dzenie).

Bycie hostem USB oznacza, 偶e to bramka obs艂uguje pod艂膮czone urz膮dzenia USB (takie jak mikrofony, myszy, klawiatury i pendrive鈥檡) - te urz膮dzenia s膮 akcesoriami.

usb-host-accessory

Gdyby bramk臋 pod艂膮czy膰 do PC po USB OTG to wtedy bramka prze艂膮czy艂a by si臋 w tryb 鈥淎ccessory鈥 a hostem USB by艂 by komputer PC. Tym trybem pracy bramki nie b臋dziemy si臋 tu zajmowa膰.

Istotne na rysunku powy偶ej jest to, 偶e to Host USB musi zasila膰 pod艂膮czone urz膮dzenie - dostarcza膰 zasilanie 5 V (specyfikacja okre艣la, 偶e powinno by膰 ono mi臋dzy 4,75 V a 5,25 V) i 500 mA.

Wynik wykrycia urz膮dzenia mo偶na sprawdzi膰 poleceniem w konsoli:

lsusb

Rys.2. Wynik komendy libusb na bramce

:tipping_hand_woman: Mo偶e si臋 zda偶y膰, 偶e po pod艂膮czeniu urz膮dzenia USB system nie mo偶e go wykry膰 z powodu problemu z zasilaniem - urz膮dzenie do dzia艂ania mo偶e wymaga膰 wi臋cej pr膮du ni偶 magistrala USB jest mu w stanie dostarczy膰 (wi臋cej ni偶 500 mA). W takim wypadku pomocne mo偶e by膰 do艂o偶enie zasilanego koncentratora USB (hub) mi臋dzy bramk膮 a urz膮dzeniem USB.

Zarz膮dzanie urz膮dzeniami przez system Linux

Programowo zarz膮dzanie urz膮dzeniami USB przez Asystenta domowego odbywa si臋 pomi臋dzy j膮drem systemu Linux a przestrzeni膮 u偶ytkownika w systemie Android.

Obrazuje to grafika poni偶ej.

Rys.3. Zarz膮dzanie USB w systemie Linux / Android

W przestrzeni j膮dra linux (Android Kernel Space). dzia艂anie USB trybie hosta USB jest takie samo jak w g艂贸wnym j膮drze Linuksa (mainline Linux kernel).

W tym opisie nie b臋dziemy wnika膰 jak to si臋 dzieje, 偶e Linux z pod艂膮czonego urz膮dzenia robi plik w systemie. Istotne jest to, 偶e w Linux wszystko jest plikiem - urz膮dzenia do艂膮czone po USB te偶.
W uproszczeniu mo偶na powiedzie膰, 偶e na bardzo niskim poziomie, komunikacja z ka偶dym urz膮dzeniem w systemie odbywa si臋 poprzez pisanie i czytanie do plik贸w w lokalizacji /dev

ls -l /dev/usb/*

Rys.4. Wynik komendy ls -l /dev/usb/* na bramce AIS dom

Wykrywanie urz膮dze艅 przez Asystenta domowego

Tak jak pokazano na rysunku powy偶ej, dla nas kluczow膮 鈥渨arstw膮鈥 do komunikacji z urz膮dzeniami jest system plik贸w j膮dra (Kernel USB File System) oraz libusb kt贸ry jest interfejsem mi臋dzy sterownikiem USB j膮dra systemu Linux a naszym programem.

Zanim dojdzie jednak do komunikacji z urz膮dzeniem Asystent domowy jeste艣my powiadamiany przez mechanizm uevent - powiadamianie przestrzeni u偶ytkownika o zdarzeniach. Komunikaty 鈥渮darzenia u偶ytkownika鈥 (uevents) s膮 generowane przez sterownik j膮dra Linuxa.

W ten spos贸b Jolka wie, 偶e pod艂膮czono urz膮dzenie zigbee, dysk czy kontroler z mikrofonem.
Rys.5. Prost膮 ilustracja mechanizmu uevent na bramce AIS dom

Po tym jak dostaniemy powiadomienie o pod艂膮czonym urz膮dzeniu mo偶emy uruchomi膰 stosown膮 us艂ug臋 (pm start zirbee2mqtt), podmapowa膰 dysk i automatycznie pokaza膰 go w folderze 鈥渄yski wymienne鈥 itd.
Po usuni臋ciu urz膮dzenia te偶 jeste艣my powiadamiani i wtedy zatrzymujemy us艂ug臋 itd鈥

Kontroler - klawiatura i myszka

Interfejsem do urz膮dzenia s膮 pliki /dev/input/*

ls -l /dev/input/*

Rys.6. Wynik komendy ls -l /dev/input/* na bramce AIS dom

Komunikacja nie odbywa si臋 bezpo艣rednio przez plik ale przez us艂ug臋 鈥淚nput Manager鈥 kt贸ra korzysta z binarki libinput.so.

Asystent domowy zdarzenia o naci艣ni臋ciu przycisku kontrolera czy ruchu myszy otrzymuje z systemu Linux jako (Input events). Za ka偶dym razem, gdy u偶ytkownik naci艣nie przycisk na kontrolerze - generowane jest zdarzenie, kt贸re przechwytujemy w Asystencie domowym.

Aby obserwowa膰 zdarzenia kt贸re s膮 generowane, mo偶esz wpisa膰 w konsoli co艣 takiego:

su -c getevent

Rys.6. Wynik komendy su -c getevent na bramce AIS dom

:information_source: : getevent stale wy艣wietla nadchodz膮ce zdarzenia, dop贸ki nie naci艣niesz Ctrl-C.

Format zwracany przez getevent to typ zdarzenia, kod zdarzenia i warto艣膰 zdarzenia.
Dzi臋ki temu mo偶emy sprawdzi膰, czy kontroler przekazuje odpowiednie informacje do systemu Asystent domowy.

W podobny spos贸b mo偶emy wys艂a膰 zdarzenie (naci艣ni臋cie klawisza) do Asystenta domowego.

su -c "sendevent /dev/input/event7 1 330 1"

Rys.7. Wynik komendy sendevent na bramce AIS dom

:information_source: Jak wida膰 dane wyj艣ciowe getevent s膮 w formacie szesnastkowym (hexadecimal,), ale dane wej艣ciowe sendevent s膮 dziesi臋tne. Po naci艣ni臋ciu przycisku wysy艂ane jest wi臋cej zdarze艅 - je偶eli zmienimy format to w ten spos贸b mo偶emy programowo symulowa膰 naci艣ni臋cie przycisku.

Pro艣ciej mo偶na wys艂a膰 zdarzenie naci艣ni臋cia klawisza za pomoc膮 komendy input tu wystarczy poda膰 2 parametry:

input keyevent 

Na bazie komendy input keyevent dzia艂a nasza us艂uga kt贸ra mo偶e by膰 wywo艂ana z poziomu aplikacji Asystent domowy.

Rys.8. Us艂uga - emulacja naci艣ni臋cia klawisza na kontrolerze, za pomoc膮 input keyevent na bramce AIS dom

Kontroler - mikrofon

Urz膮dzenia audio nie s膮 obs艂ugiwane bezpo艣rednio przez /dev/input/* ale poprzez interfejs ALSA, binarki libtinyalsa.so i libaudio.so i serwis Audio Flinger.

Po pod艂膮czeniu kontrolera jego mikrofon dodany jest jako karta dzwi臋kowa, co mo偶na sprawdzi膰 komend膮:

cat /proc/asound/cards

Rys.9. Wynik komendy cat /proc/asound/cards na bramce AIS dom

Kary dzi臋kowe mog膮 by膰 obs艂ugiwane za pomoc膮 miksera, kt贸ry ma zwykle kilka kontrolek.
呕eby zobaczy膰, jakie kontrolki ma nasz kotroler (karta 2), wpisujemy w konsoli tak膮 komed臋:

su -c 'tinymix -D 1'

Rys.10. Wynik komendy su -c 鈥榯inymix -D 1鈥 na bramce AIS dom

Kontroler 2 (Mic Capture Volume) odpowiada za g艂o艣no艣膰 mikrofonu na kontrolerze, 偶eby wy艣wietli膰 jego, parametry wpisujemy w konsoli:

su -c 'tinymix -D 1 2'

Rys.11. Wynik komendy su -c 鈥榯inymix -D 1 2鈥欌 na bramce AIS dom

Wi臋cej o mo偶liwo艣ciach tinyalsa mo偶na przeczyta膰 na stronie projektu:

To jak to si臋 dzieje, 偶e po w艂o偶eniu HDMI dzwi臋k jest tam przekierowany a po podpi臋ciu SPDIF tam itd to ju偶 zas艂uga Androida i Audio Flinger


Mam nadzieje, 偶e powy偶szy opis wprowadza w temat tego jak dzia艂a kontroler w Asystencie domowym, po zg艂臋bieniu tego tematu przy odpowiednich zdolno艣ciach programistycznych, mo偶na doda膰 w艂asny kontroler i wysy艂a膰 z niego zdarzenia do bramki.

Oczywi艣cie pro艣ciej b臋dzie kupi膰 nasz kontroler, w艂o偶y膰 do bramki - Jolka powie, 偶e 鈥淧od艂膮czono pilot radiowy z mikrofonem鈥 i niech to magicznie dzia艂a :slight_smile: