माइक्रोस्कोप मुनि BLE (ATTы GATTы…)

माइक्रोस्कोप मुनि BLE (ATTы GATTы…)

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

ब्लुटुथ 4.0 को लागि पहिलो विनिर्देश जारी भएको पछि धेरै लामो समय बितिसकेको छ। र, यद्यपि BLE विषय धेरै रोचक छ, यसले अझै पनि यसको जटिलताको कारण धेरै विकासकर्ताहरूलाई बन्द राख्छ। मेरो अघिल्लो लेखहरूमा, मैले मुख्यतया तल्लो तह, लिङ्क तह र भौतिक तहमा हेरेँ। यसले हामीलाई एट्रिब्युट प्रोटोकल (ATT) र जनरल एट्रिब्युट प्रोफाइल (GATT) जस्ता जटिल र भ्रामक अवधारणाहरूको सहारा लिनबाट जोगिन अनुमति दियो। यद्यपि, त्यहाँ जाने कतै छैन, तिनीहरूलाई बुझे बिना, उपयुक्त उपकरणहरू विकास गर्न असम्भव छ। आज म तपाईहरु संग यो ज्ञान साझा गर्न चाहन्छु। मेरो लेखमा म भर पर्नेछु पाठ्यपुस्तक नर्डिक वेबसाइटबाट शुरुवातकर्ताहरूको लागि। त्यसैले सुरु गरौं।

किन सबै कुरा यति गाह्रो छ?

मेरो विचारमा, यो तुरुन्तै स्पष्ट थियो कि स्मार्टफोन मार्फत उपकरणहरू प्रबन्ध गर्नु एक धेरै आशाजनक र लामो समयसम्म चल्ने विषय हो। तसर्थ, तिनीहरूले यसलाई तुरुन्त र अधिकतम रूपमा संरचना गर्ने निर्णय गरे। त्यसोभए विभिन्न ग्याजेटहरूका निर्माताहरू तिनीहरूको आफ्नै प्रोटोकलहरूसँग आउँदैनन्, जुन त्यसपछि असंगत हुनेछ। त्यसैले कठिनाई। पहिले नै पहिलो चरणमा, तिनीहरूले BLE प्रोटोकलमा सम्भव सबै निचोड गर्ने प्रयास गरे। र यसले केही फरक पार्दैन कि यो पछि उपयोगी हुनेछ वा छैन। थप रूपमा, तिनीहरूले भविष्यको लागि उपकरणहरूको सूची विस्तार गर्ने सम्भावनाको लागि प्रदान गरे।

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-बिट UUIDs को परिचय को लागी निर्णय गर्यो। यसले व्यक्तिगत रूपमा मलाई लाइसेन्स नभएको 433 मेगाहर्ट्ज ब्यान्डको सम्झना दिलाउँछ, जुन रेडियो च्यानलबाट सबै प्रकारका कुलिबिनहरूलाई दिइएको थियो। हाम्रो अवस्थामा, सेवा र विशेषताहरूको 128-बिट पहिचानकर्ता खेती गरिएको थियो। यसको मतलब हामी हाम्रा सेवाहरू र उपकरणहरूको लागि, लगभग कुनै पनि 128-बिट मान प्रयोग गर्न सक्छौं। सबै उस्तै, उही UUID को साथ आउने सम्भावना शून्य हुन्छ।

वास्तवमा, छोटो 16-बिट UUID सँग 128-बिट मानमा विस्तार हुन्छ। विनिर्देशमा, यो विस्तारलाई ब्लुटुथ बेस UUID भनिन्छ र यसको मान 00000000-0000-1000-8000-00805F9B34FB छ। यदि, उदाहरणका लागि, 16-बिट विशेषता UUID मा 0x1234 मान छ भने, त्यसपछि बराबरको 128-bit UUID मा 00001234-0000-1000-8000-00805F9B34FB मान हुनेछ। र पनि सम्बन्धित सूत्र दिइएको छ:

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

