Mehrere Analogeingänge abfragen erzeugt nur wirre Daten vom LM35...

[Zeitsklave]

Also ein 100nF Kondensator und 50Ohm haben nichts bewirkt, 100nF direkt am LM35 leider auch nicht.
Ich habe 5 LM35 an 5 Analogen eingängen (1-5). Gestern hatte ich 3 LM35 an 3 Eingängen (1,3,5), und es hat funktioniert... Im Quelltext hab ich nur die vier Zeilen hinzugefügt, die zusätzlich die Eingänge 2 und 4 auslesen.
Egal ob ich das Board über USB mit Stom versorge oder über das Netzteil meiner ausgangierten Fritz!Box (das zufälligerweise perfekt passt!), die ergebnisse bleiben komplett gleich!

Hier mal ein Screenshot meiner Ergebnisse wie ich sie im Browser ausgebe:
Bild hier  

Wenns vorher ging und jetzt, nachdem ich sämtliche Sensoren fertig konfektioniert habe, kanns ja eigentlich fast nur noch an der Verkabelung liegen. Wenn ich die Abfrage für 2 und 4 wieder auskommentiere hab ich immernoch die gleichen verrückten Werte.
Allerdings hatte ich das Problem ja vorher auch schon, wie im ersten Post beschrieben, praktisch mit der gleichen Verkabelung, mit ders dann später plötzlich mal funktioniert hat...

Ich bin ratlos...

Ich hab zwar einen alten Oszillographen am Dachboden (der wohl älter ist als ich...), aber bis ich den wieder runterschlepp und enstaub... Ich weiß nichtmal ob das Ding für sowas geeignet ist, ganz zu schweigen davon dass ich nie richtig kapiert hab wie man das Monster bedient ^^



Edit: Endlich Erfolg! Ich war vorhin wohl doch zu voreilig... Die Kondensatoren direkt am LM35 zwischen Signal und GND haben das Ruder rumgerissen!
Die Werte sind zwar noch nicht 100% sauber, haben sich aber trotzdem deutlich stabilisiert, und wären jetzt prinzipiell für meinen Zweck zu gebrauchen. Wobei es natürlich schön wäre wenn die Kurve noch ein bisschen glatter wäre... Gehe ich richtig in der Annahmen, dass ein höherer Wert am Kondensator ein stabileres Signal liefert?
Bild hier  

[BMS]

Hallo,
das untere Diagramm sieht ja schon deutlich besser aus, freut mich
Eine größere Kapazität könnte eventuell noch eine Verbesserung bringen, wohl aber nicht beliebig besser, denke ich.
Aber mich wundert, dass die Messwerte im ersten Diagramm so stark verrauscht waren Da sind ja Sprünge um 20 Grad drin, wären bei 10mV/°C Sprünge um 200mV.
Kannst du bitte den Code von analogRead() raussuchen? Eventuell muss dort eine Pause nach der MUX-Einstellung rein (sog. Acquisition Time -> damit sich der interne Kondensator der Sample-And-Hold-Stufe im ADC lang genug auf die neue Spannung aufladen kann)
Grüße, Bernhard

Nachtrag: Was auch helfen sollte, ist eine Mittelung im Programm. Also du könntest mehrere Messungen direkt nacheinander durchführen (nur an einem Kanal) und dann den Durchschnitt berechnen. Das dürfte das Rauschen auch noch reduzieren.

[Zeitsklave]

Ich hab jetzt mal auf dem ersten Sensor eine Mittelwertmessung gebastelt, mal sehen was dabei rauskommt Ich wart bis morgen damit, weil ich schonmal das Intervall auf 10 Minuten gestellt hab, so wies sein soll...

Ich bin nicht sicher ob ich das Richtige in den Arduino-libaries gefunden hab:

int analogRead(uint8_t pin)
{
    uint8_t low, high;

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
    if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
    if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644P__)
    if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
    if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif
    
#if defined(__AVR_ATmega32U4__)
    pin = analogPinToChannel(pin);
    ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#elif defined(ADCSRB) && defined(MUX5)
    // the MUX5 bit of ADCSRB selects whether we're reading from channels
    // 0 to 7 (MUX5 low) or 8 to 15 (MUX5 high).
    ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#endif
  
    // set the analog reference (high two bits of ADMUX) and select the
    // channel (low 4 bits).  this also sets ADLAR (left-adjust result)
    // to 0 (the default).
#if defined(ADMUX)
    ADMUX = (analog_reference << 6) | (pin & 0x07);
#endif

    // without a delay, we seem to read from the wrong channel
    //delay(1);

#if defined(ADCSRA) && defined(ADCL)
    // start the conversion
    sbi(ADCSRA, ADSC);

    // ADSC is cleared when the conversion finishes
    while (bit_is_set(ADCSRA, ADSC));

    // we have to read ADCL first; doing so locks both ADCL
    // and ADCH until ADCH is read.  reading ADCL second would
    // cause the results of each conversion to be discarded,
    // as ADCL and ADCH would be locked when it completed.
    low  = ADCL;
    high = ADCH;
#else
    // we dont have an ADC, return 0
    low  = 0;
    high = 0;
