AskSin++ HM-ES-TX-WM Messfehler

Begonnen von ext23, 17 Januar 2018, 20:52:18

Vorheriges Thema - Nächstes Thema

ext23

Ich habe ein panStamp AVR1 mit dem AskSin++ HM-ES-TX-WM geflashed.

Arduino IDE 1.8.5
AskSin++ Master Branch vom 16.01.2018

Ich habe es als S0 Zähler verdrahtet und als Typ LED eingestellt.

Er zählt sauber die Impulse. Ich nutze außerdem den ElectricityCalculator.

Jetzt ist mir aufgefallen, dass der ElectricityCalculator, der HM-ES-TX-WM und das Display am Zähler unterschiedliche Werte für die aktuelle Leistung anzeigen.

Ich dachte der HM-ES-TX-WM sendet (und misst) alle (über) 3 Minuten so wie es auch eingestellt ist im Modul aber das ist leider nicht so.

Daraus ergeben sich 2 Probleme:
1. Der HM-ES-TX-WM berechnet die Leistung falsch, der bezieht die Berechnung nämlich immer! auf 3 Minuten (180sec).
2. Der ElectricityCalculator macht es im Prinzip richtig, hat aber eventuell eine gewissen Abweichung zwischen den Readings Zeiten und dem was der HM-ES-TX-WM als Meßzeitraum hat. Einfach gesagt falls das HM Funk Paket nicht ankommt muss es wiederholt werden, dazwischen liegt eine Zeit X in der der HM-ES-TX-WM aber nicht weiter die Impulse zählt und die Funk Payload anpasst.

Das Problem 2 kann man schwer umschiffen, da muss man wohl mit leben. Aber Punkt 1 ist ein Bug. Da stellt sich mir nur die Frage:
A. Warum schwanken die Meßzeiträume so stark, Beispiel (MM:SS): 9:23, 3:15, 12:06, 14:24, 16:17, 40:05, 38:36, 31:04, 3:29, 3:31 .... Ich habe so das Gefühl, der Abstand steigt mit zunehmender Leistung. Wo der Abstand 30 min und mehr war, lief die Waschmaschine etc. (Stimmt auch mit der seriellen Debug Ausgabe überein, also es sind keine Funk Paketverluste...)
B. Warum berechnet er den eigenen ermittelten Leistungswert der ja eigentlich ziemlich genau sein sollte falsch.

@papa: Du weiß ja, dass ich das HM-ES-TX-WM Beispiel auch für meine Wasseruhr nehme wo ich im 2 Kanal betrieb Probleme habe. Hängt das irgendwie zusammen?

Ich bin leider kein Prog Spezi. Ich programmiere gerne AVRs aber dann in ANSI C, ohne Objektorientierung, ich schaue also in den HM-ES-TX-WM Code wie ein Schwein ins Uhrwerk.:

Vielleicht kann mir ja hier jemand helfen.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

papa

Das Problem mit dem Timing kommt durch die vielen Interrupts, die durch den Zähler ausgelöst werden. Das funktioniert mit den Deep-Sleep-Mode per Watchdog überhaupt nicht. Hier für gibt es 3 Lösungen.

Die beste Lösung wäre die Verwendung eines Echtzeituhr, welche den Interrupt für die zu messende Zeitspanne bereitstellt. Hierzu könnte man den CPU-Takt auf den internen Quarz per Fuses umstellen und den externen Quarz mit einem 32,768kHz Quarz bestücken. Die Lib hat dann dafür einen RTC-Klasse, welche die dann den Timer zur Verfügung stellt. Da Du mit nem Panstamp arbeitest, ist das wahrscheinlich nicht so einfach.

Mit einer externen RTC mit DS2331 sollte sich auch ein Interrupt nach einer bestimmten Zeit auslösen lassen.

Alternativ kannst Du auch auf den Deep-Sleep verzichten. Dann sollte das Ganze aber mit einem Netzteil versorgt werden. Hierzu muss nur die folgende Zeile (462)
hal.activity.savePower<Sleep<> >(hal);
durch
hal.activity.savePower<Idle<> >(hal);
ersetzt werden.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

ext23

Netzteil habe ich dran, ich dachte das muss eh am Netz hängen in dem Modus, oder war das nur für IEC? Egal, ich habs am Netz das ist kein Thema.

Die Sache ist ja die, die Zeitspanne ist im Prinzip egal, die muss nicht immer genau 3 Minuten sein. Es muss eben nur richtig berechnet werden. Sprich wenn es 3,5 Minuten sind, dann muss man eben den Energy Wert auch auf 210 Sekunden berechnen. Dann hat man das Problem des falschen Energy Werten schon mal gelöst. Natürlich sollte es nicht zwischen 3 Minuten und 45 Minuten schwanken, das ist etwas fett.

Der EnergyCalculator berechnet die Leistung auf Grundlage der Abstände des Readings. Also Reading_time_neu - Reading_time_alt. Sprich der rechnet richtig egal wie lange der Zeitrahmen ist. Es muss nur sichergestellt werden, dass die Zeit des Messintervalls identisch ist mit dem Abstand der gesendeten Readings. Das ist natürlich in der praxis schwer weil allein durch den Funk ein paar Millisekunden Versatz sind, bei Funk Störungen natürlich etwas mehr. Wenn die Differenz im Rahmen von 1-2 Sekunden liegt sind die Werte noch OK, also eine Abweichung von ca. +/- 5W. Bei längerem Messintervall wird der natürlich kleiner.

Ich ändere den Deep Sleep mode mal.

