MCP3021 ADC liefert nur Schrott

[Luca S. (chababo)]

Hallo, ich muss dringend einen MCP3021 mit einem ESP32 zum laufen 
bekommen.

Leider habe ich das Problem, dass die Daten schlicht nutzlos sind, die 
ich erhalte.
Die Spannung am Analog Pin ist sauber von 0 - ca. 2.5V in dem Bereich, 
wo ich ihn nutze. Vdd ist 3.3V.

Ich habe 2 verschiedene Libraries für Arduino getestet, leider 
funktioniert nichts davon:
https://github.com/mkuniac/MCP3021/tree/master

https://reference.arduino.cc/reference/en/libraries/mcp3x21/

Das Resultat ist immer höchst wechselhaft, nur in einem kleinen Bereich 
linear, z.B. Wert 600-700, dann bin ich plötzlich wieder bei 500, wenn 
ich die Spannung weiter erhöhe.

Hardwaremässig kann man ja denke ich nicht viel falsch machen. Habe 
trotzdem noch ein Bild angehängt. Pullups sind natürlich auch dran an 
SCL und SDA (10k).

Der Code ist ja auch extrem simpel:

uint16_t result = mcp3021.readADC();

Serial.print("Value: ");

Serial.println(result);

Für die mkuniac Library.

Hat jemand eine Idee oder funktionierenden Code für Arduino?
Wäre sehr dankbar, ansonsten muss ich wohl ein SO-8 IC auf den SOT23 
Footprint basteln, da ich diesen erfolgreich getestet habe. Dies möchte 
ich sehr gerne vermeiden.

[Björn S. (bjrn_s869)]

Luca S. schrieb:
> SCL und SDA (10k).

Auch wenn dies hier nicht das Problem ist, sind die Widerstände für 
meinen Geschmack zu hochohmig.

[Luca S. (chababo)]

Ok, war halt immer so mein Standardwert, hatte bis jetzt auch nie 
Probleme.
Aber 4.7k ist wohl gängiger?

Hier sieht man noch, wie die 2 Datenbytes daherkommen, man muss also die 
Mitte der beiden Bytes "herausschneiden".

Und hier der Library Code, vielleicht erkennt ja jemand gleich einen 
Fehler darin, wie die Bytes zusammengesetzt werden?

Sorry für die mehrfachen Bilder.

[Wastl (hartundweichware)]

Luca S. schrieb:
> Und hier der Library Code

Und wo ist der Schaltplan und der Aufbau? Ich fürchte sehr dass
du über die Speisespannung massive Störungen hereinbekommst,
auch wenn ich bisher keine Schaltung gesehen habe. Selbst
dein Spannungsteiler für den ADC Input hat keinerlei weitere
Dämpfungsmechanismen für Störungen und ist sehr hochohmig. Kann
also viel passieren, zumal die Referenz des ADC offensichtlich
auch gleich die Versorgungsspannung ist. Der ESP32 wird deine
Versorgung nicht "in Ruhe lassen". Wenn jetzt dein UBat geteilt
durch den Spannungsteiler zufällig höher ist als deine Versorgungs-
spannung dann ist die Kacke auch am Dampfen ....

[Martin O. (ossi-2)]

You should check whether really two bytes are read from the device. You 
should also check the raw data bytes before the shift operations.

[Luca S. (chababo)]

Wastl schrieb:
> Luca S. schrieb:
>> Und hier der Library Code
>
> Und wo ist der Schaltplan und der Aufbau? Ich fürchte sehr dass
> du über die Speisespannung massive Störungen hereinbekommst,
> auch wenn ich bisher keine Schaltung gesehen habe.

Hi, das ganze ist ein Custom PCB, wird von einer 12V Batterie gespeist, 
geht dann erstmal durch einen externen 12V Regler für den hochstromteil 
(LED-Controller, um konstante Helligkeit zu erreichen bei gleicher 
Ansteuerung), der ESP32-WROOM und die Peripherie bekommt eine stabile 
3.3V Spannung aus einem Schaltregler. (Anhang)

Ich habe auch ein paar andere I2C Komponenten, die problemlos laufen.

Als Spannungsquelle nutze ich momentan ein Labornetzgerät, das ich auch 
vorher schon benutzt habe.

[Wastl (hartundweichware)]

Luca S. schrieb:
> Hi, das ganze ist ein Custom PCB, .........
> ...........

Aus dieser scheiss Prosa sollen wir uns jetzt den kompletten
Schaltplan zusammenreimen? Ja was jetzt? Batterie oder
Netzteil? Von wo nach wo? Jede Menge Ungwägbarkeiten.

LED-Controller, Schaltregler, jede Menge Quellen für Störungen

Luca S. schrieb:
> eine stabile 3.3V Spannung aus einem Schaltregler

Ja, stabil ist halt relativ, besonders für einen ADC.

[Max D. (max_d)]

Hast du ein Oszilloskop mit dem du deine Versorgung mal ansehen kannst ?
digitale schaltungen stören sich nicht dran wenn die Versorgung bisschen 
schwankt, aber deiner analogen Bude verhagelt es halt das Ergebnis.

[Luca S. (chababo)]

Kann dir schon das ganze Projekt zusenden, wenn du Zeit hast dafür:
https://we.tl/t-LBAC8ou4DU

Es ist gedacht für eine LED-Steuerung über Batterie, zum testen speise 
ich es aber natürlich per Netzteil.

[Udo S. (urschmitt)]

Versuche mal parallel zu R16 ein 22-100nF Kondensator zu hängen.
Ändert sich dadurch etwas?

[Luca S. (chababo)]

Max D. schrieb:
> Hast du ein Oszilloskop mit dem du deine Versorgung mal ansehen kannst ?
> digitale schaltungen stören sich nicht dran wenn die Versorgung bisschen
> schwankt, aber deiner analogen Bude verhagelt es halt das Ergebnis.

