Datenfehler mit dem ADC CS5532

Hallo

Ich benutze den CS5532 im Continuous Conversation Mode. Der ADC wird ganz am Anfang einmal initialisiert und l=E4uft dann durch. Der Wandler arbeitet und gibt auch korrekte Daten ab. Das Problem ist, da=DF ca. alle halbe Stunde f=FCr ca. 20 Sekunden die Daten auf einem konstanten Wert stehen bleiben. Betrachtet man das graphisch hat man ein Rauschband, da=DF auf einmal zu einem Strich wird und dann wieder zu einem Rauschband (siehe

formatting link
Ich habe das mit einem Oszilloskop an den seriellen Ausgangsdaten des ADC =FCberpr=FCft. Diese verhalten sich genauso. Es liegt also nicht an der Weiterverarbeitung und Abspeicherung der Daten auf Compact Flash. Die Werte sind auch keine Anschlagswerte. W=E4hrend der Fehler auftritt gibt der ADC auch Werte ab, nur eben konstante. Es ist nicht so, dass keine Daten vom ADC kommen. Nach der Initialisierung ganz am Anfang werden auch keine Kommandos mehr an den Wandler geschickt. Was kann das blo=DF sein, ich habe keine Ideen mehr. Hat von euch vielleicht schonmal jemand so ein Problem gehabt, oder habt ihr eine Idee, was das sein k=F6nnte? Unter
formatting link
findet ihr einen Schaltungsausschnitt. Ich denke aber, dass ich den Wandler richtig beschaltet habe.

Gru=DF Markus

Reply to
midiwidi
Loading thread data ...

Hallo,

mit welchem Contreller ist der CS5532 verbunden? L=E4uft des Datenabholen per Interrupt und Hardware-SPI oder ist in dem Controller eine Soft-SPI impementiert? Wie ist der ADC-Takt implementiert? Hast Du den Abschnitt Self Calibration (Datenblatt S. 33) gelesen? Vielleicht liegt dort das Problem.

Steffen

Reply to
Steffen Hildebrandt

Der ADC ist mit einem FPGA verbunden in dem ein Modul l=E4uft (state machine), da=DF die ADC-Werte in einem FPGA-internen Register ablegt.Das Spi-Modul ist ebenfalls hardware-m=E4=DFig im FPGA implementiert. Im Continuous Conversation Mode wird die Verf=FCgbarkeit von Daten vom ADC mit dem Runterziehen von SDO signalisiert. Danach f=E4ngt die state maschine an, die Daten abzuholen. Ich glaube allerdings nicht, dass das Problem im FPGA liegt, denn ich habe die konstanten Daten ja auch mit dem Oszilloskop direkt auf dem SPI-Interface zum ADC beobachten k=F6nnen. Der ADC gibt die Daten mit

100Hz aus.Das Oszi konnte nicht auf Pausen von SDO 10ms (100Hz) triggern, d.h. die Ausgabe erfolgt ganz regelm=E4=DFig mit 100Hz. Auch hat das Oszi nach der Initialisierung nicht auf SDI triggern k=F6nnen. D.h. es werden auch keine Kommandos zum ADC geschickt. Den Abschnitt Self Calibration habe ich gelesen. Ich denke aber, da=DF man ein Kommando zum ADC schicken mu=DF, damit er die Kalibrierung durchf=FChrt. Meiner Meinung nach gibt es kein Kommando f=FCr eine periodesche Selbstkalibrierung, soda=DF dieses Problem mit einer falschen Initialisierung des ADCs zu erkl=E4ren w=E4re.
Reply to
midiwidi

Hat keiner eine Idee ? Ich wei=DF nicht welche Tests ich noch machen kann, um das Problem zu l=F6sen.

Reply to
midiwidi

Womit wird der ADC angesteuert? Falls mit 'nix', könnte das sichtbare Rauschen auch hauptsächlich aus idle tones bestehen und die könnten gelegentlich synchron zur Abtastrate sein. Der rauschfreie Zustand wäre dann eher das Ideal und weniger das Problem. Bleibt der Effekt, wenn man den ADC mit einem kleinen Sinus aussteuert, so 4 * Rauschamplitude?

Gibt es in der Umgebung des ADC mehrere Takte, die nur beinahe synchron sind? Bleibt es bei einer halben Stunde wenn man die Abtastrate ein paar ppm ändert?

idle tones: hochauflösende DeltaSigma-Wandler mit konstanter Ansteuerung erzeugen gelegentlich diskrete Frequenzen sehr kleiner Amplitude.

Ich gehe mal davon aus, dass die analoge Spannungsversorgung nicht digital kontaminiert ist.

Gruß, Gerhard

Reply to
Gerhard Hoffmann

In dem Fall, den das Bild zeigt, waren die Eing=E4nge des Wandlers kurzgeschlossen. Den Test mit einem Sinus 4-facher Rauschamplitude werde ich noch durchf=FChren. Aber das verwunderliche ist, dass die Amplitude im Fehlerhall nicht auf Null abf=E4llt und dort konstant bleibt, sondern auf einem Wert der auch dem Eingangssignal entspricht. Der ADC soll zum Messen des elektrischen Feldes eingesetzt werden. Bei ersten Testmessungen am E-Feld mit seinem Absolutwert und seinen nat=FCrlichen Variationen, trat der Fehler auch auf. Auch wenn man am Eingang eine Spannung (z.B. aus einem Labornetzteil) anlegt, tritt der Fehler auf. In der N=E4he des Wandlers gibt es eigentlich nur 2 Takte. Den Systemtakt des ADC (nicht =FCber Quarz erzeugt, sondern vom FPGA eingespeist) und gelegentlich den SPI-Clock. Der Spi-Clock wird durch runterteilen des Systemclocks im FPGA erzeugt. Diese zwei Takte sind also phasenstarr zueinander. Es gibt insgesamt 10 Me=DFger=E4te mit diesem ADC. 7 davon zeigen diesen Fehler, obwohl alle Ger=E4te identisch sind. Die Zeit zwischen den Fehlern ist nicht konstant, sondern variiert. Auch sind die Abst=E4nde zwischen den Fehlern bei jedem Ger=E4t unterschiedlich. Die L=E4nge des Fehlerzustandes ist auch nicht konstant. Sie zeigt aber das Selbe Verhalten wie die Abst=E4nde zwischen den Fehlern. Unter

formatting link
findet ihr die Plots =FCber das zeitliche Auftreten der Fehler. Die X-Achse entspricht der Fehlernummer und die Y-Achse zeigt die Zeitdifferenz zum vorhergehenden Fehler in Sekunden. Wie es auf der Versorgungsspannung aussieht teste ich gerade. K=F6nnten irgendwelche Spikes oder Rauschen auf der Versorgungsspannung den Wandler zu so einem Verhalten bewegen?

Gru=DF Markus

Reply to
midiwidi

midiwidi schrieb:

Naja, vorsicht. Wenn man es versaut kann man sich schöne Timingverletzungen an den Hals holen, die zwar meistens laufen, aber eben zu sporadischen Ausfällen führen können. Versuchmal der Sache mit Kältespray und Warmluft zu Leibe zu rücken (FPGA, Quarz, ADC), wenn sich dann was ändert (Zeit zwischen den Aussetzern etc.) hast du ne heisse Spur.

Sporadische Fehler durch asynchrones Timing können sowas machen.

Es scheint mir, dass entweder der Sample&Hold sich mal verklemmt, oder die ADC Logik.

MfG Falk

Reply to
Falk Brunner

Hallo Falk

Ich habe die Elektronik mal im Klimaschrank versenkt und bei verschiedenen Temperaturen mit kurzgeschlossenen Eing=E4ngen laufen lassen. Dabei kam raus, dass sowohl die Fehlerdauer, als auch der Abstand zwischen den Fehlern temperaturabh=E4ngig ist.

bei -20=B0C: Fehlerdauer ca. 6s, Zeit zwischen den Fehlern ca. 600s bei +20=B0C: Fehlerdauer ca. 20s, Zeit zwischen den Fehlern ca. 2000s bei +50=B0C: Fehlerdauer ca. 12s, Zeit zwischen den Fehlern ca. 1200s

An was f=FCr Timingverletzungen denkst du da? Der ADC l=E4uft mit einem Masterclock von 4,9152MHz. Der SPI-Clock entsteht mittels Teilen durch

4=2E Beide Frequenzen liegen im Bereich der Anforderungen (Masterclock:1

- 5 MHz, SPI-Clock: 0 - 2 MHz) und meines Wissens k=F6nnen beide Takte v=F6llig asynchron sein.Die SDI-Leitung scheidet aus, weil nach der Initialisierung nicht mehr kommandiert wird. Die SDO-Leitung hab ich mir angesehen und keine Auff=E4lligkeiten entdeckt. Nach was glaubst du, mu=DF ich suchen?

Gru=DF Markus

Reply to
midiwidi

Sind es denn ueberhaupt echte Fehler, d.h. liegen die angezeigten Werte ausserhalb der spec oder ist es nur gelegentlich verdächtig rauscharm?

Gruß, Gerhard

Reply to
Gerhard Hoffmann

midiwidi schrieb:

OK, aber wenn man im FPGA irgendwelche "TTL-Tricks" anwendet, gibts Probleme.

Schau dir an, ob dein FPGA, welches den ADC ansteuert sauber synchron programmiert ist. Keine gated clock etc.

Mfg Falk

Reply to
Falk Brunner

midiwidi schrieb:

Unsaubere Logik, wie z.B. gated clocks, asynchrone resets die Laufzeitabhängig sind etc.

MfG Falk

Reply to
Falk Brunner

Falk Brunner schrieb:

Reply to
Mario Baussmann

Vorsicht mit FPGA bei -20°C! das funktioniert bei uns auch nicht / nicht richtig. Temp. Spezifikation mal im Datenblett anschauen, bei unserem FPGA von XILINX geht der Temp Bereich nur bis -5°!

midiwidi schrieb:

Reply to
Mario Baussmann

Mario Baussmann schrieb:

Naja, sollte man nicht sooo eng sehen. Bis -5 GARANTIERT Xilinx dass alles geht. Drunter geht das meiste auch, nur wirds eben nicht garantiert. Und einfache Logik dürfte damit keinerlei Probleme haben. Sonderfunktionen wie PLLs/DLLs, High-speed Tranceivers evt. schon eher.

MFG Falk

Reply to
Falk Brunner

Es gibt keine asynchronen Resets im Modul f=FCr den ADC, aber einen gated Clock und zwar den Spi-Clock. Wie soll man das aber anders l=F6sen? Der SPI-Takt darf ja nur am ADC "anliegen", wenn die Daten ausgetaktet werden. Hier mal den VHDL-Quelltext des ADC-Moduls. Das Gate des SPI-CLK findet man in der f=FCnftletzten Zeile.

------------------- ---------------------

library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_arith.all; USE ieee.std_logic_unsigned.ALL;

entity CS5532 is

port( CMDIn: in std_logic_vector( 7 downto 0); DataInLow: in std_logic_vector(15 downto 0); DataInHigh: in std_logic_vector(15 downto 0);

Write_ADC: in std_logic; Reset_ADC: in std_logic; Stop_ADC: in std_logic;

SDI: in std_logic; -- ADC In Data Sft_enb: in std_logic; -- wait of B field ADC gap for shift out

NRES : in std_logic; CLK : in std_logic;

ADC_CLK: out std_logic; -- ADC CLK out 4,9152MHZ =3D

9,830400 MHz / 2 SCLK: out std_logic; -- shift clk for ADC SDO: out std_logic; -- OutData to ADC CS_ADC: out std_logic;

DataOut: out std_logic_vector(31 downto 0);

-- debug WR_RQ_out: out std_logic; RD_RQ_out: out std_logic; CS_RQ_out: out std_logic; CR_RQ_out: out std_logic; -- debug

WR_Mode_out: out std_logic; RD_Mode_out: out std_logic; CS_Mode_out: out std_logic; CR_Mode_out: out std_logic; Busy_out : out std_logic;

RD_RDY_out : out std_logic; CV_RDY_out : out std_logic

); end CS5532;

architecture behavioral of CS5532 is

signal Write_Data: std_logic_vector(39 downto 0); signal Write_Data_save: std_logic_vector(39 downto 0); signal ADC_In: std_logic_vector(31 downto 0); -- signal Read_Data_Out: std_logic_vector(7 downto 0);

signal WR_RQ: std_logic; signal RD_RQ: std_logic; signal RS_RQ: std_logic; signal CS_RQ: std_logic; signal CR_RQ: std_logic; signal CStop_RQ: std_logic;

signal WR_Mode: std_logic; signal RD_Mode: std_logic; signal RS_Mode: std_logic; signal CS_Mode: std_logic; signal CR_Mode: std_logic;

signal Busy: std_logic;

signal RD_RDY: std_logic; signal CV_RDY: std_logic;

signal clk_count: std_logic_vector(2 downto 0);-- generated ADC Clk signal cnt_wr: std_logic_vector(5 downto 0);-- Counter for write mode signal cnt_cs: std_logic_vector(6 downto 0);-- Counter for conv. Modes signal cnt_R: std_logic_vector(3 downto 0); signal CS_ADC_int: std_logic; signal Sft_clk_gate: std_logic; signal srsdi: std_logic_vector(1 downto 0);-- for find falling egde sdi signal Sft_enb_rec: std_logic; --external shift enable received signal sft_reg: std_logic_vector(1 downto 0); signal start_cnt_c: std_logic; signal cnt_enb_c: std_logic; signal start_cnt_w: std_logic; signal cnt_enb_W: std_logic;

begin

-- generated CLK's for ADC process (clk, NRes) begin if (NRES=3D'0') then clk_count '0'); elsif (clk'event and clk =3D '0') then clk_count

