Forum: Mikrocontroller und Digitale Elektronik Sekunden genauer Timer im Energiespar Modus


von Rene F. (elv)


Lesenswert?

Hallo,

ich habe folgendes Problem wie folgt:

Hardware:
Arduino Pro mini 8MHz / 3.3V (Spannungsregler+LED entfernt)
HTU21D Temp-Feuchte-Sensor
2x AAA Batterien
1x Sender 433 MHz HFS-300
1x DC Converter Boost Step up Down 0.9V/3.3V

Software:
Ein Temperatur/Feuchte/Sensor für eine Wetterstation sendet genau alle 
174,5s ein
Datentelegram. Im Standby Betrieb werden 8,7mA benötigt, dass ist für 
den Batteriebetrieb
langfristig gesehen ein zu hoher Wert. Optimal wären ca. < 1 mA im 
Standby Betrieb.
Der Watchdog-Timer ist leider zu ungenau.

Sketch:
1
#include <TempHygroTX868.h>
2
#include <SparkFunHTU21D.h>
3
4
HTU21D htu;
5
TempHygroTX868 tx;
6
// pin of build-in signal LED
7
#define LED 13
8
9
void setup()
10
{
11
 // HFS-300 is at data pin 5
12
 htu.begin();
13
 tx.setup(5, TempHygroTX868::PROT_V12);
14
}
15
16
void loop()
17
{
18
 byte address = 4;
19
20
 digitalWrite(LED, HIGH);
21
 float humidity = htu.readHumidity();
22
 float temperature = htu.readTemperature();
23
24
#ifdef DEBUG
25
 Serial.print(humidity);
26
 Serial.print("t");
27
 Serial.println(temperature);
28
#endif
29
 
30
 delay(100);
31
 
32
 if (humidity < 900 && temperature < 900) {
33
   // valid reading
34
   tx.send(temperature, humidity);
35
 }
36
 digitalWrite(LED, LOW);
37
38
 tx.setAddress(address);
39
 tx.send(temperature, humidity);
40
 
41
 delay(2.9 * 60 * 1000UL);
42
}

Vielleicht kann mir wer weiter helfen?
Danke!
LG
Rene

[Mod: bitte das nächste Mal die [c]-Tags selber einfügen]

: Bearbeitet durch Moderator
von Magnus M. (magnetus) Benutzerseite


Lesenswert?

Rene F. schrieb:
> 1x DC Converter Boost Step up Down 0.9V/3.3V
(...)
> Im Standby Betrieb werden 8,7mA benötigt, dass ist für den
> Batteriebetrieb langfristig gesehen ein zu hoher Wert.

Was sagt das Datenblatt deines DC/DC-Wandlers dazu?

von Rene F. (elv)


Lesenswert?

Leider habe ich kein Datenblatt. (ebay no name)
Jedoch habe ich im Watchdog-Timer betrieb ca. 0,76mA gemessen, jedoch 
ist der Watchdog-Timer zu ungenau einmal ca. 167s dann wieder ca. 177s 
usw..
Brauche exakt 174,5s siehe Sketch oben: delay(2.9  60  1000UL);

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

An welcher Stelle hast Du überhaupt den Strom gemessen? Vor oder nach 
dem DC/DC?

von Rene F. (elv)


Lesenswert?

2x AAA in Serie Ampermeter dann DC/DC

von Peter D. (peda)


Lesenswert?

Der ATmega328P kann mit Uhrenquarz betrieben werden und braucht dann 
~1µA (Power Save).
Für den CPU-Takt muß man dann die Fuses auf interne 8MHz setzen.

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

Rene F. schrieb:
> 2x AAA in Serie Ampermeter dann DC/DC

Und welchen Strom misst du wenn du...

a) den Arduino vom DC/DC trennst?
b) den Arduino vom DC/DC trennst und statt dessen einen
   Widerstand (z.B. 10k) an den Ausgang des DC/DC hängst?
   (Bitte den verwendeten Widerstandswert nennen!)

von Rene F. (elv)


Lesenswert?

Arduino Pro mini 8MHz / 3.3V möglich ohne SMD löten?
Möchte dem Board treu bleiben wenn möglich.

von Wolfgang (Gast)


Lesenswert?

Rene F. schrieb:
> Brauche exakt 174,5s siehe Sketch oben: delay(2.9  60  1000UL);
Das wirst du ohne direkten Link zu einer Atomuhr nicht hin bekommen.

von foobar (Gast)


Lesenswert?

> Im Standby Betrieb werden 8,7mA benötigt,

Ich sehe keinen Standby Betrieb - dein Sketch rödelt auf 100%.

von H.Joachim S. (crazyhorse)


Lesenswert?

Man bekommt es mit dem Uhrenquarz hin, aber vielleicht ist ein externer 
RTC-Chip mit Alarm eine Möglichkeit die schneller zum Erfolg führt.
Klar, mehr Hardware.

von Sascha W. (sascha-w)


Lesenswert?

H.Joachim S. schrieb:
> Man bekommt es mit dem Uhrenquarz hin, aber vielleicht ist ein externer
> RTC-Chip mit Alarm eine Möglichkeit die schneller zum Erfolg führt.
> Klar, mehr Hardware.
und nicht für 1/2 Sekunden geeignet - wenn er es so genau haben will.

