ESP-NOW timing accuracy auf ESP8266/ESP32

Ich hab in deine INO nicht reingeschaut. Verteile bei dem ESP32 die Aufgaben auf beide Kerne.

ESP-NOW geht doch über WLAN, oder? Da kann immer jemand dazwischen funken. Evtl. hat der ESP32 eine schlechtere Antenne.

ESP-NOW geht doch über WLAN, oder? dann wurde ich erwarten dass mein Packet verloren geht oder falsch ankommt. Es gibt doch keine repeat funktion bei ESP-NOW.

Sherlock 🕵🏽‍♂️ schrieb:

WLAN vermeidet Kollisionen. Wenn der Funk-Kanal gerade belegt ist, müssen die anderen warten.

Und wenn die anderen nicht wissen das sie warten sollen? Gibt ja noch mehr, was auf 2,4GHz funkt. Wenn ein anderer schon vorher angefangen hat zu funken, woher soll er wissen, dass er eine Pause machen muss, damit ESP-NOW Daten senden kann?

Obelix X. schrieb:

Wenn ein anderer schon vorher angefangen hat zu funken, woher soll er wissen, dass er eine Pause machen muss, damit ESP-NOW Daten senden kann?

Du hast die Verkehrsregelung nicht verstanden. Paket fertig senden und Klappe halten ist angesagt, damit die anderen auch eine Chance haben.

Rainer W. schrieb:

Du hast die Verkehrsregelung nicht verstanden. Paket fertig senden und Klappe halten ist angesagt, damit die anderen auch eine Chance haben.

Du hast meinen Kommentar nicht verstanden. (Ich hatte die Ironie Tags vergessen und dein Detektor hat nicht angeschlagen)

Genau und was haben wir dann? Jitter! Das war die Frage vom TO.

Für alle die meine Aussage missverstehen - wenn es auf Realtime ankommt würde ich nicht auf WLAN setzen.

Sherlock 🕵🏽‍♂️ schrieb:

Dann hast du Pech.

Ich nicht, ich habe ja kein Problem damit aber der TO.

Der TO schreibt leider nicht warum ihm der Jitter so wichtig ist.

Sherlock 🕵🏽‍♂️ schrieb:

Im guten Fall hast du unregelmäßige Verzögerungen im einstelligen ms Bereich. Das ist völlig normal.

Das ist so nicht richtig. Ich habe einen ESP32 der nach exakt 700µs auf Daten antworten muss. Diese kommen per UART rein uns müssen 700µs nach dem letzten Byte wieder raus (bzw die Antwort).

Geht. Nur nicht mit den einfachen Arduino Funktionen. Man muss sich schon gedanken machen was man will und wie man das erreicht. Und den ESP32 verstehen sollte man auch.

John P. schrieb:

Ich habe einen ESP32 der nach exakt 700µs auf Daten antworten muss.

Das geht mit WLAN nicht. Du kannst dort keine beliebig schnellen Antwortzeiten garantieren. Deshalb wurden (kabelgebundene) Feldbusse erfunden.

Sherlock 🕵🏽‍♂️ schrieb:

Wie machst du das, wohnst du alleine in einem freistehenden Haus?

Cyblord -. schrieb:

Das geht mit WLAN nicht. Du kannst dort keine beliebig schnellen Antwortzeiten garantieren. Deshalb wurden (kabelgebundene) Feldbusse erfunden

