รวมกลุ่ม

แบทช์คืออะไร?

การรวมกลุ่มหมายถึงการบัฟเฟอร์เหตุการณ์เซ็นเซอร์ในฮับเซ็นเซอร์และ/หรือฮาร์ดแวร์ FIFO ก่อนที่จะรายงานเหตุการณ์ผ่าน เซ็นเซอร์ HAL ตำแหน่งที่เหตุการณ์เซ็นเซอร์ถูกบัฟเฟอร์ (ฮับเซ็นเซอร์และ/หรือฮาร์ดแวร์ FIFO) เรียกว่า "FIFO" ในหน้านี้ เมื่อไม่ได้ใช้งานการแบทช์เหตุการณ์เซ็นเซอร์ เหตุการณ์ของเซ็นเซอร์จะถูกรายงานไปยังเซ็นเซอร์ HAL ทันทีเมื่อพร้อมใช้งาน

การรวมกลุ่มสามารถช่วยให้ประหยัดพลังงานได้อย่างมากโดยการปลุกเฉพาะตัวประมวลผลแอปพลิเคชันหลัก (AP) ซึ่งรัน Android เมื่อเหตุการณ์เซ็นเซอร์จำนวนมากพร้อมที่จะประมวลผล แทนที่จะปลุกการทำงานของแต่ละเหตุการณ์ การประหยัดพลังงานที่เป็นไปได้มีความสัมพันธ์โดยตรงกับจำนวนเหตุการณ์ที่ฮับเซ็นเซอร์และ/หรือ FIFO สามารถบัฟเฟอร์ได้: มีศักยภาพในการประหยัดพลังงานมากขึ้นหากสามารถจัดกลุ่มเหตุการณ์ได้มากขึ้น การแบทช์ใช้ประโยชน์จากการใช้หน่วยความจำที่ใช้พลังงานต่ำเพื่อลดจำนวนการปลุก AP ที่กำลังไฟสูง

การรวมชุดสามารถเกิดขึ้นได้เฉพาะเมื่อเซ็นเซอร์มีฮาร์ดแวร์ FIFO และ/หรือสามารถบัฟเฟอร์เหตุการณ์ภายในฮับเซ็นเซอร์ได้ ไม่ว่าในกรณีใด เซ็นเซอร์จะต้องรายงานจำนวนเหตุการณ์สูงสุดที่สามารถจัดกลุ่มได้ในคราวเดียวผ่าน SensorInfo.fifoMaxEventCount

หากเซ็นเซอร์มีพื้นที่สงวนไว้ภายใน FIFO เซ็นเซอร์จะต้องรายงานจำนวนเหตุการณ์ที่สงวนไว้ผ่าน SensorInfo.fifoReservedEventCount หาก FIFO ถูกกำหนดไว้สำหรับเซ็นเซอร์โดยเฉพาะ ดังนั้น SensorInfo.fifoReservedEventCount จะเป็นขนาดของ FIFO หากมีการแบ่งปัน FIFO กับเซ็นเซอร์หลายตัว ค่านี้อาจเป็นศูนย์ กรณีการใช้งานทั่วไปคือการอนุญาตให้เซ็นเซอร์ใช้ FIFO ทั้งหมด หากเป็นเซ็นเซอร์ที่ทำงานอยู่เพียงตัวเดียว หากมีการใช้งานเซ็นเซอร์หลายตัว เซ็นเซอร์แต่ละตัวจะรับประกันพื้นที่สำหรับเหตุการณ์ SensorInfo.fifoReservedEventCount เป็นอย่างน้อยใน FIFO หากใช้ฮับเซ็นเซอร์ การรับประกันอาจบังคับใช้ผ่านซอฟต์แวร์

เหตุการณ์เซ็นเซอร์จะรวมกันเป็นชุดในสถานการณ์ต่อไปนี้:

  • เวลาแฝงในการรายงานสูงสุดของเซ็นเซอร์ในปัจจุบันมีค่ามากกว่าศูนย์ ซึ่งหมายความว่าเหตุการณ์ของเซ็นเซอร์สามารถหน่วงเวลาได้จนถึงเวลาแฝงของรายงานสูงสุดก่อนที่จะรายงานผ่าน HAL
  • AP อยู่ในโหมด Suspend และเซ็นเซอร์เป็นเซ็นเซอร์แบบไม่ปลุก ในกรณีนี้ เหตุการณ์จะต้องไม่ปลุก AP และต้องเก็บไว้จนกว่า AP จะกลับมาทำงาน