Sascha

von H.Joachim S. (crazyhorse)


Lesenswert?

Naja, man kann ja auf die vorherige Sekunde wecken lassen und dann noch 
ne halbe Sekunde so rumdödeln.
Exakt 174,5s (was ist denn das überhaupt für ne Zahl und wo kommt diese 
Forderung her?) liefert keine Uhr der Welt. Ok, verdammt nah dran, aber 
mit exakt sollte man vorsichtig seion.

von Rene F. (elv)


Lesenswert?

Die zahl 174,5s wurde mit einer Stoppuhr (1/10) gestoppt.
Der Sender mit 433Mhz sendet im erwä#hnten Intervall, jedoch sind auch 
175s ausreichend.

von Mal einwerfen (Gast)


Lesenswert?

Weg mit dem Scheiss delay. Der braucht nur Strom und bringt nichts. Lass 
den Timer Interrupt laufen. Was soll der Stepup ? Die 2 AAAZellen 
bringen ja auch schon 2.5V oder so

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Am besten macht man einen Resync nach dem Datentelegramm und lässt z.B. 
einen Timer für 170s laufen. Gerade beim Mega328 ist es ja möglich Timer 
2 mit dem 32kHz Quarz zu treiben, was bei einem Vorteiler von 1024 alle 
8 Sekunden einen Interrupt auslöst. Das lässt man 21 mal passieren 
(168s) und wartet dann auf ein Datentelegramm.

von Rene F. (elv)


Lesenswert?

AW: @ foobar (Gast)

Das Sketch ist in dieser Form funktionstüchtig und das Datentelegram 
wird korrekt empfangen. Das Sketch mit Watchdog-Timer (8s Sleep) wurde 
hier nicht angehängt, da es zu ungenau ist.

von Zeno (Gast)


Lesenswert?

Eigentlich der falsche Ansatz. Man weckt nicht Controller alle alle x 
Sekunden auf um dann zu warten das der Sensor ein Datentelegramm sendet.

Es funkktioniert genau anders herum. Der Controller wird in Intervallen 
von x Sekunden aufgeweckt, dann sendet er eine Anforderung an die 
Sensoren und empfängt die Daten von selbigen. Wenn der Sensor nach einer 
bestimmten Zeit nicht auf die Anforderung regiert wird der Datensatz 
halt verworfen. Der Host merkt sich das ein Datensatz ausgefallen ist. 
Wenn das mehrfach hintereinander vorkommt, kann entsprechend reagiert 
werden.
Bei den käuflichen Wetterstationen verläuft die Datenabfrage genau so.

Der Host - also der µC - weckt den Sensor und fordert die Daten an und 
nicht anders herum.

Bei Deiner Methode wird das Ganze irgendwann aus dem Ruder laufen sobald 
der Sensor das Intervall nicht exakt einhält.

von Rene F. (elv)


Lesenswert?

Es war ein Versuch für einen bestehende Wetterstation einen Sender 
nachzubauen. Es hat ja auch mit den oben angezeigten Sketch geklappt, 
dass Datentelegram wird auch empfangen wenn die 175s eingehalten werden.
Die Station sucht zweimal am Tag neue Sender mit einer Kennung.

Natürlich ist im Sketch, dass "delay(2.9  60  1000UL);" nicht die 
Lösung.

Bitte um etwas Rücksicht ich bin erst ca. seit einer Woche mit der
Thematik Arduino beschäftigt. (Newbie)

von Mike J. (linuxmint_user)


Lesenswert?

Rene F. schrieb:
> Arduino Pro mini 8MHz / 3.3V (Spannungsregler+LED entfernt)
> HTU21D Temp-Feuchte-Sensor
> 2x AAA Batterien
> 1x Sender 433 MHz HFS-300
> 1x DC Converter Boost Step up Down 0.9V/3.3V

100 Stück der XC6206P332MR 3,3V Festspannungsregler kosten bei eBay um 
die 2€ und sie ziehen nur 7µA Ruhestrom.
Dazu ein LiIon-Akku und du hast keine Probleme mehr mit dem Ruhestrom.

von Manfred (Gast)


Lesenswert?

Mike J. schrieb:
> 100 Stück der XC6206P332MR 3,3V Festspannungsregler kosten bei eBay um
> die 2€ und sie ziehen nur 7µA Ruhestrom.
> Dazu ein LiIon-Akku und du hast keine Probleme mehr mit dem Ruhestrom.

Blödsinn hoch sieben! Versuche noch einmal, den Thread zu lesen oder Dir 
vorlesen zu lassen.

Die von Rene gemessenen 9mA sind der Verbrauch des µC, nicht des 
Reglers:
Rene F. schrieb:
> Spannungsregler+LED entfernt

Sein Problem besteht in der gewaltig großen Ungenauigkeit des 
AT328-SleepTimers, das hat mit der Versorgung rein garnichts zu tun.

Rene F. schrieb:
> 2x AAA in Serie

sind leider auch Unfug: Die haben im Neuzustand 3 Volt, Entladeende aber 
erst unter 2 Volt. Für den realen Aufbau spendiere drei Zellen in Reihe.

