ADC MCP3903 gibt zwischendurch Müll aus

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Mich bringt hier dieser ADC langsam zur Verzweiflung.
Datenblatt: https://www.microchip.com/wwwproducts/en/MCP3903

Der ADC bekommt 4MHz am OSC1 und EXT_CLK im Register ist auf 1.
Der Prescaler ist auf 1 gestellt.
Oversampling ist auf 256 gestellt somit ist der ADC auf 24Bit gestellt 
(der Readout wurde auch auf 24 Bit gestellt).
Der SPI Takt beträgt 3,8MHz. (bis zu 10MHz sind erlaubt und auch mit 
2MHz auslesen bessert nichts)

Per SPI lese ich immer alle 6 Kanäle des ADC aus, das funktioniert auch 
wunderbar.
Nur manchmal gibt der ADC absoluten Müll aus, zb 0x7FFFFF (also MAX_INT 
auf 24Bit) aber auch sonstige Werte die zu hoch sind.
So misst meine Software statt den anliegenden 12V (natürlich mit 
Spannungsteiler) auch mal 100V+, weil der ADC "nen Furz lässt".
Das tritt nur zwischendurch einzeln und zufällig auf.
zB nach 20s passiert das mal und dann nochmal nach 30s.

Jetzt dacht ich, dass ich den ADC mal während einer Wandlung auslese, 
aber das ist laut den DRSTATUS_CHx Bits nicht der Fall, die sind immer 
"0 = Data Ready".

Fällt wem auf was das sein könnte?

[Karl M. (Gast)]

Ich tippe mal,

# Fehler im Programm
# Steckbrettaufbau
# Schlechte Versorgungsspannung, die muss besonders gefiltert und 
rauscharm sein.
# generelle Schaltungsfehler

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Die Klassiker kann ich soweit ausschließen ;)

laut Oszi liegt der Müll auch auf dem SPI an, kommt also direkt vom ADC.
Das Signal sieht jetz etwas gubblig aus, weils über 10cm Lackdraht muss 
um ranzukommen und die Masse von "sonstwo" kommt.
Beide Oszibilder zeigen einen zu hohen Wert in den ersten 3 Bytes.
Da kommt eigentlich eher was wie 0x00 0x01 0x34 und dann eben die 
gezeigten Ausreißer.
-> kein Fehler im Programm.
-> kein Steckbrettaufbau, sondern eine Platine, den ADC gibts nur in 
SMD.
-> die 5V analog kommen direkt aus nem 78L05 und die 3,3V Digital sind 
gut entkoppelt.

Hmm, Schaltungsfehler, eigentlich ist alles wie im Datenblatt.

[Karl M. (Gast)]

Mw E. schrieb:
> -> die 5V analog kommen direkt aus nem 78L05

Nun hier ist schon mal ein Problem, "gut" ist so eine 78L05 in meinen 
Augen, d.h. was rauschen angeht, nicht.

Da treiben wir für Quarzoszillatoren einen ganz anderen Aufwand.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Der rauscht jetzt aber nicht sodoll, dass ein ADC bis zum MSB 
ausschlägt.
Für den Vollausschlag brauchts am Eingang des ADC 0,5V.
Das schafft der 78L05 nun wirklich nicht ;)
Mal abgesehen davon, dass der ADC noch 68dB Supply Rejection hat.

Aber irgendwo muss der ADC sich ja verhaspeln, sonst würds ja 
funktionieren.


Nur so interessehalber, welchen rauscharmen Spannungsregler würdeste 
denn empfehlen?

[foobar (Gast)]

Um Fehler im Analogteil auszuschließen, könnte man ja mal die Eingänge 
auf einen festen Wert setzten. Btw, ist der Fehler immer auf dem 
gleichen Kanal?

> - kein Fehler im Programm.

Wenn du HW-Fehler ausschließt, kann's ja eigentlich nur noch daran 
liegen. Register falsch programmiert, settling delays nicht abgewartet 
(i.e. SINC-filter), falscher SPI-Mode, etc.

[pegel (Gast)]

Die Signale sehen aber wirklich übel aus.
Das sollen 3,3V Pegel sein?

[pegel (Gast)]

Da liegen irgendwo deutliche Störungen vor.

[Christian S. (roehrenvorheizer)]

Hallo,

vielleicht möchtest Du mal die Platine zeigen?

MfG

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

