{"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\/it\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","title":{"rendered":"BLE sotto la lente (ATT e GATT\u2026)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"BLE<\/p>\n

BLE sotto la lente (ATT e GATT\u2026)<\/h2>\n

Parte 1, panoramica<\/b><\/p>\n

\u00c8 passato un po' di tempo da quando \u00e8 stata rilasciata la prima specifica per Bluetooth 4.0. Sebbene il tema del BLE sia molto interessante, continua a scoraggiare molti sviluppatori a causa della sua complessit\u00e0. Negli articoli precedenti, ho trattato principalmente i livelli pi\u00f9 bassi, il Link Layer e il Physical Layer. Questo ha permesso di evitare concetti complicati e confusi come il protocollo degli attributi (ATT) e il profilo generale degli attributi (GATT). Tuttavia, non ci sono alternative: per sviluppare dispositivi compatibili \u00e8 impossibile ignorarli. Oggi mi piacerebbe condividere con voi queste conoscenze. Nella mia articolo, far\u00f2 riferimento a tutorial<\/a><\/noindex> per principianti dal sito di Nordic. Quindi, iniziamo.
\n<\/a><\/noindex><\/p>\n

Perch\u00e9 \u00e8 tutto cos\u00ec complicato?<\/h3>\n

\nDal mio punto di vista, era subito chiaro che la gestione dei dispositivi tramite smartphone \u00e8 un tema molto promettente e di lungo termine. Perci\u00f2 \u00e8 stata decisa una strutturazione immediata e massima. I produttori di vari gadget non dovrebbero inventare protocolli propri che in seguito risulterebbero incompatibili. Da qui la complessit\u00e0. Gi\u00e0 nella prima fase, nel protocollo BLE si \u00e8 cercato di includere tutto ci\u00f2 che era possibile. Non importa se sar\u00e0 utile in seguito o meno. Inoltre, \u00e8 stata prevista la possibilit\u00e0 di ampliare la lista dei dispositivi in futuro.<\/p>\n

Diamo un'occhiata all'immagine che illustra lo schema del protocollo BLE. Esso \u00e8 composto da diversi strati. Il primo strato, il livello fisico (PHY), \u00e8 responsabile del canale radio del dispositivo. Il Link Layer (LL) contiene tutta la sequenza di byte nel messaggio trasmesso. Nelle articoli precedenti, abbiamo studiato proprio questo. L'Host Controller Interface (HCI) \u00e8 il protocollo di scambio tra gli strati o i chip BLE, nel caso in cui Controller e Host siano implementati su chip differenti. La creazione dei pacchetti, la suddivisione in frame, il controllo degli errori e l'assemblaggio dei pacchetti sono gestiti dal Logical Link Control and Adaptation Protocol (L2CAP). La sicurezza dei pacchetti \u00e8 garantita dal Security Manager Protocol (SMP). Il Generic Access Profile (GAP) \u00e8 responsabile dello scambio iniziale di dati tra dispositivi, per determinare \u00abChi \u00e8 chi\u00bb. Esso comprende anche la scansione e la pubblicit\u00e0. In questo articolo mi soffermer\u00f2 sulle due parti rimanenti del protocollo: GATT e ATT. GATT \u00e8 un'estensione di ATT, pertanto sono strettamente interrelati.<\/p>\n

\"BLE
\n
\nPer semplificare la narrazione, vorrei usare un'analogia. L'ho sentita da qualche parte e vorrei sostenerla. Immaginate un dispositivo BLE come una libreria con diverse mensole. Ogni mensola rappresenta un tema diverso. Ad esempio, abbiamo mensole di fantascienza, matematica, enciclopedie. Su ogni mensola ci sono libri relativi al tema specifico. E in alcuni libri ci sono anche segnalibri con annotazioni. Inoltre, abbiamo un piccolo catalogo cartaceo di tutti i libri. Se ricordate le biblioteche scolastiche \u2014 \u00e8 un cassetto stretto con schede cartacee. Con questa analogia, la libreria rappresenta il profilo del nostro dispositivo. Le mensole sono i servizi, i libri sono le caratteristiche e il catalogo \u00e8 la tabella degli attributi. I segnalibri nei libri sono i descrittori, di cui parler\u00f2 pi\u00f9 avanti in modo pi\u00f9 dettagliato.<\/p>\n

Chi sviluppa dispositivi sa che in molti progetti ci sono sezioni di codice simili. Infatti, molti dispositivi hanno funzionalit\u00e0 comparabili. Ad esempio, se i dispositivi funzionano a batteria, il problema della ricarica e del monitoraggio del loro livello sar\u00e0 identico. Lo stesso vale per i sensori. In sostanza, l'approccio orientato agli oggetti nella programmazione \u00aboffre la possibilit\u00e0 di creare oggetti che legano insieme propriet\u00e0 e comportamenti in un'unione autonoma, che pu\u00f2 poi essere riutilizzata multiple volte\u00bb<\/i>. A mio avviso, nel BLE \u00e8 stata fatta un tentativo simile. Il gruppo Bluetooth Special Interest Group (SIG) ha sviluppato i profili. I dispositivi di diversi produttori, che hanno profili identici, devono funzionare senza difficolt\u00e0 tra loro. I profili, a loro volta, sono composti da servizi e i servizi da caratteristiche, arricchite da descrittori. In generale, questo pu\u00f2 apparire cos\u00ec:<\/p>\n

\"BLE
\n
\nAd esempio, consideriamo lo schema del profilo di un monitor della frequenza cardiaca (braccialetto fitness). Esso \u00e8 composto da due servizi e diverse caratteristiche. Da questo schema, la gerarchia del profilo \u00e8 subito chiara. La caratteristica del punto di controllo azzera il conteggio totale delle calorie. <\/p>\n

1. Il servizio della frequenza cardiaca include tre caratteristiche (0x180D):
\n    a) Caratteristica obbligatoria della frequenza cardiaca (0x2A37)
\n    b) Caratteristica opzionale della posizione del sensore corporeo (0x2A38)
\n    c) Caratteristica condizionale del punto di controllo della frequenza cardiaca (0x2A39)
\n2. Servizio di gestione della batteria (0x180F):
\n    a) Caratteristica obbligatoria del livello di carica della batteria (0x2A19)<\/p>\n

