Algorithmen zur Bahnplanung

[Sternthaler]

Jetzt geht es ja wieder Schlag auf Schlag. Scheint irgendwie mit Tapeten zusammenzuhängen .
Und die Decke hat heute auch schon wieder ihr Papier bekommen.

Und natürlich ein Hallo an alle.

Ich habe zwar immer noch nicht gefunden warum der Asuro mathematisch noch fährt wenn die Motoren stehen, aber zumindest weiß ich nun, dass auch die Werte beim Drehen der Motoren nicht korrekt sind.
Es werden sporadisch fehlerhafte Messwerte eingestreut, die bei Motorstillstand zu einer angeblichen Fahrt führen. Bei drehenden Motoren fällt es nur nicht auf, da die dann berechnete Geschwindigkeit ja nicht exakt nachgemessen werden kann.
Diese fehlerhaften Daten haben immer einen ähnlichen Wert um 435. Sie sind nur leicht gestreut. (ca. 430 - 440)
Die Werte entstehen nicht durch die 50 Hertz von flackernden Lampen. Dies ist in absoluter Dunkelheit ermittelt. Außerdem ist kein 50 Hz-Rhythmus festzustellen.

Somit ist mir klar, dass ich irgendwo bei meinen Variablenhaufen und / oder beim Speicherplatz für den Stack Mist gebaut habe.
Die Programmlogik habe ich am Sonntag einen geduldigen, sachkundigen Freund (ich hoffe, dass er das nun noch immer ist) mal nachvollziehen lassen. Auch er konnte dort nach ca. 6 Stunden programmcodeanstarren nichts am Ablauf feststellen.

Wer also die Geduld hat, meinen Fehler mit zu suchen, sollte sich mit ganz hoher Wahrscheinlichkeit auf die Speichernutzung konzentrieren.

Gruß Sternthaler, der Verzweifelte.

[oberallgeier]

Hallo Du verzweifelter Sternthaler,

... Dies ist in absoluter Dunkelheit ermittelt. Außerdem ist kein 50 Hz-Rhythmus festzustellen. ...

Jetzt weiß ich endlich, warum Deine Posts so oft zu nächtlicher Stunde entstehen. Du arbeitest bei absoluter Dunkelheit! Klar - da hat man nicht sooo viel Probleme beim Ausrichten der Tapeten. Aber 50Hz-Rhythmus - - - pulst bei euch die Dunkelheit?

Na ja, erstens hab ich von Speichernutzung sowieso keine Ahnung. Aber es sieht mir doch ein bisschen nach einer elektrischen Störung aus, oder? Der simultane Einbruch bei 28o, 44o und 19u hat doch sicher etwas zu bedeuten! Und bei 25u und 50u gibts einen Durchgriff von "Totaleinbruch" auf "rot" zu einer deutlichen Verletzung der Monotonie auf "blau". Ausserdem zeigt die Monotonieverletzung auf 25u eine deutliche Erholungsphase von mindestens zwei Abfragen auf blau. Könnte das Alles nicht ein (elektrisches) Übersprechen von anderen Signalen sein? Woher käme sonst diese eindeutige Erholungsphase bei 25u-blau?

Wenn ich mir die Signale meiner Odometrie ansehe - bei (Tages-?) Licht, ohne Abdeckung, aber mit einer Beilagscheibe am Odometerrad, dann finde ich solche Störungen nicht mal andeutungsweise. Vielleicht - DAS ist die Idee - ich brenn mir mal Deinen Code auf meinen Asuro - und wenns ein Speicherfehler ist . . . dann hätten wir doch das gleiche Ergebnis ! ? ! ?

... Wer also die Geduld hat, meinen Fehler mit zu suchen, sollte sich mit ganz hoher Wahrscheinlichkeit auf die Speichernutzung konzentrieren ...

Was tut mann denn nicht alles gegen die Verzweiflung auf dieser Welt . . . .

