mikrocontroller.net

Forum: HF, Funk und Felder ZigBee-Transceiver


Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

Viele Gruesse, Axel

Autor: araz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: juergen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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&lan...

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke juergen,
werde mir genauer anschauen.

Gruß Araz

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt auch schon Chips wo der ZigBee Stack fest drin ist (EM260, 
CC2480A1).

Neben evt. Lizenzkosten nicht die Kosten für die Funkzulassung 
vergessen!

Autor: Nico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Neben evt. Lizenzkosten nicht die Kosten für die Funkzulassung
> vergessen!

Ich dachte die Frequenzen dafuer sind frei?

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg S.
Mit Funkzulassung meinst du, CE und FCC Zulassung, oder was anderem?

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Araz Kocher (araz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat denn keine ne Idee oder kann mir die Frage beantworten?

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.