{"id":84024,"date":"2020-06-04T19:42:32","date_gmt":"2020-06-04T17:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty"},"modified":"2020-06-04T19:42:32","modified_gmt":"2020-06-04T17:42:32","slug":"ble-pod-mikroskopom-atty-gatty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","title":{"rendered":"BLE under mikroskopet (ATTs GATTs…)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"BLE<\/p>\n

BLE under mikroskopet (ATTs GATTs…)<\/h2>\n

Del 1, \u00f6versikt<\/b><\/p>\n

Det har redan g\u00e5tt ganska l\u00e5ng tid sedan den f\u00f6rsta specifikationen f\u00f6r Bluetooth 4.0 sl\u00e4pptes. Och \u00e4ven om BLE \u00e4r ett mycket intressant \u00e4mne, avskr\u00e4cker det fortfarande m\u00e5nga utvecklare p\u00e5 grund av sin komplexitet. I mina tidigare artiklar har jag huvudsakligen granskat det mest grundl\u00e4ggande lagret, Link Layer och Physical Layer. Detta gjorde det m\u00f6jligt att undvika att ta upp s\u00e5 komplexa och f\u00f6rvirrande begrepp som attributprotokoll (ATT) och det generella attributprofil (GATT). Men vi kan inte undvika dem, f\u00f6r att utveckla kompatibla enheter \u00e4r det om\u00f6jligt utan att f\u00f6rst\u00e5 dem. Idag skulle jag vilja dela med mig av dessa kunskaper. I min artikel kommer jag att bygga p\u00e5 en handledning<\/a><\/noindex> f\u00f6r nyb\u00f6rjare fr\u00e5n Nordic. S\u00e5 l\u00e5t oss b\u00f6rja.
\n<\/a><\/noindex><\/p>\n

Varf\u00f6r \u00e4r allt s\u00e5 komplicerat?<\/h3>\n

\nEnligt min \u00e5sikt var det tydligt fr\u00e5n b\u00f6rjan att kontroll av enheter via smartphones \u00e4r ett mycket lovande och l\u00e5ngsiktigt \u00e4mne. D\u00e4rf\u00f6r beslutades det att strukturera det omedelbart och maximalt. S\u00e5 att tillverkare av olika enheter inte skulle hitta p\u00e5 sina egna protokoll som sedan blir inkompatibla. D\u00e4rav komplexiteten. Redan i det f\u00f6rsta steget f\u00f6rs\u00f6kte man pressa in allt som var m\u00f6jligt i BLE-protokollet. Och oavsett om det kommer att vara anv\u00e4ndbart i framtiden eller inte. Dessutom f\u00f6ruts\u00e5gs m\u00f6jligheten att ut\u00f6ka enhetslistan f\u00f6r framtiden.<\/p>\n

L\u00e5t oss titta p\u00e5 en bild d\u00e4r schemat f\u00f6r BLE-protokollet \u00e4r ritat. Det best\u00e5r av flera lager. Det nedersta, det fysiska lagret (PHY) ansvarar f\u00f6r enhetens radiokanal. Link Layer (LL) inneh\u00e5ller hela sekvensen av byte i det \u00f6verf\u00f6rda meddelandet. I tidigare artiklar har vi studerat just detta. Host Controller Interface (HCI) \u00e4r protokollet f\u00f6r utbyte mellan lager eller chip i BLE, om Controller och Host implementerats p\u00e5 olika chip. Logisk l\u00e4nkkontroll och anpassningsprotokoll (L2CAP) ansvarar f\u00f6r bildandet av paket, uppdelning i ramar, felkontroll och paketsammanst\u00e4llning. Security Manager Protocol (SMP) ansvarar f\u00f6r kryptering av paket. Allm\u00e4n \u00e5tkomstprofil (GAP) ansvarar f\u00f6r den initiala datutbytet mellan enheter f\u00f6r att best\u00e4mma 'Vem \u00e4r vem'. Det omfattar ocks\u00e5 scanning och advertising. I denna artikel kommer jag att fokusera p\u00e5 de tv\u00e5 \u00e5terst\u00e5ende delarna av protokollet \u2014 GATT och ATT. GATT \u00e4r en \u00f6verbyggnad p\u00e5 ATT, s\u00e5 de \u00e4r starkt sammanfl\u00e4tade.<\/p>\n

\"BLE
\n
\nF\u00f6r att f\u00f6renkla ber\u00e4ttelsen skulle jag vilja anv\u00e4nda en analogi. Jag har h\u00f6rt den n\u00e5gonstans och skulle vilja st\u00f6dja den. F\u00f6rest\u00e4ll dig en BLE-enhet som en bokhylla med flera hyllplan. Varje hylla representerar ett s\u00e4rskilt \u00e4mne. Till exempel har vi hyllor med sk\u00f6nlitteratur, matematik, uppslagsverk. P\u00e5 varje hylla st\u00e5r b\u00f6cker med angivet \u00e4mne. Och i vissa b\u00f6cker finns det till och med pappersbokm\u00e4rken med anteckningar. Dessutom har vi en liten papperskatalog \u00f6ver alla b\u00f6cker. Om du minns skolbibliotek \u2014 det \u00e4r en smal l\u00e5da med papperskort. Med denna analogi \u00e4r bokhyllan profilen f\u00f6r v\u00e5r enhet. Hyllorna \u00e4r tj\u00e4nster, b\u00f6cker \u00e4r egenskaper, och katalogen \u00e4r en tabell med attribut. Bokm\u00e4rkena i b\u00f6ckerna \u00e4r deskriptorer, som jag ocks\u00e5 kommer att ber\u00e4tta mer om senare.<\/p>\n

Alla som har utvecklat enheter vet att det i m\u00e5nga projekt finns liknande kodbitar. Faktum \u00e4r att m\u00e5nga enheter har liknande funktionalitet. Till exempel, om enheterna drivs av batterier, kommer problemet med laddning och \u00f6vervakning av deras niv\u00e5 att vara detsamma. Det samma g\u00e4ller sensorer. Egentligen erbjuder det objektorienterade tillv\u00e4gag\u00e5ngss\u00e4ttet i programmering \"m\u00f6jlighet att skapa objekt som kopplar ihop egenskaper och beteenden i en sj\u00e4lvst\u00e4ndig f\u00f6rening som sedan kan \u00e5teranv\u00e4ndas p\u00e5 m\u00e5nga s\u00e4tt\"<\/i>. Enligt min mening har BLE f\u00f6rs\u00f6kt med en liknande ansats. En grupp fr\u00e5n Bluetooth Special Interest Group (SIG) har utvecklat profiler. Enheter fr\u00e5n olika tillverkare som har samma profiler b\u00f6r kunna arbeta tillsammans utan problem. Profiler best\u00e5r i sin tur av tj\u00e4nster, och tj\u00e4nster av egenskaper som kompletteras med deskriptorer. I allm\u00e4nhet kan detta se ut s\u00e5 h\u00e4r:<\/p>\n

\"BLE
\n
\nSom exempel kan vi titta p\u00e5 profilen f\u00f6r en pulsm\u00e4tare (fitnessarmband). Den best\u00e5r av tv\u00e5 tj\u00e4nster och flera egenskaper. Fr\u00e5n den kan vi omedelbart f\u00f6rst\u00e5 hierarkin i profilen. Egenskapen f\u00f6r kontrollpunkten \u00e5terst\u00e4ller den totala kaloriutgiften till noll. <\/p>\n

1. Tj\u00e4nsten f\u00f6r hj\u00e4rtfrekvens inkluderar tre egenskaper (0x180D):
\n    a) Obligatorisk egenskap f\u00f6r hj\u00e4rtfrekvens (0x2A37)
\n    b) Valfri egenskap f\u00f6r kroppens sensorposition (0x2A38)
\n    c) Konditionell egenskap f\u00f6r kontrollpunkten f\u00f6r hj\u00e4rtfrekvens (0x2A39)
\n2. Tj\u00e4nsten f\u00f6r batteri\u00f6vervakning (0x180F):
\n    a) Obligatorisk egenskap f\u00f6r batteriniv\u00e5 (0x2A19)<\/p>\n

