Hallo zusammen!
Ich habe schon seit Längerem eine Projektidee im Kopf, wobei ich mir bei
einem speziellen Teil der Umsetzung unsicher bin.
Folgendes soll realisiert werden: Es sollen kleine gleichartige mobile
Geräte mit Transponder gebaut werden, die sich gegenseitig erkennen und
eine kleine Menge an Daten austauschen.
So soll zyklisch geprüft werden, ob andere Geräte in Reichweite sind und
falls mit ihnen noch keine Daten ausgetauscht wurden, soll dies dann
geschehen.
Das ganze ist nicht Zeitkritisch, und für jeden Datenaustausch sind
nicht mehr als ein paar Byte nötig.
Als Wunschkriterium würde ich gerne das Ganze via Bluethooth
realisieren, nicht zuletzt um die kleinen Geräte mit dem PC
konfigurieren zu können.
Mein Problem ist nun folgendes:
Befinden sich nun beispielsweise 10 dieser Geräte in einem gemeinsamen
Funknetz um Daten auszutauschen, so würde man die Kommunikation
normalerweise mittels eines Masters regeln, so wie auf einem Bus.
Was gibt es denn für Konzepte das ganze ohne einen Master zu regeln?
Stellt da Bluetooth eine Funktionalität bereit?
Da alle Geräte gleich (gleichberechtigt) sind kann man ja keinen Master
bestimmen? Die Geräte sind ja wie gesagt mobil, d.h. es können immer
wieder neue dazukommen oder Geräte geraten außer Reichweite.
Ich würde mich sehr freuen, falls mir jemand ein paar Tipps hat, wo ich
weitersuchen kann.
Gruß
Daniel
http://de.wikipedia.org/wiki/Bluetooth
sollte dir weiter helfen
Was das Master_Slave Problem angeht brauchst du bei deinem Vorhaben kein
masterloses System, sonderen eine Multimasterkonfiguration.
Ohne Master keine Kommunikation, Slaves senden nicht von allein sondern
nur nach Aufforderung durch einen Master.
Namaste
Man kann sowas "bare bone" mit IEEE 802.15.4 ZigBee Transceivern
realisieren. Man muesste zur Konfiguration dem Host PC einen 15.4
Knoten als Gateway spendieren.
Mit "bare bone" meine ich keines der angebotenen NW Layer wie
MAC Bitcloud RUM, die sind alle ohne Master nicht lebensfaehig.
Die Knoten sollten zum Senden so eingestellt werden, dass sie CSMA-CA
verwenden.
Um Energie zu sparen muesste man sich ein dezentrales
zeitsynchronisiertes Standby-Schema ausdenken, denn die Knoten brauchen
im RX-Modus so ca. 15mA.
Das ist uebrigens auch der Grund, wozu der Master-Knoten gut ist, von
dem weis man, dass er immer ein offenes Ohr / Antenne hat, da er meist
Netz/USB betrieben ist.
Hey zusammen,
danke für eure Antworten!
@Axel: Meinst du das so, dass beispielsweise jeder Knoten jede Sekunde
versucht via CSMA/CA ein "Ich bin hier" auszusenden, damit jeder Knoten
die anderen (die er empfängt) erkennt und in eine Art dynamische Liste
aufnimmt?
Naja so ungefaehr, ein Knoten der erwacht muss solange zuhoeren bis
er einen Knoten mit passender Netzwerkadresse hoert, danach ist er
synchronisiert. Nun koennte man aus der Adresse vielleicht berechnen,
wann die anderen aktiv sind bzw. wann alle mal zuhoeren (Broadcast)
... ich seh schon, so ein Protokoll denkt man sich nicht ebenmal
nebenbei aus ... was soll deine Anwendung denn genau leisten ?
Vielleicht sollte man umgekehrt heran gehen: Jeder neue bleibt solange
wach bis er sich synchronisiert hat. dazu muss aber irgendeiner die
Systemzeitvorgeben.
Man könnte zum Beispiel so vorgehen der mit der niedrigsten ID(IP) ist
automatisch Master des systems hört der mit der zweitniedrigsten länger
nichts von seinem Chef versucht er ihn zu erreichen klappt das nicht
übernimmt er den Laden.
Damit ist auch klar wie das System Startet jeder ist Master, bis er
jemanden findet der eine höheren Priorität in Form einer niedrigeren ID
hat. Dazu plärrt er in Kurzen abständen und lauscht in den Pausen ob
jemand antwortet.
Wenn jetzt sequentiell zugeschaltet wird lernen sich alle kennen und
können ihre Position anhand der ID-Liste verfolgen. Dabei muss jeweils
der mit der niedrigsten ID einen suchen dem er den Job als Master
aufhelfen kann und jeder muss über eine Timoutroutine beobachten ob noch
ein Master für ihn da ist, wenn nicht darf er auf dem Tisch tanzen.
Namaste
kann man mit zigbees collision avoidance hinbekommen? - zb das RFM12
kann ja nur senden oder empfangen, aber nicht gleichzeitig? - wie prüft
man in dem fall ob auch das auf dem "Bus" liegt was da sein soll??
auch interessiert schrieb:> kann man mit zigbees collision avoidance hinbekommen?
Nein, aber mit dem darunter liegenden IEEE 802.15.4 schon.
> - zb das RFM12> kann ja nur senden oder empfangen, aber nicht gleichzeitig? - wie prüft> man in dem fall ob auch das auf dem "Bus" liegt was da sein soll??
Deshalb heißt es auch "collision avoidance" und nicht "collision
detection" (wie bei 802.1). Man kann halt nur vorher hören und
dann hoffen, dass nicht jemand anders zufällig zur gleichen Zeit
sendet.
@Winfried:
Ja an eine ID Reihung hatte ich auch schon gedacht, aber solche
Protokolle hat sicher schon jemand an einer Uni erdacht und sicher auch
simuliert, vielleicht kann der TE ja mal die allwissende Suchmaschine
bemuehen und ein paar Optionen posten. Andererseits denkt man sich
solche Protokolle am besten anhand eines gegebenen Szenarios und in
Gegenwart einer Flasche Bier aus ;-)
Hallo zusammen!
Das Verfahren mit ID- Listen klingt gut! Trotzdem ein recht kniffeliges
Thema, vor allem wenn man den Fall betrachtet, dass ein Knoten "allein"
ist, da er dann die die ganze Zeit lauschen muss, bis er sich mal
snychronisieren kann.
Ich hatte ja geschrieben, dass ich "kleine gleichartige mobile
Geräte mit Transponder" bauen möchte. Mein Ziel wäre ein solches Modul
möglichst lange mit einer Knopfzelle (~120mAh @ 3.7V) betreiben zu
können. 15mA wären da schon zu viel.
Es kann nämlich oft der Fall sein, dass ein Knoten allein ist.
Der ATmega128RFA1 braucht ja beispielsweise auch 17mA im RX_LISTEN. So
wie ich das verstanden habe, kann man im SLEEP Modus nicht empfangen.
Atmel schreibt hierzu:
In Deep Sleep mode all major digital blocks with no data retention
requirements are
disconnected from main supply providing a very small leakage current.
Watchdog timer,
MAC symbol counter and 32.768kHz oscillator can be configured to
continue to run.
Dann wird es wohl auch keine Möglichkeit geben, unter 17mA zu empfangen.
Ich dachte da an sowas: Im Sleep-Mode öfters mal "reinhören" und falls
man ein Bit "aufschnappt" bleibt man im RX_LISTEN und überprüft, ob
wirklich relevante Daten ankommen. Ansonsten geht man wieder in den
Sleep- Mode.
Wenn für das Erkennen eines anderen Knotens aus dem Sleep-Mode heraus 1
bis 2 Seknunden ins Land gehen würden, wäre das nicht schlimm.
Das Problem hierbei wäre nur, dass das Ganze nicht so toll funktioniert,
wenn sich zwei Knoten "treffen", ohne dass schon ein Netzwerk aus
mehreren Knoten mit ausreichend Datenverkehr vorhanden ist.
Denkt ihr die Idee mit 120mAh eines solchen Knoten, mehr als nur wenige
Stunden zu betreiben, ist zu abwägig?
jain..
Es gibt immer eine Lösung, welche jedoch einen entsprechenden Aufwand
nach sich zieht.
Eine Hinreichend genaue Systemuhr könnte auf Kosten der permanenten
Bereitschaft zum Beispiel solch ein Ansatz sein.
Grundlegendes Problem ist wer allein ist muss irgendwie rumplärren und
hoffen das jemand antwortet. So ist das nun einmal wenn man sich im Wald
verläuft. Wenn alle Sensoren und der Boss pennen, so braucht man
wenigsten einen Wecker um wach zu werden und um jemanden zu finden, der
mit einem redet, sollte man plärren können und das Ganze irgendwie so
timen, dass einen auch jemand hören kann.
Energie ist immer das Hauptproblem bei so kniffligen Dingen, man sollte
erst mal das Prinzippielle in den Griff bekommen bevor man anfängt
überall was abzuschneiden. Step bei Step, so löst man solche Probleme,
nicht:"Ich hab da ne Idee aber keine Ahnung wies geht und nächst Woche
möchts bittschön laufen." Das machen Anfänger und wenn sie dan dreimal
auf die Nase.... , werden sie aufgeben oder klüger.
Ich behaupte also mal, das ist machbar, aber nicht in einem Schritt!
"Eine Erfindung besteht zu 1% aus Intuition und zu 99% Schweiß."
Albert Einstein
Bei deinem Projekt setze ich wegen des mangels an Erfahrung noch mal den
Faktor 1000 an, und wünsche Dir den notwendigen Biß, das durchzureiten.
Namaste
Winne
die triviale lösung für das "anfangsproblem" wäre doch zb. wenn ein
"Benutzer" (per tasterdruck) eines der module in den "plärrmodus"
versetzen könnte. dann gäbs was was die anderen module im sleep modus
hören könnten, und das netz könnte sich aufbauen? - und solange mind 2
module hin und wieder kommunizieren, stirbt es auch nicht weg..?
-zugegeben, nicht grad ne autonome lösung, aber evtl für dein szenario
praktikabel?
Ich pflichte Winne bei, so ein System vollstaendig befreit von jeglichem
Detailwissen aufzuziehen dauert entweder sehr lange oder scheitert. Wenn
es derartig unuebersichtlich wird, hilft normalerweise eine Reduzierung
der Anforderungen, also
- Knopfzelle => 2 x R6,
- permanentes Detektieren der Netzumgebung => manuell gesteuerte
Detektion oder einen Hilfsleuchtturm (Beacon-Sender) einsetzen.
Danach mit einem Prototypen das ganze testen und schauen, wo noch
versteckte Probleme lauern. Bis man das System dann am spielen hat,
gibt es vielleicht schon neue Bauteile, die den initialen Anforderungen
weiter entgegenkommen.
Die obigen Systemanforderungen kann man sicher nicht als
48h-Hack-Projekt realisieren.