หากเซ็นเซอร์ไม่รองรับการแบทช์และ AP อยู่ในโหมดสลีป เฉพาะเหตุการณ์เซ็นเซอร์การปลุกเท่านั้นที่จะถูกรายงานไปยัง AP และเหตุการณ์ที่ไม่ตื่นจะต้องไม่ถูกรายงานไปยัง AP

พารามิเตอร์การแบทช์

พารามิเตอร์สองตัวที่ควบคุมลักษณะการทำงานของการแบทช์คือ sampling_ period_ns และ max_report_latency_ns sampling_period_ns กำหนดความถี่ในการสร้างเหตุการณ์เซ็นเซอร์ใหม่ และ max_report_latency_ns กำหนดระยะเวลาที่ต้องรายงานเหตุการณ์ไปยังเซ็นเซอร์ HAL

การสุ่มตัวอย่าง_ช่วงเวลา_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 ไม่รองรับการสร้างเหตุการณ์ที่ความถี่มากกว่า 1,000 Hz
  • หาก sampling_period_ns มากกว่า SensorInfo.maxDelay ดังนั้นการใช้งาน HAL จะต้องตัดทอนเป็น SensorInfo.maxDelay โดยไม่แจ้งให้ทราบ

เซ็นเซอร์ทางกายภาพบางครั้งมีข้อจำกัดเกี่ยวกับอัตราการวิ่งและความแม่นยำของนาฬิกา เพื่อคำนึงถึงเรื่องนี้ ความถี่ในการสุ่มตัวอย่างจริงอาจแตกต่างจากความถี่ที่ร้องขอตราบใดที่เป็นไปตามข้อกำหนดในตารางด้านล่าง

หากความถี่ที่ร้องขอคือ

จากนั้นความถี่ที่แท้จริงจะต้องเป็น

ต่ำกว่าความถี่ขั้นต่ำ (<1/maxDelay)

ระหว่าง 90% ถึง 110% ของความถี่ขั้นต่ำ

ระหว่างความถี่ต่ำสุดและสูงสุด

ระหว่าง 90% ถึง 220% ของความถี่ที่ร้องขอ

เหนือความถี่สูงสุด (>1/นาทีดีเลย์)

ระหว่าง 90% ถึง 110% ของความถี่สูงสุด และต่ำกว่า 1100 Hz

max_report_latency_ns

max_report_latency_ns ตั้งเวลาสูงสุดเป็นนาโนวินาที ซึ่งสามารถหน่วงเวลาเหตุการณ์และจัดเก็บไว้ในฮาร์ดแวร์ FIFO ก่อนที่จะรายงานผ่าน HAL ขณะที่ AP ตื่นอยู่

ค่าศูนย์หมายความว่าจะต้องรายงานเหตุการณ์ทันทีที่มีการวัด โดยจะข้าม FIFO ไปเลย หรือล้าง FIFO ทันทีที่มีเหตุการณ์หนึ่งจากเซ็นเซอร์ปรากฏ

ตัวอย่างเช่น มาตรความเร่งที่ทำงานที่ 50 Hz โดยมี max_report_latency_ns=0 จะทำให้เกิดการขัดจังหวะ 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

พฤติกรรมนอกโหมด Suspend

เมื่อ AP ตื่นตัว (ไม่อยู่ในโหมด Suspend) กิจกรรมจะถูกจัดเก็บชั่วคราวใน FIFO ตราบใดที่เหตุการณ์ไม่ล่าช้าเกินกว่า max_report_latency

ตราบใดที่ AP ไม่เข้าสู่โหมด Suspend ก็จะไม่มีเหตุการณ์ใดหลุดหรือสูญหาย หาก FIFO ภายในเต็มก่อนที่ max_report_latency จะผ่านไป ระบบจะรายงานเหตุการณ์ ณ จุดนั้นเพื่อให้แน่ใจว่าไม่มีเหตุการณ์ใดสูญหาย

หากเซ็นเซอร์หลายตัวใช้ FIFO เดียวกันและค่า max_report_latency ของเซ็นเซอร์ตัวใดตัวหนึ่งผ่านไป เหตุการณ์ทั้งหมดจาก FIFO จะถูกรายงาน แม้ว่าค่า max_report_latency ของเซ็นเซอร์ตัวอื่นจะยังไม่ผ่านไปก็ตาม ซึ่งจะช่วยลดจำนวนครั้งที่รายงานเหตุการณ์เป็นชุด เมื่อต้องรายงานเหตุการณ์หนึ่ง เหตุการณ์ทั้งหมดจากเซ็นเซอร์ทั้งหมดจะถูกรายงาน

