Phased-Array-Mikrofon (2023)

• Das 192-Kanal-Phased-Array-Mikrofon kann die Richtcharakteristik auch nach der Aufnahme noch ändern oder gleichzeitig auf Hunderttausende Punkte fokussieren und ermöglicht so die Lokalisierung und Visualisierung von Schallquellen, die mit gewöhnlichen Richtmikrofonen nur schwer zu erreichen sind
• Die Hardware besteht aus radialen Mikrofonarmen und einem zentralen Hub und verwendet für Kosten von etwa 700 $ 192 MEMS-Mikrofone, eine Colorlight-i5-FPGA-Karte und eine Gigabit-Ethernet-Übertragungsstruktur
• Das FPGA konzentriert sich statt auf komplexe Vorverarbeitung auf die Übertragung roher PDM-Daten, verarbeitet 3,125 MHz Eingangsdaten und nutzt mit etwa 715 Mbit/s rund 70 % der Gigabit-Ethernet-Bandbreite
• Die Software kombiniert CIC-Filter, FFT-basierte Kalibrierung, GPU-Optimierung und Triton-Beamforming, um 3D-Schallquellen im Nahfeld und 2D-Schallquellen im Fernfeld in Echtzeit zu visualisieren
• UDP-Pakete können mit tcpdump aufgezeichnet und wiedergegeben werden, aber die Rohdatenspeicherung erreicht 87,5 MB/s, sodass für 1 Stunde Aufnahme 315 GB erforderlich sind

---

Aufbau eines 192-Kanal-Phased-Array-Mikrofons

• Ein 192-Kanal-Phased-Array-Mikrofon wird mit FPGA-Datenerfassung sowie GPU-basiertem Beamforming und Visualisierung kombiniert
• Anders als bei gewöhnlichen Richtmikrofonen lässt sich bei einem Phased Array die Richtcharakteristik auch nach der Aufnahme noch ändern, und es kann in Echtzeit gleichzeitig auf Hunderttausende Punkte fokussieren
• Sämtliche Designs sind als Open Source veröffentlicht

Hardware-Design

• Array-Struktur und Kosten

  • Ein Phased Array wird aufgebaut, indem viele Mikrofone mit großem Abstandsmuster verteilt angeordnet werden
  • Bei linearen Arrays gelten exponentielle Abstände zwischen den Mikrofonen für Breitbandsignale als optimal
  • Das 2D-Array verwendet radial angeordnete Arme aus symmetrischen linearen Arrays, damit die zentrale Hub-Platine klein bleibt
  • Die Gesamtkosten des Arrays liegen bei etwa 700 $

• Arm-Platinen

  • Die Länge jedes Arms wurde an die Grenzen von PCB-Fertigung und -Bestückung angepasst; die maximale Länge für 4-lagige PCB-Fertigung und -Bestückung bei JLCPCB betrug 570 mm
  • Verwendet werden günstige MEMS-Mikrofone mit digitalem Ausgang zu etwa 0,5 $ pro Stück
    • In dieser Preisklasse sind die Leistungsunterschiede zwischen Mikrofonen nicht groß
    • Die meisten zeigen bis 10 kHz eine brauchbare Leistung, aber Phasenverzögerung und Pegelabgleich sind nicht spezifiziert
  • Die Mikrofone geben Daten im PDM(pulse density modulation)-Format aus
    • Sie liefern 1-Bit-Ausgabe mit Frequenzen bis 4 MHz, also weit oberhalb des hörbaren Bereichs
    • Das kompensiert Quantisierungsrauschen durch eine hohe Abtastrate
    • Sie unterstützen DDR, bei dem Daten an steigender und fallender Taktflanke übernommen werden, sodass zwei Mikrofone auf einer Leitung multiplexed werden können
  • Jeder Arm hat 8 Mikrofone und 4 Ausgangsleitungen, die Takteingangsleitung besitzt Ausgangspuffer
  • Das Design stellt sicher, dass die Anstiegszeit auf einem vernünftigen Niveau bleibt, auch wenn Hunderte Mikrofone dasselbe Taktsignal teilen
  • Die Ausbeute der Arm-PCBs war schlecht; nur etwa 50 % der Platinen funktionierten anfangs
    • Der häufigste Fehler war ein Kurzschluss der Taktleitung gegen 3V3 oder GND
    • Um den Kurzschluss zu beheben, mussten Mikrofone einzeln durch Try-and-Error entfernt werden
    • Einige Mikrofone lieferten selbst nach Nacharbeit fehlerhafte Daten; der Code maskiert diese Mikrofone und schließt sie aus
  • Im nächsten Design könnten serielle Widerstände in der Taktleitung, bessere Panelisierung und verbesserte Lötpastenschablonen die Nacharbeit reduzieren

