सूक्ष्मदर्शकाखाली BLE (ATTы GATTы…)

सूक्ष्मदर्शकाखाली BLE (ATTы GATTы…)

भाग १, आढावा

पहिले ब्लूटूथ ४.० स्पेसिफिकेशन रिलीज होऊन बराच काळ लोटला आहे. आणि BLE चा विषय खूप मनोरंजक असला तरी, त्याच्या जटिलतेमुळे तो अजूनही अनेक डेव्हलपर्सना अडचणीत आणतो. माझ्या मागील लेखांमध्ये, मी प्रामुख्याने सर्वात खालच्या पातळीवर लक्ष केंद्रित केले होते - लिंक लेयर आणि फिजिकल लेयर. यामुळे मला अॅट्रिब्यूट प्रोटोकॉल (ATP) आणि जेनेरिक अॅट्रिब्यूट प्रोफाइल (GATT) सारख्या जटिल आणि गोंधळात टाकणाऱ्या संकल्पना टाळता आल्या. तथापि, या संकल्पना समजून घेतल्याशिवाय, सुसंगत उपकरणे विकसित करणे अशक्य आहे. आज, मी हे ज्ञान तुमच्यासोबत शेअर करू इच्छितो. या लेखात, मी यावर अवलंबून राहीन पाठ्यपुस्तक नवशिक्यांसाठी, नॉर्डिकच्या वेबसाइटवरून. तर, चला सुरुवात करूया.

सगळं इतकं गुंतागुंतीचं का आहे?

माझ्या मते, स्मार्टफोनद्वारे डिव्हाइस नियंत्रित करणे ही एक अतिशय आशादायक आणि दीर्घकालीन संकल्पना आहे हे लगेच स्पष्ट झाले. म्हणून, आम्ही लगेचच शक्य तितक्या चांगल्या प्रकारे त्याची रचना करण्याचा निर्णय घेतला. गॅझेट उत्पादकांना त्यांचे स्वतःचे प्रोटोकॉल विकसित करण्यापासून रोखण्यासाठी हे करण्यात आले जे नंतर विसंगत असतील. हे गुंतागुंतीचे स्पष्टीकरण देते. अगदी सुरुवातीपासूनच, आम्ही BLE प्रोटोकॉलमध्ये शक्य तितके सर्व काही पिळून काढण्याचा प्रयत्न केला. आणि ते नंतर उपयुक्त ठरेल की नाही हे अप्रासंगिक होते. आम्ही भविष्यात डिव्हाइसेसची यादी वाढविण्याची शक्यता देखील प्रदान केली.

BLE प्रोटोकॉल आकृती दर्शविणारी प्रतिमा पाहूया. त्यात अनेक स्तर असतात. सर्वात खालचा, भौतिक स्तर (PHY), डिव्हाइसच्या रेडिओ चॅनेलसाठी जबाबदार असतो. लिंक लेयर (LL) मध्ये प्रसारित संदेशातील संपूर्ण बाइट क्रम असतो. आपण मागील लेखांमध्ये या स्तराचा अभ्यास केला आहे. कंट्रोलर आणि होस्ट वेगवेगळ्या चिप्सवर लागू केले असल्यास BLE स्तर किंवा चिप्समधील संप्रेषणासाठी होस्ट कंट्रोलर इंटरफेस (HCI) हा प्रोटोकॉल आहे. लॉजिकल लिंक कंट्रोल अँड अॅडॉप्टेशन प्रोटोकॉल (L2CAP) पॅकेट निर्मिती, फ्रेमिंग, एरर कंट्रोल आणि पॅकेट रीअसेंब्लीसाठी जबाबदार आहे. सिक्युरिटी मॅनेजर प्रोटोकॉल (SMP) पॅकेट एन्क्रिप्शनसाठी जबाबदार आहे. "कोण कोण आहे" हे निर्धारित करण्यासाठी डिव्हाइसेसमधील प्रारंभिक डेटा एक्सचेंजसाठी जेनेरिक अॅक्सेस प्रोफाइल (GAP) जबाबदार आहे. स्कॅनिंग आणि जाहिरात देखील या प्रोफाइल अंतर्गत येतात. या लेखात, मी प्रोटोकॉलच्या उर्वरित दोन भागांवर लक्ष केंद्रित करेन - GATT आणि ATT. GATT ही ATT वरील एक सुपरस्ट्रक्चर आहे, म्हणून ते जवळून एकमेकांशी जोडलेले आहेत.

