ไมโครโฟนแบบ Phased Array (2023)

 (benwang.dev)
1 คะแนน โดย GN⁺ 2024-11-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ไมโครโฟนแบบ phased array 192 แชนเนลสามารถเปลี่ยนทิศทางการรับเสียงได้แม้หลังบันทึกแล้ว หรือโฟกัสพร้อมกันได้ที่จุดนับแสน ทำให้ระบุตำแหน่งแหล่งกำเนิดเสียงและแสดงผลเป็นภาพได้ ซึ่งไมโครโฟนแบบมีทิศทางทั่วไปทำได้ยาก
  • ฮาร์ดแวร์ประกอบด้วยแขนไมโครโฟนแบบรัศมีและฮับกลาง ใช้ไมโครโฟน MEMS 192 ตัว, การ์ด FPGA Colorlight i5 และโครงสร้างส่งข้อมูลผ่าน Gigabit Ethernet ด้วยต้นทุนประมาณ $700
  • FPGA เน้น การส่งข้อมูล PDM ดิบ มากกว่าการประมวลผลล่วงหน้าที่ซับซ้อน โดยประมวลผลอินพุต 3.125MHz และใช้แบนด์วิดท์ Gigabit Ethernet ประมาณ 70% ที่ราว 715Mbps
  • ซอฟต์แวร์ผสาน CIC filter, การปรับเทียบด้วย FFT, การปรับแต่งให้เหมาะกับ GPU และ beamforming ด้วย Triton เพื่อ แสดงภาพแบบเรียลไทม์ ของตำแหน่งแหล่งกำเนิดเสียงทั้งระยะใกล้แบบ 3D และระยะไกลแบบ 2D
  • แพ็กเก็ต UDP สามารถจับด้วย tcpdump แล้วนำมาเล่นซ้ำได้ แต่การจัดเก็บข้อมูลดิบมีอัตราสูงถึง 87.5MB/s ทำให้การบันทึก 1 ชั่วโมงต้องใช้พื้นที่ 315GB

การประกอบไมโครโฟน phased array 192 แชนเนล

  • ผสาน ไมโครโฟนแบบ phased array 192 แชนเนล เข้ากับการเก็บข้อมูลด้วย FPGA และการทำ beamforming/visualization บน GPU
  • ต่างจากไมโครโฟนแบบมีทิศทางทั่วไป phased array สามารถเปลี่ยนทิศทางการรับเสียงได้แม้หลังบันทึกแล้ว และสามารถโฟกัสพร้อมกันที่จุดนับแสนแบบเรียลไทม์ได้
  • งานออกแบบทั้งหมดเผยแพร่เป็น โอเพนซอร์ส

การออกแบบฮาร์ดแวร์

  • โครงสร้างอาร์เรย์และต้นทุน

    • สร้าง phased array โดยวางไมโครโฟนจำนวนมากด้วยการกระจายระยะห่างที่กว้าง
    • ในอาร์เรย์เชิงเส้น เป็นที่ทราบกันว่า ระยะห่างแบบเลขชี้กำลัง ระหว่างไมโครโฟนเหมาะสมที่สุดสำหรับสัญญาณแถบกว้าง
    • อาร์เรย์ 2D จัดวางแขนอาร์เรย์เชิงเส้นแบบสมมาตรเป็นแนวรัศมี เพื่อให้บอร์ดฮับกลางมีขนาดเล็ก
    • ต้นทุนอาร์เรย์ทั้งหมดประมาณ $700

  • บอร์ดแขน

    • ความยาวของแต่ละแขนถูกกำหนดให้สอดคล้องกับข้อจำกัดด้านการผลิตและประกอบ PCB โดยความยาวสูงสุดสำหรับการผลิต/ประกอบ PCB 4 ชั้นของ JLCPCB คือ 570mm
    • ใช้ไมโครโฟน MEMS เอาต์พุตดิจิทัลราคาถูก ราคาประมาณ $0.5 ต่อตัว
      • ในช่วงราคานี้ ประสิทธิภาพระหว่างไมโครโฟนไม่แตกต่างกันมาก
      • ส่วนใหญ่ให้ประสิทธิภาพใช้ได้ถึง 10kHz แต่ไม่ได้ระบุ phase delay และการแมตช์ระดับเสียง
    • ไมโครโฟนส่งข้อมูลด้วยรูปแบบ PDM(pulse density modulation)
      • ให้เอาต์พุต 1 บิตที่ความถี่สูงสุด 4MHz ซึ่งสูงกว่าช่วงที่ได้ยินมาก
      • ชดเชย quantization noise ด้วยอัตราสุ่มตัวอย่างที่สูง
      • รองรับ DDR ที่ latch ข้อมูลบนขอบขาขึ้นและขาลงของสัญญาณนาฬิกา จึง multiplex ไมโครโฟนสองตัวบนสายเดียวได้
    • แต่ละแขนมีไมโครโฟน 8 ตัวและสายเอาต์พุต 4 เส้น โดยมี output buffer บนสายอินพุต clock
    • ออกแบบให้ rise time ยังอยู่ในระดับสมเหตุสมผล แม้ไมโครโฟนหลายร้อยตัวใช้สัญญาณ clock เดียวกัน
    • yield ของ PCB แขนไม่ดีนัก และบอร์ดที่ทำงานได้ตั้งแต่ต้นมีประมาณ 50%
      • ความเสียหายที่พบบ่อยที่สุดคือสาย clock ลัดวงจรไปยัง 3V3 หรือ GND
      • การแก้ short ต้องทดลองถอดไมโครโฟนทีละตัว
      • ไมโครโฟนบางตัวยังส่งข้อมูลผิดหลัง rework แล้ว และโค้ดจะ mask ไมโครโฟนเหล่านั้นออก
    • ในการออกแบบถัดไป สามารถลดงาน rework ได้ด้วยตัวต้านทานอนุกรมบนสาย clock, การปรับปรุง panelization และการปรับปรุง solder paste stencil

  • บอร์ดฮับ

    • การเก็บข้อมูลใช้ FPGA ซึ่งต้องการ I/O latency ต่ำจำนวนมากและอินเทอร์เฟซความเร็วสูงอย่าง Gigabit Ethernet
    • เลือกใช้การ์ด Colorlight i5
      • เหตุผลคือมี I/O เพียงพอ ราคาต่ำ หาได้ง่าย และมี Ethernet PHY ในตัว 2 ตัว
      • ในโปรเจกต์นี้ใช้ Ethernet PHY เพียงตัวเดียว
    • เดิมการ์ดนี้เป็นอินเทอร์เฟซ Ethernet สำหรับแผง LED แต่ถูก reverse engineer อย่างสมบูรณ์ แล้ว
    • GPIO ประมาณ 100 ขาถูกนำออกมาผ่านคอนเนกเตอร์ DDR2 ทำให้ fan-out ง่ายกว่า BGA ของ FPGA เดิม
    • นอกจาก FPGA แล้ว ฮับยังมีวงจรจัดการพลังงานแบบง่าย คอนเนกเตอร์สำหรับบอร์ดแขน และคอนเนกเตอร์ Ethernet ที่มี magnetics ในตัว

  • การออกแบบเชิงกล

    • แขนยึดกับฮับด้วย PCB mounting standoff/nut และสกรู M3
    • การเชื่อมต่อระหว่างแขนกับฮับทำผ่าน คอนเนกเตอร์ 8 พิน pitch 2mm
    • แบบแรกใช้สล็อตบน PCB แขนเข้ากับ PCB โครงสร้างตามแนวเส้นรอบวง แต่แขนมีความแข็งต่อการบิดต่ำ ทำให้โครงสร้างทั้งหมดเสียรูปได้ง่าย
    • แบบสุดท้ายวางชิ้น MDF หนา 1/4 นิ้ว ที่ตัดด้วยเลเซอร์ไว้รอบนอกอาร์เรย์ แล้วรัดแขนแต่ละข้างกับ MDF ด้วย cable tie
    • อาร์เรย์ไมโครโฟนติดตั้งบนผนังจึงไวต่อเสียงสะท้อน จึงลดเสียงสะท้อนด้วย โฟมดูดซับเสียง เพื่อให้ปรับเทียบได้ง่ายขึ้น

