रीडिंग पेन पैकेट लॉस कंसीलमेंट (PLC) और ऑडियो रोबस्टनेस

दर्शक: यह लेख उन हार्डवेयर खरीदारों और ऑडियो फर्मवेयर इंजीनियरों के लिए लिखा गया है जो शोर कक्षा और घरेलू वातावरण के लिए रीडिंग पेन लाइन का मूल्यांकन कर रहे हैं। यह मान लेता है कि आप पहले से ही ब्लूटूथ और वाई-फाई कोएक्सिस्टेंस को उच्च स्तर पर समझते हैं और अब पैकेट लॉस के तहत पीएलसी व्यवहार के लिए एक ठोस विशिष्टता की आवश्यकता है।

ऑडियो पैकेट्स ऑडियो फ्रेम्स के समान नहीं हैं। एक रीडिंग पेन डिकोडर संपीड़ित बिटस्ट्रीम से पीसीएम फ्रेम्स को निकालता है, लेकिन ट्रांसपोर्ट लेयर उन फ्रेम्स को पैकेट्स के अंदर वितरित करती है जिन्हें खोया, पुनः क्रमित, डुप्लिकेट या विलंबित किया जा सकता है। जब कोई पैकेट गायब हो जाता है — जो सामान्य बीएलई और वाई-फाई कोएक्सिस्टेंस के तहत हर कुछ मिनट में हर प्रोडक्शन रीडिंग पेन पर होता है — तो डिकोडर के पास अगले अपेक्षित सैंपल के आने से पहले एक प्रतिस्थापन गढ़ने के लिए कुछ सौ माइक्रोसेकंड होते हैं। उस गढ़ने की प्रक्रिया को पैकेट लॉस कंसीलमेंट (पीएलसी) कहा जाता है, और गढ़ने की गुणवत्ता तय करती है कि बच्चे को एक साफ शब्द सुनाई देता है या एक गड़बड़ जो उन्हें फिर से ओआईडी कोड टैप करने पर मजबूर करती है। यह लेख बताता है कि 11 प्रोडक्शन मॉडलों (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6) में पीएलसी कैसे लागू किया जाता है, इसे कैसे मापा जाता है, और आरएफक्यू में पीएलसी मजबूती कैसे निर्दिष्ट करें ताकि आपको स्कूल-डिस्ट्रिक्ट पायलट के दौरान इसे डीबग न करना पड़े।

1. पीएलसी केवल वीओआईपी में ही नहीं, रीडिंग पेन में क्यों मायने रखता है

पीएलसी का आविष्कार वॉइस ओवर आईपी के लिए हुआ था, जहाँ प्रबंधित नेटवर्क पर सामान्य पैकेट हानि दर 0.5–2 प्रतिशत होती है और श्रोता एक वयस्क होता है जो छूटी हुई ध्वनि को मानसिक रूप से भर सकता है। रीडिंग पेन का परिवहन वास्तविकता बहुत कठोर है। पेन 2.4 गीगाहर्ट्ज़ वाई-फाई कक्षा में 30 अन्य छात्रों के साथ वीडियो स्ट्रीमिंग करते हुए बैठता है; पेन मूल ऐप के साथ बीएलई 5.0 पर भी जोड़ा गया है; पेन एक साथ क्लाउड को उपयोग टेलीमेट्री भेजने के लिए अपना स्वयं का वाई-फाई स्कैन भी चला सकता है। स्थानीय ऑडियो पथ पर पैकेट हानि प्रोफ़ाइल 0.5–2 प्रतिशत नहीं होती — यह बर्स्टी होती है, जब वाई-फाई रेडियो एंटीना पर हावी होता है और बीएलई लिंक लेयर पुनः प्रसारित करती है तो कभी-कभी 30–80 एमएस के अंतराल आते हैं।