चर्चा सोपी करण्यासाठी, मी एक उपमा वापरू इच्छितो. मी ते कुठेतरी ऐकले आहे आणि तेच प्रतिध्वनीत करू इच्छितो. कल्पना करा की एक BLE डिव्हाइस अनेक शेल्फ्स असलेले बुककेस आहे. प्रत्येक शेल्फ एक वेगळा विषय दर्शवितो. उदाहरणार्थ, आपल्याकडे विज्ञान कथा, गणित आणि विश्वकोशांसाठी शेल्फ्स आहेत. प्रत्येक शेल्फमध्ये त्या विषयावरील पुस्तके आहेत. काही पुस्तकांमध्ये नोट्ससह कागदी बुकमार्क देखील असतात. आपल्याकडे सर्व पुस्तकांचा एक छोटा कागदी कॅटलॉग देखील आहे. जर तुम्हाला शालेय ग्रंथालये आठवत असतील तर ती कागदी कार्डे असलेल्या अरुंद ड्रॉवरसारखी असतात. या उपमामध्ये, बुककेस हे आपल्या उपकरणाचे प्रोफाइल आहे. शेल्फ्स म्हणजे सेवा, पुस्तके म्हणजे वैशिष्ट्ये आणि कॅटलॉग म्हणजे एक विशेषता सारणी. पुस्तकांमधील बुकमार्क हे वर्णनात्मक आहेत, ज्याची मी नंतर अधिक तपशीलवार चर्चा करेन.

ज्यांनी उपकरणे विकसित केली आहेत त्यांना माहित आहे की अनेक प्रकल्पांमध्ये समान कोडचे तुकडे असतात. याचे कारण असे की अनेक उपकरणांमध्ये समान कार्यक्षमता असते. उदाहरणार्थ, जर उपकरणे बॅटरीवर चालणारी असतील, तर चार्जिंग आणि त्यांच्या पातळीचे निरीक्षण करण्याची समस्या सारखीच असेल. सेन्सर्सनाही हेच लागू होते. मूलतः, प्रोग्रामिंगसाठी ऑब्जेक्ट-ओरिएंटेड दृष्टिकोन "गुणधर्म आणि वर्तन एकत्रित करून एक स्वयंपूर्ण संघटन तयार करण्याची क्षमता प्रदान करते जी नंतर पुन्हा वापरली जाऊ शकते."माझ्या मते, BLE नेही असाच दृष्टिकोन वापरण्याचा प्रयत्न केला. ब्लूटूथ स्पेशल इंटरेस्ट ग्रुप (SIG) ने प्रोफाइल विकसित केले. वेगवेगळ्या उत्पादकांकडून समान प्रोफाइल असलेल्या डिव्हाइसेसनी एकमेकांशी अखंडपणे काम केले पाहिजे. प्रोफाइलमध्ये, सेवांचा समावेश असतो आणि सेवांमध्ये वर्णनकर्त्यांनी पूरक वैशिष्ट्ये असतात. सर्वसाधारणपणे, ते असे दिसू शकते:

उदाहरणार्थ, हृदय गती मॉनिटर (फिटनेस ब्रेसलेट) साठी प्रोफाइल आकृती पाहू. त्यात दोन सेवा आणि अनेक वैशिष्ट्ये आहेत. या आकृतीवरून प्रोफाइल पदानुक्रम लगेच स्पष्ट होतो. चेकपॉइंट वैशिष्ट्य एकूण कॅलरी खर्चाची संख्या शून्यावर रीसेट करते.

१. हृदय गती सेवेमध्ये तीन वैशिष्ट्ये समाविष्ट आहेत (०x१८०D):
    अ) अनिवार्य हृदय गती वैशिष्ट्य (०x२A३७)
    ब) पर्यायी बॉडी सेन्सर पोझिशन पॅरामीटर (०x२A३८)
    c) हृदय गती नियंत्रण बिंदूचे सशर्त वैशिष्ट्य (0x2A39)