• Hub-Platine

  • Für die Datenerfassung wird ein FPGA verwendet, das viele latenzarme I/Os und Hochgeschwindigkeitsschnittstellen wie Gigabit Ethernet benötigt
  • Konkret wurde eine Colorlight i5-Karte ausgewählt
    • Gründe waren genügend I/O, niedriger Preis, gute Verfügbarkeit und zwei integrierte Ethernet-PHYs
    • In diesem Projekt wird nur ein Ethernet-PHY verwendet
  • Diese Karte ist ursprünglich eine Ethernet-Schnittstelle für LED-Panels, wurde aber vollständig reverse-engineered
  • Etwa 100 GPIOs sind über DDR2-Steckverbinder herausgeführt, was das Fan-out gegenüber dem ursprünglichen FPGA-BGA erleichtert
  • Der Hub enthält neben dem FPGA auch eine einfache Stromversorgungsschaltung, Steckverbinder für die Arm-Platinen und einen Ethernet-Steckverbinder mit integrierter Magnetik

• Mechanisches Design

  • Die Arme werden mit PCB-Abstandshaltern, Muttern und M3-Schrauben am Hub befestigt
  • Die Verbindung zwischen Armen und Hub erfolgt über 8-polige Steckverbinder mit 2 mm Raster
  • Das ursprüngliche Design verzahnte Schlitze in den Arm-PCBs mit einer ringförmigen Struktur-PCB, aber wegen der geringen Torsionssteifigkeit der Arme verformte sich die Gesamtstruktur leicht
  • Das endgültige Design verwendet außen am Array lasergeschnittene 1/4-Zoll-MDF-Teile, an denen jeder Arm mit Kabelbindern befestigt wird
  • Das Mikrofonarray ist an einer Wand montiert und daher anfällig für Reflexionen; zur einfacheren Kalibrierung werden diese mit Akustikschaum reduziert

FPGA-Gateware

• Designziele

  • Das zentrale Ziel der Gateware ist, die erfassten Rohdaten verlustfrei und zuverlässig an den Computer zu übertragen
  • Dezimierung und Filterung im FPGA könnten die Datenrate senken, aber auch rohe PDM-Daten lassen sich über Gigabit Ethernet übertragen
  • Das Senden der Rohdaten reduziert die Komplexität des FPGA-Codes und beschleunigt iterative Entwicklung
  • Das Kompilieren des Codes geht schneller als Place-and-Route, und Debugging mit einem Debugger in normalem Code ist einfacher als Gateware-Debugging

• PDM-Schnittstelle

  • Das PDM-Eingangsmodul teilt den 50-MHz-Systemtakt durch 16 und erzeugt so einen 3,125-MHz-PDM-Takt
  • Nach jeder Taktflanke werden 96 Eingangspins übernommen, und in jedem Taktzyklus werden 32 Bit Daten geschoben
  • Zu jedem 192-Bit-Datenblock wird ein 32-Bit-Integer-Header mit Inkrement angefügt
  • Die Eingangs-Datenrate der PDM-Schnittstelle beträgt 3,125 MHz × 96 Eingangspins × DDR 2 = 600 Mbit/s
  • Die Ausgangsdatenrate inklusive Header beträgt 700 Mbit/s, und die Auslastung des 32-Bit-Ausgabedatenpfads liegt bei etwa 40 %

• Paketisierung und UDP-Übertragung

  • Das Paketisierungsmodul ähnelt einem FIFO-Puffer mit spezieller Eingabeschnittstelle
  • Da die Ethernet-Schnittstelle schneller ist als die PDM-Ausgabe, könnten wie bei einem Standard-FIFO Pakete kleiner als angefordert entstehen, wenn schon bei nur einem Eintrag ausgegeben wird
  • Das Paketisierungsmodul wartet, bis Daten für ein ganzes Paket in der Queue liegen, und startet dann die Übertragung, um Pakete mit fester Größe sicherzustellen
  • Jedes Paket enthält 48 PDM-Ausgabeblöcke zu je 224 Bit
    • Ein Block besteht aus 192 Bit Daten und 32 Bit Header
    • Die Nutzdaten pro Paket betragen 1344 Byte
    • Hinzu kommen 20 Byte IPv4-Header und 8 Byte UDP-Header
  • Die Paketfrequenz liegt bei etwa 65 kpps, was zu einer Leitungsrate von 715 Mbit/s und einer Gigabit-Ethernet-Auslastung von rund 70 % führt
  • Für UDP-Streaming wird LiteEth verwendet
    • Es abstrahiert die zugrunde liegende Komplexität wie UDP/IP-Kapselung und ARP-Tabellen
    • Es bietet eine leicht anzubindende Schnittstelle, um FIFO mit einem UDP-Stream zu verbinden
    • Sporadische Latenzen werden durch den Pufferraum des Paketisierungs-FIFOs aufgefangen

