Guten Tag zusammen, es gibt sehr viele Tutorials und Bücher über "eine" drahtlose Verbindung zwischen zwei Schaltungen, allerdings suche ich eine Lösung für folgende Aufgabenstellung: Es müssen mehrere Sensoren (ca. 5) kontinuierlich und drahtlos durch einen "Master" (vllt Arduino) abgefragt werden. Pro Sensor werden ca. 32 Bit pro Intervall abgefragt. Es sollen alle Sensoren je mindestens 25 mal pro Sekunde abgefragt werden, also ca. 125 Abfragen pro Sekunde im Falle von 5 Sensoren. Multipliziert mit 32 Bit ergibt das eine Rate von 500 Bytes/s. Erste Frage: Macht es Sinn die Sensoren kontinuierlich senden zu lassen und nur reihum abzufragen (Senden auf unterschiedlichen Frequenzen? Senden auf der gleichen Frequenz abwechselnd zu bestimmten Zeitslots? (Synchronisierung erforderlich!)) oder ist es sinnvoller die Daten explizit anzufordern, per ISR evtl., sodass nur ein Sensor pro Abruf aktiv ist? Ohne nun genau um eine Lösung zu bitten, möchte ich hier gerne fragen in welche Richtung meine Recherche gehen soll: Bluetooth? Zigbee? WLAN? NRF24L01? Für erste Denkanstöße und Wegweiser wäre ich sehr dankbar! Gruß! Benny
:
Bearbeitet durch User
Benny H. schrieb: > Es müssen mehrere Sensoren (ca. 5) kontinuierlich und drahtlos durch > einen "Master" (vllt Arduino) abgefragt werden. Muss das sein? Das erhöht den Datenverkehr deutlich. Was soll passieren wenn Daten mal nicht ankommen? Muss dann wiederholt werden? Können sich die Slaves gegenseitig sehe? Dann wäre vielleicht CSMA/CA eine vernünftige Strategie.
Benny H. schrieb: > Es sollen alle Sensoren je mindestens 25 > mal pro Sekunde abgefragt werden, also ca. 125 Abfragen pro Sekunde im > Falle von 5 Sensoren. Multipliziert mit 32 Bit ergibt das eine Rate von > 500 Bytes/s. Das ist zu einfach gedacht. Du hast immer Protokolloverhead, denn eine Übertragung (über Funk) besteht nie allein aus den Nutzdaten. Benny H. schrieb: > Ohne nun genau um eine Lösung zu bitten, möchte ich hier gerne fragen in > welche Richtung meine Recherche gehen soll: Bluetooth? Zigbee? WLAN? > NRF24L01? Umgebungsbedingungen? Entfernungen?
Wolfgang schrieb: > Benny H. schrieb: >> Es müssen mehrere Sensoren (ca. 5) kontinuierlich und drahtlos durch >> einen "Master" (vllt Arduino) abgefragt werden. > > Muss das sein? Das erhöht den Datenverkehr deutlich. Ja schon, das muss sein. Die Sache ist recht zeitkritisch. > > Was soll passieren wenn Daten mal nicht ankommen? Muss dann wiederholt > werden? Nein, das ist nicht schlimm, solange kein Ausfall über mehrere Zyklen geschieht. Eine unvollständige Transmission wird einfach verworfen werden können. > > Können sich die Slaves gegenseitig sehe? Das ist nicht vorgesehen. Wenn das aber bzgl. einer Synchronisation notwendig ist, kann man drüber nachdenken. :) > > Dann wäre vielleicht CSMA/CA eine vernünftige Strategie. Danke! Ich seh's mir an!
Klugscheisser schrieb: > Benny H. schrieb: >> Es sollen alle Sensoren je mindestens 25 >> mal pro Sekunde abgefragt werden, also ca. 125 Abfragen pro Sekunde im >> Falle von 5 Sensoren. Multipliziert mit 32 Bit ergibt das eine Rate von >> 500 Bytes/s. > > Das ist zu einfach gedacht. Du hast immer Protokolloverhead, denn eine > Übertragung (über Funk) besteht nie allein aus den Nutzdaten. Stimmt, daran hatte ich naiverweise nicht gedacht. Allerdings denke ich, dass selbst eine doppelt so hohe Datenrate für ein geeignetes System keine Schwierigkeit darstellen wird. Soweit zu einer weiteren naiven Annahme. :) > > Benny H. schrieb: >> Ohne nun genau um eine Lösung zu bitten, möchte ich hier gerne fragen in >> welche Richtung meine Recherche gehen soll: Bluetooth? Zigbee? WLAN? >> NRF24L01? > > Umgebungsbedingungen? Entfernungen? Im Freien, aber nicht zwangsläufig "LOS". Entfernung max 10 m. Danke schonmal und Gruß!
Benny H. schrieb: > Ja schon, das muss sein. Die Sache ist recht zeitkritisch. Warum kann nicht jeder Slave selbständig sein Ding tun und unabhängig von "der Sache" die Daten übertragen. Vielleicht erzählst du einfach mal, worum es geht. Benny H. schrieb: >> Können sich die Slaves gegenseitig sehe? > > Das ist nicht vorgesehen. Wenn das aber bzgl. einer Synchronisation > notwendig ist, kann man drüber nachdenken. :) Falls die Slave gegenseitig in Funkreichweite sind und den selben Funkkanal benutzen, können sie sich sehen. Dann muss man da nicht vorsehen. Und wenn die Slaves nicht den selben Funkkanal benutzen, bauen sie unabhängig ihren Punkt-zu-Punkt Verbindung zum Mast auf. Dann ist das völlig egal, ob das 1 oder 5 Slaves tun.
Wolfgang schrieb: > Warum kann nicht jeder Slave selbständig sein Ding tun und unabhängig > von "der Sache" die Daten übertragen. Das verstehe ich nicht ganz. Inwiefern "sein Ding tun"? Die Sensoren sollen Werte erfassen und mittels eines kleine Controllers an den Master per Funk übertragen. Die Auswertung der Daten soll dann der Master übernehmen. Wahrscheinlich wird das ein Pad sein, also eine App, genauer gesagt. > > Vielleicht erzählst du einfach mal, worum es geht. Ich bitte um Verständnis, wenn ich da nicht 100%ig ausführlich berichten kann. Aber ich werde gerne etwas genauer. :) Es sollen Bewegungsdaten (Accelerator- & Gyroscope-Daten) erhoben werden von ca. 5 Teilnehmern, die sich innerhalb eines Radius von max. 5 m bewegen. Diese Bewegungsdaten sollen zentral ausgewertet werden und anschließend graphisch repräsentiert werden. (Letzteres ist aber keine Sache mehr für dieses Forum.) Zeitkritisch ist das deshalb, weil die Bewegungen ziemlich genau und quasi-parallel erfasst und ausgewertet werden sollen. Man stelle sich da zB Synchronschwimmen vor. > Falls die Slave gegenseitig in Funkreichweite sind und den selben > Funkkanal benutzen, können sie sich sehen. Dann muss man da nicht > vorsehen. Das ist der Fall. Sie sind definitiv in Funkreichweite. > > Und wenn die Slaves nicht den selben Funkkanal benutzen, bauen sie > unabhängig ihren Punkt-zu-Punkt Verbindung zum Mast auf. Dann ist das > völlig egal, ob das 1 oder 5 Slaves tun. Ist sicher auch eine Alternative. Die bessere? Das muss ich noch herausfinden...
Benny H. schrieb: > Inwiefern "sein Ding tun"? Damit meinte ich "messen und übertragen alle 40ms", unabhängig von einer Aufforderung durch den Master > Zeitkritisch ist das deshalb, weil die Bewegungen > ziemlich genau und quasi-parallel erfasst und ausgewertet werden sollen. Was heißt "quasi", ausgedrückt in Millisekunden? Wie genau gleichzeitig muss das sein? Wenn es auf sauber synchronisierte Abtastung ankommt, könnte der Master ein Triggersignal senden, dass alle Slaves empfangen. Anschließend könnten die Slaves ihre Daten per CSMA übertragen, ohne dass sich der Master da weiter einmischen muss.
Wolfgang schrieb: >> Zeitkritisch ist das deshalb, weil die Bewegungen >> ziemlich genau und quasi-parallel erfasst und ausgewertet werden sollen. > > Was heißt "quasi", ausgedrückt in Millisekunden? Wie genau gleichzeitig > muss das sein? > Die Daten der 5 Sensoren sollen "grafisch" gleichzeitig beim Master angezeigt werden, also in einer App. Für eine flüssige Darstellung nahm ich zunächst 25 Messungen pro Sekunde pro Slave an. Wir kommen damit auf 125 Messungen pro Sekunde. Damit steht jedem Slave ein Slot von maximal 8 ms zur Verfügung um ca. 32 Bit (netto, also plus header) zu übertragen. > Wenn es auf sauber synchronisierte Abtastung ankommt, könnte der Master > ein Triggersignal senden, dass alle Slaves empfangen. Anschließend > könnten die Slaves ihre Daten per CSMA übertragen, ohne dass sich der > Master da weiter einmischen muss. Interessant. Allerdings müsste doch dann jeder Slave "warten bis er dran ist", richtig? Wenn alle direkt nach dem Trigger senden, gibt's Kollisionen. Lieg ich richtig? Man müsste also eine individuelle Wartezeit festlegen, sodass die Messungen nacheinander gesendet werden. Also Trigger -> Sensor1.send(), Sensor2.wait(10) -> Sensor2.send(), Sensor3.wait(20) -> Sensor3.send() usw... Dafür müssten aber allesamt den Trigger wirklich zeitgleich empfangen bzw. darauf reagieren...
Benny H. schrieb: > Für eine flüssige Darstellung nahm > ich zunächst 25 Messungen pro Sekunde pro Slave an. Deine Augen und dein Gehirn sind also in der Lage, 25 Messwerte pro Sekunde abzulesen und zu erfassen? Gratuliere zu deiner Mutation zum Übermenschen. Ich schaffe eher so 5. Georg
Georg schrieb: > Benny H. schrieb: >> Für eine flüssige Darstellung nahm >> ich zunächst 25 Messungen pro Sekunde pro Slave an. > > Deine Augen und dein Gehirn sind also in der Lage, 25 Messwerte pro > Sekunde abzulesen und zu erfassen? Gratuliere zu deiner Mutation zum > Übermenschen. Ich schaffe eher so 5. > > Georg Lieber Georg, für einen evtl. vorhandenen Frust, der Dich dazu ermutig solch destruktive und nutzlose Kommentare zu verfassen, kann ich leider nichts. Daher mit aller Höflichkeit: lass es einfach. Wenn Du nichts konstruktives dazu beitragen kannst, mach was anderes. Schau Tierbabyvideos, entspann Dich, geh joggen, o.ä.. Um nun mit gutem Willen die eigentliche Frage, die hinter dem Quatsch steckt, den Georg gepostet hat, zu beantworten: Es sollen 25 Messwerte pro Sekunde erfasst werden um damit GRAFISCH (wie vorher beschrieben) die Auswertung der mittels eines Algorithmus sinnvoll bearbeiteten Messwerte anzuzeigen. Somit erhalte ich ein flüssiges Feedback der Bewegungen in "Echtzeit". Das soll aber nicht Thema dieses Threads sein.
Benny H. schrieb: > Dafür müssten aber allesamt > den Trigger wirklich zeitgleich empfangen bzw. darauf reagieren... Wenn man interruptgesteuert arbeitet und sauber programmiert, ist das bis auf einen gewissen jitter bestimmt drin. Brauchst du ja eh, auch damit deine messwerte zueinander passen, es darf nur sehr geringe jitter geben. wann dann der messwert wirklich beim master eintrifft ist ja egal, solange du deine zykluszeit nicht überschreitest. ist bei 40ms sicher sportlich.. ich denke da zuerst mal an WLAN, habe aber keine erfahrung wie ein jitter da aussehen würde.. muss das ganze in echtzeit passieren, oder reichts wenn du die daten halt zugeordnet bekommst? idee: 40ms trigger über funk, datensammeln erstmal auf den slaves?
Würde auch WLAN nehmen. Im passenden Zeitraster die Daten sammeln und zwischenspeichern und dann im Paket verschicken, vielleicht jede Sekunde. Alles kommt an, ohne dich drum kümmern zu müssen. Damit wirst du unabhängig von Latenzen im Funkkanal.
Eigentlich hatte ich eine längere Antwort vorbereitet. Dann habe ich die letzte Antwort des Fragestellers gesehen und meine vorbereitete Antwort gelöscht. Das ganze ist wieder ein Klassiker :( Fragesteller verrät nichts, lässt sich Würmer aus der Nase ziehen, aber wird sofort pampig und erhebt Ansprüche wenn jemand etwas in seinen Andeutungen übersieht.
Benny H. schrieb: > Es sollen Bewegungsdaten > (Accelerator- & Gyroscope-Daten) erhoben werden von ca. 5 Teilnehmern, > die sich innerhalb eines Radius von max. 5 m bewegen. Diese > Bewegungsdaten sollen zentral ausgewertet werden und anschließend > graphisch repräsentiert werden. (Letzteres ist aber keine Sache mehr für > dieses Forum.) Zeitkritisch ist das deshalb, weil die Bewegungen > ziemlich genau und quasi-parallel erfasst und ausgewertet werden sollen. Es gibt da im wesentlichen zwei Ansätze. 1. Du läßt jeden Slave auf seiner eigenen Frequenz senden und baust 5 unabhängige Empfänger in den Master. Dann können die Slaves ganz unabhängig voneinander senden und der Master muß die Empfänger nur schnell genug pollen um keine Daten zu verpassen. Mit einem einzelnen Empfänger, der reihum auf die Frequenzen der 5 Slaves getuned wird, wirst du eher nicht glücklich werden, weil du dann die Slaves auch wieder mit dem Master synchronisieren müßtest. Dann kannst du auch gleich 2. machen: 2. Alle senden auf der gleichen Frequenz, aber nacheinander. Am einfachsten ist die Synchronisation, wenn der Server den Slaves der Reihe nach Redeerlaubnis gibt. Da es sowieso ein festes Zeitraster geben soll, reicht es ja aus wenn der Master reihum jedem Slave einen Zeitslot zuteilt. Variante 2 ist weniger Hardware-Aufwand und skaliert vermutlich besser. Kommt darauf an, wieviel Nutzbandbreite man hat und wieviel Slots man braucht. Dafür ist die Softwareseite aufwendiger.
Die ganzen Antworten sind müßig, solange diese Frage Wolfgang schrieb: > Was heißt "quasi", ausgedrückt in Millisekunden? Wie genau gleichzeitig > muss das sein? nicht beantwortet ist. Und bei der bisherigen Argumentation zum Thema Abtasthäufigkeit wirds mit der Antwort wohl auch nichts werden. Also frag einfach mit einem Funkssystem deines geringsten Mißtrauens die Sensoren irgendwie irgendwann ab... Oliver
WLAN? Ist das nicht dezent übertrieben? Warum nicht einfach Bluetooth und zyklisch die Werte abfragen?
Oliver S. schrieb: > Die ganzen Antworten sind müßig, solange diese Frage > > Wolfgang schrieb: >> Was heißt "quasi", ausgedrückt in Millisekunden? Wie genau gleichzeitig >> muss das sein? > > nicht beantwortet ist. Quatsch. Echte Gleichzeitigkeit ist gar nicht verlangt. Das wurde nur von ein paar Leuten in die (sicherlich etwas unglücklich formulierte) Frage des TE hineininterpretiert. Er hat einfach 5 asynchrone Datenquellen, die ca. 25 mal pro Sekunde Meßwerte produzieren und will diese Meßwerte an seinen Master senden. Vermutlich ist es ihm auch egal, wenn die Slaves immer 25 Meßwerte zusammen verschicken - so lange die zeitliche Auflösung reicht.
Ich würde es mit folgender Strategie versuchen: Der Master fordert nicht jeden Slave einzeln zum Senden auf, sondern gibt ein für alle geltendes "Startsignal" und die Slaves senden danach mit einer individuell eingestellten Verzögerung nacheinander. Zur Sicherheit sollte jeder Slave zu den Messwerten eine Kennung und eine Prüfsumme dazupacken.
... relativ zum Startsignal. Sorry, vergessen. Blackbird
Benny H. schrieb: > Erste Frage: Macht es Sinn die Sensoren kontinuierlich senden zu lassen Nein, natürlich nicht. In aller Regel sind ja die in der Fläche verteilten Sensoren gerade die Stellen, an denen es besonders energieeffizient zugehen sollte, weil sie durch eben diese Verteilung halt (oft) nicht netzversorgbar sind. > Ohne nun genau um eine Lösung zu bitten, möchte ich hier gerne fragen in > welche Richtung meine Recherche gehen soll: Bluetooth? Zigbee? WLAN? > NRF24L01? Die Entscheidung darüber wird i.d.R. durch andere Randbedingungen gefällt, nämlich die erforderliche Reichweite, Datenrate und Datensicherheit. Je höher die Anforderungen bei diesen drei Aspekten sind, desto höher ist tendenziell auch der Energieverbrauch.
Axel S. schrieb: > Vermutlich ist es ihm auch egal, > wenn die Slaves immer 25 Meßwerte zusammen verschicken - so lange die > zeitliche Auflösung reicht. Sicher? Benny H. schrieb: > Die Daten der 5 Sensoren sollen "grafisch" gleichzeitig beim Master > angezeigt werden, also in einer App. Für eine flüssige Darstellung nahm > ich zunächst 25 Messungen pro Sekunde pro Slave an. Wie soll die Darstellung flüssig werden, wenn die Slaves ihre Daten in Blöcken verschicken?
Eine Sekunde verzögert grafisch darstellen?
Wolfgang schrieb: > Axel S. schrieb: >> Vermutlich ist es ihm auch egal, >> wenn die Slaves immer 25 Meßwerte zusammen verschicken - so lange die >> zeitliche Auflösung reicht. > > Sicher? Aber sicher sicher. Wobei das auch nur ein Beispiel war. Je nachdem wieviel Bruttokapazität der Kanal hat, wird man sich entscheiden müssen wie kurz man die Slots machen kann. Denn zur Vermeidung von Kollisionen muß man immer ein wenig Zeit zwischen den Slots lassen. Je weniger Daten pro Slot übertragen werden, desto mehr schlagen diese Kunstpausen auf die Netto-Datenrate durch. Das Prinzip sieht man überall, wo Daten in Paketen übertragen werden. Bei Ethernet macht man Jumbo-Frames um die nutzbare Datenrate zu erhöhen. Bei Filesystemen schraubt man die Blocksize hoch. etc. > Benny H. schrieb: >> Die Daten der 5 Sensoren sollen "grafisch" gleichzeitig beim Master >> angezeigt werden, also in einer App. Für eine flüssige Darstellung nahm >> ich zunächst 25 Messungen pro Sekunde pro Slave an. > > Wie soll die Darstellung flüssig werden, wenn die Slaves ihre Daten in > Blöcken verschicken? Dann stellt die App die Daten halt mit einer Sekunde Verzögerung dar. Der Flüssigkeit tut das keinen Abbruch.
Axel S. schrieb: > Variante 2 ist weniger Hardware-Aufwand Eigentlich nicht. Bei Variante 1 braucht man für jeden Slave einen Sender (beim Slave) und einen Empfänger (beim Master) Bei Variante 2 braucht man auch für jeden Slave einen Sender (beim Slave) und einen Empfänger (auch beim Slave, damit er die Frage vom Master hören kann). Und zusätzlich noch einen Sender und einen Empfänger beim Master. Aber da heutzutage Sender und Empfänger kombiniert in einem Bauteil/Modul kaum teurer sind als ein Sender alleine, ist Variante 2 wohl die bessere: der Master sendet ein Startsignal, und jeder Slave antwortet nach einer Verzögerung, die seiner Adresse entspricht, so daß der Master die Daten nacheinander empfängt.
Benny H. schrieb: > Es sollen Bewegungsdaten > (Accelerator- & Gyroscope-Daten) erhoben werden von ca. 5 Teilnehmern, > die sich innerhalb eines Radius von max. 5 m bewegen. Diese > Bewegungsdaten sollen zentral ausgewertet werden und anschließend > graphisch repräsentiert werden. (Letzteres ist aber keine Sache mehr für > dieses Forum.) Zeitkritisch ist das deshalb, weil die Bewegungen > ziemlich genau und quasi-parallel erfasst und ausgewertet werden sollen. Sag doch gleich, dass du einen Drohnen-Schwarm steuern willst ;-)
Benny H. schrieb: > Erste Frage: Macht es Sinn die Sensoren kontinuierlich senden zu lassen > und nur reihum abzufragen (Senden auf unterschiedlichen Frequenzen? > Senden auf der gleichen Frequenz abwechselnd zu bestimmten Zeitslots? > (Synchronisierung erforderlich!)) oder ist es sinnvoller die Daten > explizit anzufordern, per ISR evtl., sodass nur ein Sensor pro Abruf > aktiv ist? Würde ich im Erstversuch mit 5 Bluetooth Verbindungen auf verschiedenen Kanälen machen. Dann brauchst du zwar insgesamt 10 Module (statt mindestens 6), aber du hast die Daten unabhängig voneinander am Prozessor und kannst Sie mit full speed abfragen. Der ganze Protokolloverhead entfällt und die Diskussion ob es nun Zeitschlitz-, Synchron- oder Kollisionstechnologie sein soll auch. Sie sind auch viel einfacher zu Identifizieren (z.B. mit nem Handy) weil jedes seinen Namen sofort sendet. Die Module sind zudem relativ günstig und einfach zu bedienen und wenn ich mich recht erinnere ist es auch egal ob du Sie zwischen den Telegrammen einfach abschaltest da die Verbindung eine Zeit lang bestehen bleibt.
Vielen Dank für die ganzen Kommentare und die konstruktive Hilfe! Ich bin derzeit etwas eingespannt als junger Vater, daher bleibt nicht viel Zeit für andere Dinge. Der ein oder andere wird's kennen... @ dunno >muss das ganze in echtzeit passieren, oder reichts wenn du die daten >halt zugeordnet bekommst? Nein, das muss wirklich Echtzeit sein, da die Bewegungen live beobachtet und ausgewertet werden sollen. Und die Daten müssen später auch noch abrufbar sein zu einer Analyse. Das ist aber eher etwas für's Speichermanagement. Das passt nicht unbedingt auf diese Baustelle hier. Wenn ich Deine Idee richtig verstehe, dann werden erstmal die Daten auf den Slaves gesammelt und bei einem Trigger des Masters, senden alle Slaves nacheinander ihre Daten an den Master, richtig? Müsste man ausprobieren. Ich weiß, dass man z.B. bei den ZigBee Modulen verschiedene Kanäle einrichten kann. Ob dann ein "gleichzeitiger" Versand infrage kommt, weiß ich nicht... Oder aber man verzögert den Versand mit einer ausreichenden Zeit. Eben n*40 ms mit n=0,1,2,3,4 bei 5 Teilnehmern. So als Idee... @Joachim: Diese Sekunde macht mir Bauchschmerzen. Das hieße doch auch, dass die Visualisierung mindestens 1 Sekunde Latenz aufweist, richtig? Das wäre schlecht. Latenz wird's sicherlich geben, keine Frage. Aber 1 Sekunde ist schon sehr viel, finde ich. @ Jack: >Fragesteller verrät nichts falsch >lässt sich Würmer aus der Nase ziehen weil ich nur soviel wie nötig darüber reden möchte. >aber wird sofort pampig und erhebt Ansprüche wenn jemand etwas in seinen >Andeutungen übersieht Pampig? Ich habe dem Georg lediglich Alternativen zu seinen nutzlosen Kommentaren aufgezählt. Oder erschienen seine Glückwünsche bzgl. meines übermenschlichen Daseins als annähernd hilfreich oder höflich? @ Axel: Deine 2. Variante finde ich klasse. So habe ich mir das auch vorgestellt. Ich muss immer wieder auf den ZigBee Standard zurückkommen, da er mir wirklich ideal dafür vorkommt. Ich kann damit sicherlich solch ein Zeitmanagement bzgl. der "Redeerlaubnis" einrichten, oder? Oder galt Deine Anspielung auf die doch etwas aufwendigere Softwarearbeit der Idee das alles selbst zu implementieren? Das scheint mir allerdings dann doch wie das Rad neu erfinden zu wollen, oder täusch ich mich? Danke nochmal! Zu Deinem zweiten Kommentar: Klar, es ist sicherlich eine Definitionssache, was nun mit Echtzeit gemeint ist. Natürlich ist eine Echtzeit im Sinne von Gleichzeitigkeit unmöglich. Es geht nur darum die Messwerte mit einer Rate abzufragen, auszuwerten und darzustellen, die eine Echtzeit für das menschliche Auge suggeriert.
Benny H. schrieb: > Pampig? Ich habe dem Georg lediglich Alternativen zu seinen nutzlosen > Kommentaren aufgezählt. Nö, deine Angaben sind so völlig überzogen. Man kann keine 5 Signale 25mal pro Sekunde als Mensch in Echtzeit auswerten, weder als Diagramm, noch als Grafik oder Zahlenkolonne. Du schaffst höchstens 10 - 20 mal weniger. Also brauchst du diese Datenmenge gar nicht in Echtzeit, höchstens für die spätere: Benny H. schrieb: > Und die Daten müssen später auch noch > abrufbar sein zu einer Analyse. Also ist dises Beharren auf "Echtzeit" ein völlig unnötiges Feature, ausser du hast nur die Hälfte des Problems erzählt und es gibt weitere Randbedingungen. Übrigens ist dein Beispiel Synchronschwimmen ganz prima, weil die meisten Sendemodule durch das Wasser wohl so stark gedämpft werden dass sie unter Wasser gar nichts liefern. Soviel zu Echtzeit.
Noch so einer... Der Andere schrieb: > Man kann keine 5 Signale 25mal pro Sekunde als Mensch in Echtzeit > auswerten, weder als Diagramm, noch als Grafik oder Zahlenkolonne. Du > schaffst höchstens 10 - 20 mal weniger. Man soll auch nicht alle 5 Signal gleichzeitig per Auge auswerten... Und auf die 25 Werte komme ich, damit es flüssig dargestellt werden kann. Weniger kann ich immer noch realisieren, falls ich doch nur 5 Werte pro Sekunde pro Sender brauche und anschließend die darzustellenden Werte per Interpolation ausgebe, um sie ruckelfrei zu visualisieren. Das allerdings geht zu Lasten der Auflösung, die m.M. nach schon mindestens 20 Werte pro Sekunde betragen soll, weil es sich um schnelle Bewegungsabläufe handelt. > Also ist dises Beharren auf "Echtzeit" ein völlig unnötiges Feature, > ausser du hast nur die Hälfte des Problems erzählt und es gibt weitere > Randbedingungen. Zum Thema "Echtzeit" hab ich sicherlich genug geschrieben. Und wenn Bewegungen live über Sensoren erfasst grafisch aufbereitet dargestellt werden sollen (vielleicht noch besser vergleichbar mit motion capturing), dann weiß ich nicht wie Du darauf kommst, das als "völlig unnötiges Feature" abzustempeln... keine Ahnung... > Übrigens ist dein Beispiel Synchronschwimmen ganz prima, weil die > meisten Sendemodule durch das Wasser wohl so stark gedämpft werden dass > sie unter Wasser gar nichts liefern. > Soviel zu Echtzeit. Ja? Ganz prima? Das freut mich sehr. Bevor ich komplett ausfallend werde, weil mich diese Sorte von Kommentaren einfach nur anko**en, hier nochmal eine kurze sachliche Erklärung dazu: Es ging dabei nur um eine Analogie. Dann nimm eben Synchronsprinter - über Wasser! Wie ich anfangs geschrieben habe, befinden sich die Module bzw. die Antennen "im Freien".
Ich danke nochmal allen, die hilfreiche Kommentare gegeben habeen. Ich denke, dass ich mit den XBee Modulen recht gut fahren werden, um die Aufgabe zu realisieren.
Da fällt mir doch glatt auf, dass ich gar nicht alle Antworten gelesen habe... sorry dafür! X4U schrieb: > > Würde ich im Erstversuch mit 5 Bluetooth Verbindungen auf verschiedenen > Kanälen machen. Ok, Danke! Interessant. Kann den mein Master (in meinem Fall wohl eine App auf einem Tablet) 5 Bluetooth Verbindungen parallel aufbauen? (Das kann ich natürlich recherchieren, aber naiv gefragt geht's schneller. :) ) Das müsste so sein, da nicht bei jeder Abfrage der Slaves die Verbindung wieder neu hergestellt werden kann, wenn das "pairen" lange dauert.
Benny H. schrieb: > Ok, Danke! Interessant. Kann den mein Master (in meinem Fall wohl eine > App auf einem Tablet) Bis jetzt war ich nur stiller Mitleser. Aber wie willst du denn ein Zigbee Modul bzw. mehrere an ein Tablet bekommen?! Zum Thema Motion Capturing: das wird auch nicht in Echtzeit dargestellt. Die Daten werden gesammelt, verarbeitet und dann dargestellt. Beim Motion Capturing nimmt man ja keine Bewegungssensoren sondern ein Kamerasystem. Dein ganzer Aufbau kommt einer Drohnen-Snycro relativ nahe. Da wird dies so gehandhabt: die Absolute Position wird mit Kamerasystemen ermittelt, ähnlich des der Motion Capturing, die Soll Ansteuerung wird meist per Funk realisiert und zwar jeder Client nacheinander. Das ist auch die übliche Verfahrensweise bei Sensoren, sei es Temperatur oder whatever. Master sendet eine Anforderung an Client N und Client N antwortet mit seinem aktuell gespeicherten Wert. Da fällt es auch nicht ins Gewicht ob er in dem aktuellen Frame gerade nicht fertig mit der aktuellen Auswertung ist, sondern er sendet den letzten aktuelle Messwert. Wenn es denn unbedingt an ein Tablett gehen muss ein MC mit USB CDC-HID und das Tablett dann mit USB-OTG die seriellen Daten empfangen lassen.
Hi Draco, oder Benny. :) > Bis jetzt war ich nur stiller Mitleser. Aber wie willst du denn ein > Zigbee Modul bzw. mehrere an ein Tablet bekommen?! Über Umwege sicherlich, aber ich stelle mir vor eine UART2USB Lösung zu nutzen. Die Daten sollen natürlich drahtlos am Koordinator empfangen, evtl. gepuffert und anschließend über UART an die App gesendet werden, bzw. die App liest die Daten aus (so ungefähr: http://www.allaboutcircuits.com/projects/communicate-with-your-arduino-through-android/). Aber das ist noch Zukunftsmusik... > > Zum Thema Motion Capturing: das wird auch nicht in Echtzeit dargestellt. > Die Daten werden gesammelt, verarbeitet und dann dargestellt. Beim > Motion Capturing nimmt man ja keine Bewegungssensoren sondern ein > Kamerasystem. Sorry, aber wir reiten zu lange auf dem Begriff Echtzeit rum. Lassen wir den Begriff einfach weg. Natürlich wird gepuffert und bearbeitet bevor etwas angezeigt werden soll. Das nimmt Zeit in Anspruch. Mir geht es nur darum, dass die Daten nicht einfach gesammelt und irgendwann mal bearbeitet und dargestellt werden sollen, sondern dass das so zeitnah wie möglich passieren soll. > > Dein ganzer Aufbau kommt einer Drohnen-Snycro relativ nahe. Da wird dies > so gehandhabt: die Absolute Position wird mit Kamerasystemen ermittelt, > ähnlich des der Motion Capturing, die Soll Ansteuerung wird meist per > Funk realisiert und zwar jeder Client nacheinander. Das ist auch die > übliche Verfahrensweise bei Sensoren, sei es Temperatur oder whatever. > Master sendet eine Anforderung an Client N und Client N antwortet mit > seinem aktuell gespeicherten Wert. Da fällt es auch nicht ins Gewicht ob > er in dem aktuellen Frame gerade nicht fertig mit der aktuellen > Auswertung ist, sondern er sendet den letzten aktuelle Messwert. Wenn es > denn unbedingt an ein Tablett gehen muss ein MC mit USB CDC-HID und das > Tablett dann mit USB-OTG die seriellen Daten empfangen lassen. Das klingt gut, danke. Und Du beantwortest ja auch Deine Frage von oben bzgl. Darstellung auf einem Tablet. :) Ein Drohnen-Synchro wird's nicht, aber bleiben wir doch einfach bei dem Beispiel. Ich will versuchen das mal zu wiederholen, in etwas abstrakterer Form: Ich habe 5 Sensoren, die je ca. 20 Messwerte/s erfassen. Diese ermittelten Messwerte werden gepuffert. Ein Master teilt den Slaves nacheinander mit ihre Werte zu übermitteln. Die gesammelten Werte werden in Paketen per serieller Schnittstelle an ein auswertendes Gerät (z.B. Tablet bzw. App) gesendet bzw. von diesem abgerufen. Im weiteren Verlauf werden diese Werte grafisch "hübsch" dargestellt, sodass etwas über die Synchronizität der 5 Teilnehmer bzgl. der Beschleunigung gesagt werden kann (vllt mithilfe von scichart.com o.ä.). Für mich klingt das erstmal realisierbar aber ich bin sehr dankbar für den Erfahrungsschatz eines jeden Mitlesers, falls ich's mir zu einfach vorstelle oder Stolperfallen übersehe. Wenn ich mir über collision avoidance keine Gedanken machen möchte, dann macht es doch Sinn "fertige" Lösungen einzusetzen, so etwas wie die ZigBee Module, die entsprechend konfiguriert werden, richtig? Bevor ich solche Sachen selbst schreibe, meine ich... Danke erstmal bis hierhin! Ich bin sehr froh über den Austausch.
Hallo, hier mal meine 2 Cents zur Übertragung: Nehmen wir mal an, Du verwendest zur Übertragung so etwas wie die bekannten RFM12. Die benötigen in der späteren Ausführung ein frei wählbares "Magic Byte", damit der Empfänger überhaupt zuhört. Ich würde alle Slaves auf den selben Kanal setzen und Jedem eine Nummer zuordnen (Device ID) Solche Features wie Listen before Talk erst mal aussen vor. Somit können sich alle Slaves sehen. Der Zeitslot ist 8 ms. Das Protokoll sähe in etwa so aus: Magic Byte, Sync (z.B. 0x55), Device ID, Daten, Time Stamp, Prüfsumme, Endbyte... Wenn der erste Slave seine Daten sendet, empfangen alle Anderen in einer ISR die ersten 2 Byte, das Magic Byte braucht der Empfänger um die Luke runterzulassen. In den anderen Slaves wird in der ISR erst mal ein 8 ms Timergestoppt, die Adresse ausgewertet und der 8 ms Timer wieder neu gestartet. Wenn der Dev 1 sendet, setzt Dev 2 in der ISR ein Sendeflag und nach Ablauf des Timers ist er mit Senden dran usw. Damit der Ausfall eines Slaves nicht das Ganze zum Stehen bringt, muss noch eine Fehlerbehandlung eingebaut werden a la "...jetzt erwarte ich eine Sendung von Dev X. Und wenn die nicht kommt, dann zähle ich die ID hoch und warte weiter auf meinen Slot zum Senden..." In der Timer ISR prüfst Du das Sendeflag und wenn gesetzt, wird gesendet. Wenn der Timer (den der Slave ja zwangsläufig erst nach Empfang und Auswertung der Dev-ID und somit später startet) abläuft und keine Empfangs-ISR vorher zuschlägt und das Sendeflag nicht gesetzt ist, hat der vorhergehende Slave nicht gesendet. Also ID hochzählen und Timer neu starten. Der Master braucht nur zuzuhören und die Daten zu empfangen. Zur Übertragung von Steuerkommandos vom Master zu den Slaves würde ich dann den Sync ändern, z.B. in 0xAA oder so.. Ist nur eine sehr grobe Skizze, aber so in diese Richtung würden meine Überlegungen wohl gehen... Gruss Elux
:
Bearbeitet durch User
Eigentlich gute Idee, aber: - Was ist wenn der Wert eines Sensors zufällig mit dem MagicByte / Syncbyte übereinstimmt. Wie verhält sich dann der zugehörige Client? - Was ist wenn der Client nun aber 10ms für die Wandlung braucht und aber über die 8ms kommt? - Wenn der Master anfordert, spart man sich den TimeStamp des Clients, da der Master ja den TimeStamp setzen kann. - Sechs verschiedene Zeitbasen im gesamten System halte ich gegenüber einer einzelnen Zeitbasis wesentlich unsicherer. Aber das die Clients sich selbst nacheinander "beauftragen" is keine schlechte Idee. Hat aber auch den Nachteil das man dann in allen entsprechenden Clients jedesmal die Reihenfolge ändern muss wenn man nun doch einen anderen Wert vorher braucht. Bei der Sternförmigen Anforderung braucht man bloß im Master die Reihenfolge ändern.
Hallo, Dann gäbe es ja noch die nRF24 mit ihrem "Enhanced Shockburst" und dem "Automatic Acknowledgement with Payload", d.h. man kann bis zu 6 Slaves mit einem Master verbinden, wobei die Slaves nur ihre Acknowledgement Buffer mit den Sensordaten füllen müssen. Der Master fragt einen Slave nach dem anderen ab, indem er ein leeres Packet verschickt. Der Slave-nRF24 bestätigt dies mit dem Acknowledge, welches die Sensordaten enthält. Im Slave gibts einen IRQ, der dafür sorgt, das neue Daten gemessen werden. So geht es dann zyklisch weiter. Der Master muss die empfangenen Daten nur noch bündeln und z.B. über ein Bluetoothmodul an PC etc. weiterreichen. Ist schnell, billig und auch die Reichweite sollte locker passen (evt. die Module mit ext. Antenne nehmen). Beste Grüße, Tom
irgendwie muss dann aber definiert sein wievile Clints es überhaupt gibt, bzw. muss bei einer Erweiterung der Anzahl das System angepasst werden. es muss ja mal "genullt" werden um den Ringelpietz von vorn zu beginnen. aber wer war denn nun der letzte der jetzt wieder anfangen muss ?
Naja, es gibt ja kein Bedarf für ein dynamisches Sensorarray. Es ist ja auf fünf begrenzt. Und wenn ein sechstes / siebtes hinzugefügt werden soll dann teilt man das dem Master halt mit.
Draco schrieb: > Aber das die Clients sich selbst nacheinander "beauftragen" is keine > schlechte Idee. Hat aber auch den Nachteil das man dann in allen > entsprechenden Clients jedesmal die Reihenfolge ändern muss wenn man nun > doch einen anderen Wert vorher braucht. Bei der Sternförmigen > Anforderung braucht man bloß im Master die Reihenfolge ändern. Eine sternförmige Anordnung ist sicherlich sinnvoll, behaupte ich mal. Und es kommt höchstwahrscheinlich keiner hinzu, wenn es mal installiert ist. Ob es bei 5 bleibt, weiß ich nicht. Können auch 10 werden. Mehr aber nicht. :) > Dann gäbe es ja noch die nRF24 mit ihrem "Enhanced Shockburst" und dem > "Automatic Acknowledgement with Payload", d.h. man kann bis zu 6 Slaves > mit einem Master verbinden, wobei die Slaves nur ihre Acknowledgement > Buffer mit den Sensordaten füllen müssen. Der Master fragt einen Slave > nach dem anderen ab, indem er ein leeres Packet verschickt. Der > Slave-nRF24 bestätigt dies mit dem Acknowledge, welches die Sensordaten > enthält. Im Slave gibts einen IRQ, der dafür sorgt, das neue Daten > gemessen werden. So geht es dann zyklisch weiter. > Der Master muss die empfangenen Daten nur noch bündeln und z.B. über ein > -Bluetoothmodul an PC etc. weiterreichen. Sehr interessant, weil einfach und effizient, finde ich. Falls es doch mehr als 6 Clients werden, müsste man zwei solcher Netze aufbauen und nacheinander im Wechsel abfragen. Also z.B. 8 Clients, je 4 in einem NRF24-Netz. Zwei MCUs als Master, von dem einer die Daten des anderen erhält und zusammen mit seinen Daten an den MasterMaster (die App des Tablets) weiterreicht. Könnte klappen, erscheint mir aber auch etwas von hinten durch die Brust ins Auge, oder so ähnlich... Aber könnte man es so machen? Kann man ja einfach ausprobieren. Die Module erscheinen mir auch ein klein wenig günstiger als der ZigBee Kram. Stephan H. schrieb: > irgendwie muss dann aber definiert sein wievile Clints es überhaupt > gibt, bzw. muss bei einer Erweiterung der Anzahl das System angepasst > werden. es muss ja mal "genullt" werden um den Ringelpietz von vorn zu > beginnen. aber wer war denn nun der letzte der jetzt wieder anfangen > muss ? Ja, es ist schon definiert, wieviele Clients es gibt, bzw. wird es definiert sein. Nach meiner Vorstellung liegt dem Master ein Array mit den Adressen der einzelnen Clients vor, fest programmiert. Ein dynamisches Array ist, wie Draco schon sagte, nicht vorgesehen.
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.