Poti an ADC: "Fixieren" von ADC-Daten?

Hm, eine Hysterese wäre möglich, würde ja aber quasi das Messergebnis verfälschen. Denn müsstest du ja beispielsweise um von 40 zu 42 zu kommen erst über 50 gehen.

Wäre aber leicht einzubinden. Einfach den alten Wert speichern und dann wenn ein Neuer ankommt checken ob er um sagen wir 5 abweicht. Wenn ja alten Wert aktualisieren und neuen Wert verarbeiten, sonst nicht.

Ich würde auch mal versuchen einen Durchschnittswert zu bilden. Also z. B. 16 Ergebnisse zu sammeln, Ergebnis / 16, und dann verarbeiten. Der ADC ist ja relativ fix.

Da du die ADC Werte aber eh schon durch 8 teilst wundert es mich dass da noch etwas schwankt. Ist der Kondensator am V_REF dran? Ist die Betriebsspannung sauber? Wie ist der Poti angeschlossen? Als Spannungsteiler VCC - GND oder offen? Ist noch etwas dazwischen (wie OpAmp)? Schaltest du die ADC Kanäle schon um? Ich hatte mal das Problem dass nach dem Umschalten die erste Messung nicht ganz so zuverlässig war.

Thomas hat eigentlich das wesentliche bereits angedeutet.

Fast alle AVR besitzen einen 10-Bit-ADC, mir ist nur der ATtiny5/10 bekannt, der nur 8 Bit hat. Allerdings kannst Du das Messergebnis auch linksorientiert in die beiden Ergebnisregister ausrichten lassen, und dann nur das Highbyte davon verwerten - kannst Du im Datenblatt unter ADC -> Register Description -> ADCH/L nachlesen.

Dann gibt es diverse Empfehlungen um Rauschen zu minimieren

• Versorgung des analogen Bereiches (AVcc) über einen Tiefpaß (und getrennt vom digitalen Bereich)
• AGnd über Single Point Connection
• kurze Signalwege
• Aus AVcc versorgte I/Os während einer Conversion nicht schalten
• Digitale Input Puffer der Eingänge Abschalten
• Durch den AVR selbst verursachtes Rauschen vermindern, indem der (bis auf die ADC-Clock) weitgehend "eingeschläfert" bzw "gestoppt" wird -> ADC-Noisereduction-Sleepmode

Steht im Datenblatt üblicherweise unter ADC -> Noise Canceller -> Noise Cancelling Techniques

---

Das alles wird Dein Problem aber nicht komplett lösen können - Du hast halt analoge "Werte" (quasi unendlich viele, unendlich hoch aufgelöst), die Du in wenige, schwach aufgelöste diskrete Werte digitalisieren willst. Dadurch hast Du immer Grenzen zwischen Deinen Werten, wo das hin und herkippt. Selbst, wenn nur das LSB zappelt, kann das sich durch die binären Überläufe bis zum MSB hin auswirken, dh. wenn alle Bits dazwischen bereits 1 oder 0 sind, zappelt auch das MSB.
Zur angesprochenen Mittelwertbildung, das kann man bei Deinem konkreten Fall eleganter machen:
Du addierst einfach 2⁵=32 10-Bit-Ergebnisse auf. Dann stehen im Highbyte bereits die oberen 7 Bit.
Allerdings wirst Du auch da "kippende" Ergebnisse haben, um das zu vermeiden, kommst Du um die Hysterese nicht rum. Dann ist es allerdings besser (->Thomas bereits angedeutet), die Hysterese mit der vollen Auflösung zu prüfen (bzw mit den nicht mehr zappelnden Bits).

Vllt. hilft auch ein "Median Filter".....

http://www.mikrocontroller.net/articles/Median_Filter

Das ändert doch aber auch nichts am Problem, es geht ja hier nicht um Ausreisser oder stark schwankende Messwerte. Wenn das Messergebnis genau an einer Grenzschwelle zwischen zwei diskret unterschiedlichen Zielwerten rauscht, kippt doch der Median ebenso. Wenn Du jedesmal abwechselnd 127 und 128 als Ergebnis erhälst (also eigentlich nur das LSB zappelt), zappelt Bit6 mit. Daran ändert auch das konventionelle arithmetische Mittel nichts. Weil eben immer zu einem der beiden möglichen Werte hinentschieden werden muß.
Beim Median ist es der "in die Mitte sortierte" Wert, hier also der häufigere der beiden möglichen Werte. Das kann dann also auch wieder abwechselnd 127 oder 128 sein.