Dann blasen wir mal zur Jagd, oder? Schick doch mal den hex rüber.

[mare_crisium]

Buon giorno, SternThaler,

nur, damit Du nicht denkst, ich würde nächtlichen Eskapaden nicht weiterverfolgen !

In Deinem Diagramm scheinen mir die Abstände zwischen den Ausreissern ganzzahlige Vielfache einer einzigen Grundperiode von etwa 6,65 Einheiten zu sein. Es könnte sich also um eine Störung handeln, die nach Art einer "Schwebung" durch das unglückliche Zusammentreffen zweier periodischer Vorgänge entsteht. Die 6,65 Einheiten entsprechen dann der Differenzfrequenz beider Vorgänge.

Bin natürlich sehr daran interessiert, dass Dein Asuro ohne zu humpeln zum Ziel findet!

Ciao,

mare_crisium

P.S.: Oberallgeier, Du alter Schwede: So ganz sauber sind Deine Kurven aber auch nicht! Guck' mal die Maxima #2 und #3 der blauen Spur an !

[Sternthaler]

Hey mare_crisium, holla Oberallgeier,

ich bin noch dran, habe aber noch kein Programm gesendet, da mir diese blöde Idee mit der Regelmässigkeit auch schon gekommen war.

Mein Ansatz geht / ging eher in die Richtung, dass ich die Störungen selber verursache, da ich, per Timer gestartet, ca. alle 2 Sekunden noch die Batterie messen lassen. (Auch die Taster können im Timer-Interrupt zu einer AD-Wandlung auf dem entsprechenden MUX-Kanal führen.)
Da aber die Messwertaufnahme aller oben angegeben ca. 50 Messwerte innerhalb von ein paar Millisekunden fertig ist, könnte dann höchstens nur eine einzige Störung über die Batteriemessung kommen.

Mittlerweile habe ich auch schon die Batteriemessung und auch die Taster weggelassen, aber nix da: Müll kommt immer noch.
Aktuell sieht es so aus, als ob der AVR einen INTERNEN Fehler hätte.
Ist ja so einfach, die Schuld auf andere zu schieben .


Los geht es zum starten der ADC-Messung im Timer-Interrupt:
- SIGNAL (SIG_OVERFLOW2)

Über die dort verwaltetet Variable "sens_i.adc_do_akt" versuche ich aber jede weitere 'Umstellerei' am einmal ausgewählten und gesetzten ADMUX-Wert zu verhindern.

Der Timer ermittelt (so mein Plan) nur dann den nächsten AD-Kanal, und würde den ADMUX ändern, wenn halt die gerade angestossene AD-Wandlung abgeschlossen ist.
Dafür ist am Ende der ADC-Interrupt-Funktion die Zuweisung:
- sens_i.adc_do_akt = ADC_DO_NICHTS;
vorhanden.

Sohnematz der 'Kleine' hatte eine gute Idee, dass ADC-Werte nur dann ausgewertet werden, wenn der geholte Wert auch zu dem erwarteten MUX-Kanal passt.
Meine 'Erwartungshaltung', welchen Kanal ich meine gestartet zu haben, halte ich ja in der Variablen "sens_i.adc_do_akt" fest.
Hierzu kann es dann nur einen MUX-Kanal geben, und wenn der halt nicht passt: Weg mit den Daten und neu versuchen.


Mittlerweile habe ich ein Test-Programm, mit dem man sowohl beim Starten (im Timer-Interrupt), als auch beim Abholen der AD-Werte (im ADC-Interrupt) Daten sammeln kann.
Es werden ca. 50 'Datensätze' gesammelt und dann zum PC gesendet.
In der Sendezeit werden alle Interrupt disabled, bzw. die Sensoren werden deaktiviert.
Nach dem Senden der 50 'Datensätze' geht das Spiel wieder weiter.
So kann ich nun kontinuierlich Daten bekommen.

