Fixes

[LineF]

Hallo Dirk,

anbei ein paar Fixes für den DevAES Branch. Die Struktur s_l4_0x01 sollte nur ein Byte groß sein, da in AS.cpp:554 von der Funktion getRegAddr auch nur ein Byte zurückgegeben wird und dieses der Struktur direkt zugewiesen wird. Bitte nochmals überdenken!

Ansonsten bin ich jetzt dabei, meinen Sensor auf den DevAES Branch zu bringen. Ein erstes Pairing hat schon funktioniert und die Werte kommen auch schon. Jetzt muß ich nochmals die LED-Blinkerei beim Pairen fixen und dann geht's an Peering.

Ich habe in fhem einen virtuellen Sensor mit meinem RT-DN gepeert und mit Werten meines Sensors versorgt, da ich der peering-Funktion meines Sensors nicht vertraute. Aber auch das Peering von fhem zum RT-DN ist nicht 100%ig. Immer mal wieder kommen die Werte nicht durch und der RT springt dann auf seinen internen Temperatursensorwert :-(

Hast Du dir in der alten Lib nochmals das Burst-Thema angeschaut? Da werd' ich jetzt allerdings nicht mehr weiter machen - lieber meine Zeit in die neue Lib investieren.

Viele Grüße, Martin

[LineF]

Hallo Dirk,

ich weiß jetzt nicht, ob Dich meine letzten Mails erreicht haben - deshalb die Nachricht jetzt wieder hier über...

Ich hatte nochmals das Timing getestet und den Takt des Atmel per Oszi ausgemessen. Das Standard-Timing war sogar noch zu langsam (nur 98,8% der Sollfrequenz). Ich bin jetzt auf 100,2% und muß damit zum berechneten Zeitintervall 1500ms zugeben.

Dann bin ich jetzt auf den Powermode 1 gewechselt. Auch hier sind die Zeiten des Atmel massiv neben den Sollwerten:

In diesem Modus wird ja der Watchdog-Timer benutzt. Das Manual selbst spricht von einem "ungenauen" Timer. Ich habe deshalb die Meldungen mal im durch die Formel berechneten Abstand rausgeschickt und in fhem mit Sniffing mitprotokolliert - hier habe ich ja einigermaßen genaue Zeitwerte. Ergebnis war, daß der Watchdog noch viel langsamer lief. Ich habe nun die Werte, die in der ISR-Routine zu den millis hinzuaddiert werden, um 7,5% erhöht. D.h. statt 256 wird jetzt 275 hinzuaddiert. Damit habe ich jetzt auch im Power Mode 1 eine stabile Übertragung zum RT.

Insofern würde es mich schon sehr interessieren, ob das alles nur meine Probleme sind, oder ob die im "offiziellen" Wettersensor auch drin sind und hier der von mir bereits beschriebene "Burst-Bug" zuschlägt. Dann ist das Timing nämlich egal und funktioniert immer.

Den Burst-Bug habe ich übrigens in der neuen Lib auch schon erlebt. Ich vermute, daß da irgendwo noch ein Index-Fehler oder sonst was rumgeistert und für seltsame Effekte sorgt.

Viele Grüße, Martin

[trilu2000]

Hallo Martin,

das mit dem Watchdog ist mir auch schon mal aufgefallen. Ich muss mal überlegen wie man eine Calibrierungsroutine bauen könnte. Die Idee wäre

• Calibrierungsfunktion wird beim first time start angesprungen.

Watchdog wird initialisiert und gestartet und gegen den internen Timer verglichen, der Differenzwert wird im EEprom gespeichert und als Variable im Speicher abgelegt.

In der Watchdog routine wird der Differenzwert auf den Timer angewendet...

Die Abweichung des normalen Timers sollte zu vernachlässigen sein. Ein Quarz hat 1 - 2 % Abweichung, aber zeitkritische Funktionen gibt es derzeit eigentlich keine. Der RT passt sich ja kleinen Abweichungen selbstständig an...

Viele Grüße

Horst

Am 25.04.2016 um 23:19 schrieb Martin:

Hallo Dirk,

ich weiß jetzt nicht, ob Dich meine letzten Mails erreicht haben - deshalb die Nachricht jetzt wieder hier über...

Ich hatte nochmals das Timing getestet und den Takt des Atmel per Oszi ausgemessen. Das Standard-Timing war sogar noch zu langsam (nur 98,8% der Sollfrequenz). Ich bin jetzt auf 100,2% und muß damit zum berechneten Zeitintervall 1500ms zugeben.

Dann bin ich jetzt auf den Powermode 1 gewechselt. Auch hier sind die Zeiten des Atmel massiv neben den Sollwerten:

In diesem Modus wird ja der Watchdog-Timer benutzt. Das Manual selbst spricht von einem "ungenauen" Timer. Ich habe deshalb die Meldungen mal im durch die Formel berechneten Abstand rausgeschickt und in fhem mit Sniffing mitprotokolliert - hier habe ich ja einigermaßen genaue Zeitwerte. Ergebnis war, daß der Watchdog noch viel langsamer lief. Ich habe nun die Werte, die in der ISR-Routine zu den millis hinzuaddiert werden, um 7,5% erhöht. D.h. statt 256 wird jetzt 275 hinzuaddiert. Damit habe ich jetzt auch im Power Mode 1 eine stabile Übertragung zum RT.

Insofern würde es mich schon sehr interessieren, ob das alles nur meine Probleme sind, oder ob die im "offiziellen" Wettersensor auch drin sind und hier der von mir bereits beschriebene "Burst-Bug" zuschlägt. Dann ist das Timing nämlich egal und funktioniert immer.

Den Burst-Bug habe ich übrigens in der neuen Lib auch schon erlebt. Ich vermute, daß da irgendwo noch ein Index-Fehler oder sonst was rumgeistert und für seltsame Effekte sorgt.

Viele Grüße, Martin

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/trilu2000/NewAskSin/pull/16#issuecomment-214526592

[kc-GitHub]

Hi Martin, bin leider am WE nicht dazu gekommen mir deine Änderungen anzusehen. Denke ab Donnerstag ist wieder mehr Zeit. @Horst, gegen welche Quelle willst du den Watchdog kalibrieren? Auch die Timer laufen mit dem internen Osszillator. Wenn man eine genauere Zeitbasis braucht, dann muss man eben einen Quarz anschließen. Für den Watchdog solte auch ein externer Uhrenquarz reichen.

Ich meine aber auch, dass der Watchdog hier vermutlich nicht das Problem ist. Oder habe denn die "fertigen" peerbaren Sensoren einen Quarz?

[trilu2000]

Ich möchte gegen den internen Timer kalibrieren. Der interne Timer wird doch über den Takt vom Quarz gesteuert und ein externer Quarz sollte eigentlich genauer sein, als der interne Taktgenerator für den Watchdog.

Am 26.04.2016 um 10:08 schrieb Dirk:

Hi Martin, bin leider am WE nicht dazu gekommen mir deine Änderungen anzusehen. Denke ab Donnerstag ist wieder mehr Zeit. @Horst https://github.com/Horst, gegen welche Quelle willst du den Watchdog kalibrieren? Auch die Timer laufen mit dem internen Osszillator. Wenn man eine genauere Zeitbasis braucht, dann muss man eben einen Quarz anschließen. Für den Watchdog solte auch ein externer Uhrenquarz reichen.

Ich meine aber auch, dass der Watchdog hier vermutlich nicht das Problem ist. Oder habe denn die "fertigen" peerbaren Sensoren einen Quarz?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/trilu2000/NewAskSin/pull/16#issuecomment-214662388

[kc-GitHub]

Achso. Dann musst du aber auch einen externen Quarz haben. Wobei ein "einfacher" Arduino hat einen. Dann geht das. Ungenauigkeiten durch Temperaturschwankungen bekommt man so aber nicht kompensiert.

Bei einem eigenem Schaltungsentwurf könnte man für einen genaueren Watchdog einen 32kHz verwenden.

[LineF]

Hallo Horst,

1-2% sind bei 2-3 Min. Abstand eine Verschiebung von 1-3 Sek. Das hat bei mir bereits einen Unterschied zwischen Funktionieren und Nichtfunktionieren gemacht... Zeitkritisch ist das "Treffen" der Empfangsslots des RTs m.E. schon. Laut Schaltbild ist der Watchdog ein eigenständiger Oszillator und mit keinem der anderen Oszillatoren verbunden - wäre damit auch nicht quartzgenau zu betreiben...

Martin

[LineF]

Ich habe mich gestern nochmals intensiv dem Timing mit dem RT gewidmet. Nachdem der interne RC-Oszillator in meinem Sensor nun relativ gut kalibriert ist, habe ich mal ausgemessen, wie lange der RT "empfangsbereit" ist. Das sind ca. 10 Sek., in denen der RT seinen Empfänger einschaltet - und zwar ausgehend vom letzten empfangenen Telegramm. Damit habe ich aber u.U. folgendes Problem (ist bei mir so): Wenn ich exakt so lange warte, wie die Formel vorgibt, dann kann es passieren, daß aufgrund der Toleranzen der Takterzeugung im RT und im Sensor das Intervall in der Realität doch etwas kürzer ist, als der RT erwartet. Dann geht der erste Sendeversuch beim ersten Telegramm verloren und nur der erste Re-Transmit kommt beim RT an (dieser liegt dann wieder innerhalb des Empfangsfensters). Beim nächsten Telegramm kommt erst der zweite Re-Transmit an. Anschließend bin ich außer Sync und der RT muss wieder neu "suchen".

Aus diesen Beobachtungen wäre grundsätzlich die Empfehlung abzuleiten, zu der Zeit, die die Formel vorgibt, 5 Sekunden dazu zu addieren. Damit wäre man mitten im Empfangsfenster des RTs. Allerdings ist zu beachten, daß dieser dann auch länger auf sein Signal wartet (mit eingeschaltetem Empfänger), was zu einem erhöhten Batterieverbrauch führt.

Ich werde deshalb bei mir grundsätzlich 2 Sekunden zugeben.

@Horst: Laut Atmel Doku und Application Note wäre ein 32.768 KHz Quartz gar nicht dumm. Damit ließe sich der Atmega im PowerSaving Mode betreiben (ohne Watchdog - nur mit Timer 2 und zugehörigem Interrupt) und lt. AppNote könnte damit auch noch der interne RC kalibriert werden...

Martin

[LineF]

Ok, prima.

Allerdings hat Horst hier bereits ein ganz neues universelles Modul erstellt. Ist zwar universell in der Anwendung, produziert aber wahrscheinlich auch einiges an Code. Vielleicht sollte man das nur bei Bedarf reinkompilieren...

Martin

[kc-GitHub]

So, ist gemerged. Horst hatte einige Änderungen gemacht. Daher musste ich die Konflikte erst noch auflösen.

Bei mir kompiliert es erst mal. @Horst und Martin, könnt ihr das bitte einmal testen ob das so ok ist.

Übrigens musste ich pcint.cpp und pcint.h löschen, da Eclipse das sonst nicht kompilieren will. Weil ISR (PCINT[0-2]_vect) dann mehrfach deklariert ist. Ich vermute in der Arduino-IDE wird es auch diesen Fehler geben.

[LineF]

Im Atmel Studio waren die PCINTs ebenfalls mehrfach deklariert. Ich musste auch pcint.cpp/.h raus nehmen. Heute abend werde ich wahrscheinlich dann nochmals testen.

[trilu2000]

Hallo Zusammen, War zu optimistisch und wollte die pcinterrupts komplett neu lösen, hänge aber an der Komplexität. Rauslöschen ist absolut ok. Werde morgen die Änderungen zurück nehmen. Viele Grüße Horst

On 4. Mai 2016 01:12:22 MESZ, Dirk notifications@github.com wrote:

So, ist gemerged. Horst hatte einige Änderungen gemacht. Daher musste ich die Konflikte erst noch auflösen.

Bei mir kompiliert es erst mal. @Horst und Martin, könnt ihr das bitte einmal testen ob das so ok ist.

Übrigens musste ich pcint.cpp und pcint.h löschen, da Eclipse das sonst nicht kompilieren will. Weil ISR (PCINT[0-2]_vect) dann mehrfach deklariert ist. Ich vermute in der Arduino-IDE wird es auch diesen Fehler geben.

---

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/trilu2000/NewAskSin/pull/16#issuecomment-216692415

Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet.

[LineF]

So, habe eben den DevAES in meinen dev rein gemerged - compiliert und läuft. Viele Grüße, Martin