Der ADC erfaßt 10 Bit, Andreas interessieren nur die oberen sieben. Ob man nun lediglich die letzten 3 wegläßt, rundet oder auch mittelt, ändert nichts, wenn der Wert genau an den Schwellen rauscht. (also zwischen 0bxxxxxxx111 und (0bxxxxxxx111+0b0000000001) schwankt.

Mit der Hysterese ist das ja so, daß eben nicht jede Veränderung am Eingang als neuer Messwert verwertet wird, sondern nur wenn die Abweichung hinreichend groß ist. Bei Dir zappeln ja nur ein/zwei Bits (was sich allerdings auch auf die höherwertigen Bits addiert - deswegen reicht irgendeine Mittelwertbildung oder Teilen (Rechtsschieben) nicht aus. Vielmehr ist die Differenz zwischen altem und neuen Wert als Kriterium heranzuziehen. Ist die größer als das Zappeln, hast Du 'n neuen Wert. Sinnigerweise verwendest Du für die Differenzbestimmung die vollen 10 Bit (vor der Reduktion auf die benötigten 7 Bit).

Unter Assembler würde ich das in etwa so angehen:
Der ADC ermittelt das Ergebnis linksorientiert.
Dieses wird einmal rechtsgeschoben (also die oberen 7 Bit im highbyte, die letzten 3 Bit linksorientiert im lowbyte).
Das ganze wird vom letzten Wert (der ebenso gespeichert wurde) abgezogen (SUB, SBC).
Kam es dabei zu einem Überlauf (also war der neue größer als der alte), wird das Ergebnis negiert (COM, NEG, SBCI).
Damit hast Du den Betrag der Differenz - überschreitet einen kritischen Wert (Rauschen/Zappeln), kann der alte Wert durch den neuen überschrieben werden (alle 10 Bit), sonst nicht.

Dein Programm wertet lediglich das obere der beiden Bytes aus, das mit den 7 höherwertigen Bits.

Anmerkung: War jetzt nur so 'ne erste Idee, Möglicherweise geht das mit dem Betrag der Differenz auch einfacher über'ne Fallunterscheidung - wenn neu>alt (CP, CPC) rechne neu-alt, sonst alt-neu... der Rest bleibt ... unter C (Hochsprache wird Dich das eh nicht so interessieren, mit der Idee kommst Du trotzdem mit?

Leicht Off-Topic:

Was mich jetzt mal interessieren würde: Warum nimmst du nicht einfach Rotary-Encoder?
Machen das die (neueren, digitalen) Synthesizer nicht auch so?
Da hättest du höchstens bei der Auswertung Probleme, aber für C gibts da ja schon zig fertige Lösungen.


Was LotadaC sagte stimmt, hatte ich nicht bedacht. Durchschnittswert hilft dir in dem Fall auch nicht weiter (es würde das Problem höchstens etwas lindern, wenn überhaupt).

Das mit dem Encoder hat er ja selbst bereits in #6 angedeutet...
Mittelwerte und so können einige Bytefolgen erschlagen, andere aber nicht. -> Linderung1
Außerdem verringert sich dadurch ja effektiv die Samplefrequenz (um die in die Mittelung einfließenden Samples) -> gefühlte Linderung2

Trotzdem lassen sich Bytefolgen finden, bei denen das auch nach der Mittelung zappelt.

Der Ansatz mit der Hysterese legt quasi 'ne Schwelle fest, bis zu der Änderungen ignoriert werden. Diese muß logischerweise über dem Rauschen und unter dem Nutzsignal liegen. Würde man das auf das bereits auf 7 Bit reduzierte ADC-Ergebnis (also den fertigen Wert) anwenden, also Änderungen um 1 Bit ignorieren, würde das Ergebnis bei einer Änderung immer um mindestens 2 Springen.
Es stehen dem ADC aber 10 Bit zur Verfügung, bezogen auf die zu verwertenden 7Bit hätte man also achtel eines "Bit" für die Differenzbildung und die Ignorierschwelle. (Allerdings muß man sich dann auch immer die vollen 10 Bit des letzten/noch gültigen Ergebnisses merken. Deswegen Left adjusted und eins rechtsgeschoben -> das obere Byte enthält die gewünschten 7Bit, das untere die achtel-Subbits).

Hallo,

ich hätte noch folgende Lösung anzubieten:

Mittelwert über eine bestimmte Anzahl von Messungen bilden (z.B. 8 Messungen)
neuer Wert wir erst ermittelt, wenn Abweichung zum Mittelwert > 4 (Triggerschwelle)

Bei dieser Lösung ist das Bitmuster völlig egal, über die Triggerschwelle und die Anzahl der Messungen kannst du die Empfindlichkeit anpassen.

Grundsätzlich würde ich aber eine Lösung mit Encodern vorziehen, da eine exakte Auswertung von Analogsignalen immer aufwendiger und fehleranfälliger ist.

Gruss
gp177

Wo wertest Du denn die Differenz aus? Noch mit 10bit ADC-Auflösung, oder nach dem "teilen" auf 7bit? Irgendwie ist mir das Problem selbst nicht ganz klar - wenn eine hinreichend große Differenz vorliegt, soll er das doch mitbekommen.
Oder meinst Du, daß der letzte Wert beim Reset nicht initialisiert ist?
Beim Start einfach eine Messung für den Initialwert machen (Vorwert), und dann in die Schleife die die neuen Werte erfaßt, mit der Differenzbildung?

---

Zur EEPROM-Sache:
insbesondere zum Schreiben brauchst Du bei einigen Controllern verhältnismäßig viel Spannung - schau mal ins Datenblatt des Controllers ganz hinten bei den Erratas, da steht das manchmal...
Hmm... das über den BOD selbst zu machen... kann ich mir nicht vorstellen, daß das reicht. BOD erfaßt ja die interne Vcc, also wenn die bereits hinreichend eingebrochen ist. Dann müßte erstmal der BOD-Reset durchlaufen, Du könntest BORF abfragen, und versuchen die noch im SRAM befindlichen Werte ins EEPROM zu übertragen. Erstend kostet das zu viel Zeit, und zweitens müßte dazu der BOD ja irgendwie wieder freigegeben werden, während die Spannung eigentlich noch weiter fällt.
Scheint ein Holzweg zu sein...

Eher so:
Irgendwo bei der Spannungsversorgung (Schalt-/Linearregler etc) wird bereits die Spannung abgegriffen, dann kommt 'ne Schottkydiode und dahinter 'n hinreichend großer Speicherkondensator, der Deine eigentliche Schaltung und (zumindest) den Controller versorgt.
Die vorn abgegriffene Spannung landet über einen sinnigen Spannungsteiler am Controller, am ADC oder besser noch am AC, welcher beim Unterschreiten eines Schwellwertes einen Interrupt triggert.
Geht also vorn die Spannung runter, wird der Controller noch'ne Zeitlang aus dem Speicher versorgt, löst aber den IRQ aus, wo Du erstmal ggf alle stromverbrauchenden Externa abschalten lassen kannst, und dann Deine Sicherung ins EEPROM machen kannst. Da dieses nicht beliebig oft beschrieben werden kann, solltest Du vorher auslesen, ob der zu schreibende Wert vielleicht zufällig schon/noch drinnsteht - bei nur 127 diskreten Möglichkeiten, kann das ja durchaus sein...

Was LotadaC sagte ist schon eine gute Idee.
Ich würde es nur etwas anders machen (ohne externe Beschaltung).
Einfach einen Timer nutzen (man könnte auch den WatchDog hierfür missbrauchen) um zeitliche Interrupts zu bekommen, sagen wir alle 1-2 Sekunden. Darin die Werte in den EEPROM schreiben. Aber wie LotadaC schon sagte: Erst überprüfen ob das Schreiben überhaupt nötig ist da der Speicher sonst fix flöten geht.

Hmm...
Das ist doch aber in Hinsicht auf die zulässigen EEPROM-Schreibzyklen eher ungünstig. Also wenn dann im Worstcase alle 2s alternierende Bytes in die Speicherzelle geschrieben werden...
Eigentlich will er doch beim Abschalten den geltenden Wert im EEPROM hinterlegen, und beim Anschalten von dort laden.
Problem ist also, das "Abschalten" rechtzeitig zu erkennen, um dann noch die Daten (das Byte) zu sichern. Bei Bedarf.
Da der AVR aber nicht irgendwie definiert heruntergefahren wird (bzw er sich eben selbst darum kümmern muß), sondern einfach die Spannungsversorgung abgeschaltet wird, muß man eben darauf reagieren.

Joah, hast Recht, im Worst Case würden alle 2sec neu geschrieben. Aber ja nur wenn man am Poti rum fummelt. Aus der Sicht ist dene Lösung natürlich eleganter (wenn auch etwas kritischer, da wenn der Puffer Kondensator zu klein wird und die Spannung unter die sinkt die der EEPROM zum Beschreiben braucht...)

Meine Lösung wäre etwas eher in Richtung Hau-Ruck. Belastet den Speicher mehr, ja, dafür ganz ohne weitere Komponenten. Aber mal so ausgerechnet... Der Speicher überlebt mindestens 100.000 Schreibzyklen. Bei 2 Sekunden Intervallen und nonstop am Poti rotieren würde das - wenn ich mich nicht verrechnet habe - 2,3 Tage dauern bis das Limit erreicht ist. Ich wage es zu bezweifeln dass der / die Potis so oft bewegt werden, sollte also lange halten. Man muss ja auch nicht immer das selbe Byte im Speicher beschreiben. Gehen wir mal von 256 Bytes an Speicher aus und nur einem Poti wären das statt 2,3 Tage schon 1,6 Jahre intensive 24h/7d Dauernutzung

Muss man wissen welcher Weg einem lieber ist

Dann mußt Du aber beim Reset immer wissen, welche Adresse jetzt die aktuelle ist. Ok, da könnte man jetzt vielleicht 'ne Lösung konstruieren die davon ausgeht, daß erstmal überall 0xFF steht, und von vorn beginnend den ersten mit 0xFF überschreibt (bzw beim laden den letzten lädt, der nicht 0xFF enthält. weichen alle ab, wird die letzte Adresse geladen und der gesamte Speicher ausser der ersten Adresse mit 0xFF beschrieben (dort stattdessen der vorherige Inhalt der letzten Adresse)). 0xFF kann dann natürlich kein Nutz-Byte sein...

Andererseits sollen ja später Zustände von mehreren Potis gespeichert werden...

(wie gesagt, ich verstehe den eigentlichen Grund nicht, machbar ist das so natürlich).
Ob 'ne Diode und'n Spannungsteiler nun wirklich so'n Schaltungsaufwand darstellen, muß er selbst entscheiden, 'n Speicherelko sollte ja eh am Controller sein. Wie groß der dann dimensioniert ist....

egal...

Sag ich ja, muss jeder selber wissen und für sich entscheiden
Kennst mich ja, ich verkabel so ungerne ^^

Mit dem Speicher würde ich das so ähnlich machen wie du gesagt hast.
Wieder angenommen 1 Poti (also 1 Byte, Werte 0x00-0x7F), 256 Bytes EEPROM.
1 Byte im Ram (oder Register) reservieren für die aktuelle Speicheradresse.
Bei Power-On rückwärts durch den EEPROM lesen bis entweder Adresse = 0 oder Wert != 0xFF. Adresse speichern.
Bei neuem Wert prüfen ob Adresse = Maximum. Wenn ja: EEPROM komplett löschen, Adresse auf 0 und speichern. Sonst Adresse erhöhen und speichern. Fertig.
Würde nur 1 Byte Ram schlucken, bissl CPU beim Starten und beim Überlauf (Erase).

Klappt natürlich auch mit mehr Speicher und Potis, jetzt nur der Einfachheit halber exemplarisch erzählt.