वीओआईपी पीएलसी एल्गोरिद्म स्थिर, सुव्यवस्थित हानि के लिए डिज़ाइन किए गए थे। रीडिंग पेन पीएलसी को बर्स्ट हानि, जिटर स्पाइक्स और रेडियो सबसिस्टम द्वारा पृष्ठभूमि स्कैन करने पर कभी-कभी 200 एमएस के अंतराल को संभालना होता है। डिकोडर का काम प्रत्येक छूटे हुए स्लॉट के लिए एक विश्वसनीय ऑडियो फ्रेम गढ़ना है, फिर पैकेट्स बहाल होने पर निर्बाध रूप से वास्तविक बिटस्ट्रीम को सौंपना है। एक खराब पीएलसी कार्यान्वयन क्लिक, पॉप करता है, या सबसे बुरी स्थिति में — एक अक्षर को दोहराता है ताकि बच्चे को एक ही शब्द दो बार सुनाई दे और वह भ्रमित हो जाए।

2023 के बाद से हमारी 47,000+ शिप की गई इकाइयों में, ऑडियो-संबंधी सहायता टिकट इस प्रकार विभाजित हैं: 38 प्रतिशत पीएलसी आर्टिफैक्ट्स (क्लिक, पॉप, दोहराए गए अक्षर) हैं, 24 प्रतिशत वॉल्यूम या एजीसी समस्याएँ हैं, 18 प्रतिशत कोडेक-बेमेल बग हैं, 12 प्रतिशत स्पीकर हार्डवेयर दोष हैं, और 8 प्रतिशत सामग्री लेखन समस्याएँ हैं। पीएलसी फर्मवेयर में हमारे द्वारा ठीक की जाने वाली सबसे बड़ी एकल ऑडियो गुणवत्ता समस्या है, और L5, T2, और Y6 प्लेटफ़ॉर्म ने इसे संबोधित करने के लिए विशेष रूप से इंजीनियरिंग प्रयास किया है।

2. व्यवहार में पीएलसी कैसे काम करता है

पीएलसी एल्गोरिद्म तीन परिवारों में आते हैं। वेवफ़ॉर्म प्रतिस्थापन सबसे सरल है: जब कोई फ्रेम गायब हो जाता है, तो डिकोडर फेड-आउट के साथ अंतिम अच्छे फ्रेम को दोहराता है। यह अस्वरित व्यंजनों और स्थिर स्वरों के लिए काम करता है, लेकिन यह रोबोटिक लगता है और ट्रांज़िएंट्स पर श्रव्य असंतताएँ उत्पन्न करता है। पिच-सिंक्रोनस ओवरलैप-ऐड (PSOLA) अधिक परिष्कृत है: डिकोडर पिछले फ्रेम की पिच अवधि का अनुमान लगाता है और उस अवधि का उपयोग करके प्रतिस्थापन संश्लेषित करता है। यह स्वच्छ भाषण के लिए बहुत अच्छा काम करता है और यही डिफ़ॉल्ट रूप से Opus उपयोग करता है। मॉडल-आधारित पीएलसी गायब फ्रेम को उत्पन्न करने के लिए एक छोटे तंत्रिका नेटवर्क या सिग्नल मॉडल का उपयोग करता है; नवीनतम RNNoise और WaveNet-शैली के पीएलसी कार्यान्वयन यहाँ आते हैं।

रीडिंग पेन पोर्टफोलियो इन परिवारों में से दो का उपयोग करता है। B1, B2, F8, K7, KF1, P2, Q6, और Q8 प्लेटफ़ॉर्म पर डिकोडर एक फिक्स्ड-फ़ंक्शन हार्डवेयर ब्लॉक या पोर्टेड Helix/MP3/AAC फिक्स्ड-पॉइंट लाइब्रेरी है; पीएलसी को फर्मवेयर 2.4.7 (B1/B2), 3.1.2 (F8), 1.9.5 (K7/KF1), 2.0.3 (P2), और 3.3.1 (Q6/Q8) में जोड़ी गई PSOLA संवर्द्धन के साथ वेवफ़ॉर्म-प्रतिस्थापन एल्गोरिद्म के रूप में लागू किया गया है। L5, T2, और Y6 प्लेटफ़ॉर्म पर डिकोडर Cortex-A53 पर चलने वाला libopus संदर्भ कार्यान्वयन है जिसमें SILK+CELT लेयर पर डिफ़ॉल्ट रूप से पीएलसी सक्षम है; यह एक मॉडल-आधारित पीएलसी है जो पुराने वेवफ़ॉर्म दृष्टिकोण की तुलना में बर्स्ट हानि पर नाटकीय रूप से बेहतर है।

