บทเรียน 3.4 — สุ่มสัญญาณให้ถูก: Nyquist aliasing และ ring buffer

บทเรียน 3.1–3.3 เราอ่าน sensors.bmi270.motion() → dsp.tilt(ax, ay, az) → (roll, pitch) → ui.Bar บน ui.Scale สองแกน + ui.Seg7

สิ่งที่แถบกับ Seg7 ทำได้ดี: บอก ค่าปัจจุบัน ชัดเจน · สิ่งที่ทำไม่ได้เลย: บอกว่า เมื่อกี้เป็นยังไง

ภาพขวาคือสัญญาณ accel จริงตอนคนเดิน 10 ก้าว — ยอดที่ทำเครื่องหมายสีแดงคือก้าว ข้อมูลชุดนี้อ่านจากแถบหรือตัวเลขไม่ได้เลย ต้องเห็นเป็นเส้นเวลาเท่านั้น

Time series คือข้อมูลชุดหนึ่งที่ แต่ละค่ามีเวลากำกับ และเรียงตามเวลา

เซนเซอร์ให้สัญญาณต่อเนื่องซึ่งมีค่าอยู่ทุกเสี้ยววินาที แต่คอมพิวเตอร์เก็บค่าต่อเนื่องไม่ได้ มันทำได้อย่างเดียวคือ แอบมองเป็นระยะ ๆ แล้วจดค่าไว้ — เรียกว่า การสุ่มตัวอย่าง (sampling)

$$f_s=\frac{1}{T_s}$$

ไทย: อัตราสุ่มคือส่วนกลับของระยะห่างระหว่างการมองสองครั้ง
ตัวเลขของลูปเรา: $T_s = 200$ ms $\Rightarrow f_s = 5$ Hz

วงจร sample-and-hold (ภาพขวาบน) คือฮาร์ดแวร์ที่ทำเรื่องนี้จริง ๆ ในชิป: ปิดสวิตช์ชั่วขณะเพื่อชาร์จตัวเก็บประจุ แล้วเปิดสวิตช์ค้างค่านั้นไว้ให้ ADC อ่านทัน — เอาต์พุตจึงเป็นขั้นบันได ไม่ใช่เส้นโค้ง

กราฟบนจอไม่ใช่สัญญาณจริง มันคือ จุดที่เราจดไว้ แล้วลากเส้นตรงเชื่อมกัน ระหว่างจุดสองจุดเกิดอะไรขึ้นบ้าง เราไม่มีทางรู้จากกราฟนี้เลย

ปี 1928 แฮร์รี ไนควิสต์ พิสูจน์ไว้ว่า ถ้าจะเก็บสัญญาณที่มีความถี่สูงสุด $f_{\max}$ ให้ครบ ต้องสุ่มเร็วกว่าสองเท่าของมัน

$$f_s > 2 f_{\max}\qquad\Longleftrightarrow\qquad f_{\max} < \frac{f_s}{2}$$

ไทย: จะเห็นคลื่นความถี่หนึ่งได้ ต้องสุ่มเร็วกว่าสองเท่าของคลื่นนั้น
ตัวเลขของลูปเรา: $f_s = 5$ Hz $\Rightarrow$ เห็นการสั่นได้ไม่เกิน 2.5 Hz

การเขย่ามือของคนอยู่ราว 2-5 Hz เราจึงเห็นเฉพาะส่วนที่ช้ากว่า 2.5 Hz ส่วนที่เร็วกว่านั้นจะปลอมตัวเป็นคลื่นช้า (สไลด์ถัดไป) · อัตราสุ่มของเราไม่ได้ตั้งด้วยฮาร์ดแวร์ แต่เกิดจากความเร็วลูป Python

$$f_s = \frac{1}{T_{\text{loop}}},\qquad T_{\text{loop}} = T_{\text{sleep}} + T_{\text{work}}$$

ไทย: งานในลูปหนักขึ้น อัตราสุ่มตกลงเงียบ ๆ — จึงต้องวัดคาบลูปจริง (ท่าที่ 5)

$$f_{\text{alias}} = \bigl|\,f - k f_s\,\bigr|,\qquad k = \text{จำนวนเต็มที่ทำให้ } f_{\text{alias}} \le \tfrac{f_s}{2}$$

ไทย: ถ้าสัญญาณเร็วเกินไป มันจะไม่หายไปเฉย ๆ แต่จะ ปลอมตัว มาเป็นคลื่นช้ากว่าความจริง ซึ่งอันตรายกว่าการมองไม่เห็น

ตัวเลขจากบอร์ดนี้ — เดโมที่ทำได้ในบทเรียน: เขย่าบอร์ดที่ราว 6 Hz ขณะลูปสุ่มที่ $f_s = 5$ Hz

$$f_{\text{alias}} = |6 - 1\times 5| = 1\ \text{Hz}$$

กราฟจะโชว์คลื่นช้า ๆ 1 Hz ที่ ไม่มีอยู่จริง ทั้งที่มือเราเขย่าอยู่ 6 ครั้งต่อวินาที

นี่คือเหตุผลเดียวกับที่ล้อรถในหนังบางทีดูเหมือนหมุนถอยหลัง — กล้องคือ ADC ที่สุ่มที่ 24 เฟรมต่อวินาที

เจอตอนไหน ค่าที่เร็วเกินอัตราสุ่มไม่มี error ไม่มีคำเตือน มันแค่ให้คำตอบที่ผิด และดูน่าเชื่อถือด้วย

Chart เก็บค่าเป็น จำนวนเต็ม เท่านั้น แต่ motion() คืนทศนิยม เช่น 9.78