२. बॅटरी देखभाल सेवा (०x१८०F):
    अ) अनिवार्य बॅटरी पातळी वैशिष्ट्य (०x२A१९)

यूआयडी

प्रोफाइल घटकांना (सेवा, वैशिष्ट्ये आणि वर्णनकर्ते) अद्वितीयपणे प्रवेश करण्यासाठी, त्या सर्वांना क्रमांकित करणे आवश्यक आहे. यासाठी, युनिव्हर्सली युनिक आयडी (UUID) ची संकल्पना सादर केली आहे. प्रत्येक ओळीवर कंसात UUID दर्शविला आहे. आणि येथे एक वैशिष्ट्य आहे. त्यांनी UUID साठी 16- आणि 128-बिट कोड वापरण्याचा निर्णय घेतला. तुम्ही विचारता का? BLE प्रोटोकॉल ऊर्जा संवर्धनाबद्दल आहे. म्हणून, 16-बिट कोड अगदी वाजवी आहे. नजीकच्या भविष्यात 65 पेक्षा जास्त अद्वितीय सेवा आणि वैशिष्ट्ये तयार होण्याची शक्यता कमी आहे. या टप्प्यावर, मोजता येणारी प्रत्येक गोष्ट आधीच मोजली गेली आहे (लक्षात ठेवा "त्याने तुम्हालाही मोजले" ही म्हण कुठून येते :-)) क्रमांकित घटक प्रोफाइल, सेवा, वैशिष्ट्ये и वर्णनकर्ते तुम्ही लिंक्स पाहू शकता.

तथापि, मला वाटते की इंटरनेटवरील ४-बाइट आयपी अॅड्रेसची कहाणी सर्वांना आठवत असेल. सुरुवातीला त्यांना वाटले की ते पुरेसे आहे, परंतु आता आम्हाला ६-बाइट अॅड्रेसवर जाण्यासाठी अजूनही संघर्ष करावा लागत आहे. ही चूक पुन्हा होऊ नये आणि DIY उत्साही लोकांच्या खोडकर हातांना मोकळीक मिळावी म्हणून, SIG ने ताबडतोब १२८-बिट UUIDs सादर करण्याचा निर्णय घेतला. हे मला परवाना नसलेल्या ४३३ MHz बँडची आठवण करून देते, जे सर्व प्रकारच्या रेडिओ चॅनेल हॅकसाठी दिले गेले होते. आमच्या बाबतीत, आम्हाला १२८-बिट सेवा आणि वैशिष्ट्यपूर्ण ओळखकर्ता देण्यात आला होता. याचा अर्थ असा की आम्ही आमच्या सेवा आणि उपकरणांसाठी जवळजवळ कोणतेही १२८-बिट मूल्य वापरू शकतो. प्रत्येकजण समान UUID घेऊन येण्याची शक्यता कमी किंवा कमी आहे.

खरं तर, लहान १६-बिट UUIDs चे १२८-बिट मूल्यापर्यंत स्वतःचे विस्तार असतात. स्पेसिफिकेशनमध्ये, या विस्ताराला ब्लूटूथ बेस UUID म्हणतात आणि त्याचे मूल्य 00000000-0000-1000-8000-00805F9B34FB आहे. उदाहरणार्थ, जर एखाद्या गुणधर्माच्या १६-बिट UUID चे मूल्य 0x1234 असेल, तर समतुल्य १२८-बिट UUID चे मूल्य 00001234-0000-1000-8000-00805F9B34FB असेल. संबंधित सूत्र अगदी दिले आहे:

                                १२८_बिट_व्हॅल्यू = १६_बिट_व्हॅल्यू * २^९६ + ब्लूटूथ_बेस_यूयूआयडी

मला माहित नाही की हा जादूचा आकडा कुठून आला. जर कोणाला वाचकांना माहित असेल तर कृपया टिप्पण्यांमध्ये लिहा (सिनोपटेक टोपणनाव असलेल्या वापरकर्त्याने आधीच असे केले आहे. टिप्पण्या पहा). १२८-बिट UUID तयार करण्यासाठी, तत्वतः, तुम्ही एक विशेष वापरू शकता जनरेटर, जे तुमच्यासाठी ते करेल.