Leider gerade nicht zur Hand, hätte irgendwo noch ein altes, analoges 
rumliegen.

Udo S. schrieb:
> Versuche mal parallel zu R16 ein 22-100nF Kondensator zu hängen.
> Ändert sich dadurch etwas?

Ich versuche es gleich.

[Wastl (hartundweichware)]

Luca S. schrieb:
> Kann dir schon das ganze Projekt zusenden, wenn du Zeit hast dafür:
> https://we.tl/t-LBAC8ou4DU

Jetzt muss ich mir nur noch schnell eine Altium-Lizenz kaufen
und das Zeug installieren. Nur noch einen Moment ...

[Gunnar F. (gufi36)]

Luca S. schrieb:
> Leider gerade nicht zur Hand, hätte irgendwo noch ein altes, analoges
> rumliegen.

was soll das Geschwafel? Stell es auf den Tisch, schalt es an. Brauchst 
du dann noch weitere Hilfe?

[Udo S. (urschmitt)]

Hier ist ein Datenblatt:
https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/20001805C.pdf

Da steht unter anderem in Kapitel 6: Der Baustein hätte gerne eine 
niedrige Eingangsimpedanz.

In 6.2 steht 10kOhm Pullup des I2C ist für 100kHz, bei 400kHz sollten es 
eher 2K2 sein.

Eine weitere Möglichkeit für Fehler könnte eine schlechte Masseführung 
sein, falls größere Ströme über die gleiche Masse führen an der der 
Baustein hängt, der Eingangsspannungsteiler aber nicht.
So eine PWM eines LED Drivers die die Masse ein paar 100mV hochzieht 
könnte solche Effekte z.B. herbeiführen.

[Foobar (asdfasd)]

Dieses "GND_protected" lässt mich vermuten, dass es mehrere Grounds 
gibt.  Die GND der 12V sind aber mit dem GND_protected verbunden, oder?

[Luca S. (chababo)]

Gunnar F. schrieb:
> Luca S. schrieb:
>> Leider gerade nicht zur Hand, hätte irgendwo noch ein altes, analoges
>> rumliegen.
>
> was soll das Geschwafel? Stell es auf den Tisch, schalt es an. Brauchst
> du dann noch weitere Hilfe?

Moment, muss nur noch kurz 50km fahren, dann ist es auch schon auf dem 
Tisch.

[Udo S. (urschmitt)]

Eine weitere Möglichkeit wäre dass das Netzteil das zum testen verwendet 
wird bei PWM in Überlast kommt oder warum auch immer schwingt. Die 
Schaltung funktioniert durch den Spannungsregler noch, aber man misst 
halt unterschiedliche Spannungen wegen der Schwingung.

[Luca S. (chababo)]

Foobar schrieb:
> Dieses "GND_protected" lässt mich vermuten, dass es mehrere Grounds
> gibt.  Die GND der 12V sind aber mit dem GND_protected verbunden, oder?

Genau, ich habe einen Verpolungsschutz per MOSFET realisiert, bei dem 
das Ground unterbrochen wird. Danach ist aber alles auf dem gleichen 
Ground.

Hier mal die Schemas, für alle, die kein Altium haben, damit das Nörgeln 
mal aufhört:


PWM Output ist im Moment nicht aktiv beim Testen, damit haben die 
Störungen also nicht zu tun.

[Luca S. (chababo)]

Udo S. schrieb:
> Hier ist ein Datenblatt:
> 
https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/20001805C.pdf
>
> Da steht unter anderem in Kapitel 6: Der Baustein hätte gerne eine
> niedrige Eingangsimpedanz.
>
> In 6.2 steht 10kOhm Pullup des I2C ist für 100kHz, bei 400kHz sollten es
> eher 2K2 sein.
>
> Eine weitere Möglichkeit für Fehler könnte eine schlechte Masseführung
> sein, falls größere Ströme über die gleiche Masse führen an der der
> Baustein hängt, der Eingangsspannungsteiler aber nicht.
> So eine PWM eines LED Drivers die die Masse ein paar 100mV hochzieht
> könnte solche Effekte z.B. herbeiführen.

Das I2C Interface läuft auf 100kHz, da ich die Standard Wire library 
verwende.

Der PWM Output ist im Moment auch nicht aktiv, die Störungen können also 
auch nicht von da kommen.

[Andreas M. (amesser)]

Luca S. schrieb:
> Das Resultat ist immer höchst wechselhaft, nur in einem kleinen Bereich
> linear, z.B. Wert 600-700, dann bin ich plötzlich wieder bei 500, wenn
> ich die Spannung weiter erhöhe.

Zu welcher vbat gehören diese Werte? Ich vermisse einen 
Tiefpass/Pufferkondensator am Eingang des ADC.

Wenn ich richtig sehe, dann hat der von dir gewählte Tantal den 
doppelten ESR von dem im Datenblatt des MIC4680? Ich denke außerdem, 
dass die Versorgung überdimensioniert ist. Der wird viel im lückenden 
Betrieb laufen was viel Ripple auf den 3.3V bedeutet. Auch ist der MIC 
recht lahm bei Transienten, davon erzeugt gerade der ESP viele. Gegen 
Schwankungen suf der Versorgung ist der ADC allergisch. Du solltest auf 
jeden Fall einen LC Filter vor den ADC setzen, besser wäre eine separat 
stabilisierte Versorgung/Referenz. Der Hinweis mit den 10uF im 
Datenblatt des ADC steht da nicht zum Spaß.

[Luca S. (chababo)]

Stimmt, den 10uF habe ich offenbar weggelassen. Ob es daran liegt?

Ja, der Regler ist überdimensioniert für den ESP32. Ich wollte noch 
Reserve haben für allfällige Peripheriemodule, die nachgerüstet werden. 
Ich wusste nicht, dass dies das Regelverhalten negativ beeinflusst.

