XBee Module - Kommunikation PC <-> ATmega - Datenanzei

Hallo

Ich habe nach einigen Mühen eine Kommunikation Xbee <-> Xbee zum laufen bekommen; ein Xbee hängt am UART eines ATmega8 ,eines am USB Port meines PC; es sind beides Xbees Modell XB24-BWIT-004 von watterott; eines ist als Router konfiguriert, eines als Coordinator; die Übertragung klappt, ich kann mit HTerm die empfangenen Date anzeigen und in ein File abspeichern. Übertragungsrate 38400 Baud.

Der ATmega8 sendet alle 500ms Daten alle Daten - wenn ich sie im Textfile ansehe, werden die Daten nicht als 1 Datenpaket angezeigt, sondern "aufgedröselt" mit 16ms - siehe angehängtes File, wobei die Pakete, die in den 16ms aufgezeichnet werden, auch unterschiedlich lang sind. Die Daten zusammen sind korrekt, die Sendepausen von ca 500ms stimmen auch, nur die Datenpaketaufteilung verstehe ich nicht. Muss ich da bei den Xbee-Modulen noch irgendwo etwas einstellen?

Eingestellt habe ich bei den Modulen nichts außer der Baudrate und "Coordinator" und "Router" und die Adressen...

mfg

Hero_123

siehe angehängtes File ?

Hi Gast

Melde Dich an, dann kannst Du es downloaden

Wenn ich mich nicht täusche, versendet das XBee Datenpakete. D.h. es kann passieren dass es halt wartet bis das paket voll ist. Schau aber lieber noch mal im Datenblatt. Da sollte das genau erläutert sein.

Hi

habe da mal im Datenblatt nachgeschaut, werde da aber nicht so ganz schlau daraus; so wie es aussieht sind 2 Parameter wohl wichtig:

- Serial Interfacing -> RO - Packetization Timeout - war 3, habs auf 0 gestellt (beim Sender "End Device" und beim Empfänger "Coordinator"), dann fkte der Empfänger nicht mehr (der Coordinator hat keine Signale mehr empfangen,owohl der Sender munter gesendet hat)

- Sleep Modes -> SP - Cyclic Sleep Period - ist bei mir auf 20 gestellt; habe ich noch nicht verändert...

Jedenfalls nerven diese 16 ms - muß mal checken, was aufgezeichnet wird, wenn ich z.B. mit 10ms Zykluszeit sende (also alle 10 ms) - nehme an, daß dann Daten verschluckt werden...

hat da jemand schon mal ebensolche Erfahrungen gemacht? Wenn ja, wie wurden sie gelöst?

Die Xbees sind XB24-B mit Werkseinstellungen, gesendet wird 8N1, 38400 Baud

mfg

Hero_123

Ich glaube das es folgende Grund gibt : Das Protokoll von Xbee ist nach eine Standard "Xbee" aufgebaut. Da darf jede Teilnehmer nur 5% von der Zeit das Sendekanal besetzen, sodas ein Kanal mehrere Xbee modulen bedienen kan. Damit werden jede 16 mS eine Pakket gesendet, unabhangig von die 500 mS von UART von AVR. Das Xbee fullt jeden 16 mS pakket nach Bedarf aus seine Buffer und schickt es ab. Solange den Buffer kein Overflow hat, ist doch alles OK, nicht ?

