XBee lässt Pakete fallen und die tatsächliche Datenrate ist niedriger als erwartet

Ich übertrage kontinuierlich mit 9600 bps unter Verwendung der Standardkonfigurationen für meine beiden XBees XB24-B. Die Kommunikation erfolgt nur in eine Richtung, der Sender ist mit dem ATMega328 UART verbunden und der Empfänger ist über USB (FTDI) mit dem PC verbunden. Hier ist die tatsächliche Datenrate für ein bestimmtes Programm:

  • Kabelgebundene Verbindung (kein XBee): 7694 bps
  • vom ZNET 2.5 Router/End Device AT zum ZNET 2.5 Coordinator AT: 6800 bps (einige verlorene Pakete)
  • vom ZNET 2.5 Coordinator AT zum ZNET 2.5 Router/End Device AT: 0356 bps (viele verlorene Pakete)
  • vom Zigbee Router/End Device AT zum Zigbee Coordinator AT : 0000 bps (funktioniert nicht)
  • vom Zigbee Coordinator AT zum Zigbee Router/End Device AT: 0328 bps (viele verlorene Pakete)

Warum das? Kann ich etwas tun, um diese Quoten zu verbessern?

Bearbeiten Für höhere Baudraten (115200) erhalte ich noch schlechtere Paketverlustraten:

  • Kabelgebundene Verbindung (kein XBee): 94200 bps
  • mit XBee XB24-B ZNet 2.5: 27900 bps

Bearbeiten Wenn ich den Koordinator dazu bringe, das Endgerät zu adressieren, fällt die Paketverlustrate auf das normale Niveau (6800 bps), was nicht ideal ist, aber besser als das vorherige Szenario

Crossposting im Arduino-Forum und im SparkFun-Forum
Im Digi-Forum gibt es jemanden mit einem ähnlichen Problem
aber ich habe es trotzdem gekreuzt

Antworten (3)

Sie können [die verworfenen Pakete auf Null reduzieren][1], indem Sie die richtige Zieladresse zuweisen, bevor Sie mit der Übertragung beginnen.

Die verlinkte Seite wurde als Malware-Angriffsseite gemeldet.
Ja leider ist die Originalseite nicht mehr da.

Wie sieht die Signalstärke und Geschwindigkeit der WLAN-Verbindung aus? Überprüfen Sie die XBee API-Dokumentation, Sie sollten auf diese Informationen zugreifen können. Welche Antennen verwendest du?

Die Rohdatenrate von Zigbee beträgt nur 250 kbit/s im 2,4-GHz-Band und es ist ein Protokoll mit sehr hohem Overhead. Bei nahezu perfekter Signalstärke und aktivierter Verschlüsselung sollten Sie nur einen maximalen Datendurchsatz von ~20-25 kbit/s erwarten, ohne den Stack anzupassen, etwas mehr ohne Verschlüsselung. Das Zigbee-Protokoll unterstützt wirklich nur das Senden von Daten, die in ein einzelnes Paket passen, das meiner Meinung nach ungefähr 100 Bytes groß ist. Wenn Sie einen Datenstrom senden, muss die Anwendungsschicht diese Daten in Pakete aufteilen und zusätzliche Informationen in den Datenraum des Pakets aufnehmen, damit sie wieder zusammengesetzt werden können. Dieser Vorgang kann ziemlich langsam sein und den Datendurchsatz weiter beeinträchtigen.

Der Digimesh-Stack von Digi ist etwas schneller, da er den Overhead reduziert und größere Pakete zulässt.

Ich bin mir nicht sicher, was Ihre beabsichtigte endgültige Anwendung hier ist, aber Zigbee ist überhaupt nicht für das Streamen von Daten ausgelegt. Es dient zum Senden kleiner Informationen, Sensormesswerte, Anweisungen usw., die in ein einziges Paket passen. Möglicherweise haben Sie einfach das falsche Protokoll für Ihre Anwendung ausgewählt.

Ich streame Audio. Gibt es ein geeigneteres Protokoll, das die gleiche Hardware verwendet? Welches Protokoll empfehlen Sie? Bluetooth?
Wenn es sich nicht bereits um digitales Audio handelt, verwenden Sie FM. Wenn Sie einen vorgefertigten Transceiver mit der richtigen Bandbreite finden, ist es einfach.
@Jader: Wie wolltest du Audio mit 9600 bps streamen? 1,2 Kbit/s ist viel zu langsam. Wenn Sie aus irgendeinem Grund im digitalen Bereich bleiben möchten, bietet Bluetooth PCM-Schnittstellen zum Streamen von Audio.
@Nick Ich werde kein Audio mit diesen Raten streamen, ich habe nur versucht, jeweils ein Problem zu lösen. Meine Sorge ist jetzt, den XBee zu optimieren. Ich werde mich mit Bluetooth befassen, danke!
Sie sollten Zigbee niemals, niemals, niemals zum Streamen von Audio oder irgendetwas verwenden, das zeit- oder durchsatzkritisch ist.

UPDATE: Angesichts der jüngsten Erkenntnis, dass Zigbee nicht für das Streamen von Daten geeignet ist, würde ich vorschlagen, es in den Müll zu werfen und einen besseren Transceiver mit mehr Funktionalität, mehr Durchsatz und etwa 1/4 des Preises zu kaufen

Ich empfehle dringend, nach Möglichkeit die Flusskontrolle zu verwenden, um die verlorenen Pakete zu adressieren. Es besteht die Möglichkeit, dass ein Gerät in kleinen, aber erheblichen Zeiträumen, in denen es verarbeitet, nicht auf seine UART-Pins schaut und daher Bits / Bytes verpasst und Dinge aufhängen kann. Durch die Implementierung der Hardware-Flusskontrolle (RTS- und CTS-Pins) kann jedes Gerät dem anderen mitteilen, wann es für weitere Daten bereit ist oder nicht.

Sobald Sie die Flusskontrolle angeschlossen haben, werden Sie meiner Meinung nach den höheren Durchsatz erreichen, den Sie suchen =)

Ich arbeite mit Bluetooth-OBD-Geräten, die meine Android-App mit Fahrzeugnetzwerken verbinden, also arbeite ich ziemlich viel mit Wireless/Bluetooth.

Meine MCU hat keine eingebaute Flusskontrolle, also muss ich sie implementieren.
Die Flusskontrolle wird die Probleme mit dem Durchsatz auf Zigbee nicht lösen, sie wurde nie für das Streamen von Daten entwickelt.
Meine Antwort aktualisiert. Ich benutze das Gerät, das ich verlinkt habe, und es ist ein Kinderspiel, damit zu arbeiten.
Ist Ihnen klar, dass Bluetooth und Zigbee sehr unterschiedliche Protokolle sind? Wenn Sie Zigbee benötigen, funktioniert Bluetooth nicht. Ein Gerät zum anderen für Bluetooth, perfekt. Für eine Gruppe von Sklaven und einen Herrn, ja. Bei einem Mesh-Netzwerk mit vielen Knoten funktioniert Bluetoth nicht.
XBee lässt Pakete fallen und die tatsächliche Datenrate ist niedriger als erwartet
AntwortenHierDatenschutz-Bestimmungen1y, 0v