Getestet habe ich den Bereich von ca. 4V - 12V, aber die Werte machen 
keinen logischen Sinn. bis ca. 6V ändert sich der Wert nicht grossartig 
von ca. 350, danach gehts auf einmal auch wieder zurück auf 250, später 
bei ca. 8v sprungweise auf 700, wo es dann für ein paar 100mV einen 
linearen Eindruck macht, um danach wieder kleinere Werte auszugeben.

[Andreas M. (amesser)]

Luca S. schrieb:
> Getestet habe ich den Bereich von ca. 4V - 12V, aber die Werte machen
> keinen logischen Sinn. bis ca. 6V ändert sich der Wert nicht grossartig
> von ca. 350,

Der MIC läuft doch erst ab 4V an, kommen bei 4V vbat überhaupt noch 4v 
am MIC an? Der externe 12V Regler wird ja auch noch was brauchen?

Ich würde mir erstmal Gedanken um die 3.3V machen. Mal mit dem Oszi 
draufschauen. Mehr als ein paar mV Ripple darf da nicht sein. Wie oben 
schon geschrieben könnte auch dein Labornetzteil oder Dein 12V Regler 
schwingen, Schaltregler haben eine negative Impedanz am Eingang...
Vielleicht gibt es auch Konflikte auf dem I2C? Ohne Oszi kommst Du da 
nicht weiter...

[Luca S. (chababo)]

Andreas M. schrieb:
> Der MIC läuft doch erst ab 4V an, kommen bei 4V vbat überhaupt noch 4v
> am MIC an? Der externe 12V Regler wird ja auch noch was brauchen?

Kann sein, dieser Bereich ist auch nicht relevant, habe halt schnell 
durchgetestet mit dem Labornetzteil. Relevant ist, dass von 8-13V 
korrekte Messwerte vorliegen. Der Analogeingang vom ADC kommt aber 
direkt von der Eingangsseite des 12V Reglers, nur die 
Versorgungsspannung wird danach abgegriffen. Es ist ein China Buck-Boost 
Regler, bis runter auf 8V gibt er die 12V aus.

Danke für die Tipps, ich werde am Wochenende das Oszilloskop besorgen 
und die 3.3V anschauen. Auch noch testweise den fehlenden 10uF 
Kondensator anlöten über der Speisung vom ADC.

Der 12V Regler sollte nicht das Problem sein. Zumindest hatte ich es 
zuvor schon mit einem anderen ADC erfolgreich betrieben (MCP3426). Da 
hatte ich aber auch noch einen 3.3V Linearregler anstelle des 
Schaltreglers.
Ich habe danach viele Hardwareänderungen gemacht, u.a. aus 
Effizienzgründen auf den Schaltregler gewechselt, da das Ganze möglichst 
wenig Strom von der Batterie verbrauchen soll.

I2C Adresskonflikte gibt es keine.

[Andreas M. (amesser)]

Du bist dir sicher das Masse am Eingang des Daygreen mit der am Ausgang 
verbunden ist? Das ist bei Buck/Boost normalerweise nicht der Fall 
(außer es ist ein SEPIC)

[Andreas M. (amesser)]

Der MCP3426 hat eine interne Referenzspannung, der MCP3021 hingegen 
nimmt die Versorgung als Vref....

[Martin O. (ossi-2)]

Ist der Ground vom MCP3021 kontaktiert, nicht nur im Schaltplan sondern 
in der Realität ?

[Luca S. (chababo)]

Andreas M. schrieb:
> Der MCP3426 hat eine interne Referenzspannung, der MCP3021 hingegen
> nimmt die Versorgung als Vref....

Aha, das erklärt einiges...

Andreas M. schrieb:
> Du bist dir sicher das Masse am Eingang des Daygreen mit der am Ausgang
> verbunden ist? Das ist bei Buck/Boost normalerweise nicht der Fall
> (außer es ist ein SEPIC)

Weiss ich nicht sicher, aber würde es schaden, sie trotzdem 
zusammenzuhängen?

Martin O. schrieb:
> Ist der Ground vom MCP3021 kontaktiert, nicht nur im Schaltplan sondern
> in der Realität ?

Ja, das PCB ist gemäss Schema verbunden.

[Andreas M. (amesser)]

Luca S. schrieb:
> Weiss ich nicht sicher, aber würde es schaden, sie trotzdem
> zusammenzuhängen?

Wenn sie intern nicht verbunden sind, dann schadet es.

[Fritz G. (fritz65)]

Dein Code nutzt von den 10 bits des Wandlers nur die untersten 8, die 
zwei höchstwertigen werden durch die 6bit - Schiebeaktion entsorgt. Das 
macht nur sinn, wenn die zu messende Spannung < VDD/4 ist.Wenn die 
Referenz 3.3 V ist, ist also bei ca. 0.8V Schluss und die Zählung fängt 
wieder bei 0 an.

[Andreas H. (signore_rossi)]

Der 6 Bit Shift in library_code.png arbeitet auf der 16 Bit Variable 
value. Da geht nichts verloren.

Würden wirklich die zwei höchstwertigen Bits verloren gehen, würde Luca 
auch keine Werte um 600 herum sehen.

Ich würde auf jeden Fall mal prüfen, ob Eingangs-GND und Ausgangs-GND 
des Daygreen Regler miteinander verbunden ist.

[Stephan S. (uxdx)]

Luca S. schrieb:
> Hardwaremässig kann man ja denke ich nicht viel falsch machen. Habe
> trotzdem noch ein Bild angehängt. Pullups sind natürlich auch dran an
> SCL und SDA (10k).

Bei 3.3 Volt sollten die Pullups viel kleiner sein, schau Dir mal die 
Flanken mit dem Oszi an.

Luca S. schrieb:
> Leider gerade nicht zur Hand, hätte irgendwo noch ein altes, analoges
> rumliegen.

