Forum: HF, Funk und Felder Adressieren mehrerer XBee's


von Torsten O. (Gast)


Lesenswert?

Hallo,

ich habe eine kurze Frage zum ansprechenden von XBee Modulen. Ich habe 
ein Netzwerk aus drei XBee Modulen. Jetzt möchte ich vom meinem Master 
aus (Koordinator) beide Slaves (Router/End Device) abwechselnd 
ansprechen. Ich nutze kein API.

Eine Möglichkeit ist, die Zieladresse mit Hilfe von '+++', 'ATDH', 
'ATDL' jedes Mal zu ändern. So wie ich die Sache sehe dürfte das aber 
nicht unendlich oft möglich sein, da diese Adresse ja im Speicher 
abgelegt wird. Ich gehe mal davon aus, dass es sich dabei um einen 
EEPROM handel, oder?

Wenn das nun so sein sollte ist ein EEPROM nicht beliebig oft 
beschreibbar. Gibt es noch eine Möglichkeit die Zieladressen zu ändern?

Vielen Dank im voraus


lg Torsten

von Thomas B. (escamoteur)


Lesenswert?

Wieso gehst Du davon aus, dass die ZIELADRESSE im EEPROM liegen sollte? 
Macht doch überhaupt keinen Sinn und wäre wohl auch zu langsam.

Im Datenblatt ist jedensfalls nichts derartiges zu finden. Außerdem ist 
Deine Anwendung, von einem Knoten aus viele andere anzusprechen ja der 
Sinn von ZigBee.
Tom

von Torsten O. (Gast)


Lesenswert?

Aha, also kann ich davon ausgehen, dass meine Variante so richtig ist? 
Aber in welcher Art von Speicher liegen dann diese "Einstellungen"? Ein 
flüchtiger Speicher kann es ja nicht sein? grübel

Aber danke trotzdem für die superschnelle Antwort :)


lg Torsten

von Jean Player (Gast)


Lesenswert?

Hi,
ich gehe davon mal aus, das du deine Einstellungen per X-CTU vornimmst.
Dann schreibst du direkt in den Flash.
Alle Eistellungen, die mittels AT-Befehlen vornimmst, gehen ins RAM und 
sind somit flüchtig.
Gruß

von Torsten O. (Gast)


Lesenswert?