von Wolfgang (Gast)


Lesenswert?

Zeno schrieb:
> Es funkktioniert genau anders herum. Der Controller wird in Intervallen
> von x Sekunden aufgeweckt, dann sendet er eine Anforderung an die
> Sensoren und empfängt die Daten von selbigen.
Dazu müsste der Sensor erstmal einen Empfänger haben, der auf den 
Controller lauschen kann (und während dessen dauernd Strom verbraucht). 
Und auch da wäre man bei Batteriebetrieb aus Energiegründen wieder in 
einem Szenario, wo man eine Strategie braucht, um die Empfängerlaufzeit 
kurz zu halten, i.e. das Empfangszeitfenster möglichst stark 
einzugrenzen.
Außerdem: "3-V-AM-Sendemodul HFS 300" hört sich nicht wirklich nach 
bidirektionaler Kommunikationsmöglichkeit an.

Rene F. schrieb:
> Leider habe ich kein Datenblatt. (ebay no name)
Wenigstens eine Link auf das Angebot deines "DC Converter Boost Step up 
Down 0.9V/3.3V", eine Angabe zum dort verwendeten IC oder ein Bild von 
der Platine wird es doch geben. Dein Modul wird doch kein Einzelstück 
sein ;-)

von Mike J. (linuxmint_user)


Lesenswert?

Manfred schrieb:
> Die von Rene gemessenen 9mA sind der Verbrauch des µC, nicht des
> Reglers:

Ja, das ist schon klar.
"foobar (Gast)" hatte das ja schon erwähnt. Das ist aber nicht das 
einzige Problem.

Rene F. schrieb:
>> 1x DC Converter Boost Step up Down 0.9V/3.3V

Hier hat er aber einen Verbraucher den er durch seine zwei in Reihe 
geschalteten NiMH-Akkus, die ja in Summe nur 2-3V liefern.

Das ist ein Problem für ihn, denn er benötigt die 3,3V ja für seine 
Sensoren.

Es gibt StepUp oder auch StepDown Schaltregler, welche mittels 
TrickleCharge imstande sind einen sehr geringen Ruhestrom zu 
ermöglichen, aber man kommt damit niemals auf den niedrigern Ruhestrom 
eines solchen Festspannungsreglers.
Ich würde auch wetten dass er keinen super stromsparenden StepUp-Wandler 
gekauft hat, sondern einen der ohne Last schon ein paar mA zieht.


Das was du hier als "Hauptproblem" ansiehst, das ist keins.
Er kann einfach einen Uhrenquarz an Timer2 hängen und sich über den 
Prescaler alle 0,5s einen Interrupt geben lassen.
(Wie "Peter D. (peda)" oben geschrieben hat.)


Zeno schrieb:
> Bei Deiner Methode wird das Ganze irgendwann aus dem Ruder laufen sobald
> der Sensor das Intervall nicht exakt einhält.

Manchmal geht es eben nicht anders. Ich habe das auch schon so gemacht.

Der Sender verschickt alle 10 Minuten ein Paket, der Empfänger wird alle 
10 Minuten aufgeweckt (eigentlich etwas früher und wartet eine kurze 
Zeit bis ein Datenpaket ankommt) und synchronisiert sich dann mit der im 
Datenpaket hinterlegten Uhrzeit. Ich hatte es so gemacht dass die Uhren 
nach einer gewissen Zeit dann alle sehr synchron liefen und die 
Abweichung so minimal war wie es nur irgend wie aufwandstechnisch 
sinnvoll möglich war.

So muss der Empfänger nicht permanent an bleiben. Neu konfigurieren kann 
man ihn dann eben immer nur dann wenn gerade ein Datenpaket ausgetauscht 
wird.

Ich hatte es so gestaltet dass man die einzelnen Empfänger abschalten 
konnte, aufladen usw. (außer Reichweite) und sie sich dann selbst in das 
System synchronisieren sobald sie ein Datenpaket empfangen. Zu Beginn 
verbrauchen sie etwas viel Strom weil sie permanent an sind, man konnte 
aber händisch auch ein Sync an der Basisstation erzwingen, so dass der 
Sender dem Empfänger vorzeitig ein Korrektur-Sync-Paket schickt.


Was blöd war, das war der Wunsch dass man am PC das zu einem beliebigen 
Zeitpunkt neu konfigurieren wollte, aber das ging eben nicht weil der 
einzelne Empfänger ja nur alle 10 Minuten (oder der jeweils eingestellte 
Intervall, vielleicht auch 30 Minuten oder 1 Stunde) aufwacht.

Manche Empfänger sollen auch sehr energiesparend einen Interrupt 
auslösen können sobald ein genügend starkes Feld existiert, so dass man 
die Empfänger quasi nach Belieben aufwecken kann, aber das haben wir 
dann verworfen. Die, welche das konnten waren für unsere Zwecke dann 
auch wieder nicht passend.

von K. S. (the_yrr)


Lesenswert?

Rene F. schrieb:
> jedoch
> ist der Watchdog-Timer zu ungenau einmal ca. 167s dann wieder ca. 177s
> usw..
> Brauche exakt 174,5s