Reply to
midiwidi

Gerhard Hoffmann schrieb:

.=2E.. > Womit wird der ADC angesteuert? Falls mit 'nix', k=F6nnte das sichtbare

.=2E. idle tones: hochaufl=F6sende DeltaSigma-Wandler mit konstanter Ansteuerung

Hallo Gehrhard, ich will kein neues Thema er=F6ffnen. Mich interessiert: Woher kommt die Regel "sinus mit 4mal Rauschamplitude" (Soll das 4 mal Standardabweichung sein?) Wo gibt es diese Regel zum nachlesen? Gru=DF Lutz

Reply to
ludwig zweck

Nein. Die idle tones treten nur auf wenn sich ein "langfristig eingeschwungener" Zustand einstellt. Wenn man das System immer ein bißchen auf Trab hält kommt das nicht vor. 4 mal Rauschamplitude ist ganz gut weil es das System einerseits genug aufmischt, andererseits kann man gelegentliche Veränderungen noch gut mit bloßem Auge auf der üblichen Skala sehen.

näheres:

formatting link
Seite 5

Beim ADS1210 habe ich die idle tones schon sehen koennen. Den Effekt, daß es gelegentlich absolut ruhig war hatte ich aber nicht.

Gruß, Gerhard

Reply to
Gerhard Hoffmann