एटीटीएस जीएटीटीएस…

आता मजेदार भाग येतो. मी तुम्हाला आठवण करून देतो की ATT क्लायंट-सर्व्हर संबंधांवर आधारित आहे. आपण आता सर्व्हर डिव्हाइस पाहत आहोत. त्यात सेन्सर व्हॅल्यूज, लाईट स्विच स्टेटस, लोकेशन डेटा इत्यादी माहिती आहे. आता "आमच्या परेडमधील सर्व सहभागी" क्रमांकित आहेत, आपल्याला ते कसे तरी डिव्हाइसच्या मेमरीमध्ये संग्रहित करावे लागतील. हे करण्यासाठी, आपण त्यांना अॅट्रिब्यूट टेबल नावाच्या टेबलमध्ये ठेवतो. हे काळजीपूर्वक लक्षात ठेवा. हे BLE चे हृदय आहे. आपण तेच पुढे तपासणार आहोत. आतापासून, आपण प्रत्येक ओळीला अॅट्रिब्यूट म्हणू. हे टेबल स्टॅकमध्ये खोलवर स्थित आहे आणि नियमानुसार, आपल्याला त्यावर थेट प्रवेश नाही. आपण ते सुरू करतो आणि त्यात प्रवेश करतो, परंतु आत काय होते ते एक रहस्य आहे.

चला स्पेसिफिकेशनमधील इमेज पाहूया, पण त्याआधी, मी अटींमधील एक सामान्य गोंधळ, विशेषतः वर्णनकर्त्यांकडे लक्ष वेधू इच्छितो. वर्णनकर्त्याची भूमिका एखाद्या वैशिष्ट्याच्या वर्णनाला पूरक म्हणून काम करते. जेव्हा त्याच्या क्षमता वाढवायची असतात तेव्हा वर्णनकर्त्यांचा वापर केला जातो. ते गुणधर्म देखील असतात आणि सेवा आणि वैशिष्ट्ये प्रमाणेच, गुणधर्म सारणीमध्ये असतात. आपण लेखाच्या दुसऱ्या भागात त्यांची तपशीलवार चर्चा करू. तथापि, कधीकधी वर्णनकर्त्यांचा वापर गुणधर्म सारणीमधील पंक्ती क्रमांकाचा संदर्भ देण्यासाठी केला जातो. हे लक्षात ठेवले पाहिजे. गोंधळ टाळण्यासाठी, आपण या उद्देशांसाठी "विशेषता पॉइंटर" हा शब्द वापरू.


म्हणून, गुणधर्म म्हणजे एक वेगळे मूल्य ज्याच्याशी खालील गुणधर्म संबंधित असतात:
१. अॅट्रिब्यूट हँडल म्हणजे अॅट्रिब्यूटशी संबंधित टेबल इंडेक्स.
२. विशेषता प्रकार हा एक UUID आहे जो त्याच्या प्रकाराचे वर्णन करतो
३. अॅट्रिब्यूट व्हॅल्यू म्हणजे अॅट्रिब्यूट पॉइंटरद्वारे इंडेक्स केलेला डेटा.
४. अॅट्रिब्यूट परवानग्या म्हणजे अॅट्रिब्यूटचा तो भाग जो अॅट्रिब्यूट प्रोटोकॉल वापरून वाचता किंवा लिहिता येत नाही.

हे सर्व आपण कसे समजून घ्यावे? एखाद्या गुणधर्माचा निर्देशांक म्हणजे, साधारणपणे, आपल्या टेबलमधील त्याची संख्या.
हे क्लायंटला वाचन किंवा लेखन विनंतीमध्ये एखाद्या गुणधर्माचा संदर्भ देण्याची परवानगी देते. आपण आपल्या ओळी (विशेषता) 0x0001 ते 0xFFFF पर्यंत क्रमांकित करू शकतो. आपल्या बुककेस रूपकामध्ये, हा कागदाच्या कॅटलॉगमधील कार्ड क्रमांक आहे. त्याचप्रमाणे, लायब्ररी कॅटलॉगमध्ये, कार्डे चढत्या क्रमाने लावली जातात. त्यानंतरच्या प्रत्येक ओळीची संख्या मागीलपेक्षा जास्त असणे आवश्यक आहे. जसे लायब्ररीमध्ये, कार्डे कधीकधी हरवतात, तसेच आपल्या ओळी क्रमांकांमधील अंतर देखील असू शकते. हे स्वीकार्य आहे. मुख्य गोष्ट अशी आहे की ते चढत्या क्रमाने आहेत.