• FPGA-Ressourcennutzung

  • Das FPGA der Colorlight i5 ist ein LFE5U-25F-6BG381C mit 25k LUT
  • Das Design wurde mit der Open-Source-Toolchain Project Trellis platziert und geroutet
  • Durch die einfache Gateware bleibt die Ressourcenauslastung niedrig und es gibt viel Spielraum für zusätzliche Funktionen
  • DP16KD: 16/56, 28 %
  • TRELLIS_FF: 1950/24288, 8 %
  • TRELLIS_COMB: 3701/24288, 15 %
  • Der maximale Takt besteht bei 73,17 MHz gegenüber dem Ziel von 50 MHz
  • Die Timing-Warnung beim Ethernet-RX-Takt ist ein false positive im Zusammenhang mit dem Gray Counter von LiteEth

Software-Verarbeitungspipeline

• CIC-Filter

  • Jedes Mikrofon gibt ein 3,125-MHz-1-Bit-Signal aus, das für die weitere Verarbeitung auf eine niedrigere Abtastrate und Bit-Tiefe reduziert werden muss
  • Dafür wird ein CIC-Filter mit geringem Rechenaufwand verwendet
  • Als Referenz dient die Serie Moving Average and CIC Filters von Tom Verbeure
  • Die endgültige Wahl ist ein 4-stufiger CIC-Filter mit 16-facher Dezimierung
    • Er senkt die Abtastrate auf 195 kHz
    • Die Ausgabe ist 32 Bit breit
  • Um 3,125-MHz-Daten anzunehmen, muss ein Sample-Bündel innerhalb von 320 ns verarbeitet werden
  • Eine einfache Rust-Implementierung war auf einem einzelnen Core nicht schnell genug; schließlich wurde eine Implementierung verwendet, die Abstraktionen reduzierte und Auto-Vektorisierung besser ermöglichte
  • Eine SIMD-Intrinsics-Implementierung war deutlich schneller, stieß aber in Kombination mit anderem Code auf Ausrichtungsprobleme
  • Benchmark-Ergebnisse:
    • bench_cic: 574ns/iter, 41MB/s
    • bench_fast_cic: 181ns/iter, 132MB/s
    • bench_simd_cic: 36ns/iter, 666MB/s

• Kalibrierung

  • Die Kalibrierung des Arrays erfolgt, indem ein Lautsprecher mit White Noise im Raum vor dem Array bewegt wird
  • Zwischen allen Mikrofonpaaren wird FFT-basierte Kreuzkorrelation berechnet, um relative Verzögerungen zu bestimmen
  • Es gibt mehr als 18.000 Mikrofonpaare, daher ist der Rechenaufwand hoch
  • Bei Fenstergrößen von 16k bis 64k ist die FFT speichergebunden; deshalb wurden IFFT und Peak-Suche kombiniert, um Ergebnisse nicht in den Speicher schreiben zu müssen, was zu einer 15-fachen Beschleunigung führte
  • Auf einem Ryzen 7950X läuft dieser Prozess in Echtzeit
  • Danach werden die Schallquellenposition zu jedem Zeitpunkt und die Position jedes Mikrofons per Gradientenabstieg optimiert
    • Die Loss Function minimiert die Differenz zwischen gemessener und idealer Korrelation
    • Mikrofonpositionen sollen nicht zu stark von ihren Ausgangspositionen abweichen
    • Auch der Ruck der Schallquellenbahn wird reduziert
  • Während der Kalibrierung wird auch die Schallgeschwindigkeit als Optimierungsparameter einbezogen, sodass der gesamte Prozess wie ein übermäßig komplexes Thermometer funktioniert
  • Nach Hunderten Iterationen konvergieren Größen wie Schallquellenposition, Mikrofonposition und Schallgeschwindigkeit zu plausiblen Lösungen
  • Dieses Problem eignet sich gut für GPU-Vektorisierung und konvergiert in wenigen Sekunden
  • Der endgültige mittlere Positionsfehler liegt bei etwa 1 mm
  • Auch großskalige systematische Verformungen wie Durchbiegung aufgrund mangelnder Struktursteifigkeit werden kalibriert
  • Der maximale Fehler zwischen Soll- und kalibrierter Position beträgt etwa 5 mm
  • Die Wellenlänge eines 10-kHz-Signals beträgt etwa 3,4 cm; ohne Kalibrierung können daher im Hochfrequenzbereich bedeutende Phasenfehler entstehen