Hm, das klingt einleuchtend, aber ich habe dann ein Problem - wenn ich alle 500ms Daten schicke, dürfen diese Daten nicht zu groß (=umfangreich oder zu lang) sein; mir ist es schon passiert, daß ich Daten gesendet habe (mehr als 400 byte), und da wurden Daten "verschluckt", ich habe mir die gesendeten Daten per HTerm anzeigen und in eine Datei schreiben lassen, und da war ganz klar zu sehen, daß da Daten gefehlt haben (da hätte z.B. stehen sollen "Bodensensoren: 233", es stand aber nur da "Bodens" und dann kam schon der nächste Wert -> BufferOverflow...wenn ich weniger Daten sende, werden zumindest alle Daten übertragen

Was kann man da machen? Ich kann bei meinen USART leider kein RTS/CTS anschliessen (hardwaremässig nicht möglich), sodaß ich eine Steuerung des Sendeflusses hätte...

gibt es keine Möglichkeit beim Xbee, diese 16ms "Gedenkpause" zu elimieren? Was würde überhaupt passieren, wenn ich alle 10ms sende? Dann müssten ja auf jeden Fall Datenpakete "verschluckt" werden...

mfg

Hero_123

Da gibt eine Moglichkeit um diesen Buffer overflow beim Xbee zu detectieren : einfach die Serielle Hardware/SW control nutzen !!
So steht es in die Manual :
Product Manual v1.xAx - 802.15.4 Protocol
For OEM RF Module Part Numbers: XB24-...-001, XBP24-...-001
2.1.2. Transparent Operation
By default, XBee/XBee-PRO RF Modules operate in Transparent Mode. When operating in this
mode, the modules act as a serial line replacement - all UART data received through the DI pin is
queued up for RF transmission. When RF data is received, the data is sent out the DO pin.
Serial-to-RF Packetization
Data is buffered in the DI buffer until one of the following causes the data to be packetized and
transmitted:
If the module cannot immediately transmit (for instance, if it is already receiving RF data), the
serial data is stored in the DI Buffer. The data is packetized and sent at any RO timeout or when
100 bytes (maximum packet size) are received.
If the DI buffer becomes full, hardware or software flow control must be implemented in order to
prevent overflow (loss of data between the host and module).
1. No serial characters are received for the amount of time determined by the RO (Packetization
Timeout) parameter. If RO = 0, packetization begins when a character is received.
2. The maximum number of characters that will fit in an RF packet (100) is received.
3. The Command Mode Sequence (GT + CC + GT) is received. Any character buffered in the
DI buffer before the sequence is transmitted.

Hi

ja, das mit packetization habe ich auch im manual gelesen und daß der Buffer bei mir 72byte groß ist; ebenso das mit dem RO = Packetization; diese habe ich dann ja auf 0 gestellt (beim "End Device" und dem "Coordinator") mit dem Ergebnis, daß der Empfänger ("Coordinator") nichts mehr gemacht hat... hätte diese RO = 0 mal nur beim Sender einstellen sollen...
Das mit der seriellen HW-Control geht leider nicht (ist nicht verfügbar), das mit der sw control -> da weiß ich derzeit nicht wie ich das implementieren kann, denn dann muß ja ein Signal (welches? und wie) vom Sende-Xbee an den NIBO gesandt werden, dieser muß es auswerten und mit dem senden warten, bis dieses Signal vom Xbee wieder weg ist...

ich dachte eigentlich, daß das Xbee sofort Daten sendet, wenn es Daten empfängt; vielleicht verstehe ich das Ganze nur nicht; meine Meinung war, daß parallel zum Empfang von Daten auch Daten gesendet werden können - oder kann ich damit NUR senden und danach neue Daten NUR empfangen (also zuerst alles Empfangen und dann alles senden)?

mfg

Hero_123

Hi

oh Mann, ich habs gefunden - so ein Sch** - mein Fehler! Ich habe ja ein Xbee Explorer USB Board für meinen Empfänger (auch nötig, um die Xbees zu konfigurieren, auf dem Board ist ein FTDI Chip, der den USB Anschluss zum virtuellen ComPort macht - ComPort -> da muß man in den "Eigenschaften" "Port Einstellungen" "erweitert" noch einiges einstellen, u.a bei "BM Einstellungen" "reduzieren Sie die Werte um Komm-Probleme ..." -> DA waren meine 16ms eingestellt!!!!! Ich habs dann auf 1ms gestellt, und schon gehts OHNE 16ms "Gedenkpause"...

und was lernt man daraus? Immer die GANZE Kette betrachten!!

mfg

Hero_123

Hi

ich bekomme noch die Krise - wenn ich Daten sende, ist die max Größe der übertragbaren Daten ca 165 bytes; soll mehr übertragen werden, wird der Rest einfach "abgeschnitten" (Xbees im Transparent Mode, 115 kB, packetization timeout RO = 3, alle 500ms sollen Daten - ca 250 byte - übertragen werden).... wie kann ich diese Beschränkung aufheben,OHNE Flusskontrolle zu verwenden? Ich kann hw-mäßig kein RTS und CTS am Xbee anschließen (dies läßt der verwendete PortD des NIBO2 nicht zu)...

Hat jemand auch diese Beschränkung - wenn ja, gibt es eine Lösung OHNE hw-mäßig RTS/CTS zu verwenden? Leider kann ich das Xbee-Modul nicht programmieren, ich verwende ein Xbee Explorer USB Board. Ich hatte eigentlich erwartet, daß nur die Baudrate eine Begrenzung darstellt, da sich die Xbees ja im Transparent Mode befinden....

mfg

Hero_123

Ich verwende die XBee Module im Paket-Modus, da hatte ich noch nie Probleme.

Hi workwind

also - egal, in welchem Modus du sie verwendest (Transparent Modus oder API-Modus) - nach meinem Verständnis wird IMMER der Paket-Modus verwendet.
Im Transparent-Modus (den ich verwende, da ich nur 1 Punkt-Punkt Verbindung benötige) sollen sie "einfach als Kabelersatz für die RS232 SS dienen" (das ist es, was ich mache); und ich hatte erwartet, daß dann die Daten entsprechend der eingestellten Baudrate übertragen werden - bei 115kB maximal eben diese 115k Bits/sek, und nicht nur max 170 byte (bei 8N1), wobei die Daten zyklisch alle 500ms gesendet werden sollen (geplante payload 500-600bytes).
Ich habe es im AP-Modus noch nicht versucht, da ich dann meine Sendepakete anders aufbereiten müßte (so habe ich zumindest die Beschreibungen der Xbee verstanden).

Jetzt würde mich doch mal interessieren

- in welchem Modus betreibst Du sie
- mit welcher baudrate sendest Du
- wie groß sind Deine daten (wieviele bytes/sendezyklus überträgst Du)
- hast Du schon mal probiert, bei z.B. 57,6 kB mehr als 500byte AUF EINMAL zu senden? Wenn ja, würdest Du mir bitte die Konfiguration Deiner Xbees zukommen lassen?

Meine Konfiguration:
- XB-24B, ZNET 2.5 ROUTER/END DEVICE AT (version 1247)
- XB-24B, ZNET 2.5 COORDINATOR AT (version 1047)

bei beiden packetization Timeout RO = 3

Du mußt schon verstehen - eine Aussage wie "Ich verwende die XBee Module im Paket-Modus, da hatte ich noch nie Probleme." hilft mir leider nicht weiter.

Im anhang ist mein Programm - vielleicht ist da ja ein Fehler (denke aber, daß da kein Fehler ist)

nb - Du kannst ja mal mein Programm auf deinen NIBO2 flashen und mir sagen, ob du ALLE Daten wie im file angegeben übertragen bekommst - ich zeige sie mit HTerm an. Wäre schön, wenn Du das machen würdest, denn ich komme so nicht weiter.

mfg

Hero_123