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 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.
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.
