RFM12 listen-before-talk

[mw2000 (Gast)]

Hallo zusammen,

ich habe mittlerweile 2 RFM12 Module am Laufen, die sich auch über 
längere Zeit gut verstehen. So konnte das eine Modul 1000 von 1000 
gesendeten Byte-Paketen empfangen. ;)

Nun möchte ich einen Handshake einbauen in dem das empfangende Modul dem 
sendenden Modul ein korrekt empfangenes Paket bestätigt. Um zu 
verhindern , das die Module (später sollen es mal 10stk sein) alle 
durcheinander quatschen, soll nun listen-before-talk implementiert 
werden.

Nun zur Frage: Wie geht Ihr daran?

Einfach vor dem Transmit das ATS oder RSSI - Signal  im Statusregister 
checken und ggf warten?

Gruß

mw2000

[N. S. (sharpay)]

Falls alle (Slaves) zu einem Empfänger (Master) senden würde es Sinn 
machen wenn der Master die Slaves reihum abfragt. Listen before talk 
könnte Probleme machen da die Module viel Rauschen empgfangen.

[mw2000 (Gast)]

Hallo,

@ Norbert S.
  Diese Variante muss leider ausscheiden.

bei der Anwendung soll es eine Basis geben und mehrere Satelliten, die 
nur sporadisch Daten an die Basis senden. die Satelliten sind 
batteriebetrieben, sehr klein und sollen sehr lange (> 2Jahre) mit einer 
Batterie 1200mA leben. Daher aktivieren sie das RFM12 nur zum Senden und 
warten danach noch 5s auf ein ACK-Paket, danach geht wieder alles in den 
Tiefschlaf. (Soweit der Plan)

Die Daten sind nicht zeitkritisch, ich möchte nur die Ausbeute an 
korrekten Paketen Steigern, wegen der Laufzeit der Batterie.

Würdest Du für LBT einfach das RSSI Signal abfragen?

Gruss

Matthias

[holger (Gast)]

>Daher aktivieren sie das RFM12 nur zum Senden und
>warten danach noch 5s auf ein ACK-Paket,

Das widerspricht dem Vorschlag von Norbert doch nicht.
Lass die Empfänger einfach eine Weile lauschen, und wenn
sie keine Aufforderung zum senden bekommen haben gehen sie
wieder schlafen. Wenn sie nicht an der Reihe waren haben sie so
auch keine Sendeenergie ins blaue geschossen und damit auch
keine andere laufende Sendung gestört.

[mw2000 (Gast)]

Ich möchte ca. 10x am Tag einen Status übertragen und diesen in 
zufälligen Abständen, da müsste ich ja lange lauschen oder sehr oft von 
der Basis nachfragen! Da das RFM 12 ca. 20mA im Empfangsmodus benötigt 
kann ich mit 1200mA max 60h (auf 2Jahre) d.h. 4min pro Tag hören (Strom 
der Restschaltung und fürs Senden nicht berücksichtigt) Ich denke das 
kann nicht funktionieren...

Gruß

mw2000

[Markus J. (markusj)]

Ich würde mich nicht auf das RSSI-Signal verlassen, vielleicht stört ja 
gerade ein anderer Nutzer in der Umgebung das Band noch (schwach) oder 
du kriegst aus sonst irgendeinem Grund Hintergrundrauschen rein.
Stattdessen: Ein Vielfaches einer Paketdauer auf dem Medium lauschen. 
Solltest du einen Paketanfang verpasst haben, passiert so nichts weil du 
länger wartest als das Paket noch unterwegs ist (und es damit nichts 
macht wenn du das Startsignal verpasst hast).
Solltest du nach diesem Zeitraum keine eingehende Datenübertragung 
bekommen, ist das Medium frei.
Sieh dir Mal den Wikipedia-Artikel zu CSMA/CA an. 
(http://de.wikipedia.org/wiki/Carrier_Sense_Multiple_Access/Collision_Avoidance)
Speziell der Teil mit der RTS/CTS-Erweiterung ist interessant um Fälle 
abzudecken, bei denen sich nicht alle Endpunkte "hören" können, wohl 
aber eine Station dazwischen (die dann gestört wird).

mfG
Markus

[Markus J. (markusj)]

Nachtrag: Ein anderer Anhaltspunkt ist das Status-Bit der Clock Recovery 
(CRL). Speziell wenn deine Datenpakete sehr lang sind, könnte es 
sinnvoll sein wenn du einfach nur darauf zu prüfst, ob die Clock 
Recovery innerhalb einer gewissen Zeitspanne stabil "einrastet".

mfG
Markus

[Stephan V. (orca)]

Ich weiß, der thread ist schon etwas älter, aber bevor ich einen neuen 
aufmache, hängt ich mich lieber hier dran.

Welches Flag ist das Richtige für listen-before-talk? RSSI oder DQD?
Wo ist da eigentlich genau der Unterschied?

Sorry, aus dem Datenblatt werd ich nicht schlau:

RSSI 
A digital RSSI output is provided to monitor the input signal level. 
It goes high if the received signal strength exceeds a given preprogrammed level.

DQD 
The Data Quality Detector is based on counting the spikes on the unfiltered received data.

D.h. RSSI zeigt mir an, ob die Trägerfrequenz belegt ist, und DQD zeigt 
mir ob da wirklich Daten gesendet werden, oder wie ist das zu verstehen?


by(e)
Stephan

[Jörg W. (dl8dtl) (Moderator)]

Stephan V. schrieb:

> D.h. RSSI zeigt mir an, ob die Trägerfrequenz belegt ist, und DQD zeigt
> mir ob da wirklich Daten gesendet werden, oder wie ist das zu verstehen?

So in etwa.