Hallo ich bin gerade dabei eine Art Wetterstation aufzubauen. Ein externes Modul zum Senden der Temperaturen, Feuchtigkeit usw und ein internes Modul zum Empfang der Daten und der Ausgabe auf ein Display. Nun beschäftige ich mich mit der Funkübertragung und da es ein batteriebetriebens Gerät ist, sollte die Technik so sparsam wie möglich sein. Ich möchte auf jedenfall im 433 oder 868MHz Netz bleiben, da in meiner Umgebung viel WLAN arbeitet. In engerer Auswahl stehen bei mir ZigBit 900 Module von Meshnetics und Funkmodule von verschiedenen Herstellern. Ich kann mich aber überhaupt nicht entscheiden und bitte euch deshalb um Rat. Funkmodule sind ansich sparsamer (rund 10mA TX gegenüber >20mA bei ZigBee), aber ist die Überlegung richtig? Ansich ist ja die Energiebetrachtung am wichtigsten. Ich würde gerne alle 10sec Daten senden. Aber auf was muss ich noch achten? Was sind die Merkmale auf die ich am meisten achten muss? Weiß jemand ob man bei beiden Lösungen eine Art "Wake on Radio" hat? Danke schonmal! Pascal
>da es ein batteriebetriebens Gerät ist, sollte die Technik so sparsam >wie möglich sein. Wegen Ultra Low Power solltest du dir vielleicht auch mal EnOcean anschauen: http://www.enocean.com/de/enocean_module/
Kann mir sonst niemand etwas aus seiner Erfahrung berichten? Hat schon jemand mit Enocean gearbeitet? Gruß, Pascal
Pascal wrote: > Funkmodule sind ansich sparsamer (rund 10mA TX gegenüber >20mA bei > ZigBee), aber ist die Überlegung richtig? Da die Sendezeit sehr kurz ist, ist der Stromverbrauch beim Senden normalerweise eher unwichtig. Der größere Teil der Energie wird bei derartigen Setups oft anderweitig verbraucht. > Weiß jemand ob man bei beiden Lösungen eine Art "Wake on Radio" hat? Wen willst du denn damit wecken? Einen Controller? Die Empfänger verbrauchen bei derartigen Teilen viel Strom, wenn sie aktiv sind (bei 2,4 GHz noch mehr). Daher kann man einen Empfänger, der die ganze Zeit über auf den Kanal hören soll, normalerweise nicht aus einer (kleinen) Batterie betreiben. IEEE 802.15.4 bietet als Kompromiss für derartige Fälle noch beacon-enabled networking, bei dem man versucht, die Einschaltzeit der (batteriebetriebenen) Endknoten zu minimieren.
Das heißt ansich ist es egal ob ich auf ZigBee oder die "normalen" RF Module zugreife? Ich mein ich benötige die Mesh Funktion eigentlich nicht, mir reicht eine P2P Verbindung. Ja ich dachte daran, dass durch einen Impuls vielleicht das Modul erkennen könnte, dass etwas gesendet wird. Aber ich weiß jetzt ob es sowas gibt, eine Art Interrupt eben!
Einfache Peer to Peer Anwendungen koenntest du mit einem AT86RF212 Radio Modul und µracoli (http://uracoli.nongnu.org/) leicht programmieren, die AT86RF212 Module sind zwar noch nicht definiert, werden aber bald im Paket sein. Neben den Zigbits kannst du mal schauen, ob dir die Dresden-Elektronik-Module zusagen: http://www.dresden-elektronik.de/shop/prod78.html Das Problem bei Wakeup-on-Radio ist, dass der Receiver Teil des Radios staendig eingeschaltet sein muss, beim AT86RF212 sind das 9mA. Besser ist wirklich ein zeitlich synchronisiertes Aufwachen oder einer der Knoten ist mains-powered und kann im Permanent-RX-Mode betrieben werden. Der Controller kann natuerlich ueber einen RX-Interrupt geweckt werden, die 9mA fliessen aber trotzdem, so dass sich das Leistungsbudget damit nicht grundlegend verbessert.
Ok, danke schonmal! Ich hab mich auf jedenfall jetzt auf 868MHz festgelegt. Von ZigBee werde ich wohl die Hände lassen, das scheint mir in dem Fall nicht sehr viel zu bringen. Wo kann ich eigentlich finden wie im "Normalfall" Sensornetzwerke betrieben werden? Zum Beispiel die Idee mit der zeitlichen Synchronisation habe ich auch schonmal gesehen, aber mich würde das Thema ansich interessieren. Danke! ;-)
Pascal wrote: > Wo kann ich eigentlich finden wie im "Normalfall" Sensornetzwerke > betrieben werden? Zum Beispiel die Idee mit der zeitlichen > Synchronisation habe ich auch schonmal gesehen, aber mich würde das > Thema ansich interessieren. Naja, leider muss jeder Hersteller da sein eigenes Süppchen kochen, denn gerade der wichtige Aspekt der zeitlichen Sychronisierung im µs Bereich wird von ZigBee überhaupt nicht unterstützt. Bei vermaschten Netzen ist das sowieso kaum möglich. Wir haben ein eigenes schlankes Protokoll auf 802.15.4-2003 Basis entwickelt, was sich sehr gut sychronisieren lässt. Aber eben nur Stern-Netzwerk. Bei NanoNET siehts mit der Sychronisierung schon besser aus, allerfings hat sich das immer noch nicht so recht durchgesetzt. Wohl wegen der extrem hohen Entwicklungskosten.
Bist du Entwickler? Wo arbeitst du denn? Hast du Nachrichtentechnik o.ä. studiert? Ich bin nämlich derzeit bei IBM und mach mein Praxissemester, möchte da aber später nicht bleiben. Mich reizt die HF und die NT viel mehr und das gibt es so in der Form leider nicht ;-)
Ich bin Hardware-Entwickler beim Fraunhofer Institut. Wir haben ein drahtloses Sensornetzwerk gebaut, was sich recht genau synchronisieren lässt, zuverlässige Datenübertragung bietet und dazu noch so wenig wie möglich Energie benötigt. Ist halt nicht so universell wie ZigBee...
Bist du in München? Da war ich nämlich mal zum Vorstellungsgespräch, aber ich wollte dann doch nicht in die Forschung. Das hört sich alles echt toll an! Was für Module habt ihr denn genutzt? Ich bin mir noch nicht ganz schlüssig. Am liebsten würde ich nur einen Receiver für die Innenstation und einen Trasmitter für die Außenstation. Für den Receiver würde ich den micrf221 nehmen (http://www.micrel.com/page.do?page=/product-info/products/micrf221.jsp). Der hat mich jetzt eigentlich überzeugt, aber ich finde keinen geeigneten Transmitter. Den einzigen den sie bei Micrel anbieten mit 868Mhz, der passt mir nicht ganz. Vor allem weil er "nur" -3dbm Sendeleistung hat und das Datenblatt sowas von schwach ist. Die restlichen Transmitter sind für 300-433 MHz ausgelegt.. Hast du vielleicht einen Vorschlag? Ansonsten gefallen mir auch die Transceiver von Amber Wireless, aber ich wollte eigentlich einfache Module, die nicht soviel Schnick-Schnack haben.
wobei der CC2420 im 2.4GHz Band sendet und nicht im 868.3MHz Band, dort gibt es fuer IEEE802.15.4 nur den AT86RF212 von Atmel. Auszerdem, ist der CC2420 nicht mehr zeitgemaesz, er wird vom AT86RF230/AT86RF231 sowohl in der Preformance, als auch durch einen niedrigeren Stromverbrauch geschlagen.
Ja, das ist mir alles klar. Wir brauchen jedoch zwingend den Hardware-SFD-Ausgang. Bei der nächsten Hardware-Version kommt dann wohl der CC2520 rein.
Christian R. wrote: > Ja, das ist mir alles klar. Wir brauchen jedoch zwingend den > Hardware-SFD-Ausgang. Kannste auch mit dem AT86RF231 haben. ;-)
Achso, hat der das mittlerweile? Der 230 hatte ja keinen SFD Ausgang. Muss ich mir mal ansehen, ob der besser ist als der CC2520.
also ATMEL hat ja super Chips! So gute hab ich noch nirgends gesehen und ich hab mir schon verdammt viele angeschaut! Allerdings versteh ich nciht, wieso man die nur in diesem RF Guide anschauen kann. Ich hab nämlich Interesse an dem ATA5824 oder ATA5811, sind schön stromsparend, haben genug Leistung und laufen auf 868Mhz. Aber wieso findet man kein Datenblatt davon? Muss ich mir dieses Allgemeine Datenblatt ankucken und bei der Bestellung dann durchgeben was ich will oder wie läuft das? Danke! P.S.: Die werden alle über SPI angesprochen, ist das eine kompliziert Sache? Wie lang braucht man in der Regel bis man eine Funkstrecke zum Laufen gebracht hat? Gruß, Pascal
Hi, mich wundert das noch niemand die RFM12-Module (sowohl in 433 und 868Mhz Ausführung) vorgeschlagen hat. Also mach ich das mal an dieser Stelle. Bei mir laufen die Dinger recht zuverlässig und kosten auch nur um die 5Euronren. Gruß
Christian R. wrote: (SFD-Pin) > Achso, hat der das mittlerweile? Der 230 hatte ja keinen SFD Ausgang. Naja: er hatte keinen dedizierten Pin dafür. Man konnte den normalen IRQ auf einen input capture interrupt legen, und dann bei RX_START- Interrupt den Timestamp sichern. Beim 231 kann man zusätzlich den RX_START-Interrupt noch auf einen weiteren IRQ-Pin legen. > Muss ich mir mal ansehen, ob der besser ist als der CC2520. Zumindest ist er aus Dresden. ;-)
> Zumindest ist er aus Dresden. ;-) Route Jörg <-> Atmel http://maps.google.de/maps?f=d&saddr=K%C3%B6nigsbr%C3%BCcker%2BStr.%2B61%2B01099%2BDresden&daddr=Hohe+Stra%C3%9Fe+16a.+D-01069+Dresden&hl=de&geocode=&mra=ls&dirflg=w&sll=51.038503,13.721043&sspn=0.010308,0.027895&g=Hohe+Stra%C3%9Fe+16a.+D-01069+Dresden&ie=UTF8&z=14
Big Brother wrote:
> Route Jörg <-> Atmel
Nun, zu Fuß würde ich diese Strecke aber nicht zurücklegen wollen. ;-)
Jörg Wunsch wrote: > Christian R. wrote: > Beim 231 kann man zusätzlich den RX_START-Interrupt noch auf einen > weiteren IRQ-Pin legen. Muss ich mir mal ansehen, speziell was die Latenz und Genauigkeit angeht. >> Muss ich mir mal ansehen, ob der besser ist als der CC2520. > > Zumindest ist er aus Dresden. ;-) Naja. Das ist kein Argument ;) Wir haben noch eine ganze Kiste von Dresden Elektronik Zeugs bei uns rumstehen....leider hatten wir noch keine Zeit weiter, das mal anzugucken...vielleicht komm ich mal dazu.
Christian R. wrote: > Muss ich mir mal ansehen, speziell was die Latenz und Genauigkeit > angeht. Naja, sub-Mikrosekundengenauigkeit haben sie nicht, aber besser als ein Symbol schon. Der Interrupt kommt später als beim CC2x20, meiner Erinnerung nach erst nach dem PHR, während der CC2x20 den Interrupt bereits am Ende des SFD triggert. Auch der AT86RF230 hat den RX_START-Interrupt noch eher getriggert (ähnlich wie Chipcon, nur halt nicht als separaten Pin).
hallo Leute, ich habe auch einer Wetterstation mit Altmega 16 aufzubauen. Ein externes Modul zum Senden der Temperaturen, Feuchtigkeit und druck und ein internes Modul zum Empfang der Daten und Ausgabe auf ein Display. für die Funkübertragung wurde der AT86RF231 bereitgestellt. bis jetzt hatte ich kein erfahrung mit Funkübertragung. kann mir jemand bei der initialiserung und send und empfangsfunktionen(TX.RX) von AT86RF231 hilfen. woran ich achten muss. Grüsse und Danke fürs Lesen
Hi Mark, der RF231 funkt auf 2.4GHz, das Thema gehoert also nicht in diesen Thread. Ein Projekt, das jede Menge Beispielcode zur Low Level Kommunikation mit den AT86RFxxx Transceivern liefert wurde bereits oben in diesem Thread genannt. Ciao Axel
Moin moin ... die Frage ist willst Du große Reichweite ?? >50m ?? dann schließt sich 2.4Ghz nicht unbedingt aus, wird aber aufwendiger. Zum Thema Stromsparen ... der sparsamste ist der 2.4Ghz Transceiver von Nordic. Wir haben ihn als Empfänger auf einen Jahreverbrauch von unter 300mA/h gebracht ... sprich wir haben nicht mehr zur Verfügung bekommen und mussten zusehen wie wir es schaffen. Da hilft nur pollen, und wenn man die Pausen so wählt das das Sendesignal immer ein wenig länger ist bekommt der Empfänger das mit und geht "richtig" an und empfängt. Bei 868Mhz würde ich mir mal Infineon TDA5150, TDK 5116F oder den Atmel T5750 anschauen. Alle drei sind Transmitter wobei der von Atmel der einfachste ist. T5750(5754-434Mhz) - ca.6dBm, 9-10mA, TDK5116F(5110-434Mhz) - 10dBm, 14-18mA, TDA5150(Multifrequenz) - 16-19mA. Und als Empfänger vielleicht den Infineon TDA5210 oder den Atmel AT8201(allerdings 434Mhz). Solltest Du Dir mal anschaun ... Gruß Micha
Mi Gö wrote: > Wir haben ihn als Empfänger auf einen Jahreverbrauch von unter > 300mA/h gebracht ... Was soll das sein? Je länger ich ihn eingeschaltet lasse, um so mehr Strom nimmt er (zu jedem beliebigen Zeitpunkt) auf? Hmm. Ansonsten musst du dazu schon sagen, unter welchem Szenario du die Energiebilanz betrachtest. Da die aktiv schwingenden Schaltungsteile bei diesen Frequenzen am oberen Ende des UHF-Bandes ziemlich viel Strom ziehen, braucht halt auch ein reiner standby-Betrieb mächtig Strom. Wenn man also gezwungen ist, die ganze Zeit ,,zuzuhören'', dann ist's ziemlich Essig mit Strom sparen, egal welcher Hersteller und welcher IC. Dass in deiner 868-MHz-Liste der AT86RF212 fehlt, kann ich mir nur damit erklären, dass du von ihm offenbar nichtmal den Namen und die Eigenschaften kennst...
hallo Axel, kann du mir bitte den Link zu dem Beispielcode zur Kommunikation mit den AT86RF231 Transceivern schicken, wenn möglich den Protokoll. Danke
Jörg Wunsch wrote: > Mi Gö wrote: >> Wir haben ihn als Empfänger auf einen Jahreverbrauch von unter >> 300mA/h gebracht ... > > Was soll das sein? Je länger ich ihn eingeschaltet lasse, um so > mehr Strom nimmt er (zu jedem beliebigen Zeitpunkt) auf? Hmm. > > Ansonsten musst du dazu schon sagen, unter welchem Szenario du die > Energiebilanz betrachtest. Da die aktiv schwingenden Schaltungsteile > bei diesen Frequenzen am oberen Ende des UHF-Bandes ziemlich viel > Strom ziehen, braucht halt auch ein reiner standby-Betrieb mächtig > Strom. Wenn man also gezwungen ist, die ganze Zeit ,,zuzuhören'', > dann ist's ziemlich Essig mit Strom sparen, egal welcher Hersteller > und welcher IC. :) so kommt zu blendenden Bilanzen .. nein Spaß beiseite ... ein Pic18 steuert den nRF24L01. die Annahme waren Telegramlänge: 100bit mindestAnzahl an Telegrammen pro Tag: 10 Reaktionszeit: 1sec. max Jahresverbrauch 300mA war für ein Öffnungssystem .. der Vorteil dieses Chips ist seine extrem schnelle Anschwingzeit .. somit kann man sehr effektiv pollen und kommt rechnerisch auf 237mA im Jahr ... wenn Du vielleicht 2 AAA Akkus mit 800mA nutzt erreicht Du entsprechend mehr ... mann kann an allen Stellen drehen .. Telegramlänge runter .. Reaktionszeit hoch etc. Funktioniert sehr gut :) aber die Reichweite ist halt sehr beschränkt. > Dass in deiner 868-MHz-Liste der AT86RF212 fehlt, kann ich mir nur > damit erklären, dass du von ihm offenbar nichtmal den Namen und die > Eigenschaften kennst... Doch doch ich kenn diesen .. ist aber unattraktiv da zu teuer und keine besonderen Merkmal so das man damit argumentieren könnte .. dazu muss man sagen das wir primär unidirektionale System bauen und nen Receiver einfach günstiger ist. Und es gibt nen einfacheren Transceiver .. TDA5250 von Infineon. Denn kann man sogar so beschalten das man mit nem einfachen I/O senden und Empfangen schalten kann und dann den Datapin entspr. der Richtung nutzt .... Gruß Micha
Mi Gö wrote: > die Annahme waren > Telegramlänge: 100bit > mindestAnzahl an Telegrammen pro Tag: 10 > Reaktionszeit: 1sec. > max Jahresverbrauch 300mA Passt immer noch nicht (300 mA ist eine Stromaufnahme, keine Energieaufnahme), aber an Hand deines anderen Textes deute ich das mal auf 300 mAh um. Worauf bezieht sich dabei die Reaktionszeit? Also: auf was reagierst du denn? Da du von einem reinen Sender ausgehst, wird es ja kaum die Reaktion auf ein empfangenes Funksignal sein. >> Dass in deiner 868-MHz-Liste der AT86RF212 fehlt, kann ich mir nur >> damit erklären, dass du von ihm offenbar nichtmal den Namen und die >> Eigenschaften kennst... > Doch doch ich kenn diesen .. ist aber unattraktiv da zu teuer und keine > besonderen Merkmal so das man damit argumentieren könnte .. Nun, derartige Entscheidungskriterien sollte man auch dazu schreiben. Der Preis dürfte (verglichen an der zu investierenden Arbeit) für den OP bzw. andere Leute mit Einzelstücken eher in den Hintergrund rücken. Eine Massenproduktion ist da sicher was anderes. Vorteilhaft an IEEE-802.15.4-Transceivern ist natürlich die höhere Übertragungs- sicherheit im Vergleich zum einfachen Link, einerseits durch die Modulation selbst, andererseits durch die möglichen Bestätigungen, die dem Absender die Möglichkeit geben, eine misslungene Übertragung sofort zu wiederholen. Je nach Anwendung kann das ja durchaus den höheren Preis für den Transceiver (statt getrennter ICs) rechtfertigen. Kommt hinzu, dass man für Sender und Empfänger den gleichen Code im Controller benutzen kann, kann u. U. auch ein Entwicklungszeit-Vorteil sein.
Doppeltreffer :) jup ich hatte das h vergessen .. es soll natürlich mAh heißen ... und ja .. es ist die Reaktionszeit auf einen Sender .. wovon natürlich das pollen abhängig ist. Dein Einwand bezüglich Transceiver und auch IEEE ist sicher nicht von der Hand zuweisen .. wie gesagt bei uns ist die bidi durchs visuelle erledigt .. "licht geht an oder nicht" .. bei Datenstrecken ist es natürlich immer recht sinnvoll auf Rückantwort zu setzten um alles sicherer zu machen .. allerdings sollte eine solche Sicherheit bei einfachen Wetterdaten nicht unbedingt nötig sein(sofern es nicht eine Tsunamivorhersage ist ;) )und man könnte eine Fehlfunktion auch am Empfänger signalisieren .. zB seit 2h keine Daten LED oder ähnliches. Bei sensiblen Daten würd ich immer den Aufwand betreiben. Zum anderen braucht ein Transceiver meist auch mehr Strom .. was bei Empfänger(meist Netzgebunden) eher uninteressant ist, beim Sender nicht. Der müsste ja immer noch nen Empfangszyklus mit einschalten. Also effektiv ist es sicher erstmal wichtig ein Kopf zu machen wie wichtig ist die Sicherheit auf der Funkstrecke .. dann kann man entscheiden welchen Weg man geht .. wie gesagt wenn ich einfach Licht einschalten will ist es blödsinnig eine Rückmeldung per Funk zu bekommen, ich seh es ja. Ist das Licht aber außerhalb meines Sichtbereiches sieht die Welt schon anders aus ... Gruß Micha
Pascal wrote: > Kann mir sonst niemand etwas aus seiner Erfahrung berichten? > Hat schon jemand mit Enocean gearbeitet? > > Gruß, Pascal Ja, hab ich. Die Frage wäre, wieviele Sensorsignale Du hast und wie genau Du die messen willst. Für Den Sensor der Wetterstation hätte ich jetzt erst mal an STM110 gedacht. Alle 10 Sekunden Übertragen ist aber ziemlich häufig für eine energieautarkte Station. Was vielleicht Sinn macht ist alle 10 Sekunden messen und wenn's sich deutlich geändert hat, dann senden. Alle 10-100 Zyklen mal ein "Hallo ich lebe noch" Senden sollte dann wohl reichen, um zu erkennen, dass der Sensor defekt ist. Beim Empfänger (RCM130) ist es halt die Frage. Der muss dauerversogt sein. Du brauchst einen extra Prozessor, um den seriellen Datenstrtom auszuwerten und Dein Display anzusteuern. Unter 20mA kommst Du da in Summe glaub ich nicht weg. Zum Thema Sychrone Netze: Kennt irgendjemand ein System, dass ohne einen dauerversorgten Sternknoten auskommt?
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.