मलाई थाहा छैन यो जादुई नम्बर कहाँबाट आयो। यदि पाठकहरू मध्ये कसैलाई थाहा छ भने, उनीहरूलाई टिप्पणीहरूमा लेख्न दिनुहोस् (सिनोपटेक उपनाम भएको प्रयोगकर्ताले पहिले नै यो गरिसकेको छ। टिप्पणीहरू हेर्नुहोस्)। 128-बिट UUIDs को साथ आउन को लागी, सिद्धान्त मा तपाइँ एक विशेष प्रयोग गर्न सक्नुहुन्छ जेनेरेटरजसले तिम्रो लागि गर्नेछ।

ATTy GATTy...

वास्तवमा, त्यसपछि रमाईलो सुरु हुन्छ। मलाई सम्झाउन दिनुहोस् कि ATT ग्राहक-सर्भर सम्बन्धमा आधारित छ। अब हामी सर्भर उपकरण हेर्दैछौं। यसले जानकारी समावेश गर्दछ जस्तै सेन्सर मान, लाइट स्विच स्थिति, स्थान डेटा, आदि। अब जब सबै "हाम्रो परेडमा सहभागीहरू" नम्बर गरिएका छन्, हामीले तिनीहरूलाई कुनै न कुनै रूपमा यन्त्रको मेमोरीमा राख्नु पर्छ। यो गर्नको लागि, हामीले तिनीहरूलाई एट्रिब्यूट टेबल भनिने तालिकामा राख्छौं। यो राम्रोसँग सम्झनुहोस्। यो BLE को धेरै हृदय हो। यो हामी थप विचार गर्नेछौं। अब हामी प्रत्येक लाइनलाई एट्रिब्युट कल गर्नेछौं। यो तालिका स्ट्याक मा गहिरो स्थित छ र, एक नियम को रूप मा, हामी यसमा प्रत्यक्ष पहुँच छैन। हामी यसलाई प्रारम्भ गर्छौं र यसलाई पहुँच गर्छौं, तर भित्र के हुन्छ हामीबाट सात सिलहरू पछाडि लुकेको छ।

स्पेसिफिकेशनबाट तस्विरलाई हेरौं, तर त्यस अघि, म तुरुन्तै सर्तहरूमा, अर्थात् वर्णनकर्ताहरूमा बारम्बार भ्रममा ध्यान आकर्षित गर्न चाहन्छु। वर्णनकर्ताको भूमिका विशेषताको विवरणलाई पूरक बनाउनु हो। जब यो यसको क्षमता विस्तार गर्न आवश्यक छ, तब वर्णनकर्ताहरू प्रयोग गरिन्छ। तिनीहरू पनि विशेषताहरू हुन्, र सेवाहरू र विशेषताहरू जस्तै, तिनीहरू विशेषता तालिकामा अवस्थित छन्। हामी तिनीहरूलाई लेखको दोस्रो भागमा विस्तृत रूपमा जाँच गर्नेछौं। यद्यपि, कहिलेकाहीं वर्णनकर्ताहरूले विशेषता तालिकामा पङ्क्ति नम्बरलाई बुझाउँछन्। यो मनमा राख्नुपर्छ। भ्रमबाट बच्नको लागि, हामी यी उद्देश्यहरूको लागि "विशेषता सूचक" शब्द प्रयोग गर्नेछौं।


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

यो सब कसरी बुझ्ने ? विशेषता सूचक हो, अपेक्षाकृत बोल्दै, हाम्रो तालिकामा यसको संख्या।
यसले क्लाइन्टलाई पढ्न वा लेख्न अनुरोधहरूमा एक विशेषता सन्दर्भ गर्न अनुमति दिन्छ। हामी हाम्रो रेखाहरू (विशेषताहरू) 0x0001 देखि 0xFFFF सम्म नम्बर गर्न सक्छौं। बुककेससँगको हाम्रो सम्बन्धमा, यो कागजको सूचीमा रहेको कार्ड नम्बर हो। त्यसैगरी, पुस्तकालयको क्याटलगमा जस्तै, संख्याको बढ्दो क्रममा कार्डहरू मिलाइन्छ। प्रत्येक पछिको रेखाको संख्या अघिल्लो एक भन्दा ठूलो हुनुपर्छ। पुस्तकालयमा जस्तै, कहिलेकाहीँ केही कार्डहरू हराउँछन्, त्यसैले हामीसँग, लाइन नम्बरिङमा खाली ठाउँहरू हुन सक्छ। यो अनुमति छ। मुख्य कुरा यो हो कि तिनीहरू क्रमिक रूपमा जान्छन्।