Beamforming und Visualisierung

• Beamforming-Methode

  • Beamforming ist der Prozess, rohe Mikrofoneingänge zu verarbeiten und eine Richtantwort zu erzeugen
  • Die implementierte Methode ist das einfachste Delay-and-Sum, also DAS
  • Jedes Signal wird entsprechend dem Entfernungsunterschied zur Schallquelle verzögert und dann summiert
  • In diesem Projekt erfolgt das Beamforming im Frequenzbereich
    • Dort wird die Verzögerung als linearer Phasenterm proportional zur benötigten Verzögerung und als komplexe Multiplikation mit dem Signal umgesetzt
    • Auch Verzögerungen, die keine ganzzahligen Vielfachen der Abtastperiode sind, lassen sich so natürlich behandeln
  • Die verschiedenen überlappenden Subarrays des ursprünglichen Arrays werden je nach Frequenzbereich verwendet
  • Da nicht für alle Frequenzen mit allen Mikrofonen beamgeformt werden muss, sinkt der Durchsatzbedarf, und zugleich hilft das, den Beamforming-Gewinn über alle Frequenzen anzugleichen

• GPU-Implementierung auf Triton-Basis

  • Der Beamformer ist als Triton-Kernel implementiert
  • Triton ist ein Python-DSL, das zur Ausführung auf Nvidia-GPUs kompiliert wird
  • Bei Beamforming über Hunderttausende Punkte ermöglicht die massive Parallelität der GPU Echtzeitergebnisse
  • Wegen einer aktuellen Einschränkung in Triton bei der Unterstützung von Shared-Memory-Array-Indizierung ist die Performance leicht suboptimal, aber das Schreiben in CUDA C++ wurde nicht gewählt

• 3D-Beamforming im Nahfeld

  • 3D-Beamforming im Nahfeld wird auf einem 5-cm-Voxelraster ausgeführt
  • Die Rastergröße beträgt 64×64×64
  • Auf einer RTX 4090 wird eine Aktualisierungsrate von 12 Hz erreicht
  • Höhere Geschwindigkeiten werden durch nicht optimale CPU-GPU-Synchronisations-Overheads bei kleinen Workloads begrenzt
  • Das Voxelraster wird mit der OpenGL-basierten High-Performance-Visualisierungsbibliothek VisPy dargestellt
  • Das Rendern von 250.000 halbtransparenten Voxeln ist im Vergleich zur Polygonanzahl moderner Spiele bei interaktiven Frameraten unproblematisch

• 2D-Beamforming im Fernfeld

  • Bei weit entfernten Schallquellen sind die Wellenfronten nahezu eben, sodass die Entfernung der Quelle das Arraysignal nicht wesentlich verändert
  • Bei nahen Schallquellen ist die Krümmung der Wellenfront groß genug, um die 3D-Position zu bestimmen
  • Beamforming im Fernfeld kommt ohne Tiefendimension aus und kann daher mit höherer Auflösung ausgeführt werden
  • Es wird ein 512×512-Pixelraster verwendet, ebenfalls mit 12 Hz Aktualisierungsrate
  • Für das Fernfeld-Beamforming wird statt einer echten Ebenenwellen-Annahme die Näherung verwendet, Punkte sehr weit entfernt zu platzieren
  • Wegen vieler Reflexionen und Mehrwegeffekte im Raum wird die 2D-Visualisierungsdemo von der akustischen Umgebung beeinflusst