B2B विशिष्टता उद्देश्यों के लिए, सार्थक अंतर फिक्स्ड पीएलसी (एक ज्ञात एल्गोरिद्म जिसे विक्रेता नाम दे सकता है) और अनुकूली पीएलसी (एक एल्गोरिद्म जो देखी गई पैकेट हानि सांख्यिकी के आधार पर अपनी कंसीलमेंट रणनीति को समायोजित करता है) के बीच है। सभी 11 प्रोडक्शन मॉडल अनुकूली पीएलसी का उपयोग करते हैं, लेकिन L5/T2/Y6 परिवार तेज़ी से अनुकूलित होता है क्योंकि Opus का पीएलसी स्वयं बिटस्ट्रीम में निर्मित होता है।

3. प्रति-मॉडल पीएलसी कार्यान्वयन

नीचे दी गई तालिका 11 प्रोडक्शन मॉडलों के लिए इंजीनियरिंग बेसलाइन है। "PLC algorithm" फर्मवेयर में विशिष्ट कंसीलमेंट रणनीति का नाम देता है; "PLC convergence time" वह है कि डिकोडर को कितने लगातार अच्छे फ्रेम चाहिए इससे पहले कि वह इंटरपोलेशन बंद करे और बिटस्ट्रीम पर फिर से भरोसा करे; "tested loss profile" वह पैकेट हानि पैटर्न है जिसका हम क्यूए स्वीकृति में उपयोग करते हैं।

कन्वर्जेंस टाइम की संख्या पर ध्यान दिया जाना चाहिए। लॉस बर्स्ट के बाद डिकोडर पर फिर से पूरी तरह भरोसा करने से पहले B1 और B2 को 12 अच्छे फ्रेम (~250 ms @ 22.05 kHz) चाहिए। L5, T2, Y6 को केवल 4 फ्रेम (~80 ms) चाहिए। वास्तविक कक्षा में, पेन एक Wi-Fi कोएक्सिस्टेंस इवेंट के कारण 30–80 ms ऑडियो खो देता है, और फिर अगले इवेंट से पहले 250–800 ms साफ़ ऑडियो होता है। पुराने प्लैटफ़ॉर्म उस साफ़ विंडो का लगभग एक तिहाई हिस्सा रिकवरी में बिताते हैं; नए प्लैटफ़ॉर्म लगभग दसवाँ हिस्सा। व्यक्तिपरक रूप से, यह "पेन कभी-कभी क्लिक करता है" और "पेन कभी क्लिक नहीं करता" के बीच का अंतर है।

4. तीन लॉस पैटर्न जो वास्तव में होते हैं

PLC साहित्य आमतौर पर एक ही प्रतिशत पर यूनिफ़ॉर्म रैंडम पैकेट लॉस मान लेता है। रीडिंग पेन में ऐसा नहीं होता। 47,000+ यूनिट्स के हमारे फ़ील्ड टेलीमेट्री में, तीन लॉस पैटर्न प्रमुख हैं, और उनमें से हर एक को अलग PLC प्रतिक्रिया की आवश्यकता होती है।

पैटर्न A — Wi-Fi कोएक्सिस्टेंस बर्स्ट। जब पेन का Wi-Fi रेडियो बैकग्राउंड स्कैन करता है या टेलीमेट्री भेजता है, तो BLE लिंक लेयर 20–80 ms के लिए ऑडियो पैकेट्स को क्यू में रखता है, और फिर क्यू को खाली करता है। ऑडियो में 20–80 ms का गैप दिखता है जिसके बाद 3–5 फ्रेम का बर्स्ट आता है। PLC को गैप को छिपाना होगा और बर्स्ट के दौरान क्लिक किए बिना गुज़रना होगा। L5/T2/Y6 पर Opus PLC इसे सहजता से संभालता है; B1/B2/F8/P2 पर वेवफ़ॉर्म-सब्स्टिट्यूशन PLC 60 ms गैप्स पर लगभग 30 प्रतिशत समय एक श्रव्य क्लिक उत्पन्न करता है।

