AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

Tom Major

Zitat von: DeepCore am 10 Dezember 2018, 13:30:02
Hallo zusammen!
Wo kann ich diese Definitionen finden? Ich vermute mal, dass die aus den Homematic XML-Dateien generiert wurden/werden, oder?

Die device registers stehen in Register.h
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

fhemfreund

Zitat von: fhemfreund am 10 Dezember 2018, 02:34:01
...
Habe meine Messung mit 3V Versorgung + BME280 + MAX44009 Breakout gemacht. Der Standby kam mir ehrlich gesagt auch zu hoch vor (komme in anderen ATMega Projekten teilweise in den nA Bereich beim Sleep). Habe zur Zeit noch den int. RC gefused - da auf dem Board ja ein Uhrenquartz ist: funktioniert dein Sketch auch damit (wg. Timing etc.)? Normalerweise spart das auch noch ...

...

@Tom,
bringe das nochmal hier hoch, da es ev. untergegangen ist: funktioniert dein Sketch auch mit 32Khz Takt? Würde das mal im Rahmen meiner Stromverbrauchsmessungen dann probieren ...

Andreas

Tom Major

Zitat von: fhemfreund am 10 Dezember 2018, 18:36:16
@Tom,
bringe das nochmal hier hoch, da es ev. untergegangen ist: funktioniert dein Sketch auch mit 32Khz Takt? Würde das mal im Rahmen meiner Stromverbrauchsmessungen dann probieren ...

Ja das geht, du kannst dich z.B. an papas Example HM-WDS10-TH-O orientieren.
Basically die codestellen die mit sysclock arbeiten auf rtc ändern..

32k Quarz spart dir ungefähr 3,5 von den 4uA mit aktiviertem watchdog, siehe 'Power-Down Supply Current vs. VCC' im Datenblatt.
Solange du aber 20uA hast ist diese Änderung nicht so entscheidend.
Kann gut sein dass es an den breakout boards liegt, die haben oft auch einen LDO drauf. Ich werde meine bei Gelegenheit auch mal messen was die verbrauchen.
Und auch mal den Sendestrom, das hatte ich schon länger vor.

Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

@papa
Ich wollte in einem neuem Projekt die AltSoftSerial
https://github.com/PaulStoffregen/AltSoftSerial
zusammen mit AskSinPP verwenden, habe aber gesehen das diese und auch deine Lib den 16bit Timer1 verwenden, und ich glaube du nimmst auch den Timer2 her, habe zumindest code Stellen dafür gesehen.
Kann ich aber zumindest den Timer0 für meine Zwecke zusammen mit der AskSinPP verwenden?
Danke,
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

fhemfreund

Zitat von: Tom Major am 10 Dezember 2018, 23:53:31
Ja das geht, du kannst dich z.B. an papas Example HM-WDS10-TH-O orientieren.
Basically die codestellen die mit sysclock arbeiten auf rtc ändern..

32k Quarz spart dir ungefähr 3,5 von den 4uA mit aktiviertem watchdog, siehe 'Power-Down Supply Current vs. VCC' im Datenblatt.
Solange du aber 20uA hast ist diese Änderung nicht so entscheidend.
Kann gut sein dass es an den breakout boards liegt, die haben oft auch einen LDO drauf. Ich werde meine bei Gelegenheit auch mal messen was die verbrauchen.
Und auch mal den Sendestrom, das hatte ich schon länger vor.

Habe jetzt nochmal mit hoher Abtastung (100 Werte/s) gemessen und siehe da - es kommt etwas sinnvolleres heraus: ~ 28mA beim Senden.
Der gemessene Standbystrom ist wahrscheinlich korrekt, da auf meinen Breakout-Boards jeweil LDOs vom Typ 662K verbaut sind. Diese haben einen Ruhestrom von ~ 7 ... 15uA.
Ein MCP1700 verbraucht nur ca. 1.6 ... 4uA und ist pinkompatibel. Ev. tausche ich und messe nochmal.

Mit den neuen Werten komme ich auf ~310Tage. Eine Reduktion um 2uA im Standby (ev. via Uhrenquartz) kommt auf ~330Tage.

>Basically die codestellen die mit sysclock arbeiten auf rtc ändern.
heisst das einfach von z.B.


battery.init(seconds2ticks(12UL * 60 * 60), sysclock);


auf


battery.init(seconds2ticks(12UL * 60 * 60), rtc);