ตัวอย่างเช่น หากเซ็นเซอร์ต่อไปนี้ทำงานอยู่:

  • มาตรความเร่งที่แบทช์กับ max_report_latency = 20 วินาที
  • ไจโรสโคปแบทช์กับ max_report_latency = 5s

ชุดมาตรความเร่งจะถูกรายงานในเวลาเดียวกันกับที่ชุดไจโรสโคปจะถูกรายงาน (ทุกๆ 5 วินาที) แม้ว่ามาตรความเร่งและไจโรสโคปจะไม่แชร์ FIFO เดียวกันก็ตาม

พฤติกรรมในโหมดระงับ

การรวมกลุ่มมีประโยชน์อย่างยิ่งในการรวบรวมข้อมูลเซ็นเซอร์ในเบื้องหลังโดยไม่ทำให้ AP ตื่นตัว เนื่องจากไดรเวอร์เซ็นเซอร์และการใช้งาน HAL ไม่ได้รับอนุญาตให้ระงับการปลุก* AP จึงสามารถเข้าสู่โหมด Suspend ได้แม้ในขณะที่กำลังรวบรวมข้อมูลเซ็นเซอร์ก็ตาม

พฤติกรรมของเซ็นเซอร์ในขณะที่ AP ถูกระงับนั้นขึ้นอยู่กับว่าเซ็นเซอร์นั้นเป็นเซ็นเซอร์ปลุกหรือไม่ สำหรับรายละเอียดเพิ่มเติม โปรดดูที่ เซ็นเซอร์ปลุก

เมื่อ FIFO ที่ไม่ตื่นเต็ม จะต้องพันรอบและทำงานเหมือนบัฟเฟอร์แบบวงกลม โดยเขียนทับเหตุการณ์เก่าด้วยเหตุการณ์ใหม่แทนที่เหตุการณ์เก่า max_report_latency ไม่มีผลกระทบต่อ FIFO ที่ไม่ปลุกขณะอยู่ในโหมด Suspend

เมื่อ FIFO การปลุกเต็ม หรือเมื่อ max_report_latency ของเซ็นเซอร์ปลุกตัวใดตัวหนึ่งผ่านไป ฮาร์ดแวร์จะต้องปลุก AP และรายงานข้อมูล

ในทั้งสองกรณี (การปลุกและไม่ปลุก) ทันทีที่ AP ออกจากโหมด Suspend จะมีการสร้างแบตช์ด้วยเนื้อหาของ FIFO ทั้งหมด แม้ว่า max_report_latency ของเซ็นเซอร์บางตัวจะยังไม่ผ่านพ้นไปก็ตาม ซึ่งช่วยลดความเสี่ยงที่ AP จะต้องปลุกอีกครั้งทันทีหลังจากกลับสู่โหมด Suspend ดังนั้นจึงช่วยลดการใช้พลังงานให้เหลือน้อยที่สุด

*ข้อยกเว้นที่น่าสังเกตอย่างหนึ่งของไดรเวอร์ที่ไม่ได้รับอนุญาตให้ระงับการปลุกระบบคือเมื่อเซ็นเซอร์ปลุกพร้อม โหมดการรายงานต่อเนื่อง ถูกเปิดใช้งานด้วย max_report_latency < 1 วินาที ในกรณีนี้ ผู้ขับขี่สามารถระงับการทำงานขณะล็อกได้ เนื่องจาก AP ไม่มีเวลาเข้าสู่โหมด Suspend เนื่องจากจะถูกปลุกโดยเหตุการณ์ปลุกก่อนที่จะเข้าสู่โหมด Suspend

ข้อควรระวังในการแบทช์เซ็นเซอร์ปลุก

อาจใช้เวลาสองสามมิลลิวินาทีก่อนที่ AP จะออกจากโหมด Suspend โดยสมบูรณ์และเริ่มล้าง FIFO ทั้งนี้ขึ้นอยู่กับอุปกรณ์ ต้องจัดสรรพื้นที่ส่วนหัวให้เพียงพอใน FIFO เพื่อให้อุปกรณ์ออกจากโหมด Suspend โดยที่ FIFO การปลุกเครื่องไม่ล้น จะไม่มีเหตุการณ์ใดสูญหาย และจะต้องปฏิบัติตามค่า max_report_latency

