Selbstbau Funkthermometer 433Mhz

[bismosa]

Hallo!

Schande auf mein Haupt. Das habe ich wirklich übersehen.
Ich hasse es, wenn meine Tochter "aber" sagt, aber 20MHz ist für Batteriebetrieb doch ein sehr starker Stromfresser? Lt. Datenblatt bei 5V knapp 12mA und bei 8MHz kanpp 6mA...macht aber wohl bei einer Laufzeit von wenigen Sekunden vielleicht nicht zu viel aus...

Ich hatte gestern Abend noch viel rumprobiert. Nachdem ich da meinen Fehler noch nicht gefunden hatte, habe ich angefangen die Vorlage etwas zu verändern.
1.) Fuses: E:FF, H:DF, L:E2 (8 MHz, Divide clock by 8 abgewählt)
2.) Ich nutze jetzt die DHT lib von Rob Tillaart (https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTlib)
3.) Ich nutze noch die Platine vom Digispark, daher habe ich an Pin1 noch eine LED, die ich kurz aufblitzen lassen, wenn der DHT22 ausgelsen wird
4.) Meldet der DHT einen Fehler wird 10x ausgelsen und erst dann der Fehlerwert gesendet (wenn mein Handy in der Nähe ist habe ich öfter mal Checksum Error...beim nächsten Versuch wird aber ordnungsgemäß übermittelt. Vielleicht liegt es auch an dem dünnen Jumperdraht.
5.) Um eine Batterieanzeige zu bekommen nutze ich derzeit den "SystemStatus"  (https://github.com/cano64/ArduinoSystemStatus)
6.) Wenn ich den Sendepin als Input definiere, fängt mein Sender an ein durchgehendes Signal zu senden. Das muss ich nochmal prüfen...

Noch offen:
1.) Batterieanzeige testen, Genauigkeit?
2.) Überprüfen, wie sich der Stromverbrauch verhällt und diesen optimieren
3.) Testen, ob es vielleicht auch mit 1MHz (also mit gesetztem "Divide clock by 8") noch funktioniert und ob sich das auf den Stromverbrauch auswirkt
4.) Spannungsversorgung mit 1x oder 2x AA Batterien / StepUp  (Messen, was optimaler ist)
5.) Power-LED auslöten

Die noch offenen Punkte werde ich abarbeiten, wenn die Bestellte Hardware eintrifft. Das wird wohl noch etwas dauern.
Meinen aktuellen Zwischenstand habe ich mal angefügt.

Vielen Dank für die Hilfe und auch die Vorlage hier! Wenn ich soweit bin, werde ich nochmal genauere Schaltpläne und das fertige Programm hier posten.

Gruß
Bismosa

[Groej]

Hallo an alle,

ich versuche seit einiger Zeit das Projekt hier aus diesen Thema (siehe ZIP Datei ) auf den Attiny85 zu bekommen. Ich mache das mit Arduino IDE auf und bekomme schon beim Sketch prüfen Fehlermeldungen (siehe Bild ).
Geht das gar nicht Arduino IDE? Ich wollte es dann weiter mit einen Arduino Nano als ISP auf den Attiny85 brennen aber soweit komme ich gar nicht wegen der Fehler beim Sketch prüfen.
Bin für jeden Tipp dankbar.

Danke

Gruß
Jörg

[bismosa]

Hallo,
das Problem hatte ich auch...
Ich habe die Kommentare alle entfernt, den gesamten Text markiert in Notepad++ die Zeilenenden in Unix konvertiert...und dann ging es 

Gruß
Bismosa

[Groej]

Hallo,

danke für den Tipp werde ich die Tage testen.

Gruß

Jörg

[Groej]

Hallo,

so habs doch gleich probiert. Also die Kommentare zu entfernen hat gereicht. Habs auch schon hochgeladen mit dem Arduino Nano als ISP. Kanns leider nur nicht testen. Muß erst in den Garten fahren weil da der Raspi mit FHEM und dem Signalduino ist. Hoffe das Teil läuft auf anhieb.

Danke

Gruß

Jörg

[bismosa]

Hallo,