Wie kommst du darauf, dass du exakt 174.5 Sekunden brauchst? Nur weil 
das Original das so macht, heißt es nicht dass das so sein muss. Der µC 
wird im Original auch nur mit einem RC Oszillator laufen und damit kaum 
viel genauer als der Watchdog sein.

Rene F. schrieb:
> Es war ein Versuch für einen bestehende Wetterstation einen Sender
> nachzubauen. Es hat ja auch mit den oben angezeigten Sketch geklappt,
> dass Datentelegram wird auch empfangen wenn die 175s eingehalten werden.

und was passiert wenn du nur alle 170s  oder alle 180s sendest? Teste 
mal opb der ganze Aufwand überhaupt nötig ist, nicht dass es nachher 
auch funktioniert wenn du alle 100s oder alle 300s sendest.

von MaWin (Gast)


Lesenswert?

Rene F. schrieb:
> Arduino Pro mini 8MHz / 3.3V (Spannungsregler+LED entfernt)

Falsche Wahl.

Da beim einfachen Arduino USB programming keine fuses programiert werden 
können, kann man ihn nicht auf 32kHz Quartz mit sleep und wake up on 
timer event programmieren.

Du musst den ATmega328 nackt programmieren "STK500 oder ISPDongle", oder 
besser gleich einen energiesparenderen AVR (PicoPower) nutzen.

Rene F. schrieb:
> Ein Temperatur/Feuchte/Sensor für eine Wetterstation sendet genau alle
> 174,5s ein Datentelegram.

Und dein Arduino simuliert offenbar diesen Weterstationssensor. Das 
klingt nicht danach, als ob die Zeit quartzgenau eingehalten werden 
muss, sondern als ob dein WatchDog-timing reicht.

von Einer K. (Gast)


Lesenswert?

MaWin schrieb:
> Falsche Wahl.
Unfug!

MaWin schrieb:
> Du musst den ATmega328 nackt programmieren
Ein so gestippter pro Mini ist nicht mehr als ein Nackter ATMega328P
Einzig dass man den Resonator auch noch entfernen muss (irgendwo muss 
der Uhrenquarz ja hin, die Möglichkeiten sind auf 1 begrenzt), macht 
einen Unterschied.

MaWin schrieb:
> besser gleich einen energiesparenderen AVR (PicoPower) nutzen.
auf dem Pro Mini ist die PicoPower Variante montiert.

MaWin schrieb:
> Da beim einfachen Arduino USB programming keine fuses programiert werden
> können, kann man ihn nicht auf 32kHz Quartz mit sleep und wake up on
> timer event programmieren.

Ein ISP Progammer kann es richten.
Dafür eignet sich quasi jeder Arduino.
(evtl. gibt es ein paar Exoten als Ausnahme.)

MaWin schrieb:
> Du musst den ATmega328 nackt programmieren "STK500 oder ISPDongle", oder
> besser gleich einen energiesparenderen AVR (PicoPower) nutzen.
Das "oder besser" ist da sehr interessant gesetzt.
Denn es bringt Dinge zum Vergleich, die NICHTS miteinander zu tun haben.

MaWin schrieb:
> Da beim einfachen Arduino USB programming keine fuses programiert werden
> können,
Der Pro Mini hat sowieso keinen USB Anschluss!
Was soll die Ansage dann?

von Mike J. (linuxmint_user)


Lesenswert?

MaWin schrieb:
> Und dein Arduino simuliert offenbar diesen Weterstationssensor. Das
> klingt nicht danach, als ob die Zeit quartzgenau eingehalten werden
> muss,

So wie er das beschreibt klingt das nach einer Wetterstation die in dem 
Intervall sendet und er hat da nur einen Batterie-gespeisten Empfänger 
gebastelt der diese Daten empfängt und vielleicht auch anzeigt.

Siehe hier:
Rene F. schrieb:
> Die zahl 174,5s wurde mit einer Stoppuhr (1/10) gestoppt.
> Der Sender mit 433Mhz sendet im erwä#hnten Intervall, jedoch sind auch
> 175s ausreichend.

von Εrnst B. (ernst)


Lesenswert?

Rene F. schrieb:
> TempHygroTX868 tx;

Bei der "Library" ist doch ein stromspar-example-Program dabei, was das 
trotz Sleep und Watchdog hinzubekommen scheint.


https://github.com/skaringa/TempHygroTX868/blob/master/examples/TX868_HTU21_LowPower/TX868_HTU21_LowPower.ino

von Axel S. (a-za-z0-9)


Lesenswert?

Rene F. schrieb:
> Das Sketch ist in dieser Form funktionstüchtig

Nein.

Wenn dein Anspruch war, einen batteriebetriebenen Temperatursensor zu 
bauen, dann ist dieser Sketch nicht funktionstüchtig, denn er saugt 
die Batterien in ca. 2 Wochen leer.


Rene F. schrieb:
> Bitte um etwas Rücksicht ich bin erst ca. seit einer Woche mit der
> Thematik Arduino beschäftigt. (Newbie)

Tja. Dann wird es Zeit, daß mal jemand Tacheles mit dir redet: wenn du 
dieses Projekt erfolgreich durchziehen willst, dann mußt du 
programmieren lernen. Und nein, du kannst es noch nicht.

