Instabiler IR-Empfang (Programmabhängig)

Wenn es mit dem einen Programm funktioniert und nur bei  Deinem die 
Sparlampen stören, wird in Deinem Programm wohl die Fehlererkennung od. 
irgend eine Plausibilitätsprüfung noch nicht ganz optimal sein?

Bau doch erst mal ein paar Prüfpunkte ein oder sammle Roh-Daten was der 
Empfänger an Müll einsammelt.

So viel Müll ist das gar nicht.
Ich hätte erwähnen sollen, dass ich das Oszi schon mal dran hängen 
hatte.

Wie sich aber gerade herausstellt habe ich an einer völlig falschen Ecke 
gesucht.

In der timer.h gibt es ein OSCCAL-Parameter (Oscilator Calibration).
Das habe ich mal Schrittweise verringert und siehe da, auf einmal wird 
das alles so, wie es sein soll.

Ursprünglich stand der OSCCAL auf 158 (laut Kommentar war 157 beim 
Entwickler bereits zu langsam).
Ich hab ihn im Moment auf 154 stehen, damit läuft das schon sehr gut.

Kann mir bitte jemand relativ leicht verständlich erklären, wofür der 
OSCCAL-Parameter in der timer.h ist, was man genau mit ihm einstellt und 
ob es da einen Richt-/Sollwert gibt, nach dem man ihn einstellen sollte 
oder ob man damit einfach 'herumspielt' bis alles klappt?

Wenn ich das richtig deute, kalibriert man mit diesem Parameter den 
Internen Oszillator vom Atmega.
Was sagt die Zahl im Parameter aus? 154mS? Hz? Eier, Kartoffeln?
Und welche genaue Auswirkung hat das Verändern des Parameters auf das 
ganze Programm?
(Was würde passieren, wenn ich einen Wert von "1" und was, wenn ich 
"1000" einstelle oder den OSCCAL komplett weg lasse?)
Die einzige Auswirkung, die ich momentan subjektiv merke ist, dass die 
IR-Verarbeitung auf einmal deutlich stabiler funktioniert.

Mir scheint es so, als wäre der Parameter ein 'Feinabgleich' für den 
µC-Oszillator.
Wenn dem so wär, müsste man das doch bei jedem neuen µC aufs neue 
'feinabgleichen'

Ich stehe da gerade ein wenig auf dem Schlauch und finde nichts für mich 
verständliches.

Gruß, Markus

FoFi schrieb:
> Mir scheint es so, als wäre der Parameter ein 'Feinabgleich' für den
> µC-Oszillator.

Ja, ist so!

> Wenn dem so wär, müsste man das doch bei jedem neuen µC aufs neue
> 'feinabgleichen'

Richtig. Hab nicht in die HW geschaut - externer 
Quarz/Oszillator/Resonator ist eine Alternative.

Nun okay, das macht's für mich schon mal deutlich verständlicher.
Kannst du mir auch noch verraten, was das nun für eine Einheit ist, die 
man beim OSCCAL angibt? Angenommen es wären Hz - 154Hz daneben wär ja 
schon ne Menge.

Gibt's ne einfache Möglichkeit rauszufinden, auf welcher Frequenz genau 
der interne OSC schwingt um sich das 'rumspielen' mit dem OSCCAL zu 
ersparen und direkt den 'richtigen' Korrekturfaktur einzugeben?

Vllt sollte ich es auch anders formulieren:
Wie finde ich raus, welcher der 'optimale' OSCCAL-Wert für 'meinen' 
Atmega48 is?

FoFi schrieb:
> Kannst du mir auch noch verraten, was das nun für eine Einheit ist, die
> man beim OSCCAL angibt? Angenommen es wären Hz - 154Hz daneben wär ja

Das steht im Datenplat des Prozessors. Nein, Hz sind es nicht.

fonsana

@FoFi: zum Kalibrieren gibt es eine Application Note von Atmel:
http://www.atmel.com/Images/doc2555.pdf

Oder kürzer: CLKO Pin per Fuse aktivieren, Frequenzzähler/Oszi dran und 
OSCCAL Werte mit kleinem Testprogramm durchprobieren. Datenblatt des 
Mega48 benutzen. Da stehen Hinweise dafür drin.

Himmel ist das ein Aufwand.
Ein weiterer Grund in Zukunft auf externe Quarze zu setzen.

Danke für die Infos!

Um das Thema abzuschließen möchte ich noch folgendes mitteilen:

Ich habe bezüglich diesem Thema noch eine Menge gegooglet und 
'gespielt'.
Aus den Google-Ergebnissen wurde ich persönlich nicht sonderlich schlau, 
das überschreitet alles noch meinen aktuellen Kenntnisstand, aber was 
ich rausgefunden habe war, dass das Programm und der IR-Empfang immer 
stabiler und 'besser' wurde, je tiefer ich den OSCCAL-Wert in de 
rtimer.h angesetzt habe.
Irgendwo bei ca 135 lief das ganze dann so, dass ich es als 'perfekt' 
empfunden habe.

Irgendwann habe ich dann einfach mal die komplette OSCCAL rausgenommen 
und siehe da, so einfach kann es laufen - voila!

Zufällig bin ich dann über den 'Advanced'-Reiter im AVR-Studio -> 
AVR-ISP-Mode gestolpert und habe einfach mal auf 'read' geklickt. (Siehe 
Anhang)
Dort spuckt mir mein Atmega48 den Wert "0x8A" aus, der Dezimal "138" 
ist, was auch mit meiner 'Versuchsreihe' überein stimmt, in der ich auf 
~135 kam.

Wenn ich also richtig verstehe steht die Standard-Kalibrierung MEINES 
Atmega48s auf 138 - der Atmega48 des Programmentwicklers stand wohl auf 
167 (dem Kommentar nach zu urteilen).
Beim Entwickler lief die 167 zu schnell, weshalb er auf 158 
'feinjustierte'/drosselte.
Bei mir ist 158 immer noch deutlich zu hoch, weil der Standard bei 138 
liegt (womit auch alles exzellent läuft).

Was mir jetzt noch unbegreiflich ist: Scheinbar haben verschiedene µCs 
des gleichen Modells unterschiedliche 'Grundkalibrierungen' für den 
internen OSC.
Wenn dem so ist, ist die Funktion doch reines Glücksspiel, wenn jemand 
ein Programm für einen Atmega XYZ entwickelt und den Code (oder sogar 
nur die *.hex) öffentlich zur Verfügung Stellt.
Wenn jemand das Projekt 'nachbaut' und den µC einfach nur flasht ohne am 
OSCCAL zu drehen (sofern ein OSCCAL gesetzt wurde), ist die 
Wahrscheinlichkeit, dass die Kalibrierung mit der des Entwickler-µCs 
übereinstimmt, ja äußerst gering.

Kurzum ist es bei 'öffentlichen' Projekten, in denen eine Feinjustierung 
des internen Oszillators vorgenommen wird äußerst ratsam den kompletten 
C-Code zu veröffentlichen und nicht nur die fertige *.hex.
Oder sogar die OSCCAL komplett weg zu lassen und mit der +/-10% 
Ungenauigkeit des internen OSC zu leben.
Verstehe ich das richtig oder habe ich mich gedanklich irgendwo vertan?

Vielen Dank für die Erläuterung :-)