UUID<\/h3>\n

\nF\u00f6r att vi tydligt ska kunna referera till profilens element (tj\u00e4nster, egenskaper och deskriptorer) m\u00e5ste vi numrera dem p\u00e5 n\u00e5got s\u00e4tt. F\u00f6r detta \u00e4ndam\u00e5l introduceras begreppet Universally Unique ID (UUID) eller Universell unik identifierare. I parenteserna vid varje rad anges just UUID. H\u00e4r finns det en egenskap. F\u00f6r UUID beslutades det att anv\u00e4nda en kodl\u00e4ngd p\u00e5 16 och 128 bitar. Varf\u00f6r, undrar ni? I BLE-protokollet styrs allt av energibesparing. D\u00e4rf\u00f6r \u00e4r en dimension p\u00e5 16 bitar helt rimlig. Det \u00e4r osannolikt att det kommer att skapas fler \u00e4n 65 000 unika tj\u00e4nster och egenskaper inom den n\u00e4rmaste framtiden. Just nu har vi redan r\u00e4knat allt vi kunde (minns ni varifr\u00e5n det kommer \u2014 \"han har r\u00e4knat er ocks\u00e5\" :-)) Numrerade element profiler<\/a><\/noindex>, tj\u00e4nster<\/a><\/noindex>, egenskaper<\/a><\/noindex> och deskriptorer<\/a><\/noindex> du kan titta p\u00e5 l\u00e4nkarna.<\/p>\n

Men jag tror att vi alla minns historien om de 4 bytes IP-adressen p\u00e5 internet. F\u00f6rst trodde man att det skulle r\u00e4cka, men nu kan vi fortfarande inte g\u00e5 \u00f6ver till en 6 bytes adress. F\u00f6r att inte upprepa det misstaget och ge plats \u00e5t busiga h\u00e4nder fr\u00e5n amat\u00f6rer, beslutade SIG redan fr\u00e5n b\u00f6rjan att inf\u00f6ra \u00e4ven 128-biters UUID. Detta p\u00e5minner mig personligen om det olicensierade 433 MHz-bandet, som gavs \u00e5t olika hobbyister fr\u00e5n radiokanalen. I v\u00e5rt fall gavs den 128-bitiga identifieraren f\u00f6r tj\u00e4nster och egenskaper ut. Detta inneb\u00e4r att vi, f\u00f6r v\u00e5ra tj\u00e4nster och enheter, praktiskt taget kan anv\u00e4nda vilket 128-bit v\u00e4rde som helst. Chansen att skapa en identisk UUID \u00e4r \u00e4nd\u00e5 n\u00e4ra noll.<\/p>\n

I sj\u00e4lva verket har korta 16-biters UUID sitt eget utvidgande till ett 128-bitars v\u00e4rde. I specifikationen kallas denna utvidgning Bluetooth Base UUID och har v\u00e4rdet 00000000-0000-1000-8000-00805F9B34FB. Om, till exempel, 16-biters UUID f\u00f6r attributet har v\u00e4rdet 0x1234, kommer dess motsvarande 128-bitars UUID att ha v\u00e4rdet 00001234-0000-1000-8000-00805F9B34FB. Det finns \u00e4ven en motsvarande formel angiven:<\/p>\n

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID<\/p>\n

Varifr\u00e5n detta magiska nummer kommer vet jag inte. Om n\u00e5gon av l\u00e4sarna vet \u2014 l\u00e5t dem skriva i kommentarerna (Anv\u00e4ndaren med smeknamnet Sinopteek har redan gjort det. Se kommentarerna). N\u00e4r det g\u00e4ller att skapa 128-bitars UUID, kan man i princip anv\u00e4nda en speciell generator.<\/a><\/noindex>, som g\u00f6r detta \u00e5t dig.<\/p>\n

ATT\u044b GATT\u044b…<\/h3>\n

\n Det \u00e4r faktiskt h\u00e4r det blir intressant. Jag p\u00e5minner om att ATT \u00e4r baserat p\u00e5 en klient-server-relation. Just nu tittar vi p\u00e5 serverdelsystemet. Det inneh\u00e5ller information som sensorv\u00e4rden, tillst\u00e5nd f\u00f6r ljusbrytaren, positionsdata, osv. Nu n\u00e4r alla \"deltagare i v\u00e5r parad\" \u00e4r numrerade, m\u00e5ste vi p\u00e5 n\u00e5got s\u00e4tt placera dem i minnet p\u00e5 enheten. F\u00f6r detta placerar vi dem i en tabell som kallas attributtabellen. Kom ih\u00e5g detta noggrant. Detta \u00e4r hj\u00e4rtat av BLE. Det \u00e4r just detta vi kommer att fokusera p\u00e5 i forts\u00e4ttningen. Nu ska vi kalla varje rad en attribut. Den h\u00e4r tabellen finns i djupet av stacken och vi har vanligtvis ingen direkt \u00e5tkomst till den. Vi initierar den och g\u00f6r anrop till den, men vad som h\u00e4nder d\u00e4r inne \u00e4r dolt f\u00f6r oss. <\/p>\n

L\u00e5t oss titta p\u00e5 bilden fr\u00e5n specifikationen, men innan dess vill jag genast p\u00e5peka f\u00f6rvirringen kring termer, s\u00e4rskilt kring descriptors. Rollen f\u00f6r en descriptor \u00e4r att komplettera beskrivningen av en egenskap. N\u00e4r vi beh\u00f6ver ut\u00f6ka dess funktioner, d\u00e5 anv\u00e4nder vi descriptors. De \u00e4r ocks\u00e5 attribut och, liksom tj\u00e4nster och egenskaper, finns de i attributtabellen. Vi kommer att g\u00e5 igenom dem i detalj i den andra delen av artikeln. Men ibland kallas descriptors f\u00f6r radnumret i attributtabellen. Det \u00e4r n\u00e5got att ha i \u00e5tanke. F\u00f6r att inte f\u00f6rv\u00e4xla dem, kommer vi f\u00f6r dessa \u00e4ndam\u00e5l att anv\u00e4nda termen \"attributpekar\".
\n\"BLE
\n
\nS\u00e5, ett attribut \u00e4r ett diskret v\u00e4rde som har f\u00f6ljande egenskaper kopplade till sig:
\n1. Attributpekar (Attribute Handle) - detta \u00e4r indexet i tabellen som motsvarar attributet.
\n2. Attributtyp (Attribute Type) - detta \u00e4r UUID som beskriver dess typ.
\n3. Attributv\u00e4rde (Attribute Value) - detta \u00e4r data som indexeras av attributpekaren.
\n4. \u0420\u0430\u0437\u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0430\u0442\u0440\u0438\u0431\u0443\u0442\u043e\u0432 (Attribute Permissions) \u2014 \u044d\u0442\u043e \u0447\u0430\u0441\u0442\u044c \u0430\u0442\u0440\u0438\u0431\u0443\u0442\u0430, \u0440\u0430\u0437\u0440\u0435\u0448\u0435\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435     \u043c\u043e\u0433\u0443\u0442 \u0431\u044b\u0442\u044c \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u044b \u0438\u043b\u0438 \u0437\u0430\u043f\u0438\u0441\u0430\u043d\u044b \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 \u0430\u0442\u0440\u0438\u0431\u0443\u0442\u043e\u0432<\/p>\n

Hur ska vi f\u00f6rst\u00e5 allt detta? Attributpekaren \u00e4r, f\u00f6r att tala i termer, dess nummer i v\u00e5r tabell.
\nDet g\u00f6r det m\u00f6jligt f\u00f6r kunden att referera till en attribut i l\u00e4s- eller skrivf\u00f6rfr\u00e5gningar. Vi kan numrera v\u00e5ra rader (attribut) fr\u00e5n 0x0001 till 0xFFFF. I v\u00e5r association med ett bibliotek \u00e4r detta kortnumret i den papperskatalogen. P\u00e5 samma s\u00e4tt som i ett biblioteks katalog placeras korten i ordning efter stigande nummer. Numret p\u00e5 varje efterf\u00f6ljande rad m\u00e5ste vara st\u00f6rre \u00e4n det f\u00f6reg\u00e5ende. Precis som i ett bibliotek kan vissa kort ibland f\u00f6rsvinna, s\u00e5 kan det ocks\u00e5 finnas luckor i radernas numrering. Detta \u00e4r till\u00e5tet. Det viktigaste \u00e4r att de g\u00e5r i ordning.<\/p>\n

Attributtypen avg\u00f6r vad den aktuella attributen representerar. I analogi med C-spr\u00e5ket,
\nd\u00e4r det finns booleska, numeriska variabler och str\u00e4ngar, s\u00e5 \u00e4r det h\u00e4r. Genom attributtypen f\u00e5r vi veta
\nvad vi har att g\u00f6ra med och hur vi ska arbeta med denna attribut vidare. Nedan kommer vi att titta p\u00e5 n\u00e5gra specifika attributtyper. Till exempel 'service declaration' (0x2800), 'characteristic declaration' (0x2803), 'descriptor declaration' (0x2902).<\/p>\n

Attributens v\u00e4rde \u00e4r faktiskt dess v\u00e4rde, f\u00f6rl\u00e5t f\u00f6r tautologin. Om attributtypen \u00e4r en str\u00e4ng kan attributv\u00e4rdet till exempel vara slogan \"Hello World !!!\". Om attributtypen \u00e4r en 'service declaration', d\u00e5 \u00e4r dess v\u00e4rde sj\u00e4lva tj\u00e4nsten. Ibland kan det \u00e4ven vara information om var man kan hitta andra attribut och deras egenskaper.<\/p>\n

Attributens beh\u00f6righeter g\u00f6r det m\u00f6jligt f\u00f6r servern att f\u00f6rst\u00e5 om l\u00e4s- eller skriv\u00e5tkomst \u00e4r till\u00e5ten.
\nObservera att dessa beh\u00f6righeter endast g\u00e4ller attributens v\u00e4rde och inte pekaren, typen och sj\u00e4lva beh\u00f6righetsf\u00e4ltet. Det vill s\u00e4ga, om skriv\u00e5tkomst till\u00e5tits f\u00f6r attributet, kan vi byta till exempel, raden \"Hello World !!!\" mot raden \"Good morning\". Men vi kan inte f\u00f6rbjuda att skriva en ny rad eller \u00e4ndra attributtypen och ange raden som en 'service declaration'. N\u00e4r en klient kontaktar servern beg\u00e4r klienten dess attribut. Detta g\u00f6r det m\u00f6jligt f\u00f6r klienten att ta reda p\u00e5 vad servern kan tillhandah\u00e5lla. \u00c4ven om det inte n\u00f6dv\u00e4ndigtvis \u00e4r n\u00f6dv\u00e4ndigt att l\u00e4sa och skriva v\u00e4rden.<\/p>\n

Hur det ser ut<\/h3>\n

\nKonceptet GATT best\u00e5r av att gruppera attribut i en attributtabell ihop i en mycket specifik och logisk ordning. L\u00e5t oss ta en n\u00e4rmare titt p\u00e5 profilen f\u00f6r hj\u00e4rtfrekvensen som visas nedan. Den v\u00e4nstra kolumnen i denna tabell \u00e4r valfri. Den beskriver helt enkelt vad denna rad (attributet) \u00e4r. Alla andra kolumner \u00e4r redan bekanta f\u00f6r oss.<\/p>\n

\"BLE
\n
\nI \u00f6verkant av varje grupp har vi alltid attributet f\u00f6r tj\u00e4nstebeskrivning. Dess typ \u00e4r alltid 0x2800, och pekaren beror p\u00e5 hur m\u00e5nga attribut som redan finns i tabellen. Dess beh\u00f6righeter \u00e4r alltid endast l\u00e4sbara, utan n\u00e5gon autentisering eller auktorisering. Vi kommer att prata om dessa begrepp lite senare. V\u00e4rdet \u00e4r en annan UUID som definierar vilken tj\u00e4nst detta \u00e4r. I tabellen \u00e4r v\u00e4rdet 0x180D, vilket Bluetooth SIG definierar som tj\u00e4nsten f\u00f6r hj\u00e4rtfrekvens. <\/p>\n

Efter tj\u00e4nstebeskrivningen f\u00f6ljer en beskrivning av egenskapen. I formen liknar den beskrivningen av tj\u00e4nsten. Dess UUID har alltid v\u00e4rdet 0x2803, och beh\u00f6righeterna \u00e4r ocks\u00e5 alltid endast l\u00e4sbara utan n\u00e5gon autentisering eller auktorisering. L\u00e5t oss titta p\u00e5 f\u00e4ltet Attributv\u00e4rde, som inkluderar viss information. Det inneh\u00e5ller alltid en pekare, UUID och en upps\u00e4ttning egenskaper. Dessa tre element beskriver den efterf\u00f6ljande beskrivningen av egenskapsv\u00e4rdet. Pekaren indikerar naturligtvis platsen f\u00f6r beskrivningen av egenskapsv\u00e4rdet i attributtabellen. UUID beskriver vilken typ av information eller v\u00e4rde vi kan f\u00f6rv\u00e4nta oss. Till exempel, temperaturv\u00e4rde, status f\u00f6r en ljusstr\u00f6mbrytare eller n\u00e5got annat godtyckligt v\u00e4rde. Slutligen beskriver egenskaperna hur man kan interagera med egenskapsv\u00e4rdet. <\/p>\n

H\u00e4r st\u00e5r vi inf\u00f6r ytterligare en f\u00e4lla. Den handlar om beh\u00f6righeterna f\u00f6r attributen och egenskaperna. L\u00e5t oss titta p\u00e5 bilden av bitf\u00e4ltens egenskaper fr\u00e5n specifikationen.<\/p>\n

\"BLE
\n
\nSom ni ser finns det h\u00e4r ocks\u00e5 f\u00e4lt som ger l\u00e4s- och skrivm\u00f6jligheter. Du kanske undrar varf\u00f6r vi har beh\u00f6righeter f\u00f6r l\u00e4sning\/skrivning f\u00f6r attributet och egenskapen.
\nL\u00e4s-\/skriv\u00e5tkomst f\u00f6r egenskapsv\u00e4rdet? Ska de inte alltid vara desamma? Faktum \u00e4r att egenskapsv\u00e4rdena i huvudsak \u00e4r rekommendationer f\u00f6r kunden, som anv\u00e4nds i GATT och applikationslager. De \u00e4r bara tips om vad kunden kan f\u00f6rv\u00e4nta sig av attributet f\u00f6r egenskapsdeklarationen. L\u00e5t oss g\u00e5 in p\u00e5 detta mer noggrant. Vilka typer av \u00e5tkomstr\u00e4ttigheter finns det f\u00f6r attributet? <\/p>\n

1. \u00c5tkomstr\u00e4ttigheter:
\n     \u2014 l\u00e4sning
\n     \u2014 skrivning
\n     \u2014 l\u00e4sning och skrivning
\n2. autentiseringstillst\u00e5nd:
\n     \u2014 autentisering kr\u00e4vs
\n     \u2014 autentisering kr\u00e4vs inte
\n3. auktoriseringstillst\u00e5nd:
\n     \u2014 auktorisering kr\u00e4vs
\n     \u2014 auktorisering kr\u00e4vs inte<\/p>\n

Den viktigaste skillnaden mellan attribut\u00e5tkomstr\u00e4ttigheter och egenskapsegenskaper \u00e4r att de f\u00f6rstn\u00e4mnda g\u00e4ller servrar medan de senare g\u00e4ller kunder. En server kan ha l\u00e4sbeh\u00f6righet f\u00f6r egenskapsv\u00e4rdet, men det kan finnas krav p\u00e5 autentisering eller auktorisering. D\u00e4rf\u00f6r, n\u00e4r kunden beg\u00e4r egenskapsv\u00e4rden, f\u00e5r vi veta att l\u00e4sning \u00e4r till\u00e5ten. Men vid f\u00f6rs\u00f6k att l\u00e4sa f\u00e5r vi ett felmeddelande. S\u00e5 det \u00e4r rimligt att s\u00e4ga att r\u00e4ttigheternas prioritet \u00f6ver egenskaperna \u00e4r avg\u00f6rande. Kunskapen om vilka r\u00e4ttigheter attributet har kan vi, fr\u00e5n kundens sida, inte f\u00e5.<\/p>\n

Descriptor<\/h3>\n

\nL\u00e5t oss \u00e5terkomma till v\u00e5r tabell. Efter att ha deklarerat egenskapsv\u00e4rdet kan f\u00f6ljande attributdeklarationer g\u00f6ras:
\n1. Ny egenskapsdeklaration (det kan finnas m\u00e5nga egenskaper i tj\u00e4nsten)
\n2. Ny tj\u00e4nstdeklaration (det kan finnas m\u00e5nga i tabellen)
\n3. Deklaration av descriptor <\/p>\n

N\u00e4r det g\u00e4ller egenskapen f\u00f6r att m\u00e4ta hj\u00e4rtfrekvens, s\u00e5 \u00e5tf\u00f6ljs v\u00e4rdet av egenskapen i v\u00e5r tabell av en deskriptor. En deskriptor \u00e4r en attribut med ytterligare information om egenskapen. Det finns flera typer av deskriptorer. Vi kommer att diskutera dessa mer ing\u00e5ende i den andra delen av denna artikel. Just nu fokuserar vi endast p\u00e5 deskriptoren f\u00f6r klientens egenskapskonfiguration (Client Characteristic Configuration Descriptor - CCCD). Den har ett UUID som \u00e4r 0x2902. Med hj\u00e4lp av denna deskriptor kan klienten aktivera indikation eller notifiering p\u00e5 servern. Skillnaden mellan dem \u00e4r liten, men \u00e4nd\u00e5 finns den. En notifiering kr\u00e4ver ingen bekr\u00e4ftelse fr\u00e5n klientens sida. En indikation kr\u00e4ver dock det, \u00e4ven om det sker p\u00e5 GATT-niv\u00e5, utan att n\u00e5 applikationsniv\u00e5n. Varf\u00f6r \u00e4r det s\u00e5, kanske ni undrar? Tyv\u00e4rr \u00e4r det n\u00e5got jag inte k\u00e4nner till. Jag kan bara s\u00e4ga att experter fr\u00e5n Nordic rekommenderar att anv\u00e4nda notifiering. S\u00e4rskilt eftersom paketintegritetskontrollen (genom CRC) sker i b\u00e5da fallen.<\/p>\n

Slutsats<\/h3>\n

\nI slutet av artikeln skulle jag vilja s\u00e4ga n\u00e5got mer. Den sista tabellen \u00e4r n\u00e5got f\u00f6rvirrande. Men jag valde att ta upp den eftersom den presenteras i artikeln<\/a><\/noindex>, som jag st\u00f6djer mig p\u00e5. I den andra delen av min artikel planerar jag att g\u00e5 djupare in i specifikationen f\u00f6r Bluetooth 4.0. D\u00e4r v\u00e4ntar mer korrekt grafik och diagram. I den tredje delen skulle jag vilja g\u00e5 igenom en logg som erh\u00e5llits med Wireshark fr\u00e5n en av enheterna och se \"i verkligheten\" all den teori som vi studerar.<\/p>\n

Anst\u00e4lld vid koncernen \u201eC\u00e9sar Satellite\u201c<\/a><\/noindex>
\nVladimir Pechersky
\n
K\u00e4lla: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b…) \u0427\u0430\u0441\u0442\u044c 1, \u043e\u0431\u0437\u043e\u0440\u043d\u0430\u044f \u0423\u0436\u0435 \u043f\u0440\u043e\u0448\u043b\u043e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u0441 \u0442\u0435\u0445 \u043f\u043e\u0440, \u043a\u043e\u0433\u0434\u0430 \u0432\u044b\u0448\u043b\u0430 \u043f\u0435\u0440\u0432\u0430\u044f \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u043d\u0430 Bluetooth 4.0. \u0418, \u0445\u043e\u0442\u044f \u0442\u0435\u043c\u0430 BLE \u043e\u0447\u0435\u043d\u044c \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0430, \u043e\u043d\u0430 \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043e\u0442\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0433\u0438\u0445 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432, \u0438\u0437-\u0437\u0430 \u0441\u0432\u043e\u0435\u0439 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u043b \u0432 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u043c \u0441\u0430\u043c\u044b\u0439 \u043d\u0438\u0436\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c Link Layer \u0438 Physical Layer. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84025,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84024","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47BLE under mikroskopet (ATT och GATT\u2026) | ProHoster","description":"BLE under mikroskopet (ATT och GATT...) Del 1.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b\u2026) | ProHoster","og:description":"BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b...) \u0427\u0430\u0441\u0442\u044c 1.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-04T17:42:32+00:00","article:modified_time":"2020-06-04T17:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84024","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:06:38","updated":"2022-09-28 11:11:59","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/84024","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=84024"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/84024\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/84025"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=84024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=84024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=84024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}