Also jetzt muss ich doch noch mal nachfragen, sorry. Wenn ich die 
Zieladresse mit Hilfe von X-CTU ändere und speichere (also via "Modem 
Configuration") bleibt die Zieladresse auch nach dem Trennen der 
Stromversorgung erhalten, gleiches gilt wenn ich es über das integrierte 
Terminal von X-CTU mache ("+++", "ATDHxxxxxx", "ATDLxxxxxxxx").

Wenn ich aber von meinem Arduino aus die AT - Kommandos sende bleiben 
sie nicht erhalten nach der Trennung vom Strom? Wie kann das sein?


lg Torsten

von Jean Player (Gast)


Lesenswert?

Torsten Ohne schrieb:
> Zieladresse mit Hilfe von X-CTU ändere und speichere (also via "Modem
> Configuration") bleibt die Zieladresse auch nach dem Trennen der
> Stromversorgung erhalten,
logisch, du schreibst ins Flash.

Torsten Ohne schrieb:
> gleiches gilt wenn ich es über das integrierte
> Terminal von X-CTU mache ("+++", "ATDHxxxxxx", "ATDLxxxxxxxx").
Werde ich später mal testen, aber glaube ich nit, es sei denn du 
schreibst noch ein ATWR hinterher.


Torsten Ohne schrieb:
> Wenn ich aber von meinem Arduino aus die AT - Kommandos sende bleiben
> sie nicht erhalten nach der Trennung vom Strom? Wie kann das sein?

Hmm,
theoretisch und auch bei mir praktisch, bleiben die Einstellungen, die 
via At Befehlen vorgenommen wurden, nur erhalten, wenn man ein ATWR 
schreibt, welches bewirkt, das die Einstellungen im nicht flüchtigen 
Speicher landen.

Gruß

von Harald (Gast)


Lesenswert?

An deiner Stelle würde ich mir (insbesondere bei > 2 Modulen) den 
API-Modus noch mal näher anschauen. Am besten sogar gleich den API-Mode 
2, dann hat man niemals Synchronisationsprobleme. Nach einer 
vergleichbar kleinen Lernphase gewinnt man sehr hilfreiche Vorteile bzw. 
Funktionalitäten. Nur keine Angst davor!

von Torsten O. (Gast)


Lesenswert?

Hallo Harald,

also ich glaube ich stoße jetzt an meine Grenzen mit dem AT-Modus. 
Grundlegend funktioniert das alles. Aber kann es sein, dass nach man den 
Kommandomodus aufgerufen und wieder verlassen hat einen Moment warten 
muss bis man ihn erneut "betreten" kann?

Vielleicht hast du ja auch einen guten Literaturtipp, so dass ich mich 
möglichst schnell in diesen API-Modus einarbeiten kann. Es handelt sich 
dabei nämlich um meine Bachelorarbeit, die Zeit läuft. Wenn das nicht so 
schnell machbar ist, müsste ich auf die Regelung einer zweiten Strecke 
vorläufig verzichten.

Vielen Dank im voraus


lg Torsten

von Harald (Gast)


Lesenswert?

Hallo Torsten,
im Grunde genommen reicht das Datenblatt völlig aus. Source kann ich dir 
leider nicht geben, aber eine grobe Anleitung.

Init
====
Init kannst Du immer(!) mit <1sec warten> +++ <1sec warten> machen, um 
in den COmmand Mode zu kommen. Dann
"ATAP2,CN" + Enter senden. Das ist dann ein Wechsel in den API-Mode 2 
und anschliessenden Verlassen des Command-Modes. Sofort danach geht es 
im API-Mode weiter. Aufgrund des obigen zusammengefassten Befehls sendet 
das Modul 2x OK + Enter. Diese können einfach verworfen werden. Man kann 
als erstes eine einfache Dummy-Abfrage machen (z.B. Channel-Nr. abfragen 
mit 'CH'), dann weiß man, dass der API-Mode funktioniert.

Anschliessend API-Frames senden, wie diese im Datenblatt im Kapitel API 
beschrieben sind. Man kann das auch im Programm X-CTU manuell 
durchspielen, es gibt ein entsprechendes Fenster, um HEX-Werte 
einzugeben. Leider muss man die Checksumme im Taschenrechner selbst 
durchrechnen, dafür gibt es keine Unterstützung.

Bzgl. "geschützte" Zeichen im API-Mode 2:

Beim Senden:
============
Prüfen, ob 0x11 0x13 0x7D oder 0x7E gesendet werden soll. Falls nein, 
normal weitermachen. Falls ja:
0x7D senden (ESC character), dann obiges Byte XOR 0x20.
Dann weitermachen mit weiteren Zeichen.

Beim Empfangen:
===============
0x7E empfangen --> Markiert neuen Frame, egal was vorher war.
0x7D empfangen --> Nächstes Zeichen abwarten und dieses mit 0x20 XOR 
verknüpfen. Dieses Resultat ist dann das eigentliche Zeichen.

Anhand der gegebenen Länge der Frames und der Kennzeichnung mit einer ID 
kann man diese sehr schön in einer State Machine verarbeiten. Ist 
wirklich keine hohe Kunst, lässt sich alles in 100 Zeilen Programmcode 
verarbeiten.

Der oft zu Unrecht gescholtene beschriebe API-Mode 2 mit den 
"geschützten Zeichen" bietet den großen Vorteil, dass man eigentlich 
niemals die Synchronität verlieren kann, denn 0x7E markiert immer einen 
neuen Frame. Wenn man das nicht hätte und das Modul z.B. noch auf 
Zeichen wartet, könnte man sehr schlecht wieder die Synchronität für 
einen neuen Frame herstellen. Normalerweise sollte das ja eh nicht 
passieren, da man nichts verlieren möchte. Andererseits kann das gerade 
am Anfang viel Kopfzerbrechen ersparen.

Beim Googeln kann man einige Beispiele finden, die raten aber teilweise 
vom API-Mode 2 ab (haben's offensichtlich nicht verstanden), 
andererseits sind die entstandenen Beispiele bzw. Treiber oftmals 
komplex und schwer zu durchschauen.



Viel Erfolg!

von Michael S. (Gast)


Lesenswert?

Hallo Harald,

wenn du absolute nicht in den API-Modus wechseln möchtest - und wenn du 
die XBee sfotwaremäßig programmierst, dann gibt es folgende eine Krücke:

1. Die Guard-Time auf z.B. 100ms reduzieren.
2. Zum Senden eines AT-Commands zuerst
   100ms (= Guard-Time) warten,
   dann das AT-Command senden,
   dann das AT-Command zum Übernehmen senden.

Auf diese Art kann man "relativ" schnell Veränderungen in der 
Konfiguration der XBee vornehmen, ohne die Hürde des API-Modus nehmen zu 
müssen.

Allerdings kann man viele Vorteile, die dieser Modus bietet, so nicht 
nutzen.
Z.B. kann man keine remote-device knonfigurieren.

Michael S.

von Dieter (Gast)


Lesenswert?

Beim mir tritt derzeit das Problem auf, dass ich zyklisch im Abstand von 
1s ein Frame von A nach B übertragen will. Abgeschickt werden die Daten 
punktgenau. Der Empfänger aber "sammelt" diese scheinbar und gibt diese 
gebündelt aus. (z.B. 3 Frames auf einmal - so als wären diese en bloc 
angekommen). Dabei kann schon mal ein Verzug von 2-3s entstehen. Das ist 
natürlich nervig. Der Versatz tritt allerdings erst nach 5..6 gesendeten 
Botschaften bzw. Sekunden ein.
Kann sich jemand darauf einen Reim machen?

PS: Ich verwende den API-Mode.

von Michael S. (Gast)


Lesenswert?

Hallo Dieter,

werden eingehende Frames nicht abgeholt, dann sammeln sich mehrere davon 
im Empfangspuffer an.

Ich würde prüfen, ob

- die serielle Schnittstelle hinreichend häufig abgefragt wird,
- die die Empfangsroutine korrekt funktioniert.


Michael S.

von Dieter (Gast)


Lesenswert?

Meiner Meinung nach wird die serielle Schnittstelle häufig genug 
abgefragt und auch die Empfangsroutine arbeitet korrekt. Und auch die 
Versenderoutine arbeitet korrekt (mit Oszi und Togglepin geprüft).
Werde ich aber natürlich alles nochmal explizit prüfen.

Das heisst aber im Umkehrschluss, dass du solche "Steckenbleiber" noch 
nicht beobachtet hast?

von Michael S. (Gast)


Lesenswert?

Hallo Dieter,

nein, dieses Problem habe ich nicht beobachtet.
Bzw. nur dann, wenn der Empfang nicht über den RX-Interrupt läuft und 
ich die Schnittstelle nicht häufig genug abgefragt habe.

Vielleicht ist das ja das Stichwort - Abfrage des RX-Interrupt ??

Michael S.

von Torsten O. (Gast)


Lesenswert?

Hallo Harald,

erstmal vielen Dank für die sehr ausführliche Beschreibung, ich werde 
das die Tage mal ausprobieren.

Eine Frage habe ich noch zu den Übertragungszeiten. Ich habe mir zwei 
Programme geschrieben die folgendes bewirken.

xBee 1 sendet ein einzelnes Byte an ein xBee 2. Dieses bestätigt den 
Empfang durch ebenfalls ein gesendetes Byte, ist dieses am xBee 1 
angekommen messe ich die Sende/Empfangsdauer. Diese liegt grob zwischen 
(20..30)ms. Ist das normal?

Ich muss dazu sagen, dass ich keinen speziellen Modus der xBee Module 
verwende, also ich "sende" bzw. "empfange" die Daten zw. µC und xBee 
ganz normale über die RS232.

Das Ziel dieser Kommunikation zwischen zwei oder auch mehreren xBee 
Modulen soll eine Regelung von verschiedenen Strecken bzw. Sensor/Aktor 
- Netzwerken sein. Im Moment nutze ich als Strecke OPV's. Aufgrund 
dieser großen Totzeiten ist eine Regelung von schnellen Strecken absolut 
unmöglich. Daher die Frage ob das mit xBee Modulen irgendwie schneller 
geht?



Vielen Dank

lg Torsten

von Jean Player (Gast)


Lesenswert?

Torsten Ohne schrieb:
> Eine Frage habe ich noch zu den Übertragungszeiten. Ich habe mir zwei
> Programme geschrieben die folgendes bewirken.
>
> xBee 1 sendet ein einzelnes Byte an ein xBee 2. Dieses bestätigt den
> Empfang durch ebenfalls ein gesendetes Byte, ist dieses am xBee 1
> angekommen messe ich die Sende/Empfangsdauer. Diese liegt grob zwischen
> (20..30)ms. Ist das normal?

Unsinnig. Xbee kümmert sich darum selber !!!
Das Xbee Protokoll sendet selber ACK's hin und her.
Ich nutze derzeit nur das ZNET Protokoll aber ich meine alle nutzen 
Ack's und CRC !


Gruß

von Torsten O. (Gast)


Lesenswert?

Okay, also ob die xBee's das nun nutzen spielt ja erstmal keine Rolle. 
Ich frage mich nur, ob diese "riesigen" Latenzzeiten normal sind?

lg Torsten

von Harald (Gast)


Lesenswert?

Hallo Torsten,

wenn Du bisher nicht den API-Mode verwendest, muss ja nach dem Versand 
eines Zeichens erstmal das Timeout ("Wartezeit auf weitere Zeichen") 
ablaufen. Die kann man einstellen. Das gleiche dann nochmal auf der 
anderen Seite.
Ist aber alles suboptimal, mit dem API-Mode wird zu einem definierten 
Zeitpunkt gesendet, nämlich nach Abschluss des Frames. Eine Bestätigung 
vom anderen Modul ist indes völlig überflüssig, Du bekommst einen 
API-Frame über den Erfolg der Übertragung.
Auf äquidistante Übertragung von Werten für eine Regelung kann man aber 
noch immer nicht 100%tig setzen, da bei einer Belegung des verwendeten 
Kanals evtl. 1..n Übertragungen daneben gehen und erst n+1 erfolgreich 
ist.

Weiterhin: Welche Baudrate wird auf der Seriellen verwendet? Bedenke, 
die Datenrate over-the-air ist mit immerhin 250kBit angegeben, meist ist 
die eigene Serielle der eigentlich Bremsschuh. Du kannst mit Hilfe des 
Baudratenregisters im XBee auch untypische sehr hohe Baudraten erzielen 
(z.B. 250kBit müsste gehen, bitte prüfen), es müssen nicht zwangsläufig 
typische "Norm"baudraten verwendet werden.

Ergo: Die schhellstmögliche Übertragung lässt sich nur per API 
realisieren. Weiterhin gibt es in der Knowledge-Base von digi.com auch 
ein Dokument von zu erwartenden Latenzen.

P.S. In welcher Gegend von Deutschland schreibst Du deine Arbeit?

von Torsten O. (Gast)


Lesenswert?

Hallo Harald,

nochmals vielen Dank für die vielen Informationen. Ich teste das alles 
mal durch, sobald mein DA-Wandler richtig funktioniert. Im Moment arbeit 
ich mit 9600 Baud, also nicht wahnsinnig viel. Ist aber auch ein guter 
Ansatz. Die API-Geschichte schaue ich mir dann auch genauer an. Ich 
wohne und schreibe meine Bachelorarbeit in Berlin, warum fragst du?

lg Torsten

von Harald (Gast)


Lesenswert?

Zur Frage des Studienortes: Manchmal ist es ja so, dass die Frage 
vielleicht aus einer benachbarten Uni/FH kommt, mit denen man eh zu tun 
hat. Dann hätte ich mir das mal vor Ort angeschaut.

Übrigens ist Wartezeit zum Sammeln der Daten mittels "ATRO" einstellbar:

Packetization Timeout. Set/Read number of character times of 
inter-character delay required before transmission. Set to zero to 
transmit characters as they arrive instead of buffering them into one RF 
packet.

von Torsten O. (Gast)


Lesenswert?

Hallo Harald,

ich habe jetzt mal angefangen mich mit dem API Modus zu befassen. 
Zunächst mal mit dem ersten, da mir die Geschichte mit den 
Escapesequenzen noch nicht so ganz klar ist.

Das xBee Modul ist auf API eingestellt und ich sende folgende Bytes via 
RS232 (Beispiel aus dem Digi XBee Datenblatt) :

// Start
0x7E

// Größe
0x00
0x05

// AT Kommando
0x09

// Frame ID
0x01

// Kommando BD
0x42
0x44

// Parameter
0x07

// Checksumme
0x68

Wenn ich dann die Baudrate überprüfe stelle ich fest, dass sie sich 
nicht geändert hat. Woran kann das liegen?

lg Torsten

von Harald (Gast)


Lesenswert?

Aus dem Datenblatt:

Modified interface data rates do not take effect until the CN (Exit AT 
Command Mode) command is issued and the system returns the 'OK' 
response.

Ansonsten sieht der Frame und die Checksumme schon mal korrekt aus. Eine 
Atwort solltest Du also erhalten, auf der alten Baudrate.

von Torsten O. (Gast)


Lesenswert?

Hallo Harald,

also so langsam geht es voran. Ich habe jetzt folgende Sequenz gesendet 
um mir die NodeIdentifier anzeigen zu lassen :

// API Frame senden
softSerial.print((byte)0x7E);

// Länge
softSerial.print((byte)0x00);
softSerial.print((byte)0x05);

// 'AT Command'
softSerial.print((byte)0x08);

// 'Frame ID'
softSerial.print((byte)0x52);

// 'NI'
softSerial.print((byte)0x4E);
softSerial.print((byte)0x49);
softSerial.print((byte)0x0D);

// Checksumme
softSerial.print((byte)0x01);

Ich bekomme nun tatsächlich auch eine Antwort :

0x7E
0x00
0x05
0x88
0x52
0x4E
0x49
0x00
0x8E

Für mich sieht das nach so einem Command Response aus. Die Frage die 
sich mir nun stellt :  Wo bleibt der Rest? Als NodeIdentifier habe ich 
"CTRL" im xBee Modul gespeichert. Sollte das jetzt nicht auch gesendet 
werden?


lg Torsten

von Torsten O. (Gast)


Lesenswert?

Also das Senden von Daten via API funktioniert freu

lg Torsten

von Harald (Gast)


Lesenswert?

Also klappt dann alles?

Eine Antwort über den Erfolg bekommt man nur, wenn die Frame-ID nicht 0 
ist. Aber das hast Du ja so richtig gemacht!

von Torsten O. (Gast)


Lesenswert?

Ja, soweit erstmal schon. Die Sache mit der FrameID ist mir aber noch 
unklar. Was für einen Wert repräsentiert die FrameID?

Wie ist das jetzt mit dem Auslesen der NodeIdentifier? Ich bekomme als 
Antwort, dass das AT Commando erfolgreich war. Aber die NodeIdentifier 
wird dennoch nicht gesendet, so dass ich sie auslesen kann?


lg Torsten

von Harald (Gast)


Lesenswert?

Die FrameID ist einfach nur eine (idealerweise) fortlaufende Nummer. 
Anhand dieser kann man die Antworten den vorausgegangenen Anfragen 
zuordnen, sofern man mehrere auf einmal gesendet hat. Es muss ja nicht 
zwangläufig im Ping-Pong Verfahren gearbeitet werden, man kann das Modul 
quasi im gewissen Maße zuballern.

NI: Der String steht in der Antwort. Wenn deine Antwort nur "NI" 
enthält, dann bedeutet das, dass der NodeIdentifier von dir vorher noch 
nicht gesetzt wurde - der Inhalt ist also "leer". Mache doch mal den 
Test und setze diesen mittels X-CTU oder auch per Programmierung und 
lese dann nochmal aus.

Der NI ist ja auch nur ein beliebiger zuweisbarer Knotenname, der keine 
weitere Relevanz hat. Wolltest Du vielleicht anstatt dessen die 64-bit 
MAC oder die 16-bit Adresse (MY) auslesen?

von Torsten O. (Gast)


Lesenswert?

Hallo nochmal,

also das Auslesen der SerialLow mit Hilfe des API Frames funktioniert. 
Die NodeIdentifier kommt allerdings nicht an, mit X-CTU kann ich sie 
lesen. Ich habe auch "CTRL" programmiert grübel

Das xBee Modul liefer mir als Response ein 0x00, also OK, zurück. Muss 
ich das verstehen?

lg Torsten

von Harald (Gast)


Lesenswert?

Schau mal in die Firmware-History, vielleicht ist da etwas bekannt.

In deinem obigen Beispiel sendest Du nach dem 'N' und 'I' noch ein 0x0D 
hinterher? Warum? Damit würdest Du doch schon 0x0D als NodeIdentifier 
zuweisen, oder?

von Josef H. (josef_h85)


Lesenswert?

@Harald

Du hast geschrieben: "Es muss ja nicht
zwangläufig im Ping-Pong Verfahren gearbeitet werden, man kann das Modul
quasi im gewissen Maße zuballern."

Wird die Datangeschwindigkeit dadurch erhöht?
Ich bekomme nur eine langsame Verbindung im API=2 Mode zustande. Ich 
sende einen Frame mit möglichst großer Payload. Dann warte ich die 
TxResponse ab und werte diese aus. Bei OK sende ich den nächsten Frame 
usw. . Ich komme dabei auf Nutz-Datenraten von etwa 1KB/s. Interface 
wird mit 115200Baud betrieben. Ich finde das das viel zu langsam ist. 
Wenn ich die Payload verkleinere dann ist die Antwortzeit (TxRespone) 
auch etwas schneller, die Datenrate wird jedoch insgesammt etwas 
geringer.

Ich verwende 16-Bit Addressen, keine Verschlüsselung und habe schon 
versucht die ACK's auszuschalten (MAC-Mode=3). Das hat alles keinen 
Einfluss zwischen sendes des Frames und der Antwort der TX-Respone 
vergehen fast immer 100ms.

Ich habe einen Coordinator und zwei End-Devices, wobei aber immer nur 
ein End-Device sendet.

Im Transparent-Mode hab ich bei Messungen etwa 10KB/s erreicht, warum 
ist der API-Mode (auch ohne ACK) so viel langsamer?

Hier die Infos zu den Latenzen:
http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=3065

Kann es irgend einer Einstellung der XBees liegen?

von Torsten O. (Gast)


Lesenswert?

Ich habe was die Zeiten angeht das gleiche Problem. Ich versuche ja nun 
eine Regelung via Funkstrecke zu machen, d.h. :  der Regler bekommt den 
Sollwert über einen analogen Eingang (µC), den Istwert der Strecke via 
xBee und errechnet daraus den Stellwert (PI - Regler). Der Stellwert 
wird dann wiederrum via xBee an die Strecke gesendet. Aufgrund der 
großen Latenzzeiten kann ich maximale alle 150ms einen Stellwert senden, 
und das bei nur einem Sensor/Aktor - Konten (Strecke). Es sollen aber 
mehrere Konten geregelt werden. Ergo :  Mit xBee lassen sich nur relativ 
langsame Strecken regeln.

lg Torsten

von Harald (Gast)


Lesenswert?

Das mit dem Ping-Pong Verfahren bezog sich auf die Parametrierung. Da 
muss man nicht erst jeden Frame abwarten, sondern kann mehrere Kommandos 
kurz hintereinander absetzen. Die Zuordnung über den Erfolg kann dann 
über die FrameID erfolgen.

Die Frage zum Datendurchsatz würde ich mal an Digi Deutschland stellen 
(Dortmund). Die sind dort sehr hilfsbereit, versuche es einfach mal. Mit 
hohen Datendurchsätzen hatte ich bisher keine Erfahrung.

Bitte 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
Noch kein Account? Hier anmelden.