FPGA gateware

  • เป้าหมายการออกแบบ

    • เป้าหมายหลักของ gateware คือส่งข้อมูลดิบที่เก็บได้ไปยังคอมพิวเตอร์อย่างเสถียรโดยไม่สูญหาย
    • หากทำ decimation และ filtering บน FPGA จะลดอัตราข้อมูลได้ แต่ข้อมูล PDM ดิบ ก็สามารถส่งผ่าน Gigabit Ethernet ได้เช่นกัน
    • การส่งข้อมูลดิบช่วยลดความซับซ้อนของโค้ด FPGA และทำให้พัฒนาแบบวนซ้ำได้เร็วขึ้น
    • การคอมไพล์โค้ดเร็วกว่า place-and-route และการใช้ debugger ในโค้ดทั่วไปก็ง่ายกว่าการดีบัก gateware

  • อินเทอร์เฟซ PDM

    • โมดูลอินพุต PDM แบ่ง system clock 50MHz ด้วย 16 แล้วส่งออกเป็น PDM clock 3.125MHz
    • หลังแต่ละขอบ clock จะ latch ขาอินพุต 96 ขา และ shift ข้อมูล 32 บิตในแต่ละ clock cycle
    • เพิ่ม header เป็นจำนวนเต็ม 32 บิตที่เพิ่มขึ้นให้กับข้อมูลแต่ละ chunk ขนาด 192 บิต
    • อัตราข้อมูลอินพุตของอินเทอร์เฟซ PDM คือ 3.125MHz × ขาอินพุต 96 ขา × DDR 2 = 600Mbps
    • อัตราข้อมูลเอาต์พุตรวม header คือ 700Mbps และ utilization ของ data path เอาต์พุต 32 บิตอยู่ที่ประมาณ 40%

  • การทำ packetization และส่งผ่าน UDP

    • โมดูล packetization คล้าย FIFO buffer ที่มีอินเทอร์เฟซอินพุตแบบพิเศษ
    • เนื่องจากอินเทอร์เฟซ Ethernet เร็วกว่าเอาต์พุต PDM หากทำเหมือน FIFO มาตรฐาน แค่มี item เดียวก็อาจส่งออกจนเกิดแพ็กเก็ตที่เล็กกว่าที่ต้องการ
    • โมดูล packetization จะรอจนกว่าข้อมูลครบหนึ่งแพ็กเก็ตสะสมในคิวแล้วค่อยเริ่มส่ง เพื่อรับประกัน แพ็กเก็ตขนาดคงที่
    • แต่ละแพ็กเก็ตมีบล็อกเอาต์พุต PDM ขนาด 224 บิตจำนวน 48 บล็อก
      • หนึ่งบล็อกประกอบด้วยข้อมูล 192 บิตและ header 32 บิต
      • ข้อมูลต่อแพ็กเก็ตคือ 1344 ไบต์
      • เพิ่ม IPv4 header 20 ไบต์และ UDP header 8 ไบต์
    • อัตราแพ็กเก็ตประมาณ 65kpps ส่งผลให้ line rate เป็น 715Mbps และ utilization ของ Gigabit Ethernet ประมาณ 70%
    • ใช้ LiteEth สำหรับ UDP streaming
      • abstractions ความซับซ้อนระดับล่าง เช่น UDP/IP encapsulation และ ARP table
      • มีอินเทอร์เฟซที่เชื่อม FIFO กับ UDP stream ได้ง่าย
      • latency เป็นครั้งคราวถูกดูดซับด้วย buffer headroom ของ packetization FIFO

  • การใช้ทรัพยากร FPGA

    • FPGA ของ Colorlight i5 คือ LFE5U-25F-6BG381C และมี 25k LUT
    • ออกแบบและ route ด้วยโอเพนซอร์ส toolchain Project Trellis
    • ด้วยการรักษา gateware ให้เรียบง่าย การใช้ทรัพยากรจึงต่ำ และเหลือพื้นที่มากสำหรับเพิ่มฟีเจอร์
    • DP16KD: 16/56, 28%
    • TRELLIS_FF: 1950/24288, 8%
    • TRELLIS_COMB: 3701/24288, 15%
    • maximum clock ผ่านที่ 73.17MHz จากเป้าหมาย 50MHz
    • คำเตือน timing ของ Ethernet RX clock เป็น false positive ที่เกี่ยวข้องกับ gray counter ของ LiteEth