ข้อควรระวังเมื่อทำการแบทช์เซ็นเซอร์เมื่อเปลี่ยนแบบไม่ปลุก

เซ็นเซอร์ขณะเปลี่ยนจะสร้างเหตุการณ์เฉพาะเมื่อค่าที่วัดมีการเปลี่ยนแปลงเท่านั้น หากค่าที่วัดได้เปลี่ยนแปลงในขณะที่ AP อยู่ในโหมด Suspend แอปพลิเคชันคาดว่าจะได้รับเหตุการณ์ทันทีที่ AP เริ่มทำงาน ด้วยเหตุนี้ การจัดชุดเหตุการณ์เซ็นเซอร์ เมื่อไม่ปลุกระบบ จะต้องดำเนินการอย่างระมัดระวัง หากเซ็นเซอร์แชร์ FIFO ของตนกับเซ็นเซอร์อื่นๆ เหตุการณ์สุดท้ายที่สร้างโดยเซ็นเซอร์การเปลี่ยนแปลงแต่ละตัวจะต้องถูกบันทึกไว้ภายนอก FIFO ที่ใช้ร่วมกันเสมอ เพื่อไม่ให้เหตุการณ์อื่นเขียนทับได้ เมื่อ AP ตื่นขึ้น หลังจากที่มีการรายงานเหตุการณ์ทั้งหมดจาก FIFO แล้ว จะต้องรายงานเหตุการณ์เซ็นเซอร์การเปลี่ยนแปลงครั้งล่าสุด

นี่คือสถานการณ์ที่ควรหลีกเลี่ยง:

  1. แอปพลิเคชันลงทะเบียนกับตัวนับก้าวที่ไม่ปลุก (เมื่อเปลี่ยน) และมาตรความเร่งที่ไม่ปลุก (ต่อเนื่อง) ทั้งสองใช้ FIFO เดียวกัน
  2. แอปพลิเคชันได้รับเหตุการณ์ตัวนับขั้นตอน step_count=1000 steps >
  3. AP ไประงับ
  4. ผู้ใช้เดิน 20 ก้าว ส่งผลให้เหตุการณ์ตัวนับก้าวและตัววัดความเร่งถูกสลับกัน โดยเหตุการณ์ตัวนับก้าวสุดท้ายคือ step_count = 1020 steps
  5. ผู้ใช้ไม่เคลื่อนไหวเป็นเวลานาน ส่งผลให้เหตุการณ์ตัวตรวจวัดความเร่งสะสมต่อไปใน FIFO และเขียนทับทุกเหตุการณ์ step_count ใน FIFO ที่ใช้ร่วมกันในที่สุด
  6. AP ตื่นขึ้น และกิจกรรมทั้งหมดจาก FIFO จะถูกส่งไปยังแอปพลิเคชัน
  7. แอปพลิเคชันรับเฉพาะเหตุการณ์มาตรวัดความเร่งและคิดว่าผู้ใช้ไม่ได้เดิน

ด้วยการบันทึกเหตุการณ์ตัวนับขั้นตอนสุดท้ายไว้นอก FIFO ทำให้ HAL สามารถรายงานเหตุการณ์นี้เมื่อ AP เริ่มทำงาน แม้ว่าเหตุการณ์ตัวนับขั้นตอนอื่นๆ ทั้งหมดจะถูกเขียนทับโดยเหตุการณ์ตัวตรวจวัดความเร่งก็ตาม ด้วยวิธีนี้ แอปพลิเคชันจะได้รับ step_count = 1020 steps เมื่อ AP เริ่มทำงาน

ดำเนินการแบทช์

เพื่อประหยัดพลังงาน จะต้องดำเนินการแบทช์โดยไม่ได้รับความช่วยเหลือจาก AP และต้องอนุญาตให้ AP ระงับในระหว่างการแบทช์

หากดำเนินการแบทช์ในฮับเซ็นเซอร์ ควรลดการใช้พลังงานของฮับเซ็นเซอร์ให้เหลือน้อยที่สุด

คุณสามารถแก้ไขเวลาแฝงของรายงานสูงสุดได้ตลอดเวลา โดยเฉพาะอย่างยิ่งในขณะที่เซ็นเซอร์ที่ระบุเปิดใช้งานอยู่แล้ว และไม่น่าจะส่งผลให้สูญเสียเหตุการณ์

ลำดับความสำคัญของการจัดสรร FIFO