@pegel
Ich hatte ja gesagt, dass die Signale so übel aussehen, weil die über 
Lackdraht gehen mit ich nicht 30s+ lang 2 Tastköpfe auf nen Pin halten 
muss und dabei nen Krampf bekomme. Die Masse kommt dabei vom Netzteil 
abegriffen, gibt also nen schönen HF Loop.
Wenn ich dann kurz direkt am Pin messe um zu gucken wies Signal wirklich 
aussieht ohne das Lackdrahtgeraffel, dann is das gut.
Am Problem hat sich durch den Eingriff aber null geändert.
Muss ich die Platine nachher nochmal ausm gehäuse popeln, dann gibts nen 
Bild dazu.

@foobar:
Mit dem SINC Filter hatt ich auch schon überlegt, aber laut DB muss der 
nur zu Anfang zur Ruhe kommen.
Zudem sagt das DB, dass bei gesetztem DR_LTY Bit mir der ADC auch erst 
nen IRQ wirft, wenn der SINC settled ist:
> 1 = True “No Latency” Conversion, data ready pulses after 3 DRCLK periods 
(DEFAULT)
Das Bit muss ich also nichtmal setzen :>
Diese 3 DRCLK braucht auch der SINC.
Ansonsten stelle ich ihn nur auf externen Takt, da der Takt vom µC kommt 
statt nem zweiten Quarz.
Das sind 4MHz, daher ist im ADC der Prescaler auf 1.
Zudem OSR auf 256 damit auch 24Bit gewandelt werden und das auslesen 
wird auf 24bit gestellt.
Zum Debuggen hab ich ihn noch so eingestellt, dass er durch alle 
Register loopt mit ich in einem Rutsch auch an die Statusbits komme.
Dabei ist "DRSTATUS_CHn: Data Ready Status" imemr auf:
0 = Data Ready
Auch wenn das ausgelesene Ergebnis offensichtlich Grütze ist.

Der ADC unterstützt SPI Mode 0,0 und 1,1 auf dem Bild ist SPI Mode 0,0 
zu sehen.
CLK ist Low idle und gesampled wird bei steigender Taktflanke.
Ist so im Oszi eingestellt und auch im µC.

Den CH0 Eingang setze ich ja immer auf feste Werte, 12V oder 0V (Klemme 
J7-1 und J7-2 verbunden).
C54 werde ich mal noch durch ne Drahtbrücke ersetzen und dann testen.
Am CH0 lausche ich zu Debugzwecken auf den Fehler, wenn ich >100V Messe 
ist der Fehler offensichtlich da.
Aber auch bei CH1 - CH5 tritt das sporadisch auf wenn ich auf Bitmuster 
größer 0x05 0xFF 0xFF teste trotz kurzgeschlossenem J1-2/J1-1

Da ist ja offensichtlich nen Fehler, aber ich seh ihn nicht und bei 
euren Vorschlägen gucke ich mir das ja immer nochmal an und es sieht 
nicht nach nem Fehler aus jeweils.

@roehrenvorheizer
Hier mal 2 Bilder.
Einmal die ganze Platine zur Übersicht und dann der Ausschnitt mit dem 
ADC und dem STM32F205.

[Bla (Gast)]

Ich hol mir meine Debugsignale auch über Lackdraht und sei es UART oder 
SPI, es sah nie so grausig aus.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Ich löse mal auf, denn inzwischen läufts endlich.
Falls mal noch jemand dieses Problem haben sollte.

Das DB verspricht ja vollmundig, dass aklles in Ordnung ist:

>The Data Ready pins indicate if a new conversion
>result is ready to be read on each of the A, B and C
>pairs of ADCs.
>The Data Ready pins are independent of the SPI
>interface and act like an interrupt output.The Data
>Ready pins state is not latched


>To ensure that all channel ADC data are present at the
>same time for SPI read, regardless of phase delay settings
>for either or both channels, there are two sets of
>latches in series with both the data ready and the ‘read
>start’ triggers.
>The first set of latches holds each output when data is
>ready and latches both outputs together when
>DRMODE<1:0>=00. When this mode is on, both ADCs
>work together and produce one set of available data
>after each data ready pulse (that corresponds to the
>lagging ADC data ready). The second set of latches
>ensures that when reading starts on an ADC output, the
>corresponding data is latched so that no data
>corruption can occur.
>If an ADC read has started, in order to read the
>following ADC output, the current reading needs to be
>completed (all bits must be read from the ADC output
>data registers).

Der Letzte Absatz sagt ja direkt, dass man immer lesen kann und bekommt 
seine Daten und man muss alles durchlesen (was ich auch tuhe).

Was da nicht steht ist, dass man direkt nach dem DataReadPuls als IRQ 
die Daten lesen muss dann funktionierts.