Ich versuche, den Frequenzgang eines INMP441-Mikrofons mit einem ESP32 und einem Python-Skript zu messen. Der ESP32 erfasst 6000 Samples über I²S und sendet sie seriell. Ich spiele mit Python (
) und richten Sie dann das aufgezeichnete Mikrofonsignal am Sweep aus, um die Übertragungsfunktion zu berechnen.
Das resultierende Frequenzgangdiagramm ist jedoch falsch. Es zeigt entweder eine flache Linie, unerwartete Einbrüche oder verrauschte Artefakte. Ich vermute, dass der Sweep nicht richtig erfasst wird, bin mir aber nicht sicher, wo das Problem liegt.
Ich kann meinen Arduino-Code leider nicht posten, aber hier sind einige Hinweise:
Relevantes Arduino-Setup
ESP32 sendet „READY“ über die serielle Schnittstelle
Erfasst dann 6000 Samples vom Mikrofon
Wendet DC-Offset-Entfernung und -Filterung an
Sendet die rohen Float-Samples seriell zwischen „DATA_START“ und „DATA_END“
Was meiner Meinung nach schief gehen könnte
Timing-Diskrepanz: Der ESP32 beginnt mit der Aufnahme, bevor der Sweep abgespielt wird, sodass er den Sweep möglicherweise ganz verpasst oder nur einen Teil davon erfasst.
Sweep nicht laut genug: Der Sweep erreicht das Mikrofon möglicherweise nicht deutlich oder das Mikrofon ist zu weit vom Lautsprecher entfernt.
Ausrichtungsfehler: Wenn der Sweep nicht sauber erfasst wird, findet die Kreuzkorrelation in Python nicht die richtige Verzögerung, was zu einem falsch ausgerichteten oder leeren „aligned_mic“-Array führt.
Fenster- oder FFT-Artefakte: Wenn die Ausrichtung auch nur um ein paar Samples abweicht, wird die FFT-basierte Übertragungsfunktion verzerrt.
Wie kann ich sicherstellen, dass der ESP32 den Sweep erfasst, während er abgespielt wird?
Gibt es eine bessere Möglichkeit, die Sweep-Wiedergabe und die Mikrofonaufnahme zu synchronisieren, ohne den Arduino-Code zu ändern?
Gibt es Best Practices für die vorherige Ausrichtung und Validierung des erfassten Signals? Berechnung der Übertragungsfunktion?
Ich versuche, den [b]Frequenzgang eines INMP441-Mikrofons[/b] mit einem ESP32 und einem Python-Skript zu messen. Der ESP32 erfasst 6000 Samples über I²S und sendet sie seriell. Ich spiele mit Python ([code]sounddevice.play()[/code]) und richten Sie dann das aufgezeichnete Mikrofonsignal am Sweep aus, um die Übertragungsfunktion zu berechnen. Das resultierende Frequenzgangdiagramm ist jedoch falsch. Es zeigt entweder eine flache Linie, unerwartete Einbrüche oder verrauschte Artefakte. Ich vermute, dass der Sweep nicht richtig erfasst wird, bin mir aber nicht sicher, wo das [url=viewtopic.php?t=26065]Problem[/url] liegt. Ich kann meinen Arduino-Code leider nicht posten, aber hier sind einige Hinweise: Relevantes Arduino-Setup [list] [*][b]Mikrocontroller[/b]: ESP32
[*][b]Mikrofon[/b]: INMP441 (I²S-Digitalmikrofon)
[*][b]Abtastrate[/b]: 48.000 Hz
[*][b]Puffergröße[/b]: 6000 Samples (≈125 ms)
[*][b]I²S-Konfiguration[/b]:
[code]I2S_MODE_MASTER | I2S_MODE_RX[/code]
[*][code]I2S_BITS_PER_SAMPLE_32BIT[/code]
[*][code]I2S_CHANNEL_FMT_ONLY_LEFT[/code]
[/list]
[*][b]Datenfluss[/b]: [list] ESP32 sendet „READY“ über die serielle Schnittstelle
[*]Erfasst dann 6000 Samples vom Mikrofon
[*]Wendet DC-Offset-Entfernung und -Filterung an
[*]Sendet die rohen Float-Samples seriell zwischen „DATA_START“ und „DATA_END“
[/list]
Was meiner Meinung nach schief gehen könnte [list] [*][b]Timing-Diskrepanz[/b]: Der ESP32 beginnt mit der Aufnahme, [b]bevor[/b] der Sweep abgespielt wird, sodass er den Sweep möglicherweise ganz verpasst oder nur einen Teil davon erfasst.
[*][b]Sweep nicht laut genug[/b]: Der Sweep erreicht das Mikrofon möglicherweise nicht deutlich oder das Mikrofon ist zu weit vom Lautsprecher entfernt.
[*][b]Ausrichtungsfehler[/b]: Wenn der Sweep nicht sauber erfasst wird, findet die Kreuzkorrelation in Python nicht die richtige Verzögerung, was zu einem falsch ausgerichteten oder leeren „aligned_mic“-Array führt.
[*][b]Fenster- oder FFT-Artefakte[/b]: Wenn die Ausrichtung auch nur um ein paar Samples abweicht, wird die FFT-basierte Übertragungsfunktion verzerrt.
[/list] [list] [*]Wie kann ich sicherstellen, dass der ESP32 den Sweep erfasst, [b]während[/b] er abgespielt wird?
[*]Gibt es eine bessere Möglichkeit, die Sweep-Wiedergabe und die Mikrofonaufnahme zu synchronisieren, ohne den Arduino-Code zu ändern?
[*]Gibt es Best Practices für die vorherige Ausrichtung und Validierung des erfassten Signals? Berechnung der Übertragungsfunktion?
[*]Berechne ich den Frequenzgang richtig?
[/list] Das ist mein Python-Code: [code]import numpy as np import matplotlib.pyplot as plt import serial import time import sounddevice as sd from scipy.signal import chirp, correlate, windows
# === Wait for ESP32 === ser = serial.Serial(SERIAL_PORT, BAUD_RATE, timeout=SERIAL_TIMEOUT) print("Waiting for READY from ESP32...") while True: line = ser.readline().decode('utf-8', errors='ignore').strip() if line == "READY": print("ESP32 is ready. Playing sweep...") break
# === Play Sweep === sd.play(sweep, samplerate=FS) sd.wait()
# === Receive Mic Signal === print("Waiting for DATA_START...") raw_data = [] while True: line = ser.readline().decode('utf-8', errors='ignore').strip() if line == "DATA_START": raw_data = [] continue elif line == "DATA_END": break else: try: raw_data.append(float(line)) except ValueError: continue ser.close()
mic_signal = np.array(raw_data) if len(mic_signal) < 6000: print(f"⚠️ Only {len(mic_signal)} samples received — expected 6000.") exit()
if len(aligned_mic) != N_SAMPLES: print(f"⚠️ Alignment failed: got {len(aligned_mic)} samples instead of {N_SAMPLES}") exit()
aligned_mic *= windows.hann(N_SAMPLES)
# === Compute Transfer Function === S = np.fft.rfft(sweep, NFFT) M = np.fft.rfft(aligned_mic, NFFT) H = M / (S + 1e-12) freqs = np.fft.rfftfreq(NFFT, 1 / FS)
Ich baue einen Open-Source-Audiospektrumanalysator für die Lautsprecherherstellung. Das „Killer -Feature“ verwendet einen logarithmischen Sweep als Anregungssignal und analysiert die Antwort , wenn...
Ich muss ein lokales Autoplay-Video auf meiner Website implementieren. Dennoch wusste ich, dass neuere Browser, d. h. Chrome, Mozilla und Safari, die automatische Wiedergabe blockiert haben, wenn das...
Für iOS17 hatten wir keine Probleme beim Abspielen von Apple Fairplay-verschlüsselten Inhalten mit Schlüsseln, die von unserem Schlüsselserver geliefert wurden, der auf FairPlay Streaming Server SDK...
Für iOS17 hatten wir keine Probleme beim Abspielen von Apple Fairplay-verschlüsselten Inhalten mit Schlüsseln, die von unserem Schlüsselserver geliefert wurden, der auf FairPlay Streaming Server SDK...
Wir versuchen, einen Videostream auf der Android-Plattform abzuspielen, aber
erfolglos.
Mit VideoView können wir mobile YouTube-Videos abspielen (z. B.
diese URL funktioniert einwandfrei:...