Hallo zusammen,
wir denken derzeit darüber nach ein drahtloses Sensornetz für unser
Technikum aufzubauen. Im Prinzip geht es darum Vibrationen von Motoren
per Sensor zu detektieren und an eine zentrale Einheit zu senden.
Als Verfahrenstechniker bin ich dabei leider bereits sehr schnell an das
Ende meines Wissens gestoßen.
Die Kern-Anforderungen:
- pro Motor mehrere Sensoren (ca.10-20)
- mehrere Motoren (ca. 10-20+) teilweise gleichzeitig im Betrieb
- Reichweite sollte groß sein (100 Meter+)
- Datenübertragung sollte im Sekundentakt erfolgen
- Zentrale Einheit zum Sammeln der Daten kann ein einfacher
PC/Server sein
- Batteriebetrieb, je länger desto besser (natürlich ;-))
- Kosten möglichst gering (natürlich ;-))
- weitere Anforderungen für eine ferne Zukunft, Übertragung von
Steuerungen
Soweit die Kern-Anforderungen.
Meine grundsätzliche Idee sieht nun wie folgt aus:
- Jeder Motor bekommt ein Funkmodul, welches entsprechend Senden und
Empfangen kann
- Jedes dieser Funkmodule fasst die einzelnen Sensoren zusammen und
sendet die jeweiligen Werte an die zentrale Einheit
- Die zentrale Einheit bildet ein Empfänger(später auch mit Sender) der
alle Daten abspeichert
Meine Fragen:
1) Ist die grundsätzliche Idee soweit logisch?
2) Falls, nein: Was fehlt?
3) Falls, ja: Wie mache ich am besten weiter? Ich würde gerne als
Funktechnik Zigbee nehmen, da dieses wohl am flexibelsten ist. Gerne
hier auch mit Internet of Things Unterstützung (Zigbee IP). Der Plan ist
jetzt Sensoren mit einem µController zu verbinden und als Funkmodul z.B.
den TI CC2538 (http://www.ti.com/product/cc2538) verbauen. Stelle ich
mir das zu einfach vor? Wo fange ich am besten an?
Bin leider wie gesagt komplett unerfahren mit µController, aber klingt
nach einem spannenden Vorhaben, bei dem man viel lernen kann.
Danke für die Aufmerksamkeit und ich freue mich auf eure Antworten.
Grüße, Stefan
>Wo fange ich am besten an? Kauf dir einen uC und lass eine LED leuchten. Das ist Stufe 1. Das was du möchtest ist Stufe 1001.
100m sind in gestörter Umgebung sportlich. Kabel sind unmöglich? Deine zentrale Einheit muß senden können. Einen Datensammler nach dem anderen abfragen. Vielleicht ist hier RPi gut, ggf. mit WLAN-shield. Pro Motor einen.
Also 400+ Sensoren sollen Sekündlich Messungen per Funk an einen zentralen Empfänger senden. Das sind also gerade mal 2,5 Millisekunden pro Paket inclusive Kollisionsbehandlung und Fehlerkorrektur. Das wird sehr aufwändig - ich trau mich nicht ran. > weitere Anforderungen für eine ferne Zukunft Was soll das heissen? Eierlegende Wollmilchsau? Frei-Fahrtschein für alle Eventualitätten? Kannst du vergessen. Ohne konkrete Anforderung würde ich keine Zusage für "weitere Anforderungen" abgeben. > Vielleicht ist hier RPi gut Vermutlich nicht, weil der Linux Kernel mit gewissen Verzögerungen zwischen den tasks umschaltet. Weniger als eine Millisekunde wäre da sehr ungewöhnlich.
Ach, ich hab' was überlesen: > Jedes dieser Funkmodule fasst die einzelnen Sensoren zusammen > und sendet die jeweiligen Werte an die zentrale Einheit Na dann ist das Timing ja doch nicht so spektakulär. Ich würde erstmal nach besonders störfesten Funkmodulen ausschau halten.
Wäre vielleicht besser pro Motor einen WLAN-Zentralle und von da mit Kabel zu den Sensoren. Wenn der Platz kein Problem ist Wurde sogar mit vielen SPS Herstellern und einer Visualisierung/SCADA gehen.
Also mit IEEE 802.15.4 und OQPSK250 kbit/s braucht ein Packet im MAC Format 1888us (40 byte Payload, 2 Byte pro Sensor). Mit 20 Motoren wird ohne ACK frames der Kanal zu 3.6% belegt ... auch wenn bis zu 3 Hops pro Knoten verwendet werden kommt man im schlimmsten Fall auf 15% Kanalbelegung - etwas wird noch durch CCA hinzu kommen, aber es sollte machbar sein, ggf. kann man immer noch ueber Datenkomression bei den Sensorwerten nachdenken. In einer 100m Halle, womoeglich Stahlbeton, wird es wegen der Reflexionen (2.4GHz) sicher erforderlich sein, Hops/Router zu verwenden.
Gibt es in der Halle schon W-LAN? Wenn ja wäre das wohl der einfachste Weg. Stefan H. schrieb: > Bin leider wie gesagt komplett unerfahren mit µController, aber klingt > nach einem spannenden Vorhaben, bei dem man viel lernen kann. Ohne Zweifel. Wenn jemand noch nicht programmieren kann und auch keine Ahnung von HTML, Webserver und Datenbanken hat und sich als erstes Projekt gleich mal eine selbstgeschriebene Internetshop-Software als Einstieg aussucht, ist das in etwa vergleichbar. Ist irgendwie zu schaffen aber nur mit genügend Zeit und Fleiss und dranbleiben, auch wenn es Rückschläge gibt, und die wird es geben! Fang deutlich kleiner an.
Wie sieht es mit folgender Konfiguration aus: Einzelne Cluster aus nRF24 o.ä. (MySensors bietet hier alles nötige). Pro Cluster ein Gateway an WLAN/Zigbee/886 für größere Reichweite. Das sorgt auch für die nötige Lastverteilung. Ich mache so was für Hausautomation: Mehrere einfache Module in den Zimmern (Sparmatic+nRf24, Temperatur-/Fenstersensoren mit Mega328+nRF) und (geplant) pro Zimmer ein ESP8266 für die WLAN Anbindung (Momentan sind es noch Mega328+nRF+PA, die zu einem zentralen Raspberry Pi mit nRf24+PA senden). LG Tom
Beschäftige Dich mal mit 6LowPAN. Dabei werden nur IPv6-Pakete über ein Low-Power-Netzwerk (wie Zigbee) geschickt und der benötigte Router ersetzt nur den (komprimierten) IPv6-Header der 6LowPAN-Knoten durch einen IPv4-Header und schickt das ganze dann ins normale Netzwerk. In der Nähe von Motoren würde ich dann eher auf die Sub-GHz-Variante (868 MHz) setzen. Passende Module gibt es hier: http://www.libelium.com/products/waspmote-mote-runner-6lowpan/
Hallo zusammen, ich versuche mal auf die verschiedenen Punkte einzugehen und die weiteren Schritte zu besprechen. 1. Scheinbar bin ich da doch etwas naiv an die Sache herangetreten, was nicht heißt, dass ich einen Rückzieher mache, sondern mir erst einmal ein kleineres Projekt daraus mache (mit dem Ziel aus dem ersten Beitrag im Hinterkopf). 2. Kabel ist leider nicht möglich bzw. finde ich drahtlos einfach überschaulicher. Was jedoch nicht heißt, dass mehrere Sensoren an einem Motor per Kabel mit einem Funkmodul verbunden werden könnten, falls das technisch leichter wäre 3. WLAN hätte ich aufgrund von der maximalen Anzahl an Funkern (verbessert mich, wenn ich falsch liege, aber vielleicht wächst das System über die Jahre hinweg) und des Stromverbrauches ausgeschlossen 4. nRF24, ist interessant, unten mehr dazu. Mein Ansatz wäre also das Problem auf ein kleineres zu schrumpfen und Udos Rat zu folgen. Beginnen möchte ich also damit ein Sensorsignal per Funk an einem Empfänger (z.B. an einem Laptop) zu senden. Der erste Schritt, festlegen der Funktechnologie (mit der eventuellen Erweiterung für die Zukunft im Hinterkopf), drei Möglichkeiten finde ich interessant: *A)* Zigbee, mit XBee Modulen. Vorteil: Größe des Sensornetzes ist laut Literatur sehr groß skalierbar Nachteil: Wohl etwas teurer *B)* nrf24, z.B. mit nrf24l01+. Vorteil: sehr günstig im Vergleich, Nachteil: Netzwerkgröße, maximal 6 Empfänger/Sender. Frage hierzu: Kann ich mir ein Netzwerk hier wie einen Baum aufbauen? z.B. 6*6*6 Module auf drei eben mit entsprechend 216 Blättern (leaves) auf der untersten Ebene mit insgesamt 216 + 36 + 6 Modulen? *C)* 6LoWPAN Vorteil: ähnlich wie Zigbee, nur offener Nachteil: weniger beliebt als Zigbee _Fragen dazu:_ 1) Ist die Grundauswahl soweit in Ordnung? 2) Zu was würdet ihr mir raten und gibt es vielleicht schon konkrete Umsetzungen hinsichtlich Auswahl der Komponenten? Ich danke euch für eure Antworten, sieht so als hätte ich ein neues Hobby ;-) Gruß, Stefan
Stefan H. schrieb: > 1) Ist die Grundauswahl soweit in Ordnung? Das kann doch keine beurteilen. Du musst mal mit klaren Spzifikationen rüberkommen. Deine ganzen Beiträge sind ein einziges geplappere ohne konkrete Ansätze. Da kann man nix beurteilen. Du musst genau wissen wieviele Daten pro Zyklus pro Motor übertragen werden müssen. Außerdem du dir dazu ein Telegramm (Adresse, Statusflags, etc) überlegen. Dann kannst du dir Module selektieren die die benötigte Datenrate abkönnen. Außerdem muss das System die gewünschte Anzahl von Knoten beherrschen können. Das ist alles nicht so einfach bei solch einer Anzahl von Knoten. Stefan H. schrieb: > 2. Kabel ist leider nicht möglich bzw. finde ich drahtlos einfach > überschaulicher. Es hat gute Gründe warum sich das im industriellen Umfeld so gut wie überhaupt nicht etabliert hat. Hunderte Akkus die ständig geladen werden müssen. Alle hundert Zyklen müssen die Akkus ausgetauscht werden (-> Kosten). Adressverwaltung von Hunderten Knoten ist nötig, Probleme bei der Störfestigkeit, Zertifizierungsprobleme, und und und.
Hallo Stefan, > wir denken derzeit darüber nach ein drahtloses Sensornetz für unser > Technikum aufzubauen. Im Prinzip geht es darum Vibrationen von Motoren > per Sensor zu detektieren und an eine zentrale Einheit zu senden. Was für Motoren? Elektro- oder Verbrennungsmaschinen? Wie groß (Baugröße, Leistung) ist so ein Motor? > Die Kern-Anforderungen: > - pro Motor mehrere Sensoren (ca.10-20) Warum braucht man so viele Sensoren für eine Vibrationsüberwachnung? Was sind das für Sensoren? Beschleunigung (MEMS)? > - Datenübertragung sollte im Sekundentakt erfolgen Hast du schon mal über eine Vorverarbeitung in den Slaves nachgedacht? Das würde die zu übertragende Datenmenge ggf. deutlich reduzieren. Mit freundlichen Grüßen Thorsten Ostermann
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.