meine Hardware ist nun endlich da. Daher konnte ich nun endlich weiter testen.
Mein Versuchsaufbau ist identisch mit dem Schaltplan https://forum.fhem.de/index.php?action=dlattach;topic=52755.0;attach=53190;image allerdings mit einem DHT22.

Mein grobes Ziel ist es:
- 1 Messwert pro Minute
- ca. 1 Jahr Batterielaufzeit (am liebsten mit 1xAA oder 2xAAA...realistisch wird aber eher nur 2xAA möglich werden.)

Daher habe ich jetzt erst einmal den Verbauch versucht zu messen. Leider ist mein Multimeter nicht schnell genug...aber es gibt schon mal "grobe  Richtwerte".
Da beim Senden kurzzeitig mehr verbraucht wird, bilde ich einen groben Schnitt.
Hier meine Messergebnisse:

Code Auswählen Erweitern


Gerechnet wurde mit https://oregonembedded.com/batterycalc.htm
Annahmen:
Laufzeit pro Mess/Sendevorgang: 3000ms
Obere Reihe: 1 Wert pro Minute
Untere Reihe: 1 Wert alle 5 Min.
Es wird bei dem Rechner mit einem Verlust von 15% durch Selbstentladung der Batterie gerechnet!
Es wurde nicht berücksichtigt, das durch eine leerer werdende Batterie der Strombedarf (insbesondere beim StepUp) ansteigt

Standby [mA] Lesen/Senden [mA] Lebensdauer Capacity rating of battery (mAh)
1,5V/StepUp 0,09 30 55,84 Tage 0,15 Jahre 2500
0,09 30 227,56 Tage 0,62 Jahre 2500
3V/StepUp 0,03 15 113,73 Tage 0,31 Jahre 2500
0,03 15 492,72 Tage 1,35 Jahre 2500
3V/StepUp CR2032 0,03 15 10,92 Tage 0,03 Jahre 240
0,03 15 47,3 Tage 0,13 Jahre 240
3V CR2032 0,023 5 31,27 Tage 0,09 Jahre 240
0,023 5 116,81 Tage 0,32 Jahre 240
3v CR2450 0,023 5 75,56 Tage 0,21 Jahre 580
0,023 5 282,28 Tage 0,77 Jahre 580


Eigentlich fast selbsterklärend. Mein erstes Fazit daraus ist:
- Das reicht für meine Anwendung noch lange nicht. Da muss noch einiges Optimiert werden
- Der Standby-Verbrauch von 0,09mA ist m.E. gering genug um hier mit einem StepUp arbeiten zu können. Nur im Standby sollte eine AA Batterie 983 Tage durchhalten.
- Wichtig ist der Verbrauch im Betrieb. Die Laufzeit zu verkürzen bringt am meisten!
- Durch den StepUp ist es möglich die Batterien komplett bis zum Ende (0,9V) zu verwenden.

Ich frage mich, wie die Billigen Baumarktthermometer es schaffen mit 2 AAA Batterien eine Laufzeit von über 1 Jahr zu realisieren und dabei auch einen Messwert pro Minute senden...

Hier ist übrigens ein ähnliches Projekt: https://crycode.de/diy-funk-wetterstation-mit-dht22-attiny85-und-radiohead

Ich werde mir jetzt die Software nochmal genauer anschauen müssen. Mal schauen, wie sich das optimieren lässt.
@juergs
Du hast in deinem Sketch

//--- The sensor can only be read from every 1-2s, and requires a minimum
//--- 2s warm-up after power-on.
LaCrosse.sleep(2);   //--- two seconds, no deep sleep

Woher kommt diese Wartezeit? Weder im Datenblatt noch in anderen Beispielen konnte ich dies finden.

Ist die Wartezeit von 1sek. zwischen dem Senden von Temperatur und Luftfeuchtigkeit wirklich nötig?

Das werde ich als nächstes testen...

Gruß
Bismosa

[juergs]

@juergs
Du hast in deinem Sketch Woher kommt diese Wartezeit? Weder im Datenblatt noch in anderen Beispielen konnte ich dies finden.
Ist die Wartezeit von 1sek. zwischen dem Senden von Temperatur und Luftfeuchtigkeit wirklich nötig?
Das werde ich als nächstes testen...
Gruß
Bismosa

