Hallo,
ich habe 9 Rondostate (= el. Heizkörper-Thermostate). An deren serieller
Schnittstelle hängt jeweils ein Atmega8, der mit den Rondostaten
sprechen soll (9600 Baud).
Das funktioniert leidern nicht zuverlässig, da die Rondostate den
internen Oszillator des eingebauten AVRs nutzen. Manche senden zu
langsam, andere zu schnell und es gibt wohl auch Drift.
Bisher habe ich probiert:
- Atmega8 mit 2 Mhz Keramik-Resonator, Übertragung des Rondostats
messen, Baudrate errechnen, Uart einstellen. Das Ergebnis stimmte,
Kommunikation klappte nur in eine Richtung.
- Atmega8 mit 2 Mhz Keramik-Resonator, beim Start wird in einer Schleife
eine Anfrage an den Rondostat geschickt. Wenn keine Antwort kommt, wird
das Baudratenregister um 1 erhöht und erneut probiert.
Fazit: Geht irgendwie, aber ist anscheinend nicht fein genug.
- Atmega8 mit internem 2 Mhz Takt, Baudrate auf 9600 und dann per
OSCCAL-Register den internen Oszillator nachjustiert, bis die
Kommunikation klappte.
Fazit: Geht besser, aber irgendwann gibt es Aussetzer oder der Rondostat
reagiert nicht. Ich vermute, die Rondostate driften weg (Temperatur oder
Batteriespannung).
Was könnte ich hier noch versuchen? (Änderungen am Rondostat scheiden
aus)
Gruß,
Andreas
Andreas schrieb:> - Atmega8 mit internem 2 Mhz Takt, Baudrate auf 9600 und dann per> OSCCAL-Register den internen Oszillator nachjustiert, bis die> Kommunikation klappte.> Fazit: Geht besser, aber irgendwann gibt es Aussetzer oder der Rondostat> reagiert nicht. Ich vermute, die Rondostate driften weg (Temperatur oder> Batteriespannung).
Wenn das funktioniert, dann führ da die idee doch einfahc weiter. Wenn
Fehler auftauchen wird einfach neu justiert (oder vlt. kann man auch
schon vorher den drift festellen und nachführen, mit nem input-capture
oder so)...
Ja, das wäre auch mein nächster Ansatz gewesen.
Ich bin aber mit der Gesamtsituation unzufrieden: Entweder kann ich mit
einer Taktrate empfangen, oder senden. Ich finde keine, mit der beides
geht. So timing-krisitsch kann das doch nicht sein?...
Andreas schrieb:> Bisher habe ich probiert:
[...]
Und das naheliegendste, einen "Baudratenquarz" zu verwenden, hast du
nicht probiert? Warum um alles in der Welt?!
Die Dinger kosten nur wenige Cent mehr als ein Keramikresonator und sind
mindestens genauso leicht verfügbar wie diese. Und du weißt dann, daß du
die Soll-Baudrate mit ca. 50ppm Genauigkeit einhältst,
kommunikationsprobleme also entweder an deinem defekten Programm oder
der Gegenstelle liegen müssen.
Zumindest für ein Exemplar eines solchen Quarzes sollte dein Einkommen
doch wohl reichen?
Andreas schrieb:> Was könnte ich hier noch versuchen?
Na erstmal die eigenen uPs Quarzstabil machen.
Dann werden Vermutungen zu Messungen. ;-)
Wenn das Protokoll bekannt ist kann man die Baudrate der Rhondos messen
und eine Soft Uart entsprechend einstellen.
2MHz ist natürlich kompletter Mist. Schau doch mal, in welchen
Abstufungen (UBRR ändern) du die Baudrate ändern kannst....
Versuch es mal mit 16MHZ und U2X=1.
Baud=2.000.000/(UBRR+1)
Jetzt kannst du im Bereich um 9600Baud in Schritten von ca. ~50 Baud
einstellen und solltest immer was passendes finden.
Danke für den Tipp, das leuchtet ein. Ich habe die 2 Mhz genommen, weil
das ganze batteriebetrieben läuft. Aber der Atmega8 wacht eh nur alle 4
Minuten kurz aus Powerdown auf.
Andreas schrieb:> Ich weiß, dass die Rondostate die Soll-Baudrate nicht einhalten> (per> Oszilloskop und Logic Analyzer gemessen).
Dann ist das wohl ein Produktmangel. Gib sie zurück.
Es sei denn, die serielle Kommunikation ist als Produkteigenschaft
garnicht spezifiziert. Dann hast du ein Problem. Jedenfalls wenn die
einzige Möglichkeit zur Kommunikation ist, daß du sie von außen anregst.
Denn dann hast du keine Möglichkeit, vorab die Baudrate zu messen, die
der Peer gegenwärtig für richtig hält (und die höchstwahrscheinlich
stark von der Temperatur des Rondostaten abhängig ist).
Dagegen hilft dann nur noch die große Keule: Wissenschaftliche Arbeit
mit all ihren Längen.
Sprich: man fängt in einer Situation an, in der eine Kommunikation
möglich ist. Vermißt die Baudrate und variiert dann die als Störung
vermutete Umweltbedingung, hält dabei die Kommunikation am laufen und
vermisst kontinuierlich weiterhin die Baudrate (und paßt die eigene
natürlich auch laufend an). Letztlich ergibt sich ein schickes Diagramm,
welches die Abhängigkeit aufzeigt. Jedenfalls, sofern die Vermutung
bezüglich der Störquelle korrekt war. Wenn nicht: auch ein negatives
Ergebnis ist im wissenschaftlichen Sinne ein Erkenntnisgewinn. Man weiß:
das war's nicht und generiert eine neue Vermutung, um sie dann auf
dieselbe Weise entweder zu bestätigen oder zu widerlegen.
Dann benutzt man einen Sensor, um die Störung zu messen, die man als
tatsächlich relevant erkannt hat, die aufgezeichnete Abhängigkeit, um
aus dem Sensorwert den Korrekturwert für die Baudrate zu gewinnen und
dann geht's wie von Zauberhand...
@c-hater: Die Schnittstelle ist keine ofizielle Produkteigenschaft. Das
sind billige Thermostate aus dem Baumarkt, die zufälligerweise alle paar
Minuten einige Daten ausgeben, die ich gut gebrauchen kann. Hat wohl der
Hersteller zum Debuggen genutzt...
@Amateur: Die Baudrate der Rondostate ist nicht einstellbar.
Werde weiter probieren.
Danke!
Andreas schrieb:> die zufälligerweise alle paar> Minuten einige Daten ausgeben, die ich gut gebrauchen kann
Da gibt es durchaus die Möglichkeit, die Daten mit hoher Auflösung zu
empfangen und zu analysieren, besonders wenn du weisst was gesendet
wird. Es ist ja nicht unwahrscheinlich, dass alle Sendungen gleich
anfangen, dann kann man das erste Zeichen benutzen um die aktuelle
Baudrate zu bestimmen.
Modems z.B. machen das mit dem A, weil alle Befehle mit AT anfangen.
In jedem Fall ist ein 2MHz Quarz eine sehr schlechte Wahl für 9600 Baud.
Gruss Reinhard
Ok. Ein höherer Takt ermöglicht feinere Einstellung der Baudrate per
Baudratenregister. Aber erlaubt das eine feinere Einstellung, als wenn
ich bei 2 Mhz OSCCAL verstelle?
Der Rondostat driftet, also bringt mir ein stabiler Takt an meinem
Atmega eigentlich nichts. Damit bleibt nur, immer mal wieder neu
abzugleichen.
Andreas schrieb:> Damit bleibt nur, immer mal wieder neu> abzugleichen.
Sag ich doch: bei jeder Meldung. Die Baudrate driftet ganz bestimmt
nicht innerhalb 0,1 Sekunden weg.
Gruss Reinhard
Andreas schrieb:> Der Rondostat driftet, also bringt mir ein stabiler Takt an meinem> Atmega eigentlich nichts.
So ist es.
> Damit bleibt nur, immer mal wieder neu> abzugleichen.
Nein, es gibt noch eine ganz andere Möglichkeit als ständig die Baudrate
einer UART nachzuführen (um dann im entscheidenden Moment vielleicht
doch daneben zu liegen).
Es handelt sich ja vermutlich um eine sehr kurze Nachricht, nur einige
Bytes maximal.
Da kann man auch einfach die zeitlichen Abstände sämtlicher
Signalflanken mit einer sehr viel höheren Zeitauflösung erfassen (dafür
bietet sich die Input-Capture Funktion von Timer1 an) und das Signal
dann in nachher mit Software analysieren.
Das ist umso einfacher, als daß du ja zumindest die ungefähre Baudrate
und die Zahl der erwarteten Bytes bereits vorab kennst, das vereinfacht
die Analyse so sehr, daß es keine große Herausforderung mehr ist, sie zu
programmieren.
Andreas schrieb:> Damit bleibt nur, immer mal wieder neu abzugleichen.
Wenn du weißt, wie die gesendeten Daten aussehen, mußt du ihn für die
Datenübertragung irgendwie zum Plappern bringen (oder tut er das von
selbst), kannst dann seine Baudrate ausmessen und unter Nutzung der doch
wohl vorhandenen Kurzzeitstabilität mit ihm kommunizieren.
Ist die Takterzeugung im Rondostat nicht mit einem Quarz stabilisiert?
Oder wird der Quarz, der da eindeutig vorhanden ist, nur für die
Stabilisierung der Software-Uhr verwendet?
Egal ob Quarz stabilisiert oder sonstwie, mit Kältespray/Kühlschrank
könntest Du evtl. den Ausreißer lokalisieren und dann tauschen oder
Deine Schaltung anpassen. Aber Vorsicht mit Kondenswasser.
ich will eigentlich nicht die Rondostaten manipulieren. Der eingebaute
Quarz ist nur für die Uhr...
Ich lasse das Projekt vorerst ruhen, habe meinen ISP-Programmer
verschlampt und muss auf einen neuen warten :(
Andreas schrieb:> Aber erlaubt das eine feinere Einstellung, als wenn> ich bei 2 Mhz OSCCAL verstelle?
2e6 / 8 / 9600 = 26
D.h. Du kannst in 4% Schritten variieren, das ist viel zu grob.
Du solltest mindestens 1% Schritte ermöglichen.
