www.mikrocontroller.net

Forum: Projekte & Code XBee for NewBees (DOS-Tool zum Testen von XBee's im API-Modus)


Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

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

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

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

Autor: jtre (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

in die Materie wollte ich mich gerade einarbeiten, herzlichen Dank für 
die Bereitstellung!

Beste Grüße,  Jürgen

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

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

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

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

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

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

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

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

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

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

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

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

Autor: Klugscheißer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist kein DOS-Tool, sondern eine Windoof-Konsolenapplikation!

Autor: Michael S. (Gast)
Datum:

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

Autor: Patrick F. (Firma: AISLER B.V.) (helipaddi)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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

Autor: Ch Sp (spelli)
Datum:

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

Autor: Michael S. (Gast)
Datum:

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

Autor: Ch Sp (spelli)
Datum:

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

Autor: Michael S. (Gast)
Datum:

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

Autor: Ch Sp (spelli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hatte gehofft, irgendwo einen BASCOM-Schnipsel zu finden...

Naja. Ich versuche mich mal weiter einzuarbeiten.

Danke!

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.