Vergiß Arduino. Es ist zwar nicht so, daß man das mit Arduino nicht 
hinbekommen könnte (unter der Haube ist das auch nur ein avr-gcc, also C 
bzw. C++). Aber wenn du es mit Arduino kannst, dann kannst du es auch 
ohne. Oder anders gesagt: Arduino bringt dir hier gar keinen Mehrwert.

Stromsparende Sensoren baut man so, daß man den µC in den Pausen in den 
Tiefschlaf legt. Und wenn der Watchdog zu ungenau ist, um den µC zur 
richtigen Zeit aufzuwecken, dann hängt man einen 32kHz Uhrenquarz an die 
entsprechenden Pins und verwendet einen Schlafmodus, wo dieser Quarz und 
ein Timer weiterlaufen. Dann kann der Timer den µC sub-sekundengenau 
aufwecken.

Blöderweise sind die dafür notwendigen Pins auf deinem Arduino Board 
schon belegt. Du kannst also nicht nur das Arduino Framework vergessen, 
sondern auch dein Arduino Board.

Arduino ist wie Lego. Man kann damit nette Dinge zusammenstecken. Aber 
man kann damit nicht zum Mond fliegen. Noch nicht mal Kaffee kochen.

Natürlich kann man immer noch was frickeln, um den Arduino zu retten. 
Z.B. eine externe Echtzeituhr anflanschen, die den Arduino aus dem 
Schlaf holt. Oder man könnte einen ATTiny13 entsprechend programmieren. 
Aber unter dem Strich bleibt das Gefrickel. Mit dem passenden Knowhow 
reicht ein ATMega88PA + Uhrenquarz + Sensor + Funkmodul. Den Stepup 
würde man abschaltbar machen, daß er im Schlaf die Batteriespannung 
durchreicht (dem µC reicht das). Und erst nach dem Aufwachen würde er 
aktiviert und die Spannung auf 3.3V hochboosten.

Aber wie das mit Knowhow so ist: man muß es sich erstmal aneignen.

von MaWin (Gast)


Lesenswert?

Arduino Fanboy D. schrieb:
> Der Pro Mini hat sowieso keinen USB Anschluss!

Oh, das habe ich übersehen. Ich habe mir zwar das Modell vorher im Bild 
angeguckt, aber ähnlich einem Nano angesehen.
Offenbar ist aber nur der Bootloader vorinstalliert, d.h er wird vom TO 
seriell programmiert werden. Damit kommt man immer noch nicht an die 
fuses, der Hinweis an den TO man müsste ihn per STK/ISP programieren ist 
also nicht verkehrt.

Arduino Fanboy D. schrieb:
> auf dem Pro Mini ist die PicoPower Variante montiert.

Hmm, auf der gefundenen Seite stand bloss ATmega328. 
https://www.amazon.de/Arduino-kompatibles-ATmega-Mini-ATmega328/dp/B00H9CVQDW 
Man sollte wohl die Originalseite nutzen. 
https://store.arduino.cc/arduino-pro-mini Obwohl, man weiss ja auch 
nicht welchen billigen pro er nun gekauft hat.

Das Arduino Pro scheint eine maximal blöde Marketingskonstruktion zu 
sein: Kaum Nutzen weil ihm die einface Handhabbarheit der Arduinos per 
USB fehlt, aber maximaler Preis weil sie so tun als wäre es ein Arduino. 
Das einzige was drauf ist, der Spannungsregler, stört mehr als dass er 
nützt. Die Welt will betrogen werden.

von Einer K. (Gast)


Lesenswert?

MaWin schrieb:
> Die Welt will betrogen werden.
Es ist wohl der kleinste und stromsparendste AVR Arduino von allen.

Klar, kannst du das als Betrug bezeichnen, wenn dir danach ist!

MaWin schrieb:
> Obwohl, man weiss ja auch
> nicht welchen billigen pro er nun gekauft hat.

ALLE Arduinos mit dem ATMega 328 verwenden die PicoPower Version.
ALLE.
Auch die Klone und  Nachbauten.

Wieso machst du dich nicht einfach Kundig, bevor du dich mit deinem 
Nichtwissen blamierst?

von Peter D. (peda)


Lesenswert?

Rene F. schrieb:
> Die zahl 174,5s wurde mit einer Stoppuhr (1/10) gestoppt.

Soweit sich das ohne Schaltplan vermuten läßt, geht es um das 
Senderaster.
Die Wetterstation wird daher einen Toleranzbereich haben, in dem das 
Signal empfangen wird. Man kann also erstmal ausprobieren, welches die 
minimale und die maximale Zeit ist. Super genaue 174,5s sind bestimmt 
nicht nötig.

von Harald W. (wilhelms)


Lesenswert?

Axel S. schrieb:

> Arduino ist wie Lego. Man kann damit nette Dinge zusammenstecken. Aber
> man kann damit nicht zum Mond fliegen.

Im Legoland habe ich aber auch eine Mondrakete gesehen. :-)

von Manfred (Gast)


Angehängte Dateien:

Lesenswert?

Mike J. schrieb:
> Rene F. schrieb:
>>> 1x DC Converter Boost Step up Down 0.9V/3.3V
> Hier hat er aber einen Verbraucher ...