• Gerichtetes Audio

  • Die beiden vorherigen Beamforming-Implementierungen berechnen die Schallenergie an jedem Ort, erzeugen aber kein beamgeformtes Audio im Speicher
  • Für gerichtete Audioaufnahmen wurde ein Delay-and-Sum-Beamformer im Zeitbereich implementiert
    • Er nimmt 3D-Koordinaten relativ zum Zentrum des Arrays als Eingabe
    • Er gibt Audio-Samples aus
  • Dieser Beamformer ist in Bezug auf die Position differenzierbar
  • Die Position einer Audioquelle kann mit einer differenzierbaren Loss Function optimiert werden
  • Eine mögliche Anwendung wäre die Bestimmung der physischen Position jedes Sprechers in Mehrparteien-Transkriptionen mithilfe eines Forced-Alignment-Modells
  • Zur Demonstration spielt ein Lautsprecher vor dem Array Audio ab, während ein anderer Lautsprecher in gleicher Entfernung etwa 45 Grad vom Zentrum des Arrays entfernt White Noise wiedergibt
  • Der Vergleich zwischen rohem Audio eines einzelnen Mikrofons und beamgeformtem Audio zeigt den Effekt des Beamforming

Aufzeichnungsmethode und Grenzen

• Da die Daten des Mikrofonarrays als UDP-Pakete vorliegen, können sie mit Tools wie tcpdump aufgezeichnet werden
• Paket-Capture-Dateien können gelesen und die Pakete erneut in einen Listener eingespeist werden
• Die zuvor genannten Programme wurden zwar für den Echtzeitbetrieb entwickelt, funktionieren auf diese Weise aber auch mit aufgezeichneten Daten
• Der Nachteil ist, dass die Rohdaten unverändert gespeichert werden und die Ausgangsdatenrate dadurch sehr hoch ist
  • Selbst Quantisierungsrauschen wird vollständig mitgespeichert
  • Die Datenrate beträgt 87,5 MB/s
  • Für 1 Stunde Aufnahme sind 315 GB erforderlich
• Eine stärker optimierte Implementierung könnte Kompression anwenden oder erst nach dem CIC-Filter bei geringerer Abtastrate aufzeichnen

Mögliche Erweiterungen

• Das Projekt ist praktisch abgeschlossen, und in naher Zukunft sind keine weiteren Arbeiten geplant
• Trotzdem gibt es für alle, die es selbst bauen möchten, noch Erweiterungspotenzial
  • Einsatz fortgeschrittenerer Beamforming-Algorithmen wie DAMAS
  • Eine bessere GUI, die bestehende Funktionen kombiniert, etwa Schallquellen zu sehen und Audio genau dort aufzunehmen
  • Auch die Kombination aus differenzierbarem Beamforming und neuronalen Netzen wäre möglich, zum Beispiel für Anwendungen wie das Forced-Alignment-Beispiel

[GN⁺]

Hacker-News-Kommentare

• Interessant ist, dass bei der Kalibrierung auch die Schallgeschwindigkeit ein Parameter ist, der optimiert wird, um das beste Modell des Systems zu erhalten. Dadurch wirkt das ganze Verfahren wie ein absurd überentwickeltes Thermometer.
  Das erinnert an den Elektronik-Spruch: „Jeder Sensor ist ein Temperatursensor, und einige messen auch noch etwas anderes.“

  • In der Highschool habe ich mit Hilfe meiner Eltern ein Gerät gebaut, das misst, wie schnell der Druck in einem Druckzylinder abfällt, aus dem durch ein winziges Loch Luft entweicht.
    Es stellte sich heraus, dass man damit auch die Temperatur messen und durch Extrapolation der Kurve den absoluten Nullpunkt bestimmen konnte.
    Soweit ich mich erinnere, lag das Ergebnis um etwa 20 K daneben, was für ein Garagenprojekt eines Schülers ziemlich gut war.
  • Ich halte mich an die Regel, dass man bei Messungen über die Zeit unbedingt auch die Umgebungstemperatur mitmessen sollte.
  • Ich mag solche zufälligen Messungen.
    Besonders gefällt mir das Beispiel, dass eine hinreichend genaue Inertial Measurement Unit (IMU) über den Coriolis-Effekt sogar eine relativ genaue Längenbestimmung ermöglichen kann.
  • Ich frage mich, ob es auch einen Spruch gibt wie: „Alle elektronischen Geräte sind Rauchgeneratoren, und einige rechnen auch.“
  • Ich habe gerade erfahren, dass Duracell Powercheck© über Temperatur funktionierte.
    https://youtu.be/zsA3X40nz9w?si=oGg2wdUlLXSDxpsN