पैटर्न B — कंजेशन के तहत रीऑर्डर। जब BLE लिंक रीट्रांसमिट करता है, तो पैकेट्स ऑर्डर से बाहर आ सकते हैं। डिकोडर को तय करना होगा कि इन-ऑर्डर पैकेट की प्रतीक्षा करनी है (जिससे जिटर आता है) या वास्तविक पैकेट के बाद लेट पैकेट चलाना है (जिससे ग्लिच आता है)। Opus का PLC लेट पैकेट को रखता है और कंसीलमेंट को रिफ़ाइन करने के लिए उसका उपयोग करता है। पुराने प्लैटफ़ॉर्म पर फ़िक्स्ड-फ़ंक्शन AAC और MP3 PLC लेट पैकेट को पूरी तरह ड्रॉप कर देते हैं, जो सही है लेकिन इसका मतलब है कि मॉडल में लेट पैकेट का योगदान बर्बाद हो जाता है।

पैटर्न C — कम RSSI से लंबा फ़ेड। जब पेन पेयर्ड पेरेंट फ़ोन से BLE रेंज की सीमा पर होता है, तो ऑडियो पैकेट्स 200–500 ms तक लगातार खो सकते हैं। यह दुर्लभ है लेकिन यह वही फ़ेल्योर मोड है जो सबसे खराब फ़ील्ड रिपोर्ट्स उत्पन्न करता है। L5/T2/Y6 पर Opus PLC पहले 200 ms के लिए समझने योग्य लेकिन क्रमशः अधिक सिंथेसाइज़्ड स्पीच चलाएगा, और फिर रोबोटिक आर्टिफ़ैक्ट्स से बचने के लिए स्पीकर को म्यूट कर देगा। पुराने प्लैटफ़ॉर्म पर वेवफ़ॉर्म-सब्स्टिट्यूशन PLC अंतिम फ्रेम को दोहराएगा और स्पष्ट रूप से श्रव्य लूप उत्पन्न करेगा।

5. PLC गुणवत्ता मापना: PESQ और PLCQA

स्पेसिफ़िकेशन के लिए दो ऑब्जेक्टिव मेट्रिक्स उपयोगी हैं। PESQ (Perceptual Evaluation of Speech Quality) ITU-T P.862 मानक है और 1.0 से 4.5 तक का स्कोर देता है। PLCQA Audio Engineering Society से एक नया मेट्रिक है जो विशेष रूप से PLC मूल्यांकन के लिए डिज़ाइन किया गया है और 0 से 100 तक स्कोर करता है। हम तीन इंजेक्टेड लॉस पैटर्न के साथ एक मानकीकृत 30-सेकंड स्पीच क्लिप का उपयोग करके 11 प्रोडक्शन मॉडल पर दोनों को मापते हैं: 5 प्रतिशत यूनिफ़ॉर्म रैंडम, 200 ms अंतराल पर 30 ms बर्स्ट, और 500 ms अंतराल पर 60 ms बर्स्ट।

पुराने फिक्स्ड-फंक्शन प्लेटफ़ॉर्म और Opus प्लेटफ़ॉर्म के बीच का अंतर लॉस पैटर्न बिगड़ने के साथ चौड़ा होता जाता है। 5 प्रतिशत रैंडम लॉस पर स्प्रेड 0.57 PESQ (3.35 से 3.92) है। 60 ms बर्स्ट लॉस पर स्प्रेड 1.04 PESQ (2.58 से 3.62) है। इसका मतलब: अगर आपका रीडिंग पेन प्रोग्राम असली क्लासरूम में असली Wi-Fi और असली BLE के साथ चलेगा, तो L5/T2/Y6 प्लेटफ़ॉर्म B1/B2/F8/P2 प्लेटफ़ॉर्म की तुलना में तनाव के तहत काफ़ी स्वच्छ ऑडियो देता है।

RFQ लिखने वाले खरीदार के लिए, जिस थ्रेशोल्ड की हम सलाह देते हैं वह है 30 ms बर्स्ट लॉस के तहत PESQ ≥ 3.5 और बर्स्ट लॉस के तहत PLCQA ≥ 70। हमारे मौजूदा फ़र्मवेयर में B1, B2, F8 और P2 को छोड़कर हर प्लेटफ़ॉर्म यह बार पार करता है।