Aber leider, leider sieht es so aus, dass immer noch nicht immer alles passt.
Da ich mal wieder immer noch in der Firma sitze, sende ich euch das Progrämmchen heute Nacht zu gewohnter Stunde.

Gruß Sternthaler

[oberallgeier]

Hei mare_crisium, grüß Dich Sternthaler,

... So ganz sauber sind Deine Kurven aber auch nicht! Guck' mal die Maxima #2 und #3 der blauen Spur an

Ja, Du hast recht. Aber - würdest Du einer total sauberen Kurve trauen? Ich nicht. Scherz beiseite - die Kurve stammt aus meinen ersten Erfahrungen mit dem asuro - und ich habe mit dem herzlich wenig gemacht. Vermutlich hatte ich damals noch nicht mal ne Beilagscheibe drauf. Als Ausrede für meine asuro-Abstinenz: dafür läuft mein eigenes Mini-Projekt schon die ersten Meter .

@Sternthaler: ich will Dir jetzt nix erzählen, welche festen Qualitätsschwüre ich die letzen Tage geschworen hatte und danach widerrufen musste. Soll kein Vorwurf an Dich sein - nur ich traue mir nicht über den Weg. Oder, wie ich es mal zum Entsetzen meiner Bosse (m)einem technischen Vorstand sagte: meine Fehler sind die hässlichsten, die finde ich leider erst ganz zum Schluss . . .

Trotz allem - das wird schon werden - es funktioniert bestimmt gut, wir wissen nur noch nicht, wo es verbessert werden muss.

[mare_crisium]

Buona notte, Sternthaler,

