Hallo zusammen,
ich habe mich mal auf der Meshnetics Seite umgesehen. Jetzt bin ich doch
ganz angetan von den ZigBit Modulen, aber einiges ist mir unklar:
- Die OpenMAC Software ist OpenSource, aber was kann ich damit machen?
Kann ich damit wirklich Verbindungen aufbauen. Ich kenn das nur von
Bluetooth wenn man nur den HCI-Layer hat: man kann schon Verbindungen
aufbauen, aber das ist alles andere als komfortabel
- was ist mit dem eZeeNet Stack, ist der auch umsonst bzw. bekommt man
den mit wenn man ein Modul kauft? Ich nehme an mit diesem Stack ist der
Verbindungsaufbau leichter und komfortabler (mehr Funktionalität)
- ich habe meine AVRs immer unter Linux mit avrdude geflasht, die
Programme mit avr-gcc compiliert. Geht das hier prnzipiell auch so?
Ich weiß das sind ein Haufen Fragen aber je mehr ich auf der
Meshnetics-Seite und in den Beiträgen hier im Forum lese umso weniger
versteh ich.
Na jedenfalls schonmal danke für jegliche Antwort, mir hilft gerade
glaub ich alles weiter.
Gruß
Gepi
Hi,
es hängt ein davon ab, was genau Du machen möchtest und wieviel Aufwand
Du betreiben möchtest.
Natürlich hat man mit dem OpenMAC Stack schon eine gewisse
Grundausstattung, aber ich befürchte eher, dass es in die Richtung geht,
die Du von BT (HCI) schon kennst.
Erst der "eZeeNet Stack" bietet Dir dann die höheren Protokoll-Ebenen,
die z.B. das Mesh-Routing abwickeln.
Der eZeeNet Stack ist erst einmal nicht bei einem gekaufen Modul dabei.
Du hast nur das blanke Module. Mehr nicht.
Möchtest "richtig" entwickeln und Support haben, kommst Du um das ZigBit
Development Kit wohl nicht herum.
Wenn Du einem Blick auf die API des Stacks werfen möchtest, kannst Du
Dir mal folgendes runterladen:
eZeeNet SDK for Atmel AVRRZ200 oder eZeeNet SDK for Atmel AVRRZ502
Dort sind Demos mit Source enthalten. Der Stack liegt aber nur als
binäre Version mit entsprechenden Header Files vor. Zu kompilieren ist
alles mit dem AVR-Studio und dem avr-gcc.
Gruss,
Christian
vergessen:
Da die Module das JTAG Interface des ATmega1281 nach aussen führen,
sollte ein Programmieren/Debuggen mit einem ICE mkII möglich sein.
Ich habe die Module hier rumfliegen, bin aber noch nicht zum Spielen
gekommen.
Zum Posting von gerade:
Ob auf den Modulen überhaupt eine Firmware drauf ist, weiß ich aus o.g.
Grund leider nicht. Ich vermute aber fast, dass der SerNet Stack drauf
ist.
Vielleicht könnte dazu ja nochmal jemand etwas sagen, der mit Dingern
schon gespielt hat.
Gepi wrote:
> ich habe mich mal auf der Meshnetics Seite umgesehen. Jetzt bin ich doch> ganz angetan von den ZigBit Modulen, aber einiges ist mir unklar:
Ja, sind echt niedlich, nicht? :-)
> - Die OpenMAC Software ist OpenSource, aber was kann ich damit machen?> Kann ich damit wirklich Verbindungen aufbauen. Ich kenn das nur von> Bluetooth wenn man nur den HCI-Layer hat: man kann schon Verbindungen> aufbauen, aber das ist alles andere als komfortabel
Kommt halt drauf an, was du machen willst.. je höher im Stack um so
komfortabler (theoretisch) aber auch um so weniger spezifisch für deine
Nutzung - und wenn man die Meinungen so liest auch um so anfälliger für
Störungen.
Was hast du denn vor?
> - was ist mit dem eZeeNet Stack, ist der auch umsonst bzw. bekommt man> den mit wenn man ein Modul kauft? Ich nehme an mit diesem Stack ist der> Verbindungsaufbau leichter und komfortabler (mehr Funktionalität)
Ich habe nur eine Peer-to-Peer Verbindung als Master-Slave auf dem
untersten 802.15.4 Level erstellt, so wie SupaChris das hier in einem
der Threads beschrieben hat.. also nur der Basic-Mode, der im Datenblatt
des AT86RF230 drin ist.
Alle Levels darüber waren für mich zu kompliziert, langsam und
recourcenfressend, deswegen habe ich weder den Stack von Atmel, µracoli
oder den von Meshnetics genutzt.
Falls du noch wo reingucken möchtest, als dritte Meinung sozusagen:
https://savannah.nongnu.org/projects/uracoli
(direkt zur Doku: http://www.nongnu.org/uracoli/manual/index.html)
Fand ich persönlich noch am besten, allerdings bisher kein
Application-File für die Meshnetics Module (also welche Pins wo
angeschlossen sind usw).
> - ich habe meine AVRs immer unter Linux mit avrdude geflasht, die> Programme mit avr-gcc compiliert. Geht das hier prinzipiell auch so?
Ja. Bei mir läuft aber auch nur JTAG (JTAGICEMKII).. ISP über SPI hab
ich nicht zum laufen bekommen.. liegt wahrscheinlich an meinem USB-Prog
(ISPMKII-Clon), den ich hier habe (mit 3,3V Pegelwandler). Da will ich
Benedikt Sauter noch 2 alte Module schicken, damit er da mal drüber
gucken kann, wo es hackt.
Laut Meshnetics haben einige aber auch ISP am laufen, nur wie konnten
die mir nicht sagen und Zugriff auf den Evaluation-Board-Support habe
ich leider nicht, sonst könnte ichs vielleicht rausfinden (kein Eval
Board).
Rein technisch spricht allerdings nichts dagegen, dass das ISP geht
(wurde mir auch in nem Telefonat von einem Techniker bestätigt).
Ich muss echt mal zur Post :-(
> Ich weiß das sind ein Haufen Fragen aber je mehr ich auf der> Meshnetics-Seite und in den Beiträgen hier im Forum lese umso weniger> versteh ich.
- rudimentäre Funkübetragung wo du alles in der Hand hast: direkt selber
machen oder halt mal gucken, was die RF-Library von µracoli so hergibt,
aber da ist dann Anpassung für das Modul nötig
- etwas mehr Komfort, aber nicht mehr alles in deiner Hand, bzw
schwierig Anpassungen vorzunehmen: MAC-Layer
- viel Komfort, aber wohl recht anfällig für zeitkritische Sachen und
kaum noch modifizierbar: ZigBee-Stack
> Na jedenfalls schonmal danke für jegliche Antwort, mir hilft gerade> glaub ich alles weiter.
Du müsstest halt mal erzählen, was du machen möchtest.. dann kann man
dir spezifischer antworten.
Falls du nur mal testen willst, würde ich dir die Meshbeans empfehlen,
weil das anlöten von irgendwas an die Module ist ne echte Fummelei und
nur mit Mikroskop (4-fach) handhabbar :-(.. vor allem muss man hinterher
die Drähte mit Kleber fixieren (Adapter für 1mm Raster kosten auch nicht
grad wenig), sonst reißen die Lötaugen ab - kann dir ein Lied davon
singen. Hätt ich das damals vorher gewusst, hätt ich mir 2 so boards
geholt.
Den Stack kann man immer drauf programmieren, der ATmega drin ist voll
ansprechbar.. die Pinbelegung findest du hier in der Artikel-Sammlung.
Grüsse
Hallo,
habe den Meshbean-Support dank der Wiring-Beschreibung hier in µracoli
eingebaut und im Downloadbereich einen aktuellen CVS-Snapshot und eine
vorkompilierte Versionen u.a. fuer das wdba1281 abgelegt (die Online
Doku ist auch aktualisiert).
http://download.savannah.gnu.org/releases/uracoli/
Vielleicht hilft's weiter, viele Gruesse, Axel
Hallo,
hat es hier schon mal einer geschafft die OpenMAC-Beispiele (z.B.
RangeMeasurementTool) im AVR-Studio zu debuggen? Also mit
C-Debug-Informationen zum Laufen zu bringen?
Grüße Peter
Hallo!
Wie muss man den eZeeNet Stack konfigurieren,damit im Beacon-enabled
Modus übertragen wird?
Geht der bei den ZigBit-Modulen eigentlich,weil ich dazu in den
Datenblättern gerade nichts finde?
Wenn ich google,lese ich auch immer nur,dass ein Beacon vom Coordinator
zum End Device übertragen wird.
Wenn nun ein Router dazwischen wäre,wird da der Beacon auch zum End
Device geroutet?
Antworten wären nett.
Danke,Ulf
Ulf wrote:
> Wie muss man den eZeeNet Stack konfigurieren,damit im Beacon-enabled> Modus übertragen wird?
Ich kenne eZeeNet nicht richtig, habe aber dunkel in Erinnerung,
dass das nur non-beacon enabled networking kann.
> Geht der bei den ZigBit-Modulen eigentlich,weil ich dazu in den> Datenblättern gerade nichts finde?
Den Modulen selbst dürfte das egal sein, nur die Firmware
entscheidet das.
> Wenn ich google,lese ich auch immer nur,dass ein Beacon vom Coordinator> zum End Device übertragen wird.> Wenn nun ein Router dazwischen wäre,wird da der Beacon auch zum End> Device geroutet?
Nein, der Router ist der Empfänger der Beacons seines übergeordneten
Coordinators. Er selbst sendet wiederum verschachtelt Beacons an seine
eigenen Devices. Vernünftiger Weise sollte er die Beacons zu einem
Zeitpunkt senden, da sein übergeordnetes Netz selbst inaktiv ist
(also außerhalb dessen CAP/CFP).
>Ich kenne eZeeNet nicht richtig, habe aber dunkel in Erinnerung,>dass das nur non-beacon enabled networking kann.
@jörg: das glaube ich auch.in einem infoblatt zu den meshnetics steht
nur,dass mit SerialNet GTS möglich sind,aber von Beacon-enabled steht
nichts da.Hast du Erfahrungen mit BitCloud,ob dies evtl. dort möglich
ist?
>Nein, der Router ist der Empfänger der Beacons seines übergeordneten>Coordinators. Er selbst sendet wiederum verschachtelt Beacons an seine>eigenen Devices. Vernünftiger Weise sollte er die Beacons zu einem>Zeitpunkt senden, da sein übergeordnetes Netz selbst inaktiv ist>(also außerhalb dessen CAP/CFP).
Hmm,wie kann der Router Beacon´s senden?Dachte das kann nur der
Coordinator?
Ist das dann so ne Art abgespeckte Version der Coordinator-Beacons?
Ulf wrote:
> @jörg: das glaube ich auch.in einem infoblatt zu den meshnetics steht> nur,dass mit SerialNet GTS möglich sind,...
GTS geht allerdings nur mit beacon-enabled networks.
> Hast du Erfahrungen mit BitCloud,ob dies evtl. dort möglich> ist?
Nö, ich kenne mehr die Hardware, die Meshnetics-Software selbst hatte
ich noch nicht in den Fingern.
> Hmm,wie kann der Router Beacon´s senden?Dachte das kann nur der> Coordinator?
Naja, im Sinne von IEEE 802.15.4 ist ein Router auch ein coordinator
(aber nicht der PAN coordinator).
> Ist das dann so ne Art abgespeckte Version der Coordinator-Beacons?
Nein, es sind die gleichen Beacons, natürlich mit einer anderen short
address. Insbesondere müssen sie die gleiche Konfiguration haben
(beacon order und superframe order).
@ Jörg:
>GTS geht allerdings nur mit beacon-enabled networks.
Das ist mir bereits bekannt.(aber jetz in den falschen Hals bekommen ;)
)
Aber was mich da bei der Sache stutzig macht,sind folgende Punkte aus
dem Datenblatt ( http://www.meshnetics.com/netcat_files/286_9.pdf ):
Key Features:
eZeeNet
-Mesh or Tree topology
-Support for a large number of nodes
-Optional GTS (Guaranteed Time Slot) and Security
-...
SerialNet
-Private Profile with simple Serial Command Interface
-Based on ZigBee Network Layer (NWK v1.0)
-Mesh or Star topology
-Optional Beacon Management, GTS and Security
-...
Also: Warum steht da nur bei SerialNet der Punkt "Optional Beacon
Management",wenn beim eZeeNet-Stack "Optional GTS" möglich ist?Durch das
GTS muss eZeeNet ja quasi auch Beacon-fähig sein?!!
Tom wrote:
> Also: Warum steht da nur bei SerialNet der Punkt "Optional Beacon> Management",wenn beim eZeeNet-Stack "Optional GTS" möglich ist?
Gute Frage. Nächste Frage?
Das wird dir wohl nur Meshnetics erklären können...
@Jörg:
Meine oben gestellte Frage scheint geklärt:Ich denke es ist ein
inhaltlicher Fehler im Datenblatt.
Hab mir grad mal die MAC.h-Datei angeschaut und da sind Konstanten wie
z.B. "MAC_PIB_BEACON_PAYLOAD_LENGTH_MAX" drin definiert.
Also dürfte eZeeNet einen Beacon-enabled-Mode haben...
Gruß,Tom
Ich möchte in das Meshbean-Board die SerialNet Firmware reinladen (User
Guide:Section 5)!
In Section5 steht,dass die Image Files (serialnet.hex und
serialnet.srec) auf das Board geladen werden müssen. (ich mach das über
JTAG ICE mkII)
Wenn ich nun das AVR Studio 4.13 öffne und dort auf "Projekt öffnen"
gehe ist dort nur eine "serialnet.hex" Datei (für meinen angegebenen
Pfad).Klick ich dort drauf,sagt mir das AVR Studio,dass es die Datei in
eine "serialnet.hex.aps"-Datei wandelt.
Ist das richtig,oder sollte da nicht normalerweise eine "serialnet.aps"
drin stehen?
Kann ich das erstellte Projekt nun einfach in mein Board laden?
Sorry für die Frage,aber hab lange nicht mehr mit dem AVR Studio
gearbeitet. :)
Toni wrote:
> Sorry für die Frage,aber hab lange nicht mehr mit dem AVR Studio> gearbeitet. :)
Dann solltest du es vielleicht besser gar nicht benutzen und gleich
AVRDUDE nehmen. ;-)
Unter AVR Studio darfst du damit kein Projekt anlegen, sondern du
musst stattdessen den Programmierdialog aufrufen und dem dann das
File zum Fraß vorwerfen. Ein Motorola-S-Record-File versteht der
aber (im Gegensatz zu AVRDUDE) meines Wissens nicht, nur Intel Hex.
Vermutlich werden beide Dateien aber ohnehin den gleichen Inhalt
haben, nur eben ein anderes Dateiformat.
Danke für die Antwort.
Ja ich denke auch das die .hex- und .srec-Datei denselben Inhalt haben.
Ich wollte sowieso erstmal nur schauen ob da was funktioniert.
Dazu habe ich dann die Applikation "Hardware-Test" draufgespielt,denn
dazu war eine *.aps-Datei vorhanden.Es ging dann auch mit dem erkennen
unterschiedlicher Temp.- und Helligkeitswerte.
Danach hab ich die Serialnet-Demo mal draufgespielt.Während des
Ladevorgangs kam dann in einem kleinen Fenster die Meldung:
"This object file indicates initialized EEPROM data.Do you want to load
this data?" -> Was hat es damit auf sich?
Sollte ich da OK oder Abbrechen klicken?
Toni wrote:
> "This object file indicates initialized EEPROM data.Do you want to load> this data?" -> Was hat es damit auf sich?
Steht doch da: die Datei möchte außer Flash-Inhalt auch noch
Initialisierungswerte im EEPROM hinterlegen. Wenn du im EEPROM
bereits sinnvolle Werte hast, wirst du diese u. U. dann lieber
nicht bügeln wollen, wenn da aber noch nichts drin steht, dann
könnte die Applikation konfus werden, wenn sie nicht zumindest
ihre Standardwerte vorfindet. (Ich würde erwarten, dass die
Applikation diese Werte ggf. selbst später aktualisiert.)
Ich bins nochmal:
Ich wollte nun mal die Netzwerkfunktion testen.Dazu habe ich nach dem
User Guide die WSN-Demo genommen.
Wenn ich die Datein von der mitgelieferten Software benutzte,steht dann
nach dem Compilieren:
"wsndemo.o:1: ***missing separator. Stop."
Build failed with 1 error and 0 warnings...
Was bedeuted das?Kann mir da jemand weiterhelfen?
Hilfe!
Seit Wochen quäle ich mich mit den Meshbeans herum. Ich schaffe es nicht
einmal die Quellen von "RangeMeasurement" zu kompilieren, dabei macht
das Programm schon fast das, was ich brauche (mit kleinen Änderungen).
Ich lege also in AVR Studio ein neues Projekt an und füge Quellen und
Makefile ein. Ein Druck auf F7 beschehrt mir dann folgende Meldung:
Kann mir jemand sagen, was da schief läuft? Ich kann's mir ja teilweise
denken, deshalb: Was muss ich im Makefile ändern, damit ich beim Build
keine Auswahl zu treffen brauche?
Timbuktu wrote:
> Kann mir jemand sagen, was da schief läuft?
Ja, dein AVR Studio ist nicht in der Lage, das "make" mit beliebigen
customized arguments aufzurufen, es ruft einfach nur "make" auf
(vermutlich).
> Ich kann's mir ja teilweise> denken, deshalb: Was muss ich im Makefile ändern, damit ich beim Build> keine Auswahl zu treffen brauche?
Du müsstest als erstes Target ein dummy-Target schreiben, das dann
als Abhängigkeit das von dir gewünschte Target erhält. Üblicherweise
benennt man dieses dummy-Target mit dem Namen "all", aber der Name
ist dabei nicht entscheidend. Wichtig ist nur, dass es die erste
Zeile im gesamten Makefile bildet, die ganz links beginnt und danach
einen Doppelpunkt hat -- im Extremfalls also wirklich ganz an den
Anfang des Makefiles oben schreiben.
Beispiel:
1
all: meshbean2
Danach guckst du weiter nach unten, wo das bislang erste Target
auftaucht (könnte auch "all" heißen) und kommentierst das mitsamt
den dahinter stehenden Kommandos (durch einen harten TAB eingerückt)
aus.
p.s.: Ein separater Thread wäre sinnvoller gewesen. Du hast ja kein
Problem mit den Meshnetics-Modulen, sondern nur eins mit "make" und
"AVR Studio".
hallo!
habe grad ein großes problem:
ich habe das zigbit development kit mit complete support von meshnetics
und nutze den BitCloud-stack.
jedenfalls möchte ich in meinem netzwerk beacons versenden und damit
verbunden logischerweise auch die superframe-struktur nutzen.
jetzt habe ich mir mal ein paar header-files der mac-schicht
angeschaut,wo beacon und superframe definiert sind und dabei
festgestellt,dass einige variablen nur als Kommentar dort stehen.
beispielsweise steht in der "macstart.h":
...
// NOT used - superframe functionality is not implemented.
//uint8_t beaconOrder;
// NOT used - superframe functionality is not implemented.
//uint8_t superframeOrder;
//! If this value is TRUE, the device will become the PAN coordinator of
//! a new PAN
bool panCoordinator;
...
dieses "superframe functionality is not implemented" macht mich jetzt
ziemlich stutzig,ob mit der BitCloud-software das versenden von beacons
überhaupt geht????
für BEACON_ORDER und SUPERFRAME_ORDER steht als default-wert "15", was
bedeutet,dass der coordinator keine beacons versendet.aber diesen wert
kann man ja ändern.
andere den beacon-modus betreffende variablen stehen nicht als kommentar
dort!
kann mir jemand meine frage beantworten?ist wirklich wichtig!!!
timo wrote:
> dieses "superframe functionality is not implemented" macht mich jetzt> ziemlich stutzig,ob mit der BitCloud-software das versenden von beacons> überhaupt geht????
Ich habe mir bitcloud noch nicht angesehen, würde deiner Analyse aber
zustimmen, dass beacon-enabled networking da (noch?) nicht vorgesehen
ist.
Jörg Wunsch wrote:
>Ich habe mir bitcloud noch nicht angesehen, würde deiner Analyse aber>zustimmen, dass beacon-enabled networking da (noch?) nicht vorgesehen>ist.
ich habe grad mit der EMEA in dresden (meshnetics deutschland)
telefoniert.
da bekam ich die kurze und knappe antwort: beacon-enabled geht nicht auf
bitcloud.(sicher haben die das vor,aber aktueller stand ist halt NEIN)
zum ezeenet-stack (wo ja angegeben wird,dass optional GTS möglich ist)
wurde mir auch mitgeteilt, dass "einige" funktionen unterstützt werden.
Hallo!
Vielleicht finde ich hier jemand der mir evtl. eine Antwort geben kann:
Ich hab die Meshbean Development Boards von Meshnetics und möchte
aufgenommene Sensordaten vom End Device zum Coordinator übertragen.
Die Daten sollen aber auf jedenfall über einen Router vom End Device zum
Coordinator gelangen (also quasi eine Baumtopologie).
Meine Frage ist nun,was ich da alles am Router programmieren muss?
Reicht es etwa,das ich das Modul (z.B. über die DIP-Switches) als Router
definiere?Oder müsste ich mit Hilfe der API´s Einstellungen z.B. in der
Netzwerkschicht vornehmen??
Zwar ist in der WSN-Demo der Fall der Baumstruktur drin,aber mich
verwirrt es halt ein wenig, wenn ich mir das Netzwerk mit dem
WSN-Monitor anschaue und dort manchmal ein "Linie" vom End Device zum
Router geht und manchmal direkt zum Coordinator!?In diesen beiden Fällen
ändert sich dann automatisch auch die "Parent-Adresse" des End
Device.Einmal halt 0x0000 (für Coordinator) und sonst gegebenenfalls
eine Adresse für den Router.
Kann mir da jemand weiterhelfen?Wäre nett.
MfG,Sven
Sven wrote:
> Die Daten sollen aber auf jedenfall über einen Router vom End Device zum> Coordinator gelangen (also quasi eine Baumtopologie).
Warum ,,auf jeden Fall''? So, wie ich ZigBee verstanden habe, besteht
seine Stärke ja darin, dass es das Netz dynamisch umsortieren kann,
sodass jeweils die besten Links genutzt werden. Wenn nun das Endgerät
den ZigBee-Coordinator besser aufnehmen kann als den nächsten Router,
warum sollte jemand das Routing dann extra ,,pessimieren''? Das hat
keinen Sinn. Selbst wenn beide gleich gut zu sehen sind, entstehen
durch das Routing ja zusätzliche ,,Kosten'' (Verzögerungen, Strom-
verbrauch), sodass ein vernünftiger Routing-Algorithmus in diesem
Falle wohl immer noch den direkten Weg bevorzugen sollte.
Geh mit deinem Endgerät einfach so weit weg vom ZigBee-Coordinator,
dass der nächstgelegene Router für das Endgerät einfach die bessere
Wahl wird.
@ Jörg Wunsch:
Ja klar hast du recht. Aber das ist nunmal mein Vorhaben,die Daten über
den Weg eines Routers zu übermitteln, die von dir beschriebenen "Kosten"
mal außen vor gelassen.
Also müsste ich sicherlich bestimmte Einträge in der Routingtabellen
vornehmen,damit die Daten vom End Device zuerst zum Router gelangen. Der
Router müsste dann laut Routingtabelle erkennen, dass die Daten nicht
für ihn bestimmt sind und leitet somit die Daten an den Coordinator
weiter,oder?
Ich weiss halt nur nicht wie ich das realisieren soll?!?
theoretisch müsste ich doch definieren,dass der Router das Parent-Node
vom EndDevice ist,aber die Daten sind für ihn bestimmt sind,sondern für
'sein' Parent-Node,also den Coordinator?!
Kann man die parentAddr eines Knotens definieren?
Wenn ja wo? (ist jetzt egal ob in Bitcloud oder eZeeNet)
Hab mir gedacht,dass wenn ich dem End Device die parentAddr des Routers
zuweise,was aber nicht die Zieladresse der Daten ist,dürfte doch der
Frame auf jedenfall den Router passieren,oder?
Ich kenne beide Implementierungen nicht wirklich, aber ich glaube,
das was du da willst, ist einfach eine Vergewaltigung. Das Routing
legt ein Endgerät nicht selbst nach Gutdünken fest, sondern das Netz
implementiert Algorithmen, die es zum Ziel haben, ein möglichst
optimales (und ,,selbstheilendes'') Routing zu erreichen. Du willst
nun daher kommen und all das, was die Entwickler sich da mühevoll
ausgedacht haben, deiner Vorstellungswelt unterordnen. Das Ei will
mal wieder klüger sein als die Henne.
Wenn überhaupt, dann würde ich sowas als Entwickler bestenfalls
zu Debug-Zwecken implementieren. Wenn es dann aber nicht dokumen-
tiert ist (wer dokumentiert schon gern seine internen Debugfunktionen?)
und du keinen Sourcecode dafür hast, wirst du da wohl keine Chance
haben.
Naja BitCloud ist nach eZeeNet entwickelt worden.Es ist einfacher
aufgebaut usw.,quasi eine Verbesserung.
Ich habe den kompletten Stack-Support.Die Dokumentation beinhaltet
allerdings nicht alle Layer.
Vorhin habe ich aber z.B. in einer Pdf gelesen,dass Tree-Routing so
gestaltet werden kann wie ich das möchte,d.h. den Devices jeweils
Parent-und Childrenadresse zuordnen. Da gibt es etwa Funktionen wie
"ZDO_GetNeighborTable()" wobei ZDO die entsprechende Schicht des
BitCloud-Stack ist.
Ich habe halt schon in ein paar Dokumenten die ich mit Google gefunden
habe gelesen,dass diese NeighborTable für Tree-Routing angewendet wird.
Sven wrote:
> Da gibt es etwa Funktionen wie> "ZDO_GetNeighborTable()" wobei ZDO die entsprechende Schicht des> BitCloud-Stack ist.
Solange es aber kein ZDO_SetNeighborTable() gibt, kannst du sie doch
damit nicht ändern, oder übersehe ich hier was?
Ja das ist es leider glaube ich auch.
Im User Manual steht zu 'Get' und 'Set' nur folgendes:
"The descriptive function name may have a 'Get' or 'Set' prefix,
indicating requesting that some parameter is returned or setting that
parameter in the underlying stack,respectively (e.g.
HAL_GetSystemTime)."
hab jetzt auch nochmal den ganzen sourcecode durchgeschaut und da steht
auch keine ähnliche Funktion wie ZDO_SetNeibTable().
Aber eine Frage hätte ich trotzdem noch (auch wenn die evtl. ein wenig
dumm ist,aber mit Funk hatte ich vorher noch nicht soviel zu tun :( ):
Funktionen wie:
- void ZDO_GetParentAddr(NodeAddr_t *parentAddr) -> mit der man
Parentinformationen anfordern kann oder
- uint8_t HAL_GetSystemTime(void) -> Zeit die seit Start vergangen ist
in ms
Wird das irgendwo im AVR-Studio (IDE für BitCloud) angezeigt? Also d.h.
wie die parentAddr lautet oder die Systemzeit??
Hallo!
ich habe mal eine Frage zum BitCloud-Stack:
Wird die APS-Schicht des Stacks für das Routing von Nachrichten
benötigt?
Als ich die Funktion APS_DataInd() in meinem Routing-Programm
auskommentiert habe, war das Übertragen von Daten vom End Device zum
Coordinator nicht möglich.
Mit genannter Funktion ging es dann.War das nur Zufall?
Kann mir da bitte jemand schnell eine Antwort geben???
Danke,Freddy
Freddy schrieb:
> Wird die APS-Schicht des Stacks für das Routing von Nachrichten> benötigt?
Ich kenne BitCloud nicht explizit, aber normalerweise sollte die
NWK-Schicht fürs Routing zuständig sein.
> Kann mir da bitte jemand schnell eine Antwort geben???
Der Atmel-Support vielleicht?
Hallo zusammen,
ich habe mal eine prinzipielle Frage:
Kennt jemand einen Zigbee-Stack, der beacon-enabled network mit CFP und
GTS unterstützt. Ich habe jetzt schon eine ganze Weile gesucht, aber
noch keinen Stack mit Unterstützung dieser (optionalen) Eigenschaften
gefunden.
Der Freescale 802.15.4 MAC bietet diese Features, aber das ist eben kein
ZigBee-Stack. Sollte es keinen ZigBee-Stack geben, der das kann?
Danke und Gruß
Hein