Mein Fehler. Ich bin noch nicht ganz wach :( Ich hatte gedacht innerhalb eines ESP32 wäre die Verzögerung/Jitter aufgetreten.

esp-now IST ABER KEIN ECHTES wlan: nur die untersten 2 OSI schichten. Soweit ich lese sollte es eigentlich keinen Jitter in ms Bereich haben. Deshalb die Frage ob war an meinen Arduino skteches falsch ist, oder ob ESP-NOW die performance unter Arduino nicht bereit stellt sondern eher in C?

Nochmal: Andere nutzen die gleichen Funkfrequenzen, das führt zu unregelmäßigen Wartezeiten. Sonst würde WLAN nicht funktionieren.

Alles roger dann entnehme ich aus dem was du schreibst dass die Warterei in den untersten 2 Schichten statfindet. Kennst du zufällig eine andere Übertragung die ein besseres Jitter-Verhalten hätte? Meine 2 Wahl war nordic priopriotory radio https://www.nordicsemi.com/Products/Wireless/2-4-GHz-proprietary Zufällig Erfahrungen damit?

Mat. K. schrieb:

Kennst du zufällig eine andere Übertragung die ein besseres Jitter-Verhalten hätte?

Wo für brauchst du das geringe Jitter? Oft werden hier irgendwelche Dinge gewünscht, und dann stellt sich heraus, das es eigentlich gar nicht notwendig ist.

Mat. K. schrieb:

Deshalb die Frage ob war an meinen Arduino skteches falsch ist

Nicht direkt falsch, aber unschön und mögliche Jitter-Ursache:

• Printf seriell in einer Callback-Funktion
• doppelter Aufruf von millis()

Mat. K. schrieb:

Gehört das mit dem Jitter so oder habe ich einen Fehler in mein INO (siehe Anhang)?

Die weitaus sinnvollere Frage wäre, ob Du bzw. Deine Anwendung mit einem Jitter dieser Größenordnung leben kann?

Was mir aber an Deinem Sender-Sketch auffällt: Du hast keine konstanten Sendeintervalle, wie bestimmst Du da den Jitter überhaupt?

Denn Du startest Deinen 300ms Timer ja erst nach dem Senden neu, also liegen zwischen zwei Übertragungen immer: 300ms + Dauer der vorigen Übertragung.

Was mir noch auffällt, eher allgemeiner: Die Arduino DigitalRead/Write Funktionen haben einen ziemlich schlechten Ruf, wenns um schnelles der sehr exaktes Timing geht. Drum nimmt man besser möglichst HW-nähere Zugriffsmethoden um einen Timing-Pin zu toggeln.

Hallo,

die benötigten Takte/Zeiten für

1

digitalWrite()

u.ä. Funktionen sind konstant und nur paar µs. Kann man als Konstante aus der Gesamtbetrachtung rauskürzen.

Die Mainloop hat auch kein festes Timing, weil im Hintergrund immer irgendwelche Interrupts beschäftigt sind. lastTime wird hier immer aufaddiert, hat kein festes Timing in dem Sinne wie es gedacht ist. Der Vergleich sollte

1

>=

sein und

1

lastTime += timerDelay

. Damit man ein halbwegs konstantes Intervall hat. Den Unterschied zwischen

1

lastTime = millis()

und

1

lastTime += timerDelay

sollte man sich einmal in Ruhe klarmachen. Hat beides Vor- und Nachteile, je nach Anwendungsfall. Für

1

lastTime = millis()

ist es auch entscheidend an welcher Position diese Zeile steht.

Ist aber für die Übertragung alles vollkommen egal. Was ist denn überhaupt das Problem? Oder ist das nur eine generelle Frage, weil man zufällig ein Oszi angeklemmt hat?

Wenn du das Originalzeug von Espressif nutzt (was ich annehme), hast du aufgrund des echtzeitbefreiten Kernels schon mal Null Latenzgarantien, auch wenn du den Wifi-Stack hackst (was aber gar nicht ETSI-konform waere). Mit FreeRTOS kann es besser sein, aber auch da muss man den original Radio-Stack umdesignen. Ein Produkt sollte daraus trotzdem nie werden, der 8266 hat einfach zuviele Boecke und einige dieser Brettle gehoeren eigentlich spaetestens nach dem EMV-Test in die Entsorgung. Mit dem ESP32 mag's besser sein, ich bin lieber auf Mediatek umgestiegen.