tja, das mit der Grundeinheit führt offenbar nicht zu einer schnellen Lösung des Problems . Die andere Aufälligkeit ist, dass alle Ausreisser denselben Wert haben (sieht aus wie 440, also 0x1B. Die Zahl ändert sich nicht, selbst, wenn die richtigen Messwerte sich verändern. Hab' mir schon das Bitmuster aufgeschrieben, das führte aber auch zu keiner zündenden Idee. Ist das vielleicht ein Fehlercode Deines Betriebssystems?

Wir werden's schon 'rauskriegen - spätestens, wenn Oberallgeier den Code auf seinem Asuro testet!

Ciao,

mare_crisium

[Sternthaler]

Einen schönen Guten Morgen wünsche ich euch.

Und hier wie versprochen zu meiner besten (oder doch nicht?) Arbeitszeit Code und Daten.

Die andere Aufälligkeit ist, dass alle Ausreisser denselben Wert haben (sieht aus wie 440, also 0x1B. Die Zahl ändert sich nicht, ...

Leider, leider pendeln diese Mistdinger doch. Sie gehen in den angehängten Daten von 448 bis 455 (ohne 454)
Nun könnte man meinen, dass dies der Messwert für die Batterie darstellt.
Leider scheint das aber nicht der Fall zu sein, da die Batteriemessung 2 mal 'erwischt' wurde und da 913 bzw. 914 ermittelt wurden.
--> 914 / 2 = 457 <-- Liegt verteufelt nah an den Mistdingern. Und die sind ja auch wie eine Batteriespannung recht konstant.
Aber warum durch 2 teilen? Wäre es eine 8 Bit anstatt 10 Bit Messung, muss ja durch 4 geteilt werden. (P.S.: Der AVR kann 8 oder 10 Bit)

... es funktioniert bestimmt gut, wir wissen nur noch nicht, wo es verbessert werden muss.

Nee, es funktioniert eben nicht gut. (Ich immer mit den gespaltenen Haaren.)
Das Problem hier ist ja, dass durch diese Mistdinger Tiks entstehen. Somit fährt der Asuro datentechnisch und rechnet eine Positon und einen Drehwinkel aus, der innerhalb kürzester Zeit zu ziemlich falschen Koordinaten führt. Und das obwohl der Asuro physikalisch keinen mm gefahren ist. (OK, die angehängten Daten zeigen drehende Räder. Das Problem ist aber auch bei Radstillstand vorhanden.)

Wir werden's schon 'rauskriegen - spätestens, wenn Oberallgeier den Code auf seinem Asuro testet!

Einen zweiten Asuro habe ich mir vom Nachbarn geliehen. Auch auf dem ist das gleiche Problem vorhanden. (Es liegt eben doch wohl an der Software.)
[OT] Sind nette Nachbarn. Also hockt man ab und zu bei Kaffee oder Wein zusammen; natürlich auch bei jeder Fete (@oberallgeier: Man kommt hier in der Straße wirklich zu nichts anderem). Selbstverständlich kommt man von Hölzchen über Stöckchen auch auf den Asuro.
Wer hat Spaß am Asuro bekommen? Sie natürlich. Totale Begeisterung.
Da Sie aber nicht mit Lötkolben und C umgehen kann, läßt sie mich einen Asuro zu Weihnachten für ihren Mann bestellen. Soll ja eine echte Überraschung werden.
Er hat vielleicht aus der Wäsche geschaut. Mittlerweile hat er auch schon einige Erweiterungen und fummelt nun auch heftig in C rum. [/OT]


----> Was für Daten sind in der Exceltabelle?
- T0, C0, M0, A0
Datensatz, der zum Zeitpunkt des ADC-Starts in der Timer-Interruptfunktion geschrieben wird.
Suche nach: MD_ADC_HIST_I_TIM in asuro_st.c

- T1, C1, M1, A1, V1
Datensatz, der am Anfang des ADC-Interrupts hinter die x0-Daten geschrieben wird.
Suche nach: MD_ADC_HIST_I_ADC in asuro_st.c
Erst starten, dann ADC-Wert abholen ist die Logik. Ob ADC-Werte ohne Start kommen wird festgestellt. Dann wären alle x0-Daten auf 0.

Beide MD_ADC_HIST_I_xxx-Dinger kommen aus asuro_md.h ganz am Ende.

Tx und Cx geben die Zeit in 1/36000 Sekundeneinheiten an.
Zeit[sec] = (Tx * 256 + Cx) / 36000

Mx ist der Multiplexer-Kanal aus dem Register Atmega-ADMUX
Ax ist der logische Multiplexer-Kanal aus der Variablen sens_i.adc_do_akt

In Excel berechnete Spalten sind:
P, F, T1-T0 und T0-T0
- P zeigt Probleme, bzw. die Batteriespannung.
- F würde einen Fehler markieren, wenn Mx oder Ax zwischen Start und ADC-Wert abweichen. ---> Meine Vermutung, dass der AVR eine Macke hat ist hinfällig. Meine Defines für MD_ADC_HIST_I_xxx hatten einen Fehler.
- T1-T0 zeigt die verstrichene Zeit in 1/36000[s] an zwischen Messergebnis und Start.
- T0-T0 zeigt die Zeit zwischen 2 Starts. Hier ist eine Softwareverzögerung vorhanden, damit vor allem die LED's genügend Zeit bekommen komplett an bzw. aus zu gehen. (Mit Oska geprüft, ob diese Zeit ausreicht.)


----> Wie können die Daten in Excel angezeigt werden?
Die Werte für Mx und Ax sind in Excel im Reiter 'Tabelle1' angegeben.
Oben die Ax-Werte (logischer Kanal)
Unten die Mx-Werte (echter ADMUX-Kanal)

Sinnvoll ist es, wenn man den Excel-Filter der Spalte M0 nutzt.
Hier den ADC-Kanal auswählen, und nur die dazugehörenden Daten betrachten.
Beide Radseiten können mit dem M0-Filter 'Benutzerdefiniert' mit 'Zeilen anzeigen' 'ist kleiner oder gleich' und als Wert eine 1 eintragen, angezeigt werden.


----> Hier noch ein paar Dinge, die mir in den Daten aufgefallen sind.
- Werden beide Radseiten angezeigt, dann treten die Mistdinger entweder einzeln, oder immer direkt zusammen auf.

- Die Mistdinger treten nur in der Nähe des 'Umschlagens' vom 8-Bit-Zähler aus C0 auf.
Wenn man den Filter P einstellt, dass nur 'X'-Daten angezeigt werden, liegt C0 von 252 bis 255 und von 0 bis 17.
Genau in diesem Bereich, nämlich genau beim 'Umschlagen', kann im Timer-Interrupt die Batteriemessung vorbereitet werden.
--> Ist hier doch der Zusammenhang? Warum dann aber auch vor dem 'Umschlagen'? Und warum dann nicht immer?
Ich habe getestet, dass die Batterie-Vorbereitung im Code auskommentiert ist. -> Keine Änderung bei den Daten. Weiterhin Mistdinger.


So, nun habt ihr den vollen Durchblick und könnt mir meinen Programmfehler zeigen .

Frohes Schaffen und immer gute Laune wünscht euch
Sternthaler

Hier die Exceldaten (415 kB): http://www.asuro-sternthaler.de/asur...aten-11-00.xls

P.S.: Es gibt, unter anderem auch von mir, in anderen Threads auch schon die Frage nach 'unerwartet' auftretenden Tik's.
Mir ist es beim Nikolaus aufgefallen, und ich meine, dass andere auch beim Messen per Interrupt das Problem hatten. Könnte aber auch ohne Interrupt gewesen sein.

[oberallgeier]

!) Ich bin noch am grübeln und 2) ich bin nicht annähernd firm im asuro-code. Aber . . . .