UUID<\/h3>\n

\nAffinch\u00e9 possiamo fare riferimento in modo univoco agli elementi del profilo (servizi, caratteristiche e descrittori), \u00e8 necessario numerarli in qualche modo. A questo scopo si introduce il concetto di Identificatore Unico Universale (UUID). Tra parentesi in ogni riga \u00e8 indicato proprio l'UUID. C'\u00e8 per\u00f2 una particolarit\u00e0. Per l'UUID si \u00e8 deciso di utilizzare un codice lungo 16 e 128 bit. Perch\u00e9, vi chiederete? Nel protocollo BLE tutto \u00e8 subordinato al risparmio energetico. Pertanto, una dimensione di 16 bit \u00e8 del tutto ragionevole. \u00c8 improbabile che nel prossimo futuro vengano creati pi\u00f9 di 65.000 servizi e caratteristiche unici. Fino ad ora, tutto ci\u00f2 che era possibile \u00e8 gi\u00e0 stato conteggiato (ricordate da dove viene \u2014 \"lui ha contato anche voi\" :-)) Elementi numerati profili<\/a><\/noindex>, servizi<\/a><\/noindex>, caratteristiche<\/a><\/noindex> e descrittori<\/a><\/noindex> potete visualizzarli tramite i link.<\/p>\n

Tuttavia, credo che tutti ricordino la storia dei 4 byte degli indirizzi IP su Internet. Inizialmente si pensava che fossero sufficienti, ma ora non riusciamo a passare agli indirizzi a 6 byte. Per evitare di ripetere questo errore e dare libero sfogo alle mani impertinenti dei fai-da-te, SIG ha deciso di introdurre anche UUID a 128 bit. Personalmente, mi ricorda lo spettro non autorizzato dei 433 MHz, che \u00e8 stato messo nelle mani di vari inventori nei canali radio. Nel nostro caso, \u00e8 stato messo a disposizione un identificatore a 128 bit per servizi e caratteristiche. Ci\u00f2 significa che possiamo utilizzare praticamente qualsiasi valore a 128 bit per i nostri servizi e dispositivi. La probabilit\u00e0 di inventare un UUID identico \u00e8 comunque prossima allo zero.<\/p>\n

In realt\u00e0, gli UUID brevi a 16 bit hanno una loro estensione fino a un valore a 128 bit. Nelle specifiche, questa estensione \u00e8 chiamata Bluetooth Base UUID ed \u00e8 rappresentata da 00000000-0000-1000-8000-00805F9B34FB. Se, ad esempio, l'UUID a 16 bit di un attributo ha un valore di 0x1234, il corrispondente UUID a 128 bit avr\u00e0 il valore 00001234-0000-1000-8000-00805F9B34FB. Viene persino fornita la formula corrispondente:<\/p>\n

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

