Welches Protokoll

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo zusammen,

    ich hab mir auf meiner Raspberry ein Programm in c++ geschrieben, das soweit schon läuft.

    jetzt benötige ich auf Kommando der Raspberry möglichst schnell (0,02sec ? ) Daten, die mir ein esp8266 mit angeschlossenen Bewegungssensoren schon in einem array (integer, 6 * 500) gespeichert hat.

    Zusätzlich soll mir der esp an die Raspberry bei bestimmten Bedingungen selbstständig Daten schicken.

    Das Ganze soll über WLAN laufen. Ein Router ist aber nicht immer erreichbar. Abstand Raspberry - ESP ist 2-3 Meter.

    Welches Protokoll würdet Ihr mir empfehlen, das die oben genannten Bedingungen einhalten kann? PHP, Mosquitto, json....

    Gruss,

    Achim

    Einmal editiert, zuletzt von hunter_spike (13. Oktober 2021 um 14:21)

  • Wenn du WLAN benutzt und sagst, dass ein Router nicht immer erreichbar ist, wie sollst du dann 20 ms erreichen? Also, ein funktionierendes WLAN musst du schon haben, sonst kann das ja nichts werden.

    Ein sauberes WLAN sollte eigentlich im Bereich von maximal 2-3 ms liegen. Aber selbst wenn ein WLAN da ist, kannst du dich nicht wirklich drauf verlassen.

    Technisch gesehen ist wohl das gängige Vorgehen, eine Socketverbindung aufzubauen.

    Ich würds einfach mal ausprobieren und die Antwortzeiten aufzeichnen.

    Bei 2-3 Metern kannst du sonst vielleicht auch auf ESP NOW zurückgreifen oder auf 868 MHz-Funkverbindungen oder Bluetooth. Entscheidend ist, in welchem Netzwerk du die geringsten Störungen hast. WLAN und ESP NOW stören sich ggf. mit anderen WLAN-Netzen. Bluetooth benutzt den gleichen Frequenzbereich und ist deshalb auch nicht viel besser. 868 MHz hat geringe Reichweiten und ist daher nicht so extrem störanfällig. Allerdings sind die Übertragungsraten eingeschränkt, so dass es mit 20 ms bei 3 KB Daten auch schon eng wird.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Also ich hab's geschafft mit meinem uC Werte via MQTT in 1ms Abständen zu übertragen. Ich habe MicroPython verwendet.

  • Wenn ich Sensor hoere denke ich auch immer zuerst an MQTT. Allerdings habe ich bislang noch nie Zeitconstraints gehabt. Ich koennte mir vorstellen dass C++ noch schneller ist als µP (obwohl wohl die meisste Zeit beim Netzxfer drauf geht) und somit sollte MQTT auch fuer die folgenden Anforderung

    Zusätzlich soll mir der esp an die Raspberry bei bestimmten Bedingungen selbstständig Daten schicken.

    sinnvoll sein.

  • Das kannst du bei einem PI vergessen.

    So schnell ist der nicht, das er sicher alle 0.02s die Daten entgegennehmen kann.

    Er soll nicht alle 0,02 Sec Daten entgegennehmen, sondern auf Anforderung soll die Antwort nach 0,02 Sec da sein.

    Abgeshen davon... warum sollte er das nicht können bei 1-2 ms Antwortzeiten?

    Die Frage ist eher,wie verlässlich die Antwortzeit sein muss und was passiert, wenn die Antwort doch mal länger dauert. Für die Schnellabschaltung eines Kernkraftwerks würde ich mich nicht auf 20 ms Antwortzeit über WLAN verlassen.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Er soll nicht alle 0,02 Sec Daten entgegennehmen, sondern auf Anforderung soll die Antwort nach 0,02 Sec da sein.

    OK, aber auch das wird schwer, der PI ist ein Computer, der nicht wirklich Echtzeitfähig ist. Die Reaktionszeit auf die Bereitstellung der Daten ist einfach zu kurz.

    Ja, in dem neuesten kernel sind die echtzeitfähigkeiten enthalten, doch der PI hat dafür einfach zu viel zu tun, als dass er in dieser kurzen Zeit reagieren kann.

    Für die Schnellabschaltung eines Kernkraftwerks würde ich mich nicht auf 20 ms Antwortzeit über WLAN verlassen.

    Das wäre bei einem AKW vollkommen egal, da dort die Schnellabschaltung eher in mehreren Minuten (eine Stunde, eineinhalb Stunden) als Sekunden gezählt wird. "Schnell" bedeutet in diesem Fall nur, das es sehr viel schneller geht als ein geordnetes Runterfahren, was bei einem AKW schon einmal mehrere Stunden oder länger dauern kann.

    (Stelle es dir wie bei einem Auto vor, das 250 km/h fährt, da ist mit "Schnellbremsung" auch nicht gemeint, dass es gegen die Wand fährt, sondern dass es mit qualmenden Reifen gesichert zum Stehen kommt. Wenn die Reifen anschließend kaputt sind, spielt es keine Rolle. Hauptsache der Wagen steht sicher.)

    Computer ..... grrrrrr

  • Unsinn. Der Pi hat eine maximale Latenz von gewöhnlich max 2 ms - mit einem Echtzeitpatch sogar unter 100 µs. Das Problem ist eher die Netzwerkverbindung als der Pi.

    Dann sieh dir mal die Dokumentationen zum Tschernobyl-Unfall an. Ein paar Sekunden hätten vielleicht genügt, um das zu verhindern. Da wäre "Das Netzwerk ist vorübergehend nicht erreichbar" wirklich sehr unpraktisch. Und wenn du mal die Notabschaltung einer Druckmaschine (mehrere Tonnen bewegter Walzen) erlebt hast, die verhindert, dass dem Arbeiter der Arm abgerissen wird, dann denkst du anders.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

    Einmal editiert, zuletzt von Gnom (13. Oktober 2021 um 21:28)

  • [OT]

    Gnom Auch wenn ich bei Dir bin mit der Aussage zum RPi, hinkt Dein Vergleich Druckmashine <> Turbine.

    Mehrere Tonnen vielleicht, den Unterschied macht die Umdrehung.

    In dem relativ kleinen Kraftwerk, in dem ich vor vielen Jahren als Turbinenschlosser arbeitete, hatten die Läufer ein Gewicht von 6t und der angeflanschte Anker des Generators ca. 2t und das bei 3k U/min. Das kannst Du nicht in ein paar Sekunden anhalten, dann schmieren Dir die Lager ab und der Läufer rollt / fliegt schneller und weiter als man weglaufen kann.

    [/OT]

    hunter_spike Sorry für den OT!

  • Das Problem ist eher die Netzwerkverbindung als der Pi.

    Ach, und dass zählt nicht mit zur Gesamtreaktinszeit?

    Was hilft es, wenn das System die Daten empfangen, aber nicht verarbeiten kann, da eine Schnittstelle zu langsam ist.

    Dann sieh dir mal die Dokumentationen zum Tschernobyl-Unfall an. Ein paar Sekunden hätten vielleicht genügt, um das zu verhindern.

    Nein,nicht wirklich, da das Herunterfahren viel zu lange dauert.

    Die Steuerstäbe bei einem AKW so einzufahren, dass sie nicht blockieren, sondern wirklich komplett eingefahren sind, die zusätzliche Wärme abzuführen, ohne dann zum Beispiel ein Rohr platzt und Radioaktivität austritt, gehört alles zur "Schnellabschaltung"


    Stell dir einfach ein normales Kraftwerk vor, wenn es einfacher ist.

    Plötzlicher Lastabfall.

    Die Energie muss weg, das geht recht schnell, der Dampf wird einfach abgeblasen, was eine sichtbare Dampfwolke verursacht, sowie ein höllisches Pfeifen.

    Doch dann muss die Turbine mit dem Generator so gebremst werden, dass nach Behebung des Störfalls dieser kein Schrott ist.

    Und die Feuerung muss auch unterbrochen werden.

    Bei Öl und Gas ist das noch 'einfach', bei Kohle richtig lustig.

    Wie gesagt:

    Wie das harte Bremsen eines schnell fahrendes Fahrzeugs, ohne dass zu viel kaputt geht. Kleinere Schäden, die leicht zu beheben sind, spielen keine Rolle, schwere Schäden schon.


    Echtzeit bedeutet eigentlich nur, dass die Reaktionszeit den definierten Zeitraum nicht überschreitet.

    Auch eine Reaktionszeit von 1 Stunde kann "Echtzeit" sein, wenn das System immer in dieser Zeit reagiert (und z.B. ein AKW abschalten muss)

    Aber einen Reaktionszeit von 20ms in einem Wireless Lan kannst du komplett vergessen, selbst beim wired LAN wird es spannend.

    Der gesamte Prozessablauf muss kürzer als die Reaktionszeit sein, sonst schaukelt sich das auf. Und nein, das schreiben von Daten alle 20ms ist damit nicht gemeint, sondern da reagieren auf neue Daten, die deterministisch kommen. Pollen ist da keine gute Idee, es muss schon eine Interruptbehandlung das ganze erledigen.

    Und es muss eben jeder Prozessschritt bei der Verarbeitung immer eine garantierte maximale Zeit haben, von denen alle zusammen kürzer als die Reaktionszeit sein müssen.

    Ein Pico könnte das vielleicht, aber das ist ja auch kein "Computer", sondern ein Mikroprozessor, der nur eine Sache macht. (Wobei bei diesem das Schreiben spannend werden würde)

    Computer ..... grrrrrr

  • Um mal zu Thema zurück zu kommen:

    Die Raspi macht mir in der Zeit, wo keine Daten kommen, eine Bildverarbeitung in HDMI-Auflösung und noch ein paar Winkelberechnungen. Wenn Daten kommen, braucht sie das nicht machen. Von der Rechenleistung sollte also genug vorhanden sein.

    Ich könnte z.B. auf der Raspi einen Accesspoint laufen lassen. Schon ist wlan da.

    Mich würde interessieren was die schnellste Möglichkeit ist die 6000 Byte zu übertragen.

  • Die Übertragungsraten im WLAN sind gewöhnlich so hoch, dass die geringe Datenmenge hier keine große Rolle spielt. Entscheidend ist im Zweifel der Protokolloverhead. Aber generell hast du - sofern dein WLAN stabil läuft - kein Problem, die 20 ms zu halten. Die Antworteit liegt im Normalfall unter 2 ms. Bei MQTT kann ich nicht sagen, welchen Overhead das Protokoll und der Broker produzieren. Eine Socket-Verbindung dürfte aber hier ohne größere Verluste laufen.

    Aber bevor du hier eine Abschließende Antwort erwartest, die du nicht bekommen wirst, probier es doch einfach aus. In der Zeit, die du hier mit Fragen verplemperst, könntest du schon Gewissheit aus eigenen Tests haben.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Mich würde interessieren was die schnellste Möglichkeit ist die 6000 Byte zu übertragen.

    Via UDP.

    Grund: Verbindungslos, wenig Overhead

    Nachteil: Du musst alles selbst implementieren und es ist nicht garantiert, dass die Pakete auch empfangen werden.

    MQTT kann das aber auch.

    Wenn du sowas wie MQTT ohne broker haben möchtest, dann halt zmq.

    ZMQ hat auch minimalen Overhead und Server/Client sind in der Bibliothek implementiert.

  • Danke für Deine Einschätzung. Da hab ich erstmal was zum googlen.

  • UDP mag einen Ticken schneller sein - aber im Fall von Sensordaten... hm. Wäre sicher nicht besonders nützlich, wenn falsche Pakete ankommen. Bevor du einen Programmteil schreibst, der prüft, ob die übertragenen Daten überhaupt korrekt sind, nimm lieber gleich TCP. Wenn dein Netzwerk mal länger als 20 ms braucht, wird dir UDP auch nicht helfen. Außerdem dürfte der Zeitunterschied zwischen den beiden bei 6000 Bytes kaum nennenswert sein.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!