Tut's hier auch.

[Luca S. (chababo)]

Pullups sind natürlich auch dran an
>> SCL und SDA (10k).
>
> Bei 3.3 Volt sollten die Pullups viel kleiner sein, schau Dir mal die
> Flanken mit dem Oszi an.

Gut zu wissen, schaue ich auch an am Wochenende.

[Luca S. (chababo)]

Habe leider keine richtige Messsonde mehr gefunden für das Oszi, ich 
vermute, ohne Teiler kann ich nicht in den mV Bereich gehen, weil dann 
das Bild über das Fenster hinausschießt (ist lange her, dass ich das 
letzte Mal so ein Teil angeschmissen habe).
Werde mir wohl so ein USB Teil besorgen.

Bei 0.5V / Div zumindest sehe ich überhaupt keinen Ripple auf 3.3V.

[Foobar (asdfasd)]

> [Ripple auf DC mit Oszi messen]

Schalt das Teil auf AC, dann verschwindet der DC-Anteil und der Ripple 
liegt auf 0V.

[Monk (Gast)]

Luca S. schrieb:
> Habe leider keine richtige Messsonde mehr gefunden für das Oszi, ich
> vermute, ohne Teiler kann ich nicht in den mV Bereich gehen

Mit Messsonde meinst du wohl einen Tastkopf.

> Bei 0.5V / Div zumindest sehe ich überhaupt keinen Ripple auf 3.3V.
Dann liegt da wohl schon mal keine Vollkatastrophe vor.

[Luca S. (chababo)]

Also ich geb' es echt auf mit diesem ADC. Wurde der eigentlich schonmal 
erfolgreich eingesetzt? Hätte ich gewusst, was für eine Diva von einem 
ADC das ist, hätte ich es mir noch mindestens 7 Mal überlegt, den ADC zu 
wechseln.

Ich habe noch den 10uF Kondensator über der Speisung vom ADC 
angeschlossen, I2C Widerstände auf 4k7 gewechselt, gleiches Resultat.

Hier mal ein paar Werte:

Uin: 6V --> ADC: 152 (Störungen von 280)
7V --> ADC: 219 - 280
8V --> ADC: 542 (stabil)
9V --> ADC: abw. 542 und 606
10V --> ADC: 549 und 678

Das reicht glaube ich um zu verstehen, dass ich absolut nichts mit den 
Daten anfangen kann.

Kann nur noch versuchen, eine externe Lösung hinzubiegen, hier bin ich 
echt am Ende mit meinem Latein.

Aber danke für die Tipps. Ich melde mich noch, falls ich mal eine Lösung 
finden sollte.

[Foobar (asdfasd)]

Diese Werte haben nichts mit einem "mimosenhaften IC" zu tun, die sind 
schlicht und einfach Müll.  Keine Linearität, einfach Mist.  Irgendwas 
an deinem Aufbau und/oder Programm ist verkehrt.

Geh halt mal systematisch vor: mit einem (batteriebetrieben!) Multimeter 
Pin 2+1 messen (3.3V da?).  Als nächsten Pin 2+3 - ca 1/5 der 
Batteriespannung da?  Verschiedene Werte ausprobieren, das Verhältnis 
Batteriespannung zu Messwert muß konstant sein.  Wohlgemerkt, wirklich 
die Pins am IC messen, nicht irgendwelche Testpunkte!

Wenn das stimmt, mit dem Oszi den I2C-Bus aufnehmen (wenn möglich die 
anderen I2C-Slaves entfernen).  Stimmt die Adresse und das R/W-Flag. 
Werden Daten übertragen, passen sie zum Messwert und stimmen sie mit 
denen des Programms überein?

Kannst dir Testweise auch mal die empfangenen Rohbytes ausgeben (am 
besten, bevor du sie ins RAM schreibst - ich traue deinem "i" nicht - 
überprüfen, ob das wirklich 2 wird!).

Sinn ergibt die API eh nicht.  Entweder das requestfrom ist synchron, 
dann braucht es den available nicht.  Ist es asynchron, muß für jedes 
Byte per available gepollt werden, bis es da ist.

Wie auch immer, deine Methode, bei available==0 abzubrechen, kann im 
Fehlerfall nicht richtig sein (entweder du bekommt weniger als 2 Bytes 
und lieferst Zufallszahlen zurück oder es kommen mehr und du 
überschreibst dir das RAM).  Und falls die API asynchron ist (die Doku 
lässt sich darüber nicht aus), kommt auch im Normalfall nur Müll raus.

[Luca S. (chababo)]

Vielen Dank für die guten Punkte!

Werde ev. Zu späterem Zeitpunkt nochmals auf Fehlersuche gehen wie du es 
beschrieben hast. Jetzt muss ich erstmal das Projekt abliefern. Habe mir 
dazu eine externe Lösung per UART verbunden, was jetzt funktioniert. 
Habe zum Glück eine zusätzliche UART Schnittstelle eingeplant.

Foobar schrieb:
> Sinn ergibt die API eh nicht.  Entweder das requestfrom ist synchron,
> dann braucht es den available nicht.  Ist es asynchron, muß für jedes
> Byte per available gepollt werden, bis es da ist.

Sympathisch ist mir die Library auch nicht. Vor allem wie du gesagt 
hast, kaum dokumentiert.

[Monk (Gast)]

Luca S. schrieb:
> Sympathisch ist mir die Library auch nicht

Warum benutzt du sie dann? Es kann doch nicht so schwer sein, einen ADC 
"zu Fuß" abzufragen.

[Wastl (hartundweichware)]

Steve van de Grens schrieb:
> Warum benutzt du sie dann? Es kann doch nicht so schwer sein, einen ADC
> "zu Fuß" abzufragen.

