स्ट्रीमिंग वीडियो BLE या क्लासिक ब्लूटूथ 4.0 का उपयोग कर?


10

BLE के पास केवल 100Kbps का डेटा पेलोड है इसलिए मैं सोच रहा था कि क्या ब्लूटूथ लो एनर्जी का उपयोग करके लाइव वीडियो स्ट्रीम करना संभव है?

क्लासिक ब्लूटूथ 4.0 में 2Mbps का डेटा पेलोड है जो वीडियो को प्रसारित करना आसान बनाता है लेकिन मैं कुल बिजली के बारे में अधिक चिंतित हूं इसलिए BLE को लागू करना चाहता हूं। क्या मुझे वीडियो स्ट्रीम करने के लिए BLE का उपयोग करने पर वही परिणाम मिल सकता है?


1
यह सवाल 2M (bps) PHY के साथ BLE नियंत्रकों के लिए ब्लूटूथ 5 के लिए पुराना है।
ZX9

जवाबों:


12

मध्यम बैंडविड्थ स्ट्रीमिंग (ऑडियो या वीडियो) के लिए बीएलई बहुत अनुपयुक्त है, क्योंकि यह कुछ और छोटे डेटा पैकेटों के हस्तांतरण के लिए डिज़ाइन किया गया है, जिनके बीच में बहुत से सोने का समय है। यही कारण है कि इसे 'कम ऊर्जा' कहा जाता है और 'कम शक्ति' नहीं - यह छोटे पैकेटों के लिए प्रति बिट पिकोजॉल्स की मात्रा को कम करता है, प्रतिस्पर्धा मानकों के संबंध में। अन्य मानकों में अधिक शक्ति का उपयोग किया जाता है, क्योंकि उनके पास कम कुशल रेडियो नहीं हैं, लेकिन क्योंकि कम से कम रिसीवर लगातार संचालित होता है, जबकि रेडियो ट्रैफ़िक में तुलनात्मक रूप से बहुत बड़ी खामियां हैं, और क्योंकि स्थानांतरित बिट्स का एक महत्वपूर्ण हिस्सा पेलोड नहीं है, बल्कि ओवरहेड है - प्रोटोकॉल हेडर, चेकसम, यहां तक ​​कि सिर्फ खाली जगह। BLE इनमें से अधिकांश अनावश्यक शक्ति को हटा देता है। लेकिन आप बुरा मानें, यह नहीं है ' t जादुई रूप से सक्रिय होने पर ट्रांससीवर्स के बिजली उपयोग में सुधार होता है। और वीडियो ट्रांसफर करते समय, ट्रांसीवर्स लगातार संचालित होते हैं। आप BLE का सबसे बड़ा लाभ खो देते हैं।

इस डिजाइन पसंद थोड़ा के रूप में अनिवार्य रूप से करने के लिए भूमि के ऊपर कम कर देता है के रूप में आप की तरह, लेकिन यह भी यह बनाता है यह नहीं है कि किसी भी स्ट्रीमिंग की सुविधा में निर्मित देशी रूप पैकेट पुनर्संयोजन, देरी पावती और अतुल्यकालिक स्थानान्तरण की तरह। आपके पास वास्तव में कुछ भी निर्मित नहीं है, BLE उतना ही कच्चा है जितना कि आप वायरलेस इंटरफ़ेस से मिल सकते हैं, शायद nRF24 और TI CC2x00 को रोक सकते हैं। नतीजतन, आपको सॉफ्टवेयर में (या तो माइक्रोकंट्रोलर पर या अपने उपयोगकर्ता डिवाइस पर) यह करने की आवश्यकता होगी और यह अविश्वसनीय रूप से बहुत अधिक ऊर्जा का उपयोग करता है यदि आप इसके लिए एक उद्देश्य-निर्मित प्रोटोकॉल का उपयोग करते हैं जैसे कि ब्लूटूथ 3.0 EDR या वाई - फाई।

यह कुछ हद तक प्रतिसादात्मक धारणा की ओर जाता है जो एक बार जब आप ऑडियो-टाइप डेटा दरों और इसके बाद के संस्करण में प्राप्त करना शुरू करते हैं, तो ब्लूटूथ लो एनर्जी हो जाती है, आपके कार्यान्वयन के आधार पर, ब्लूटूथ 3.0 की तुलना में लगभग 2x कम कुशल, और जब आप मेगाबिट रेंज में आते हैं तो यह काफी हद तक होता है वाईफाई से कम कुशल। यही कारण है कि वाईफाई मौजूद है - और यकीनन वायरलेस रेंज, हालांकि आजकल दोनों मानकों के लिए ट्रांसीवर बहुत अधिक समकक्ष हैं। WiFi में वैकल्पिक MIMO और विविधता है।

तो जब भी ध्यान में नहीं लिया जा रहा है - कम से कम वीडियो के लिए - बहुत प्रतिबंधक बैंडविड्थ और सीमा सीमा जो ब्लूटूथ लगाता है, तो आप इस विधि के साथ कम बिजली वीडियो हस्तांतरण के लक्ष्य को प्राप्त नहीं कर सकते हैं।


8

ठीक है, 100kbps के साथ, आप कम गुणवत्ता वाले वीडियो को एक डाक टिकट के आकार में स्ट्रीम करने में सक्षम हो सकते हैं :-)

बिना किसी सटीकता के, मैं कल्पना करूँगा कि आप चाहते हैं HD (पूर्ण HD भी नहीं) @ 30fps H264 में, औसत गति (कारक 2) के साथ, अनुमानित अनुमानित अनुमान हो सकता है:

(1280px * 720px) * 30fps * 2 * 0.07 ~ = 3800kbps

तो आपको इसे एक कारक 38 (कम से कम!) से कम करना होगा।

कहते हैं कि आप ~ 320x200 @ 15fps के लिए व्यवस्थित होते हैं, आप अभी भी थोड़ा ऊपर हैं ( सैद्धांतिक बैंडविड्थ, उम्मीद कम)।


1
एक औसत गति कारक क्या है? और 0.07 मूल्य क्या है?
m.Alin

@ m.Alin शायद .07 ऑडियो है?
ZX9

0

मेरा सभी परीक्षण 2000 से अधिक ओकटेट्स / सेकंड से कम पर समाप्त हुआ

आवश्यक शर्तें:

  • Android: Nexus गैलक्सी टैब 7 Android 6.0.1 (GATT क्लाइंट)
  • लिनक्स: R-PI + BCM20702A0 (GATT सर्वर)
  • NUCLEO-F411RE: BlueNRG (GATT सर्वर)

सभी परीक्षण जो मैंने Android <-> Linux & Bunget, Android <-> Linux & Bleno, Android <-> ST-Micro Nucleus + blueNRG के बीच किए हैं। Linux और NUCLEO GATT सर्वर चला रहे हैं। Android मुख्य रूप से GATT क्लाइंट चला रहा है।

  • Android-> GATT सर्वर नोटिफ़िकेशन / WRITE NO RESPONSE को अक्सर 13 ms से अधिक नहीं भेजा जा सकता है। 13ms से अधिक का पैकेट खो गया।

  • सर्वर-> एंड्रॉयड नोटिफिकेशन / राइट नॉट रिस्पॉन्स 15 एमएस से अधिक बार नहीं भेजा जा सकता है

  • दोनों पक्षों, आरक्षक संकेतक, जैसा कि अक्सर 15..20 एमएस से अधिक नहीं किया जा सकता है।

यह 1000ms / 13ms तक जाता है -> 77 बार / 20 बाइट्स का दूसरा = 1500 ओकटेट्स / सेकंड।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.