6. FEC, रिडंडेंसी, और हम डिफ़ॉल्ट रूप से इनका उपयोग क्यों नहीं करते

PLC एक कन्सीलमेंट एल्गोरिद्म है — यह लापता ऑडियो को बाद में बनाता है। फ़ॉरवर्ड एरर करेक्शन (FEC) और पैकेट रिडंडेंसी प्रिवेंशन एल्गोरिद्म हैं — वे ऑडियो को कई बार भेजते हैं ताकि रिसीवर एक कॉपी खो जाने पर भी मूल को पुनर्निर्मित कर सके। दोनों दृष्टिकोण VoIP के लिए मौजूद हैं, और दोनों रीडिंग पेन प्लेटफ़ॉर्म पर उपलब्ध हैं। हम तीन कारणों से इन्हें डिफ़ॉल्ट रूप से सक्षम नहीं करते।

पहला, FEC और रिडंडेंसी BLE लिंक पर ऑडियो बैंडविड्थ को लगभग दोगुना कर देते हैं। 64 kbps ऑडियो स्ट्रीम वाले रीडिंग पेन पर, FEC 16–32 kbps और जोड़ देता है, जो OID लुकअप एक्नॉलेजमेंट और BLE पेयरिंग ट्रैफ़िक के लिए लिंक बजट से प्रतिस्पर्धा करता है। दूसरा, कोडेक का PLC इतना अच्छा हो गया है कि FEC Opus प्लेटफ़ॉर्म पर 0.2 PESQ अंक से भी कम का सुधार देता है, जो सुनने की सीमा से नीचे है। तीसरा, FEC विलंबिता जोड़ता है, और रीडिंग पेन ऑडियो एक क्लिक-एंड-लिसन अनुभव है जहाँ कोई भी अतिरिक्त विलंबिता एक रिग्रेशन है।

सैटेलाइट-कनेक्टेड क्लासरूम के लिए रीडिंग पेन लाइन बनाने वाले OEMs के लिए (MENA डिस्ट्रीब्यूटर से एक विशिष्ट लेकिन वास्तविक अनुरोध), हम L5 और T2 पर Opus के इन-बैंड FEC को सक्षम करते हैं। यह फ़्लैग फ़र्मवेयर मैनिफ़ेस्ट में firmware ID OPUS_INBAND_FEC=1 पर एक्सपोज़्ड है और 20 ms विलंबिता की कीमत पर मज़बूती में नाटकीय सुधार करते हुए बिटरेट में लगभग 4 kbps जोड़ता है।

7. फ़ील्ड में PLC: 12,000-यूनिट स्कूल पायलट

47 कैंपस और लगभग 12,000 रीडिंग पेन (K7, KF1 और L5 का मिश्रण) वाले एक Gulf-state स्कूल ज़िले के साथ 2025 का एक पायलट हमारे मौजूदा PLC रोडमैप को चलाने वाली फ़ील्ड टेलीमेट्री उत्पन्न किया। K7/KF1 समूह में 4.2 प्रतिशत ऑडियो-टिकट दर देखी गई — जिसे किसी भी सपोर्ट संपर्क के रूप में परिभाषित किया गया जिसमें "क्लिक करना," "स्किप करना," "दोहराना," या "अजीब आवाज़" का उल्लेख था। उसी वातावरण में L5 समूह में 1.1 प्रतिशत ऑडियो-टिकट दर देखी गई। दोनों हमारे सपोर्ट कॉन्ट्रैक्ट द्वारा स्वीकार्य माने जाने वाले 5 प्रतिशत थ्रेशोल्ड से नीचे हैं, लेकिन यह अंतर वही है जो PESQ टेबल से अपेक्षित होगा।