Das ist überhaupt nicht schwer, ich frage mich warum man dafür
überhaupt eine Lib braucht. Die behindert eher als dass sie hilft,
weiss man doch (als Arduino-Jünger) nicht was die im Hintergrund
bzw. im Inneren so tut.

Protokoll im Datenblatt verstehen und SPI Protokoll anwenden....

[Rahul D. (rahul)]

Wastl schrieb:
> Die behindert eher als dass sie hilft,
> weiss man doch (als Arduino-Jünger) nicht was die im Hintergrund
> bzw. im Inneren so tut.

Die kann man aber einsehen und analysieren. Die liegt nämlich als 
Quellcode vor (wie in einem anderen Beitrag von Jona S. zu sehen).
Sein Problem liegt wohl eher allgmeine an mangeldem Wissen (böse 
Unterstellung).

[Luca S. (chababo)]

Wollte nur möglichst schnell zum Ziel kommen, da es mir nicht darum 
geht, jedes Bit zu analysieren, sondern eine funktionierende Lösung zu 
entwickeln.

[J. S. (jojos)]

Der Code ist doch minimal, was soll in der Lib falsch sein?
Wie ist denn Geschwindigket des AD Wandler, wird der evtl. zu schnell 
ausgelesen? Was passiert mit einem Delay von ein paar ms zwischen 
aufrufen?

[Rahul D. (rahul)]

Luca S. schrieb:
> Wollte nur möglichst schnell zum Ziel kommen, da es mir nicht
> darum
> geht, jedes Bit zu analysieren, sondern eine funktionierende Lösung zu
> entwickeln.

Siehe Bild im Anhang...

[Sebastian W. (wangnick)]

J. S. schrieb:
> Wie ist denn Geschwindigket des AD Wandler, wird der evtl. zu schnell
> ausgelesen?

Der ist lt. DB und meiner Rechnung schnell genug, um während der 
Übertragung des ACK und dann der vier binären Nullen des ersten 
Antwortbytes selbst bei 400kHz I2C-Geschwindigkeit mit dem Sampling und 
der Konversion fertig zu werden.

LG, Sebastian

[Rolf (rolf22)]

Sebastian W. schrieb:
> Der [ADC] ist lt. DB und meiner Rechnung schnell genug, um

Und woher weißt du, ob die Lib auch langsam genug ist?  ;-)

Die Schleifen-Endebedingung mit available() > 0 ist grundsätzlich ein 
extrem grober Fehler und kann bei zu schneller Lib leicht zu 
Zufallswerten führen, wie sie der OP beobachtet hat.

[Sebastian W. (wangnick)]

Rolf schrieb:
> Und woher weißt du, ob die Lib auch langsam genug ist?  ;-)

Weil in Wire.requestFrom() schon die gesamte Kommunikation stattgefunden 
hat, und mit Wire.available() nur noch aus einem internen Puffer des uC 
gelesen wird.

Aber ja, Matthews Code in https://github.com/mkuniac/MCP3021/tree/master 
ist unschön, weil bei Lesefehlern Zufallswerte geliefert werden können. 
Da ist Pavels https://github.com/pilotak/MCP3X21/blob/master/MCP3X21.cpp 
besser, und liefert bei Lesefehlern definiert 0xFFFF. Aber das Problem 
des TO taucht ja auch bei Verwendung von Pavels Code auf ...

LG, Sebastian

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Luca S. schrieb:
> Genau, ich habe einen Verpolungsschutz per MOSFET realisiert, bei dem
> das Ground unterbrochen wird. Danach ist aber alles auf dem gleichen
> Ground.
Und vorher schon werden die Absolute Maximum Ratings einiger Bausteine 
verletzt...

Kurz: es ist die absolut schlechteste Idee, rinem Baustein die 
Bezugsmasse zu nehmen. Der sucht sich dann irgendeine andere. Und nimmt 
dabei evtl. bleibenden Schaden.

Luca S. schrieb:
> Wollte nur möglichst schnell zum Ziel kommen
Dann miss mit dem Oszi, was auf dem Bus an den Pins der beteiligten 
Komponenten bezogen auf ihren jeweiligen GND-Pin los ist, und schau, ob 
das zum Datenblatt passt.

[Rolf (rolf22)]

Sebastian W. schrieb:
> Weil in Wire.requestFrom() schon die gesamte Kommunikation stattgefunden
> hat, und mit Wire.available() nur noch aus einem internen Puffer des uC
> gelesen wird.

Gut, wenn das in der vom OP benutzten Lib so ist, dann sollte das 
Programm trotz des Schleifenfehlers funktionieren.

ABER: Google sagt, dass es mit requestFrom() ein Timing-Problem 
gab/gibt, dem man zum Glück ausweichen kann:
https://arduino.stackexchange.com/questions/43007/why-is-a-delay1-necessary-before-wire-requestfrom

[Rainer W. (rawi)]

Björn S. schrieb:
> Auch wenn dies hier nicht das Problem ist, sind die Widerstände für
> meinen Geschmack zu hochohmig.

Woher willst du wissen, welche Kapazität der Bus bei Luca hat?
Hast du schon einmal in die I2C-Bus Spezifikation reingeguckt?
Abb. 41 und 42 geben Maximal- und Minimalwert in Abhängigkeit von 
Buskapazität bzw. Spannung an.
https://www.nxp.com/docs/en/user-guide/UM10204.pdf

10kΩ sind danach bis 100pF Buskapazität noch in Ordnung.

[Stephan S. (uxdx)]

Rainer W. schrieb:
> 10kΩ sind danach bis 100pF Buskapazität noch in Ordnung.

Und Abbildung 42 sagt, dass bei 3 Volt der Mindest-Widerstand 0,5 kOhm 
sei und bei 5 Volt knapp 2 kOhm (Standard und Fast Mode). Die 3 mA in 
der Abbildung 42 sind übrigens der Mindest-Strom, höhere Ströme sind 
nicht verboten. Im Interesse steiler Flanken würde ich da mit den 
Widerständen eher nach unten gehen. Wie oben schon gesagt, da muss ein 
Oszi her.

