- Labornetzteil AliExpress         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

Thema: Lösungsansatz für bidirektionalen Datenfunk gesucht

  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    06.11.2004
    Beiträge
    1.693

    Lösungsansatz für bidirektionalen Datenfunk gesucht

    Anzeige

    E-Bike
    Es mag sein, das mein Problem im Prinzip ganz einfach ist, ichaber ein Brett vor dem Kopf habe und das Ziel einfach nicht sehe.

    Wenn ich zwei PCs miteinander reden lassen will, kann ich einfach Tx und Rx kreuzen und jeder kann Daten senden und gleichzeitig empfangen.
    Soweit ist noch alles gut.
    Wenn aber zwei µC das gleich über Funk machen sollen, wird es schon anspruchsvoller.

    Nehmen wir mal 27,1MHz und 27,2MHz als Beispiele.
    Tx des ersten µC sendet auf 27,1MHz die Daten zu RX des zweiten µC, der diese auch auf 27,1MHz empfängt.
    Tx des zweiten µC sendet auf 27,2MHz zu Rx des ersten, der auch auf 27,1MHz lauscht.
    Soweit ist es auch noch klar.

    Aber jetzt kommt der entscheidene Punkt.

    Mir stehen pro µC nur ein Sendemodul und ein Empfangsmodul zu. Die Frequenz ist dabei erstmal nebensächlich. Aber das Problem ist, es ist eine Vielzahl von Controllern, die gleichzeitig senden und empfangen sollen.
    Sobald einer was sendet, müssen alle andern (im Empfangsbereich) das empfangen können und im schlimmsten Fall selbst auch noch was senden können.
    Es ist nicht möglich einen Master und viele Slaves zu bestimmen.
    Es ist nicht möglich alle mit einen Takt zu synchronisieren und damit nur zu bestimmten Zeiten senden zu lassen.
    Es ist nicht möglich, auf mehreren Frequenzen zu senden.
    Es ist nicht möglich, die Daten durch die einzelnen µC durchzureichen bis am Ende der richtige die Daten hat.

    Ich habe schon überlegt, alles auf nur einer Frequenz zu realisieren. Aber dann empfängt der µC ja auch die 'eigenen Daten' und das mit einer so großen Signalstärke, das die anderen nicht durchdringen können.

    Habe ich jetzt nur einen Denkfehler, oder geht es wirklich nicht so einfach?

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.06.2004
    Ort
    Bad Schussenried in Oberschwaben
    Alter
    34
    Beiträge
    1.461
    Hi!

    Tja... Da fällt mir nur die gute alte Packet-Methode ein.
    Die Daten, die µC1 an µC2 versenden will, bekommen einen Header.
    Un diesem Header steht die Adresse des Empfängers und des Absenders (und die der Relais...). Also im weitesten Sinne "Von µC1 an µC2 [über µC7 und µC19]"
    Was in dem Paket steht geht also nur µC2 was an, der auch gleich weis, dass das Paket von µC1 kommt. Die anderen haben also ruhig zu sein.

    Naja, da du keine voll-duplex-Übertragung hast kommt es darauf an, wie viele µCs im Netzwerk sind, und wie belastet dein Frequenzband ist.
    Je mehr was sagen wollen, wirst du um einen Rooter nicht herumkommen.
    Wenn du aber nur 2 µCs hast, die miteinander reden sollen, kannst du das Packet-System von oben vergessen. Dann musst du halt ne Flusskontrolle entwickeln. z.B. dass µC1 immer zuerst darf oder so.
    oder kannst du 1 weiteren (digitalen) Kanal rausschlagen? Dann könntest du ein RTS-Signal übertragen.

    VLG Tobi

    Edit zum Eigene-daten empfangen:
    Du musst den Empfänger möglichst ausschalten, wenn beide die gleiche Antenne benutzen und du den Empfnger nicht rösten willst...
    http://www.tobias-schlegel.de
    "An AVR can solve (almost) every problem" - ts

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    15.07.2005
    Ort
    Enns
    Alter
    39
    Beiträge
    129
    ich an deiner stelle würde mir ein protokoll überlegen.

    ethernet zum beispiel(häufig in lans verwendet) arbeitet mit dem csma/cd (carrier sense multiple access/collission detection) prinzip:
    es ist ein multimastersystem, das heißt, dass jeder die selben rechte hat, wann er was sendet. gut -> wenn sich aber ergibt, dass zwei zur selben zeit senden, wird eine gewisse zeit gewartet (zufall) und dann erneut gesendet.

    mfg

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    06.11.2004
    Beiträge
    1.693
    @Tobi,
    Es geht ja nicht, das die Daten von µC1 über 7 und 19 an 2 laufen. Fällt 7 aus, kommt nichts an.
    Die Anzahl der Sender pro Cluster können unterschiedlich sein.
    Jeder sendet auch in gewissen abständen nur 2-3 Byte. Die Übertragungsrate muss auch nicht schnell sein. Selbst 120 Baud (da fehlt keine 0) würden reichen.
    Ein Router ist absolut nicht möglich.
    Die Pakete darf jeder empfangen und dann wertet jeder aus, ob das Packet für ihn gewesen ist. Wenn ja, dan verarbeiten, wenn nicht, dann weiter empfangen und selbst was senden.
    Und wie ich auch schon geschrieben habe, ist es ncht möglich pro Cluster einen Master zu bestimmen. Die Zusammenkunft der µC ist relativ zufällig.
    Der Empfänger darf beim Senden nicht ausgeschaltet werden. Aber sie haben nicht die gleiche Antenne. Und die Sendeleistung ist nicht so stark. Es müssen max. 20m (10m reichen auch) Reichweite mit fast Sichtverbindung erreicht werden.

    es ist ein multimastersystem, das heißt, dass jeder die selben rechte hat, wann er was sendet. gut -> wenn sich aber ergibt, dass zwei zur selben zeit senden, wird eine gewisse zeit gewartet (zufall) und dann erneut gesendet.
    Das wäre schon eher was. Wenn man ein Packet verloren geht kann ich damit leben. Und genau das brache ich ja auch. Jeder muss senden dürfen, wenn ihm danach ist.

    Mein problem ist aber die Frequenz. Tx und Rx müssen ja gekreuzt sein damit eine Übertragung zustande kommt.
    Würde es sichnur um zwei Einheiten handeln, wäre es ja kein Problem. Aber es können auch mehr als zwei werden. Und dann muss jeder das empfangen können, was einer sendet. Senden zwei gleichzeitig, ist es wie im wirklichen Leben, dann muss einer nochmal anfangen und danach kann der andere was sagen.
    Wie eine CD erreicht werden kann, kann ich mir (über Funk) nicht vorstellen. Keiner sendet eine Quittung, das die Daten angekommen sind. Ist aber auch nicht unbedingt nötig.

    Wie das ganze ohne n+1 oder n*2 Frequenzen aufbauen?

    Ich sehe im Moment nur die Lösung, nur eine Frequenz für alles zu nehmen. Wenn jemand anders sendet während man selbst sendet, hat man halt Pech, die Daten kommen nicht an.
    Aber das Senden könnte in einem gewissen Zeitfenster erfolgen und die Zeit in diesem Fenster wird durch Zufall bestimmt. Somit wird vermieden, das der ungünstige Fall dauerhaft eintritt.

    Es ist nicht mein Vorhaben, aber ein Beispiel um zu verdeutlichen wie man das nutzen könnte um es besser nachzuvollziehen zu können.

    Man nehme 22 Roboter. Jeweils 11 gehören zu einer Gruppe. Die Roboter bekommen einen Ball und sollen Fussball spielen. Wer den Ball hat, sendet an seine Gruppe ein Signal. Der, der in der Nähe ist, nimmt ihn den Ball ab.
    Die Roboter der anderen Gruppe "sehen" auch wer den Ball hat und versuchen ihn zu bekommen.
    Um meinem Problem aber etwas näher zu kommen, werden 7 Bälle ins Spiel gebracht (von mir aus auch 5 oder 6 oder so).
    Und da es die Roboter auf der ganzen Welt gibt und immer neue Gruppen zusammengestellt werden, kann kein master die Steuerung der Daten übernehmen (wie in der Politik z.Zt. keiner will den anderen die Macht gönnen).

    Wie gesagt, wenn es nur auf einer Frequenz geht, dan ist das so. Ich wollte nur vermeiden, das ich eine andere Möglichkeit übersehen habe wo auf einer Frequenz gesendet wird und auf einer anderen empfangen.

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.06.2004
    Ort
    Bad Schussenried in Oberschwaben
    Alter
    34
    Beiträge
    1.461
    Hi1

    Du hast mich etwas falsch verstanden!
    Die Messages werden von allen empfangen, und alle werten die Messages aus.
    Ist die Adresse (der Header) nicht für sie, interessiert sie das ganze Packet nicht.
    Also sendet µC1 dirket zu µC2. Du solltest µC2 schon eine Prüfsumme oder so zurückschicken lassen, denn alles andere ist nicht so toll...

    Der Witz des Systems ist jetzt, dass wenn µC2 keine Prüfsumme zurückschickt (erhat das Packet nicht erhalten) kann ein anderer Roboter, der eine Kopie des Packets hat, diese nochmals versenden, dient also als Relais. Also "An µC2 von µC1 über µC7".
    Kommt eine prüfumme zurück, können alle Roboter das Packet löschen, und alles ist in Butter. Der header heißt dann "An µC2 von µC1". Die Message wurde nie weitergereicht.
    So habe ich das gemeint, aber das geht ja nicht, sagst du.
    Aber das nur am Rande.

    Hm. Klar, auf einer Frequenz ist das halt immer so eine Sache.
    Der Sender sollte ein Bisschen in den Äther hören, ob gerade eine Sendung läuft. So sind schonmal 90% der Fälle von 'Kauderwelsch' abgedeckt.
    Wenn jetzt beide wirklich 100% gleichzeitug anfangen wollen, dann kommt ja nur Müll bei den anderen an. Ergo sie verstehen es nicht.
    Was passiert? Der Müll wird von den anderen Robotern als Müll herausgefiltert, erreicht also die Auswertstufe garnicht, es erfolgt also keine Bestätigungsmessage in Form eine Prüfsumme.
    Bekommen beide der gleichzeitugsender innerhalb einer gewissen Zeit keine Antwort, warten sie eine Zufällige Zeit, hochrchen, dann senden sie weider.
    Und das wiederhohlt sich halt.

    Der Vorteil dieses Systems ist, dass wenn µC2 von µC1 ausser Reichweite ist, dass das dann von µC7, der ja mittendrin steht, nochmal gesendet wird...
    So würd ich das machen.

    VLG Tobi
    http://www.tobias-schlegel.de
    "An AVR can solve (almost) every problem" - ts

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    06.11.2004
    Beiträge
    1.693
    Wir haben uns beide nicht verstanden. Ich braucht in erster Linie kein Protokoll wie man das aufbauen kann, sondern die Verteilung der Hardware (was jetzt etwas blöd ausgedrückt ist) auf welcher Frequenz kann wer zu wem senden...

    Und es ist absolut nicht vorgesehen weder eine Empfangsbestätigung zu senden noch die Paket über mehrere Stationen zu senden. Wenn einer außerhalb der Reichweite ist, hat er halt Pech. Und das gute dadran ist, es ist nicht schlimm wenn er Pech hat.
    Ein Header ist im Prinzip eingebaut. Anhand der Bits sieht der Empfänger ob er die 2-3 Bytes gebrauchen kann oder nicht.

    Ich danke dir wirklich das du dir Gedanken machst, aber mein problem liegt an einer anderen Stelle.

    Wie kann ich es erreichen, wenn ich 2+x Einheiten in einem Cluster habe, auf möglichst nur einer oder auch auf zwei Frequenzen was zu senden und gleichzeitig was zu empfangen.
    Man steht im Leben ja öfters vor Problemen und findet die einfachste Lösung nicht, weil sie so einfach ist, das man nicht drauf kommt.
    Ich habe nur das Gefühl, das es bei mir mal grade wieder soweit ist
    nsonsten muss ich die Lösung mit einer Frequenz nehmen und akzeptieren, das einige Pakete ab und zu mal verloren gehen, aber sowieso in relativ ungleichmässigen Abständen neu gesendet werden und somit irgendwann auch ankommen.

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.06.2004
    Ort
    Bad Schussenried in Oberschwaben
    Alter
    34
    Beiträge
    1.461
    Hi!

    Na dnn ist ja alles in Butter...

    Du kannst schlicht und ergreifend nicht gleichzeitig senden oder empfangen. Geht nicht.
    Ich glaube, dass du dein System so aufbauen solltest, denn durch die Packetorientierung kann jeder senden ann er will.

    Und wenn es eh egal ist, ob ein roboter pech hat, dann kannst du eigentlich deine Strings so versenden.

    Du musst halt wenn du densen willst, den sender online schalten, und standardmäßig den Empfänger.
    Mehrere Packets gleichzeitig gehen nur mit rooter.

    Also: Du empfängst standardmäßig, und sendest halt, wenn du senden willst.

    Ich weis ehrlichgesagt nicht so recht, wo dien Problem liegt....

    Frage: Was wär denn mit Easy Radio??

    VLG Tobi
    http://www.tobias-schlegel.de
    "An AVR can solve (almost) every problem" - ts

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    06.11.2004
    Beiträge
    1.693
    Ich weis ehrlichgesagt nicht so recht, wo dien Problem liegt....
    Ich würde gerne senden um empfangen gleichzeitig wie wann man Tx und Rx beim PC gekreuzt verbindet.
    Ich dachte nur es geht irgendwie und ich sehe den Wald vor lauter Bäumennicht. Dann hätte ich mich hinterher geärgert.

    Was für ein Funkmodul ich nehme weiss ich noch nicht. Es soll klein und günstig sein, wenig Strom verbrauchen und die Sendeleistung darf nicht zu groß sein oder muss mind. regelbar sein, das ich nicht viel weiter als 20m komme damit. Besonders die Faktoren klein und günstig sind wichtig. Günstig wegen der eventuellen Vielzahl die benötigt wird.

  9. #9
    Neuer Benutzer Öfters hier
    Registriert seit
    31.08.2005
    Beiträge
    13
    @tobimc: Bei Ethernet kommt Müll bei den anderen an
    (sogar beim Sender selbst), weil sich die Aussendungen
    vermischen. Bei Funkübertragung auf derselben Frequenz
    drückt der stärkere Sender den schwächeren Sender weg
    (je nach Entfernung): Die einen empfangen Message A,
    die anderen Message B. Hier ist es also komplizierter.

    Im Übrigen ist das Problem bekannt aus dem wirklichen Leben:
    in einer Konferenzschaltung hat jeder weniger Möglichkeiten
    zu Wort zu kommen als bei einem one-to-one Telefonat.

  10. #10
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.06.2004
    Ort
    Bad Schussenried in Oberschwaben
    Alter
    34
    Beiträge
    1.461
    Hi!

    Naja, aber der Sender, der schwächer ist, hat meist immernoch genug leistung, den anderen so zu stören, dass müll ankommt.

    Ich würde mir das Problem garnicht machen. ich kann die easyRADIO-Module nur empfehlen, benutze ich auch.
    TxD RxD und eine Flusskonttrolleitung. Das versenden der Daten managt das Modul selbst.
    es sind 10 Frequenzen wählbar und die Sendeleistung lässt sich von 1-10mW in 1mW Schritten einstellen.
    AD-Ausgabe der Empfangsfeldstärke.

    Kann ich nur empfehlen. Du musst ja das Rad nicht neu erfeinden...

    VLG Tobi
    http://www.tobias-schlegel.de
    "An AVR can solve (almost) every problem" - ts

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Solar Speicher und Akkus Tests