XBee for NewBees (DOS-Tool zum Testen von XBee's im API-Modus) Benötigt werden: FTDI-USB-Seriell-Adapter / ftd2xx.dll ggf: C-Compiler: z.B. Dev-C++, ftd2xx.h, ftd2xx.lib Während die Arbeit mit den XBee's im AT-Modus fast ohne eigenes Zutun funktioniert, ist die Latte für den Einstieg in den API-Modus höher gehängt. Um den Anfang und das Debuggen nicht allzu frustrierend werden zu lassen, habe ich mich entschlossen, zunächst ohne AVR ausschließlich am PC unter Dev-C++ zu arbeiten. Damit habe ich die grundlegenden Routinen erstellt und getestet - und nebenbei ist ein kleines Tool entstanden, mit dem man XBee's im API-Modus konfigurieren und ihre Arbeitsweise erforschen kann. Das Programm läuft in einem schlichten DOS-Fenster. Die Eingabe erfolgt über die DOS-Befehlszeile. Der PC ist über einen FTDI USB-Seriell-Adapter mit einer der XBee's verbunden. Die Software greift über die ftd2xx.dll von FTDI auf den Adapter zu (die Datei "cdm 2.06.00 whql certified\cdm 2.06.00 whql certified\i386.zip" muss ggf. von der Herstellersite ftdichip.com geladen werden). Getestet habe ich in einem kleinen Netzwerk mit 1 Koordinator und 2 Routern (Modem XB24-ZB, Firmware 21xx bzw. 23xx), die zugehörige Dokumentation 90000976_F.pdf ist erschöpfende Pflichtlektüre. Nach dem Laden der jeweiligen Firmware auf die XBee's (in ihrer Default-Einstellung) wurden alle weiteren Schritte aus der Befehlszeile des Tools ausgeführt. Folgende Szenarien habe ich durchgespielt und ihre Tücken erforscht: - beliebige Konfiguration des lokalen und der remote-Devices mittels AT-Kommandos, z.B. Setzen/Auslesen von Systemvariablen und Portpins, Auslesen von ADC-Werten ... - ein Router wird als Enddevice in den sleep-Modus geschickt - und wieder als Router zurückgeholt, - ein Enddevice läuft im sleep-Modus und liefert beim Aufwachen IO-Daten an ein anderen Router. Mit den Erfahrungen aus der Arbeit mit diesem Tool sollte der Einsatz eines Microcontollers zur Steuerung des Netzes deutlich leichter fallen. Dazu können Teile des C-Programmcodes in angepasster Form für den AVR genutzt werden. Und genau das war das eigentliche Ziel dieser Übung. Viel Spaß beim Funken, Michael S.
Hallo allerseits, um beim der Konzeption eines XBee-Netzes via API-Modus systematisch vorzugehen, habe ich versucht, die grundsätzlichen Möglichkeiten der Kommunikation zwischen Coordinator/Router und Enddevice auszuloten. Die Varianten sind in einem Diagramm aufgetragen. Zusätzlich sind die jeweils versandten Frame Typen dargestellt. So kann man schnell erkennen, welche Form des Datenaustausches für eine Anwendung notwendig ist und welche Frames auf den beteiligten Devices softwaremäßig implementiert werden müssen. Wie man sieht, scheint der Aufwand sich in Grenzen zu halten. mfg Michael S.
Hallo Michael, in die Materie wollte ich mich gerade einarbeiten, herzlichen Dank für die Bereitstellung! Beste Grüße, Jürgen
Hallo allerseits, zwischenzeitlich bin ich wieder einen Schritt weitergekommen. Die Kommunikation zwischen AVR und XBee steht im Grundsatz. Das Prinzip ist der PDF-Datei grafisch dargestellt. Es gibt jeweils ein gekapseltes Modul für Empfang und Senden. Auf die Module wird ausschließlich über die dargestellten Funktionen zugegriffen. In main() wird ein Flag geprüft: - Ist ein kompletes Frame empfangen ? Wenn ja, dann wird der Frame Typ ermittelt und weiter in Unterprogramme zur Behandlung der Daten verzweigt. - Sollen Daten verschickt werden ? Die für das Senden erforderlichen Daten stehen in globalen Variablen. Soweit so gut. Aber was geschieht, wenn Fehler auftreten ? Bleibt der AVR dann in einer Endlosschleife wartend hängen ? Oder ignoriert er den Fehler ? Dazu muss ich den Ablauf noch ausgiebig aus der Sicht einer Anwendung überprüfen. Im Moment denke ich daran, eine Liste anzulegen, in die die Frame_ID aller ausgehender Sendungen eingetragen wird. Beim Empfang einer Bestätigung wird die Frame_ID wieder gelöscht. Solange in der Liste Einträge vorhanden sind, stehen noch Bestätigungen aus. Aber irgendetwas fehlt da noch ... Michael S.
Hallo allerseits, eigentlich sollte man den Thread jetzt umbenennen, denn mit dieser Überarbeitung ist die direkte Kommunikation zwischen AVR und XBee im API-Modus möglich. Genaugenommen handelt sich dabei um eine Sammlung von C-Funktionen zum Formulieren von Frames (und zum Versenden derselben) sowie zum Auslesen der Frame-Komponenten empfangener Frames. Daraus eine sinnvolle Anwendung zu stricken, das ist dann der nächste Schritt (den aber jeder selbst gehen muss). Im Beispielprogramm werden im Abstand von 6 Sekunden Broadcasts versendet, die an allen mithörenden XBee's einem Pin zum Wackeln bringen (naja, eine Led zum Umschalten halt). Weitere Hinweise zum Programm finden sich in der beigefügten readme.pdf. Zum Verständnis der Arbeit mit den Frames habe ich im Diagramm "API-Kommuikation.pdf" noch kleine Ergänzungen vorgenommen Michael S.
Hallo allerseits, durch das "Verheiraten" der Programmzeilen des letzten Beitrages mit dem Modul zum Auslesen von DS18B50 Temperatursensoren (siehe Beitrag "1-wire Temperaturmessung mit DS18B20 für TINY2313 in C (ROM-Search-free)") ist jetzt eine erste nützliche Anwendung entstanden: Ein XBee, ein ATMega48 und ein (oder mehrere) DS18B50 Temperatursensoren tun sich zusammen, aquirieren Temperaturdaten und versenden diese in regelmäßigen Zeitabständen. Die XBee läuft die meiste Zeit im Sleep-Modus - und zieht auch den ATMega in den Power-Down-Modus. Die Stromaufnahme des gesamten Systems beträgt in der Sleep-Phase ca. 20µA, das sollte aber noch zu verbessern sein. Jeweils nach festgelegten Intervallen wacht die XBee auf und zieht dabei den Pin SLEEP auf high. Das wiederum weckt den ATMega auf, er stösst die Temperaturmessungen an, liest die Werte aus den Sensoren aus und sendet sie via XBee und Frame 0x10 an eine Gegenstelle. Die Gegenstation empfängt die Daten als Frame 0x90. Sobald von der Gegenstelle eine Quittierung eingegangen ist, schickt der ATMega die XBee wieder in den Sleep-Modus, der Pin SLEEP geht auf low. Woraufhin auch der ATMega sich wieder zur Ruhe legt. Weitere Hinweise gibts in der beigefügten Readme.pdf. Eine schematische Darstellung der Programmlogik und der Schaltung habe ich als XBee_DS18B20.pdf angehängt. mfg Michael S.
Hallo allerseits, hier noch einmal zurück zum Ausgangspunkt/Betreff dieses Threads. Das dort vorgestellte Tool war mir eine große Hilfe bei der 'Erforschung' der XBee's im API-Modus, wenngleich es nicht besonders komfortabel war. Seine Aufgabe ist, lokale bzw. remote XBee's mit AT-Commands zu konfigurieren und auszulesen bzw. Zeichenfolgen an ein XBee zu senden, die von einem angeschlossenen Controller weiterverarbeitet werden. Zwischenzeitlich habe ich die Bedienung und die Funktionalität noch einmal überarbeitet. Die wesentlichen Veränderungen: Das Programm fragt nun ständig die serielle Schnittstelle und die Tastatur ab (kbhit() sei es gedankt!), eingehende Daten werden ohne weiteres Zutun auf den Schirm manipuliert. Die Eingabe ist flexibler geworden: Zahlen können dezimal, hexadezimal, oktal oder binäre eingegeben werden. Das Ergebnis wird entsprechend des Wertes in 1, 2 oder 4 Byte umgewandelt. Durch ein Komma getrennt, können mehrere Zahlen hintereinander eingegeben werden. Auch das Mischen mit Textfolgen ist möglich. Die Bildschirmausgabe ist zur besseren Unterscheidung von Eingaben, gesendeten und empfangenen Daten farbig geworden. Die Programmänderungen und Hinweise zur Bedienung habe ich in der "Readme.pdf" dokumentiert bzw. korrigiert. Der Programmcode ist im File "xbee_api_101229.zip" und die ausführbare Datei in "xbee_exe.zip" beigefügt. Anmerkung: Das Programm benötigt für den Zugriff auf die serielle Schnittstelle unverändert die ftd2xx.lib und einen FTDI USB-Adapter und ist bei mir unter XP SP3 getestet. Viel Spaß beim Funken, Michael S.
Hallo allerseits, ein kleinwenig Kosmetik als Nachtrag. Während der letzten Programmtests hatte mich gestört, dass Leerzeichen in der Eingabezeile wie ein RETURN wirkten - und daher den Rest der Eingabe verworfen haben. Den Hinweisen aus der Bibel von K+R folgend hatte ich kurzerhand scanf() gegen readline() ausgetauscht. Nun werden am Prompt auch Leerzeichen angenommen. Allerdings sind nun auch leere Eingaben möglich (bei scanf() dagegen nicht). Auf eine leere Eingabe hin wurde das Programm bislang aber beendet. Das ist nicht tragisch, aber auch nicht elegant. Der geschulte Verkäufer würde vermutlich sagen: "It's not a bug, it's a feature!" Im geänderten Programm wird nach einem RETURN (ohne Eingabe) eine neue Zeile mit einem neuen Prompt ausgegeben, so wie man es von der OS-Ebene her gewohnt ist. Michael S.
Hallo allerseits, folgende Erweiterungen sind noch eingebaut: - Das Programm aktualisiert automatisch die 16BitNetzwerkadressen (die vom Coordinator vergeben werden). - Wenn bei einem 'ATND' ein Frame einer noch nicht bekannten Station im PAN empfangen wird, dann wird deren Adresse in den Adresspool übernommen. - Daraus ergibt sich, das die Adressen der Radios nicht mehr in der 'xbee_adr.cfg' definiert werden müssen (aber dürfen). Die Datei 'xbee_adr.cfg" kann sogar fehlen. Um die Adressen der präsenten Stationen einzulesen, muss lediglich per broadcast ein 'ATND' versandt werden. Nachteilig ist allerdings, dass damit die Reihenfolge der Stationen in der Liste zufällig ist. Den Jahreswechsel habe ich benutzt, um von DEV-C++ zu Codeblocks als IDE zu wechseln. Dabei wurde mir bewusst, dass ich unter DEV-C die ganze Zeit mit deaktivierten Compilerwarnungen gearbeitet hatte. Peinlich lang war die Liste der Warnungen ... Aber ich habe aufgeräumt. Viel Spaß beim Funken, Michael S.
Das ist kein DOS-Tool, sondern eine Windoof-Konsolenapplikation!
Hallo Klugscheißer, Danke für den Hinweis, ich widerspreche auch nicht. Die Formulierung "DOS-Tool" war als Arbeitstitel entstanden, weil das Tool in einer "DOS-Box" unter Windows läuft. Aber es ist richtig, die Bezeichnung "DOS-Tool" ist mißverständlich bzw. sogar falsch. Michael S.
Hi Michael, deine Beschreibungen sind wirklich Gold wert! Gerade, weil die Doku von Digi nicht so gut ist... Vielen Dank dafür! Schade, dass es hier so wenig interesse zu dem Thema gibt. Hab bisher nur gute Erfahrung gemacht mit den Xbee Modulen... Gruß aus Aachen, Patrick
allen voran: Danke für die ausführlichen Beschreibungen Michael S. schrieb: > Die Formulierung "DOS-Tool" war als Arbeitstitel entstanden, weil das > Tool in einer "DOS-Box" unter Windows läuft. das tut es ebend nicht. Es läuft in einer Shell/Kommandozeile (cmd.exe). Weiterhin kann ich dir nur dazu raten, diese IDE wegzuschmeißen. die Entwicklung ist tot und die Bibliotheken total veraltet. Steige lieber auf was moderneres um, wie code::blocks oder visual studio express http://www.cplusplus.com/forum/articles/36896/ http://www.c-plusplus.de/forum/237002
Hallo, ich beschäftige mich gerade mit XBee Modulen. Geplant ist ein Sensor Mesh-Netzwerk. Hierbei ist der Gedanke, dass die Kommunikation übr den transparenten Modus läuft. Besser würd es wohl mit der API der XBee Module laufen. Ich komme aber nicht ganz hinter den Ablauf und die Funktionsweise... Geplant ist Pro XBee Modul im Netzwerk auch je ein AVR. Leider habe ich bislang keine gute Dokumentation gefunden. Danke!
Hallo, gleiches mache ich zur Zeit auch wieder (nachdem die Arbeit lange geruht hat). Zuerst aber: Für den Aufbau eines Netzwerkes solltest Du unbedingt im API-Modus arbeiten. Der ist in der Dokumentation gut beschrieben, allerdings muss man sich den Text auf der Zunge zergehen lassen und durchaus mehrfach lesen (um jedesmal etwas mehr zu verstehen). Das Prinzip im API-Modus ist: Alle Nachrichten werden in Frames definierten Formates verpackt. Die unterschiedlichen Frames sind in der Doku ausführlich erläutert (o.k. zu den Fehlermeldungen hätte ich mir weitergehende Erklärung gewünscht). Die Kunst besteht lediglich darin, die zu sendenden Frames zu formatieren bzw. empfangene Frames zu interpretieren. Ein weiteres, entscheidendes Argument für die Arbeit im API-Modus ist: Man kann AT-Kommandos an Remote-Devices absetzen (also über Funk andere XBee's konfigurieren). Das ist - nicht nur zum Testen - extrem nützlich: So kann ein XBee ohne einen zusätzlich Controller für allerlei Aufgaben eingesetzt werden (Schalterstellungen auslesen, Änderungen von Schalterstellungen erkennen, Ports setzen = Schalten, Spannungen auslesen etc.). Nachdem Du in der Lage bist, die Frames zu bändigen, ist alles andere eine Frage Deiner Anwendung und unterliegt Deiner eigenen Definition. In den Beiträgen dieses Threads habe ich dokumentiert, wie ich selbst die XBee's im API-Modus "erforscht" habe. Vielleicht hilft es Dir ja weiter. Natürlich gibt es immer noch Verbesserungen und Vereinfachungen. Und das "Dos-Tool" ist eine Krücke - keine Diskussion. Aber es war und ist für mich extrem hilfreich beim Testen und Verstehen der Kommunikation. Und zusätzlich leite ich aus dem Programmcode, der auf dem PC geschreiben und getestet wird, die Routinen für den AVR ab. mfg Michael S.
Hallo Michael, vielen Dank für deine ausführlichen Informationen. Die Dokumentation habe ich schon eingige Male gelesen. 4 Module sollten demnächst bei mir eintrudeln. Insgesamt erscheint mir der API-Modus sehr kompliziert. Ich habe nämlich noch nicht verstanden, wo da in den Frames Platz für eigene Parameter ist... Ich muss mir erst mal einenen Beispielbefehlssatz schaffen...
Hallo Ch Sp,
> Ich muss mir erst mal einenen Beispielbefehlssatz schaffen...
Genauso habe ich auch begonnen.
Das Ergebnis meiner Untersuchung hatte ich am 21.05.10 versucht, als
Diagramm grafisch darzustellen.
Ich will am Abend mal prüfen, ob der Inhalt meinem heutigen
Kenntnisstand entspricht.
Auf der Seite 102 der Doku 90000976_G.pdf finden sich übrigens ähnliche
Skizzen.
Was mich - bis heute - irritiert, das ist die unübersichtliche Vielfalt
der Firmwareversionen.
Da fällt es schwer, sich für eine zu entscheiden.
Ich habe mich am Ende auf die Version eingeschossen, die in der
Dokumentation oben beschrieben ist und positive Erfahrung gemacht.
mfg
Michael S.
Hallo, ich hatte gehofft, irgendwo einen BASCOM-Schnipsel zu finden... Naja. Ich versuche mich mal weiter einzuarbeiten. Danke!
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.