- Labornetzteil AliExpress         
Ergebnis 1 bis 10 von 16

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

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    06.09.2009
    Beiträge
    23
    Viele dank für die kompetente Antwort!
    Eine Spannungsteilerschaltung hab ich nicht, der Ausgang des LM35 hängt direkt am Analogen Eingang. Der LM35 wird mit VCC und GND an die Versorgungsspannung angeschlossen und liefert dann am Ausgang exakt 10mV pro °C.
    Den Tipp mit der Dummy-Messung werd ich gleich mal testen, hast du einen Vorschlag wie lang der Delay sein sollte? Ich hab da leider 0 Vorstellung...!

  2. #2
    Neuer Benutzer Öfters hier
    Registriert seit
    06.09.2009
    Beiträge
    23
    oh man...
    nachdem ich mir gestern noch den ganzen abend mit einem pt1000 um die ohren gehauen hab um einen rechenweg zu finden mit dem ich vernünftige temperaturen rauskrieg (ich hab keinen gefunden), hab ichs heut nochmal mit dem lm35 versucht.
    3 stück angeschlossen, 3 stück abgefragt, super stabile werte bekommen. mit und ohne delay.
    jetzt hab ich aus freude alle 5 Sensoren fertig verkabelt, angeschlossen, und krieg wieder nur müll raus. erstmal mit abfragen von nur 3 sensoren, dann mit einer programmänderung dass alle 5 abgefragt werden, und auch mit delay zwischen 50 und 500ms.
    ich verstehs nicht, und so langsam hab ich keinen bock mehr
    was bitte mach ich falsch? die verkabelung war bei allen versuchen gleich, und auch die programmierung!

  3. #3
    Erfahrener Benutzer Roboter Genie Avatar von BMS
    Registriert seit
    21.06.2006
    Ort
    TT,KA
    Alter
    34
    Beiträge
    1.192
    Hallo,
    ich vermute eher, dass die Spannungsversorgung nicht ganz "sauber" ist. Kannst du mal die 3,3V mit einem Oszilloskop anschauen? Eventuell ist da noch ripple drauf.
    Die AREF könnte man noch filtern, meist ist hier ein LC-Tiefpass üblich (RC geht auch). Also in die Leitung von den 3,3V zu AREF z.B. ein Widerstand (10...100Ohm?) und dann von AREF zu GND ein Kondensator (100nF, 1µF ?).
    Beim LM35 kannst du auch einen Kondensator zwischen Analogpin und GND einbauen.
    Da der Fehler scheinbar bei mehreren Sensoren auftritt, kannst du auch mal alle Analogpins nacheinander testen - also einen Sensor nehmen, und dann nacheinander immer nur einen Analogpin testen (auch in Software immer nur einen Pin messen), um hier Fehlerquellen auszuschließen. Evtl. kannst du den Analogpin auch mal direkt mit GND oder 3,3V verbinden, der Wert in der Software muss dann auch wirklich das Minimum oder Maximum erreichen können. Sonst ist etwas faul
    Und dann würde mich noch interessieren, wie die Methode analogRead programmiert ist (Stichworte Acquisition Time; ADC Clock).
    Grüße, Bernhard

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    06.09.2009
    Beiträge
    23
    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  
    Geändert von Zeitsklave (14.12.2012 um 18:29 Uhr)

  5. #5
    Erfahrener Benutzer Roboter Genie Avatar von BMS
    Registriert seit
    21.06.2006
    Ort
    TT,KA
    Alter
    34
    Beiträge
    1.192
    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.
    Geändert von BMS (14.12.2012 um 19:37 Uhr)

  6. #6
    Neuer Benutzer Öfters hier
    Registriert seit
    06.09.2009
    Beiträge
    23
    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:

    Code:
    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;
    }

  7. #7
    Erfahrener Benutzer Roboter Genie Avatar von BMS
    Registriert seit
    21.06.2006
    Ort
    TT,KA
    Alter
    34
    Beiträge
    1.192
    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):
    Code:
    //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
    Geändert von BMS (14.12.2012 um 20:37 Uhr)

Ähnliche Themen

  1. Antworten: 0
    Letzter Beitrag: 10.12.2012, 19:50
  2. RS232 Problem - Nur wirre Zeichen
    Von YaNnIk im Forum AVR Hardwarethemen
    Antworten: 13
    Letzter Beitrag: 21.08.2009, 14:51
  3. Analogeingänge abfragen..aber wie ???
    Von Goliath im Forum C - Programmierung (GCC u.a.)
    Antworten: 5
    Letzter Beitrag: 16.06.2008, 11:41
  4. Terminal - bekomme nur wirre Zeichen
    Von forty im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 5
    Letzter Beitrag: 26.11.2007, 22:38
  5. Wirre Daten über ISP?
    Von SeveQ im Forum AVR Hardwarethemen
    Antworten: 1
    Letzter Beitrag: 05.05.2006, 05:43

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test