[Andreas M. (amesser)]

Lothar M. schrieb:
> Kurz: es ist die absolut schlechteste Idee, rinem Baustein die
> Bezugsmasse zu nehmen. Der sucht sich dann irgendeine andere. Und nimmt
> dabei evtl. bleibenden Schaden.

So ist es. Zumal auch nicht klar ist, was im inneren des ominösen China 
DC/DC passiert. Vermutlich ist der MCP schon von vorherigem rumgespiele 
hinüber.

Luca S. schrieb:
> Bei 0.5V / Div zumindest sehe ich überhaupt keinen Ripple auf 3.3V.

AC Messung wurde ja schon gesagt, Trigger korrekt einstellen und 
Zeitbasis muss auch passen. Es gibt übrigens auch einen Regler für das 
Offset. Wenn Du keinen Ripple misst, misst Du falsch. Jeder DC/DC hat 
prinzipbedingt Ripple. Die Frage ist nur, wie groß ist er. Ripple auch 
während der Messung durch den ADC gemessen? Ripple auch bei 
verschiedenen Eingangsspannungen gemessen?

[Luca S. (chababo)]

Lothar M. schrieb:
> Und vorher schon werden die Absolute Maximum Ratings einiger Bausteine
> verletzt...
>
> Kurz: es ist die absolut schlechteste Idee, rinem Baustein die
> Bezugsmasse zu nehmen. Der sucht sich dann irgendeine andere. Und nimmt
> dabei evtl. bleibenden Schaden.

Habe ich so auf mikrocontroller.net gefunden und übernommen. Nur ist zu 
beachten, dass das ja normalerweise nie der Fall ist. Man hängt das 
Gerät an und fertig. Nur falls sich der Kunde gar nicht achtet und 
falsch herum anhängt, wird die Masse eben nicht "freigegeben".. 
Funktioniert zumindest auch.

Andreas M. schrieb:
> Vermutlich ist der MCP schon von vorherigem rumgespiele
> hinüber.

Also ich muss ehrlich sagen, ich habe es noch seeehr selten geschafft, 
einen Hardwarebaustein zu zerstören. Da muss man doch meist mit dem 
Hammer draufhauen oder eine komplett falsche Spannung anlegen

Weiss auch nicht, welches "rumgespiele" du meinst. Ansteuerung per I2C?
Habe ihn übrigens auch schon ausgetauscht mal. Mit dem gleichen 
Resultat. Wird also wohl ein SW-Problem sein, was ich nicht sehe. Aber 
ich habe jetzt eine alternative Lösung erarbeitet.

Andreas M. schrieb:
> Zumal auch nicht klar ist, was im inneren des ominösen China
> DC/DC passiert.

Die beiden Massen sind übrigens verbunden, habe nachgemessen.

Rahul D. schrieb:
> Siehe Bild im Anhang...

Ist so, aber man muss halt manchmal auch etwas Effizienzdenken 
dazunehmen. Meistens funktioniert es ja. Habe vorher geschaut, für 
welche ADCs ich mehrere Arduino-kompatible Libraries finde, habe 
gedacht, etwas davon wird wohl funktionieren.

[Rahul D. (rahul)]

Luca S. schrieb:
> Meistens funktioniert es ja.

Interessant ist es, wenn es nicht funktioniert...
Welche Auswirkungen hat das?

[Monk (Gast)]

Luca S. schrieb:
> Ist so, aber man muss halt manchmal auch etwas Effizienzdenken
> dazunehmen.

Genau. Deswegen sollte das Ratespiel beendet werden. Messen ist 
angesagt.

[Frank E. (Firma: Q3) (qualidat)]

Mal eine ganz andere Frage: Warum überhaupt diesen ADC? Der hat lt. 
Datenblatt einen Auflösung von 10 Bit, die im ESP32 eingebauten dagegen 
12 Bit ...?

[Monk (Gast)]

Frank E. schrieb:
> die im ESP32 eingebauten dagegen 12 Bit ...?

Theoretisch ja, praktisch nicht. Probiere ihn mal aus, dann merkst du 
es.

[Rainer W. (rawi)]

Stephan S. schrieb:
>  Im Interesse steiler Flanken

Das Ziel beim I2C sind nicht möglichst steile Flanken, sondern ein 
sicher definierter Pegel in dem Moment, wo der jeweilige Empfänger das 
Signal von der Leitung liest. Genau diese Anforderung wird durch die 
Abb. 41 abgedeckt.

Stephan S. schrieb:
> Die 3 mA in der Abbildung 42 sind übrigens der Mindest-Strom, höhere
> Ströme sind nicht verboten.

Die 3mA sind der Strom, bei dem die Spannung am Ausgangstreiber 
spezifiziert ist, d.h. solange man die 3mA NICHT überschreitet, 
garantiert das Datenblatt den angegebenen Low-Level am Treiberausgang 
(VOL1). Der Low-Level wird also schlechter, wenn man zu Gunsten 
steilerer Flanken die 3mA ÜBERSCHREITET.

Mit höherem Strom speist du auch mehr Energie ein, so das zusammen mit 
steilen Flanken Signalreflektionen entsprechen kritischer werden.
Eine Diskussion über Serienwiderstände (7.3 Series protection resistors 
in den Specs) würde hier jetzt allerdings zu weit führen.

Inwieweit man durch hohen Ströme die Quellimpedanz für den High-Level zu 
Gunsten einer höheren Störunempfindlichkeit verringert, hängt von den 
jeweiligen Anforderungen ab.

[Stephan S. (uxdx)]

Luca S. schrieb:
> Hier mal ein paar Werte:
>
> Uin: 6V --> ADC: 152 (Störungen von 280)
> 7V --> ADC: 219 - 280
> 8V --> ADC: 542 (stabil)
> 9V --> ADC: abw. 542 und 606
> 10V --> ADC: 549 und 678

