Ich bekomme ein Knowles SPH0645LM4H, welches einen I2S Ausgang haben soll. Ich habe mich schon schlau gemacht, wie Ich das auswerten kann und fand diesen Beitrag: Beitrag "Knowles Acoustics KJ-33000 MEMS Joystick" (da liegt aber ein PDM-Ausgang vor). Ich habe mir das Datenblatt angesehen und stelle fest, dass einmal das I2C von MIR! erzeugt werden muss(?) und zudem auch das timing nicht ganz dem zu entsprechen schein, was ich im WIKI Artikel und bei Philips gefunden habe. Es geht einmal um das WD / WPS - Signal, das manchmal verwendet wird und manchmal nicht und darum, wenn es gesetzt werden muss. Im Dokument von Knowles liegt es einen halben Takt vor dem neuen Datenwort, in den anderen einen ganzen! Was Ich auch nicht verstehe, ist, warum ICH das Takten machen muss, und damit Master bin, während eigentlich das Mikrofon den Takt vorgeben müsste, da es selbst ja die Quelle ist. Ich wäre natürlich in der Lage, ein I2S-timing zu machen, bin aber wiederum unschlüssig wegen der Datenrate: Im Konfigurator wird als Beispiel für 44,1kHz eine Frequenz von 2x44,1+64 Bit angesetzt, als Samplefrequenz. Das ist mir plausibel, wenn es Stereo wäre, wobei Ich nicht auf 64 Bits, sondern 32 komme. (?) Kann man bei I2S die Datenwortlänge beliebig wählen? D.h. kann Ich schon nach 2x 24 Bit das Word umschalten? Das KowlesMikrofon liegt fest auf 18 Bit, sendet ansonsten Nullen! Woher kommen die 18? Der Delta-Sigmamodulator müsste doch eine beliebige Anzahl Bits an Auflösung liefern können, von mir aus mit Rauschen. Wäre schön, wenn sich diese Fragen klären liessen.
Angehängte Dateien:
-
i2s-bus-timing-mems.gif
24 KB
Angehängte Dateien:
-
I2S-Schema.gif
32 KB
Bei I2S gibt es immer nur einen Master im System und da es schwierig ist, mehrere digitale Audioquellen gut genug zu synchen oder zu resamplen, macht das schon Sinn, das timing von Außen vorzugeben. Üblicherweise sieht es bei I2S so aus, dass der Datentakt (nicht Sampletakt) bis zum 64-fachen des Worttaktes entspricht. Das ist z.B. nutzbar, um IF zu bedienen, wenn man nur einen Monokanal hat, aber die Bits füllen muss. Normalerweise überträgst Du ein Doppelwort, also "Stereo" und wechselst das Wortbit, was einen Takt vorher kommt. Warum es bei dem Mikro nicht so ist, kann damit zusammenhängen, dass es für zwei Auswertekanäle gedacht ist. Soweit Ich mich erinnere, kann man je Takt zwei Mikros anbauen, wobei das eine auf der invertierten Flanke arbeitet. Das müsste Das Datenblatt aber erklären. Für einen typischen Stereo-DAC hätte man 2x24 Bit, also 48 Bit Wortlänge mit einem Wechsel in der Mitte. Das kann man durchaus auch so ansteuern. Das wären aber 48x die Samplefrequenz. Wenn im System aber nur die 64fache vorliegt, wie z.B. bei S/PDIF dann müssen die restlichen eben aufgefüllt werden. Zu den 18 Bit: Die Dezimation nach einem Delta-Sigma ist recht willkürlich und hängt von der Filterbreite und Tiefe ab. Wenn der nicht mehr ausgibt, müsstest Du auch nicht mehr auslesen. Ist halt die Frage, mit welchen Takten zu ankommst und arbeiten kannst. Viel anzusteuern gibt es eigentlich nicht. Der LR-Umschalter ist nichts anderes, als der Takt mit einem Bit-CC Vorlauf.
Ingenieur schrieb: > Im Konfigurator wird als Beispiel für 44,1kHz eine Frequenz von > 2x44,1+64 Bit angesetzt, als Samplefrequenz. Das ist mir plausibel, wenn > es Stereo wäre, wobei Ich nicht auf 64 Bits, sondern 32 komme. (?) "2x44,1+64 Bit angesetzt, als Samplefrequenz" ist sicher falsch. Die Bitclock ist 44100 x 2 x 32 = 2.8224 MHz (bei 32-bit Wortlänge pro Kanal). > Kann man bei I2S die Datenwortlänge beliebig wählen? D.h. kann Ich schon > nach 2x 24 Bit das Word umschalten? Ja, kannst du. Dann wäre die Bitclock (BCLK) 44100 x 2 x 24 = 2.1168 MHz Die BCLK sollte sehr jitterfrei sein. Jitter -> schlechtes Audio. > > Das KowlesMikrofon liegt fest auf 18 Bit, sendet ansonsten Nullen! Woher > kommen die 18? Aufpassen... Es sendet dann nicht Nullen, sondern der Ausgang geht tri-stated. Die Bits nach dem 18. Bit solltest du also in jedem Fall ausfiltern. > Der Delta-Sigmamodulator müsste doch eine beliebige > Anzahl Bits an Auflösung liefern können, von mir aus mit Rauschen. 18 Bit sind -108dB. Mehr gibt das Mikro analogtechnisch (SNR) bestimmt nicht her, daher kann man hier getrost mit dem Wandeln aufhören. Jürgen S. schrieb: > Normalerweise überträgst Du ein Doppelwort, also "Stereo" und wechselst > das Wortbit, was einen Takt vorher kommt. Warum es bei dem Mikro nicht > so ist, kann damit zusammenhängen, dass es für zwei Auswertekanäle > gedacht ist. Soweit Ich mich erinnere, kann man je Takt zwei Mikros > anbauen, wobei das eine auf der invertierten Flanke arbeitet. Das müsste > Das Datenblatt aber erklären. Genau so ist es. Dafür gibt es den SEL input, der dem Mikro sagt, auf welchem Kanal es Daten auf DATA anlegen darf. Wenn der andere Kanal selektiert ist (WS), schaltet das Mikro seinen Ausgang auf tri-stated. So kann man 2 Mikros an eine I2S Datenleitung hängen. Korrektur > Kann man bei I2S die Datenwortlänge beliebig wählen? D.h. kann Ich schon > nach 2x 24 Bit das Word umschalten? Geht laut Datenblatt nicht. Es muss 2x32 Bit sein. "The Over Sampling Rate is fixed at 64 therefore the WS signal must be BCLK/64 and synchronized to the BCLK. "
:
Bearbeitet durch User
Joe F. schrieb: > So kann man 2 Mikros an eine I2S Datenleitung hängen. Ah, dann kriegt man so quasi automatisch die beiden Stereokanäle vollgefüllt.(?)
Genau. Es gibt auch MEMS-Mikros mit TDM-Ausgang (https://www.invensense.com/products/ics-52000/) die die Zusammenschaltung von bis zu 16 Stück auf einer Leitung erlauben.
:
Bearbeitet durch Admin
Interessant, wäre mal eine Option für ein Mic-Array, mein DSP hat ja quasi einen 64fach TDM-Input. Wobei Ich gerade sehe: "The ICS‐52000 has a high SNR of 65 dB" Ganze 65dB. Der Tontechniker in mir bekommt da das Zittern. :-)
Jürgen S. schrieb: > "The ICS‐52000 has a high SNR of 65 dB" > > Ganze 65dB. Der Tontechniker in mir bekommt da das Zittern. :-) Die 65dB SNR vermutlich nur bei 117 dB SPL?
Das SNR ist bei 94 dB @1 kHz gemessen (https://www.invensense.com/wp-content/uploads/2015/02/Low-Self-Noise-The-First-Step-to-High-Performance-MEMS-Microphone-Applications.pdf). Aussagekräftiger als SNR-Angaben finde ich bei Mikrofonen das equivalent input noise, welches beim ICS-52000 mit 29 dB(A) angegeben ist.
Das ist jetzt aber nicht so der großartige Wert. Spricht für eine geringe Empfindlichkeit.
> Im Dokument von Knowles liegt es einen halben Takt vor dem neuen > Datenwort, in den anderen einen ganzen! Weiß jemand, warum so es it?
> Im Dokument von Knowles liegt es einen halben Takt vor dem neuen > Datenwort, in den anderen einen ganzen! Ich weiß nicht, ob das I2S Philips Protokoll ist?
Angehängte Dateien:
-
i2s.png
40 KB
W. Y schrieb: >> Im Dokument von Knowles liegt es einen halben Takt vor dem neuen >> Datenwort, in den anderen einen ganzen! > > Weiß jemand, warum so es it? Tja, da sagst du was. Lt. Datenblatt von Knowles weicht das Datenformat von Standard I2S ab. DATA wird üblicherweise auf steigender CLK Flanke übernommen und bei fallender CLK Flanke geändert. Bei Knowles sieht das falsch aus (Daten sind um 1/2 CLK nach vorne verschoben (zu früh)). Ich würde mal davon ausgehen, dass das Datenblatt falsch ist. Miss CLK und DATA und WS doch einfach mal mit einem Oszilloskop an einem dieser Mikrofone.
:
Bearbeitet durch User
Ich würde sagen, dass das einfach das Ausgangstiming ist. Wenn man das mit dem Zieltakt einsampelt, macht es keinen Unterschied. Ist aber schon etwas verwirrend. Wenn Ich mir die Grafik nochmal ansehe, dann macht der Taktbezug zu den Daten jedenfalls Sinn, da der Takt bei dem Fall des Mikrofons ja vom Empfänger kommt. Um das direkt mit I2S Senden zu vergleichen, müsste man die Grafiken also um einen halben Takt versetzen, in der Annahme dass der "Leser" dem Mikro einen invertierten Takt schickt, um selber mit der steigenden lesen zu können. Aus der Sicht wäre das Knowles Mikro also einen halben Takt zu früh mit dem WORD Signal, was aber wie gesagt Wurscht ist.
> Um das direkt mit I2S Senden zu vergleichen, müsste man > die Grafiken also um einen halben Takt versetzen, in der Annahme dass > der "Leser" dem Mikro einen invertierten Takt schickt, um selber mit der > steigenden lesen zu können kann jemand hier nochmal erklären? Was genau "Leser" und Empfänger sind hier gemeint?
:
Bearbeitet durch User
Y. W. schrieb: > kann jemand hier nochmal erklären? Meiner Meinung nach ist Jürgens Theorie nicht richtig. Denn dann wäre auch WS auf der falschen Clock Flanke. Der Standard sieht einfach vor, auf fallender Flanke Signale zu ändern (sowohl WS als auch Daten), und auf steigender Flanke zu übernehmen. Da nützt also ein invertieren der Clock nichts, und es wäre auch unverständlich, warum man das tun sollte. Das Mikro wäre damit inkompatibel zu anderen Bauteilen, die I2S sprechen. Wie gesagt, ich würde mal an einem Mikro die Signale messen, und bin ziemlich sicher, dass es sich um einen Fehler im Datenblatt handelt und sich die vom Mikro ausgegebenen Signale standardgemäß auf fallenden CLK Flanken ändern.
Das ist aber doch das, was Ich meinte: Wenn der Empfänger der Mikrosignale den Takt vorgibt, muss er ihn invertieren, damit der Sender den Takt erhält, mit dem arbeiten kann. Wenn man sich das Knowles-Diagram ansieht, dann tut das Mikro auch genau das. Es sendet die Daten mit dem steigenden Takt, bis auf eben das WS. Das, was oben im Diagram als I2s angegeben ist, ist damit das Timing des Senders. Wenn als ein FPGA linksseitig das Mikro auslesen will und Emfänger ist, muss er so verfahren, wie oben beschrieben (in der Annahme, dass er inmitten des Bits lesen will). Er selber ist aber gegenüber z.B. einem I2S-Gerät selber Sender, muss also so verfahren, wie im ersten Diagramm, also auf fallender Flanke senden. Das wiederum tut der FPGA, indem er intern nach wie vor auf steigender Flanke arbeitet und eben einen solchen negierten Takt rausgibt. Mit diesem kann dann z.B. ein I2S-Empfänger arbeiten. Für mich ist das so alles konsistent, bis eben auf das Verhalten des angebliche WS des Knowles. Ich mache das auch so: Ich habe an meiner Workstation u.a. I2S-Empfänger dran, die mir ein S/PDIF Signal erzeugen können. Die kriegen alles Daten edge aligend und aufgrund des invertierten Taktes sehen sie center aligend Daten. Ich könnte jetzt mal ausprobieren, das WS zu verschieben, denke aber, dass das ebenfalls funktioniert, weil die FPGA-Ausgänge schnell genug sind, dass es der Empfänger trotzdem kapiert.
Jürgen S. schrieb: > Wenn der Empfänger der Mikrosignale den Takt vorgibt, muss er ihn > invertieren, damit der Sender den Takt erhält, mit dem arbeiten kann. Guck bitte mal in die I2S Spec. Es ist letztlich egal, wer Sender und wer Empfänger ist. Die Spec sagt einfach, dass Daten und WS immer auf fallender CLK Flanke geändert werden, und auf steigender Flanke übernommen werden. Das gilt für alle Sender und für alle Empfänger gleichermaßen. Wirklich. Ich habe hier mehrere Systeme mit ADCs und DACs, die Datenbits sind alle auf die fallenden Flanken aligned (genauso wie WS). Ein FPGA der sowohl Daten rausschickt und empfängt muss intern mit einer invertierten Clock arbeiten, und da ist es dann so, dass die ausgehenden Signale 1/2 bit vor den eingehenden Signalen liegen. Intern. Auf dem Bus ist alles auf die fallende Flanke aligned.
:
Bearbeitet durch User
Joe F. schrieb: > Guck bitte mal in die I2S Spec. Jaaaaaa, eben: > Die Spec sagt einfach, dass Daten und WS immer auf fallender CLK Flanke > geändert werden Das geht aber im FPGA und einem DSP mit Taktfrequenz nicht, daher muss man den internen Takt vom externen gedanklich trennen. > Es ist letztlich egal, wer Sender und wer Empfänger ist. Nein, es ist dann nicht egal, wenn der Sender wie im Fall der Mikrofone passiv ist und laut dessen Datenblatt auf dem steigenden Takt ändert. Dann muss, wie ich es beschrieben habe, der Takt nach Außen negiert werden, um auf dem Bus die Verhältnisse zu schaffen, wie sie nach I2S sein sollen. Du kannst natürlich fordern, dass das Mikros anders herum funktionieren sollen, allerdings hast Du immer das Problem, dass der (ich nenne Ihn mal slave) erst mit Verzögerung auf den Takt reagiert und dann die eigene Flanke niemals in der Mitte liegen kann. Das Ganze ist bei geringen Frequenzen egal, aber wenn Du mit 4 MHz auslesen willst und den Takt ins Mikro bringst, dann hat der schon eine gewisse Verzögerung und der Chip nochmal. Das sind dann schon mal 10ns und damit fast die Hälfte von den 25 der ganzen Periode. Ergo wird der Takt nach Aussen negiert und man sitzt perfekt in der Mitte. Beim FPGA ist es natürlich weniger ein Problem, weil der mit dem Takt, der Phase und auch mit kleinen Delays spielen kann, aber bei DSPs hat man diese Möglichkeit nicht. Da ist Takt = Takt. Es geht hier also um die konkrete technische Umsetzung und nicht um ein neues Prinzip oder eine andere Spec. Ich habe schon solche Mikros angesteuert und ausgewertet nur halt eben nicht diese Knowles von daher ist mir nicht Erinnerung, ob und warum dort eine Abweichung ist. Im Übrigen ist es mit anderen "Sendern" ähnlich: Ich nutzt z.B. auch S/PDIF receiver Bausteine, die einen Takt "empfangen" und zwar von mir. Die geben die Daten auch entsprechend ab, damit Ich mit der steigenden Flanke operieren kann.
Jürgen S. schrieb: > Nein, es ist dann nicht egal, wenn der Sender wie im Fall der Mikrofone > passiv ist und laut dessen Datenblatt auf dem steigenden Takt ändert. > > Dann muss, wie ich es beschrieben habe, der Takt nach Außen negiert > werden, um auf dem Bus die Verhältnisse zu schaffen, wie sie nach I2S > sein sollen. > > Du kannst natürlich fordern, dass das Mikros anders herum funktionieren > sollen, allerdings hast Du immer das Problem, dass der (ich nenne Ihn > mal slave) erst mit Verzögerung auf den Takt reagiert und dann die > eigene Flanke niemals in der Mitte liegen kann. Also ich kann dir um ehrlich zu sein nicht folgen. Der Standard definiert ganz klar das Protokoll auf dem Bus. Das Mikrofon hat dafür zu sorgen, dass es die Daten auf der richtigen CLK Flanke auf den Bus legt (und zwar auf der fallenden). Das tut es nach Datenblatt nicht. Damit darf man das Protokoll, das das Mikrofon spricht eigentlich nicht mehr I2S nennen. Man kann sich jetzt natürlich extern (im FPGA, Controller oder whatever) auf dieses Sonderformat einstellen, nur: ich glaube nicht, dass das Mikrofon so einen "Müll" ausgibt. Einen Fehler im Datenblatt halte ich da für wahrscheinlicher. Darum ja die Bitte an TO, die Signale mal an einem lebenden Exemplar aufzuzeichnen. Ich habe vermutlich in ein paar Wochen sowieso mit genau so einem Mikrofon zu tun, wenn bis dahin keine Messung vorliegt, liefere ich die eben... Jürgen S. schrieb: >> Die Spec sagt einfach, dass Daten und WS immer auf fallender CLK Flanke >> geändert werden > Das geht aber im FPGA und einem DSP mit Taktfrequenz nicht, daher muss > man den internen Takt vom externen gedanklich trennen. Selbstverständlich geht das. Man muss eben intern eine invertierte Clock verwenden, wenn man nur auf steigende Clock Flanken reagieren kann. Mit dieser invertierten Clock gibt man Daten aus, mit der nicht invertierten übernimmt man Daten vom Bus.
Kann es eigentlich sein, dass wieder irgenwo ein Prof ein Audioprojekt als Studienthema beauftragt hat und nun alle Studis rauslaufen und die Foren nach dem Thema durchforsten oder warum haben wir I2S-Wochen im Forum: Beitrag "I2S Multiplexer Realisierung" Beitrag "Hilfe zu Implementierung von I2S Interface in VHDL" Beitrag "I2S Masterclock generieren ?" Beitrag "I2S Framesynchronisation"
Ich habe Mikrofon mit I2S Philips konfiguriert und mit Oszilloskop den Wellenform geschaut. Die WS immer auf fallender CLK Flanke geändert werden, aber die Daten ist immer auf steigender CLK Flanke geändert werden. Es ist verwirrend.
Y. W. schrieb: > Die WS immer auf fallender CLK Flanke geändert > werden, aber die Daten ist immer auf steigender CLK Flanke geändert > werden. Es ist verwirrend. Krass. Immerhin gibts ein kleines Delay von 65.9 ns zwischen steigender CLK Flanke und Änderung der Datenleitung. Wenn man also schnell genug ist, kann man auch standardgemäß auf steigender CLK Flanke (besser kurz davor) Daten übernehmen. Schmutzig ist das aber trotzdem.
:
Bearbeitet durch User
Joe F. schrieb: > Selbstverständlich geht das. Man muss eben intern eine invertierte Clock > verwenden Genau das habe Ich doch geschrieben, es ist aber real so, dass die "interne Clock" im FPGA die "nicht-invertierte" ist und die "externe" die "invertierte" ist. Dann stimmt es und das Signal kommt richtig und kann ohne Verrenkung interpretiert werden. Hier gibt es bezüglich des Taktes nur ein Interpretationsproblem: Schau Dir bitte nochmal Dein Diagramm vom 13. Februar an und schiebe die Daten gedanklich aufeinander, dann ist der Takt zwischen den beiden Diagrammen invers. Das eine ist ein Diagramm mit Takt des Senders, das andere mit Takt des Empfängers. Die werden sich immer um die 180 Grad bewegen, wenn man zentrierte Daten lesen will. Ich sehe da kein Problem oder ungewöhnliches. Das ist wahrscheinlich einfach nur ungeschickt beschrieben. Das einzig komische ist das "zu spät" kommende WS bei dem Knowles, wobei das ja noch nicht geklärt ist, ob es wirklich so ist. Es kann natürlich auch sein, dass das Knowles aus irgendwelchen Gründen die Daten etwas früher auf den Bus legt und es nur in diesem vereinfachten Diagramm so aussieht, als läge es auf der Flanke. Praktisch wird sich, egal ob das intern auf fallend oder steigend agiert, immer ein delay zwischen Daten und eingehendem Takt zeigen. Das müsste man mal in der Spec nachlesen. Wahrscheinlich liegen da wie schon vermutet ein paar ns herum und man bewegt sich schon in Richtung der Taktmitte.
Angehängte Dateien:
-
memsi2s.gif
60 KB
Jürgen S. schrieb: > schiebe die > Daten gedanklich aufeinander, dann ist der Takt zwischen den beiden > Diagrammen invers. Das eine ist ein Diagramm mit Takt des Senders, das > andere mit Takt des Empfängers. Na ob die das so gedacht haben, wage Ich zu bezeiffeln. > Das ist wahrscheinlich einfach nur ungeschickt > beschrieben. Das schon eher. In dem angehängten Diagramm ist das timing auch so beschrieben, aber mit der Vermutung der Delays nach den Taktflanken könntest Du Recht haben: > Es kann natürlich auch sein, dass das Knowles aus irgendwelchen Gründen > die Daten etwas früher auf den Bus legt und es nur in diesem > vereinfachten Diagramm so aussieht, als läge es auf der Flanke. So sieht es wohl aus.
Welches Mikro ist das jetzt? Die Beschreibung gibt keine min-Zeit an für den Abstand der Flanke zu den Daten, also ist das mit 0 anzunehmen, d.h. das ist für vollsynchronen Betrieb ausgelegt. Bei externen Chips kann das bekanntlich problematisch werden, auf der steigenden flanke zu arbeiten. Daher muss der externe Takt dennoch verzögert werden, wenn auch nicht auf 180 Grad. Bei den Frequenzen ist es aber wohl Wurscht.
Das ist ein Knowles Mikrofron das Ich per google aufgefunden hatte. Wie sieht es eigentlich mit solchen Dingen wie Richtempfindlichkeit bei diesen Mikrofönchen aus?
Alina schrieb: > Hat jemand schon probiert mit STM32F4? ich habe schon in STM32 implementiert. einige Probleme habe ich, ich habe die von Mikrofon gesammelten Daten nachgeschaut. Die 24bits Data sieht immer so aus "0xFAXXXX07F". Die letzte 3 Bytes kenne ich schon wegen den Tri-state. Aber meine Frage liegt daran, warum hat die erste 2Bytes immer 0xFA? ich habe so konfiguriere mit I2S_Standard_Phillips, I2S_Mode_MasterRx, I2S_CPOL_Low und I2S_DataFormat_24b. Weiß jemand warum?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.