ব্যাচিং

ব্যাচিং কি?

ব্যাচিং বলতে সেন্সর হাব এবং/অথবা হার্ডওয়্যার FIFO-এ সেন্সর HAL-এর মাধ্যমে ইভেন্টগুলি রিপোর্ট করার আগে বাফারিং সেন্সর ইভেন্টকে বোঝায়। যে অবস্থানে সেন্সর ইভেন্টগুলি বাফার করা হয় (সেন্সর হাব এবং/অথবা হার্ডওয়্যার FIFO) এই পৃষ্ঠায় "FIFO" হিসাবে উল্লেখ করা হয়েছে৷ যখন সেন্সর ইভেন্ট ব্যাচিং সক্রিয় না থাকে, তখন সেন্সর ইভেন্টগুলি উপলব্ধ হলে সেন্সর HAL-কে অবিলম্বে রিপোর্ট করা হয়।

ব্যাচিং শুধুমাত্র প্রধান অ্যাপ্লিকেশন প্রসেসর (AP), যা Android চালায়, যখন অনেকগুলি সেন্সর ইভেন্ট প্রক্রিয়াকরণের জন্য প্রস্তুত থাকে, প্রতিটি পৃথক ইভেন্টের জন্য এটিকে জাগানোর পরিবর্তে শুধুমাত্র জাগ্রত করে উল্লেখযোগ্য শক্তি সঞ্চয় সক্ষম করতে পারে। সম্ভাব্য শক্তি সঞ্চয় সরাসরি সেন্সর হাব এবং/অথবা FIFO বাফার করতে পারে এমন ইভেন্টের সংখ্যার সাথে সম্পর্কযুক্ত: আরও ইভেন্ট ব্যাচ করা গেলে বিদ্যুৎ সাশ্রয়ের একটি বৃহত্তর সম্ভাবনা রয়েছে। ব্যাচিং উচ্চ-পাওয়ার AP ওয়েক-আপের সংখ্যা কমাতে কম-পাওয়ার মেমরি ব্যবহার করে।

ব্যাচিং তখনই ঘটতে পারে যখন একটি সেন্সর একটি হার্ডওয়্যার FIFO ধারণ করে এবং/অথবা একটি সেন্সর হাবের মধ্যে ইভেন্টগুলিকে বাফার করতে পারে৷ উভয় ক্ষেত্রেই, সেন্সরকে অবশ্যই SensorInfo.fifoMaxEventCount মাধ্যমে সর্বাধিক সংখ্যক ইভেন্টের রিপোর্ট করতে হবে যা একবারে ব্যাচ করা যেতে পারে।

যদি একটি সেন্সর একটি FIFO এর মধ্যে স্থান সংরক্ষিত থাকে, সেন্সরকে অবশ্যই SensorInfo.fifoReservedEventCount এর মাধ্যমে সংরক্ষিত ইভেন্টের সংখ্যা রিপোর্ট করতে হবে। যদি FIFO সেন্সরের জন্য উৎসর্গ করা হয়, তাহলে SensorInfo.fifoReservedEventCount হল FIFO-এর আকার। যদি FIFO কয়েকটি সেন্সরের মধ্যে ভাগ করা হয় তবে এই মানটি শূন্য হতে পারে। একটি সাধারণ ব্যবহারের ক্ষেত্রে একটি সেন্সরকে সম্পূর্ণ FIFO ব্যবহার করার অনুমতি দেওয়া হয় যদি এটি একমাত্র সক্রিয় সেন্সর হয়। যদি একাধিক সেন্সর সক্রিয় থাকে, তাহলে প্রতিটি সেন্সর FIFO-তে অন্তত SensorInfo.fifoReservedEventCount ইভেন্টের জন্য জায়গা নিশ্চিত করে। যদি একটি সেন্সর হাব ব্যবহার করা হয়, তাহলে গ্যারান্টিটি সফ্টওয়্যারের মাধ্যমে প্রয়োগ করা যেতে পারে।

সেন্সর ইভেন্টগুলি নিম্নলিখিত পরিস্থিতিতে ব্যাচ করা হয়:

• সেন্সরের বর্তমান সর্বাধিক রিপোর্ট লেটেন্সি শূন্যের চেয়ে বেশি, যার মানে হল যে সেন্সর ইভেন্টগুলি HAL-এর মাধ্যমে রিপোর্ট করার আগে সর্বাধিক রিপোর্ট লেটেন্সি পর্যন্ত বিলম্বিত হতে পারে।
• AP সাসপেন্ড মোডে রয়েছে এবং সেন্সরটি একটি নন-ওয়েক-আপ সেন্সর। এই ক্ষেত্রে, ইভেন্টগুলি অবশ্যই AP কে জাগাবে না এবং AP জাগ্রত না হওয়া পর্যন্ত সংরক্ষণ করতে হবে৷

যদি একটি সেন্সর ব্যাচিং সমর্থন না করে এবং AP ঘুমিয়ে থাকে, তবে শুধুমাত্র জেগে ওঠা সেন্সর ইভেন্টগুলি AP-কে রিপোর্ট করা হয় এবং নন-ওয়েক-আপ ইভেন্টগুলি AP-কে রিপোর্ট করা উচিত নয়৷

ব্যাচিং পরামিতি

ব্যাচিংয়ের আচরণ নিয়ন্ত্রণকারী দুটি প্যারামিটার হল sampling_period_ns এবং max_report_latency_ns । sampling_period_ns নির্ধারণ করে যে একটি নতুন সেন্সর ইভেন্ট কত ঘন ঘন তৈরি হয় এবং max_report_latency_ns নির্ধারণ করে কতক্ষণ পর্যন্ত ইভেন্টটি সেন্সর HAL কে রিপোর্ট করতে হবে।

sampling_period_ns

sampling_period_ns প্যারামিটার মানে কি তা নির্ভর করে নির্দিষ্ট সেন্সরের রিপোর্টিং মোডের উপর:

• ক্রমাগত: sampling_period_ns হল স্যাম্পলিং রেট, যার অর্থ ইভেন্টগুলি যে হারে তৈরি হয়।
• অন-পরিবর্তন: sampling_period_ns ইভেন্টের নমুনা নেওয়ার হারকে সীমিত করে, যার অর্থ ইভেন্টগুলি প্রতিটি sampling_period_ns ন্যানোসেকেন্ডের চেয়ে দ্রুত তৈরি হয় না। সময়কাল sampling_period_ns এর চেয়ে দীর্ঘ হতে পারে যদি কোনো ইভেন্ট তৈরি না হয় এবং পরিমাপ করা মানগুলি দীর্ঘ সময়ের জন্য পরিবর্তিত না হয়। আরও বিশদ বিবরণের জন্য, অন-চেঞ্জ রিপোর্টিং মোড দেখুন।
• এক-শট: sampling_period_ns উপেক্ষা করা হয়। এর কোনো প্রভাব নেই।
• বিশেষ: বিশেষ সেন্সরগুলির জন্য sampling_period_ns কীভাবে ব্যবহার করা হয় তার বিশদ বিবরণের জন্য, সেন্সর প্রকারগুলি দেখুন।

বিভিন্ন মোডে sampling_period_ns এর প্রভাব সম্পর্কে আরও তথ্যের জন্য, রিপোর্টিং মোড দেখুন।

ক্রমাগত এবং অন-চেঞ্জ সেন্সরগুলির জন্য:

• যদি sampling_period_ns SensorInfo.minDelay এর থেকে কম হয়, তাহলে HAL বাস্তবায়নকে অবশ্যই চুপচাপ এটিকে max(SensorInfo.minDelay, 1ms) এ আটকাতে হবে। Android 1000 Hz-এর বেশি ইভেন্টের জেনারেশন সমর্থন করে না।
• যদি sampling_period_ns SensorInfo.maxDelay এর থেকে বেশি হয়, তাহলে HAL বাস্তবায়নকে অবশ্যই চুপচাপ SensorInfo.maxDelay এ ছাঁটাই করতে হবে।

শারীরিক সেন্সরগুলির মাঝে মাঝে তারা যে হারে চলতে পারে এবং তাদের ঘড়ির নির্ভুলতার উপর সীমাবদ্ধতা থাকে। এটির জন্য অ্যাকাউন্ট করার জন্য, প্রকৃত নমুনা ফ্রিকোয়েন্সি অনুরোধকৃত ফ্রিকোয়েন্সি থেকে ভিন্ন হতে পারে যতক্ষণ না এটি নীচের টেবিলের প্রয়োজনীয়তাগুলিকে সন্তুষ্ট করে।