Ich hab mir mal einige Werte angesehen und diese als Bits dargstellt:

152 0b0010011000
280 0b0100011000

219 0b0011011011
280 0b0100011000

542 0b1000011110
606 0b1001011110

549 0b1000100101
678 0b1010100110

Bei den zweien ist das nur ein springendes Bit, das könnte doch auf den 
I2C-Bus hinweisen.

[Wastl (hartundweichware)]

Ich habe schon sehr am Anfang der Diskussion indirekt darauf
hingewiesen dass auch der Aufbau eine Rolle spielen kann:

Wastl schrieb:
> Und wo ist der Schaltplan und der Aufbau?

Nachdem ich hier keinen Aufbau gesehen habe scheint der TO es
ja auch nicht für nötig zu erachten mal einen Blick auf sein
Werk richten zu lassen. Da ist alles perfekt ("am Öl kann's
nicht gelegen haben, war ja keins drin").

Hier im weiteren Fortgang scheint auch niemand Zweifel am
physikalischen Aufbau der Schaltung (nicht der prinzipiellen
Verschaltung) zu haben. Oder habe ich im Wust von Kommentaren
etwas übersehen?

Na denn, dann ist ja alles in Butter. Oder doch nicht?

[Monk (Gast)]

Wastl schrieb:
> Hier im weiteren Fortgang scheint auch niemand Zweifel am
> physikalischen Aufbau der Schaltung (nicht der prinzipiellen
> Verschaltung) zu haben. Oder habe ich im Wust von Kommentaren
> etwas übersehen?

Wenn man eine Schaltung für mögliche Mängel kritisiert, ohne sie konkret 
gesehen zu haben, wird man als alter Meckersack beschimpft. Und zwar 
jedes Jahr mehr als zuvor. Im Zeitalter von "ist doch ganz einfach" und 
"du kannst alles" Videos, wird Fachwissen weniger wert geschätzt.

Dazu kommt, dass die alten Meckersäcke wirklich älter werden. (Wer hätte 
das gedacht?). Vor einiger Zeit war hier auch das Wort "Bedenkenträger" 
in Mode. Ja, alte Leute bedenken mehr. Das nennt man: weise werden.

[Andreas M. (amesser)]

Luca S. schrieb:
> Ich habe 2 verschiedene Libraries für Arduino getestet, leider
> funktioniert nichts davon:
> https://github.com/mkuniac/MCP3021/tree/master
>
> https://reference.arduino.cc/reference/en/libraries/mcp3x21/

Ich habe mir beide Libraries angeschaut. Beide sind Schrott. Die erstere 
initialisiert die Variablen nicht anständig, zweitere führt 
Schiebeoperationen auf Signed Integern durch was UB/IB sein kann. Und 
beide hoffen drauf, das niemand anderes zwischen requestFrom() und 
read() auf den I2C zugreift.

Verstehe sowieso nicht wozu man zum Lesen von 2 Byte via I2C ne extra 
Library benötigt.

Beim ESP32 kann man mit Shifts auch ziemlich auf die Nase fallen. Bei 
der Tensilica CPU führen "<<" und ">>" auf 32 Bit Variablen um mehr als 
32 Bits zu anderen Ergebnissen als man es kennt. Ist nach C/C++ auch UB, 
also zulässig. Ist mir bisher so nur beim ESP32 aufgefallen.

[Luca S. (chababo)]

Andreas M. schrieb:
> Ich habe mir beide Libraries angeschaut. Beide sind Schrott. Die erstere
> initialisiert die Variablen nicht anständig, zweitere führt
> Schiebeoperationen auf Signed Integern durch was UB/IB sein kann. Und
> beide hoffen drauf, das niemand anderes zwischen requestFrom() und
> read() auf den I2C zugreift.

Was ist den UB/IB?

Ich habe allerdings nur einen Master, sollte daher auch nichts auf dem 
Bus sein in der Zwischenzeit.

Andreas M. schrieb:
> Verstehe sowieso nicht wozu man zum Lesen von 2 Byte via I2C ne extra
> Library benötigt.

Schon, aber ich habe mir angeschaut, was gemacht wird mit den 2 Bytes 
und es ausgewertet auf einem Blatt, bin darauf gekommen, dass es Sinn 
machen sollte.

Was würdest du denn konkret anders machen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Luca S. schrieb:
> Habe ich so auf mikrocontroller.net gefunden und übernommen.
Man sollte so etwas, was man gefunden hat erst dann übernehmen, wenn man 
es verstanden hat.

Der Witz an diesen Verpolschaltungen ist, dass sie genau für den Fall 
gemacht und gedacht sind, dass keine andere Leitung zwischen den beiden 
"Schaltungsteilen" verläuft. Sie funktionieren also dann super, wenn man 
sie quasi "zur Batterie gehörig" betrachtet, Sie machen quasi aus einer 
"normalen Batterie" eine "garantiert richtig gepolte Batterie". Und da 
dahinter kommt dann die eigene Schaltung.

Wenn du eine zusätzliche Verbindung da reinmachst, dann musst du dir die 
Konsequenzen näher anschauen.

Luca S. schrieb:
> Was ist den UB/IB?
Undefined Behavior und Implicit Behaviour

Stephan S. schrieb:
> Bei den zweien ist das nur ein springendes Bit, das könnte doch auf den
> I2C-Bus hinweisen.
Serielle Busse nimmt man folgendermaßen in Betrieb:
1. man kontrolliert, ob die Pegel der Signale zum Datenblatt passen
2. man kontrolliert, ob die Flanken sauber aussehen und zum Datenblatt 
passen
3. wenn es 2 zusammengehörige Signale gibt (wie z.B. I2C->SCL/SDA oder 
SPI->SCLK/MOSI/MISO), dann kontrolliert man, ob das Timing der Signale 
zueinander und zum Datenblatt passt
4. man kontrolliert, ob die Bits in der laut Datenblatt nötigen 
Reihenfolge auf dem Bus auftauchen
5. man kontrolliert beim I2C, ob das Timing bei der Busübergabe (z.B. 
ACK) funktioniert
6. dann erst kommt die Inbetriebnahme in der Software auf 
Protokoll-Ebene

Und genau so sind auch die Datenblätter aufgebaut.

Wenn man blind irgendwo irgendwas herkopiert, die Punkte 1-5 weglässt 
und gleich bei 6 anfängt, dann ist das, wie wenn man ein Autorennen 
fährt und nicht vorher seine Hardware kontrolliert (Öl, Luftdruck) und 
in Betrieb nimmt. Und dann muss man sich nicht wundern, wenn es einen 
Kolbenfresser gibt oder die ganze Karre irgendwie in der Gegend 
herumschlingert.

Wie schon der Wastl schrieb:
> ("am Öl kann's nicht gelegen haben, war ja keins drin").

Luca S. schrieb:
> Also ich muss ehrlich sagen, ich habe es noch seeehr selten geschafft,
> einen Hardwarebaustein zu zerstören.
Ja, man lernt nie aus. Der muss ja nicht so kaputt sein, dass er nicht 
mehr tut, sondern nur so, dass er nicht mehr richtig tut.

> Also ich muss ehrlich sagen, ich habe es noch seeehr selten geschafft,
> einen Hardwarebaustein zu zerstören.
Ich habe da im Beitrag "Re: LM8705 gegen Rückspannung absichern" mal 
einen Fall, wo die Spec eines simplen Spannungsreglers nur für ein paar 
ms verletzt wird und es danach das Bauteil zerreißt.

[Andreas M. (amesser)]

Lothar M. schrieb:
> Luca S. schrieb:
>> Was ist den UB/IB?
> Undefined Behavior und Implicit Behaviour

Fast :-) Letzteres: Implementation Specific Behavior. Heißt es kommt auf 
Compiler/Platform an.