विशेषता प्रकार हा विशेषता कशाचे प्रतिनिधित्व करते हे परिभाषित करतो. C भाषेप्रमाणेच,
जिथे बुलियन, न्यूमेरिक व्हेरिएबल्स आणि स्ट्रिंग्स आहेत, तिथे तेच आहे. अॅट्रिब्यूट प्रकारानुसार, आपल्याला माहित आहे
येथे आपण कशाचा सामना करत आहोत आणि या गुणधर्मासोबत आपण कसे पुढे जावे? खाली, आपण काही विशिष्ट गुणधर्म प्रकार पाहू. उदाहरणार्थ, "सेवा घोषणा" (0x2800), "वैशिष्ट्यपूर्ण घोषणा" (0x2803), आणि "वर्णनकर्ता घोषणा" (0x2902).

एखाद्या अॅट्रिब्यूटचे मूल्य हे त्याचे प्रत्यक्ष मूल्य असते, टॅटोलॉजीबद्दल माफ करा. जर अॅट्रिब्यूटचा प्रकार स्ट्रिंग असेल, तर त्याचे मूल्य उदाहरणार्थ, "हॅलो वर्ल्ड!!!" हे घोषवाक्य असू शकते. जर अॅट्रिब्यूटचा प्रकार "सेवा घोषणा" असेल, तर त्याचे मूल्य सेवाच असते. कधीकधी, ते इतर अॅट्रिब्यूट आणि त्यांचे गुणधर्म कुठे शोधायचे याबद्दल माहिती असते.

विशेषता परवानग्या सर्व्हरला वाचन किंवा लेखन प्रवेशास परवानगी आहे की नाही हे निर्धारित करण्याची परवानगी देतात.
कृपया लक्षात ठेवा की या परवानग्या फक्त अॅट्रिब्यूट व्हॅल्यूवर लागू होतात, पॉइंटर, टाइप किंवा परमिशन फील्डवर नाही. म्हणून, जर एखादे अॅट्रिब्यूट लिहिण्यायोग्य असेल, तर आपण उदाहरणार्थ, "हॅलो वर्ल्ड!!!" स्ट्रिंग "गुड मॉर्निंग" मध्ये बदलू शकतो. तथापि, आपण नवीन ओळ लिहिण्यास मनाई करू शकत नाही किंवा अॅट्रिब्यूट प्रकार बदलू शकत नाही आणि स्ट्रिंगला "सर्व्हिस डिक्लेरेशन" म्हणून नियुक्त करू शकत नाही. जेव्हा क्लायंट सर्व्हरमध्ये प्रवेश करतो, तेव्हा क्लायंट त्याच्या अॅट्रिब्यूटची विनंती करतो. हे क्लायंटला सर्व्हर काय प्रदान करू शकते हे निर्धारित करण्यास अनुमती देते, जरी मूल्ये वाचणे आणि लिहिणे आवश्यक नाही.

ते कशासारखे दिसते

GATT ची संकल्पना म्हणजे एका विशेषता सारणीतील गुणधर्मांना एका विशिष्ट आणि तार्किक क्रमाने एकत्रित करणे. चला खालील हृदय गती प्रोफाइलवर बारकाईने नजर टाकूया. या सारणीतील सर्वात डावीकडील स्तंभ पर्यायी आहे. तो फक्त ही पंक्ती (विशेषता) काय आहे याचे वर्णन करतो. इतर सर्व स्तंभ आधीच परिचित आहेत.