max_report_lateency_ns

max_report_latency_ns ন্যানোসেকেন্ডে সর্বাধিক সময় সেট করে, যার দ্বারা AP জাগ্রত থাকাকালীন HAL-এর মাধ্যমে রিপোর্ট করার আগে ইভেন্টগুলি বিলম্বিত এবং হার্ডওয়্যার FIFO-তে সংরক্ষণ করা যেতে পারে।

শূন্যের মান নির্দেশ করে যে ইভেন্টগুলি পরিমাপ করার সাথে সাথেই রিপোর্ট করতে হবে, হয় FIFO কে সম্পূর্ণভাবে এড়িয়ে যেতে হবে, অথবা সেন্সর থেকে একটি ইভেন্ট উপস্থিত হওয়ার সাথে সাথে FIFO খালি করতে হবে।

উদাহরণ স্বরূপ, max_report_latency_ns=0 সহ 50 Hz-এ অ্যাক্টিভেট করা অ্যাক্সিলোমিটার প্রতি সেকেন্ডে 50 বার AP জাগ্রত হওয়ার সময় বাধা সৃষ্টি করবে।

যখন max_report_latency_ns>0 , সেন্সর ইভেন্টগুলি সনাক্ত হওয়ার সাথে সাথে রিপোর্ট করার প্রয়োজন নেই৷ এগুলি সাময়িকভাবে FIFO-এ সংরক্ষণ করা যেতে পারে এবং ব্যাচে রিপোর্ট করা যেতে পারে, যতক্ষণ না কোনো ইভেন্ট max_report_latency_ns ন্যানোসেকেন্ডের বেশি বিলম্বিত হয়। এর মানে হল যে আগের ব্যাচ থেকে সমস্ত ইভেন্ট রেকর্ড করা হয় এবং একবারে ফিরে আসে। এটি AP-তে প্রেরিত বাধার পরিমাণ হ্রাস করে এবং সেন্সর ডেটা ক্যাপচার এবং ব্যাচ করার সময় AP-কে একটি নিম্ন পাওয়ার মোডে (নিষ্ক্রিয়) স্যুইচ করার অনুমতি দেয়।

প্রতিটি ইভেন্ট এর সাথে যুক্ত একটি টাইমস্ট্যাম্প আছে। যে সময়ে একটি ইভেন্ট রিপোর্ট করা হয় তা বিলম্বিত করা ইভেন্ট টাইমস্ট্যাম্পকে প্রভাবিত করে না। টাইমস্ট্যাম্পটি অবশ্যই সঠিক হতে হবে এবং যে সময়ে ইভেন্টটি শারীরিকভাবে ঘটেছিল তার সাথে সঙ্গতিপূর্ণ হতে হবে, এটি রিপোর্ট করার সময় নয়।

সেন্সর ইভেন্টগুলিকে FIFO-তে সাময়িকভাবে সংরক্ষণ করার অনুমতি দিলে HAL-এ ইভেন্ট জমা দেওয়ার আচরণ পরিবর্তন হয় না; বিভিন্ন সেন্সর থেকে ইভেন্টগুলি ইন্টারলিভ করা যেতে পারে এবং একই সেন্সর থেকে সমস্ত ইভেন্ট সময়-অনুযায়ী হয়।

জেগে ওঠা এবং জাগ্রত না হওয়ার ঘটনা

ওয়েক-আপ সেন্সর থেকে সেন্সর ইভেন্টগুলি অবশ্যই এক বা একাধিক ওয়েক-আপ FIFO-তে সংরক্ষণ করতে হবে। একটি সাধারণ নকশা হল একটি একক, বড়, শেয়ার করা ওয়েক-আপ FIFO যেখানে সমস্ত ওয়েক-আপ সেন্সর থেকে ইভেন্টগুলি ইন্টারলিভ করা হয়৷ বিকল্পভাবে, আপনার প্রতি সেন্সরে একটি ওয়েক-আপ FIFO থাকতে পারে বা নির্দিষ্ট ওয়েক-আপ সেন্সরগুলির জন্য উত্সর্গীকৃত FIFO এবং বাকি ওয়েক-আপ সেন্সরগুলির জন্য একটি ভাগ করা FIFO থাকতে পারে৷