विशेषता प्रकारले विशेषताले के प्रतिनिधित्व गर्छ भनेर निर्धारण गर्छ। सी भाषा संग समानता द्वारा,
जहाँ बुलियन, संख्यात्मक चर र स्ट्रिङहरू छन्, त्यसैले यो यहाँ छ। विशेषता प्रकार द्वारा हामी पहिचान गर्छौं
हामी केसँग व्यवहार गर्दैछौं र हामी कसरी यस विशेषतासँग काम गर्न जारी राख्न सक्छौं। तल हामी केही विशिष्ट प्रकारका विशेषताहरू हेर्नेछौं। उदाहरणका लागि, "सेवा घोषणा" (0x2800), "विशेषता घोषणा" (0x2803), "वर्णनकर्ता घोषणा" (0x2902)।

एक विशेषता को मूल्य यसको वास्तविक अर्थ हो, tautology माफ गर्नुहोस्। यदि विशेषता प्रकार एक स्ट्रिङ हो, तब विशेषता मान हुन सक्छ, उदाहरणका लागि, नारा "हेलो विश्व !!!"। यदि विशेषता प्रकार "सेवा घोषणा" हो भने, त्यसको मान सेवा नै हो। र कहिलेकाहीँ यो अन्य विशेषताहरू र तिनीहरूका गुणहरू कहाँ फेला पार्ने बारे जानकारी हो।

विशेषता अनुमतिहरूले सर्भरलाई पढ्न वा लेख्न पहुँच अनुमति दिइएको छ भनेर बुझ्न अनुमति दिन्छ।
ध्यान दिनुहोस् कि यी अनुमतिहरू विशेषता मानमा मात्र लागू हुन्छन्, र सूचक, प्रकार, वा अनुमति फिल्डमा होइन। ती। यदि विशेषता रेकर्डिङलाई अनुमति दिइएको छ भने, हामी परिवर्तन गर्न सक्छौं, उदाहरणका लागि, रेखा "हेलो वर्ल्ड !!!" "सुप्रभात" लाईनमा। तर हामी नयाँ लाइन लेख्न निषेध गर्न वा विशेषता प्रकार परिवर्तन गर्न र लाइनलाई "सेवा घोषणा" को रूपमा तोक्न सक्दैनौं। जब ग्राहकले सर्भरलाई सम्पर्क गर्दछ, ग्राहकले यसको विशेषताहरू अनुरोध गर्दछ। यसले ग्राहकलाई सर्भरले के प्रदान गर्न सक्छ भनेर जान्न अनुमति दिन्छ। यद्यपि यो मानहरू पढ्न र लेख्न आवश्यक छैन।

यो कस्तो देखिन्छ?

GATT को अवधारणा भनेको एट्रिब्युट तालिकामा एट्रिब्युटहरूलाई धेरै विशिष्ट र तार्किक क्रममा समूहबद्ध गर्नु हो। तलको मुटुको दर प्रोफाइललाई नजिकबाट हेरौं। यस तालिकाको सबैभन्दा बायाँ स्तम्भ वैकल्पिक छ। यसले हामीलाई यो रेखा (विशेषता) के हो भनेर वर्णन गर्दछ। अन्य सबै स्तम्भहरू हामीलाई पहिले नै परिचित छन्।

