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)...
Andreas schrieb: > Was könnte ich hier noch versuchen? Soft-UART mit autom. Taktratenerkennung, Kurzzeitstabilität vorausgesetzt
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.
Ich habe ja den 2 Mhz Keramik-Resonator. Oder ist der nicht stabil genug?
Ich weiß, dass die Rondostate die Soll-Baudrate nicht einhalten (per Oszilloskop und Logic Analyzer gemessen).
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...
Da Dein Datenvolumen recht klein ist: Mach mal langsam. Manchmal hilft es etwas kürzer zu treten bzw. mit 2400 Baud.
@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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.