Entschuldige, den Wandler habe ich überlesen. Um Energie zu sparen, ist 
das ein falscher Ansatz. Der ProMini 8MHz ist gut geeignet, direkt an 
einer LiIon zu laufen. Doof ist, dass manche Peripherie nicht mehr als 
3,6V verträgt - ich bin dazu gerade am Grübeln.

MaWin schrieb:
> Arduino Fanboy D. schrieb:
>> Der Pro Mini hat sowieso keinen USB Anschluss!
>
> Oh, das habe ich übersehen.
> Ich habe mir zwar das Modell vorher im Bild
> angeguckt, aber ähnlich einem Nano angesehen.

Er hat einen Bootloader und an der Schmalseite Rx, Tx, Ub, GND und Reset 
auf die Leiste geführt. Braucht man zusätzlich ein USB-Adapterchen um 
85ct, dann ist er identisch dem Nano zu handeln.

Wegen der möglicherweise verschiedenen Spannungen habe ich mir 
zusätzlich noch eine galvanische Trennung aufgebaut - dazu findet sich 
hier irgendwo ein Thread.

> Das Arduino Pro scheint eine maximal blöde Marketingskonstruktion
> zu sein: Kaum Nutzen weil ihm die einface Handhabbarheit der
> Arduinos per USB fehlt,

Mit dem Vorteil , dass man den USB-Baustein nicht ständig mit Strom 
füttern muß.

> aber maximaler Preis weil sie so tun als wäre es ein Arduino.

Stimmt, der kostet als Chinese kaum weniger als ein Nano.

> Das einzige was drauf ist, der Spannungsregler, stört mehr
> als dass er nützt. Die Welt will betrogen werden.

Der Spannungsregler macht Sinn, aber müsste ein anderer Typ mit deutlich 
geringerem Querstrom sein. Leider ist der MCP1703 nicht pinkompatibel. 
Idiotisch ist die LED auf der Stromversorgung.

Ich habe den schon eingesetzt, um eine Batteriemimik zu überwachen. Alle 
8s einen Zähler incrementieren, etwa alle Viertelstunde ein paar ms 
Spannung messen ... mit MCP1703 und dickem Elko drumherum bin ich um 
25µA unterwegs - und das ganz simpel aus der Arduino-IDE heraus!

Rene F. schrieb:
> Arduino Pro mini 8MHz / 3.3V (Spannungsregler+LED entfernt)

ist eine sinnvolle Basis für sein Projekt.

von Einer K. (Gast)


Lesenswert?

Manfred schrieb:
> Der Spannungsregler macht Sinn, aber müsste ein anderer Typ mit deutlich
> geringerem Querstrom sein. Leider ist der MCP1703 nicht pinkompatibel.
> Idiotisch ist die LED auf der Stromversorgung.

Die originalen Pro Mini haben eine Brücke zum durchkratzen, um Regler 
und Power LED abzutrennen.
Die China Nachbauten wohl leider nicht.

von sid (Gast)


Lesenswert?

Warum den prescaler nicht anpassen zur Laufzeit?
21x 8sek schlafen lassen (168Sek)
timer prescaler auf 4sek einmal Nickerchen (172Sek),
prescaler auf 2sek und noch ein Nickerchen (174Sek),
Aufwachen prescaler auf 8sek und auf Telegram warten.
und danach von vorn ..
selbst mit nem oszillator sollte man
in drei Minuten kein Prozent Abweichung erwarten, oder?
1
volatile uint8_t c_wdt=0;
2
3
ISR(WDT_vect)
4
{
5
  if(c_wdt>1)
6
    c_wdt--;
7
  else
8
    c_wdt=23;
9
}
10
11
void enterSleep(void)
12
{
13
  WDTCSR |= _BV(WDIE);
14
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
15
  sleep_enable();
16
17
  sleep_mode();
18
19
  //Aufwachen bei ISR
20
  sleep_disable();
21
  power_all_enable();
22
}
23
24
void setup() 
25
{
26
  cli();
27
  MCUSR &= ~(1<<WDRF);
28
  WDTCSR |= (1<<WDCE) | (1<<WDE);
29
  WDTCSR = 1<<WDP0 | 1<<WDP3; //8sek
30
  sei();
31
}
32
33
void loop() {
34
35
  if(c_wdt == 0)
36
  {
37
    cli();
38
    //warten auf telegram
39
    //
40
    //
41
    //
42
    // wie auch immer
43
    WDTCSR = 1<<WDP0 | 1<<WDP3; // 8sek
44
    sei();
45
    enterSleep();
46
  }
47
  else if(c_wdt == 1) // 2sek sleep
48
  {
49
    cli();
50
    WDTCSR = 1<<WDP0 | 1<<WDP1 | 1<<WDP2; // 2sek
51
    sei();
52
    enterSleep();
53
  }
54
  else if(c_wdt == 2) // 4sek sleep
55
  {
56
    cli();
57
    WDTCSR = 1<<WDP3; // 4sek
58
    sei();
59
    enterSleep();
60
  }
61
  else  //8sek sleep
62
    enterSleep();
63
    
64
}
Nicht? bin ehrlich grad unsicher #kopfkratz