Einerseits sind 36 kHz für den ADC nicht so hoch, das Handbuch spricht von 200 kHz für 10bit-Wandlung. Andererseits wird (wohl) der Eingang bei der Odometrie gemultiplext (da muss ich nacharbeiten an der asuro-Software, um besser urteilen zu können). Nun heßt es:

Once the conversion starts, the channel and reference selection is locked to ensure a sufficient sampling time for the ADC.

• 13 - 260 μs Conversion Time

Kann es da nicht doch zu ungenügenden Wandlungszeiten kommen? ...wenn eine Wandlung gestartet wird - die vorherige sehr lange braucht, zurückgestellt und erst viel später zur Wandlung zugelassen wird als der Softwarer denkt.

Mache ich mich verständlich? Irgendwo wird doch dann ein Engpass entstehen. Aber, wie gesagt, ich muss erst mal den asuro-ADC-Code durchlesen und verdauen.

[Sternthaler]

Hallo oberallgeier,

um ein bischen beim verdauen zu helfen hier einmal die Kurzversion:

// Dabei sind (in der Reihenfolge ihres Auftretens):
- "Zeit-Variablen"
  count36kHz und timebase (Asuro-LIB-Konform)
- "Logische-Kanal-Variable"
  sens_i.adc_do_akt
    Für den Begriff 'frei' wird ADC_DO_NICHTS benutzt
- "Verzögerungs-Variable"
  sens_i.adc_delay
- "Taster-Interrupt-Variable"
  interne Variable, die im Tasten-Interrupt gesetzt wird.