प्रत्येक गटाच्या वरच्या बाजूला, आपल्याकडे नेहमीच एक सेवा घोषणा विशेषता असते. त्याचा प्रकार नेहमीच 0x2800 असतो आणि त्याचा निर्देशांक टेबलमध्ये आधीच किती विशेषता आहेत यावर अवलंबून असतो. त्याच्या परवानग्या नेहमीच वाचनीय असतात, कोणत्याही प्रमाणीकरण किंवा अधिकृततेशिवाय. आपण या संकल्पनांवर नंतर चर्चा करू. मूल्य हे दुसरे UUID आहे जे सेवेची ओळख पटवते. टेबलमध्ये, मूल्य 0x180D आहे, जे ब्लूटूथ SIG द्वारे हृदय गती सेवा म्हणून परिभाषित केले आहे.

सेवा घोषणेनंतर येणारी वैशिष्ट्यपूर्ण घोषणा ही वैशिष्ट्यपूर्ण घोषणा असते. ती सेवा घोषणेसारखीच असते. तिचा UUID नेहमीच 0x2803 असतो आणि त्याच्या परवानग्या देखील नेहमीच वाचनीय असतात, कोणत्याही प्रमाणीकरण किंवा अधिकृततेशिवाय. चला अॅट्रिब्यूट व्हॅल्यू फील्ड पाहूया, ज्यामध्ये काही डेटा असतो. त्यात नेहमीच एक पॉइंटर, एक UUID आणि गुणधर्मांचा संच असतो. हे तीन घटक त्यानंतरच्या वैशिष्ट्यपूर्ण मूल्य घोषणेचे वर्णन करतात. पॉइंटर नैसर्गिकरित्या अॅट्रिब्यूट टेबलमध्ये वैशिष्ट्यपूर्ण मूल्य घोषणेचे स्थान दर्शवितो. UUID वर्णन करते की आपण कोणत्या प्रकारची माहिती किंवा मूल्य अपेक्षा करू शकतो—उदाहरणार्थ, तापमान मूल्य, लाईट स्विचची स्थिती किंवा इतर काही अनियंत्रित मूल्य. शेवटी, गुणधर्म वैशिष्ट्यपूर्ण मूल्याशी कसे संवाद साधायचे याचे वर्णन करतात.

इथे आणखी एक धोका आपल्यासमोर आहे. तो गुणधर्म परवानग्या आणि वैशिष्ट्यपूर्ण गुणधर्मांशी संबंधित आहे. चला स्पेसिफिकेशनमधील बिटफील्ड गुणधर्मांचे चित्र पाहू.

तुम्ही बघू शकता की, येथे काही फील्ड देखील आहेत जे वाचन आणि लेखन प्रवेश प्रदान करतात. तुम्हाला कदाचित प्रश्न पडेल की आमच्याकडे गुणधर्म आणि गुणधर्मांसाठी वाचन/लेखन परवानग्या का आहेत.
वैशिष्ट्यपूर्ण मूल्यासाठी वाचन/लेखन परवानग्या? त्या नेहमी सारख्याच असाव्यात की नाही? गोष्ट अशी आहे की, वैशिष्ट्यपूर्ण मूल्यासाठी गुणधर्म हे मूलतः GATT आणि अॅप्लिकेशन लेयर्समध्ये वापरल्या जाणाऱ्या क्लायंट शिफारसी आहेत. वैशिष्ट्यपूर्ण घोषणा गुणधर्माकडून क्लायंट काय अपेक्षा करू शकतो याबद्दल ते फक्त संकेत आहेत. चला हे जवळून पाहूया. एखाद्या गुणधर्माला कोणत्या प्रकारच्या परवानग्या असतात?

१. प्रवेश परवानग्या:
     — वाचन
     — रेकॉर्डिंग
     — वाचन आणि लेखन
२. प्रमाणीकरण परवानगी:
     — प्रमाणीकरण आवश्यक
     - प्रमाणीकरण आवश्यक नाही
३. अधिकृतता परवानगी:
     - अधिकृतता आवश्यक आहे
     - अधिकृतता आवश्यक नाही