Non so da dove derivi questo numero magico. Se qualcuno dei lettori lo sa, per favore scrivetelo nei commenti (L'utente con il nickname Sinopteek lo ha gi\u00e0 fatto. Vedi i commenti). Per quanto riguarda la creazione di UUID a 128 bit, puoi sfruttare un generatore<\/a><\/noindex>, che far\u00e0 questo per te.<\/p>\n

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

\n Ora inizia la parte pi\u00f9 interessante. Ricordo che ATT si basa sulla relazione client-server. Attualmente stiamo esaminando il dispositivo del server. Esso contiene informazioni come i valori dei sensori, lo stato dell'interruttore della luce, i dati sulla posizione, ecc. Ora che tutti i \"partecipanti al nostro parata\" sono numerati, dobbiamo in qualche modo posizionarli nella memoria del dispositivo. Per fare questo, li inseriamo in una tabella chiamata tabella degli attributi. Ricordate bene questo. \u00c8 il cuore del BLE. Sar\u00e0 lui il nostro argomento di discussione in seguito. Ora chiameremo ogni riga un attributo. Questa tabella si trova in profondit\u00e0 nello stack e, di solito, non abbiamo accesso diretto a essa. La inizializziamo e la consultiamo, ma ci\u00f2 che avviene al suo interno \u00e8 nascosto a noi. <\/p>\n

Consideriamo l'immagine dalla specifica, ma prima di tutto voglio sottolineare una confusione comune nei termini, in particolare nei descrittori. Il ruolo del descrittore \u00e8 quello di integrare la descrizione di una caratteristica. Quando \u00e8 necessario ampliare le sue funzionalit\u00e0, si utilizzano i descrittori. Essi sono anche attributi e, insieme ai servizi e alle caratteristiche, si trovano nella tabella degli attributi. Li esamineremo in dettaglio nella seconda parte dell'articolo. Tuttavia, a volte i descrittori vengono confusi con il numero di riga nella tabella degli attributi. \u00c8 importante tenerne conto. Per evitare confusioni, utilizzeremo per tali scopi il termine \"indicatore dell'attributo\".
\n\"BLE
\n
\nDunque, l'attributo \u00e8 un valore discreto che ha le seguenti propriet\u00e0 associate:
\n1. Indicatore dell'attributo (Attribute Handle) \u2014 \u00e8 l'indice della tabella corrispondente all'attributo
\n2. Tipo di attributo (Attribute Type) \u2014 \u00e8 un UUID che descrive il suo tipo
\n3. Valore dell'attributo (Attribute Value) \u2014 sono i dati indicizzati dall'indicatore dell'attributo
\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

Come interpretare tutto ci\u00f2? Un puntatore dell'attributo \u00e8, in un certo senso, il suo numero nella nostra tabella.
\nPermette al cliente di fare riferimento all'attributo nelle richieste di lettura o scrittura. Possiamo numerare le nostre righe (attributi) da 0x0001 a 0xFFFF. Nella nostra analogia con la libreria, questo \u00e8 il numero della scheda nel catalogo cartaceo. Analogamente, come nel catalogo della biblioteca, le schede sono disposte in ordine crescente di numero. Il numero di ogni riga successiva deve essere maggiore di quello precedente. Come in biblioteca, a volte alcune schede si perdono, cos\u00ec anche noi possiamo avere spazi nella numerazione delle righe. Questo \u00e8 consentito. L'importante \u00e8 che vadano in ordine crescente.<\/p>\n

Il tipo di attributo determina cosa rappresenta questo attributo. Analogamente al linguaggio C,
\ndove ci sono variabili booleani, numeriche e stringhe, cos\u00ec anche qui. Dal tipo di attributo capiamo
\ncon cosa abbiamo a che fare e come dobbiamo procedere con questo attributo. Di seguito esamineremo alcuni tipi specifici di attributi. Ad esempio, \"dichiarazione di servizio\" (0x2800), \"dichiarazione delle caratteristiche\" (0x2803), \"dichiarazione del descrittore\" (0x2902).<\/p>\n

Il valore di un attributo \u00e8 essenzialmente il suo valore, scusate la tautologia. Se il tipo di attributo \u00e8 una stringa, il valore dell'attributo pu\u00f2 essere ad esempio uno slogan come \u00abHello World !!!\u00bb. Se il tipo di attributo \u00e8 una \u00abdichiarazione del servizio\u00bb, allora il suo valore corrisponde al servizio stesso. A volte, pu\u00f2 fornire informazioni su dove trovare altri attributi e le loro propriet\u00e0.<\/p>\n

Le autorizzazioni degli attributi consentono al server di comprendere se l'accesso in lettura o scrittura \u00e8 consentito.
\nSi prega di notare che queste autorizzazioni si applicano solo al valore dell'attributo, e non al puntatore, al tipo e al campo delle autorizzazioni stesse. Cio\u00e8, se la scrittura dell'attributo \u00e8 consentita, possiamo cambiare ad esempio la stringa \u00abHello World !!!\u00bb in \u00abGood morning\u00bb. Ma non possiamo vietare la scrittura di una nuova stringa o cambiare il tipo di attributo designando la stringa come \u00abdichiarazione del servizio\u00bb. Quando un cliente si rivolge al server, richiede i suoi attributi. Questo consente al cliente di capire cosa pu\u00f2 fornire il server. Anche se non \u00e8 necessario leggere e registrare i valori.<\/p>\n

Come appare<\/h3>\n

\nIl concetto di GATT consiste nel raggruppare gli attributi in una tabella degli attributi in un ordine molto specifico e logico. Esaminiamo pi\u00f9 da vicino il profilo della frequenza cardiaca riportato di seguito. La colonna pi\u00f9 a sinistra di questa tabella non \u00e8 obbligatoria. Essa ci descrive semplicemente di cosa tratta questa riga (attributo). Tutte le altre colonne ci sono gi\u00e0 familiari.<\/p>\n

\"BLE
\n
\nNella parte superiore di ogni gruppo abbiamo sempre l'attributo di dichiarazione del servizio. Il suo tipo \u00e8 sempre uguale a 0x2800, e il puntatore dipende da quanti attributi sono gi\u00e0 presenti nella tabella. Le sue autorizzazioni sono sempre disponibili solo in lettura, senza alcuna verifica di autenticit\u00e0 o autorizzazione. Parleremo di questi concetti pi\u00f9 avanti. Il valore \u00e8 un altro UUID, che definisce di che servizio si tratta. Nella Tabella, il valore \u00e8 uguale a 0x180D, che \u00e8 definito dal Bluetooth SIG come servizio della frequenza cardiaca. <\/p>\n

Dopo l'annuncio del servizio, segue l'annuncio della caratteristica. Forma \u00e8 simile a quella dell'annuncio del servizio. Il suo UUID ha sempre il valore 0x2803, e le autorizzazioni sono sempre disponibili solo in lettura senza alcuna verifica di autenticit\u00e0 o autorizzazione. Esaminiamo il campo Valore dell'Attributo, che include alcuni dati. Esso contiene sempre un puntatore, un UUID e un insieme di propriet\u00e0. Questi tre elementi descrivono l'annuncio successivo del valore della caratteristica. Il puntatore indica naturalmente il luogo dell'annuncio del valore della caratteristica nella tabella degli attributi. L'UUID descrive che tipo di informazione o valore possiamo aspettarci. Ad esempio, un valore di temperatura, lo stato di un interruttore della luce o un altro valore arbitrario. Infine, le propriet\u00e0 descrivono come \u00e8 possibile interagire con il valore caratteristico. <\/p>\n

Qui ci attende un altro ostacolo. Esso \u00e8 legato alle autorizzazioni degli attributi e alle propriet\u00e0 delle caratteristiche. Esaminiamo l'immagine delle propriet\u00e0 del campo bittale dalla specifica.<\/p>\n

\"BLE
\n
\nCome puoi vedere, ci sono anche campi che permettono lettura e scrittura. Potresti chiederti perch\u00e9 abbiamo permessi di lettura\/scrittura per l'attributo e la propriet\u00e0
\ndella caratteristica del valore? Non dovrebbero forse essere sempre gli stessi? Il fatto \u00e8 che le propriet\u00e0 per il valore della caratteristica sono, in realt\u00e0, solo raccomandazioni per il cliente, utilizzate nei livelli GATT e applicativi. Sono solo indicazioni su cosa il cliente pu\u00f2 aspettarsi dall'attributo di dichiarazione della caratteristica. Approfondiamo il tema. Quali tipi di permessi esistono per l'attributo? <\/p>\n

1. Permessi di accesso:
\n     \u2014 lettura
\n     \u2014 scrittura
\n     \u2014 lettura e scrittura
\n2. Permesso di autenticazione:
\n     \u2014 autenticazione richiesta
\n     \u2014 autenticazione non richiesta
\n3. Permesso di autorizzazione:
\n     \u2014 autorizzazione richiesta
\n     \u2014 autorizzazione non richiesta<\/p>\n

La principale differenza tra i permessi degli attributi e le propriet\u00e0 delle caratteristiche \u00e8 che i primi si riferiscono ai server, mentre le seconde ai client. Un server pu\u00f2 avere il permesso di leggere il valore di una caratteristica, ma ci potrebbe essere una richiesta di autenticazione o autorizzazione. Pertanto, quando un client richiede le propriet\u00e0 di una caratteristica, scopriremo che la lettura \u00e8 consentita. Tuttavia, al tentativo di lettura, otterremo un errore. Quindi si pu\u00f2 affermare con sicurezza che i permessi hanno priorit\u00e0 rispetto alle propriet\u00e0. Non possiamo conoscere quali permessi ha un attributo dal lato del client.<\/p>\n

Descrittore<\/h3>\n

\nTorniamo alla nostra tabella. Dopo aver dichiarato il valore di una caratteristica, sono possibili le seguenti dichiarazioni degli attributi:
\n1. Nuova dichiarazione della caratteristica (ci possono essere molte caratteristiche nel servizio)
\n2. Nuova dichiarazione del servizio (nella tabella possono essercene molte)
\n3. Dichiarazione del descrittore <\/p>\n

Nel caso della caratteristica di misurazione della frequenza cardiaca, nella nostra tabella, l'annuncio del valore della caratteristica \u00e8 accompagnato dall'annuncio del descrittore. Il descrittore \u00e8 un attributo con informazioni aggiuntive sulla caratteristica. Esistono diversi tipi di descrittori. Di questo parleremo in dettaglio nella seconda parte di questo articolo. Ora ci occuperemo solo del descrittore di configurazione delle caratteristiche del cliente (Client Characteristic Configuration Descriptor - CCCD). Ha un UUID pari a 0x2902. Con questo descrittore, il cliente ha la possibilit\u00e0 di attivare sul server la visualizzazione o la notifica. La differenza tra le due \u00e8 piccola, ma c'\u00e8. La notifica non richiede conferma di ricezione da parte del cliente. La visualizzazione, invece, lo richiede, anche se avviene a livello GATT, senza raggiungere il livello dell'applicazione. Perch\u00e9 cos\u00ec, vi chiederete? Sfortunatamente, non lo so. Posso solo dire che gli esperti di Nordic consigliano di utilizzare la notifica. Tanto pi\u00f9 che il controllo dell'integrit\u00e0 del pacchetto (utilizzando CRC) avviene in entrambi i casi.<\/p>\n

Conclusione<\/h3>\n

\nAlla fine dell'articolo, vorrei dire ci\u00f2 che segue. L'ultima tabella \u00e8 un po' confusa. Tuttavia, mi sono concentrato su di essa perch\u00e9 \u00e8 presentata in articolo<\/a><\/noindex>, su cui mi baso. Nella seconda parte del mio articolo, intendo approfondire le specifiche di BlueTooth 4.0. Qui ci attendono diagrammi e illustrazioni pi\u00f9 accurati. Nella terza parte, vorrei analizzare il log ottenuto utilizzando il programma Wireshark da uno dei gadget e vedere \"dal vivo\" tutta la teoria che stiamo studiando.<\/p>\n

Un membro del Gruppo Compagnie \u00abCesare Satellit\u00bb<\/a><\/noindex>
\nVladimir Pechersky
\n
Fonte: 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\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 al microscopio (ATT e GATT\u2026) | ProHoster","description":"BLE al microscopio (ATT e GATT...) Parte 1, panoramica \u00c8 passato un tempo considerevole da quando \u00e8 stata rilasciata la prima specifica per Bluetooth 4.0. Anche se il tema BLE \u00e8 molto interessante, continua a respingere molti sviluppatori, a causa della sua complessit\u00e0. Negli articoli precedenti ho trattato principalmente il livello pi\u00f9 basso, il Link Layer e il Physical Layer.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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, \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.","og:url":"https:\/\/prohoster.info\/it\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84024","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=84024"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84024\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/84025"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=84024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=84024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=84024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}