da drängt sich mir die Frage auf, ob man den Pro Mini
im sleep cycle mit ner Kondensatorladung befeuern kann..
wacht er auf latcht er die stromversorgung (die uA den Kondensator lädt)
Hat das schonmal jmd versucht?
Oder ist mit der passenden Stromversorgung der parasitäre Strom gering 
genug als dass das keinen Sinn mehr machte?

'sid

von sid (Gast)


Lesenswert?

und ja loop geht kürzer:
1
void loop() 
2
{
3
  cli();
4
  if(c_wdt == 0)
5
  {
6
    //warten auf telegram
7
    //
8
    //
9
    //
10
    // wie auch immer
11
    WDTCSR = 1<<WDP0 | 1<<WDP3; // 8sek
12
  }
13
  else if(c_wdt == 1) // 2sek sleep
14
    WDTCSR = 1<<WDP0 | 1<<WDP1 | 1<<WDP2;
15
  else if(c_wdt == 2) // 4sek sleep
16
    WDTCSR = 1<<WDP3;
17
  sei();
18
  enterSleep();
19
20
}
ich wüsste jetzt nicht was gegen das ändern des prescaler zur Laufzeit 
spricht;
aber irgendwie hab ich das Gefühl mir beisst gleich einer in den 
Nacken...

naja..

'sid

von Rene F. (elv)


Lesenswert?

Hallo Ernst,

danke für den Hinweis ich verwende auch das example der Libary.
Habe auch versucht in der Datei TempHygroTX868.cpp die Pausenzeit 
anzupassen.

int TempHygroTX868::getPause() {
  return 185;
}

Jedoch empfange ich immer nur von 100 Sendungen nur 10. (ca.10%)
Obwohl die zurückgemeldete Pausenzeit 185 konstant ist?
Denke die Ursache ist der Watchdog-Timer?
Ich habe auch gelesen das die Watchdog Oscillator Frequency Temperatur 
abhängig ist.

LINK:
https://thecavepearlproject.org/2019/02/25/no-parts-temperature-measurement-with-arduino-pro-mini-to-0-005c-or-better/

Die Raumtemperatur ist aber im Versuchsraum 24°C konstant?
Trotzdem danke!

von Manfred (Gast)


Lesenswert?

Rene F. schrieb:
> Obwohl die zurückgemeldete Pausenzeit 185 konstant ist?
> Denke die Ursache ist der Watchdog-Timer?

Nicht fragen, selbst messen!

Baue Dir ein Progrämmchen, was Deinen µC schlafen legt, per 
Watchdogtimer aufwacht, einen Zähler erhöht und nach xx Zyklen eine LED 
anknipst. Du setzt Dich mit der Stopuhr daneben - und kommst zu dem 
Ergebnis, dass der AT328-Watchdogtimer total beschissen ungenau ist, 
selbst im Haus bei fast konstanter Umgebungstemperatur.

Wie Dir schon gesagt wurde: Du musst mit viel Reserve frühzeitig 
aufwachen und auf den Empfang warten. Willst Du das nicht, muß ein 
qualitativ hochwertiger Quarz her - wobei Dir niemand garantiert, dass 
die Intervalle des Senders präzise sind.

von sid (Gast)


Lesenswert?

Rene F. schrieb:
> Jedoch empfange ich immer nur von 100 Sendungen nur 10. (ca.10%)
> Obwohl die zurückgemeldete Pausenzeit 185 konstant ist?
> Denke die Ursache ist der Watchdog-Timer?

Ich glaub du müsstest mal den vollständigen Code anhängen;
der watchdog timer ist sooo unpräzise nicht;
(man muss ihn halt einmal messen)

UND man darf nicht Pause mit Intervall verwechseln ;
eine 120 sekunden Pause kann 130 sekunden intervall bedeuten
(im beispiel hat skaringa deswegen)
1
/*
2
 * Interrupt service routine triggered by watchdog.
3
 */
4
ISR(WDT_vect)
5
{
6
  // Watchdog oscillator freq is about 116 kHz
7
  // at 3 V and 25 °C
8
  // Therefore time between interrupts is
9
  // 1,048,576 / 116,000 = 9.039 seconds.
10
  // So decrement the transmission timer by this value.
11
  nextTxTimer -= 9;
12
}

stehen.. also 9 sekunden für seinen 8 sek watchdog timer
und die zieht er von der Pause ab, damit er auf sein vordefiniertes 
Intervall kommt, was er verwirrenderweise "Pause" nennt.

Und mMn wird bei Dir das Problem ähnlich gelagert sein.

'sid

von Peter D. (peda)


Lesenswert?

Rene F. schrieb:
> int TempHygroTX868::getPause() {
>   return 185;
> }
>
> Jedoch empfange ich immer nur von 100 Sendungen nur 10. (ca.10%)
> Obwohl die zurückgemeldete Pausenzeit 185 konstant ist?

Was soll der Quatsch?
return 185; liefert immer 185 zurück.
Es wird nirgends die Zeit gemessen.

Ohne Schaltplan und kompletten Quelltext läßt sich Dein Fehler nicht 
finden.

von sid (Gast)


Lesenswert?

Peter D. schrieb:
> Was soll der Quatsch?
> return 185; liefert immer 185 zurück.
> Es wird nirgends die Zeit gemessen.

