ব্যাচিং কী?
ব্যাচিং বলতে Sensors HAL-এর মাধ্যমে ইভেন্ট রিপোর্ট করার আগে সেন্সর হাব এবং/অথবা হার্ডওয়্যার FIFO-তে সেন্সর ইভেন্ট বাফার করাকে বোঝায়। সেন্সর ইভেন্ট যেখানে বাফার করা হয় (সেন্সর হাব এবং/অথবা হার্ডওয়্যার FIFO), সেই লোকেশনকে এই পৃষ্ঠায় "FIFO" হিসেবে উল্লেখ করা হয়েছে। সেন্সর ইভেন্ট ব্যাচিং অ্যাক্টিভ না থাকলে, উপলভ্য হলে সেন্সর ইভেন্ট অবিলম্বে Sensors 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 নির্ধারণ করে যে কতক্ষণ পর্যন্ত
ইভেন্টটি অবশ্যই Sensors 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 ১০০০ Hz-এর বেশি ফ্রিকোয়েন্সিতে ইভেন্ট তৈরি করার সুবিধা দেয় না।sampling_period_ns,SensorInfo.maxDelay-এর থেকে বড় হলে HAL ইমপ্লিমেন্টেশনকে অবশ্যই নীরবেSensorInfo.maxDelay-এ ট্রানকেট করতে হবে।
ফিজিক্যাল সেন্সর কখনও কখনও যে রেটে রান করতে পারে এবং সেগুলির ক্লকের নির্ভুলতা সংক্রান্ত সীমাবদ্ধতা থাকে। এই কারণে, প্রকৃত স্যাম্পলিং ফ্রিকোয়েন্সি অনুরোধ করা ফ্রিকোয়েন্সির থেকে আলাদা হতে পারে, যতক্ষণ না এটি নিচের সারণীতে উল্লেখ করা প্রয়োজনীয়তা পূরণ করে।
অনুরোধ করা ফ্রিকোয়েন্সি যদি |
তাহলে আসল ফ্রিকোয়েন্সি অবশ্যই |
|---|---|
ন্যূনতম ফ্রিকোয়েন্সির নিচে (<1/maxDelay) |
ন্যূনতম ফ্রিকোয়েন্সির ৯০% থেকে ১১০%-এর মধ্যে |
ন্যূনতম ও সর্বাধিক ফ্রিকোয়েন্সির মধ্যে |
অনুরোধ করা ফ্রিকোয়েন্সির ৯০% থেকে ২২০% এর মধ্যে |
সর্বাধিক ফ্রিকোয়েন্সির উপরে (>1/minDelay) |
সর্বাধিক ফ্রিকোয়েন্সির ৯০% থেকে ১১০% এবং ১১০০ Hz-এর কম |
max_report_latency_ns
max_report_latency_ns ন্যানোসেকেন্ডে সর্বাধিক সময় সেট করে, যার মাধ্যমে
ইভেন্ট বিলম্বিত করা যায় এবং AP জেগে থাকা অবস্থায় HAL-এর মাধ্যমে রিপোর্ট করার
আগে হার্ডওয়্যার FIFO-তে স্টোর করা যায়।
শূন্য মান থেকে বোঝা যায় যে ইভেন্টগুলি পরিমাপ করা হলেই তা রিপোর্ট করতে হবে, হয় FIFO সম্পূর্ণ এড়িয়ে গিয়ে অথবা সেন্সর থেকে একটি ইভেন্ট পাওয়া মাত্রই FIFO খালি করে দিয়ে।
যেমন, AP জেগে থাকলে, ৫০ Hz-এ অ্যাক্টিভেট করা অ্যাক্সিলরোমিটার
max_report_latency_ns=0 প্রতি সেকেন্ডে ৫০ বার ইন্টারাপ্ট ট্রিগার করবে।
max_report_latency_ns>0 হলে, সেন্সর ইভেন্ট শনাক্ত করার সাথে সাথেই
রিপোর্ট করার প্রয়োজন নেই। কোনও ইভেন্ট
max_report_latency_ns ন্যানোসেকেন্ডের বেশি দেরি না হলে, সেগুলি FIFO-তে
সাময়িকভাবে স্টোর করা যেতে পারে এবং ব্যাচে রিপোর্ট করা যেতে পারে। এর অর্থ হল, আগের ব্যাচ থেকে
সব ইভেন্ট রেকর্ড করা হয় এবং একসাথে ফেরত দেওয়া হয়। এটি 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-এর সাথে ব্যাচ করা অ্যাক্সিলরোমিটার = ২০ সেকেন্ডmax_report_latency-এর সাথে ব্যাচ করা জাইরোস্কোপ = ৫ সেকেন্ড
জাইরোস্কোপ ব্যাচ রিপোর্ট করার একই সময়ে অ্যাকসিলরোমিটার ব্যাচ রিপোর্ট করা হয় (প্রতি ৫ সেকেন্ডে), এমনকি অ্যাকসিলরোমিটার ও জাইরোস্কোপ একই FIFO শেয়ার না করলেও।
সাসপেন্ড মোডে আচরণ
AP চালু না রেখে ব্যাকগ্রাউন্ডে সেন্সর ডেটা সংগ্রহ করার জন্য ব্যাচিং বিশেষভাবে উপকারী। সেন্সর ড্রাইভার ও HAL ইমপ্লিমেন্টেশনকে ওয়েক-লক* হোল্ড করার অনুমতি দেওয়া হয় না বলে, সেন্সর ডেটা সংগ্রহ করা হলেও AP সাসপেন্ড মোডে প্রবেশ করতে পারে।
AP সাসপেন্ড থাকাকালীন সেন্সরের আচরণ নির্ভর করে সেন্সরটি ওয়েক-আপ সেন্সর কিনা তার উপর। আরও বিবরণের জন্য, ওয়েক-আপ সেন্সর দেখুন।
নন-ওয়েক-আপ FIFO ভর্তি হয়ে গেলে, এটিকে অবশ্যই র্যাপ-অ্যারাউন্ড করতে হবে এবং একটি
বৃত্তাকার বাফারের মতো আচরণ করতে হবে, পুরনো ইভেন্টগুলিকে নতুন ইভেন্ট দিয়ে ওভাররাইট করতে হবে এবং
পুরনো ইভেন্টগুলিকে রিপ্লেস করতে হবে। সাসপেন্ড মোডে থাকাকালীন max_report_latency-এর ফলে নন-ওয়েক-আপ FIFO-তে কোনও প্রভাব পড়ে না।
ওয়েক-আপ FIFO পূর্ণ হয়ে গেলে অথবা কোনও ওয়েক-আপ সেন্সরের max_report_latency
টাইম-আউট হয়ে গেলে, হার্ডওয়্যারকে AP-কে জাগিয়ে তুলতে হবে এবং
ডেটা রিপোর্ট করতে হবে।
দুটি ক্ষেত্রেই (ওয়েক-আপ ও নন-ওয়েক-আপ), AP সাসপেন্ড মোড থেকে বেরিয়ে আসার সাথে সাথেই, সব FIFO-এর কন্টেন্ট সহ একটি ব্যাচ তৈরি করা হয়, এমনকি যদি
max_report_latency কিছু সেন্সরের এখনও না পেরিয়ে থাকে। এটি
AP-কে সাসপেন্ড মোডে ফিরে আসার পরেই আবার জেগে ওঠার ঝুঁকি কমিয়ে দেয় এবং
তাই বিদ্যুৎ খরচ কমিয়ে দেয়।
*ড্রাইভারদের ওয়েক লক হোল্ড করার অনুমতি না দেওয়ার একটি উল্লেখযোগ্য ব্যতিক্রম হল
কন্টিনিউয়াস রিপোর্টিং মোড সহ একটি ওয়েক-আপ সেন্সর
max_report_latency < ১ সেকেন্ডের জন্য অ্যাক্টিভেট করা হলে। এই ক্ষেত্রে,
ড্রাইভার একটি ওয়েক লক হোল্ড করতে পারে কারণ AP-এর কাছে সাসপেন্ড মোডে
ঢোকার সময় নেই, কারণ এটি সাসপেন্ড মোডে পৌঁছানোর
আগে একটি ওয়েক-আপ ইভেন্ট দ্বারা জেগে উঠবে।
ওয়েক-আপ সেন্সর ব্যাচ করার সময় সতর্কতা
ডিভাইসের উপর নির্ভর করে, AP-এর সাসপেন্ড মোড থেকে সম্পূর্ণভাবে বেরিয়ে আসতে এবং FIFO ফ্লাশ করা শুরু করতে
কয়েক মিলিসেকেন্ড সময় লাগতে পারে। সাসপেন্ড মোড থেকে বেরিয়ে আসার জন্য ডিভাইসের FIFO-তে
যথেষ্ট জায়গা থাকতে হবে।
তা না হলে, ওয়েক-আপ FIFO ওভারফ্লো হয়ে যাবে। কোনও ইভেন্ট যেন বাদ না যায় এবং
max_report_latency যেন মেনে চলা হয়।
নন-ওয়েক-আপ অন-চেঞ্জ সেন্সর ব্যাচ করার সময় সতর্কতা
পরিবর্তন-ভিত্তিক সেন্সর শুধুমাত্র তখনই ইভেন্ট তৈরি করে যখন সেটির পরিমাপ করা ভ্যালু পরিবর্তিত হয়। AP সাসপেন্ড মোডে থাকাকালীন পরিমাপ করা ভ্যালু পরিবর্তন হলে, AP জেগে ওঠার সাথে সাথেই অ্যাপ্লিকেশন একটি ইভেন্ট পাওয়ার আশা করে। এই কারণে, নন-ওয়েক-আপ অন-চেঞ্জ সেন্সর ইভেন্টের ব্যাচিং অবশ্যই সাবধানে করতে হবে যদি সেন্সরটি তার FIFO অন্যান্য সেন্সরের সাথে শেয়ার করে। প্রতিটি অন-চেঞ্জ সেন্সর দ্বারা তৈরি করা শেষ ইভেন্ট অবশ্যই শেয়ার করা FIFO-এর বাইরে সেভ করতে হবে যাতে এটি অন্য ইভেন্ট দ্বারা কখনও ওভাররাইট করা না যায় । AP চালু হওয়ার পরে, FIFO থেকে সব ইভেন্ট রিপোর্ট করা হয়ে গেলে, শেষ অন-চেঞ্জ সেন্সর ইভেন্ট অবশ্যই রিপোর্ট করতে হবে।
এখানে একটি পরিস্থিতি দেওয়া হল যা এড়িয়ে যাওয়া উচিত:
- একটি অ্যাপ্লিকেশন নন-ওয়েক-আপ স্টেপ কাউন্টার (পরিবর্তন-অনুযায়ী) এবং নন-ওয়েক-আপ অ্যাক্সেলেরোমিটার (অবিরাম) রেজিস্টার করে, দুটিই একই FIFO শেয়ার করে।
- অ্যাপ্লিকেশনটি একটি স্টেপ কাউন্টার ইভেন্ট
step_count=1000 stepscode> পায়। - AP সাসপেন্ড হয়ে যায়।
- ব্যবহারকারী ২০টি ধাপ হাঁটেন, এর ফলে স্টেপ কাউন্টার ও অ্যাক্সিলরোমিটার ইভেন্ট ইন্টারলিভড হয়ে যায়, শেষ স্টেপ কাউন্টার ইভেন্ট হল
step_count = 1020 steps। - ব্যবহারকারী অনেকক্ষণ ধরে না নড়লে, অ্যাক্সিলরোমিটার ইভেন্ট FIFO-তে
জমা হতে থাকে এবং অবশেষে শেয়ার করা FIFO-তে থাকা প্রতিটি
step_countইভেন্ট ওভাররাইট হয়ে যায়। - AP জেগে ওঠে এবং FIFO থেকে সব ইভেন্ট অ্যাপ্লিকেশনে পাঠানো হয়।
- অ্যাপ্লিকেশনটি শুধুমাত্র অ্যাক্সিলরোমিটার ইভেন্ট পায় এবং মনে করে যে ব্যবহারকারী হাঁটেননি।
FIFO-এর বাইরে শেষ স্টেপ কাউন্টার ইভেন্ট সেভ করার মাধ্যমে, AP জেগে উঠলে HAL এই ইভেন্ট সম্পর্কে রিপোর্ট করতে পারে, এমনকি যদি অ্যাক্সিলরোমিটার ইভেন্ট দ্বারা অন্য সব স্টেপ কাউন্টার ইভেন্ট ওভাররাইট করা হয়ে থাকে।
এইভাবে, AP জেগে উঠলে অ্যাপ্লিকেশনটি
step_count = 1020 steps পায়।
ব্যাচিং প্রয়োগ করা
পাওয়ার সাশ্রয় করতে, AP-এর সাহায্য ছাড়াই ব্যাচিং প্রয়োগ করতে হবে এবং ব্যাচিং চলাকালীন AP-কে সাসপেন্ড করার অনুমতি দিতে হবে।
সেন্সর হাবে ব্যাচিং করা হলে, সেন্সর হাবের পাওয়ার ব্যবহার কমিয়ে আনতে হবে।
সর্বাধিক রিপোর্ট ল্যাটেন্সি যেকোনও সময় পরিবর্তন করা যেতে পারে, বিশেষ করে যখন নির্দিষ্ট সেন্সরটি আগে থেকেই চালু করা থাকে; এবং এর ফলে ইভেন্ট হারিয়ে যাওয়া উচিত নয়।
FIFO অ্যালোকেশন প্রায়োরিটি
যেসব প্ল্যাটফর্মে হার্ডওয়্যার FIFO এবং/অথবা সেন্সর হাব বাফার সাইজ সীমিত থাকে, সেখানে সিস্টেম ডিজাইনারদের প্রতিটি সেন্সরের জন্য কত FIFO রিজার্ভ করতে হবে তা বেছে নিতে হতে পারে। এই পছন্দটি করতে সাহায্য করার জন্য, এখানে সম্ভাব্য অ্যাপ্লিকেশনের একটি তালিকা রয়েছে যখন বিভিন্ন সেন্সরে ব্যাচিং প্রয়োগ করা হয়।
হাই ভ্যালু: কম-পাওয়ারের পেডেস্ট্রিয়ান ডেড রেকনিং
টার্গেট ব্যাচিংয়ের সময়: ১ থেকে ১০ মিনিট
ব্যাচ করার জন্য সেন্সর:
- ঘুম থেকে ওঠার ধাপ শনাক্তকারী
- ৫ Hz-এ গেম রোটেশন ভেক্টর জাগিয়ে তোলা
- ৫ Hz-এ ঘুম থেকে ওঠার ব্যারোমিটার
- ৫ Hz-এ ক্যালিব্রেট না করা ম্যাগনেটোমিটারকে জাগিয়ে তোলা
এই ডেটা ব্যাচিং করলে, AP সাসপেন্ড করার সময়ও পেডেস্ট্রিয়ান ডেড রেকনিং পারফর্ম করা যায়।
উচ্চ মান: মাঝারি পাওয়ারের ইন্টারমিটেন্ট অ্যাক্টিভিটি/জেসচার শনাক্তকরণ
টার্গেট ব্যাচিং টাইম: ৩ সেকেন্ড
ব্যাচ করার জন্য সেন্সর: ৫০ হার্টজে নন-ওয়েক-আপ অ্যাকসিলরোমিটার
এই ডেটা ব্যাচিং করলে, ডেটা সংগ্রহ করার সময় AP চালু না রেখেই, অনিয়মিত অ্যাক্টিভিটি ও জেসচারকে নির্দিষ্ট সময় অন্তর শনাক্ত করা যায়।
মাঝারি ভ্যালু: মাঝারি পাওয়ারের একটানা অ্যাক্টিভিটি/জেসচার শনাক্তকরণ
টার্গেট ব্যাচিং টাইম: ১ থেকে ৩ মিনিট
ব্যাচ করার জন্য সেন্সর: ৫০ Hz-এ অ্যাকসিলরোমিটারকে জাগিয়ে তুলুন
এই ডেটা ব্যাচিং করলে, ডেটা সংগ্রহ করার সময় AP চালু না রেখেই, একটানা যেকোনও অ্যাক্টিভিটি ও জেসচার শনাক্ত করা যায়।
মাঝারি-উচ্চ ভ্যালু: লোড কমানোর জন্য বাধা দেওয়া
টার্গেট ব্যাচিং টাইম: < ১ সেকেন্ড
ব্যাচ করার জন্য সেন্সর: যেকোনও হাই-ফ্রিকোয়েন্সি সেন্সর, সাধারণত নন-ওয়েক-আপ।
জাইরোস্কোপ ২৪০ Hz-এ সেট করা থাকলে, এমনকি ১০টি জাইরো ইভেন্ট ব্যাচিং করলেও ইন্টারাপ্টের সংখ্যা ২৪০/সেকেন্ড থেকে ২৪/সেকেন্ডে কমে যেতে পারে।
মাঝারি ভ্যালু: একটানা কম-ফ্রিকোয়েন্সি ডেটা সংগ্রহ
টার্গেট ব্যাচিং সময়: ১ থেকে ১০ মিনিট
ব্যাচ করার জন্য সেন্সর:
- ১ Hz-এ ব্যারোমিটার চালু করুন
- ১ হার্টজে ওয়েক-আপ হিউমিডিটি সেন্সর
- একই রেটে অন্যান্য কম ফ্রিকোয়েন্সিযুক্ত ওয়েক-আপ সেন্সর
কম পাওয়ারে মনিটরিং অ্যাপ্লিকেশন তৈরি করার অনুমতি দেয়।
মাঝারি-কম ভ্যালু: একটানা সম্পূর্ণ-সেন্সর সংগ্রহ
টার্গেট ব্যাচিং সময়: ১ থেকে ১০ মিনিট
ব্যাচ করার জন্য সেন্সর: সবকটি ওয়েক-আপ সেন্সর, হাই ফ্রিকোয়েন্সিতে
AP সাসপেন্ড মোডে থাকাকালীন সেন্সর ডেটা সম্পূর্ণ সংগ্রহ করার অনুমতি দেয়। FIFO স্পেস কোনও সমস্যা না হলে তবেই এটি বিবেচনা করুন।