विशेषता परवानग्या आणि वैशिष्ट्यपूर्ण गुणधर्मांमधील मुख्य फरक असा आहे की पहिल्या परवानग्या सर्व्हर-विशिष्ट असतात, तर दुसऱ्या क्लायंट-विशिष्ट असतात. सर्व्हर एखाद्या वैशिष्ट्यपूर्ण मूल्याचे वाचन करण्यास परवानगी देऊ शकतो, परंतु तरीही प्रमाणीकरण किंवा अधिकृतता आवश्यक असते. म्हणून, जेव्हा क्लायंट एखाद्या वैशिष्ट्यपूर्ण गुणधर्मांची विनंती करतो, तेव्हा आपल्याला दिसेल की वाचनास परवानगी आहे. तथापि, त्या वाचण्याचा प्रयत्न केल्याने त्रुटी येईल. म्हणून, आपण सुरक्षितपणे म्हणू शकतो की गुणधर्मांपेक्षा परवानग्या प्राधान्य देतात. क्लायंटच्या बाजूने, एखाद्या गुणधर्माला कोणत्या परवानग्या आहेत हे जाणून घेण्याचा कोणताही मार्ग आपल्याकडे नाही.

वर्णनकर्ता

चला आपल्या टेबलवर परत जाऊया. वैशिष्ट्यपूर्ण मूल्य घोषित केल्यानंतर, खालील गुणधर्म घोषणा शक्य आहेत:
१. नवीन वैशिष्ट्यपूर्ण घोषणा (एका सेवेमध्ये अनेक वैशिष्ट्ये असू शकतात)
२. नवीन सेवा घोषणा (टेबलमध्ये त्यापैकी बरेच असू शकतात)
३. वर्णनकर्त्याची घोषणा

आमच्या टेबलमधील हृदय गती मोजण्याच्या वैशिष्ट्याच्या बाबतीत, वैशिष्ट्यपूर्ण मूल्याची घोषणा डिस्क्रिप्टर घोषणापत्रासह असते. डिस्क्रिप्टर म्हणजे वैशिष्ट्याबद्दल अतिरिक्त माहिती असलेली एक विशेषता. अनेक प्रकारचे डिस्क्रिप्टर आहेत, ज्याची आपण या लेखाच्या दुसऱ्या भागात तपशीलवार चर्चा करू. सध्या, आपण फक्त क्लायंट कॅरेक्टरिस्टिक कॉन्फिगरेशन डिस्क्रिप्टर (CCCD) वर स्पर्श करू. त्याचा UUID 0x2902 आहे. या डिस्क्रिप्टरचा वापर करून, क्लायंट सर्व्हरवर एकतर संकेत किंवा सूचना सक्षम करू शकतो. त्यांच्यातील फरक सूक्ष्म आहे, परंतु तरीही आहे. सूचनांना क्लायंटकडून पावतीची पावती आवश्यक नसते. संकेत GATT स्तरावर होतो, अनुप्रयोग स्तरावर नाही. असे का आहे, तुम्ही विचारता? दुर्दैवाने, मला माहित नाही. मी फक्त एवढेच म्हणेन की नॉर्डिक तज्ञ सूचना वापरण्याची शिफारस करतात. शिवाय, पॅकेट इंटिग्रिटी चेकिंग (CRC वापरून) दोन्ही प्रकरणांमध्ये होते.

निष्कर्ष

लेखाच्या शेवटी, मी पुढील गोष्टी सांगू इच्छितो. शेवटचा तक्ता थोडा गोंधळात टाकणारा आहे. तथापि, मी त्यावर थांबलो कारण तो मध्ये दिलेला आहे लेख, ज्यावर मी अवलंबून आहे. माझ्या लेखाच्या दुसऱ्या भागात, मी ब्लूटूथ ४.० स्पेसिफिकेशनमध्ये खोलवर जाण्याचा विचार करतो. अधिक अचूक आकृत्या आणि चित्रे आपल्याला तिथे वाट पाहत आहेत. तिसऱ्या भागात, मी वायरशार्क वापरणाऱ्या एका गॅझेटमधून मिळवलेल्या लॉगचे विश्लेषण करू इच्छितो आणि आपण अभ्यास करत असलेल्या सर्व सिद्धांतांना प्रत्यक्षात पाहू इच्छितो.

कंपन्यांच्या गटाचे कर्मचारी सीझर सॅटेलाइट
व्लादिमीर पेचेर्स्की

स्त्रोत: www.habr.com