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
Hallo. Weiss jemand,ob für den Bitcloud-Stack Kostenlizenzen oder Etwaiges anfallen? Wenn ja, auf welche Preise belaufen sich diese? MfG,Sebastian
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?
"missing separator" klingt nach kaputtem Makefile.
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:
1 | Build started 14.1.2009 at 15:55:36 |
2 | Makefile:60: *** |
3 | ------------------------------------------------ |
4 | Usage: make <platform> |
5 | make clean |
6 | |
7 | Supported platforms are: meshbean2 rz502 rz200 |
8 | For example: make meshbean2 |
9 | ------------------------------------------------. Stop. |
10 | Build failed with 1 errors and 0 warnings... |
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
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.