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
HTU21Dhtu;
5
TempHygroTX868tx;
6
// pin of build-in signal LED
7
#define LED 13
8
9
voidsetup()
10
{
11
// HFS-300 is at data pin 5
12
htu.begin();
13
tx.setup(5,TempHygroTX868::PROT_V12);
14
}
15
16
voidloop()
17
{
18
byteaddress=4;
19
20
digitalWrite(LED,HIGH);
21
floathumidity=htu.readHumidity();
22
floattemperature=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]
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?
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);
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.
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!)
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.
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
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.
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
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.
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.
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.
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)
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.
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.
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 ;-)
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.
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.
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.
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?
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.
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.
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.
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?
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.
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. :-)
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.
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.
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
volatileuint8_tc_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
voidenterSleep(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
voidsetup()
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
voidloop(){
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
elseif(c_wdt==1)// 2sek sleep
48
{
49
cli();
50
WDTCSR=1<<WDP0|1<<WDP1|1<<WDP2;// 2sek
51
sei();
52
enterSleep();
53
}
54
elseif(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
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
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!
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.
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
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.
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:
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?
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é