แบทช์คืออะไร?
การรวมกลุ่มหมายถึงการบัฟเฟอร์เหตุการณ์เซ็นเซอร์ในฮับเซ็นเซอร์และ/หรือฮาร์ดแวร์ 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 แล้ว จะต้องรายงานเหตุการณ์เซ็นเซอร์การเปลี่ยนแปลงครั้งล่าสุด
นี่คือสถานการณ์ที่ควรหลีกเลี่ยง:
- แอปพลิเคชันลงทะเบียนกับตัวนับก้าวที่ไม่ปลุก (เมื่อเปลี่ยน) และมาตรความเร่งที่ไม่ปลุก (ต่อเนื่อง) ทั้งสองใช้ FIFO เดียวกัน
- แอปพลิเคชันได้รับเหตุการณ์ตัวนับขั้นตอน
step_count=1000 steps
> - AP ไประงับ
- ผู้ใช้เดิน 20 ก้าว ส่งผลให้เหตุการณ์ตัวนับก้าวและตัววัดความเร่งถูกสลับกัน โดยเหตุการณ์ตัวนับก้าวสุดท้ายคือ
step_count = 1020 steps
- ผู้ใช้ไม่เคลื่อนไหวเป็นเวลานาน ส่งผลให้เหตุการณ์ตัวตรวจวัดความเร่งสะสมต่อไปใน FIFO และเขียนทับทุกเหตุการณ์
step_count
ใน FIFO ที่ใช้ร่วมกันในที่สุด - AP ตื่นขึ้น และกิจกรรมทั้งหมดจาก FIFO จะถูกส่งไปยังแอปพลิเคชัน
- แอปพลิเคชันรับเฉพาะเหตุการณ์มาตรวัดความเร่งและคิดว่าผู้ใช้ไม่ได้เดิน
ด้วยการบันทึกเหตุการณ์ตัวนับขั้นตอนสุดท้ายไว้นอก 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 ไม่ใช่ปัญหา