Projekt: Ich baue gerade eine Funk-Wetterstation, weil meine alte den Geist aufgegeben hat, die käuflichen mir nicht 100% gefallen und weil Maker halt ;) Der grobe Aufbau kann im Anhang "Weather-Station-and-Sensor-Diagram.png" angesehen werden. Die Basisstation soll mit einer (theoretisch) unbegrenzten Anzahl von eingebundenen Funksensoren erweitert werden. Dazu habe ich das Funkmodul RFM69W-868S2 ausgewählt. Dieses nimmt mir sehr viel Arbeit ab (Paket), aber "leider" nicht alles (Adressierung). Die RFM69 sind so konfiguriert, dass sie über den Interrupt-Pin den Mikrocontroller aus seinem Schlafzustand holen und dieser dann die eingetroffenen Daten per SPI vom Funkmodul abholt. Da dieser Fall nur bei der Basisstation und nicht bei den Wettersensoren vorkommt, gehen die Funkmodule der Wettersensoren nach der Aussendung ihrer Wetterdaten einfach in den Tiefschlafmodus (Wettersensor) anstatt dauerhaft zu lauschen (Basisstation). Damit sich bei der Basisstation nicht alles aufstaut oder anders ausgedrückt die Wettersensoren nicht alle zur gleichen Zeit die Frequenz "lahmlegen", senden die Funkmodule zwar in periodischen Abständen, diese sind aber um ± wenige Sekunden für jede Aussendung individuell zufällig versetzt. Ausgenommen sind Alarme (Temperatur-/Luftfeuchtigkeits-/Luftdurck-/Helligkeitsschwelle), welche immer sofort ausgesendet werden. Basisstation und Wettersensor müssen gepaart werden. Die Basisstation nach eine Frequenzsuche im (erlauben) Band und wählt eine Frequenz mit wenig Nutzung aus. Beim Paaren sendet die Basisstation auf ihrer Frequenz ein "Paarungssignal" aus. In der Zeit des Paarens macht nun der Wettersensor seinerseits eine Frequenzsuche nach dem Paarungssignal und quittiert die Paarung nachdem die Basisstation das Paarungssignal deaktiviert hat und auf den eingehenden zu paarenden Wettersensor lauscht. Beide Partner speichern sich die Frequenz und die Adresse des Partners lokal in ihrem nichtflüchtigem Speicher. Nun bietet der RFM69 ja keine RF-Adressierung für die Funkmodule, wie es beispielsweise bei Zigbee oder Z-Wave der Fall ist. Ich muss eine Adressierungslogik also in Software im Mikrocontroller nachbauen. Das Funkmodul selbst leitet, unabhängig was für eine Übertragung hereinkommt, alles an den Mikrocontroller weiter und weckt diesen dadurch immer wieder auf. Lösung zur Diskussion Ich habe mir also gedacht, dass ich für die Adressierung im MCU einfach die MCU-Seriennummer nehmen kann. Ein Ablauf könnte wie folgt aussehen: 1. Wettersensor überträgt Wetterdaten unter seiner Adresse 0xBEEF0002. 2. Basisstation empfängt Übertragung, extrahiert die Sendeadresse 0xBEEF0002 und vergleicht diese mit seiner Liste der bekannten/gepaarten Wettersensoren, findet sie dort und verarbeitet die Wetterdaten. Der offensichtliche Nachteil ist hier, dass die MCU "permanent" aufgeweckt werden muss. Eine andere Lösung, welche ich aber nur fix im Kopf habe, ist die AES-Verschlüsselung zu nehmen. Wenn ich das richtig verstehe, dann würde das Funkmodul keinen Interrupt schicken, die MCU also nicht aufwecken, wenn der Stream nicht dekodiert werden kann. Als "Passwort" könnte ich hier die MCU-Seriennummer der Basistation nehmen. Beim Paaren muss dann natürlich ohne AES gearbeitet werden. Gibt es noch eine andere Lösung oder Optimierungen an die aufgezeigten? Das hier ist mein erstes RF-Projekt. PS: Da es hier um reine nicht-HF-Implementierung geht, habe ich es auch nicht im "HF, Funk und Felder"-Forum gepostet sondern hier.
Angehängte Dateien:
:
Bearbeitet durch User
Sören K. schrieb: > Nun bietet der RFM69 ja keine RF-Adressierung für die Funkmodule, wie es > beispielsweise bei Zigbee oder Z-Wave der Fall ist. Ich muss eine > Adressierungslogik also in Software im Mikrocontroller nachbauen. Das > Funkmodul selbst leitet, unabhängig was für eine Übertragung > hereinkommt, alles an den Mikrocontroller weiter und weckt diesen > dadurch immer wieder auf. Vielleicht verstehe ich dich falsch, aber du hast beim RFM69 die Möglichkeit des "address filtering", kannst also jedem Modul seine eigene Adresse geben. Die muss in den gesendeten Daten vorkommen, damit es zu einem erfolgreichen Datenempfang kommen kann. Dazu braucht es keinen Mikrocontroller, das regelt der Packet Handler des RFM69.
Angehängte Dateien:
-
2018-03-19_10-42-48.jpg
100 KB -
2018-03-19_10-44-40.jpg
81 KB
hört sich einfach an, ich baue gerade etwas ähnliches und habe auch schon viel Zeit da rein gesteckt. Man könnte das einfach machen und ein Funk-Aussenthermometer bei eBay kaufen und mit einem Funk-USB Stick die Daten in FHEM oder ähnlichem einsammeln, aber ich finde auch das ist etwas praktisches zum Üben. Die RFM69 benutze ich auch, mit der Lib von LowPowerLabs. Da wird auch die von Felix genannte Adressierung von Nodes in einem Netz benutzt, das macht die Sache eigentlich recht einfach. Da gibt es ein Byte für die NetworkID und ein Byte für die NodeID. Es gibt auch einen 'promiscuous mode', da ist der Filter aus und der Empfänger hört alles. Mein Empfanger ist einfach ein Modul auf einer passiven Adapterplatine auf einem Raspberry, der hat eine SPI und kann das Modul direkt bedienen. Die Daten werden über ein MQTT Gateway ausgetauscht, das macht die Sache sehr universell und ich kann auch ESPs einbinden die direkt MQTT sprechen können. Die Sender sind mit LPC812 (Cortex-M0) gebaut, brauchen im Ruhezustand 1,2 µA und wecken sich selber auf um kurz zu Senden und stellen sich dann wieder tot. Der Empfänger am RaspPi hat Strom aus der Steckdose, da brauche ich den Aufwand mit dem Schlafen nicht. Die Adresse ist bei mir noch fix im Code, aber besser wäre da noch einen Mechanismus einzubauen mit dem neue Nodes eine Adresse vom Master bekommen können. Ich habe noch zwei Buttons auf dem Board, wenn nach dem Aufwachen einer gedrückt ist wollte ich ein Config Paket anfordern, in Empfang gehen und auf ein Config Paket warten. Da kann zB die Adresse, Sendeintervall und andere Parameter drinstehen die dann im Flash gespeichert werden. Hoffe da waren für dich nützliche Anregungen drin. Platinen habe ich noch übrig, die waren erst für einen PIR Sensor ausgelegt und da muss noch was geflickt werden, die gebe ich bei Interesse kostenlos ab.
Felix P. schrieb: > du hast beim RFM69 die Möglichkeit des "address filtering", kannst also > jedem Modul seine eigene Adresse geben. Die muss in den gesendeten Daten > vorkommen, damit es zu einem erfolgreichen Datenempfang kommen kann. > Dazu braucht es keinen Mikrocontroller, das regelt der Packet Handler > des RFM69. Wow, da habe ich echt das falsche Manual gelesen m( ... Danke für den Nackenschlag. Johannes S. schrieb: > Die Sender sind mit LPC812 (Cortex-M0) gebaut, brauchen im Ruhezustand > 1,2 µA und wecken sich selber auf um kurz zu Senden und stellen sich > dann wieder tot. Nach dem was ich aus dem Datenblatt entnehme soll der doch nur folgendes verbrauchen: * Transmit: 45 mA * Listening: 16 mA * Sleep: 0.1 µA Wie hast du die 1,2 µA (was ja das 10-fache und mehr ist) ermittelt? *PS: Ach du meinst den IDLE und nicht denn SLEEP Mode. Alles klar...*
:
Bearbeitet durch User
Angehängte Dateien:
-
2018-03-19_10-42-48.jpg
100 KB -
2018-03-19_10-44-40.jpg
81 KB -
chart_4_.png
41 KB
Der Gehäuseentwurf ist gestern fertig geworden, ich hänge mal Bilder an. Die SW ist auch noch eine Baustelle, die Daten möchte ich erstmal im PC haben und per Webbrowser anzeigen, ein Weiterleiten an einen µC mit Display geht aber auch.
Sören K. schrieb: > Wie hast du die 1,2 µA (was ja das 10-fache und mehr ist) ermittelt? knapp 1 µA braucht der Self Wakeup Timer, das ist ein 10 kHz RC Oszillator der einen 32 Bit Zähler taktet, bei Überlauf wird geweckt. Der Rest ist Funkmodul im Sleep und SHT15 Sensor. Das Stromsparen war nicht so einfach weil der LPC im DeepPowerDown nahezu alles abschaltet, auch PullUp Widerstände. Damit waren die Pins hochohmig und Funkmodul und SHT ziehen dann mehr Strom, da musste ich PullUp Rs nachträglich reinflicken.
Johannes S. schrieb: > Der Gehäuseentwurf ist gestern fertig geworden, ich hänge mal Bilder an. > Die SW ist auch noch eine Baustelle, die Daten möchte ich erstmal im PC > haben und per Webbrowser anzeigen, ein Weiterleiten an einen µC mit > Display geht aber auch. Dein Gehäuseentwurf sieht gut aus. Du planst es mit (Plexi-)Glas vorne? Auch eine nette Idee :) Mein Gehäuseentwurf ist noch nicht mal angefangen; und würde einem Design von den Baumarkt-Außensensoren nahe kommen (kleiner, schmaler weißer Kasten mit Luftschlitz).
Johannes S. schrieb: > Sören K. schrieb: >> Wie hast du die 1,2 µA (was ja das 10-fache und mehr ist) ermittelt? > > Der Rest ist Funkmodul im Sleep und SHT15 Sensor. Ah, es ist die Aufnahme des "Gesamtsystems" und nicht nur des Funkmoduls. Ich spiele mit dem Gedanken, das Funkmodul (beim Außensensor) einfach per Transistor stromlos zu machen und parallel zur Sensormessung "hochzufahren".
:
Bearbeitet durch User
Sören K. schrieb: > Dein Gehäuseentwurf sieht gut aus. Du planst es mit (Plexi-)Glas vorne? > Auch eine nette Idee :) Danke, ja hatte schon einen Prototypen gedruckt aber jetzt noch ein bisschen nachgearbeitet. Den Deckel kann man auch drucken, aber ich habe dafür auch zum Test auch mal fertigen Plexiglas Zuschnitt bestellt. Dann kann man reingucken und sehen ob das schon ein Insektenhotel geworden ist :) Kleiner ginge auch noch, als Batterie kann man auch gut CR123 nehmen, die haben 3V 1500 mAh und sind mit 17 mm Durchmesser 34 mm Länge recht kompakt. Pollin hat gerade 6 Stück für 10,95 € im Angebot. > Ich spiele mit dem Gedanken, das Funkmodul (beim Außensensor) einfach > per Transistor stromlos zu machen das ist beim RFM69 nicht nötig weil man den ja per SW schlafen legen kann und 0,1 µA sind ja quasi nix an Stromverbrauch. Genauso wie den SHT15 bzw. die besseren Nachfolger weil der schon alt und abgekündigt ist. Ich hatte auch DHT21 gekauft, aber die sind für Batteriebetrieb weniger gut weil die erst ab 3,6 V arbeiten. Da solltest du auch drauf achten das die Komponenten noch mit möglichst kleinen Spannungen auskommen, oder eben Lithium Batterien die eine flache Entladekurve haben.
Angehängte Dateien:
-
psu.png
8,5 KB
Johannes S. schrieb: > Da solltest du auch drauf > achten das die Komponenten noch mit möglichst kleinen Spannungen > auskommen, oder eben Lithium Batterien die eine flache Entladekurve > haben. Bis auf den Luftdrucksensor, der Vin (min) 3V0 braucht, können alle anderen aber mindestens bis zu Vin (min) 2V5. (Siehe Anhang:) Ich nehme drei Lithium Batterien mit 1V5 und 3Ah in Reihe. So sollte das bei einer Gesamtspannung von 4V5 ausreichend Spielraum für den Step-Down Converter geben. Lithium habe ich primär wegen des Temperaturratings gewählt. Energizer MPN 639155 ist mit -40°C bis +60°C geraited. Die mit Kälte am besten Ni-MH Batterien gingen nur bis -20°C. Und selbst wenn man Ni-MH Batterien rein steckt, dann ist die angelegte Gesamtspannung mit 3V6 immer noch ausreichend für den Step-Down Converter. Auch wenn dann nicht mehr viel Spielraum für das "auslutschen" der Batterien bleibt.
Step Down oder Spannungsregler habe ich extra nicht drin, die brauchen ja auch wieder Strom, auch im Leerlauf. Luftdruck hatte ich auch erst überlegt, aber den kann man besser in der Nähe einer Steckdose messen, draussen oder drinnen macht der keinen Unterschied. Da ist es einfacher den aus dem batteriebetriebenen Teil wegzulassen. Und -20°C ist schon ganz schön schattig, da müssen die anderen Komponenten auch mitspielen. Bis -8° hatte ich meine Teile in der kalten Woche draussen und es lief noch. Nur der low power Oszi zum Aufwachen hat eine hauptsächlich Temperaturabhängige Toleranz von +/- 40%, da kann man schon am Sendeintervall die Temperatur ablesen :) Aber ob der nach 30 oder 40 Sekunden sendet oder ein paar Pakete verloren gehen stört für einen Langzeittrend ja nicht.
Johannes S. schrieb: > Step Down oder Spannungsregler habe ich extra nicht drin, die brauchen > ja auch wieder Strom, auch im Leerlauf. Stimmt, aber die überwiegende Anzahl der Komponenten verträgt maximal 3V6 und nicht 4V5 (Lithium). Und bei 3x Ni-MH bin ich bei 3V6, der Sensor (genauer die Batterie) funktioniert dann aber nicht bei unter -10°C. Alle Komponenten sind übrigends mindestens von Tmin -40°C bis Tmax +80°C geraited. Ich fühle mich gerade wie ein bockiges Kind... Ich will die Lithium (Temperatur), aber dann habe ich Loss mit dem Converter - das ist doof. Aber wenn ich Ni-MH nehme komme ich zwar bei 3V6 raus, habe aber nur 0V6 Spielraum maximal bist die RF-Strecke ausfällt. Beides ist ziemlich - meh. Dilemma eines jeden Entwicklers für batteriebetriebene Geräte, vermutlich :D PS: Wir hatten gerade im "Frühling" Temperaturen von unter -17°C...
:
Bearbeitet durch User
In einem Sensor im Gewächshaus habe ich auch Lithium Batterien drin, die Ansmann Industrial AA, die haben etwa die gleichen Daten wie deine Energizer. Im Leerlauf hatte ich 3,6 V gemessen, die sind damit schon am oberen Limit. Nach der Entladekurve sind die aber schnell runter und halten dann lange die 3 V, sollte also ideal sein. Bei der Suche nach der Entladekurve habe ich diese Seite gefunden: https://www.tecchannel.de/a/batterie-test-kaelte-reduziert-leistung-um-bis-zu-40-prozent,2023671,5 Mit der Lithium Batterie sollte also für ein paar Jahre Ruhe sein. Das gleiche Board mit LPC812/RFM69 und PIR Modul braucht etwas über 50 µA und das läuft mit einfachen AA AlkaliMangan jetzt auch schon über ein Jahr. Wenn die Batteriespannung unter eine Warnschwelle fällt wird auch eine 'lowBatt' Message gesendet. > PS: Wir hatten gerade im "Frühling" Temperaturen von unter -17°C... ja, die wollte ich auch messen, hatte das aber nicht rechtzeitig fertig bekommen.
Johannes S. schrieb: > Das Stromsparen war nicht so einfach weil der LPC im DeepPowerDown > nahezu alles abschaltet, auch PullUp Widerstände. Damit waren die Pins > hochohmig und Funkmodul und SHT ziehen dann mehr Strom, da musste ich > PullUp Rs nachträglich reinflicken. Wo mußtest du denn noch pull-ups reinflicken? Das Manual erwähnt nur bei RESET- und WAKEUP-pin externe pull-ups im deep power-down mode. Und wie hast du den höheren Stromverbrauch gemessen? In der Größenordnung 1-2 µA ist das sicher schwierig. Oder war der Unterschied so kraß?
Rapunzel schrieb: > Das Manual erwähnt nur bei > RESET- und WAKEUP-pin externe pull-ups im deep power-down mode. Ja, das gilt für den uC, aber die höhere Stromaufname kam hauptsächlich vom RFM. Da habe ich den Eingängen MOSI, clk und select 47k PullUp verpasst. Habe es nicht mehr genau im Kopf, aber Verbrauch lag bei 10-20 uA. Das kann ich noch gut mit dem Multimeter messen. Wenn der uC startet im mA Bereich messen, dann wenn der uC schläft das Messgerät kurzschließen und auf den uA Bereich umschalten und Brücke wieder entfernen.
Ah, verstehe. Ich hatte mir auch das Datenblatt des RFM69 angeschaut. Da gibt es ein "Reference Design". Da sind auch keine pull-ups drin, und power-down-modes sind für das Modul ja eher die Regel als die Ausnahme. Aber: Das Design ist mit einem PIC16F690 als Controller angegeben. Den kenne ich nun sowas von gar nicht. Wenn dessen pins sich im power-down-mode anders verhalten, nützt das bei einem LPC8xx natürlich nix. Also muß ich beim nächsten mal noch eine Ecke weiter denken. Und da du das gemessen hast, wird es wohl so auch stimmen. Faktor 10 höhere Stromaufnahme bzw. 10-20 µA mehr macht bei Batteriebetrieb schon was aus. Wenn man das weiß, ist das schon mal gut und man kann Gegenarbeiten (z.B. Sendeintervall vergrößern, andere Batterie auswählen usw.). Oder externe pull-ups nehmen.
ja, das kommt darauf an wie der µC sich da verhält. Die ATTiny z.B. halten soweit ich weiss im Deep Sleep auch die PullUp gesetzt, der LPC schaltet sich im deep power down komplett ab. Da muss man im Datenblatt in die Tiefe gehen. Aber 3 kleine R sind ja kein grosser Aufwand wenn man es vorher weiss, nur meine Nachverdrahtung mit SMD in Grabstein Stellung sieht abenteuerlich aus :-)
Wie ist es denn im power-down-mode? Der vebraucht nur 200 nA mehr, aber alle Register usw. bleiben erhalten.
Also ich habe das so gelöst: * Jeder Knoten hat eine eindeutige ID, welche richtig lang ist (128 Bit, setzt sich zusammen aus irgendwelchen Sachen, die man aus dem Controller auslesen kann oder einem Zufallscode im EEPROM, je nach Controller) * Diese ID lässt sich mit einem Befehl auslesen, wobei nur der Controller dann auch antwortet, der diese ID selbst hat. Protokoll hier ist minimal, macht nix anderes, als ein Present (mit einem zufälligen zeitlichen Versatz) zu senden und mit einem weiteren Befehl weißt man dem Knoten eine Logische kurze Adresse zu. Mache ich ähnlich, wie bei Dali, nur dass ich die Adresse nicht zufällig erzeuge, dann weiß ich später, welches Modul ich in der Hand habe und kann es mappen. * Die kurze Adresse wird für weitere Kommunikation genutzt. * Kommunikation geht so, dass die Module nach jedem Senden kurz auf Empfang schalten und man hier einen Rückantwortslot hat. Daten werden ca. alle 1-2 Minuten ausgetauscht, mit dem Rückslot kann man das Modul in einen längeren Dauerrecieve-Zustand schicken und dann z.B. Updates o.ä. machen.
Knorpel schrieb: > Wie ist es denn im power-down-mode? Der vebraucht nur 200 nA mehr, aber > alle Register usw. bleiben erhalten Es kommt dann laut Datenblatt aber noch 1µA für den Oscillator des WKT dazu. Aber 1,2 µA mehr sind wohl verschmerzbar. Im power-down bleiben die pins wie gesetzt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.