chart.set_next(0, int(ax))       # ถูก
chart.set_next(0, ax)            # TypeError: can't convert float to int

ราคาที่ต้องจ่ายคือ int() ตัดทศนิยมทิ้ง ไม่ใช่ปัดเศษ — 0.9 เป็น 0 และ −0.9 ก็เป็น 0 กราฟจึงหยาบเป็นขั้นละ 1 m/s² นี่คือ quantization ตัวเดียวกับบทเรียน 2.7–2.9 แค่คราวนี้เราเป็นคนสร้างเอง

สูตร map ช่วงจริงลงช่วงแกน — วิธีแก้ที่ใช้ในงานจริง

$$v_{\text{plot}} = \operatorname{round}\!\left(\frac{a - a_{\min}}{a_{\max} - a_{\min}}\times\bigl(y_{\max} - y_{\min}\bigr) + y_{\min}\right)$$

ไทย: แกน Y ของ Chart เป็นจำนวนเต็ม ต้อง map ช่วงค่าจริงลงช่วงแกนก่อน ไม่งั้นกราฟแบนหรือทะลุขอบ

chart = ui.Chart(..., min=-2000, max=2000)   # หน่วยกลายเป็น 0.01 m/s²
chart.set_next(0, int(ax * 100))             # 9.78 -> 978

ตัวเลขจากบอร์ดนี้: ช่วง ±20 กับ int() ตรง ๆ ได้ความละเอียด 1 m/s² · คูณ 100 แล้วขยายช่วงเป็น ±2000 ได้ 0.01 m/s² — ละเอียดขึ้น 100 เท่าโดยไม่แตะเซนเซอร์เลย

โค้ด Python อยู่บน CM33 กราฟถูกวาดโดย CM55 chart.set_next() ไม่ได้วาดทันที มันแค่ ฝากคำสั่งลงคิว IPC แล้วกลับมาทำงานต่อ

ฝั่ง CM55 มีตัวจับเวลาคอยหยิบคำสั่งจากคิวมาทำ และมันมี สองความเร็ว

$$\text{อัตราระบาย} = \frac{N_{\text{ต่อครั้ง}}}{T_{\text{timer}}} = \frac{16}{0.2} = 80 \quad\text{เทียบกับ}\quad \frac{16}{0.005} = 3{,}200$$

และนี่คือกับดัก — คำสั่งที่ ปลุกโหมดเร่ง มีอยู่ชุดหนึ่ง คำสั่งที่ ไม่ปลุก ก็มีอีกชุด

โหมดเร่งจะกลับเป็นปกติเองหลังเงียบไป 500 ms

รู้กลไกแล้ว ทางแก้เหลือบรรทัดเดียว — ให้ทุกลูปมีคำสั่งที่ปลุกโหมดเร่งอย่างน้อยหนึ่งคำสั่ง และตัวที่เป็นธรรมชาติที่สุดคือป้ายสถานะที่เราอยากเห็นอยู่แล้ว

rec_msg = "กำลังบันทึก"     # เปลี่ยนเฉพาะตอนกดปุ่ม
while True:
    ax, ay, az, gx, gy, gz = sensors.bmi270.motion()
    chart.set_next(0, int(ax))          # ไม่ปลุกโหมดเร่ง
    chart.set_next(s_ay, int(ay))       # ไม่ปลุก
    chart.set_next(s_az, int(az))       # ไม่ปลุก
    led_rec.value(1)                    # ไม่ปลุก - .value() ทุกตัวไม่ปลุก
    lbl_rec.text(rec_msg)               # ← ปลุก และค้างไว้อีก 500 ms
    ui.poll()
    time.sleep_ms(PERIOD_MS)

ทำไมมันได้ผลกับลูป 200 ms ของเรา — โหมดเร่งค้างอยู่ 500 ms หลังคำสั่งสุดท้าย ลูปเราหมุนทุก 200 ms ซึ่งสั้นกว่า 500 ms ตัวจับเวลาจึงไม่มีโอกาสกลับเป็นโหมดปกติเลยตลอดการรัน

กฎนี้ชนกับกฎ "ตัวเลขเปลี่ยนไม่เกินวินาทีละครั้ง" พอดี และทางออกอยู่ตรงกลาง: ส่ง .text() ทุกรอบ แต่ส่ง ข้อความเดิม เฉลยของชุดบทเรียนนี้จึงเก็บข้อความสถานะไว้ในตัวแปร rec_msg ซึ่งเปลี่ยนเฉพาะตอนกดปุ่ม แล้วส่งซ้ำทุกรอบ · เฟิร์มแวร์เทียบข้อความเก่ากับใหม่ก่อนวาด ถ้าเท่าเดิมมันไม่วาดซ้ำ เราจึงจ่ายแค่ค่าส่งข้ามคอร์ ไม่ได้จ่ายค่าวาด และไม่มีตัวเลขไหนบนจอวิ่งเร็วกว่าที่คนอ่านทัน

คำสั่งที่ปลุกโหมดเร่งได้มีสี่กลุ่ม คือสร้าง widget · .text() · .pos() / .size() / .color() · และคำสั่งของ collection อย่าง .cell() .add_row() .prop() — ส่วน .value() ทั้งหมด ไม่ว่าจะเป็นแถบ ไฟ หรือ set_next() ของกราฟ ไม่ปลุก (ตรวจจาก ipc_ui.c โดยตรง)

อย่าตีความเกินกว่านี้ — โหมดเร่งไม่ได้ทำให้เซนเซอร์อ่านเร็วขึ้น และไม่ได้ทำให้ลูป Python เร็วขึ้น มันแค่ทำให้ คำสั่งที่เราส่งไปแล้ว ถูกวาดออกจอเร็วขึ้น