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
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
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
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ß
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
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ß
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!
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
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!
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.
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.
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.
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?
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.
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
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ß
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
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?
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
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.
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
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.
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
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!
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
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?
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
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?
@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?
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.