पायलट में PLC का एक गैर-स्पष्ट विफलता मोड भी सामने आया: जब कोई बच्चा पेन को वीडियो ऐप चला रहे टैबलेट के बहुत पास पकड़ता है, तो टैबलेट के Wi-Fi बर्स्ट्स से आने वाला 2.4 GHz हस्तक्षेप इतना तीव्र होता है कि पेन हर कुछ सेकंड में 100–200 ms ऑडियो खो देता है। L5 पर Opus PLC इसे निरंतर 200 ms हानि के बाद "म्यूटिंग" मोड पर स्विच करके संभालता है, जो B2 के वेवफ़ॉर्म लूप से कहीं बेहतर सुनाई देता है। हमने यह म्यूटिंग मोड K7 और KF1 फ़र्मवेयर में रिलीज़ 1.9.5 में जोड़ा और ऑडियो टिकट दर 4.2 प्रतिशत से घटकर 2.6 प्रतिशत हो गई।

8. खरीद अनुबंध में PLC कैसे निर्दिष्ट करें

एक सुविचारित PLC विशिष्टता के तीन भाग होते हैं। पहला, एल्गोरिद्म और कोडेक का नाम दें: "Opus SILK+CELT PLC, 48 kbps मोनो 24 kHz पर, ABR सक्षम, इन-बैंड FEC अक्षम।" दूसरा, परीक्षण पद्धति का नाम दें: "30 ms बर्स्ट हानि और 5 प्रतिशत यादृच्छिक बैकग्राउंड के तहत PESQ ≥ 3.5, ITU-T P.862 संदर्भ कार्यान्वयन के साथ मापा गया।" तीसरा, फ़ील्ड-टेलीमेट्री प्रतिबद्धता का नाम दें: "सप्लायर को प्रत्येक फ़र्मवेयर रिलीज़ पर ऑडियो-टिकट दर रिपोर्ट करनी होगी, 90-दिन के रोलिंग विंडो पर लक्ष्य ≤ 2 प्रतिशत।"

तीन विवरण मायने रखते हैं। पहला, टेस्ट सिग्नल निर्दिष्ट होना चाहिए — हम ITU-T P.501 संदर्भ स्पीच कॉर्पस का उपयोग करते हैं जिसे −26 dBov पर सामान्यीकृत किया गया है; जो सप्लायर अपने स्वयं के सिग्नल पर परीक्षण करते हैं वे बेहतर आँकड़े रिपोर्ट करेंगे। दूसरा, हानि प्रोफ़ाइल निर्दिष्ट होनी चाहिए — 5 प्रतिशत पर एकसमान यादृच्छिक न्यूनतम है; 30 ms बर्स्ट प्रोफ़ाइल वही है जो वास्तविक विफलता मोड को पकड़ती है। तीसरा, PESQ का मापन प्रोडक्शन फ़र्मवेयर पर होना चाहिए, कोडेक संदर्भ पर नहीं — प्रोडक्शन डिकोडर में एरर कंसीलमेंट, AGC और नॉइज़ सप्रेशन शामिल होते हैं जो PESQ को किसी भी दिशा में 0.4 तक बदल सकते हैं।

खरीदार टिप: सप्लायर की नवीनतम फ़र्मवेयर रिलीज़ की PESQ रिपोर्ट माँगें। यदि सप्लायर 24 घंटे के भीतर रिपोर्ट नहीं दे पाता, तो इसे पीले झंडे की तरह लें: PLC मापन हमारे पोर्टफोलियो के हर मॉडल पर मानक रिलीज़ QA का हिस्सा है।

9. PLC और OTA अपडेट मैकेनिज्म

एक अक्सर अनदेखा इंटरैक्शन: OTA फ़र्मवेयर अपडेट के दौरान PLC व्यवहार सामान्य प्लेबैक के दौरान PLC व्यवहार से अलग होता है। जब तक OTA चल रहा होता है, ऑडियो पार्टीशन को दोबारा लिखा जा रहा होता है, और फ्लैश सेक्टर मिटाए जाने के दौरान डिकोडर 200–800 ms तक रुक सकता है। PLC को इस रुकावट को क्लिक पैदा किए बिना और नया फ़र्मवेयर संभालने पर बिटस्ट्रीम के साथ सिंक खोए बिना छिपाना होता है।