Pipeline การประมวลผลซอฟต์แวร์

  • CIC filter

    • ไมโครโฟนแต่ละตัวส่งออก สัญญาณ 1 บิต 3.125MHz และต้องลดลงเป็นอัตราสุ่มตัวอย่างและ bit depth ที่ต่ำลงเพื่อการประมวลผลถัดไป
    • งานนี้ใช้ CIC filter ที่ใช้การคำนวณทางเลขคณิตน้อย
    • อ้างอิงซีรีส์ Moving Average and CIC Filters ของ Tom Verbeure
    • ตัวเลือกสุดท้ายคือ CIC filter 4 stage, decimation 16 เท่า
      • ลดอัตราสุ่มตัวอย่างลงเหลือ 195kHz
      • เอาต์พุตเป็น 32 บิต
    • เพื่อรับข้อมูล 3.125MHz ต้องประมวลผลหนึ่งชุดตัวอย่างภายใน 320ns
    • การ implement ด้วย Rust แบบง่ายยังไม่เร็วพอใน single core จึงใช้ implementation สุดท้ายที่ลด abstraction เพื่อชักนำ auto-vectorization ได้ดีขึ้น
    • implementation ด้วย SIMD intrinsic เร็วกว่ามาก แต่เจอปัญหา alignment เมื่อใช้ร่วมกับโค้ดอื่น
    • ผล benchmark:
      • bench_cic: 574ns/iter, 41MB/s
      • bench_fast_cic: 181ns/iter, 132MB/s
      • bench_simd_cic: 36ns/iter, 666MB/s

  • การปรับเทียบ

    • การปรับเทียบอาร์เรย์ทำโดยเปิด white noise จากลำโพง แล้วขยับลำโพงไปมาในห้องด้านหน้าอาร์เรย์
    • คำนวณ cross-correlation ด้วย FFT ระหว่างไมโครโฟนทุกคู่เพื่อหาหน่วงเวลาสัมพัทธ์
    • มีคู่ไมโครโฟนมากกว่า 18,000 คู่ จึงใช้การคำนวณมาก
    • สำหรับ window size 16k~64k FFT ถูกจำกัดด้วยหน่วยความจำ จึงรวม IFFT กับการค้นหา peak เพื่อไม่ต้องเขียนผลลัพธ์ลงหน่วยความจำ และได้ ความเร็วเพิ่มขึ้น 15 เท่า
    • บน Ryzen 7950X กระบวนการนี้ทำงานแบบเรียลไทม์
    • จากนั้นปรับตำแหน่งแหล่งเสียงในแต่ละช่วงเวลาและตำแหน่งไมโครโฟนแต่ละตัวด้วย gradient descent
      • loss function ลดความต่างระหว่าง correlation ที่วัดได้กับ correlation อุดมคติ
      • ป้องกันไม่ให้ตำแหน่งไมโครโฟนเบี่ยงออกจากตำแหน่งเริ่มต้นมากเกินไป
      • ลด jerk ของ trajectory แหล่งเสียงด้วย
    • ในกระบวนการปรับเทียบ ความเร็วเสียงถูกใส่เป็นพารามิเตอร์สำหรับ optimization ด้วย ทำให้กระบวนการทั้งหมดทำงานเหมือน เทอร์โมมิเตอร์ ที่ซับซ้อนเกินไป
    • หลังทำซ้ำหลายร้อยรอบ ค่าคงที่อย่างตำแหน่งแหล่งเสียง ตำแหน่งไมโครโฟน และความเร็วเสียงจะ converge ไปยังคำตอบที่สมเหตุสมผล
    • ปัญหานี้ vectorize บน GPU ได้ดี จึง converge ภายในไม่กี่วินาที
    • ค่าเฉลี่ยความคลาดเคลื่อนตำแหน่งสุดท้ายอยู่ที่ประมาณ 1mm
    • ยังปรับแก้ความบิดเบี้ยวเชิงระบบขนาดใหญ่ เช่น ความเว้าที่เกิดจากโครงสร้างแข็งแรงไม่พอ
    • ความคลาดเคลื่อนสูงสุดระหว่างตำแหน่งออกแบบกับตำแหน่งหลังปรับเทียบอยู่ที่ประมาณ 5mm
    • ความยาวคลื่นของเสียง 10kHz ประมาณ 3.4cm ดังนั้นหากไม่ปรับเทียบ อาจเกิด phase error ที่มีนัยสำคัญในย่านความถี่สูง