একইভাবে, নন-ওয়েক-আপ সেন্সর থেকে সেন্সর ইভেন্টগুলি অবশ্যই এক বা একাধিক নন-ওয়েক-আপ FIFO-তে সংরক্ষণ করতে হবে।

সমস্ত ক্ষেত্রে, জেগে ওঠা সেন্সর ইভেন্ট এবং নন-ওয়েক-আপ সেন্সর ইভেন্টগুলি একই FIFO-তে ইন্টারলিভ করা যায় না। ওয়েক-আপ ইভেন্টগুলি অবশ্যই একটি ওয়েক-আপ FIFO-তে সংরক্ষণ করা উচিত এবং নন-ওয়েক-আপ ইভেন্টগুলি অবশ্যই একটি নন-ওয়েক-আপ FIFO-তে সংরক্ষণ করা উচিত।

জেগে ওঠা FIFO-এর জন্য, একক, বড়, ভাগ করা FIFO ডিজাইন সেরা পাওয়ার সুবিধা প্রদান করে৷ নন-ওয়েক-আপ FIFO-এর জন্য, একক, বড় ভাগ করা FIFO এবং বেশ কয়েকটি ছোট সংরক্ষিত FIFO-র ডিজাইনে একই ধরনের পাওয়ার বৈশিষ্ট্য রয়েছে। প্রতিটি FIFO কনফিগার করার বিষয়ে আরও পরামর্শের জন্য, FIFO বরাদ্দ অগ্রাধিকার দেখুন।

সাসপেন্ড মোডের বাইরে আচরণ

যখন AP জেগে থাকে (সাসপেন্ড মোডে নয়), ইভেন্টগুলি সাময়িকভাবে FIFO-তে সংরক্ষণ করা হয় যতক্ষণ না তারা max_report_latency এর বেশি বিলম্ব না করে।

যতক্ষণ পর্যন্ত AP সাসপেন্ড মোডে প্রবেশ না করে, ততক্ষণ কোনো ইভেন্ট বাদ দেওয়া বা হারিয়ে যাবে না। max_report_latency শেষ হওয়ার আগে যদি অভ্যন্তরীণ FIFO গুলো পূর্ণ হয়ে যায়, তাহলে কোনো ইভেন্ট নষ্ট না হওয়ার জন্য সেই সময়ে ইভেন্ট রিপোর্ট করা হয়।

যদি বেশ কয়েকটি সেন্সর একই FIFO শেয়ার করে এবং তাদের মধ্যে একটির max_report_latency শেষ হয়ে যায়, তাহলে FIFO থেকে সমস্ত ইভেন্ট রিপোর্ট করা হয়, এমনকি অন্যান্য সেন্সরের max_report_latency এখনও অতিবাহিত না হলেও। এটি ইভেন্টের ব্যাচের প্রতিবেদনের সংখ্যা হ্রাস করে। যখন একটি ইভেন্ট রিপোর্ট করা আবশ্যক, সমস্ত সেন্সর থেকে সমস্ত ইভেন্ট রিপোর্ট করা হয়।

উদাহরণস্বরূপ, যদি নিম্নলিখিত সেন্সরগুলি সক্রিয় করা হয়:

• max_report_latency = 20s সহ অ্যাক্সিলোমিটার ব্যাচ
• max_report_latency = 5s সহ gyroscope ব্যাচ

অ্যাক্সিলোমিটার ব্যাচগুলি একই সময়ে রিপোর্ট করা হয় জাইরোস্কোপ ব্যাচগুলি রিপোর্ট করা হয় (প্রতি 5 সেকেন্ডে), এমনকি যদি অ্যাক্সিলোমিটার এবং জাইরোস্কোপ একই FIFO শেয়ার না করে।

সাসপেন্ড মোডে আচরণ

ব্যাচিং এপিকে জাগ্রত না রেখে ব্যাকগ্রাউন্ডে সেন্সর ডেটা সংগ্রহের জন্য বিশেষভাবে উপকারী। যেহেতু সেন্সর ড্রাইভার এবং HAL বাস্তবায়নকে একটি ওয়েক-লক* ধরে রাখার অনুমতি নেই, সেন্সর ডেটা সংগ্রহ করার সময়ও AP সাসপেন্ড মোডে প্রবেশ করতে পারে।