Zu seiner Ehrenrettung:
"wird eh nicht!"

der Originalcode sieht so aus:
1
void TempHygroTX868::setAddress(byte addr) {
2
  this->addr = addr;
3
}
4
....
5
int TempHygroTX868::getPause() {
6
  return 177 - addr;
7
}

solange man also an der addresse nicht rumspielt,
ändert sich da auch an der Pause nix.

mooment, wir reden doch von Öttes:
https://github.com/skaringa/TempHygroTX868/blob/master/TempHygroTX868.cpp
, oder??

'sid

von Peter D. (peda)


Lesenswert?

sid schrieb:
> der Originalcode sieht so aus:

Warum zeigt er nicht endlich mal den verdammten vollständigen echten 
Code?

sid schrieb:
> mooment, wir reden doch von Öttes:

Keine Ahnung, woher soll man das auch wissen?

von Rene F. (elv)


Lesenswert?

Hallo,
danke an alle die mir Ratschläge gegeben haben, sorry konnte aus 
beruflichen Gründen leider nicht alle Beiträge beantworten es waren 
einfach zu viele und teilweise sehr technisch.

Habe folgende Lösung gefunden:

Habe den ebay billig DC Converter Boost Step up Down 0.9V/3.3V getauscht 
auf einen Spark Fun NCP1402.

Strommessung:
Programmbetrieb 5,9 mAh (7,3s) delay(7300)
Sleepbetrieb 0,036 mAh (167s)
Sendebetrieb 20mA (s)

LINK:
https://github.com/skaringa/TempHygroTX868/blob/master/TempHygroTX868.cpp

Quellcode NEU:
#include <TempHygroTX868.h>
#include <Wire.h>
#include <SparkFunHTU21D.h>

#include <avr/sleep.h>
#include <avr/power.h>
#include <avr/wdt.h>

HTU21D htu;
TempHygroTX868 tx;

volatile int nextTxTimer;

#define LED 13
#define SWITCH 7

void setup()
{
#ifdef DEBUG
  Serial.begin(9600);
  Serial.println();
  Serial.println("Address\tHumidity (%)\tTemperature (C)");
#endif

  htu.begin();
  tx.setup(5, TempHygroTX868::PROT_V12);
  pinMode(LED, OUTPUT);

  nextTxTimer = 0;

  MCUSR &= ~(1<<WDRF);
  WDTCSR |= (1<<WDCE) | (1<<WDE);
  WDTCSR = 1<<WDP0 | 1<<WDP3;
  WDTCSR |= _BV(WDIE);
}

void loop()
{
  if (nextTxTimer <= 1) {

    nextTxTimer =20; // nextTxTimer =20=167,0sek=(real 19x) a 8,8s WDT
    byte addr = 4; // Sensoradresse

     wdt_disable(); // Watchdog timer abschalten
   delay(7300); // 7,3s warten (7300= 174,3sek) 10% Ausfälle 10x5min=9 
Empfang OK

   tx.setAddress(addr);
   sendData();
   wdt_enable(); // Watchdog timer einschalten
  }

  pwrDownSleep();
}

void sendData()
{
  digitalWrite(LED, HIGH);
  float humidity = htu.readHumidity();
  float temperature = htu.readTemperature();

#ifdef DEBUG
  Serial.print(humidity);
  Serial.print("\t");
  Serial.println(temperature);
#endif


  if (humidity < 900 && temperature < 900) {
  tx.send(temperature, humidity);
  }
  digitalWrite(LED, LOW);
}

ISR(WDT_vect)
{
  nextTxTimer -= 1;   //WDT 1x 8.8sek Stoppuhr bei 3.3V ~ 25°C
}

void pwrDownSleep()
{
  byte adcsra = ADCSRA;
  ADCSRA = 0;
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
  cli();
  sleep_bod_disable();
  sei();
  sleep_cpu();

  sleep_disable();
  power_all_enable();
  ADCSRA = adcsra; /
}

void wdt_enable() // Watchdog timer einschalten
{

  MCUSR &= ~(1<<WDRF);
  WDTCSR |= (1<<WDCE) | (1<<WDE);
  WDTCSR = 1<<WDP0 | 1<<WDP3;
  WDTCSR |= _BV(WDIE);
}

Es ist zwar nicht professionell, jedoch es funktioniert.
Der Watchdog Timer hat ca. 8,8s laut Stoppuhr bei 22-25°C Raumtemperatur 
und einer Konstant Spannung von 3,3V. (deswegen auch der DC Converter)

19x nextTxTimer WTD durchlaufen ergibt 167,2s, den Watchdog timer 
abschalten, ein nicht so schönes delay(7300) 7,3s ergibt in Summe 174,5s 
ohne der Sende-Zeit. Telegramm senden Watchdog Timer einschalten 
wdt_enable() und zurück im Powersleepmodus pwrDownSleep()
und if (nextTxTimer <= 1) 19x nextTxTimer durchlaufen usw.

Von 37 Empfangsabfragen (a 5min) wurden 35 empfangen passt.
Danke noch an alle für die Hilfe und Inspiration.

LG
René

Bitte 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
Noch kein Account? Hier anmelden.