?

Andreas

papa

Zitat von: Tom Major am 10 Dezember 2018, 23:58:26
@papa
Ich wollte in einem neuem Projekt die AltSoftSerial
https://github.com/PaulStoffregen/AltSoftSerial
zusammen mit AskSinPP verwenden, habe aber gesehen das diese und auch deine Lib den 16bit Timer1 verwenden, und ich glaube du nimmst auch den Timer2 her, habe zumindest code Stellen dafür gesehen.
Kann ich aber zumindest den Timer0 für meine Zwecke zusammen mit der AskSinPP verwenden?
Danke,
Die Sysclock wird standardmäßig an den Timer1 angebunden. Die RTC nutzt den Timer2 - aber nur, wenn sie auch im Sketch benutzt wird. Ist also im Prinzip verwendbar. Der Timer0 wird glaube ich von der Arduinobasis für die millis() verwendet. AskSinPP braucht millis() nicht - kann also auch für andere Sachen genutzt werden. Die millis() stimmen eh nicht mehr, wenn der Sleep benutzt wird.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

Zitat von: fhemfreund am 11 Dezember 2018, 01:51:21
>Basically die codestellen die mit sysclock arbeiten auf rtc ändern.
heisst das einfach von z.B.

battery.init(seconds2ticks(12UL * 60 * 60), sysclock);

auf

battery.init(seconds2ticks(12UL * 60 * 60), rtc);

Nicht ganz. Die RTC tickt immer im Sekundentakt und braucht somit die Umrechnung in ticks nicht - also nur

battery.init(12UL * 60 * 60, rtc);

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

Tom Major

Zitat von: papa am 11 Dezember 2018, 08:59:13
Die Sysclock wird standardmäßig an den Timer1 angebunden. Die RTC nutzt den Timer2 - aber nur, wenn sie auch im Sketch benutzt wird. Ist also im Prinzip verwendbar. Der Timer0 wird glaube ich von der Arduinobasis für die millis() verwendet. AskSinPP braucht millis() nicht - kann also auch für andere Sachen genutzt werden. Die millis() stimmen eh nicht mehr, wenn der Sleep benutzt wird.

Danke für die Info. millis() hatte ich gar nicht auf dem Schirm, aber stimmt, habe nachgeschaut, Arduino verwendet Timer0 dafür.
Da ich die RTC normalerweise nicht verwende werde ich Timer2 für die SoftSerial nehmen.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

fhemfreund

Zitat von: papa am 11 Dezember 2018, 09:00:39
Nicht ganz. Die RTC tickt immer im Sekundentakt und braucht somit die Umrechnung in ticks nicht - also nur

battery.init(12UL * 60 * 60, rtc);


Ok - danke für die Info. Habe dann mal alle Codestellen zusammengefasst, die von:


battery.init(seconds2ticks(12UL * 60 * 60), sysclock);
bool runready() { return sysclock.runready() || BaseHal::runready(); }
sysclock.cancel(*this);
trigger(sysclock);
sysclock.add(*this);


nach


battery.init(12UL * 60 * 60), rtc);
bool runready() { return rtc.runready() || BaseHal::runready(); }
rtc.cancel(*this);
trigger(rtc);
rtc.add(*this);


geändert werden müssen. Wenn das so korrekt ist würde ich es mal versuchen ... (und dann wieder messen)

Andreas

papa

Zitat von: fhemfreund am 11 Dezember 2018, 17:04:45
Ok - danke für die Info. Habe dann mal alle Codestellen zusammengefasst, die von:


battery.init(seconds2ticks(12UL * 60 * 60), sysclock);
bool runready() { return sysclock.runready() || BaseHal::runready(); }
sysclock.cancel(*this);
trigger(sysclock);
sysclock.add(*this);


nach


battery.init(12UL * 60 * 60), rtc);
bool runready() { return rtc.runready() || BaseHal::runready(); }
rtc.cancel(*this);
trigger(rtc);
rtc.add(*this);


geändert werden müssen. Wenn das so korrekt ist würde ich es mal versuchen ... (und dann wieder messen)

Andreas
So einfach ist es nicht. Die sxscöock wird intern immer noch gebraucht. Bitte mal den ganzen Sketch anhängen bzw. in schon vorher erwähnten Beispiel ansehen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: fhemfreund am 11 Dezember 2018, 17:04:45
Ok - danke für die Info. Habe dann mal alle Codestellen zusammengefasst, die von:


