माइक्रोस्कोप के तहत BLE (ATTы GATTы...)

माइक्रोस्कोप के तहत BLE (ATTы GATTы...)

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

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

सब कुछ इतना कठिन क्यों है?

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

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

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

जिस किसी ने भी उपकरण विकसित किया है वह जानता है कि कई परियोजनाओं में कोड के समान टुकड़े होते हैं। तथ्य यह है कि कई उपकरणों में समान कार्यक्षमता होती है। उदाहरण के लिए, यदि उपकरण बैटरी द्वारा संचालित होते हैं, तो चार्जिंग और उनके स्तर की निगरानी की समस्या समान होगी। सेंसर के लिए भी यही बात लागू होती है। दरअसल, प्रोग्रामिंग के लिए एक ऑब्जेक्ट-ओरिएंटेड दृष्टिकोण "ऐसी वस्तुएं बनाने की क्षमता प्रदान करता है जो गुणों और व्यवहारों को एक स्व-निहित संघ में जोड़ती हैं जिन्हें फिर से उपयोग किया जा सकता है". मेरी राय में, BLE ने एक समान दृष्टिकोण का प्रयास किया। प्रोफाइल ब्लूटूथ स्पेशल इंटरेस्ट ग्रुप (SIG) द्वारा विकसित किए गए थे। समान प्रोफ़ाइल वाले विभिन्न निर्माताओं के उपकरणों को बिना किसी कठिनाई के एक-दूसरे के साथ काम करना चाहिए। प्रोफ़ाइल, बदले में, वर्णनकर्ताओं द्वारा पूरक सेवाओं और विशेषताओं की सेवाओं से युक्त होती है। सामान्य तौर पर यह इस तरह दिख सकता है:

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

1. हृदय गति सेवा में तीन विशेषताएँ शामिल हैं (0x180D):
    ए) अनिवार्य हृदय गति विशेषता (0x2A37)
    बी) वैकल्पिक बॉडी सेंसर स्थिति विशेषता (0x2A38)
    ग) हृदय गति नियंत्रण बिंदु की सशर्त विशेषताएं (0x2A39)
2. बैटरी रखरखाव सेवा (0x180F):
    ए) अनिवार्य बैटरी चार्ज स्तर विशेषता (0x2A19)

यूयूआईडी

प्रोफ़ाइल तत्वों (सेवाओं, विशेषताओं और विवरणकों) तक विशिष्ट रूप से पहुंचने के लिए, हमें किसी भी तरह उन सभी को क्रमांकित करने की आवश्यकता है। इस उद्देश्य के लिए, यूनिवर्सली यूनिक आईडी (यूयूआईडी) या यूनिवर्सली यूनिक आइडेंटिफ़ायर जैसी अवधारणा पेश की गई है। यूयूआईडी को प्रत्येक पंक्ति के कोष्ठक में दर्शाया गया है। और यहाँ एक ख़ासियत है. यूयूआईडी के लिए, हमने 16 और 128 बिट लंबाई के कोड का उपयोग करने का निर्णय लिया। तुम क्यों पूछ रहे हो? बीएलई प्रोटोकॉल में, सब कुछ ऊर्जा संरक्षण के बारे में है। इसलिए, 16 बिट्स का आयाम काफी उचित है। यह संभावना नहीं है कि निकट भविष्य में 65 हजार से अधिक का निर्माण किया जाएगा। अद्वितीय सेवाएँ और विशेषताएँ। फिलहाल, जो कुछ भी वे कर सकते थे उसे पहले ही गिना जा चुका था (याद रखें कि यह कहां से आया - "उसने आपको भी गिना" :-)) क्रमांकित तत्व प्रोफाइल, सेवाओं की, характеристик и वर्णनकर्ता आप लिंक देख सकते हैं.

हालाँकि, मुझे लगता है कि हर किसी को इंटरनेट पर आईपी पते के 4 बाइट्स के साथ कहानी याद है। पहले तो हमने सोचा कि यह पर्याप्त है, लेकिन अब हम अभी भी 6-बाइट पते पर स्विच नहीं कर सकते हैं। इस गलती को न दोहराने और DIYers के चंचल हाथों को खुली छूट देने के लिए, SIG ने तुरंत 128-बिट UUIDs पेश करने का निर्णय लिया। यह व्यक्तिगत रूप से मुझे बिना लाइसेंस वाले 433 मेगाहर्ट्ज बैंड की याद दिलाता है, जो रेडियो चैनल से सभी प्रकार के कुलिबिन्स को दिया गया था। हमारे मामले में, सेवाओं और विशेषताओं का 128-बिट पहचानकर्ता तैयार किया गया था। इसका मतलब यह है कि हम, अपनी सेवाओं और उपकरणों के लिए, लगभग किसी भी 128-बिट मान का उपयोग कर सकते हैं। फिर भी, समान यूयूआईडी के आने की संभावना शून्य हो जाती है।

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

                                128_बिट_वैल्यू = 16_बिट_वैल्यू * 2^96 + ब्लूटूथ_बेस_यूयूआईडी