Luca S. schrieb:
> Schon, aber ich habe mir angeschaut, was gemacht wird mit den 2 Bytes
> und es ausgewertet auf einem Blatt, bin darauf gekommen, dass es Sinn
> machen sollte.

Naja, also bis man die Libraries zusammengesucht hat und dann geprüft 
hat, ob sie tun was sie sollen("und es ausgewertet auf einem Blatt") hat 
man das hier doch schneller selbst implementiert? Am Ende ist es eine 
Funktion die ca 5. Zeilen Code hat. Die ist schneller implementiert als 
die Suche im Webbrowser gemacht ist.

> Was würdest du denn konkret anders machen?

Hier nicht auf Arduino SDK setzen. Arduino ist gut, wenn man mal schnell 
was probieren will und sich möglichst auf den 8 Bittern bzw. Arduino 
Hardware bewegt von denen Arduino herkommt. Wenn ich einen ESP32 
verwende, dann nutze ich das Espressif SDK, das kommt direkt vom 
Hersteller und ist näher an der Hardware.

Desweiteren würde ich keinen externen ADC einsetzen. Der ESP32 hat einen 
internen ADC der für diesen Anwendungsfall hier vollkommen ausreichend 
ist. Es gibt hier keinen Grund was externes dranzupappen.

Thema Verpolungsschutz hatte ich schon gesagt, da wäre ein P-Channel auf 
der positiven Spannungsseite besser gewesen. Es fehlt auch eine 
Sicherung. Ein modernerer Buck für die 3.3V der im MHz Bereich taktet. 
Den hätte ich dann auch direkt von der Batterie gespeist. Den komischen 
12V Regler dann nur für die Led-Versorgung. Und den eigentlich auch weg: 
24V Led + PWM fähigen Boost DC/DC. Am ESP32 fehlt der JTAG zum Debuggen. 
Benutzt du eigentlich WLAN? Wenn nein, dann hätte ich statt dem ESP nen 
nRF von Nordic benutzt.

[Luca S. (chababo)]

Andreas M. schrieb:
> Naja, also bis man die Libraries zusammengesucht hat und dann geprüft
> hat, ob sie tun was sie sollen("und es ausgewertet auf einem Blatt") hat
> man das hier doch schneller selbst implementiert?

Ja, wäre in dem Fall wohl besser gewesen.

Andreas M. schrieb:
> Wenn ich einen ESP32
> verwende, dann nutze ich das Espressif SDK, das kommt direkt vom
> Hersteller und ist näher an der Hardware.

Muss ich mir mal anschauen.

Andreas M. schrieb:
> Desweiteren würde ich keinen externen ADC einsetzen. Der ESP32 hat einen
> internen ADC der für diesen Anwendungsfall hier vollkommen ausreichend
> ist. Es gibt hier keinen Grund was externes dranzupappen.

Hatte ich zuerst vor, dann habe ich mich zum Thema eingelesen und bin 
darauf gestoßen, dass dieser höchst nichtlinear und unpräzise sein soll, 
ev. gab es noch andere limitierende Gründe (Pins, Hardwaremodule, die 
nicht funktionieren, wenn xy..). Um die Batteriespannung zu messen hätte 
es aber vermutlich ausgereicht, wie du geschrieben hast.

Andreas M. schrieb:
> Und den eigentlich auch weg:
> 24V Led + PWM fähigen Boost DC/DC.

Kann ich mir das so vorstellen, dass dieser eine Datenleitung zur 
Steuerung hat und dann direkt ein PWM Signal ausgibt? Gibt's die auch 
für bis ca. 8A Strom?

Andreas M. schrieb:
> Benutzt du eigentlich WLAN?

Ja, ich lasse darauf ein Webinterface laufen, über das das Modul 
gesteuert wird.