प्रत्येक समूहको शीर्षमा हामीसँग सधैं सेवा घोषणा विशेषता हुन्छ। यसको प्रकार सधैं 0x2800 हुन्छ, र सूचकले तालिकामा पहिले नै कति विशेषताहरू छन् भन्ने कुरामा निर्भर गर्दछ। कुनै प्रमाणीकरण वा प्राधिकरण बिना, यसको अनुमतिहरू सधैं पढ्ने मात्र हुन्। हामी केहि पछि यी अवधारणाहरु को बारे मा कुरा गर्नेछौं। मान अर्को UUID हो जसले सेवा के हो भनेर पहिचान गर्छ। तालिकामा, मान 0x180D हो, जसलाई ब्लुटुथ SIG ले हृदय दर सेवाको रूपमा परिभाषित गरेको छ।

सेवाको घोषणा पछि, विशेषताको घोषणा आउँछ। यो एक सेवा घोषणा को रूप मा समान छ। यसको UUID सधैं 0x2803 हुन्छ, र यसको अनुमतिहरू सधैं कुनै प्रमाणीकरण वा प्राधिकरण बिना पढ्न मात्र हुन्छन्। एट्रिब्युट मान फिल्डमा हेरौं, जसमा केही डेटा समावेश छ। यसले सधैं एक सूचक, एक UUID, र गुणहरूको सेट समावेश गर्दछ। यी तीन तत्वहरूले विशेषता मानको पछिल्लो घोषणाको वर्णन गर्दछ। सूचकले स्वाभाविक रूपमा विशेषता तालिकामा विशेषता मान घोषणाको स्थानलाई जनाउँछ। UUID ले हामी कस्तो प्रकारको जानकारी वा मूल्य अपेक्षा गर्न सक्छौं भनेर वर्णन गर्दछ। उदाहरण को लागी, तापमान मान, प्रकाश स्विच को स्थिति, वा केहि अन्य मनमाना मान। र अन्तमा गुणहरू, जसले विशेषता मानसँग कसरी अन्तरक्रिया गर्न सकिन्छ भनेर वर्णन गर्दछ।

अर्को खाडल यहाँ हामीलाई पर्खिरहेको छ। यो विशेषता अनुमति र विशेषता गुण संग सम्बन्धित छ। स्पेसिफिकेशनबाट बिट फिल्ड गुणहरूको तस्वीर हेरौं।

तपाईले देख्न सक्नुहुने रूपमा, त्यहाँ क्षेत्रहरू पनि छन् जसले पढ्न र लेख्ने क्षमताहरू प्रदान गर्दछ। तपाईले सोचिरहनुभएको हुन सक्छ किन हामीले विशेषता र सम्पत्तिको लागि पढ्न/लेख्ने अनुमतिहरू राखेका छौं
विशेषता मूल्यको लागि पढ्नुहोस्/लेख्नुहोस्? के तिनीहरू सधैं उस्तै हुनु हुँदैन? तथ्य यो हो कि विशेषता मानका लागि गुणहरू वास्तवमा GATT र अनुप्रयोग तहहरूमा प्रयोग गरिएका ग्राहकका लागि सिफारिसहरू मात्र हुन्। यी केवल विशेषता घोषणा विशेषताबाट ग्राहकले के आशा गर्न सक्छ भन्ने बारे संकेतहरू हुन्। यसलाई थप विवरणमा हेरौं। एट्रिब्युटसँग कस्ता प्रकारका अनुमतिहरू छन्?

1. पहुँच अनुमतिहरू:
     - पढाइ
     - रेकर्ड
     - पढ र लेख
२. प्रमाणीकरण अनुमति:
     - प्रमाणीकरण आवश्यक छ
     - कुनै प्रमाणीकरण आवश्यक छैन
3. प्राधिकरण अनुमति:
     - प्राधिकरण आवश्यक छ
     - कुनै प्राधिकरण आवश्यक छैन

