MEMS Mikro mit I2S auswerten

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. "

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.

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.

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.

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?

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.

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.

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.

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.

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.

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?