Moin zusammen!
Ich entwickele derzeit eine Anwendung mit dem Xbee Pro 868, welche
später mal bei niedriger Datenrate mit hoher Reichweite funktionieren
soll. Dazu wird ein Protokoll implementiert, welches eine gesicherte
Punkt-zu-Punkt Verbindung über das API-"Protokoll" des Xbees herstellt.
Die Dokumentation ist leider relativ schlecht, Erfahrungen von anderen
Xbees scheinbar nicht direkt übertragbar.
Insbesondere stellen sich mir gerade folgende Fragen:
a) Automatische Retransmission:
In welchem Zeitintervall erfolgen diese? Ich möchte in meiner Anwendung
einen Timeout festlegen, in welcher ich einen Ack empfangen sollte.
b) Was passiert bei verloren gegangenen ACK-Paketen? Sorgt das Xbee
selbst dafür, dass der Empfänger einer Nachricht diese nur maximal
einmal der Anwendung übergibt? Ist meine Annahme, dass eine Nachricht
angekommen sein könnte, obwohl ich kein ACK bekommen habe, korrekt?
Eventuell hat jemand von euch Erfahrung mit den Modulen und kann mir
helfen. Oder ich wende mich doch mal an digi, in der Hoffnung, dass die
Antworten...
Gruß,
Matthias
Matthias Larisch schrieb:> Eventuell hat jemand von euch Erfahrung mit den Modulen und kann mir> helfen. Oder ich wende mich doch mal an digi, in der Hoffnung, dass die> Antworten...
In der Doku/API steht zu deinen Fragen nichts, da es sich um eine API
über dem eigentlichen ZigBee handelt. Deine Fragen beziehen sich direkt
auf das ZigBee-Protokoll, evtl. gibt es Headerfiles etc. mit den
Parametern?
Grüße.
Hallo!
Danke für deine Antwort.
Sollte nicht das Verhalten der API dennoch dokumentiert sein? Beim Xbee
Pro 868 handelt es sich bei der RF-Implementierung auch (angeblich)
nicht um ZigBee, sonst würde ich da wohl mal nachlesen. Das Datenblatt
gibt auch keine weitere Auskunft zur RF Implementierung, im digi.com
Forum stehen wohl ein paar Fragen dazu, jedoch seit Monaten ohne
Antwort.
Gruß,
Matthias
Matthias Larisch schrieb:> Sollte nicht das Verhalten der API dennoch dokumentiert sein?
Es sollte dokumentiert sein, ist es wohl nicht :-).
> Beim Xbee> Pro 868 handelt es sich bei der RF-Implementierung auch (angeblich)> nicht um ZigBee, sonst würde ich da wohl mal nachlesen. Das Datenblatt> gibt auch keine weitere Auskunft zur RF Implementierung, im digi.com> Forum stehen wohl ein paar Fragen dazu, jedoch seit Monaten ohne> Antwort.
Naja, das ist mehr oder weniger alles eine Soße mit Overhead (ZigBee)
oder ohne. In den Networking "Features" steht auch:
Protocol: Proprietary
Wenn du Pech hast, dann musst du dir dein eigenes ACK/Retransmission in
die höheren Layer bauen. Wird das DutyCycle auf den 868MHz vom Protokoll
gehandelt oder ist das deine Aufgabe? Wenn vom Protokoll, dann könntest
du auch Probleme mit dem ACK bekommen wenn die Kanalzeit um ist.
Grüße.
FYI
4.4 Transmission Modes
There are two transmission modes: unicast and broadcast. Unicast is the
default. It supports retries; broadcast doesn’t.
In unicast mode, a module receiving a packet will send an ACK back to
the transmitter. If the transmitter does not
receive an ACK within 200mS, it will retry up to three times. These
three retries are provided automatically, but the RR
command will set or read a multiplier: the number of times the (up to) 3
retries will be repeated if necessary. The range
of the RR parameter is 0 to 6, and the default is 0. The parameter was
introduced in firmware version 1xa0.
The EA parameter gives the number of ACK failures since the counter was
last reset. The counter is incremented
when the module reaches its retransmission limit without an ACK having
been received. When the counter reaches 0xffff
it retains that value instead of overflowing. To reset the counter, set
the EA parameter to 0.
In broadcast mode, all RF modules within range will accept the
transmission. No ACKs are sent, and there is no
automatic retransmission of packets. A packet is sent in broadcast mode
if its destination address is DL=0xffff and DH=0.
Danke für deine Mühe, leider gilt das Cookbook nicht fürs Pro 868 :)
Zumindest die Angaben zu den Retransmissions sind nachweislich anders:
Diese sind nämlich in 1er Schritten von 0-15 konfigurierbar fürs 868,
laut Datenblatt...
Ich mache jetzt erstmal Annahmen über den genauen Ablauf und teste mal
ne Weile, wie gut das funktioniert. Auf niedriger Sendeleistung kann ich
im Gebäude auch ganz gut verlorene Pakete "erzeugen" und sollte somit
hoffentlich mal alle Situationen testen können.
Wenn alle Stricke reißen, deaktivier ich das Low-Level Ack und bastel
halt selbst (Inkl. Retransmission & Ack), wobei das sicherlich die
Hardware besser kann als ich selbst, zumal die Anwendung unter Linux in
Java läuft und somit von der Reaktionszeit vermutlich recht schlecht
abschneidet.
Duty Cycle macht das 868 selbst, der ist aber kein Problem. Ich kann ihn
zum einen jederzeit auslesen, außerdem übertrage ich meistens nicht so
viele Daten. Irgendwer hat mal nen Overhead von rund 60-70%
überschlagen, d.h. ich schaff effektiv rund 1 kBit/s und das reicht mir.
Gruß,
Matthias
Hi!
Tschuldigung, dass ich länger nicht reingeschaut habe.
Also das Ack-Timeout liegt in der Größenordnung von 60ms (durch PL4
innerhalb eines Raumes kann ich manuell gut packet loss erzeugen, 10
Retransmissions dauern etwa 600ms).
In diesem Fall habe ich ACK Pakete verloren (TX Xbee auf PL0, RX Xbee
auf PL4), der Empänger hat (scheinbar) das erste Paket bereits an die
Anwendung ausgegeben, weitere Paketduplikate kamen nicht (war eigentlich
so zu erwarten - aber nun bin ich mir sicher). Getestet habe ich durch
Übertragen von etwa 500 Paketen - erstaunlicherweise kam in allen Fällen
spätestens bei der 10. Retransmission das ACK an, da muss ich auch
nochmal schauen, denn das ergibt wenig Sinn.
Grundsätzlich ist mein Paketdurchsatz derzeit noch etwas schlecht. Ich
versende nur ein Paket zur Zeit und warte zwischendurch im Java-Code auf
das TX Finished Frame. Dies erhalte ich minimal etwa 50-60ms nach dem
Versand (selbst bei 0 Retransmissions). Diese Latenz kann allerdings gut
auch durchs Scheduling vom BS oder in Java selbst entstehen, da muss ich
bei Zeiten nochmal ran. Derzeit ist es so akzeptabel :)
Ich würd sagen:
Thema erstmal so gelöst!
Gruß,
Matthias