AP স্থগিত থাকাকালীন সেন্সরগুলির আচরণ নির্ভর করে সেন্সরটি একটি জেগে ওঠা সেন্সর কিনা তার উপর। আরো বিস্তারিত জানার জন্য, ওয়েক-আপ সেন্সর দেখুন।

যখন একটি নন-ওয়েক-আপ FIFO পূর্ণ হয়, তখন এটিকে অবশ্যই চারপাশে মোড়ানো এবং একটি বৃত্তাকার বাফারের মতো আচরণ করতে হবে, পুরানো ঘটনাগুলিকে নতুন ইভেন্টগুলির পরিবর্তে পুরানো ঘটনাগুলিকে ওভাররাইট করতে হবে৷ সাসপেন্ড মোডে থাকাকালীন নন-ওয়েক-আপ FIFO-এর উপর max_report_latency কোন প্রভাব ফেলে না।

যখন একটি ওয়েক-আপ FIFO ভরে যায়, বা যখন একটি ওয়েক-আপ সেন্সরের max_report_latency শেষ হয়ে যায়, তখন হার্ডওয়্যারটিকে অবশ্যই AP কে জাগিয়ে তুলতে হবে এবং ডেটা রিপোর্ট করতে হবে।

উভয় ক্ষেত্রেই (ওয়েক-আপ এবং নন-ওয়েক-আপ), যত তাড়াতাড়ি AP সাসপেন্ড মোড থেকে বেরিয়ে আসে, সমস্ত FIFO-এর বিষয়বস্তু সহ একটি ব্যাচ তৈরি করা হয়, এমনকি কিছু সেন্সরের max_report_latency এখনও অতিবাহিত না হলেও। এটি সাসপেন্ড মোডে ফিরে আসার পরে AP-এর আবার জেগে ওঠার ঝুঁকি কমিয়ে দেয় এবং তাই, পাওয়ার খরচ কমিয়ে দেয়।

*চালকদের একটি ওয়েক লক রাখার অনুমতি না দেওয়ার একটি উল্লেখযোগ্য ব্যতিক্রম হল যখন ক্রমাগত রিপোর্টিং মোড সহ একটি ওয়েক-আপ সেন্সর max_report_latency < 1 সেকেন্ডের সাথে সক্রিয় করা হয়। এই ক্ষেত্রে, ড্রাইভার একটি ওয়েক লক ধরে রাখতে পারে কারণ AP এর সাসপেন্ড মোডে প্রবেশ করার সময় নেই, কারণ এটি সাসপেন্ড মোডে পৌঁছানোর আগে একটি ওয়েক-আপ ইভেন্ট দ্বারা জাগ্রত হবে।

ওয়েক-আপ সেন্সর ব্যাচ করার সময় সতর্কতা

ডিভাইসের উপর নির্ভর করে, AP সম্পূর্ণরূপে সাসপেন্ড মোড থেকে বেরিয়ে আসতে এবং FIFO ফ্লাশ করা শুরু করতে কয়েক মিলিসেকেন্ড সময় লাগতে পারে। FIFO-এ পর্যাপ্ত হেড রুম বরাদ্দ করা আবশ্যক যাতে ডিভাইসটিকে সাসপেন্ড মোড থেকে ওয়েক-আপ FIFO ওভারফ্লো না করে বেরিয়ে আসতে দেয়। কোন ইভেন্ট হারিয়ে যাবে না, এবং max_report_latency অবশ্যই সম্মান করা উচিত।

নন-ওয়েক-আপ অন-চেঞ্জ সেন্সর ব্যাচ করার সময় সতর্কতা

অন-চেঞ্জ সেন্সর শুধুমাত্র ইভেন্ট তৈরি করে যখন তারা যে মান পরিমাপ করছে তা পরিবর্তিত হয়। AP সাসপেন্ড মোডে থাকাকালীন পরিমাপ করা মান পরিবর্তন হলে, AP জেগে ওঠার সাথে সাথে অ্যাপ্লিকেশনগুলি একটি ইভেন্ট পাওয়ার আশা করে। এই কারণে, নন-ওয়েক-আপ অন-চেঞ্জ সেন্সর ইভেন্টগুলির ব্যাচিং অবশ্যই সাবধানে সঞ্চালন করা উচিত যদি সেন্সর অন্যান্য সেন্সরগুলির সাথে তার FIFO শেয়ার করে। প্রতিটি অন-চেঞ্জ সেন্সর দ্বারা উত্পন্ন শেষ ইভেন্টটি সর্বদা শেয়ার করা FIFO এর বাইরে সংরক্ষণ করা উচিত যাতে এটি অন্য ইভেন্ট দ্বারা কখনই ওভাররাইট করা না যায়। যখন AP জেগে ওঠে, FIFO থেকে সমস্ত ইভেন্ট রিপোর্ট করার পরে, শেষ অন-চেঞ্জ সেন্সর ইভেন্টটি অবশ্যই রিপোর্ট করতে হবে।

