Hallo zusammen, ich suche ZigBee-Transceiver, welche sind zu empfehlen. und was ist besser? ein fertiges Moduls mit µC, ein Modul ohne µC nur HF-teil oder nur Transceiver und rest selber machen? Danke
Hallo Araz, hier findest du einen Ueberblick, was an fertigen Modulen mit Atmel Radios auf dem Markt ist: http://uracoli.nongnu.org/hwlist.html Das tiny230 ganz unten auf der Seite ist ein Eigenbau von Joerg, das sehr gut funktioniert. Die Dokumentation (nicht der letzte Stand) gibts hier http://download.savannah.gnu.org/releases/uracoli/tiny230revB.zip Viele Gruesse, Axel
Hallo Axel, danke für die nützlichen Inos. kannst mir sagen, wann und welche gebühren anfallen, wenn man nur einen Chip (auf ZigBee basiert) nimmt und kein fertiges Modul?
araz wrote: > kannst mir sagen, wann und welche gebühren anfallen, wenn man nur einen > Chip (auf ZigBee basiert) nimmt und kein fertiges Modul? Eher Kosten als Gebühren. ;-) Den AT86RF230 kannst du bei CSD Electronics kaufen, da schlägt er aber ziemlich heftig zu Buche. Bei Digikey kostet er in Einzelstückzahlen etwas weniger, für größere Stückzahlen gibt's dort nur die Angebote für sogenannte Chipsätze, die aus einem Transceiver und einem ATmega bestehen.
Hallo Araz, mit Gebühren war gemeint, welche Software Lizenzkosten anfallen? Da ist zunächst die Frage, was du mit den Knoten machen willst. Muss es echtes ZigBee sein, d.h. Daten über mehrere Hops geroutet? Das geht z.B. mit BitCloud von Meshnetics. Reicht ein sternförmiges NW (1 Coordinator als Master-Knoten, mehrere Devices als Slaves, das waere dann mit IEEE 802.15.4 zu erledigen, z.B. Atmel-MAC, OpenMAC von Meshnetics)? Oder handelt es sich um eine Punkt zu Punkt oder Punkt zu Multipunkt Verbindung, da kannst du direkt auf der Radio Hardware arbeiten (z.B. AVR2001 AppNote, uracoli). Als Alternative zum ZigBee Netzwerk Stack gibt es noch 6LowPan eine IPV6 Variante, die auf 802.15.4 aufsetzt. Eine freie Implementierung für die Atmel-Raven-Boards gibts hier: http://www.sics.se/contiki/ Viele Gruesse, Axel
Hallo Leute, Also ich muss im Rahmen meines Praktikums ein Konzept für eine Firma entwickeln zur Integration einer Funkschnittstelle in einen Sensor. Ich hab mich noch nicht fest entschieden, welche Technik ich nehmen soll. für mich kommt in Frage (WLAN, Bluetooth, NanoNet, und 802.15.4 (ZigBee)). Wenn dieser Funk-Sensor in serie gehen sollte, werden dann midestens 2000 Stück produziert, von daher wollte ich schauen, ob es sich lohnt nur den Chip (Transceiver, SOC, Prozessor) zu kaufen und den rest in der Firma zu erledigen? villeicht kann mir jemand sagen bei welcher der o.g. Tecchniken Lizenzkosten ab wann anfallen. und was wird eher bevorzugt (abgesehen davon, dass sie für untershiedliche Anwendungen ausgelegt sind) Reichweiten bis 100 m Nutzdaten 32 bits aber alle 10ms. sorry, wenn ich zu viel geschrieben hab, und hoffe, dass mir jemand auf m.Fragen ungefähr antworten kann. Gruß Araz
Also die Lizenzgebühren für die ZigBee Alliance selbst sind soweit ich weiß im Chip-Preis des ZigBee Chips enthalten. Wenn du den kompletten ZigBee Stack selber schreibst, fallen natürlich keine weiteren Gebühren an. Wenn du natürlich einen fertigen Stack kaufst, musst du da beim Anbieter schauen, wie die Lizensierung läuft. Soll das ein sich selbst vernetzendes Netzwerk werden? Mit Multihop und allem pipapo? Oder würde ein einfaches Stern-netzwerk reichen? Bei ZigBee ist halt der Stack sehr teuer, wenn man den selber integrieren will, bei Modulen gehts. Bei NanoNet siehts noch schlimmer aus, der Stack kostet etwa 45.000€, die Chips sind auch recht teuer. IEEE 802.15.4 ohne ZigBee ist extrem preiswert, wenn man ein kleines eigenes Protokoll auf dem MAC-Layer aufsetzt. So haben wir das gemacht. Geht dann natürlich erst mal nur Stern-netzwerk. Dafür aber viel schneller, stabiler und energiesparender als ZigBee.
Also die Software wird bei uns i.d.R nicht geschrieben, sondern wird von Dienstleister erledigt. Wenn ich richtig verstanden hab, man kann den Stack für ZigBee schreiben, ohne irgendwelche kosten zu zahlen? was meinst du dann damit? >Bei ZigBee ist halt der Stack sehr teuer, wenn man den selber integrieren >will, bei Modulen gehts Kannst du vielleicht aus deiner Erfahrung sagen, ob ZigBee bzw.802.15.4 für von mir geschriebenen Anforderungen was ist? Gruß Araz
Nun ja, du hast nicht geschrieben, wieviele Teilnehmer gleichzeitig im Netz sind. Außerdem weiß ich nicht, ob die alle gleichzeitig irgendwas messen müssen, also zeitsynchron sein sollen. "Sehen" alle Teilnehmer den Koordinator? Alle 10ms ein Paket ist durchaus machbar, aber dann dürfen nicht allzuviele Teilnehmer im Netz sein, denn die nutzen ja alle den gleichen Kanal, und es kann nur immer einer durchkommen. Die Chips unterstützen ja alle CCA, also senden erst, wenn der Kanal frei ist. Mit ZigBee haben wir extrem schlechte Erfahrungen gemacht. Unzuverlässiger Verbindungsaufbau, speziell in gestörten Umgebungen (Bluetooth, WLAN). Niedrige Datenrate, extrem hohe Latenzzeiten. Hoher Stromverbrauch durch das ganze Routing. Was ich mit dem Stack meine: Du musst ja den ZigBee Stack als Software-Lizenz kaufen, meinetwegen vom Ember oder sowas. Das kostet eine Stange Geld, desweiteren musst du natürlich dann Lizenzgebühren zahlen pro verkauftem Modul. Selber schreiben ist auch so eine Sache. Da ist ja jede Menge Funktionalität drin, das ist nicht mal eben so gemacht. Außerdem muss man wohl erst mal an ZigBee zahlen, um alle Specs zu bekommen. Meiner Meinung nach ist die ZigBee Alliance ein geldgieriger Sauhaufen, der am Markt vorbei arbeitet. Was will man mit einem Sensornetzwerk, was haufenweise Strom pro Bit braucht, lange Latenzzeiten hat und sich nicht zeitlich synchronisieren lässt? Für einfache Temperatur- und Luftfeuchtemessungen an vielen Orten vielleicht OK, aber wirkliche Anwendungen mit vielen verteilen Sensoren, deren Messergebnisse in relation gebracht werden müssen, unbrauchbar.
Araz Kocher wrote: > Wenn ich richtig verstanden hab, man kann den Stack für ZigBee > schreiben, ohne irgendwelche kosten zu zahlen? Ja, solange du mit den veröffentlichten Spezifikationen auskommst. Die jeweils neuesten Spezifikation werden typischer Weise nur den Konsortiumsmitgliedern zugängig gemacht, und für diese Mitgliedschaft zahlt man dann was. > Kannst du vielleicht aus deiner Erfahrung sagen, ob ZigBee bzw.802.15.4 > für von mir geschriebenen Anforderungen was ist? Dazu hat Axel ja oben schon was geschrieben. Wenn du auf Layer 3 routen können willst, brauchst du sowas wie Zigbee oder 6lowPAN. Wenn du nur peer-to-peer-Kommunikation machen willst, kommst du mit Layer 2 (MAC) aus.
> Also ich muss im Rahmen meines Praktikums ein Konzept für eine Firma > entwickeln zur Integration einer Funkschnittstelle in einen Sensor. ist dieses ja als beispiel brauchbar.... http://www.chip45.com/index.pl?page=iDwaRF-168&lang=de&tax=ecde
Zu der Frage Netzwerk: Bei uns in der Firma werden die Sensoren (Drehgeber) für verschiede Anwendungen benutzt. Überwiegend wird eine Punkt-zu-Punkt Verbindung oder eine Star-Topologie aufgestellt. Aber kann sein dass ein Kunde sich auch Mesh-Netze wünscht. was ich mit Software-Lizenz nicht ganz gut verstanden habe, dass es manche Hersteller wie Chipcon mit dem Chip CC2480 auch einen kostenlosen Stack zur Verfügung stellen (bzw.inegriert?). sind diese Stacks nur auf TI-MCUs bezogen oder auf beliebige MCUs? Leute entschuldigt mich, wenn ich soviele Fragen stelle, die vielleich für manche selbstverständlich sind. Bin halt ein bisschen überfordert. Danke euch alle für eure Hilfe. Gruß Araz
Gibt auch schon Chips wo der ZigBee Stack fest drin ist (EM260, CC2480A1). Neben evt. Lizenzkosten nicht die Kosten für die Funkzulassung vergessen!
> Neben evt. Lizenzkosten nicht die Kosten für die Funkzulassung > vergessen! Ich dachte die Frequenzen dafuer sind frei?
@Jörg S. Mit Funkzulassung meinst du, CE und FCC Zulassung, oder was anderem?
>Ich dachte die Frequenzen dafuer sind frei?
Das schon, aber du darfst nicht einfach so ein Produkt auf den Markt
werfen ohne das vorher gemessen und bescheinigt wurde das alles im
erlaubten Bereich ist (FCC, ETSI,.. je nach Land wo es eingesetzt werden
soll).
Umgehen kann man das nur indem man ein fertiges Modul nimmt was diese
Zulassung schon hat.
Jörg S. wrote: > Umgehen kann man das nur indem man ein fertiges Modul nimmt was diese > Zulassung schon hat. Jein. Bei ETSI brauchst du gar keine ,,Zulassung'' als solche, sondern du musst ,,einfach nur'' die Bestimmungen einhalten. Typischer Weise wird das wiederum mit einer Messung belegt, und wenn der Modul gemessen ist, dann ist es an dir als Gerätehersteller einzuschätzen, ob das fertige Gerät allein auf der Basis eines als konform gemessenen Moduls nach wie vor die rechtlichen Bestimmungen einhält, oder ob du das besser nochmal messen solltest. Bei FCC-Land habe ich gehört, dass du zumindest eine neue FCC-ID für das fertige Gerät brauchst, ob er auch eine neue Zulassung braucht, weiß ich so genau jetzt nicht. Anders als bei ETSI ist dort aber bei sendenden Geräten eine Zulassung Pflicht.
Hallo, darf man eigentlich im Bereich 2,4GHz auf Basis vo 802.15.4 mit mehr als 250kbit/s funken, oder ist diese die maximale Datenrate? Danke euch
Araz Kocher wrote: > darf man eigentlich im Bereich 2,4GHz auf Basis vo 802.15.4 > mit mehr als 250kbit/s funken, oder ist diese die maximale Datenrate? Auf Basis von 802.15.4 selbst sind nur 250 kbit/s genormt. Allerdings ist die physische Taktrate dabei 2 MHz, d. h. man kann mit gleicher Modulation (unter Verzicht auf die Spreizung durch das Zwischenschalten der "chips") bis maximal 2 Mbit/s arbeiten. Das reduziert natürlich notwendiger Weise die Empfindlichkeit des Empfängers, da dieser keinen ,,Spreizgewinn'' (= Gewinn, der durch die Redundanz der gechipten Daten entsteht) mehr hat. Prinzipiell kannst du natürlich noch mehr Bandbreite belegen, die maximal zulässige Ausgangsleistung ist aber von der Bandbreite abhängig. IEEE 802.11 ist ja deutlich breiter.
Hallo, Danke für die schnelle Antwort. wenn man nur 500kbit/s übertragen will, kann man dennoch DSSS benutzen? und welche Netto-Datenrate kann dann man erreichen?
Araz Kocher wrote: > wenn man nur 500kbit/s übertragen will, kann man dennoch DSSS benutzen? Ja, allerdings muss es der von dir benutzte Transceiver auch können. > und welche Netto-Datenrate kann dann man erreichen? Das hängt von so vielen Dingen ab, das kann dir wohl niemand genau sagen. Eine theoretische Obergrenze kannst du dir selbst ausrechnen.
Aber im Allgemeinen können mehr Netto-Datenrate als bei ZigBee erreichen werden, oder liege ich falsch? meine wenn man das Overhead etwas kleiner macht als bei ZigBee, und die Brutto-Datenrate mehr als 250kbit/s?
Araz Kocher wrote: > Aber im Allgemeinen können mehr Netto-Datenrate > als bei ZigBee erreichen werden, oder liege ich falsch? Wenn man eine höhere Brutto-Datenrate hat, dan sollte sich auch eine höhere Netto-Datenrate ergeben. > meine wenn man das Overhead etwas kleiner macht > als bei ZigBee, und die Brutto-Datenrate mehr als 250kbit/s? Meinst du hier wirklich ZigBee, also die Netzwerkschicht, so wie sie von der ZigBee Alliance definiert ist? Dort hängt der Durchsatz im Wesentlichen von den Latenzen ab und natürlich von der Anzahl der Hops. Die eigentliche Datenrate dürfte da gar keine so große Rolle spielen.
ok..jetzt verstehe ich.
Jörg Wunsch worte:
>Ja, allerdings muss es der von dir benutzte Transceiver auch können.
gibts da speziele TRX oder kann jeder TRX, der für 802.15.4/ZigBee
ausgelgt ist die DSSS aufgabe mit mehr als 250kbit/s erledigen?
wie z.B CC2431??
Araz Kocher wrote: > ok..jetzt verstehe ich. > > > Jörg Wunsch worte: >>Ja, allerdings muss es der von dir benutzte Transceiver auch können. > > gibts da speziele TRX oder kann jeder TRX, der für 802.15.4/ZigBee > ausgelgt ist die DSSS aufgabe mit mehr als 250kbit/s erledigen? > wie z.B CC2431?? Also die 802.15.4 kompatiblen Transceiver haben die 250kBit/s fest durch die 2MChips/s. Aber natürlich steht es dir frei, einen anderen Transceiver zu suchen, der auf 2,4GHz auch mit mehr als 250kBit/s funken kann. Nur hat das dann nix mehr mit ZigBee und 802.15.4 zu tun und ist auch nicht kompatibel. Übrigens erreicht man ohne ZigBee auf dem MAC-Layer schon recht gute Netto-Raten. Ich hab hier etwa 8...12 kByte/s mit dem CC2420 und aktiver Anforderung des nächsten Paketes durch die Gegenstelle.
mir gehts eigentlich auch um die Netto-Raten. also wenn du 8...12kByte/s geschafft hast, finde ich gut, weil soweit ich weiß kann man mit ZigBee 20-30kbit/s erreichen (Laut Aussage von einem ZigBee-Modul Hersteller). Ich denke, werden auch den Weg (802.15.4) gehen. Aber wollte vorher Tests machen. Kennst welche devl-Kits mit denen man schnell einen Test machen kann? Übrigens: welche Reichweiten hast damit du erzielt?
Araz Kocher wrote: >>Ja, allerdings muss es der von dir benutzte Transceiver auch können. > gibts da speziele TRX oder kann jeder TRX, der für 802.15.4/ZigBee > ausgelgt ist die DSSS aufgabe mit mehr als 250kbit/s erledigen? > wie z.B CC2431?? Der TRX muss dafür vorbereitet sein, sowas zu können. Ein CC2420 kann das meines Wissens nicht (und ein CC2431 ist ein CC2430 plus location engine, wiederum ist der CC2430 ein CC2420 mit einem 8051-Kern). Ich weiß, dass der AT86RF231 sowas kann, und ich habe mal von einem Fernost-TRX gehört, dessen Namen ich jedoch vergessen habe.
Araz Kocher wrote: > mir gehts eigentlich auch um die Netto-Raten. > > also wenn du 8...12kByte/s geschafft hast, finde ich gut, weil soweit > ich weiß kann man mit ZigBee 20-30kbit/s erreichen (Laut Aussage von > einem ZigBee-Modul Hersteller). Und das ist schon eine optmistische Angabe. Mit den Telegesis Modulen hab ich 1kByte/s erreicht. Bei doppeltem Stromverbrauch gegenüber dem CC2420+MSP430 System. > Ich denke, werden auch den Weg (802.15.4) gehen. Aber wollte vorher > Tests machen. Kennst welche devl-Kits mit denen man schnell einen Test > machen kann? Ich hatte das CC2420 Komplett-Kit von TI (etwa 500 USD) plus nochmal ein 2er Set der Transceiver Platinen (100 USD). Damit kommt man schnell voran, Packet Sniffer und Smart RF Studio helfen da viel. > Übrigens: welche Reichweiten hast damit du erzielt? Ist sehr stark von den Antennen, der Sendeleistung, der Transceiverplatine usw. abhängig. Mit kleinen Stummelantennen von Farnell im Freifeld um die 50 bis 100m. Im Haus hier etwa 10...20 Meter.
Hallo. Ich möchte auch ein Netzwerk mit Zigbee aufbauen. Besteht eigentlich eine Möglichkeit, einen schlafenden Router (bzw. er befindet sich in einem Strom sparenden Modus) aufzuwecken ohne das dies über die Aussendung von Beacons erfolgt? Das heißt,dass ein End Device seine Daten sendet und dies der Router mitbekommt und dadurch sein Transceiver für den Datenempfang aufgeweckt wird? Mein Router sollte autark fungieren,aber trotzdem möchte ich auf das Aussenden von Beacons verzichten.Geht das? Danke,Tom
Naja, einen schlafenden Router sollte man tunlichst vermeiden. Ich hab das probiert, macht aber keinen Sinn. Der Netzaufbau nach dem aktivieren des Routers kann ewig dauern. Schließlich haben sich ja die anderen Router in der Zwischenzeit andere Wege gesucht. Wenn der jetzt wieder aktiv wird, werden ja die Routen wieder neu berechnet. Schlafen geht nur sinnvoll bei End-Devices. Was heißt autark bei dir? Energieautark?
Hi Tom, der Transceiver kann nicht mit einem "halben Ohr" hinhoeren und Rahmen empfangen wenn eine Preamble kommt. Entweder er ist immer auf Empfang (a), d.h. dass er dann immer die 15mA braucht oder er ist ausgeschalten (TRX_OFF) oder besser im Sleep (b). Im Fall (b) wird ein Zeitraster vereinbart, in dem die Devices ihre Daten loswerden können während der Router auf Empfang ist. Das Versenden der Beacons in einem Beacon-enabled Netzwerk dient dazu, bekanntzugeben, wie das Zeitraster aufgebaut ist. Man braucht die Beacons, damit sich die Devices auf das Zeitraster aufsynchronisieren koennen. Die Einsparung von Strom und die Latenzzeiten sind die Optimierungspunkte, entweder kurze Beaconperiode und damit kurze Latenzzeiten und höhrerer Stromverbrauch oder umgedreht. Axel
Hallo Leute, ich will ein Xbee evl-Bord mit einem ST-Microcontroller auch evl-Bord via RS232 verbinden und die Daten Transparent übertragen. kann mir jemand mit nem Quellcode unterstüzen?? Danke....
Danke für die schnellen Antworten. @ Christian:Genau,mit autark meine ich energieautark,d.h über Batterie betrieben >Im Fall (b) wird ein Zeitraster vereinbart, in dem die >Devices ihre Daten loswerden können während der Router auf Empfang ist. @ Axel: Für deinen Fall (b) wird das Beacon also nur an den Router gesendet und ich müsste dann das End Device so programmieren,dass es seine Datensendung innerhalb der Zeit,wo der Router aktiv ist sendet? Oder wird der Beacon auch automatisch über den Router an das End Device weitergeschickt und damit das ED synchronisiert? Habe ich das so richtig verstanden?
Tom wrote: > Danke für die schnellen Antworten. > > @ Christian:Genau,mit autark meine ich energieautark,d.h über Batterie > betrieben Achso, energie-autark bedeutet eigentlich, dass er aus der Umgebung sich selbst mit Strom versorgt. Solar, Temp-Differenz....was auch immer. Brauchste halt eine dicke Batterie. Das Zigbee (ohne Beacon) ist nicht dafür ausgelegt, dass sich die Struktur der Router ständig verändert. Hab da genug Trouble gehabt.
@ Christian: Ja ich weiss,dass mit energieautark kann man relativ betrachten.Klar hast du recht,dass dies die Energieversorgung über die Umgebung ist. Manche sehen darin aber auch den Fall einer Versorgung ohne Kabel. :) UND: Kann mir zu unten stehendem keiner ne Antwort geben? >Im Fall (b) wird ein Zeitraster vereinbart, in dem die >Devices ihre Daten loswerden können während der Router auf Empfang ist. >@ Axel: Für deinen Fall (b) wird das Beacon also nur an den Router >gesendet und ich müsste dann das End Device so programmieren,dass es >seine Datensendung innerhalb der Zeit,wo der Router aktiv ist sendet? >Oder wird der Beacon auch automatisch über den Router an das End Device >weitergeschickt und damit das ED synchronisiert? >Habe ich das so richtig verstanden? Mein Vorhaben ist,dass der Koordinator Beacons verschickt, die von 2 Routern empfangen werden.An einem Router befindet sich ein End Device,dass Sensordaten an den Koordinator übermitteln will. Der 2. Router hat (vorläufig) nichts zu übermitteln.
Hallo! Weiss jemand von euch,wie man die Dauer für ein slotted CSMA/CA im Beacon-enabled Modus berechnet. Also ich meine jetzt damit verallgemeinert und nicht auf eine spezielle Datenpaketgröße bezogen. Möchte so eher die Rechenschritte wissen! Danke,Ulf
Ulf wrote: > Weiss jemand von euch,wie man die Dauer für ein slotted CSMA/CA im > Beacon-enabled Modus berechnet. Wirklich berechnen kann man die leider gar nicht. > Also ich meine jetzt damit verallgemeinert und nicht auf eine spezielle > Datenpaketgröße bezogen. Mit einer Datenpaketgröße hat das auch nicht viel zu tun. Hast du dir den entsprechenden Teil von IEEE 802.15.4 mal durchgelesen? Auch wenn sich dieser Teil nur geringfügig geändert hat, würde ich dir dabei zum Lesen der 2006er Version raten. Der reine Algorithmus ist gar nicht so sehr verschieden vom unslotted CSMA/CA, bis auf: . die CCA-Messung muss immer an einer backoff slot boundary gestartet werden (je 20 Symbole, bezogen auf den Superframe -- ich könnte den Theoretiker, der da die 20 reingedrückt hat, statt 16 oder 32 zu nehmen, heute noch dafür steinigen), . der Kanal wird erst nach zwei erfolgreichen nicht-belegt-Messungen als frei angenommen Was die ganze Sache verkompliziert ist, dass die Messung nur innerhalb der CAP durchgeführt werden darf, und dass auch die komplette Übertragung in die CAP passen muss. Durch eine Reihe von variablen Zeiten (genaues Ende des Beacons: hängt von der Länge der pending transaction list und von der genauen Länge der beacon payload ab; was hat das random backoff dieses Mal wirklich ausgewürfelt?; gibt es ggf. GTSes?) ist das Komplettsystem damit praktisch nicht mehr vorhersagbar. Selbst wenn du initial festgestellt hast, dass deine Übertragung noch in der CAP des aktuellen Superframes vollständig abgewickelt werden könnte (wenn nicht, musst du sie gleich in die CAP des nächsten Superframes verschieben), kann es dir ,,unterwegs'' immer noch an allen Ecken und Enden passieren, dass es am Ende doch nicht mehr passt. Je nachdem, wo du gerade bist, musst du dann teilweise das random backoff bis in die nächste CAP ,,aussitzen'', teilweise musst du dort das komplette CSMA/CA neu anfangen. Alles in allem ein Algorithmus, der mir deutlich komplizierter vorkommt, als es der Aufgabe angemessen erscheint, und der am ursprünglichen Ziel, klein, billig und stromsparend zu sein (was kleine Controller und bspw. keine komplette Implementierung der gesamten Superframe-Mimik in Hardware bedeutet, denn die ist stromfressend) deutlich vorbei geschossen hat.
@ Jörg Wunsch: Danke erstmal für die ausführliche Erklärung.Ich hab mir auch mal den entsprechenden Abschnitt im IEEE 802.15.4 durchgelesen. Nun mal eine Frage zu einem eventuellen Ablauf: Ich möche in einer Baum-Topologie Daten empfangen. Beteiligt sind 1 Coordinator,1 Router und 1 FFD (Router,als quasi End Device das aufgenommene Daten sendet).Das entspricht ja laut IEEE 802.15.4-Datenblatt dem Fall "Senden von End Device zu Coordinator" -> nur halt mit Router dazwischen. Könnt ich das da also so machen,dass mein Coordinator ein Beacon an den Router sendet und dieser Router innerhalb der CAP ein Beacon an das FFD sendet.Das FFD schickt dann seine Daten an den Router und der Router die Daten wiederum an den Coordiator! Mein Coordinator wird nicht von Batterie gespeist. Das Ziel ist halt den Router solange wie möglich in den Schlaf zu legen. Danke,Ulf
Ulf wrote: > Beteiligt sind 1 Coordinator,1 Router und 1 FFD (Router,als quasi End > Device das aufgenommene Daten sendet).Das entspricht ja laut IEEE > 802.15.4-Datenblatt dem Fall "Senden von End Device zu Coordinator" -> > nur halt mit Router dazwischen. Nein, IEEE 802.15.4 deckt den Fall von Routing nicht ab, da das die Aufgabe der Schicht 3 (network layer) ist, 802.15.4 aber nur bis Schicht 2 (MAC) geht. Aus Sicht von 802.15.4 handelt es sich bei deinem Vorhaben um zwei separate device -> coordinator Datenübertragungen. Die erste geht vom Endgerät zum Router (der aus Endgerätesicht der coordinator ist, aber nicht der `PAN coordinator', d. h. er kann nicht mit einer leeren Adresse angesprochen werden). Dieser leitet das empfangene Datenpaket an seine Netzwerkschicht, die dann feststellt, dass die Netzwerkadresse (!) des Datenpakets nicht für die lokale Maschine gedacht war. Daraufhin schaut er in der Routingtabelle nach, wem er das Paket nun weiterleiten muss. Er wird feststellen, dass es an seinen eigenen coordinator (der dann wohl der `PAN coordinator' ist) weiterzuleiten ist, sodass er es mit gleicher NWK-Adressierung aber neuer MAC-Adressierung erneut dem MAC layer übergibt. Dieser fungiert nun seinerseits selbst als Endgerät gegenüber dem übergeordneten coordinator. > Könnt ich das da also so machen,dass mein Coordinator ein Beacon an > den Router sendet und dieser Router innerhalb der CAP ein Beacon an > das FFD sendet. Nein, die beacons der beiden Teilnetze sollten so geschachtelt werden, dass der Router seinen beacon außerhalb der CAP seines (PAN) coordinators sendet. Der Parameter StartTime im MLME-START.request fehlte in der 2003er Version des Standards und wurde in der 2006er Version auf der Basis eines ZigBee-Vorschlags neu eingeführt. Logischerweise funktioniert die Schachtelung nur, wenn die superframe order kleiner ist als die beacon order, d. h. alle Koordinatoren im gesamten PAN haben einen Teil des Superframes, in dem sie komplett inaktiv sind. > Das Ziel ist halt den Router solange wie möglich in den Schlaf zu legen. Das wollen alle. ;-) Das ist aber nicht wirklich trivial, da ja der Router auf seine ,,Schäfchen'' hören können muss (und das Hören halt mächtig Strom kostet). Da gibt's noch so'n Kram wie die battery life extension, bei denen der coordinator (bzw. Router) wohl jeweils nur drei (?) backoff slots lang hört, um Strom zu sparen. Andererseits verkompliziert dieser Parameter das slotted CSMA/CA weiter zusätzlich. Es gibt meines Wissens ein oder zwei Firmen, die auch mit völlig privaten Erweiterungen für ein synchronized wakeup arbeiten, aber wie das jeweils genau arbeitet, da steck ich zu wenig drin. Mindestens eine dieser beiden Firmen benutzt dafür Frames mit einem nicht durch IEEE 802.15.4 standardisierten frame type (also `reserved' im Sinne des Standards).
Hmm,das klingt mächtig kompliziert. Ich glaub da würde meine Anwendung sehr umfangreich werden. Da frag ich mich bloß,wie z.B. Firmen wie Meshnetics mit Tree-und Meshtopologien und Batterielebensdauern von ca. 10 Jahren werben? Diese Lebensdauern gelten dann sicherlich nur für End Devices und nicht Router in einem solchen Netzwerk?
Ulf wrote: > Diese Lebensdauern gelten dann sicherlich nur für End Devices und nicht > Router in einem solchen Netzwerk? Yep. Die Quadratur des Kreises ist ihnen allen noch nicht gelungen, und die ZigBee Alliance wäre sicherlich froh über einen von fremden Eigentumsrechten freien Algorithmus für einen sleeping router, den sie zum Protokollstandard erheben könnte.
Würde ich nun von einem schlafenden Router absehen,was die Kompliziertheit ein wenig verringern würde,kann ich das Netzwerk wohl am besten über unslotted CSMA/CA betreiben?! Das End Device sendet seine Daten per unslotted CSMA/CA an den Router,der sich im Empfangszustand befindet.Nach Erhalt der Daten schaltet er seinen Transceiver auf Senden um und überträgt ebenfalls die Daten per unslotted CSMA/CA an den Coordinator! Wäre die einfachste Lösung,oder? Oder existiert da noch ne andere Möglichkeit am Router soviel wie möglich Energie zu sparen?
Ulf wrote: > Würde ich nun von einem schlafenden Router absehen,was die > Kompliziertheit ein wenig verringern würde,kann ich das Netzwerk wohl am > besten über unslotted CSMA/CA betreiben?! Beacon-enabled network bringt dir eigentlich nur dann einen Vorteil, wenn du Daten vom Router/Coordinator zum Endgerät übertragen können musst, oder aber natürlich, um überhaupt einen Router in bspw. 1/16 der Zeit nur betreiben zu müssen (und damit seine Batterielebensdauer wenigstens zu ver16fachen, allerdings auf Kosten des Stromverbrauchs aller angeschlossenen Endgeräte, da diese ja zur Synchronisation regelmäßig aufwachen müssen).
@ Jörg Wunsch: >Nein, die beacons der beiden Teilnetze sollten so geschachtelt werden, >dass der Router seinen beacon außerhalb der CAP seines (PAN) >coordinators sendet. Der Parameter StartTime im MLME-START.request >fehlte in der 2003er Version des Standards und wurde in der 2006er >Version auf der Basis eines ZigBee-Vorschlags neu eingeführt. Wenn du das so machen würdest,dass der Router das Beacon an das FFD während des sleep-Mode vom Coordinator sendet,geht das dann auch, dass der Router innerhalb der CAP(Aktivzeit) vom Coordinator die vom FFD erhaltenen Daten an den Coordinator sendet? ....ja ich weiss:ist ein langer Satz :) Können da im Endeffekt die Superframes von Coordinator und Router jeweils unterschiedliche Längen besitzen? Nein,oder?-> weil das ja fest vom Coordinator vorgegeben wird?! Ulf
Ulf wrote: > Wenn du das so machen würdest,dass der Router das Beacon an das FFD > während des sleep-Mode vom Coordinator sendet,geht das dann auch, dass > der Router innerhalb der CAP(Aktivzeit) vom Coordinator die vom FFD > erhaltenen Daten an den Coordinator sendet? Verstehe ich noch nicht ganz. Die Superframes sollen ineinander geschachtelt werden im Router-Betrieb. Damit ist zwangsweise die CAP des Routers nach der CAP des (PAN) coordinators, d. h. der Router kann die empfangenen Daten erst im nächsten Superframe nach oben weiterreichen. Sieh dir mal Abschnitt 7.5.1.2 Incoming and outgoing superframe timing im IEEE 802.15.4-2006 an, da gibt's auch ein Bild dazu. > Können da im Endeffekt die Superframes von Coordinator und Router > jeweils unterschiedliche Längen besitzen? Nein, deren Konfiguration muss innerhalb eines PANs identisch sein (bis auf den Offset natürlich).
@ Jörg Wunsch: So wie ich das aus dem Text in 7.5.1.2 verstehe "On a beacon-enabled PAN, a coordinator that is not the PAN coordinator..." und du mir heut morgen schon erklärt hast,muss man quasi 2 einzelne Netzwerke betrachten-wegen den 2 Coordinatoren, wovon einer der PAN-Coordinator ist. Das Datenpaket zum PAN-Coordinator würde ich dann innerhalb der ersten CAP (incoming(received) Superframe) schicken und danach mir in der 2.CAP (outgoing Superframe) neue Sensordaten holen? Also mein gesamtes Netzwerk besteht im Endeffekt aus 1 Coordinator an dem 2 Routern hängen und diese beiden Router haben jeweils ein FFD noch dran. Da hätte ich dann quasi nach obiger Aussage ingesamt 3 Coordinatoren (da 3 Netzwerke) wovon einer der PAN-Coordinator ist um im Beacon-enabled Mode zu kommunizieren?
Ulf wrote: > Das Datenpaket zum PAN-Coordinator würde ich dann innerhalb der ersten > CAP (incoming(received) Superframe) schicken und danach mir in der 2.CAP > (outgoing Superframe) neue Sensordaten holen? Das Endgerät müsste sie dir schicken. Heißt natürlich nicht, dass du dir in jedem Superframe ein Paket schicken lassen musst, andererseits kann man natürlich die Superframe-Intervalle bis auf ca. 4 Minuten ausdehnen. > Also mein gesamtes Netzwerk besteht im Endeffekt aus 1 Coordinator an > dem 2 Routern hängen und diese beiden Router haben jeweils ein FFD noch > dran. Du meinst je ein RFD, oder? > Da hätte ich dann quasi nach obiger Aussage ingesamt 3 Coordinatoren (da > 3 Netzwerke) wovon einer der PAN-Coordinator ist um im Beacon-enabled > Mode zu kommunizieren? Ja.
Jörg Wunsch wrote:
>Du meinst je ein RFD, oder?
Nein ich meine 2 FFDs die mir die Sensordaten liefern.Der ist der,dass
ich eigentlich vor hatte,damit ein Mesh-Netzwerk aufzubauen,aber jetzt,
wo ich mich über Beacon-enabled Mode belesen habe, ist dieser Modus
hauptsächlich in Tree-Topologien angebracht.
Falls das mit dem Mesh wenig Sinn macht,würde ich da Natürlich die
Knoten die meine Sensordaten aufnehmen als RFDs auslegen,allein schon
wegen dem kleineren Stack und damit verbunden weniger Energieverbrauch.
Aber die Daten vom Coordinator zum PAN-Koordinator kann ich dann nicht
einfach über:
PAN-Coordinator sendet Beacon-> Coordinator sendet daraufhin seine vom
FFD erhaltenen Daten"
machen?Oder greift dann der Fall wie du gestern beschrieben hast,dass
aus Sicht des PAN-Coordinator der untergeordnete Coordinator als End
Device gesehen wird?
Ulf wrote: > Nein ich meine 2 FFDs die mir die Sensordaten liefern. Versteh ich nicht, als Endgeräte genügen doch immer RFDs. > Der ist der,dass > ich eigentlich vor hatte,damit ein Mesh-Netzwerk aufzubauen,aber jetzt, > wo ich mich über Beacon-enabled Mode belesen habe, ist dieser Modus > hauptsächlich in Tree-Topologien angebracht. Mir scheint, du verwechselst hier Mesh- und Tree-Topologie mit beacon-enable vs. non beacon-enabled vs. FFD/RFD. Ein FFD hat die Fähigkeit, selbst coordinator/router zu sein, das ist das Einzige, was es von einem RFD unterscheidet. Auch RFDs könnten sich in einer Maschentopologie untereinander Daten senden, allerdings muss dafür natürlich die Gegenseite auf Empfang stehen. Der Vorteil von Stern oder Baum ist, dass die RFDs schlafen können. > ...als RFDs auslegen,allein schon > wegen dem kleineren Stack und damit verbunden weniger Energieverbrauch. Was hat die Stack-Größe mit dem Energieverbrauch zu tun? Wenn du ein FFD als Endgerät betreibst, wird doch der Code für den coordinator/router nie angesprochen, also verbraucht der auch keine Energie. Wenn überhaupt, dann verbraucht er bestenfalls Leckstrom in Form des nächst größeren Controllers. Das sind aber wahrscheinlich Peanuts im Vergleich zum aktiven Strom für den HF-Teil. > Oder greift dann der Fall wie du gestern beschrieben hast,dass > aus Sicht des PAN-Coordinator der untergeordnete Coordinator als End > Device gesehen wird? Genau, der Router verhält sich gegenüber seinem coordinator selbst wieder wie ein normales Endgerät. Der Unterschied aus Sicht seines coordinators ist nur, dass er Routingtabelleneinträge für den Router besitzen kann, da er irgendwoher gelernt hat, welche weiteren Knoten dieser Router alle bedienen kann. Dieser Unterschied ist aber auf NWK-Ebene, auf MAC-Ebene ist der Router einfach nur ein Endgerät für ihn.
@ Jörg Wunsch:
Abermals ein großes Dankeschön für die ausführlichen Antworten!!! :)
Ich schon paar mal gelesen,dass ein Mesh-Netzwerk im Beacon-enabled
Modus nicht so "toll" ist. -> Weisst du warum?
>Versteh ich nicht, als Endgeräte genügen doch immer RFDs.
Das ist richtig,dass eigentlich immer RFDs als End Devices genügen,aber
auch FFDs können EDs sein.
Meines Erachtens wäre dies z.B. sinnvoll,wenn man die Daten beim Ausfall
eines Knotens über nen anderen Knoten senden will!
Ein RFD kann ja immer nur mit einem Knoten kommunizieren (...aber is
jetz auch egal.Will das hier nicht ausdehnen)
Ulf
Ulf wrote: > Ich schon paar mal gelesen,dass ein Mesh-Netzwerk im Beacon-enabled > Modus nicht so "toll" ist. -> Weisst du warum? Naja, es konterkariert ja irgendwie den Sinn des Beaconings. Die ganze Beacon-Geschichte machst du doch nur, damit die Endgeräte jeweils nur einen haben, auf den sie zu einem definierten Zeitpunkt immer mal hören müssen, und der sagt ihnen dann, ob Daten für sie anliegen. Wenn nicht (und sie auch selbst keine Daten zu senden haben), können sie sich nach dem Ende des Beacons sofort wieder schlafen legen. Wenn du vermascht Daten übertragen willst, musst du wissen, dass dein Gegenüber auch gerade zuhört. Das ist beim beacon-enabled network nur für deinen coordinator innerhalb dessen CAP gegeben (der natürlich auch selbst Routerfunktion haben kann). Im non beacon-enabled network gibt es gar keine Definition, wann ein Endgerät überhaupt hört, und ein coordinator/router muss dort eigentlich immer hören. > Meines Erachtens wäre dies z.B. sinnvoll,wenn man die Daten beim Ausfall > eines Knotens über nen anderen Knoten senden will! OK, dann hast du aber dynamisch umkonfigurierende Netze, und das bedeutet, dass alle Endgeräte ziemlich viel Strom brauchen bzw. auf diese Möglichkeit vorbereitet sein müssen. > Ein RFD kann ja immer nur mit einem Knoten kommunizieren Nö, es kann ihm eigentlich niemand verbieten, auch mit anderen RFDs zu reden. Die im RFD fehlende Funktionalität bezieht sich ja nur auf Dinge wie den Start eines PANs (und die dafür notwendigen Scans etc.) sowie das Wiedereingliedern von verloren gegangenen Schäfchen.
@ Jörg Wunsch:
Ich hab trotzdem nochmal eine Frage:
Das im IEEE-Standard der Satz "On a beacon-enabled
PAN, a coordinator that is not the PAN coordinator..." verankert
ist,kann ich das nicht anzweifeln. :)
Aber:
Ich hab mir mittlerweile schon ein paar Pdf´s und so im Netz angeschaut
für den Fall der Tree-Topologie (Coordinator->Router->End Device).
In den Sachen ist immer nur die Rede von einem Router und nicht wie du
beschreibst (und mir auch bestätigt hast),dass dieses Baum-Netzwerk
quasi aus 2 einzelnen Netzwerken besteht:
- einmal End Device zu Coordinator (1.Netzwerk) und dann
- Coordinator zu PAN-Coordinator (2.Netzwerk)
(In dem Sinne wäre das: PANCoordinator->Coordinator->End Device)
Deren Router empfängt halt auch Beacons und sendet ebenfalls während der
inaktiven Phase des seines Coordinator den Beacon Richtung End Device um
Daten zu bekommen.Da steht nirgendswo was von PAN-Coordinator und
Coordinator.
Jetzt meine Frage:
Lassen die Verfasser das außen vor,dass es wie du sagst innerhalb zweier
Netzwerke geschieht?
Ich geb zu,dass mich das ein bissl verwirrt.
Noch eine Antwort wäre nett.
Danke,Ulf
Ulf wrote: > In den Sachen ist immer nur die Rede von einem Router und nicht wie du > beschreibst (und mir auch bestätigt hast),dass dieses Baum-Netzwerk > quasi aus 2 einzelnen Netzwerken besteht: "Router" heißt das Teil in der Terminologie der Schicht 3. Die Schicht 2 kennt kein Routing, daher auch keine Router, deshalb ist das dort ein "coordinator which is not the PAN coordinator". Die Unterscheidung zwischen coordinator (allgemein) und PAN coordinator berührt in Schicht zwei ohnehin nur eine einzige Stelle: der PAN coordinator kann mit einer Nulladresse angesprochen werden und darf auch mit einer solchen senden, ein allgemeiner coordinator (also: Router aus Sicht der Schicht 3) darf das nicht. Meines Wissens macht allerdings ZigBee als derzeit prominentester Vertreter der Schicht 3 oberhalb von IEEE 802.15.4 davon keinen Gebrauch. Dort hat der PAN (und Zigbee) coordinator zwar die short address 0x0000, aber die wird immer angegeben. Wie das bei 6lowPAN ist, habe ich mir noch nicht angesehen, ich vermute aber, dass die von der möglichen Nulladressierung des PAN coordinators auch keinen Gebrauch machen. > Lassen die Verfasser das außen vor,dass es wie du sagst innerhalb zweier > Netzwerke geschieht? Die Begriffe gemäß IEEE 802.15.4 (Schicht 1 + 2) und ZigBee (Schicht 3 aufwärts) werden leider oft genug miteinander verwurschtelt. Jeder ruft auch nach ,ZigBee', selbst dann, wenn er dessen Protokolloverhead gar nicht braucht.
Hallo! Denke meine Frage passt in dieses Foren-Thema: Wird ein active/passive Scan eigentlich jedes Mal durchgeführt wenn der Transceiver aus seinem Schlafzustand aufwacht? Oder ist die Initialisierung einmalig ganz am Anfang wenn sich das Netzwerk konfiguriert? Gruß Sven
Sven wrote: > Oder ist die Initialisierung einmalig ganz am Anfang wenn sich das > Netzwerk konfiguriert? Die gehört zur Konfiguration des Netzes. Wenn allerdings ein Endgerät seinen coordinator verloren hat (weil es bspw. nicht rechtzeitig genug aufgewacht ist für den Beacon), muss es einen orphan scan machen, um ihn wieder zu finden.
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.