mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Drahtlose Übertragung von Messwerten mehrerer "Slaves"


Autor: Benny Hankister (bennyhankister)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Wolfgang (Gast)
Datum:

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

Autor: Klugscheisser (Gast)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: Wolfgang (Gast)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: Wolfgang (Gast)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: Georg (Gast)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: dunno.. (Gast)
Datum:

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

Autor: H.Joachim Seifert (crazyhorse)
Datum:

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

Autor: Jack (Gast)
Datum:

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

Autor: Axel Schwenke (a-za-z0-9)
Datum:

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

Autor: Oliver S. (oliverso)
Datum:

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

Autor: Karsten B. (kastenhq2010)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WLAN? Ist das nicht dezent übertrieben? Warum nicht einfach Bluetooth 
und zyklisch die Werte abfragen?

Autor: Axel Schwenke (a-za-z0-9)
Datum:

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

Autor: Frank Esselbach (Firma: Q3) (qualidat)
Datum:

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

Autor: Blackbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und einen Timestamp.

Blackbird

Autor: Blackbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... relativ zum Startsignal.

Sorry, vergessen.

Blackbird

Autor: c-hater (Gast)
Datum:

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

Autor: Wolfgang (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Karsten B. (kastenhq2010)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Eine Sekunde verzögert grafisch darstellen?

Autor: Axel Schwenke (a-za-z0-9)
Datum:

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

Autor: Nosnibor (Gast)
Datum:

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

Autor: Wolfgang Erbes (Firma: janeeisklar) (whattheheck)
Datum:

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

Autor: X4U (Gast)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: Der Andere (Gast)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: Draco (Gast)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

Autor: Reiner O. (elux)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Draco (Gast)
Datum:

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

Autor: Thomas Horn (flaretom)
Datum:

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

Autor: Stephan Henning (stephan-)
Datum:

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

Autor: Draco (Gast)
Datum:

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

Autor: Benny Hankister (bennyhankister)
Datum:

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

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.