Temperaturproblem mit serieller Schnittstelle

[Stephan (Gast)]

Hallo zusammen!

Ich habe ein Temperatur - Messsystem mit einem Atmega8 (Interner
Oszillator 8MHz) aufgebaut.
Auf dem Board befinden sich 3 NTCs die über den adc ausgewertet werden.
Diese Werte werden daraufhin über die serielle Schnittstelle an den PC
geschickt. Alle Bauteile die ich verwende sind für einen
Temperaturbereich bis 85°C spezifiziert. Allerdings habe ich das
Problem, dass ab ca 50°C die Ausgabe meines Protokols falsch wird. Es
werden immer Zeichen verändert. (Gerade bei den ausgegebenen Textteilen
auffällig)
Zum schreiben auf die RS232 benutze ich die in Codevision enthaltene
printf Funktion! Die Baudrate liegt bei 9600 also eigentlich nicht
besonders schnell.

Gruß
Stephan

[Peter Dannegger (Gast)]

Laß mich raten, Du benutzt den internen RC-Oszillator.

Nimm nen Quarz und die Probleme sind weg.


Peter

[Markus_8051 (Gast)]

@Peter: das brauchst Du nóch nicht einmal zu raten, Stephan hat es ja
geschrieben. :-)

Aber stimmt schon, wenn man den Takt für die RS232 aus 8MHz ableitet,
trifft man die 9600 baud nicht exakt. Wenn sich dann der Takt durch
Temperaturschwankungen noch etwas verschiebt, kann man schnell den
Toleranzbereich verlassen, so daß es zu Übertragungsfehlern kommen
kann.

Gruß,

Markus_8051

[dicky (Gast)]

bei einem msp430 konnte (und kann es weiterhin) ich mit dem internen
oszillator eine stabile 57 kbit verbindung halten, 115 kbit waren
allerdings etwas kritisch bei starken temperaturänderungen. in einer
kleinen klimakammer hier kann ich alle temperaturen zwischen knapp über
0 und 60 grad durchlaufen lassen und daten mitprotokollieren. ein test
(einmal rauf + einmal runter) dauert dabei etwa 2 stunden. der
temperatureinfluss auf die baudrate ist deutlich zu sehen. mit einem
vorhandenen 32 khz (stromsparende gesamtschaltung verbrauch 11 µA) habe
ich da aber eine genaue referenz und kann die oszillatorfrequenz
einigermassen genau mit dem timer messen. dies geschieht automatisch
jede minute. da der msp auch die chiptemperatur auslesbar anbietet
kompensiere ich den drift einfach. die messergebnisse eines einzelnen
msp übernehme ich dabei für die nachbauten. bis jetzt läuft das bei
allen nachbauten völlig problemlos, ob bei zimmertemperatur oder
draussen. um den exakten teilerfaktor zur baudrategenerierung zu finden
bin ich experimentell vorgegeangen und habe die fehlerhäufigkeit bei
verschiedenen teilerfaktoren (bei 57 kbit) auf 2 PC gemessen. es ergibt
sich da eine art umgekhrte gauss-verteilung. habe den wert im "tal"
der kurve genommen. die ergebnisse der 2 pc waren fast genau gleich. so
ein vorgehen ist leider ziemlich zeitaufwendig. spart aber die 50 ct für
einen hf quarz und kann den stromverbrauch drastisch senken, denn nur
für die datenübertragungszeiten wird kurz der prozessortakt voll
hochgefahren um beste genauigkeit zu erreichen. wenn die üblichen
baudraten doch bloss vielfache von 32,768 wären... seuffzzz...

[Peter Dannegger (Gast)]

@dicky

wenn Du den RC-Generator mit einem 32kHz Quarz nachregelst, hast du
doch wieder eine quarzstabilen Wert, ist quasi eine PLL in Software.

Geht beim ATMega8 aber auch.


Wo nun aber das Problem mit den 32kHz sein soll, verstehe ich nicht.
Du must doch nur die Zählwerte der Timer entsprechend wählen, damit der
RC-Generator eine baudfreundliche Frequenz hat (z.B. 32kHz * 225 ergibt
baudfreundliche 7,3728MHz).


Peter

[crazy horse (Gast)]

das musst du mir noch mal vorrechnen, was du glaubst damit gespart zu
haben. Ein Quarz kostet in Stückzahlen >500 gerade mal 25 Cent, ein
Keramikresonator ca. 8 Cent. Wieviele 10.000 Stk willst du denn
verkaufen, um deine tage(wochen?)lange Entwicklungs- und Testarbeit
wieder hereinzuholen?