บนแพลตฟอร์มที่ฮาร์ดแวร์ FIFO และ/หรือขนาดบัฟเฟอร์ฮับเซ็นเซอร์ถูกจำกัด ผู้ออกแบบระบบอาจต้องเลือกจำนวน FIFO ที่จะสำรองไว้สำหรับเซ็นเซอร์แต่ละตัว เพื่อช่วยในการเลือกนี้ ต่อไปนี้คือรายการการใช้งานที่เป็นไปได้เมื่อมีการใช้การจัดชุดกับเซ็นเซอร์ต่างๆ

มูลค่าสูง: การคำนวณการเสียชีวิตของคนเดินเท้าที่ใช้พลังงานต่ำ

เวลาแบทช์เป้าหมาย: 1 ถึง 10 นาที

เซ็นเซอร์เป็นแบทช์:

  • เครื่องตรวจจับขั้นตอนการปลุก
  • เวกเตอร์การหมุนเกม Wake-up ที่ 5 Hz
  • บารอมิเตอร์ปลุกที่ 5 Hz
  • แม็กนีโตมิเตอร์ที่ไม่ได้ปรับเทียบ Wake-up ที่ 5 Hz

การรวมข้อมูลนี้เข้าด้วยกันทำให้สามารถคำนวณการเสียชีวิตของคนเดินเท้าได้ในขณะที่ปล่อยให้ AP หยุดการทำงานชั่วคราว

ค่าสูง: กิจกรรม/การจดจำท่าทางที่ใช้กำลังปานกลาง

เวลาแบทช์เป้าหมาย: 3 วินาที

เซ็นเซอร์เป็นแบทช์: มาตรความเร่งแบบไม่ปลุกที่ 50 Hz

การแบทช์ข้อมูลนี้ทำให้สามารถรับรู้กิจกรรมและท่าทางตามอำเภอใจเป็นระยะๆ โดยไม่ต้องให้ AP ตื่นตัวในขณะที่รวบรวมข้อมูล

ค่าปานกลาง: กิจกรรมต่อเนื่อง/การจดจำท่าทางด้วยกำลังปานกลาง

เวลาแบทช์เป้าหมาย: 1 ถึง 3 นาที

เซ็นเซอร์เป็นแบทช์: มาตรความเร่งปลุกที่ 50 Hz

การแบทช์ข้อมูลนี้ช่วยให้สามารถรับรู้กิจกรรมและท่าทางตามอำเภอใจได้อย่างต่อเนื่อง โดยไม่ต้องให้ AP ตื่นตัวในขณะที่รวบรวมข้อมูล

ค่าปานกลาง-สูง: การลดโหลดขัดจังหวะ

เวลาแบทช์เป้าหมาย: < 1 วินาที

เซ็นเซอร์เป็นแบตช์: เซ็นเซอร์ความถี่สูงใดๆ มักจะไม่ตื่น

หากตั้งค่าไจโรสโคปไว้ที่ 240 Hz แม้แต่การรวมเหตุการณ์ไจโรเพียง 10 เหตุการณ์ก็สามารถลดจำนวนการขัดจังหวะจาก 240/วินาที เหลือ 24/วินาที

ค่าปานกลาง: การรวบรวมข้อมูลความถี่ต่ำอย่างต่อเนื่อง

เวลาแบทช์เป้าหมาย: 1 ถึง 10 นาที

เซ็นเซอร์เป็นแบทช์:

  • บารอมิเตอร์ปลุกที่ 1 Hz
  • เซ็นเซอร์ความชื้นปลุกที่ 1 Hz
  • เซ็นเซอร์ปลุกความถี่ต่ำอื่นๆ ในอัตราที่ใกล้เคียงกัน

อนุญาตให้สร้างแอปพลิเคชันการตรวจสอบที่ใช้พลังงานต่ำ

ค่าปานกลาง-ต่ำ: การรวบรวมเซ็นเซอร์เต็มรูปแบบอย่างต่อเนื่อง

เวลาแบทช์เป้าหมาย: 1 ถึง 10 นาที

เซ็นเซอร์เป็นชุด: เซ็นเซอร์ปลุกทั้งหมด ที่ความถี่สูง

อนุญาตให้รวบรวมข้อมูลเซ็นเซอร์ได้เต็มรูปแบบในขณะที่ออกจาก AP ในโหมด Suspend พิจารณาเฉพาะในกรณีที่พื้นที่ FIFO ไม่ใช่ปัญหา