Hallo bismosa,
Die Wartezeit ist empirisch...
Ich habe hier in meinem Umfeld ziemlich viele 433MHz-Sender. Z.B. 2 Stück, die im 10Sek-Rythmus mehr als 10 Repetitions des Telegramms senden.
Du kannst Dir vorstellen, dass sich da einige Telegramme einfach gegenseitig überlagern und durch die "Störung" nicht ankommen,
dann gilt auch das Recht des Stärkeren ...
Hatte auch versucht, die Wartezeiten random zu gestalten um eine Lücke bzw. ein Durchkommen des Sensorwertes zu ermöglichen.
Wenn Du ca. 10 Sensoren über dieses Protokoll anbindest (z.B. Bodenfeuchte für jeden Blumentopf  ) wird es interessant.

Um die Lebensdauer der Batterie zu schonen, kannst Du auch noch die Sendeleistung berücksichtigen, die sind von Sendemodul zu Sendemodul sehr unterschiedlich.
D.h. mit der Auswahl des Moduls beeinträchtigt man auch die Batterie-Lebensdauer kommt aber u.U. nicht so weit.
Die 9 µA  waren bei mir auch realistisch während des SendeImpulses ....
Andererseits muss man nicht bei sich langsam verändernden Messwerten alle 20 Sekunden einen Wert senden,
da reichen 10 Minuten auch aus.

[CatWeazle]

Hi Leutz,

nur zum Verständnis, das hier verwendete LaCrosse Protokoll wird doch auch vom SignalDuino unterstützt, richtig?

Einen Signalduino mit RXB6 433 Mhz Superheterodyne Empfänger habe ich, dann könnte ich mir dieses interessante Projekt auch mal vornehmen

Beste Grüße
Mike

[juergs]

Es schein mehere Synonyme für "LaCrosse Protokol" zu geben.
Hier ist das "CUL_TX" Protokoll auf 433MHz und OOK gemeint.
Sollte also mit der aculw normalerweise gehen, wenn es dort in die Firmware mit
compiliert worden ist ... (gilt für CUL - CC1101)

:FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT::OREGON::Hideki::SD_WS07:

[CatWeazle]

Schade, hätte gerne mitgespielt

Trotzdem ein sehr interessantes Projekt, ich sollte mir so einen 433mhz Cul basteln.

Grüße
Mike

[juergs]

Das hast Du falsch verstanden, der Signalduino sollte gehen ... 

[CatWeazle]

Hallo juergs,

danke für die Info, dann werde ich mir den ATtiny 85 besorgen.
aber hatte ich nicht auch gelesen, dass zum Testen eine Arduino Version der Software existiert ?!?!?

Grüße
Mike

[juergs]

Ja, hier: @github.com 

[CatWeazle]

Hallo juergs,

danke für Link, aber ich hatte schon deinen Download auf Seite zwei (LaCrosse_Nano_Dallas_4Fach.zip) heruntergeladen und auf einen UNO losgelassen.

Funktioniert aber nicht mit meinem Signalduino (RXB6 433 Mhz Superheterodyne Empfänger)

Der Sketch scheint schon zu funktionieren, im Ser.Monitor sehe ich .....

Code Auswählen Erweitern

Hello from NANO ...
SensorID: 105 First: 23.19
SensorID: 106 Second: 0.00
SensorID: 107 Third: 0.00
SensorID: 108 Fourth: 0.00
Pause-Delay (Rand): 34816


In gqrx (software defined radio receiver) kann ich sehen und hören das Daten gesendet werden.
Aber mein SingnalDuino empfängt keine Daten!

Code Auswählen Erweitern

READINGS:
     2017-02-26 19:50:51   cmds            V i R t X F S P C G
     2017-02-26 19:50:35   config          MS=1;MU=1;MC=1
     2018-01-03 16:31:03   ping            OK
     2018-01-07 15:42:21   state           opened
     2018-01-07 15:42:21   version         V 3.3.1-dev SIGNALduino - compiled at Jan  3 2017 23:59:32
   keepalive:

Grüße
Mike

[juergs]

Ich kenne mich mit dem Nicht-CC1101 nicht so aus, aber möglicherweise kannst Du das Protokoll noch hinzukomplieren?

2017-02-26 19:50:51   cmds            V i R t X F S P C G