विशेषता रिजोलुसन र विशेषता गुणहरू बीचको मुख्य भिन्नता यो हो कि पहिले सर्भरहरूमा लागू हुन्छ, र पछिल्लो ग्राहकहरूमा। सर्भरलाई विशेषता मान पढ्न अनुमति दिइन्छ, तर प्रमाणीकरण वा प्राधिकरण चाहिन्छ। त्यसकारण, जब ग्राहकले विशेषताको गुणहरू अनुरोध गर्दछ, हामी प्राप्त गर्नेछौं कि पठन अनुमति छ। तर जब हामी पढ्ने प्रयास गर्छौं, हामी त्रुटि पाउँछौं। त्यसकारण, हामी सुरक्षित रूपमा सम्पत्तिहरू भन्दा अनुमतिहरूको प्राथमिकताको बारेमा कुरा गर्न सक्छौं। ग्राहक पक्षमा, हामीले एट्रिब्युटमा के अनुमतिहरू छन् भन्ने ज्ञान प्राप्त गर्न सक्दैनौं।

वर्णनकर्ता

हाम्रो टेबलमा फर्कौं। विशेषताको मान घोषणा गरेपछि, निम्न विशेषता घोषणाहरू सम्भव छन्:
1. विशेषताहरूको नयाँ घोषणा (सेवामा धेरै विशेषताहरू हुन सक्छन्)
2. नयाँ सेवा घोषणा (तालिकामा ती मध्ये धेरै हुन सक्छन्)
3. ह्यान्डल घोषणा गर्दै

हृदय दर मापन विशेषता को मामला मा, हाम्रो तालिका मा, विशेषता मान को घोषणा वर्णनकर्ता को घोषणा संग छ। एक वर्णनकर्ता एक विशेषता को बारे मा अतिरिक्त जानकारी संग एक विशेषता हो। त्यहाँ धेरै प्रकारका वर्णनकर्ताहरू छन्। हामी यस लेखको दोस्रो भागमा विस्तृत रूपमा तिनीहरूको बारेमा कुरा गर्नेछौं। अहिलेको लागि, हामी केवल ग्राहक विशेषता कन्फिगरेसन वर्णनकर्ता (CCCD) मा छुनेछौं। यसमा ०x२९०२ बराबरको UUID छ। यो वर्णनकर्ता प्रयोग गरेर, ग्राहकसँग सर्भरमा संकेत वा सूचना सक्षम गर्ने क्षमता छ। तिनीहरू बीचको भिन्नता सानो छ, तर अझै पनि त्यहाँ छ। सूचनालाई ग्राहकबाट प्राप्तिको पुष्टिकरण आवश्यक पर्दैन। संकेतको लागि यो आवश्यक छ, यद्यपि यो GATT स्तरमा हुन्छ, अनुप्रयोग स्तरमा पुग्दैन। किन यस्तो, तपाईं सोध्नुहुन्छ? काश, मलाई यो थाहा छैन। मलाई भन्न दिनुहोस् कि नॉर्डिक विशेषज्ञहरूले सूचनाहरू प्रयोग गर्न सिफारिस गर्छन्। यसबाहेक, प्याकेजको अखण्डता जाँच गर्दै (CRC प्रयोग गरेर) दुवै अवस्थामा हुन्छ।

निष्कर्षमा

लेखको अन्त्यमा म यही भन्न चाहन्छु। अन्तिम तालिका अलि भ्रमित छ। यद्यपि, मैले यसलाई रोजें किनभने यो दिइएको छ लेख, जसमा म भर पर्छु । मेरो लेखको दोस्रो भागमा, म ब्लुटुथ 4.0 स्पेसिफिकेशनमा गहिरिएर जान चाहन्छु। थप सही रेखाचित्र र रेखाचित्रहरू हामीलाई त्यहाँ पर्खिरहेका छन्। तेस्रो भागमा, म एउटा ग्याजेटबाट Wireshark कार्यक्रम प्रयोग गरेर प्राप्त लगलाई पार्स गर्न चाहन्छु र हामीले अध्ययन गरिरहेका सबै सिद्धान्तहरू "लाइभ" हेर्न चाहन्छु।

कम्पनीको समूहका कर्मचारी "सिजर उपग्रह"
Pecherskikh व्लादिमीर

स्रोत: www.habr.com