www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RFM12 listen-before-talk


Autor: mw2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: N. S. (sharpay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mw2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: mw2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_Multipl...)
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

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan V. (orca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.