এখানে এড়ানোর জন্য একটি পরিস্থিতি রয়েছে:

1. একটি অ্যাপ্লিকেশন নন-ওয়েক-আপ স্টেপ কাউন্টার (অন-চেঞ্জ) এবং নন-ওয়েক-আপ অ্যাক্সিলোমিটারে (একটানা) নিবন্ধন করে, উভয়ই একই FIFO শেয়ার করে।
2. অ্যাপ্লিকেশনটি একটি স্টেপ কাউন্টার ইভেন্ট step_count=1000 steps code> পায়।
3. এপি সাসপেন্ড করতে যায়।
4. ব্যবহারকারী 20টি ধাপ হাঁটেন, যার ফলে স্টেপ কাউন্টার এবং অ্যাক্সিলোমিটার ইভেন্টগুলিকে ইন্টারলিভ করা হয়, শেষ ধাপের কাউন্টার ইভেন্টটি হচ্ছে step_count = 1020 steps ।
5. ব্যবহারকারী দীর্ঘ সময়ের জন্য নড়াচড়া করে না, যার ফলে অ্যাক্সিলোমিটার ইভেন্টগুলি FIFO-তে জমা হতে থাকে, অবশেষে ভাগ করা FIFO-তে প্রতিটি step_count ইভেন্ট ওভাররাইট করে।
6. AP জেগে ওঠে এবং FIFO থেকে সমস্ত ইভেন্ট অ্যাপ্লিকেশনে পাঠানো হয়।
7. অ্যাপ্লিকেশনটি শুধুমাত্র অ্যাক্সিলোমিটার ইভেন্টগুলি গ্রহণ করে এবং মনে করে যে ব্যবহারকারী হাঁটেননি৷

FIFO-এর বাইরে শেষ ধাপের কাউন্টার ইভেন্টটি সংরক্ষণ করে, AP জেগে উঠলে HAL এই ইভেন্টটি রিপোর্ট করতে পারে, এমনকি অন্যান্য সমস্ত স্টেপ কাউন্টার ইভেন্ট অ্যাক্সিলোমিটার ইভেন্ট দ্বারা ওভাররাইট করা হলেও। এইভাবে, AP জেগে উঠলে অ্যাপ্লিকেশনটি step_count = 1020 steps পায়।

ব্যাচিং বাস্তবায়ন করুন

শক্তি সঞ্চয় করতে, AP-এর সাহায্য ছাড়াই ব্যাচিং প্রয়োগ করতে হবে, এবং AP-কে ব্যাচিংয়ের সময় স্থগিত করার অনুমতি দিতে হবে।

যদি ব্যাচিং একটি সেন্সর হাবে সঞ্চালিত হয়, তাহলে সেন্সর হাবের পাওয়ার ব্যবহার কমিয়ে আনা উচিত।

সর্বোচ্চ রিপোর্ট লেটেন্সি যেকোন সময় পরিবর্তন করা যেতে পারে, বিশেষ করে যখন নির্দিষ্ট সেন্সর ইতিমধ্যেই সক্রিয় থাকে; এবং এর ফলে ঘটনা হারানো উচিত নয়।

FIFO বরাদ্দ অগ্রাধিকার

যে প্ল্যাটফর্মগুলিতে হার্ডওয়্যার FIFO এবং/অথবা সেন্সর হাবের বাফার আকার সীমিত, সিস্টেম ডিজাইনারদের প্রতিটি সেন্সরের জন্য কত FIFO সংরক্ষণ করতে হবে তা চয়ন করতে হতে পারে। এই পছন্দের সাথে সাহায্য করার জন্য, এখানে সম্ভাব্য অ্যাপ্লিকেশনগুলির একটি তালিকা রয়েছে যখন বিভিন্ন সেন্সরে ব্যাচিং প্রয়োগ করা হয়৷