midiwidi schrieb:

Schon klar, aber es gibt für sowas immer ne saubere Lösung. Wenigstens sollte man den Takt nicht kombinatorisch, sondern über ein FlipFlop erzeugen. Stichwort Glitches (wobei ich mir relativ sicher bin, dass der ADC die nicht sieht, weil er VIEL zu langsam dazu ist, aber sicher ist sicher)

Also NICHT

Reply to
Falk Brunner

Das Problem ist gel=F6st !

Ich war so fixiert auf die Kommunikation mit dem ADC, dass es sehr lange gedauert hat, bis ich das Problem erkannt habe. Es gibt zwei Prozesse, die Messung vom Magnetfeld und die Messung vom elektrischen Feld (letztere mit dem ADC). Beide laufen mit "100Hz". Der ADC f=FCr die E-Feldmessung l=E4uft im Continious Conversation Mode mit einer Ausgabefrequenz von 100Hz am MainClk. Die Magnetfeldmessung l=E4uft auch am MainClk, wird allerdings durch einen externen genauen

1Hz-Impuls synchronisiert. Das funktioniert so, da=DF mit dem 1Hz-Impuls aus dem MainClk einhundert 100Hz-Impulse erzeugt werden, die die Magnetfeldmessung starten. Nach den 100 Starts wird gewartet bis der n=E4chste 1Hz-Impuls kommt. Um die Magnetfeldmessung nicht durch die ADC-Datenausgabe zu st=F6ren wird nach der Meldung, dass der ADC fertig ist (SDO wird low) bis zum Abschlu=DF der Magnetfeldmessung gewartet (fester Zeitpunkt in Bezug zu den 100Hz-Startimpulsen), bevor die ADC-Daten abgeholt werden. Das Problem ist nun, da=DF sich durch die Synchronisation der Magnetfeldmessung mit dem 1Hz-Signal, das Wandlungsende von E-und B-Feld zueinander bewegen. Deswegen kommt es je nach Driftgeschwindigkeit vor, dass mitten im Auslesen des ADC seine Ready-Meldung (SDO=3Dlow) kommt. Wird die Magnetfeldmessung nicht mehr durch den 1Hz-Impuls synchronisiert, treten keine Fehler mehr auf.

Ich bedanke mich bei allen, die mich hier unterst=FCtzt haben !!!

Viele Gr=FC=DFe Markus

Reply to
midiwidi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.