• Ich habe früher an einem Projekt gearbeitet, bei dem Fledermäuse mit einem Array aus 4 Mikrofonen, das in großer Y-Form auf dem Boden ausgelegt war, multilateriert wurden.
  Über die Laufzeitunterschiede zu den vier Mikrofonen konnten wir die Position jeder über das Array fliegenden Fledermaus bestimmen und auch die Art identifizieren.
  Das wurde in einer Studie eingesetzt, um die Umweltauswirkungen der Installation von Windkraftanlagen zu bewerten, und war ziemlich spannend.

  • Das erinnert mich an den Optical Fence von Intellectual Ventures.
    Das war ein Gerät, das entwickelt wurde, um Mücken mit kurzen Laserpulsen zu verfolgen und zu töten.
    Weil die räumliche Position der Mücken sehr genau erfasst werden musste, konnte man nebenbei anhand von Unterschieden in der Flügelschlagfrequenz Ziele nach Geschlecht und Art unterscheiden.
  • Mit 18 habe ich ein ähnliches Projekt gemacht.
    Natürlich fehlte es mir an Hardware- und Software-Know-how, daher implementierte ich den TDOA-Algorithmus in seiner naivsten Form, und auch die Schätzung der Zeitdifferenzen per Kreuzkorrelation war sehr ineffizient.
    Trotzdem habe ich viel gelernt, und am Ende führte es zu einer Promotion über SAR-Systeme.
    SAR sehe ich eigentlich eher als Beamformer, der statt eines Arrays die Bewegung der Plattform nutzt.
  • Ich frage mich, wie die Forschungsergebnisse ausgefallen sind.
    Ich habe einmal gehört, dass die Lungen von Fledermäusen so empfindlich sind, dass beim Durchfliegen der Druckdifferenzen großer Turbinen praktisch ihre Kapillaren platzen.
  • Ich würde so etwas gern ausprobieren, um Fledermäuse in meinem Garten zu verfolgen, frage mich aber, wie realistisch das als Amateurprojekt ist.
    Gute Hinweise, wo man anfangen könnte, wären hilfreich.
  • Das erinnert auch an die hervorragende, leise Arbeit des Cosys-Lab der Universität Antwerpen.
    Sie platzierten ein Mikrofonarray unter einem Skorpion und zeigten, wie eine Fledermaus ihren Ultraschallstrahl bewegt, um den Skorpion abzuscannen.
    Ein wirklich erstaunliches Ergebnis [0].
    [0]: https://www.youtube.com/watch?v=57ScSPWhGqU

• Ich frage mich, warum für das Array nicht TDM-I2S-Mikrofone, sondern PDM verwendet wurde.
  Der ICS-52000 ist relativ günstig, kostet bei 100 Stück etwa 2 Dollar pro Stück; es gibt auch Breakout-Boards mit 4 Mikrofonen, und soweit ich weiß, kann man 8 oder sogar 16 Stück in Reihe schalten.
  https://www.cdiweb.com/datasheets/notwired/ds-nw-aud-ics5200...
  Wenn man einen Jetson oder Hardware mit I2S-fähigem DSP/GPU nutzt, kann man pro I2S-Port 16 Mikrofone in Reihe schalten; das wirkt deutlich einfacher zu montieren und zu programmieren als ein FPGA-Setup.

  • Der wichtigste Punkt waren die Kosten.
    Bei 192 Mikrofonen macht der Unterschied zwischen 2 Dollar und 0,50 Dollar pro Stück einiges aus.
    Selbst mit 16er-Daisy-Chains ist es schwer, ein Gerät mit genügend I2S-Interfaces zu finden, und die meisten Geräte haben nicht die erforderliche Anzahl.
    Das FPGA und die maßgeschneiderte Hardware waren außerdem Teil des Spaßes.
  • Ich hatte vor ein paar Jahren danach gesucht; damals waren sie teurer und nur bis 20 kHz nutzbar.
    Für das Zischen von austretendem Gas oder die Koronaentladung elektrischer Lichtbögen sind höhere Frequenzen nützlich.
    Der Orin hat intern 6 I2S-Ports, also scheinen 16*6 = 96 Mikrofone möglich zu sein, was schon eine ziemlich gute Zahl ist.
    In der Praxis sind aber offenbar nur 3 nach außen geführt, und sie liegen wohl auf verschiedenen Entwicklerboard-Anschlüssen [1].
    Wie immer liegen die Schwierigkeiten im Detail; wenn man mehr als 96 Mikrofone braucht, ist ein FPGA möglicherweise einfacher zu konfigurieren.
    Die Teile, die ich mir notiert hatte, waren: 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...
  • Ich hatte überlegt, selbst ein Phased Array zu bauen, kam aber nie bis zur PCB-Fertigung.
    Es gibt ungefähr zwei Gründe, warum I2S nicht die beste Wahl ist.
    I2S benötigt 3 Pins statt der 2 Pins von PDM.
    Wenn man die Mikrofone allerdings wie im verlinkten Datenblatt als Daisy-Chain betreiben kann, ist das ziemlich elegant, und auch wenn es kein Standard-I2S ist, verschwindet dieser Einwand.
    PDM ermöglicht den Zugriff auf eine deutlich höhere Abtastrate, wodurch man beim Delay-and-Sum-Verfahren flexibler bei der Wahl der Verzögerung ist.
    Wenn der PDM-Takt zum Beispiel 2 MHz beträgt, kann man theoretisch mit 0,5 µs Genauigkeit verzögern.
    In der Praxis würde man wohl mit geringerer Genauigkeit arbeiten, aber ein I2S-Takt liegt normalerweise höchstens bei etwa 192 kHz.
    PDM-Mikrofone sind außerdem günstiger.