উচ্চ মান: নিম্ন-শক্তি পথচারী মৃত হিসাব

লক্ষ্য ব্যাচিং সময়: 1 থেকে 10 মিনিট

ব্যাচের জন্য সেন্সর:

• জেগে ওঠা স্টেপ ডিটেক্টর
• 5 Hz এ ওয়েক-আপ গেম রোটেশন ভেক্টর
• 5 Hz এ ওয়েক-আপ ব্যারোমিটার
• 5 Hz এ ওয়েক-আপ আনক্যালিব্রেটেড ম্যাগনেটোমিটার

এই ডেটা ব্যাচ করা AP-কে সাসপেন্ড করতে দেওয়ার সময় পথচারীদের ডেড রেকনিং সম্পাদন করতে দেয়৷

উচ্চ মান: মাঝারি শক্তি বিরতিমূলক কার্যকলাপ/ অঙ্গভঙ্গি স্বীকৃতি

লক্ষ্য ব্যাচিং সময়: 3 সেকেন্ড

ব্যাচের জন্য সেন্সর: 50 Hz এ নন-ওয়েক-আপ অ্যাক্সিলোমিটার

এই ডেটা ব্যাচিং ডেটা সংগ্রহের সময় এপিকে জাগ্রত না রেখেই পর্যায়ক্রমে স্বেচ্ছাচারী ক্রিয়াকলাপ এবং অঙ্গভঙ্গিগুলি সনাক্ত করার অনুমতি দেয়।

মাঝারি মান: মাঝারি শক্তি ক্রমাগত কার্যকলাপ/ অঙ্গভঙ্গি স্বীকৃতি

লক্ষ্য ব্যাচিং সময়: 1 থেকে 3 মিনিট

ব্যাচের জন্য সেন্সর: 50 Hz এ ওয়েক-আপ অ্যাক্সিলোমিটার

এই ডেটা ব্যাচ করা ডেটা সংগ্রহের সময় AP-কে জাগ্রত না রেখেই নির্বিচারে ক্রিয়াকলাপ এবং অঙ্গভঙ্গিগুলিকে ক্রমাগত স্বীকৃতি দেয়৷

মাঝারি-উচ্চ মান: বাধা লোড হ্রাস

লক্ষ্য ব্যাচিং সময়: <1 সেকেন্ড

সেন্সর টু ব্যাচ: যে কোনো উচ্চ-ফ্রিকোয়েন্সি সেন্সর, সাধারণত নন-ওয়েক-আপ।

যদি জাইরোস্কোপটি 240 Hz এ সেট করা হয়, এমনকি মাত্র 10টি গাইরো ইভেন্ট ব্যাচ করাও বাধার সংখ্যা 240/সেকেন্ড থেকে 24/সেকেন্ডে কমিয়ে দিতে পারে।

মাঝারি মান: ক্রমাগত কম-ফ্রিকোয়েন্সি ডেটা সংগ্রহ

লক্ষ্য ব্যাচিং সময়: 1 থেকে 10 মিনিট

ব্যাচের জন্য সেন্সর:

• 1 Hz এ ওয়েক-আপ ব্যারোমিটার
• 1 Hz এ ওয়েক-আপ আর্দ্রতা সেন্সর
• অন্যান্য কম-ফ্রিকোয়েন্সি ওয়েক-আপ সেন্সর একই হারে

কম শক্তিতে মনিটরিং অ্যাপ্লিকেশন তৈরি করার অনুমতি দেয়।

মাঝারি-নিম্ন মান: ক্রমাগত পূর্ণ-সেন্সর সংগ্রহ

লক্ষ্য ব্যাচিং সময়: 1 থেকে 10 মিনিট

সেন্সর টু ব্যাচ: সমস্ত ওয়েক-আপ সেন্সর, উচ্চ ফ্রিকোয়েন্সিতে

সাসপেন্ড মোডে AP ছেড়ে যাওয়ার সময় সেন্সর ডেটা সম্পূর্ণ সংগ্রহের অনুমতি দেয়। FIFO স্থান একটি সমস্যা না হলে শুধুমাত্র বিবেচনা করুন.