L5, T2 और Y6 फ़र्मवेयर 2.6.4 और 4.2.0 एक विशेष "OTA म्यूट" मोड लागू करते हैं जो सेक्टर मिटाने से पहले ऑडियो को साइलेंस की ओर फ़ेड करता है और बाद में वापस लाता है। K7 और KF1 फ़र्मवेयर 1.9.5 भी ऐसा ही करते हैं। पुराने B1, B2, F8 और P2 फ़र्मवेयर में ऐसा नहीं होता — OTA के दौरान ऑडियो क्लिक करेगा, जो स्वीकार्य है क्योंकि उन प्लेटफ़ॉर्म्स पर OTA अभिभावक-चालित क्रिया है जिसके बारे में उपयोगकर्ता पहले से जानता है कि प्लेबैक बाधित होगा।

उन स्कूल ज़िलों में बिक्री करने वाले आयातक के लिए जो रातोंरात OTA अपडेट भेजते हैं, यह एक वास्तविक विशिष्टता आइटम है: यह आवश्यक होना चाहिए कि फ़र्मवेयर OTA म्यूट-एंड-रिज़्यूम मोड लागू करे और म्यूट अवधि फ़र्मवेयर टेलीमेट्री में लॉग की जाए ताकि IT टीमें अपडेट के सफलतापूर्वक पूरा होने की पुष्टि कर सकें।

10b. उपयोग के मामले के अनुसार PLC पैकेट हानि प्रोफ़ाइल

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

11. निर्णय मैट्रिक्स और सिफ़ारिशें

2026 से शुरू होने वाले बिल्कुल नए प्रोग्राम के लिए, सिफ़ारिश है कि L5, T2 या Y6 प्लेटफ़ॉर्म पर Opus-आधारित PLC निर्दिष्ट किया जाए और 30 ms बर्स्ट हानि के तहत PESQ ≥ 3.8 की आवश्यकता रखी जाए। K7, KF1, Q6, Q8 पर मध्य-पीढ़ी के प्रोग्रामों के लिए, AAC PSOLA PLC स्वीकार्य है लेकिन उसी हानि प्रोफ़ाइल के तहत PESQ ≥ 3.4 की आवश्यकता होनी चाहिए। B1, B2, F8, P2 पर लेगेसी प्रोग्रामों के लिए, मौजूदा वेवफ़ॉर्म-सब्स्टिट्यूशन PLC अभिभावक-चालित घरेलू उपयोग के लिए पर्याप्त है लेकिन कक्षा तैनाती के लिए निर्दिष्ट नहीं किया जाना चाहिए जहाँ Wi-Fi सह-अस्तित्व लगातार रहता है।

PLC विशिष्टता लिखने वाले प्रोक्योरमेंट अधिकारियों के लिए, अनुबंध को बंद करने वाली पंक्ति है: "ऑडियो डिकोडर एडाप्टिव PLC लागू करेगा जो ITU-T P.862 के अनुसार 30 ms बर्स्ट हानि और 5 प्रतिशत एकसमान यादृच्छिक बैकग्राउंड के तहत PESQ ≥ 3.5 हासिल करेगा, और AES PLCQA मानक के अनुसार बर्स्ट हानि के तहत PLCQA ≥ 70, −26 dBov पर P.501 संदर्भ स्पीच कॉर्पस के साथ प्रोडक्शन फ़र्मवेयर पर मापा गया। OTA अपडेट में PLC आर्टिफ़ैक्ट से बचने के लिए फ़्लैश सेक्टर मिटाने के आसपास म्यूट-एंड-रिज़्यूम शामिल होगा।"

संबंधित पठन

• रीडिंग पेन कोडेक कम्प्रेशन MP3 बनाम AAC बनाम Opus
• रीडिंग पेन ऑडियो बिटरेट 64 बनाम 128 बनाम 256 kbps
• रीडिंग पेन नॉइज़ सप्रेशन और RNNoise
• रीडिंग पेन इको कैंसलेशन और AEC
• रीडिंग पेन ब्लूटूथ 5.0 बनाम 5.2 बनाम 5.3
• रीडिंग पेन रिकॉर्डिंग फ़ॉर्मेट WAV बनाम AMR बनाम Opus
• OEM रीडिंग पेन सेवाएँ
• रीडिंग पेन के लिए कोटेशन माँगें