मुझे नहीं पता कि यह जादुई नंबर कहां से आया। यदि कोई पाठक जानता है, तो उन्हें टिप्पणियों में लिखने दें (सिनोपटेक उपनाम वाला एक उपयोगकर्ता पहले ही ऐसा कर चुका है। टिप्पणियाँ देखें)। जहां तक ​​128-बिट यूयूआईडी के साथ आने की बात है, सिद्धांत रूप में आप एक विशेष का उपयोग कर सकते हैं जनकयह आपके लिए कौन करेगा.

एटी गैटी...

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

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


तो एक विशेषता एक अलग मान है जिसके साथ निम्नलिखित गुण जुड़े हुए हैं:
1. विशेषता हैंडल विशेषता के अनुरूप तालिका सूचकांक है
2. विशेषता प्रकार एक यूयूआईडी है जो इसके प्रकार का वर्णन करता है
3. विशेषता मान विशेषता सूचक द्वारा अनुक्रमित डेटा है
4. विशेषता अनुमतियाँ एक विशेषता का हिस्सा हैं, अनुमतियाँ, जिन्हें विशेषता प्रोटोकॉल का उपयोग करके पढ़ा या लिखा नहीं जा सकता है

यह सब कैसे समझें? विशेषता सूचक, अपेक्षाकृत रूप से, हमारी तालिका में इसकी संख्या है।
यह क्लाइंट को पढ़ने या लिखने के अनुरोधों में किसी विशेषता को संदर्भित करने की अनुमति देता है। हम अपनी पंक्तियों (विशेषताओं) को 0x0001 से 0xFFFF तक क्रमांकित कर सकते हैं। बुककेस के साथ हमारे सहयोग में, यह पेपर कैटलॉग में कार्ड नंबर है। उसी प्रकार, जैसे पुस्तकालय सूची में, कार्डों को संख्या के बढ़ते क्रम में व्यवस्थित किया जाता है। प्रत्येक अगली पंक्ति की संख्या पिछली पंक्ति से अधिक होनी चाहिए। जैसे लाइब्रेरी में, कभी-कभी कुछ कार्ड खो जाते हैं, वैसे ही हमारे साथ, लाइन नंबरिंग में अंतराल हो सकता है। इसकी अनुमति है. मुख्य बात यह है कि वे उत्तरोत्तर आगे बढ़ते रहें।

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

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

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

यह कैसा दिखता है

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

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

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

यहां एक और ख़तरा हमारा इंतज़ार कर रहा है। यह विशेषता अनुमतियों और विशिष्ट गुणों से जुड़ा है। आइए विनिर्देश से बिट फ़ील्ड गुणों की तस्वीर देखें।

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

1. प्रवेश अनुमतियाँ:
     - अध्ययन
     - अभिलेख
     - पढ़ें और लिखें
2. प्रमाणीकरण अनुमति:
     - प्रमाणित करना
     - प्रमाणीकरण की आवश्यकता नहीं है
3. प्राधिकरण अनुमति:
     - अनुमति की आवश्यकता है
     - किसी प्राधिकरण की आवश्यकता नहीं

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

डिस्क्रिप्टर

आइए अपनी टेबल पर वापस आएं। किसी विशेषता का मान घोषित करने के बाद, निम्नलिखित विशेषता घोषणाएँ संभव हैं:
1. विशेषताओं की नई घोषणा (एक सेवा में कई विशेषताएं हो सकती हैं)
2. नई सेवा घोषणा (तालिका में उनमें से कई हो सकते हैं)
3. एक हैंडल घोषित करना

हृदय गति माप विशेषता के मामले में, हमारी तालिका में, विशेषता मूल्य की घोषणा वर्णनकर्ता की घोषणा के साथ होती है। एक डिस्क्रिप्टर एक विशेषता है जिसमें किसी विशेषता के बारे में अतिरिक्त जानकारी होती है। वर्णनकर्ता कई प्रकार के होते हैं। इनके बारे में हम इस लेख के दूसरे भाग में विस्तार से बात करेंगे. अभी के लिए, हम केवल क्लाइंट कैरेक्टरिस्टिक कॉन्फ़िगरेशन डिस्क्रिप्टर (सीसीसीडी) पर ही बात करेंगे। इसका UUID 0x2902 के बराबर है। इस डिस्क्रिप्टर का उपयोग करके, क्लाइंट के पास सर्वर पर संकेत या अधिसूचना सक्षम करने की क्षमता होती है। उनके बीच का अंतर छोटा है, लेकिन फिर भी है। अधिसूचना के लिए ग्राहक से प्राप्ति की पुष्टि की आवश्यकता नहीं है। संकेत के लिए इसकी आवश्यकता होती है, हालाँकि यह GATT स्तर पर होता है, अनुप्रयोग स्तर तक नहीं पहुँचता। आप पूछते हैं, ऐसा क्यों? अफ़सोस, मैं यह नहीं जानता। मैं बस यह कहना चाहता हूं कि नॉर्डिक विशेषज्ञ सूचनाओं का उपयोग करने की सलाह देते हैं। इसके अलावा, पैकेज की अखंडता की जाँच (सीआरसी का उपयोग करके) दोनों मामलों में होती है।

निष्कर्ष

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

कंपनियों के समूह का कर्मचारी "सीज़र सैटेलाइट"
पेचेर्सिख व्लादिमीर

स्रोत: www.habr.com