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

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

भाग १, विहंगावलोकन

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

सर्व काही इतके अवघड का आहे?

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

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

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

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

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

1. हृदय गती सेवेमध्ये तीन वैशिष्ट्ये समाविष्ट आहेत (0x180D):
    अ) अनिवार्य हृदय गती वैशिष्ट्य (0x2A37)
    b) ऑप्शनल बॉडी सेन्सर पोझिशन वैशिष्ट्य (0x2A38)
    c) हृदय गती नियंत्रण बिंदूची सशर्त वैशिष्ट्ये (0x2A39)
2. बॅटरी देखभाल सेवा (0x180F):
    अ) अनिवार्य बॅटरी चार्ज पातळी वैशिष्ट्य (0x2A19)

यूआयडी

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

तथापि, मला वाटते की प्रत्येकाला इंटरनेटवरील आयपी पत्त्यांच्या 4 बाइट्ससह कथा आठवते. सुरुवातीला आम्हाला वाटले की ते पुरेसे आहे, परंतु आता आम्ही अद्याप 6-बाइट पत्त्यावर स्विच करू शकत नाही. ही चूक पुन्हा होऊ नये म्हणून आणि DIYers च्या खेळकर हातांना मुक्त लगाम देण्यासाठी, SIG ने ताबडतोब 128-बिट UUID आणण्याचा निर्णय घेतला. हे मला वैयक्तिकरित्या विनापरवाना 433 मेगाहर्ट्झ बँडची आठवण करून देते, जे रेडिओ चॅनेलवरून सर्व प्रकारच्या कुलिबिन्सना देण्यात आले होते. आमच्या बाबतीत, सेवा आणि वैशिष्ट्यांचा 128-बिट अभिज्ञापक तयार केला गेला. याचा अर्थ आम्ही, आमच्या सेवा आणि उपकरणांसाठी, जवळजवळ कोणतेही 128-बिट मूल्य वापरू शकतो. सर्व समान, समान UUID सह येण्याची शक्यता शून्य आहे.

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

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

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

एटीटी गट्टी...

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

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


म्हणून विशेषता हे एक स्वतंत्र मूल्य आहे ज्याच्याशी संबंधित खालील गुणधर्म आहेत:
1. विशेषता हँडल ही विशेषताशी संबंधित सारणी निर्देशांक आहे
2. विशेषता प्रकार एक UUID आहे जो त्याच्या प्रकाराचे वर्णन करतो
3. विशेषता मूल्य म्हणजे विशेषता पॉइंटरद्वारे अनुक्रमित केलेला डेटा
4. विशेषता परवानग्या हा गुणधर्माचा भाग आहे, परवानग्या, ज्या विशेषता प्रोटोकॉल वापरून वाचल्या किंवा लिहिल्या जाऊ शकत नाहीत.

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

विशेषता प्रकार काय दर्शविते हे निर्धारित करते. सी भाषेशी साधर्म्य करून,
जेथे बुलियन, संख्यात्मक चल आणि स्ट्रिंग आहेत, म्हणून ते येथे आहे. विशेषता प्रकारानुसार आम्ही ओळखतो
आम्ही काय हाताळत आहोत आणि आम्ही या गुणधर्मासह कार्य कसे सुरू ठेवू शकतो. खाली आपण काही विशिष्ट प्रकारचे गुणधर्म पाहू. उदाहरणार्थ, “सेवा घोषणा” (0x2800), “वैशिष्ट्यपूर्ण घोषणा” (0x2803), “वर्णनकर्ता घोषणा” (0x2902).

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

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

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

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

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

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

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

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

1. प्रवेश परवानग्या:
     - वाचन
     - विक्रम
     - वाचा आणि लिहा
2. प्रमाणीकरण परवानगी:
     - प्रमाणीकरण आवश्यक
     - कोणतेही प्रमाणीकरण आवश्यक नाही
3. अधिकृतता परवानगी:
     - अधिकृतता आवश्यक
     - अधिकृतता आवश्यक नाही

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

वर्णन करणारा

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

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

निष्कर्ष

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

ग्रुप ऑफ कंपनीजचे कर्मचारी "सीझर उपग्रह"
पेचेरस्कीख व्लादिमीर

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