Beamforming และ visualization

  • วิธี beamforming

    • Beamforming คือกระบวนการประมวลผลอินพุตไมโครโฟนดิบเพื่อสร้าง การตอบสนองแบบมีทิศทาง
    • วิธีที่ implement คือแบบง่ายที่สุด delay-and-sum หรือ DAS
    • หน่วงสัญญาณแต่ละตัวตามความต่างของระยะทางถึงแหล่งเสียง แล้วรวมกัน
    • ในโปรเจกต์นี้ทำ beamforming ในโดเมนความถี่
      • ในโดเมนความถี่ การหน่วงทำด้วยพจน์ phase เชิงเส้นที่แปรตาม delay ที่ต้องการ และการคูณเชิงซ้อนกับสัญญาณ
      • จัดการ delay ที่ไม่ใช่จำนวนเต็มเท่าของคาบ sampling ได้อย่างเป็นธรรมชาติ
    • ใช้ subarray ซ้อนทับหลายชุดของอาร์เรย์เดิมตามช่วงความถี่
    • ไม่จำเป็นต้องทำ beamforming ด้วยไมโครโฟนทุกตัวในทุกความถี่ จึงลดปริมาณงาน และยังช่วยปรับ beamforming gain ของทุกความถี่ให้สอดคล้องกัน

  • การ implement บน GPU ด้วย Triton

    • Beamformer ถูก implement เป็น kernel ของ Triton
    • Triton คือ Python DSL ที่คอมไพล์ให้ทำงานบน Nvidia GPU
    • เมื่อต้อง beamforming จุดนับแสน การขนานขนาดใหญ่ของ GPU ทำให้ได้ ผลลัพธ์แบบเรียลไทม์
    • เนื่องจาก ข้อจำกัดปัจจุบัน ด้านการรองรับ shared memory array indexing ในภาษา Triton ประสิทธิภาพจึงยังไม่ optimal เล็กน้อย แต่ไม่ได้เลือกเขียน CUDA C++

  • Beamforming 3D ระยะใกล้

    • Beamforming 3D ระยะใกล้ทำบน voxel grid 5cm
    • ขนาด grid คือ 64×64×64
    • บน RTX 4090 ได้อัตราอัปเดต 12Hz
    • ความเร็วที่สูงกว่านี้ถูกจำกัดโดย overhead ที่ CPU-GPU synchronization ยังไม่เหมาะสมสำหรับหน่วยงานขนาดเล็ก
    • Voxel grid แสดงผลด้วย VisPy ไลบรารี visualization ประสิทธิภาพสูงบน OpenGL
    • การ render voxel โปร่งแสง 250,000 จุดไม่เป็นปัญหาสำหรับ framerate แบบ interactive เมื่อเทียบกับจำนวน polygon ในเกมสมัยใหม่

  • Beamforming 2D ระยะไกล

    • แหล่งเสียงระยะไกลมี wavefront เกือบเป็นระนาบ ดังนั้นระยะห่างของแหล่งเสียงแทบไม่เปลี่ยนสัญญาณอาร์เรย์อย่างมีนัยสำคัญ
    • แหล่งเสียงใกล้มีความโค้งของ wavefront มาก จึงสามารถกำหนด ตำแหน่ง 3D ได้
    • Beamforming ระยะไกลไม่มีมิติความลึก จึงทำได้ที่ความละเอียดสูงกว่า
    • ใช้ grid 512×512 pixel และได้อัตราอัปเดต 12Hz เช่นกัน
    • Beamforming ระยะไกลใช้การประมาณโดยวางจุดไว้ไกล แทนสมมติฐาน plane wave จริง
    • เนื่องจากในห้องมีการสะท้อนและ multipath มาก demo visualization 2D จึงได้รับผลกระทบจากสภาพแวดล้อมทางเสียง

  • เสียงแบบมีทิศทาง

    • beamforming สองแบบก่อนหน้าคำนวณพลังงานเสียงในแต่ละตำแหน่ง แต่ไม่ได้สร้างเสียงที่ผ่าน beamforming ไว้ในหน่วยความจำ
    • สำหรับการบันทึกเสียงแบบมีทิศทาง จึง implement time-domain delay-and-sum beamformer
      • รับพิกัด 3D เทียบกับศูนย์กลางอาร์เรย์เป็นอินพุต
      • ส่งออก audio sample
    • Beamformer นี้ทำให้ตำแหน่ง differentiable เทียบกับเอาต์พุตได้
    • สามารถ optimize ตำแหน่งแหล่งเสียงด้วย loss function ที่ differentiable ได้
    • อาจประยุกต์ใช้ forced alignment model ในการถอดเสียงหลายคนเพื่อหาตำแหน่งทางกายภาพของผู้พูดแต่ละคนได้
    • เปรียบเทียบผลโดยให้ลำโพงหนึ่งตัวเล่นเสียงหน้าอาร์เรย์ และลำโพงอีกตัวเล่น white noise ที่ระยะเท่ากันแต่ทำมุมประมาณ 45 องศาจากศูนย์กลางอาร์เรย์
    • แสดงผล beamforming โดยเปรียบเทียบ raw audio จากไมโครโฟนเดี่ยวกับ audio หลัง beamforming