battery.init(seconds2ticks(12UL * 60 * 60), sysclock);
bool runready() { return sysclock.runready() || BaseHal::runready(); }
sysclock.cancel(*this);
trigger(sysclock);
sysclock.add(*this);


nach


battery.init(12UL * 60 * 60), rtc);
bool runready() { return rtc.runready() || BaseHal::runready(); }
rtc.cancel(*this);
trigger(rtc);
rtc.add(*this);


geändert werden müssen. Wenn das so korrekt ist würde ich es mal versuchen ... (und dann wieder messen)

Andreas

Es fehlt zumindest auch
rtc.init();
und
hal.activity.savePower<SleepRTC>(hal);
in deiner Auflistung.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

fhemfreund

Zitat von: papa am 11 Dezember 2018, 19:14:07
So einfach ist es nicht. Die sxscöock wird intern immer noch gebraucht. Bitte mal den ganzen Sketch anhängen bzw. in schon vorher erwähnten Beispiel ansehen.

ok. Dann muss ich leider passen - habe mir mal dein HM-WDS10-TH-O Beispiel angeschaut und konnte auch ein paar Ähnlichkeiten zu Tom's Code feststellen - es übersteigt aber doch meine Fähigkeiten das korrekt anzupassen.

@Tom - können wir deinen Code hier von papa mal checken lassen?

Andreas

Tom Major

Zitat von: fhemfreund am 11 Dezember 2018, 20:22:05
ok. Dann muss ich leider passen - habe mir mal dein HM-WDS10-TH-O Beispiel angeschaut und konnte auch ein paar Ähnlichkeiten zu Tom's Code feststellen - es übersteigt aber doch meine Fähigkeiten das korrekt anzupassen.

@Tom - können wir deinen Code hier von papa mal checken lassen?
Andreas

Klar, ist ja kein Geheimnis und basiert natürlich sowieso auf papas Beispielen.
Ich könnte dir wahrsch. eine Testversion mit RTC machen, aber nicht vor dem WE.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

Zitat von: fhemfreund am 11 Dezember 2018, 01:51:21
Habe jetzt nochmal mit hoher Abtastung (100 Werte/s) gemessen und siehe da - es kommt etwas sinnvolleres heraus: ~ 28mA beim Senden.
Der gemessene Standbystrom ist wahrscheinlich korrekt, da auf meinen Breakout-Boards jeweil LDOs vom Typ 662K verbaut sind. Diese haben einen Ruhestrom von ~ 7 ... 15uA.
Ein MCP1700 verbraucht nur ca. 1.6 ... 4uA und ist pinkompatibel. Ev. tausche ich und messe nochmal.
Mit den neuen Werten komme ich auf ~310Tage. Eine Reduktion um 2uA im Standby (ev. via Uhrenquartz) kommt auf ~330Tage.

Habe mich heute etwas mit dem Ruhestrom der Sensor-/Breakout-Boards für BME280 und MAX44009 beschäftigt.

Tatsächlich verbrauchen die LDOs auf diesen Boards einige uA.
Habe mal versucht das ganze zu dokumentieren:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Ruhestrom#ruhestrom-mit-sensor-boards

z.B. BME280 Board 5uA, ohne LDO 0,1uA, da kann man definitiv Batterielaufzeit für das Gerät rausholen  :)

Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

fhemfreund

Zitat von: Tom Major am 11 Dezember 2018, 22:50:50
Klar, ist ja kein Geheimnis und basiert natürlich sowieso auf papas Beispielen.
Ich könnte dir wahrsch. eine Testversion mit RTC machen, aber nicht vor dem WE.

Das wäre klasse. Dann warte ich auf deine Version und werde danach messen.

Den Ansatz die LDOs zu entfernen (statt einen MCP1700 zu nehmen) habe ich auch ins Auge gefasst. So wie es aussieht muss das (in meiner Konfiguration) nur für den MAX44009 gemacht werden.
Für den BME280 gibt es ein Breakout ohne LDO.

Mit dem Uhrenquartz+Breakouts ohne LDOs+abschaltbarer LED (=LedMode off) ist einiges an Optimierungspotential vorhanden. Mal angenommen der Ruhestrom kann auf 10uA gesenkt werden, dann sind das rechnerisch schon ~458 Tage.

Andreas