- ADMUX
  Ist das im AVR enthaltene Register

   Timer-Interrupt (1/36000 Sekunden)
   {
      Erhöhe "Zeit-Variable[n]"
      WENN "Logische-Kanal-Variable" 'frei' ist
       und (weitere Bedingungen)
      DANN
         Bestimme Wert für "Logische-Kanal-Variable"
           - Berücksichtige Batterie anhand "Zeit-Variable"
           - Berücksichtige Taster anhand "Taster-Interrupt-Variable"
         Setze ADMUX auf entsprechenden pysikalischen Kanal
         Setze "Verzögerungs-Variable"
      ENDE-WENN

      WENN "Logische-Kanal-Variable" NICHT 'frei' ist
       und "Zeit-Variable" > "Verzögerungs-Variable"
      DANN
         Speicher die Daten in den x0-Werten (für IR-Übertragung)
         Starte ADC-Wandler
      ENDE-WENN
   }

   ADC-Interrupt (Nur nach einem Start aus Timer-Interupt möglich)
                 (Oder etwas doch nicht?)
   {
      Hole 16-Bit-ADC-Ergebnis
      Speicher die Daten in den x1-Werten (für IR-Übertragung)
      CASE "Logische-Kanal-Variable"
         TASTER:
            ADC-Wert intern merken
         BATTERIE:
            Bilde Mittelwert und intern merken
         LINIE (4 logische Kanäle):
            Hell-/Dunkelmessung intern merken
         RAD (2 oder 4 logische Kanäle über ADC_RAD_VERHALTEN):
            Berechne TIK und speicher in internen Variablen
      ENDE-CASE
      Setze "Logische-Kanal-Variable" zurück auf 'frei' für Timer-Interrupt
   }

Der ADC wird NICHT im Free-Running-Mode gestartet.
Somit startet eine weitere Wandlung nur dann, wenn der Timer-Interrupt dies macht.
Auch die Änderung am ADMUX wird im Timer gemacht, und kann somit frühestens nach 1/36000 Sekunden erfolgen. Nämlich erst im nächsten Timer-Interrupt.
Das von dir angesprochenes Problem, dass eine Änderung am ADMUX direkt nach einem Start erfolgt, sollte somit nie auftreten.
Genau dieses 'Unschärfe' ist mir bekannt, und deshalb kontrolliere ich den ADC und das Timing komplett selber. (Zumindest versuche ich es)

Die 36kHz und die 200kHz haben meiner Meinung nach nichts miteinander zu tun.
Der Timer ackert so vor sich hin und startet eine ADC-Wandlung im "36kHz * 'Verzögerungs-Variable'"-Raster.
Dann kommt die ADC-Wandlergeschwindigkeit mit der konfigurierten Geschwindigkeit erst ins Spiel. Es dauert halt ein bisschen, bis der ADC-Interrupt sich meldet. Vor allem, da ich den Start der Wandlung ja künstlich in Timer-Einheiten verzögere.
In dieser ADC-Wandler-Zeit will/darf ich natürlich keine Änderungen an der Variablen "Logische-Kanal-Variable" und am Register ADMUX haben. Sonst bekäme ich ja genau das von dir angesprochene Problem.
Deshalb die Belegung der "Logische-Kanal-Variable" mit 'frei' bzw. bei dem Wunsch eine Wandlung zu starten mit dem im Timer bestimmten Wert für den logischen Kanal. Aber eben nur dann, wenn der ADC 'frei' ist.
Und erst nach der ADC-Wandlung im ADC-Interrupt wieder die 'frei'gabe.


Ich hoffe, dass dies etwas Überblick gebracht hat,
Trink nen leckeren Roten dazu. Am besten ein Glas für mich mit.

Gruß Sternthaler

[mare_crisium]

Also SternThaler,