Wegen dem Quarz, ich kann auch ein AVR nehmen und ein CC1101 rann hängen, das ist im Prinzip kein Thema, ich überlege nur ob das Sinn macht. Die internen Counter des AVR sollen dafür völlig ausreichend sein. (Gut ich weiß nicht ob deine AskSin Lib schon 95% der Ressourcen braucht ;-) )

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

Ich habe jetzt nur die eine Zeile geändert. Dann sendet der zwar relativ Regelmässig alle 180 Sekunden, aber der Counter wird nicht gezählt. Die LED blinkt auch nicht bei einem Impuls.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

papa

BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

ext23

Sieht viel besser aus! Laut FHEM kommt jetzt alles 181 Sekunden was. Die eine Sekunde führt natürlich zu einer geringen Abweichung aber das lässt sich nicht vermeiden. Wenn der Controller an sich wirklich exakt 180 Sekunden misst dann stimmen die Werte die der Controller mit schickt und dann nehm ich den. Eventuell weite ich das Zeitfenster auf 5 Minuten auf, dann wird es noch etwas genauer.

Sollte ich das Wasseruhr Projekt mit dem Dual Zähler auch mal anpassen mit dem was du jetzt geändert hast?

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

papa

Zitat von: ext23 am 18 Januar 2018, 14:41:20
Sollte ich das Wasseruhr Projekt mit dem Dual Zähler auch mal anpassen mit dem was du jetzt geändert hast?

Ja
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

ext23

Moin,

habe ich gemacht, aber leider null Unterschied zum Verhalten. Sobald ich den config Button drücke geht nichts mehr.

UPDATE: misst das gehört eigentlich in das Wasseruhr Thema...

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

oli82

Zitat von: papa am 18 Januar 2018, 08:57:23
Das Problem mit dem Timing kommt durch die vielen Interrupts, die durch den Zähler ausgelöst werden. Das funktioniert mit den Deep-Sleep-Mode per Watchdog überhaupt nicht. Hier für gibt es 3 Lösungen.

Die beste Lösung wäre die Verwendung eines Echtzeituhr, welche den Interrupt für die zu messende Zeitspanne bereitstellt. Hierzu könnte man den CPU-Takt auf den internen Quarz per Fuses umstellen und den externen Quarz mit einem 32,768kHz Quarz bestücken.

Heisst das, dass ich das Beispiel in deinem branch V2 in Verbindung mit der HM Sensor Platine einfach nutzen kann oder müssen dort noch Änderungen zwecks Echtzeituhr gemacht werden?

papa

Zitat von: oli82 am 06 Februar 2018, 15:13:58
Heisst das, dass ich das Beispiel in deinem branch V2 in Verbindung mit der HM Sensor Platine einfach nutzen kann oder müssen dort noch Änderungen zwecks Echtzeituhr gemacht werden?

Die Echtzeituhr muss dort noch eingebaut werden. Derzeit nutzt nur das HM-WDS10-TH-O Example die RTC. Im Prinzip ganz einfach:

* in setup() muss rtc.init() aufgerufen werden.
* der Alarm ist in ganzen Sekunden per rtc.add(alarm) zu aktivieren
* in loop() muss zusätzlich rtc.runready() aufgerufen werden
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

oli82

Zitat von: papa am 06 Februar 2018, 17:24:11
Die Echtzeituhr muss dort noch eingebaut werden. Derzeit nutzt nur das HM-WDS10-TH-O Example die RTC. Im Prinzip ganz einfach:
Danke für die Info.
Schau ich mir morgen mal an.
Bis dahin geht das andere Projekt vor ;)

oli82

#11
Na ganz so einfach ist es dann doch nicht (zumindest für jemanden, der eher das Verständnis von Hardware hat).
Soll jetzt zwar kein Supporttread für Programmierung werden, aber ich muss doch die sysclock. aufrufe durch rtc. Aufrufe tauschen und die rtc, wie du ja bereits geschrieben hast, im setup definieren.
Zusätzlich zu meiner Verwirrung nutzt das HM-WDS10-TH-O Beispiel eine Klasse für die rtc...
Hier mal meine Änderungen

papa

Zitat von: oli82 am 07 Februar 2018, 11:11:11
Na ganz so einfach ist es dann doch nicht (zumindest für jemanden, der eher das Verständnis von Hardware hat).
Soll jetzt zwar kein Supporttread für Programmierung werden, aber ich muss doch die sysclock. aufrufe durch rtc. Aufrufe tauschen und die rtc, wie du ja bereits geschrieben hast, im setup definieren.
Zusätzlich zu meiner Verwirrung nutzt das HM-WDS10-TH-O Beispiel eine Klasse für die rtc...
Hier mal meine Änderungen

Setz mal noch MSG_CYCLE auf 120 - also nur auf die reinen Sekunden. Dann sollte er schon alle 3 Minuten eine Nachricht senden.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

oli82

Zitat von: papa am 07 Februar 2018, 22:16:04
Setz mal noch MSG_CYCLE auf 120 - also nur auf die reinen Sekunden. Dann sollte er schon alle 3 Minuten eine Nachricht senden.
Danke für´s drüber schauen.
Habe die Änderungen mal übernommen und teste heute Abend zuhause

oli82

#14
Zitat von: papa am 07 Februar 2018, 22:16:04
Setz mal noch MSG_CYCLE auf 120 - also nur auf die reinen Sekunden. Dann sollte er schon alle 3 Minuten eine Nachricht senden.

Also die Änderungen haben leider nicht geklappt.
Der Zähler wird zwar angelegt und auch die Kanäle sind zu sehen, aber es kommen keine Werte.
Habe die gleichen Änderungen auch mal am Master gemacht, aber auch ohne Erfolg.