Hi hat jemand Erfahrung mit ESP-NOW? Ich sehe, daß meine Packete (nur ein Byte) mit Jitter empfangen werden. Im Bild sieht man die Ergebnisse für ESP8266: Lila: Byte sent on sender Green: byte received on receiver Delay: ~500 micro Sekunden Jitter: ~ 6.5 milli Sekunden Auf ESP8266 bekomme ich bessere Resultate als auf ESP32. Auf ESP32 ist Delay sowie Jitter grösser. Gehört das mit dem Jitter so oder habe ich einen Fehler in mein INO (siehe Anhang)? Warum verhält sich ESP8266 besser als ESP32? Danke
Angehängte Dateien:
-
IMG_20241203_175325.jpg
440 KB
Im guten Fall hast du unregelmäßige Verzögerungen im einstelligen ms Bereich. Das ist völlig normal. Ebenfalls normal sind Ausreißer bis 200ms. Damit muss man immer jederzeit rechnen. Erst darüber kommt der Bereich, wo es ernsthaft Sinn macht, etwas verbessern zu wollen.
Ich hab in deine INO nicht reingeschaut. Verteile bei dem ESP32 die Aufgaben auf beide Kerne.
> Warum verhält sich ESP8266 besser als ESP32?
Vielleicht, weil der ESP8266 kein Betriebssystem (RTOS) hat.
ESP-NOW geht doch über WLAN, oder? Da kann immer jemand dazwischen funken. Evtl. hat der ESP32 eine schlechtere Antenne.
:
Bearbeitet durch User
>>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.
Obelix X. schrieb: > Da kann immer jemand dazwischen funken. Mat. K. schrieb: > dann wurde ich erwarten dass mein Packet verloren geht oder falsch > ankommt WLAN vermeidet Kollisionen. Wenn der Funk-Kanal gerade belegt ist, müssen die anderen warten.
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?
:
Bearbeitet durch User
Obelix X. schrieb: > Und wenn die anderen nicht wissen das sie warten sollen? Dann hast du Pech. Bluetooth und WLAN kooperieren diesbezüglich.
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.
:
Bearbeitet durch User
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: > Das ist so nicht richtig. > Ich habe einen ESP32 der nach exakt 700µs auf Daten antworten muss. Meine Nachbarn werden nicht auf ihre Tragbaren Geräte verzichten, nur damit ich die gewünschten Antwortzeiten im WLAN erreiche. Wie machst du das, wohnst du alleine in einem freistehenden Haus?
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?
Mat. K. schrieb: > 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. Nochmal: Andere nutzen die gleichen Funkfrequenzen, das führt zu unregelmäßigen Wartezeiten. Sonst würde WLAN nicht funktionieren.
> 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: > Alles roger dann entnehme ich aus dem was du schreibst dass die Warterei > in den untersten 2 Schichten statfindet. Logisch, muss ja. Ansonsten hättest du ständig Kollisionen. Mat. K. schrieb: > Kennst du zufällig eine andere Übertragung die ein besseres > Jitter-Verhalten hätte? Die wird es auf freien Funkfrequenzen nicht geben, weil du die Frequenz nicht exklusiv nutzt. Für dein gewünschtes Timing ist Funk das falsche Medium.
:
Bearbeitet durch User
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.
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.