das Brüten über der Datentabelle hat mir keine zündende Idee über die Ursache des Fehlers eingebracht . Daraufhin habe ich noch einmal das Datenblatt des ATmega8 vorgenommen und das Kapitel ADC (S. 192 - 20 nach Art einer FMEA durchgeforstet. Hier ist das Resultat:

Mögliche Fehlerquellen am ATmega ADC:

1. Frequenz der ADC-Wandlung tiefer als Auslesefrequenz:
Dauer Sample-and-hold: 1,5 - 13,5 ADC-Takte, normalerweise 1,5 Takte (Abs. 2, Seite 199)
Dauer ADC-Wandlung: 13 - 25 ADC-Takte, normalerweise 13 Takte (Abs. 2, Seite 199)
Dauer Vref-Umschaltung: nicht spezifiziert
Dauer Kanal-Umschaltung: abhängig vom Ende der laufenden ADC-Wandlung (Abs. 3, S. 200).

In Deinem Fall (ADC-Betriebsart nicht freilaufend, Kanal-Umschaltung unmittelbar vor Löschen des INT-Flags, Vref-Quelle unverändert) sind das 14,5 Takte (Tabelle 73, S. 200); bei einem ADC-Takt von 36kHz also 0,4 ms. Leider habe ich keine Formel zum Berechnen des ADC-Taktes aus MC-Takt und ADC-Vorteiler gefunden.
Möglicher Fehler: Die Wandlung wird durch das Timerinterrupt-Dienstprogramm gestartet (ADSC=high). Anschliessend wird versucht, ebenfalls vom Timer gesteuert, das Ergebnis vor Ende der Wandlung (ADSC=low bzw. ADIF=high in ASCSRA Abs.2, S. 206) auszulesen. Das liefert nicht den gewünschten Messwert sondern die vorherige Messung wird noch einmal gelesen.
Anderer möglicher Fehler: Die Wandlungszeit wird unerwartet lang, weil bei jedem Start der Wandlung das ADEN-Flag in ADCSRA gesetzt wird. In diesem Fall gilt die verlängerte Sample-and-Hold und Wandlungszeit von 38,5 ADC-Takten (Abs. 1, S199). Ergebnis ist wieder ein wiederholtes Auslesen des alten Messwertes.

2. Störfreies Auslesen nur, wenn zuvor vorheriges Ergebnis vollständig ausgelesen wurde: Bei 10-Bit-Wandlung immer erst ADCL, dann ADCH auslesen (Abs 2, S.19. Wenn die nächste Wandlung endet, bevor ADCH gelesen wurde, dann geht das neue Ergebnis verloren und stattdessen wird das alte erneut ausgegeben.
Möglicher Fehler: Es wird zu früh ausgelesen und statt des gewünschten das Ergebnis der vorhergehenden Wandlung nochmals gelesen.

3. ADMUX schaltet nie vor letztem Takt der laufenden ADC-Wandlung um: Während laufender Wandlung bleiben Änderungen von ADMUX unwirksam. Tatsächlich umgeschaltet wird erst beim letzten Takt der Wandlung (Abs. 1, S. 200).
Möglicher Fehler: Der Kanal wird zu spät, d.h. während der laufenden Wandlung in das Register ADMUX geschrieben. Weil die Umschaltung erst bei Ende der laufenden Wandlung wirksam wird, wird nochmals das Ergebnis der vorherigen Wandlung (alter Messwert aus altem Kanal) ausgelesen. Empfohlen wird Kanalumschaltung nach Auslesen des jüngsten Ergebnisses, unmittelbar vor Starten der nächsten Wandlung.

4. Mess-Spannung höher als Vref : Wenn die Messspannung ausserhalb des zulässigen Bereichs liegt, werden ADC-Werte "in der Nähe von" 0x03FF ausgegeben (Abs. 4, S. 201).
Möglicher Fehler: Es gibt Spitzen in der Ausgangsspannung des Fototransistors oder kurze Einbrüche in der Versorgungsspannung des MC (mit Einfluss auf die interne Referenzspannung).

5. Versehentliche Anwahl von ADMUX-Kanal 0b1110=0x0E: Mit diesem Kanal wird die interne Spannung von 1,23V umgewandelt (Tabelle 75, S. 206).
Möglicher Fehler: Der Kanal 0x0E wird versehentlich angewählt und die interne Referenzspannung ausgewertet.

Noch ein Test-Vorschlag: Versuchsweise mit 8-Bit Wandler arbeiten (ADLAR=1, nur ADCH auslesen). Das sollte schneller gehen und die Zeitkonstante, mit der die Ausreisser erscheinen müsste sich verändern (Wenn die Ursache in einer "unglücklichen" Koinziendenz liegt).

Irgendwie werdern wir's doch noch 'rauskriegen !

Ciao,

mare_crisium