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...
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.
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
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...
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.
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)?
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!!
Zitieren
Berechtigungen
Lesezeichen