• Wenn man auf YouTube nach Akustikkamera sucht, findet man ziemlich beeindruckende Demos, die die Leistungsfähigkeit zeigen.
  Eines der Unternehmen, das ich eine Weile beobachtet habe, ist dieses hier; offenbar steigen auch größere Anbieter wie FLIR in den Bereich ein: https://www.youtube.com/@gfaitechgmbh
  Ein interessanter, aber unheimlicher Anwendungsfall wäre, öffentliche Orte aufzuzeichnen und später auf ein Gespräch zwischen bestimmten Personen „hineinzuzoomen“.

  • Mich interessiert sehr, wie klein solche Arrays werden können.
    Nach einem Gespräch mit einem Freund, der ein Cochlea-Implantat trägt, denke ich, dass das mit passender Signalverarbeitung eine große Hilfe beim Hören sein könnte.

• Ich würde gern wieder Doktorand werden und versuchen, das mit Ultraschall-Lautsprecherarrays für medizinische Anwendungen zu kombinieren.
  Im Grunde wäre das so etwas wie ein extrem leistungsfähiges HIFU (hochintensiver fokussierter Ultraschall) mit Echtzeit-Feedback.
  https://en.wikipedia.org/wiki/Focused_ultrasound

  • Ich promoviere zu Ultraschall-Phased-Arrays in Luft und spreche auf Konferenzen und in Laboren mit Leuten aus dem Medizinbereich; in Festkörpern und Flüssigkeiten ist das deutlich schwieriger.
    Die Frequenzen sind viel höher: Man muss eher an 1–10 MHz denken, nicht an 40 kHz, und gewöhnliche Elektronik ist praktisch nicht nutzbar.
  • Ein Problem ist, dass beim Durchgang von Schallwellen durch Festkörper und Flüssigkeiten die Schallgeschwindigkeit nicht konstant über die gesamte relevante Bandbreite ist.
  • Der FUS-Doktorand, den du suchst, könnte ich sein.
    Wenn du darüber sprechen möchtest, melde dich über die E-Mail in meinem Profil.
  • Für medizinische Anwendungen braucht man wahrscheinlich Kontaktkopplung statt Ausbreitung in Luft.

• Ich würde mir wünschen, dass diese Technik in gut verpackter Form in viele Mobilgeräte kommt.
  Einer der Gründe, warum Assistenten und universelle Übersetzer nicht richtig funktionieren, ist meiner Ansicht nach die schlechte Audioqualität.
  Rauschunterdrückung und Richtungserkennung könnten hier sehr hilfreich sein.
  Ich würde zum Beispiel gern ein Gruppengespräch am Esstisch in Echtzeit übersetzen.
  Zunächst wäre es schön, wenn Smartphones und Kopfhörer ihre jeweiligen Mikrofone für solche Zwecke kombinieren könnten.
  Noch weiter gedacht: Was wäre, wenn alle Smartphones in der Nähe zusammenarbeiten könnten, um hochwertige gerichtete Audiodaten bereitzustellen?
  Natürlich unter der Voraussetzung, dass sich die Datenschutzprobleme lösen lassen.

  • Für Menschen mit Hörverlust wie mich wäre Live-Untertitelung in lauten Umgebungen wie Treffen oder Partys, inklusive Trennung und Gruppierung verschiedener Sprecher, die Killer-App.
    Das könnte das Leben verändern.
    Live Transcribe von Android ist inzwischen sehr gut, versucht aber nicht einmal zu trennen, welches Wort von welchem Sprecher stammt.
  • Aktuelle MacBook Pro haben bereits mehrere Mikrofone und machen vermutlich schon etwas Ähnliches wie ein Phased Array.
  • Das ist als Cocktailparty-Problem bekannt.
    Es zeigt, wie viel Verarbeitung unser Gehirn leistet, damit wir in einem lauten Raum verstehen können, was jemand zu uns sagt.
    https://en.wikipedia.org/wiki/Cocktail_party_effect?wprov=sf...
  • Um Phasenverschiebungen korrekt zu berechnen, muss man im Allgemeinen die Mikrofonpositionen im Raum genau kennen, und die Uhren der Smartphones müssten mit sehr hoher Präzision synchronisiert sein.
    Grob gesagt auf etwa das Zehnfache der höchsten zu erfassenden Audiofrequenz, also innerhalb von Zehntausendstelsekunden.
    Außerdem wird der Code, also die Mathematik, zur Extraktion eines verbesserten Signals sehr schwierig, wenn die Positionen der Array-Mikrofone nicht auf einer Linie, einem Kreis oder einer anderen einfachen Geometrie liegen.