#endif

    // combine the two bytes
    return (high << 8) | low;
}

[BMS]

Hallo,
im Code ist keine wirkliche Wartezeit (Acquisition Time) drin. Hier die wichtigen Zeilen aus deinem Code, die dafür verantwortlich sind (gekürzt, geändert):

//hier wird festgelegt, welcher Analogeingang gelesen werden soll
ADMUX = (analog_reference << 6) | (pin & 0x07);

//Das ist die quasi nicht vorhandene Acquisition Time
//hier solltest du unbedingt eine kleine Wartezeit einbauen, mehrere Mikrosekunden sind unbedingt erforderlich!
//RC-Kombination im Sample-And-Hold: ca. 1...100kOhm und 14pF in vergleichbaren ATmegas, also Zeitkonstante t=R*C=1,4 Mikrosekunden mindestens an Wartezeit nötig, lieber etwas mehr!
//without a delay, we seem to read from the wrong channel <-- da hat sich der Programmierer wohl etwas dabei gedacht, dann aber das delay wieder auskommentiert !?
//delay(1); ///<---------HIER

//AD-Wandlung geht los...
sbi(ADCSRA, ADSC);

Mit einer kleinen Wartezeit an der genannten Stelle sollte die AD-Wandlung deutlich stabilere Ergebnisse bringen. Wenn das noch nicht reicht, kann man noch den Takt für den AD-Wandler reduzieren (Register ADCSRA, Prescaler-Einstellungen, z.B. ADCSRA |= 0x07; ).
Gutes Gelingen weiterhin!
Grüße, Bernhard

[RoboHolIC]

Eine Abschätzung zur Delayzeit:

Die Signalquelle, hier der Ausgang des LM35, hat einen gewissen Innenwiderstand. Im Inneren des Controller ist ebenfalls ein Widerstand wirksam, der die Aufladung des Samplingkondensators bremst, Größenordnung 1kOhm, spezifiziert im Datenblatt des Controllers.

Die Reihenschaltung des äußeren und inneren Widerstandes und die Kapazität des Samplingkondensators bilden eine Zeitkonstante tau = (R_ext + R_int) * C_sampling. Das sieht auf den ersten Blick komisch aus, ist nach den Einheiten aber wirklich eine Zeit: (V/A) * (A*s/V) --> s.

Eine sprungartige Veränderung der zu messenden Spannung (z.B. beim ADC-Kanalwechsel) ist nach 1x tau erst zu 63% am Samplingkondensator sichtbar, d.h. es fehlen zum Endwert noch 37%. Nach 2* tau fehlen nur noch (oder: immer noch) 0,37*0,37*100 = 14% des eingangsseitigen Spannungshubes bis zur völligen Angleichung der Samplingspannung an die zu messende Spannung.

Es braucht folglich schon einige tau, um unter 1 Bit Abweichung des ADC-Ergebnisses (Reading) von tatsächlichen Wert zu kommen. Je größer der Spannunhshub zwischen (n-1)-tem und n-tem Sampling ist, desto mehr tau's braucht es, um die 1-Bit-Grenze zu unterschreiten.

P.S.: Ich habe gerade gesehen, dass wikipedia eine gute Abhandlung über das Thema "Zeitkonstante" bietet.

[BMS]

Die genauen Werte finden sich im Datenblatt ( www.datasheetcatalog.org/datasheets2/30/3055029_1.pdf ) auf Seite 282.
R=1...100kOhm, C=14pF
Nehmen wir mal den worst-case an (R=100kOhm) und warten 5*tau, damit sich der Kondensator auf über 99% aufladen kann.
Dann müssen wir 5*tau=5*R*C=5*1e5Ohm*1,4e-11F=7µs warten (Mikrosekunden); bei z.B. 10kOhm Quellimpedanz dann 10% länger.

[Zeitsklave]

Oh je, sooo tief wollt ich doch auch nicht in die Materie einsteigen
So viel Fachwissen darf doch eigentlich nicht nötig sein um einfach 5 Analoge Anschlüsse auszulesen, ganz besonders bei einem Board wie Arduino...
Aber gut, was solls
7µs ist ja ziemlich wenig, da sollte das delay(1), das ich gestern noch "de-auskommentiert" hab locker reichen.
Ich hab auch gestern (oder wars vorgestern schon?) die Mittelwertrechnung eingebaut, mit 5 Werten und 10ms Abstand. Trotz dem Mittelwert und dem delay(1) waren jetzt die Werte noch ziemlich wackelig, obwohl ich jetzt schon innerhalb von einem Grad bin, also durchaus brauchbar. Einzig der Sensor mit der längsten Leitungslänge schwankt noch um etwas mehr als 1 Grad, der hat allerdings nur 68nF dranhängen, ich hatte nix besseres mehr da...
Jetzt hab ich mal die Mittelwertrechnung auf 10 Werte mit je 20ms Abstand ausgedehnt, mal sehen ob ich jetzt das Diagramm etwas geglättet krieg (Sieht einfach schöner aus).

Vielen vielen Dank für das Hirnschmalz erstmal, ich werd weiter berichten!