วิธีบันทึกและข้อจำกัด

  • ข้อมูลอาร์เรย์ไมโครโฟนเป็นแพ็กเก็ต UDP จึงบันทึกได้ด้วยเครื่องมืออย่าง tcpdump
  • สามารถอ่านไฟล์ packet capture แล้ว inject แพ็กเก็ตกลับเข้า listener ได้
  • โปรแกรมก่อนหน้าถูกออกแบบให้ทำงานแบบเรียลไทม์ แต่ก็ทำงานกับข้อมูลบันทึกด้วยวิธีนี้ได้
  • ข้อเสียคือบันทึกข้อมูลดิบตรง ๆ ทำให้อัตราข้อมูลเอาต์พุตสูงมาก
    • เก็บ quantization noise ไว้อย่างครบถ้วนด้วย
    • อัตราข้อมูลคือ 87.5MB/s
    • การบันทึก 1 ชั่วโมงต้องใช้ 315GB
  • implementation ที่ปรับให้เหมาะสมกว่านี้สามารถใช้การบีบอัด หรือบันทึกที่อัตราสุ่มตัวอย่างต่ำลงหลังผ่าน CIC filter ได้

แนวทางต่อยอดที่เป็นไปได้

  • โปรเจกต์โดยหลักถือว่าเสร็จสมบูรณ์แล้ว และไม่มีแผนทำงานเพิ่มในอนาคตอันใกล้
  • อย่างไรก็ตาม ยังมีพื้นที่ให้ต่อยอดสำหรับผู้ที่อยากสร้างเอง
    • ใช้อัลกอริทึม beamforming ขั้นสูงกว่า เช่น DAMAS
    • GUI ที่ดีขึ้นโดยผสานฟีเจอร์เดิม เช่น ดูว่าเสียงมาจากไหนแล้วบันทึกเสียงจากตำแหน่งนั้น
    • ผสาน differentiable beamforming กับโมเดลโครงข่ายประสาท เช่น การประยุกต์แบบตัวอย่าง forced alignment ก็เป็นไปได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-23
