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
In Wikipedia steht nur was über Master/Salve- Verbindungen. Das Hilft mir leider bei meinem Problem nicht weiter.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.