Hallo Community, möchte eine Reihe von Sensoren betreiben und deren Werte gleichzeitig von mehreren Mikrocontrolern bzw. Raspberry Pi ausgewertet werden. Das soll auch weiter funktionieren wenn einer dieser Empfänger abgekoppelt wird (also Weiterreichen der Daten geht nicht). Es braucht also ein Protokoll wo die Sensoren Daten einspeisen können und die "Empfänger" alle Daten auch sehen können. Hätte ich ein Ethernet-Netzwerk könnte man dafür sicherlich z.B. das Mosquitto Protokoll verwenden, aber das ist in dem Fall wie Kanonen auf Spatzen. Kann eines der üblichen Hardwareprotokolle wie I2c, Uart oder SPi dazu bewegt werden, sich so zu verhalten, indem man auf bidirektionale Kommunikation verzichtet? Eventuell mit CAN (damit hab ich am wenigsten Erfahrung)? Schon mal viele Dank für Vorschläge!
Wenn das alles drahtgebunden stattfindet, kann man je nach Entfernung z.B. UART oder RS485 benutzen, aber es muss sichergestellt werden, das es keine Kollisionen gibt, bzw die Sender sich inaktiv (hochohmig) schalten, wenn sie fertig mit der Sendung sind. Zu Vermeidung von Kollisionen muss also der Sender vorher reinhören, ob sich gerade kein anderer Sender auf dem Bus befindet und er muss auch während der Übertragung prüfen, das kein anderer zufällig gerade gleichzeitig mit ihm angefangen hat - da würde nur Müll rauskommen. Es wäre evtl. sogar sinnvoll, wenn ein wenig Zufall mit reinspielt. Also das z.B. nicht alle Sender das gleiche Intervall nach einer Sendung eines anderen benutzen, um selber loszutröten.
Ein bussystem wäre schon sinnvoll. Can ist genau so konzipiert und gedacht. Spi und i2c könnte man auch hinbiegen, wenn es nen master geben soll.. Einfacher für dich und billiger wird aber mqtt auf fertigen controllern, da du sonst ja keine anforderungen nennst..
von was hängst du am ehersten ab? begrenzten Ressourcen am µC oder Kabel zur verbindung? Ethernet würde sich ja schon mal ganz gut an bieten für osi 1+2
Oh, noch was: CAN hat einen Grossteil der o.a. Anforderungen in Hardware gegossen, ist aber nicht unbedingt das einfachste Bussystem. Allerdings robust und mit vielen Features. Empfänger kannst du immer so viele haben, wie du willst, die Sender müssen sich abstimmen.
Alex G. schrieb: > indem man auf bidirektionale > Kommunikation verzichtet? Davon ist dringend abzuraten denn dann gibt es keine Bestätigungen, und folglich keine Kenntnis darüber ob überhaupt irgendetwas irgendwo angekommen ist. Georg
Hallo, das hängt auch stark von der Bedeutung der Daten für Dich oder die Funktion der Geschichte ab. Hier laufen seit einigen Jahren mehrere temperatur/Feuchtesensoren in den Zimmern. Übertragung mit RFM02 auf 433MHz. Die Sensoren senden alle 2 Minuten von einem freilaufenden Timer gesteuert. Damit gibt es merkliche Toleranzen der 2 Minuten, die hier aber von Vorteil sind: es stören sich nicht dauerhaft Sensoren weil sie zur gleichen Zeit senden. Ganz praktisch: die Daten als solche in diesem Abstand sind unwichtig für mich, es dürfen also Pakete ausfallen. Am Tag kommen von den rund 700 Sendungen ca. 1% nicht an, also 5-7 fehlen, maximal 2 hintereinander. Habe ich nur am Anfang kontrolliert. Prinzipeöö kann man das auch über UART oder SPI schicken wenn man nur Sensor TX und Empfänger RX benutzt. Mehrere RX an einem TX ist kein Problem, es ist eben auch Fire-and-Forget. Der Sensor sendet seine Dazen, ob die Ankommen ist ihm egal. Nachteil bei diesen Kabellösungen: man muß Leitungslängen und Treberleistungen beachten und ein ausgefallenes Gerät legt u.U. das ganze System lahm wenn er die Leitung "festhält". Aktuelle Sachen bei mir WLAN mit ESP8266 und MQTT, Mosquitto läuft auf einem RasPi. Meine Liste sagt, es sind im Moment 13 aktive ESP8266 in meinem WLAN, dazu noch ein Sensor und 3 PIR-Sensoren, die sich nur anmelden wenn sie was loswerden wollen. Es hängt meiner Meinung nach also hauptsächlich von der Anwendung ab, wie zuverlässig es real sein muß, wieviel Aufwand für Kabel und Hardware man reinstecken will oder muß. Meine Versionen decken meine EInzelanwendung komplett und sicher ab, das muß nicht bei Dir zutreffen. FrontEnd ist FHEM, läuft auch auf dem RasPi. Gruß aus Berlin Michael
Matthias S. schrieb: > ist aber nicht unbedingt das einfachste Bussystem Eigentlich schon. Ok, man sollte CAN-Hardware verwenden und nicht versuchen, dass in Software nachzubilden. Ansonsten ist das doch sehr einfach zu handhaben.
georg schrieb: > Davon ist dringend abzuraten denn dann gibt es keine Bestätigungen, und > folglich keine Kenntnis darüber ob überhaupt irgendetwas irgendwo > angekommen ist. Dann muss sich eben jeder Empfänger an seinen zehn Fingern abzählen, ob er alles mitbekommen hat. Dafür muss der Sender seine Pakete nur mit einer Paketnummer versehen. Ob es auf vollständigen Empfang der Messdaten überhaupt ankommt, weiß hier keiner. FEC hilft, damit der Empfänger keine falschen Daten versteht.
Vielen Dank für die Hilfreichen Antworten! Wolfgang schrieb: > Dann muss sich eben jeder Empfänger an seinen zehn Fingern abzählen, ob > er alles mitbekommen hat. Dafür muss der Sender seine Pakete nur mit > einer Paketnummer versehen. Ob es auf vollständigen Empfang der > Messdaten überhaupt ankommt, weiß hier keiner. > FEC hilft, damit der Empfänger keine falschen Daten versteht. Richtig, das ist auch der Plan. Base64 U. schrieb: > von was hängst du am ehersten ab? > > begrenzten Ressourcen am µC oder Kabel zur verbindung? Ethernet würde > sich ja schon mal ganz gut an bieten für osi 1+2 Eigentlich wollte ich eben das relativ starre und dicke Ethernet-Kabel vermeiden, weil manche der Sensoren sehr klein sind und die Abstände zu den auswertenden Einheiten, auch nur etwa 50-100cm.. Allerdings fällt mir grad wieder ein dass man über Ethernet ja auch Stromversorgung betreiben kann (der allerneuste Raspi unterstützt das mit einem Adapter), d.h. ich bräuchte sonst keine Leitungen. Außerdem dürfte ich bei den Abständen und geringen Datenraten wahrscheinlich auf Schirmung verzichten können. dunno.. schrieb: > Spi und i2c könnte man auch hinbiegen, wenn es nen master geben soll.. Es soll ja mehrere "Master" geben, wobei die nicht senden müssen. dunno.. schrieb: > Einfacher für dich und billiger wird aber mqtt auf fertigen controllern, > da du sonst ja keine anforderungen nennst.. Was für controler meinst du da genau? mqtt ist soweit ich das kenne, ja ein Softwareprotokoll das auf einer, anderweitig bereitgestellten, bidirektionalen Datenverbindung basiert. Matthias S. schrieb: > Oh, noch was: CAN hat einen Grossteil der o.a. Anforderungen in Hardware > gegossen, ist aber nicht unbedingt das einfachste Bussystem. Allerdings > robust und mit vielen Features. Empfänger kannst du immer so viele > haben, wie du willst, die Sender müssen sich abstimmen. Das klingt schon mal recht gut. Mit Abstimmen meinst du auch diese Kollisionserkennung? Hmm, schätze ich werde wohl beides evaluieren müssen. Fange aber mit dem vereinfachten Ethernet an.
:
Bearbeitet durch User
Vielleicht : - Multi-master i2c - LIN (bin nicht sicher davon aber bestudiere das mal)
CAN ist dafür ideal, weil die Hardware das Protokoll übernimmt, d.h. die Software wird besonders einfach. Es gibt ja auch viele MCs mit CAN intern.
> Eigentlich wollte ich eben das relativ starre und dicke > Ethernet-Kabel vermeiden Ich glaube du hast die Koaxialen Netzwerkkabel nicht kennen gelernt. Oder Token-Ring. Sonst wärst du für den heutigen Stand der Technik dankbarer. Die heute üblichen Netzwerkkabel sind genial praktisch und zuverlässig. Das muss man mal sagen. Ich habe in meiner Wohnung flache weiße Kabel unauffällig an die weißen Wände geklebt. Die passen auch ganz locker zwischen Türen und Rahmen durch (ohne Bohren). Früher (als ich noch schön war, in den 90er Jahren) hätten die Leute für solche Kabel ein Vermögen ausgegeben. Heute bekommt man sie für ca 1 € pro Meter. ich stimme allerdings den Vor-Postern zu, dass für deinen Fall CAN oder als billigere Alternative RS485 wahrscheinlich vorteilhafter ist. Dafür kannst du die selben Kabel verwenden.
Ich würde auch CAN nehmen. Man braucht keinen Master am Bus und man muss sich auch nicht um das Zeitregime (Kollisionen) kümmern, das macht der CAN-controller im MC selbst. Und über die ID-Filter kann man am Empfänger auch gut einstellen, welche Nachrichten man überhaupt sehen bzw. darauf reagieren will.
Eine andere Frage, speziell an einen Multi Master Bus waere die Buslast. - 10% ist trivial, da kann man sich Retries leisten - 50% ist eher nicht trivial, da muss man sich Muehe geben um Retries zu vermeiden - 90% ist aufwendig. Fuer bis zu 100% Buslast sollte man einen Bus verwenden, der dafuer zugeschnitten wurde. zB Arcnet. Der zieht 2.5MBit mit fast 100% Auslastung durch. Fuer weitere Ideen sollte man sich die Stoerart und -haeufigkeit ueberlegen, und allenfalls optimieren. A propos Koax, die gibt's auch mit 1mm Durchmesser.
:
Bearbeitet durch User
Zitronen F. schrieb: > Eine andere Frage, speziell an einen Multi Master Bus waere die Buslast. > - 10% ist trivial, da kann man sich Retries leisten > - 50% ist eher nicht trivial, da muss man sich Muehe geben um Retries zu > vermeiden > - 90% ist aufwendig. Beim CAN-Bus sind 100% kein Problem (Collision Avoidance).
Wenn es von mehreren Sendern NUR in eine Richtung geht, kann man sich per RS485 eine fest ans Timing gebundene Übertragung stricken. Als Grundgedanke mal das DMX-Protokoll: 512 Kanäle werden sequentiell übertragen. Allerdings bei DMX von einem Sender. Wobei es auch hier "Merger" gibt, die Daten einfügen. Und genau so kann es funktionieren. Aber: Das Signal muss durchgeschleift werden und kann nicht nur angeklemmt werden. Ich würde aber das "Weiterreichen" sowieso in Erwägung ziehen. Es vereinfacht die Sache, weil das Timing des Signals nicht von verschiedenen Sendern beeinflusst wird. Und das Signal wird immer wieder erneuert und somit am Ende der Kette nicht schlechter. Wenn ein Sender abgekoppelt werden soll, kann man dies tun. Man muss eben die Leitung überbrücken und darf diese nicht unterbrechen. Also wenn der Sender abgekoppelt wird, wird eben "Data In" mit "Data Out" gebrückt bzw. einfach die Leitungen zusammengesteckt. Der erste Teilnehmer in der Kette sendet das Signal wie bei DMX, beginnend mit einem BREAK zur Erkennung des Startwertes. Das Signal läuft in den nächsten Teilnehmer hinein. Dieser hat eine zugewiesene Adresse (einfachst per DIP-Switch). Er liest den gesamten Datenblock maximal möglicher Teilnehmer (bei DMX 512 Stück) ein, legt seine eignen Daten an die ihm mit der Adresse zugewiesenen Stelle rein und sendet das komplette Datenpaket weiter. Jeder Teilnehmer kann nun auch bei Bedarf alle Daten der anderen Teilnehmer sehen. Es ist einfach und man kommt mit einer UART aus. Da die Daten weitergereicht werden, müsste man nicht einmal zwingend RS485 nehmen, sondern könnte sogar bei kurzen Wegen direkt das Signal der UART (TTL) nehmen. Nur eben wie gesagt: Der "Bus" wird beim Entnehmen oder Abschalten eines Teilnehmers unterbrochen. Wenn es nur ums Abschalten geht, könnte man ein direktes Durchschleifen des Signals auch elektronisch bewerkstelligen, wenn ein Teilnehmer keinen Saft hat. Dazu muss dieser nur im Betrieb aktiv das Signal für sich unterbrechen und an UART-In bzw. Out legen. Kostet im Zweifelsfall ein paar Transistoren oder wenns ganz Low-Tech sein kann, auch nur 2 Relais-Wechselkontakte. Kein großes Ding. Ansonsten: CAN Gruß Jeder Sender muss nun das Timing verfolgen.
CAN Bus hat eine kleine Payload von vielleicht 6 bytes, waehrend Arcnet 512 oder 1k aufs Mal kann. Die Anbindung an einen Controller ist allerdings unterschiedlich
Zitronen F. schrieb: > CAN Bus hat eine kleine Payload von vielleicht 6 bytes Ist jetzt kein echtes Problem, man sendet einfach mehrere Pakete hintereinander. Es gibt diverse CAN-Bootloader, die so funktionieren. Die CAN-Controller haben oft auch große Puffer. Z.B. beim AT90CAN128 kann man von den 15 Message Objekten 8 als Empfangspuffer konfigurieren, d.h. man kann 8 Pakete a 8 Byte = 64 Byte hintereinander rausrotzen, ohne das der Empfänger in den Interrupt springen muß. Man hat also eine sehr geringe Interruptlast. Eine UART wäre da schon längst übergelaufen.
Alex G. schrieb: > Es soll ja mehrere "Master" geben, wobei die nicht senden müssen. Wie sollen die Master denn Master sein wenn sie deren Slaves nichts sagen dürfen?
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.