ความคิดเห็นจาก Hacker News

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

    • ตอนมัธยมปลาย ผมได้รับความช่วยเหลือจากพ่อแม่ ทำอุปกรณ์วัดว่าแรงดันลดลงเร็วแค่ไหนใน กระบอกสูบอัดความดัน ที่มีอากาศรั่วออกทางรูเล็กมาก ๆ
      ปรากฏว่าวิธีนั้นยังใช้วัดอุณหภูมิได้ด้วย และสามารถ extrapolate กราฟเพื่อหาอุณหภูมิศูนย์สัมบูรณ์ได้
      เท่าที่จำได้ ผลคลาดเคลื่อนไปประมาณ 20K ซึ่งสำหรับโปรเจกต์ในโรงรถของเด็กมัธยมแล้ว ผมว่าก็ยอดเยี่ยมทีเดียว
    • ผมมีหลักว่าเวลาวัดอะไรบางอย่างตามเวลา จะต้องวัด อุณหภูมิแวดล้อม ไปพร้อมกันเสมอ
    • ผมชอบ การวัดโดยบังเอิญ แบบนี้
      ตัวอย่างที่ผมชอบเป็นพิเศษคือ หน่วยวัดความเฉื่อย (IMU) ที่แม่นยำพอสามารถใช้เอฟเฟกต์คอริออลิสเพื่อวัดลองจิจูดได้ค่อนข้างแม่นยำด้วย
    • สงสัยว่ามีสุภาษิตทำนอง “อุปกรณ์อิเล็กทรอนิกส์ทุกชิ้นคือเครื่องกำเนิดควัน และบางชิ้นก็ยังคำนวณได้ด้วย” ไหม
    • เพิ่งรู้ว่า Duracell Powercheck© ทำงานโดยใช้อุณหภูมิ
      https://youtu.be/zsA3X40nz9w?si=oGg2wdUlLXSDxpsN

  • เมื่อก่อนเคยทำโปรเจกต์ระบุตำแหน่งค้างคาวแบบ multilateration ด้วย อาร์เรย์ไมโครโฟน 4 ตัว ที่วางบนพื้นเป็นรูปตัว Y ขนาดใหญ่
    ใช้ความต่างของเวลาที่เสียงเดินทางมาถึงไมโครโฟนทั้งสี่ตัว เพื่อหาตำแหน่งของค้างคาวแต่ละตัวที่บินผ่านเหนืออาร์เรย์ และยังระบุชนิดได้ด้วย
    งานนี้ถูกใช้ในการวิจัยเพื่อประเมินผลกระทบต่อสิ่งแวดล้อมจากการติดตั้งกังหันลม และสนุกมากทีเดียว

    • ทำให้นึกถึง Optical Fence ของ Intellectual Ventures
      เป็นอุปกรณ์ที่พัฒนาขึ้นเพื่อติดตามและฆ่ายุงด้วยพัลส์เลเซอร์สั้น ๆ
      เพราะต้องจับตำแหน่งของยุงในอวกาศอย่างแม่นยำ ผลพลอยได้คือสามารถตรวจจับความแตกต่างของความถี่การกระพือปีก เพื่อแยกเป้าหมายตามเพศและชนิดได้
    • ตอนอายุ 18 ผมทำโปรเจกต์คล้าย ๆ กัน
      แน่นอนว่าทักษะฮาร์ดแวร์และซอฟต์แวร์ยังไม่พอ เลย implement อัลกอริทึม TDOA ในรูปแบบที่ซื่อที่สุด และวิธีประมาณความต่างเวลาด้วย cross-correlation ก็ไร้ประสิทธิภาพมาก
      แต่ก็ได้เรียนรู้เยอะ และท้ายที่สุดนำไปสู่ปริญญาเอกด้าน ระบบ SAR
      ผมมองว่า SAR จริง ๆ แล้วใกล้เคียงกับ beamformer ที่ใช้การเคลื่อนที่ของแพลตฟอร์มแทนอาร์เรย์
    • อยากรู้ว่าผลการวิจัยเป็นอย่างไร
      เคยได้ยินว่าปอดของค้างคาวไวมาก จนถ้าบินผ่าน ความต่างของความดัน ของกังหันขนาดใหญ่ เส้นเลือดฝอยจะแตกได้จริง ๆ
    • อยากลองทำอะไรแบบนี้เพื่อติดตามค้างคาวในสวน แต่สงสัยว่าสำหรับมือสมัครเล่นที่ทำเป็นโปรเจกต์ส่วนตัวแล้วจะเป็นไปได้จริงแค่ไหน
      ถ้ามีแหล่งข้อมูลอ้างอิงว่าควรเริ่มจากตรงไหนก็คงดี
    • ทำให้นึกถึงงานที่ยอดเยี่ยมและเงียบ ๆ ของ Cosys-Lab ที่มหาวิทยาลัย Antwerp
      พวกเขาวางอาร์เรย์ไมโครโฟนไว้ใต้แมงป่อง และแสดงให้เห็นว่าค้างคาวขยับลำแสงอัลตราซาวด์เพื่อสแกนแมงป่องอย่างไร
      เป็นผลลัพธ์ที่น่าทึ่งจริง ๆ [0]
      [0]: https://www.youtube.com/watch?v=57ScSPWhGqU

  • สงสัยว่าทำไมถึงใช้ PDM แทนที่จะใช้ ไมโครโฟน I2S แบบ TDM ในอาร์เรย์
    ICS-52000 ค่อนข้างถูก อยู่ที่ระดับ 2 ดอลลาร์เมื่อซื้อ 100 ตัว และเท่าที่เข้าใจมีบอร์ด breakout ที่มีไมโครโฟน 4 ตัว รวมถึงสามารถต่อแบบ chain ได้ถึง 8 หรือ 16 ตัว
    https://www.cdiweb.com/datasheets/notwired/ds-nw-aud-ics5200...
    ถ้าใช้ Jetson หรือฮาร์ดแวร์ที่มี DSP/GPU และรองรับ I2S ก็สามารถต่อไมโครโฟนแบบ chain ได้ 16 ตัวต่อพอร์ต I2S หนึ่งพอร์ต ดูเหมือนจะประกอบและเขียนโปรแกรมง่ายกว่าการจัดชุด FPGA มาก

    • เหตุผลหลักคือค่าใช้จ่าย
      ถ้ามีไมโครโฟน 192 ตัว ความต่างระหว่าง 2 ดอลลาร์/ตัวกับ 0.5 ดอลลาร์/ตัวจะค่อนข้างมาก
      ต่อให้ทำ daisy chain 16 ตัว ก็ยังหาอุปกรณ์ที่มีอินเทอร์เฟซ I2S เพียงพอได้ยาก และอุปกรณ์ส่วนใหญ่ก็ไม่ได้มีมากพอตามจำนวนที่ต้องใช้
      FPGA กับฮาร์ดแวร์สั่งทำเองก็เป็นส่วนหนึ่งของความสนุกด้วย
    • ผมเคยค้นดูเมื่อหลายปีก่อน ตอนนั้นมันแพงกว่านี้ และทำได้แค่ถึง 20kHz
      ถ้าต้องการฟังเสียงฟู่ของก๊าซรั่วหรือการปล่อยโคโรนาของอาร์กไฟฟ้า ความถี่ที่สูงกว่า จะมีประโยชน์
      ภายใน Orin มีพอร์ต I2S 6 พอร์ต ดังนั้นดูเหมือนว่าจะรองรับไมโครโฟนได้ถึง 16*6 = 96 ตัว ซึ่งเป็นตัวเลขที่ค่อนข้างดี
      แต่ในทางปฏิบัติดูเหมือนมีเพียง 3 พอร์ตที่ถูกนำออกมานอกบอร์ด และอยู่บนคอนเน็กเตอร์ของบอร์ดพัฒนาคนละตัวกัน [1]
      ในงานออกแบบ รายละเอียดมักเป็นปัญหาเสมอ ดังนั้นถ้าต้องการมากกว่า 96 ตัว FPGA อาจจัดโครงสร้างได้ง่ายกว่า
      ชิ้นส่วนที่ผมจดไว้คือ ICS-52000 $3.50 20kHz, ICS-41350 $1.05 40kHz, SPH0641LU4H-1 $1.45 80kHz+
      [1] https://docs.nvidia.com/jetson/archives/r34.1/DeveloperGuide...
    • ผมเคยคิดจะทำ อาร์เรย์เฟส เอง แต่ไปไม่ถึงขั้นทำ PCB
      เหตุผลที่ I2S ไม่ใช่ตัวเลือกที่ดีที่สุดมีอยู่ราว ๆ สองข้อ
      I2S ต้องใช้ 3 พิน แทนที่จะเป็น 2 พินแบบ PDM
      แต่ถ้าสามารถทำ daisy chain ไมโครโฟนได้เหมือนใน datasheet ที่ให้มา ก็ถือว่าเจ๋งมาก และถึงจะไม่ใช่ I2S มาตรฐาน ประเด็นนี้ก็หมดไป
      PDM เข้าถึงอัตราการสุ่มตัวอย่างที่สูงกว่ามากได้ จึงมีความยืดหยุ่นมากขึ้นในการเลือก delay สำหรับการคำนวณแบบ delay-and-sum
      เช่น ถ้า clock ของ PDM อยู่ที่ 2MHz ตามทฤษฎีจะหน่วงเวลาได้ด้วยความละเอียด 0.5µs
      ในทางปฏิบัติคงใช้ความละเอียดต่ำกว่านั้น แต่ clock ของ I2S โดยทั่วไปอยู่ที่สูงสุดราว 192kHz
      ไมโครโฟน PDM ยังถูกกว่าด้วย

  • หากลองค้นหา กล้องเสียง บน YouTube จะพบเดโมที่ค่อนข้างน่าประทับใจซึ่งแสดงให้เห็นประสิทธิภาพ
    หนึ่งในบริษัทที่ผมติดตามมาระยะหนึ่งคือที่นี่ และดูเหมือนผู้เล่นรายใหญ่อย่าง FLIR ก็เข้ามาในตลาดนี้ด้วย: https://www.youtube.com/@gfaitechgmbh
    กรณีใช้งานที่น่าสนใจแต่ก็น่าขนลุกคือการบันทึกเสียงในพื้นที่สาธารณะไว้ แล้วภายหลังค่อย ‘ซูมเข้า’ ไปที่บทสนทนาระหว่างบุคคลบางคน

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

  • อยากกลับไปเป็นนักศึกษาบัณฑิตศึกษาแล้วลองทำแอปพลิเคชันทางการแพทย์โดยผสานกับ อาร์เรย์ลำโพงอัลตราซาวนด์
    โดยพื้นฐานแล้วมันคล้าย HIFU (อัลตราซาวนด์โฟกัสความเข้มสูง) ที่ทรงพลังมากและมีฟีดแบ็กแบบเรียลไทม์
    https://en.wikipedia.org/wiki/Focused_ultrasound

    • ผมกำลังทำปริญญาเอกด้านอาร์เรย์เฟสอัลตราซาวนด์ในอากาศ และได้คุยกับคนสายการแพทย์ตามงานประชุมหรือห้องแล็บอยู่บ้าง แต่ใน ของแข็งและของเหลว นั้นยากกว่ามาก
      ความถี่สูงกว่ามาก จึงต้องคิดที่ประมาณ 1~10MHz ไม่ใช่ 40kHz และวงจรอิเล็กทรอนิกส์ทั่วไปแทบจะใช้ไม่ได้
    • ปัญหาหนึ่งคือเมื่อคลื่นเสียงผ่านของแข็งและของเหลว ความเร็วเสียงไม่ได้คงที่ ตลอดช่วงแบนด์วิดท์ที่สนใจ
    • นักศึกษาบัณฑิตศึกษา FUS ที่คุณกำลังหาอยู่อาจเป็นผมก็ได้
      ถ้าอยากคุย ติดต่อได้ทางอีเมลในโปรไฟล์
    • ถ้าเป็นแอปพลิเคชันทางการแพทย์ ดูมีแนวโน้มสูงว่าจะต้องใช้ การคัปปลิงแบบสัมผัส ไม่ใช่ผ่านอากาศ

  • คงดีถ้าเทคโนโลยีแบบนี้ถูกบรรจุมาอย่างดีแล้วใส่ลงในอุปกรณ์มือถือหลายชนิด
    ผมมองว่าสาเหตุหนึ่งที่ผู้ช่วยดิจิทัลหรือเครื่องแปลภาษาอเนกประสงค์ยังติดขัดอยู่คือ คุณภาพเสียงที่แย่
    หากลดสัญญาณรบกวนและตรวจจับทิศทางได้ ก็น่าจะช่วยได้มาก
    เช่น อยากแปลบทสนทนากลุ่มรอบโต๊ะอาหารแบบเรียลไทม์
    ขั้นแรกคงดีถ้าโทรศัพท์กับหูฟังสามารถรวมไมโครโฟนของแต่ละคนมาใช้เพื่อจุดประสงค์นี้ได้
    ยิ่งไปกว่านั้น ถ้าโทรศัพท์ทุกเครื่องที่อยู่ใกล้กันร่วมมือกันเพื่อให้ได้เสียงเชิงทิศทางคุณภาพสูงได้จะเป็นอย่างไร
    แน่นอนว่าต้องอยู่บนสมมติฐานว่าสามารถแก้ปัญหาความเป็นส่วนตัวได้

    • สำหรับคนที่มีภาวะหูตึงอย่างผม การให้ คำบรรยายแบบเรียลไทม์ ในสภาพแวดล้อมที่มีเสียงดังอย่างงานสังสรรค์หรือปาร์ตี้ และการแยก·จัดกลุ่มคำพูดของผู้พูดแต่ละคน จะเป็น killer app
      มันอาจเปลี่ยนชีวิตได้
      Live Transcribe ของ Android ตอนนี้ดีมากแล้ว แต่ยังไม่แม้แต่จะพยายามแยกว่าคำไหนมาจากผู้พูดคนใด
    • MacBook Pro รุ่นล่าสุดมีไมโครโฟนหลายตัวอยู่แล้ว และน่าจะทำการประมวลผลบางอย่างที่คล้าย อาร์เรย์เฟส อยู่
    • สิ่งนี้เป็นที่รู้จักกันในชื่อ ปัญหาค็อกเทลปาร์ตี้
      มันเผยให้เห็นว่าสมองทำการประมวลผลอย่างมหาศาลเพื่อให้เราเข้าใจสิ่งที่ใครบางคนพูดกับเราในห้องที่มีเสียงดัง
      https://en.wikipedia.org/wiki/Cocktail_party_effect?wprov=sf...
    • โดยทั่วไป หากต้องการคำนวณการเลื่อนเฟสให้ถูกต้อง ต้องรู้ ตำแหน่งไมโครโฟน ในอวกาศอย่างแม่นยำ และนาฬิกาของโทรศัพท์ก็ต้องซิงก์กันด้วยความแม่นยำสูงมาก
      โดยคร่าว ๆ ต้องอยู่ในระดับประมาณ 10 เท่าของความถี่เสียงสูงสุดที่ต้องการเก็บ หรือภายในหนึ่งในหลายหมื่นวินาที
      อีกทั้งถ้าตำแหน่งไมโครโฟนในอาร์เรย์ไม่ใช่เส้นตรง วงกลม หรือเรขาคณิตง่าย ๆ แบบอื่น โค้ดหรือคณิตศาสตร์ในการดึงสัญญาณที่ดีขึ้นออกมาก็จะยากมาก

  • Boeing เคยทำ เวอร์ชันทรงกลม ของอุปกรณ์แบบนี้ และใช้กับต้นแบบ 787 เพื่อค้นหาวัสดุกันเสียงที่เหมาะสม
    ว่ากันว่าในสภาพแวดล้อมที่มีเสียงดังอย่างเครื่องบิน ภาพลวงทางการได้ยินอาจทำให้รู้สึกว่าเสียงมาจากตำแหน่งที่ต่างจากตำแหน่งจริง
    เมื่อมีงบประมาณด้านน้ำหนักสำหรับวัสดุกันเสียงที่กำหนดไว้ การทำให้จุด 80/20 ถูกต้องจึงสำคัญ

  • ถ้าอยากลองเล่นกับ Zynq 7010 ก็น่าดู บอร์ด EBAZ4205
    ซื้อได้บน AliExpress ในราคา 20~30 ยูโร และเดิมทีเป็นคอนโทรลเลอร์ขุด Bitcoin
    มีคนทำ reverse engineering ทั้งหมดแล้วอัปขึ้น GitHub และยังมีบอร์ดอะแดปเตอร์สำหรับเข้าถึง GPIO ด้วย
    ถ้าอยากเริ่มแบบซับซ้อนน้อยลง ก็มี FPGA จีนอย่างบอร์ด “Sipeed” ที่ใช้ GoWin FPGA
    ใช้งานได้ค่อนข้างดี และ IDE ก็ฟรี

    • ชุดเครื่องมือ Xilinx ก็ฟรีเช่นกัน

  • เมื่อคืนผมหาข้อมูลแล้วก็มาถึงหน้านี้พอดี
    สงสัยว่ามีใครรู้วิธีติดตั้งไมโครโฟนในห้องแล้วบันทึกเฉพาะเสียงจาก บริเวณหนึ่ง ๆ ไหม
    กรณีใช้งานของผมคือบันทึกเสียงจากฝั่งโซฟาเพื่อดูทีวีกับเพื่อนออนไลน์ โดยตัดเสียงของเพื่อน ๆ และเสียงรายการออกจากเสียงที่บันทึก
    ดูเหมือนถ้าทำอาร์เรย์ไมโครโฟนแล้วใช้ beam steering น่าจะทำได้ แต่ผมหาตัวอย่างโค้ดที่ทำงานแบบเรียลไทม์บน GitHub ได้ไม่มากนัก

    • ลองดู OBS หรือ VoiceMeeter ก็น่าจะเห็นวิธีที่สตรีมเมอร์ใช้เลือกเส้นทางเสียงระหว่างไลฟ์หรือบันทึกได้
      https://obsproject.com/
      https://voicemeeter.com/
    • เสียงรายการที่ดังและเสียงใกล้ ๆ จากเพื่อนออนไลน์จะสะท้อนในห้องและจากร่างกาย
      สิ่งที่ต้องการไม่ใช่ไมโครโฟนหรือเทคนิค beamforming แต่เป็น การตัดเสียงสะท้อน แบบเดียวกับที่ซอฟต์แวร์ประชุมวิดีโอทุกตัวใช้
      ใส่เสียงรายการกับเสียงเพื่อนเป็นอินพุต แล้วใช้การตัดเสียงสะท้อนกับแต่ละรายการก็พอ
    • อย่างที่บทความบอกไว้ “วิธี beamforming ที่ง่ายที่สุดคือ delay-and-sum (DAS)”
      วัดระยะจากจุดหนึ่ง คือโซฟา ไปยังไมโครโฟนแต่ละตัว จากนั้นหน่วงสัญญาณในโดเมนเวลาเท่ากับเวลาที่เสียงเดินทางจากโซฟาไปถึงไมโครโฟน แล้วนำมารวมกัน
      โดยพื้นฐานแล้วคือพยายามปรับให้ไมโครโฟนรับสัญญาณจากโซฟาเหมือนเกิดขึ้นในเวลาเดียวกัน แม้จะอยู่ห่างกันคนละระยะ
      เพื่อให้วิธีนี้ได้ผล ต้องทำให้ ความแตกต่างของระยะห่างระหว่างไมโครโฟน มากพอ