• Boeing hat eine kugelförmige Version eines solchen Geräts gebaut und sie bei den 787-Prototypen verwendet, um Kandidaten für Schalldämmmaterial zu finden.
  In einer lauten Umgebung wie einem Flugzeug können auditive Illusionen dazu führen, dass man Geräusche an einer anderen Stelle wahrnimmt, als sie tatsächlich entstehen.
  Wenn es für Schalldämmmaterial ein festes Gewichtbudget gibt, ist es wichtig, den 80/20-Punkt richtig zu treffen.

• Wenn du mit dem Zynq 7010 herumspielen möchtest, lohnt sich ein Blick auf das EBAZ4205-Board.
  Es kostet bei AliExpress 20–30 Euro und war früher ein Bitcoin-Mining-Controller.
  Einige Leute haben es vollständig reverse-engineert und auf GitHub gestellt, und es gibt auch Adapterplatinen für den Zugriff auf die GPIOs.
  Wenn du weniger komplex einsteigen willst, gibt es auch chinesische FPGAs wie die „Sipeed“-Boards mit GoWin-FPGA.
  Die sind ziemlich brauchbar, und die IDE ist kostenlos.

  • Die Xilinx-Toolchain ist ebenfalls kostenlos.

• Ich bin gestern Abend bei der Recherche genau auf dieser Seite gelandet.
  Ich frage mich, ob jemand weiß, wie man Mikrofone in einem Raum installiert, um nur Audio aus einem bestimmten Bereich aufzunehmen.
  Mein Anwendungsfall wäre, die Couch aufzunehmen, während ich mit Online-Freunden fernsehe, und dabei die Stimmen der Freunde und den Ton der Sendung aus dem Audio zu entfernen.
  Mit einem Mikrofonarray und Beam Steering müsste das möglich sein, aber ich habe auf GitHub nicht viele Codebeispiele gefunden, die in Echtzeit funktionieren.

  • Wenn du dir OBS oder VoiceMeeter ansiehst, bekommst du einen Eindruck davon, wie Streamer Audio während Livestreams oder Aufnahmen selektiv routen.
    https://obsproject.com/
    https://voicemeeter.com/
  • Der laute Fernsehton und das nahe Audio deiner Online-Freunde werden im Raum und an deinem Körper reflektiert.
    Was du brauchst, ist nicht Mikrofon- oder Beamforming-Technik, sondern Echo Cancellation, wie sie jede Videokonferenzsoftware verwendet.
    Du gibst den Sendungston und das Audio der Freunde als Eingänge hinein und wendest jeweils Echo Cancellation darauf an.
  • Wie im Artikel erwähnt, ist „die einfachste Beamforming-Methode Delay-and-Sum (DAS)“.
    Man misst die Entfernung von einem Punkt, also der Couch, zu jedem Mikrofon, verzögert die Signale im Zeitbereich um die Zeit, die der Schall von der Couch bis zum jeweiligen Mikrofon braucht, und addiert sie dann.
    Im Grunde versucht man, die Mikrofonsignale so auszurichten, als hätten alle Mikrofone das Couch-Signal zur gleichen Zeit empfangen, obwohl sie unterschiedlich weit entfernt sind.
    Damit diese Methode wirkt, müssen die Abstandsunterschiede zwischen den Mikrofonen ausreichend groß sein.