Denselben nicht, aber den Gleichen 
SCNR 
1 „Gefällt mir“
So jetzt bin ich auch soweit wie Du: In meiner FRITZBox 7590 habe ich umgestellt von WPA2/WPA3 auf
Mit nur WPA2 bekomme ich immer zuverlässige Verbindung & viel schnelleren Verbindungsaufbau.
Jetzt erreiche ich auch 400-500 KB/s Upload. Deutlich schneller als 1.0.6. Auch den teilweisen Einbruch der Upload-Geschwindigkeit auf 200 KB/s kann ich nachvollziehen.
Insgesamt läuft das jetzt sehr stabil. Die Ringbuffer Implementierung scheint für 2.0.6 weniger zu greifen da das Schreiben auf SD-Karte schneller geworden ist. Hast Du da noch Verbesserungen erzielen können z.B. mit Puffergröße?
Leider noch nicht. Meine Test-Hardware hat leider aufgegeben und ich muss erst einmal für Ersatz sorgen 
Ich hatte zum Testen mal den RingBuffer / das Schreiben auf die SD komplett rausgenommen um zu sehen, wie der reine WiFi Durchsatz ist. Da scheint es besser zu sein, aber auch dort schwankt es. Ich sehe in Wireshark sehr viele „Update TCP Window“ was die Schwankung erklären würde.
Mir ist allerdings noch unklar, wie man das ändern könnte.
Die aktuellen Einstellungen sind für die meisten Anwendungen vermutlich ja auch ziemlich gut. Nur wenn man halt sehr große Daten verarbeiten möchte, bricht die Datenrate ein.
Es gibt hier ja jede Menge Infos dazu: Wi-Fi Driver - ESP32 - — ESP-IDF Programming Guide latest documentation aber dadurch entstehen viele Abhängigkeiten, die ich noch nicht durchblicke…
Ich hatte zum Testen mal den RingBuffer / das Schreiben auf die SD komplett rausgenommen um zu sehen, wie der reine WiFi Durchsatz ist.
So ähnlich habe ich das auch gemacht: Zunächst ein separates Minimalprojekt mit ESPAsyncWebserver & SD_MMC Karte. Darin zwei Upload-Methoden, mit und ohne Ringpuffer/Task. Ich kann das Testprojekt hier gern mal zur Verfügung stellen…
Die Uploadrate so 400-500 KB/s, also Top!
Nach einigen Hardware/Software Resets dann plötzlich nur 200 KB/s. Nach einigen weiteren Resets wieder hohe Geschwindigkeit. Der Upload mit Task/Ringbuffer nur minimal schneller, teilweise auch gleiche Geschwindigkeit. Das erkläre ich mir mit der verbesserten SD-Schreibgeschwindigkeit. Da hat das gepufferte Schreiben nicht mehr so Auswirkungen.
Die Upload Dateigröße scheint keine Rolle zu spielen, ob 1MB oder 10MB.
Für den schwankenden Wifi-Durchsatz habe ich dann noch verschiedene Dinge probiert:
- Wifi.setStaticBuffers auf true/false → Verlangsamt den Upload. Ohne Aufruf ist es besser
- Wifi.setLightSpeed(false) → Keine Auswirkungen
Das bringt Alles keine Änderungen. Komisch das sich das ab und an nach einem Reset anders verhält. So als ob sich das Wifi beim Start unterschiedlich eingrooved…
@Christian die Wifi-Parameter ändern bedeutet Neukompilieren mit Arduino-Lib-Builder, hast Du das vor?
Der Task der TCP-Lib ist keinem Core zugeordnet. Das könnte eine Mögliche Ursache sein.
Vom Header der Lib:
//If core is not defined, then we are running in Arduino or PIO
#ifndef CONFIG_ASYNC_TCP_RUNNING_CORE
#define CONFIG_ASYNC_TCP_RUNNING_CORE -1 //any available core
#define CONFIG_ASYNC_TCP_USE_WDT 1 //if enabled, adds between 33us and 200us per event
#endif
Vom Code der Lib:
xTaskCreateUniversal(_async_service_task, "async_tcp", 8192 * 2, NULL, 3, &_async_service_task_handle, CONFIG_ASYNC_TCP_RUNNING_CORE);
Man könnte den Wert über den Präprozessor testweise auf einen Core festnageln. Und mit beiden Cores mal testen.
Vermutlich sollte dann aber auch CONFIG_ASYNC_TCP_USE_WDT gesetzt werden, sowie es passiert, wenn CONFIG_ASYNC_TCP_RUNNING_CORE nicht gesetzt wird.
2 „Gefällt mir“
Deshalb dachte ich an Speicherzuweisung. Das mit den unterschiedlichen Cores hatte ich auch schon probiert und in der plantform.ini zusätzlich -DCONFIG_ASYNC_TCP_RUNNING_CORE=1 gesetzt. Core 0 hatte ich nicht probiert und ich habe es auch nicht sauber genug getestet / abgegrenzt - würde ich dann noch einmal probieren, wenn die neue Hardware da ist. CONFIG_ASYNC_TCP_USE_WDT 1 hatte ich auch nicht auf dem Schirm.
Ja, das hatte ich schon gemacht, um bei er 2.0.6 auch wieder die beiden Funktionen vTaskGetRunTimeStats und vTaskList nutzen zu können. @tuniii hatte das hier mal gezeigt: RFID mit oder ohne Task - #19 von tuniii
Der Portexpander war wirklich auf beiden Platinen identisch (NXP PCA9555). Keine Ahnung warum der deepsleep einmal nicht funktioniert. Aber da scheint generell irgendein HW-Issue auf dem einen Board zu sein. Man schafft es immer wieder in einen Modus zu kommen, wo die SD Karte nicht erkannt wird.
Werde das am Donnerstag weiter untersuchen…
Hast du da ggf. ne Karte mit mehr als 32 GB drin?
Ich hatte vor ner Weile ein Board von einem User hier, der hatte mir eine 64 GB-Karte mitgeschickt. Und damit gab es tatsächlich solche Probleme, die es mit 32 GB nicht gab. Warum weiß ich nicht - vielleicht yet another ESP32-Bug. Es lag auch nicht an seinem Board - ich konnte das auch mit anderer Hardware nachstellen.
Ja, es ist ursprünglich eine 64 GB Karte gewesen, habe sie aber auf 32 GB formatiert.
Hatte davor eine 2GB Karte drin, die hat aber ebenfalls diese Probleme, nur traten sie dort häufiger auf 
. Auf der neuen Hardware scheint es aber bis jetzt nicht aufzutreten. Alles bisschen komisch da die Boards eigentlich identisch sind ^^.
Kann man des ESP komplett zurücksetzen? Werde wohl auch mal bisschen mit Kreuz-Tausch-Versuchen arbeiten…
Gibt es bestimmte SD-Karten-Empfehlungen ?
Ich verwende 32 GB Sandisk.
Komplett zurücksetzen geht mit „Erase Flash“.
Nachtrag: Sehe eben erst, dass ich ja im Arduino 2-Thread schreibe. Also meine Aussagen mit SD bezogen sich auf Arduino 1. Mit 2 habe ich das so ausgiebig nicht getestet im Vergleich.
Der user mit dem Problem mit der 64GB SD-Karte war ich. Und ich hatte zum Testen auch mal die Arduino Version 2 geflasht, mit dem gleichen Ergebnis. Bin dann aber auch wieder zurück zur v1, weil der Deepsleep nicht funktioniert hatte. (der Vollständigkeit: LPCD nutze ich nicht)
Das Problem mit der SD-Karte tritt bei mir aber eigentlich nur nach dem Flashen auf und ich kann den ESPuino nach ein paar Sekunden dann wieder per Tastendruck aus dem Deepsleep holen, insofern kann ich damit leben.
Ich teste hier mit dem aktuellen Release 2.0.6, einer 64GB formatierten SD-Karte mit SD_MMC und dem Board mit PE (lolin_d32_pro_sdmmc_pe):
- Die 64GB Karte schnurrt hier wie ein Kätzchen, Lese/Schreibzugriffe sind schneller als in 1.0.6
- Deep-Sleep auf dem Rotary-Button läuft einwandfrei, lange drücken = schlafen, kurz drücken = aufwachen
- LPCD kann ich hier nicht testen da mein Testboard etwas älter ist und keinen echten GPIO frei hat
@fetzerch Kannst Du einmal schauen ob die Probleme bei Dir noch bestehen? In 2.0.2/2.0.3 gab es zumindest einige Bugs bei SD Zugriff…
1 „Gefällt mir“
Das klingt gut, ja kann ich gerne in den nächsten Tagen mal machen. 
Also auch LPCD scheint zu funktionieren. Allerdings nur wenn der Tag direkt auf den Reader aufgelegt wird. Ohne Modifikation der Settings klappt es mit 10 mm Gehäuse nicht zuverlässig.
@Joe91 kannst Du Deine Erfahrungen/Probleme hier noch ein wenig weiter auftrennen/präzisieren?
Weil LPCD und Arduino 2 sind ja erstmal zwei paar Schuhe - Kann mir jetzt nicht wirklich vorstellen warum sich die Leseempfindlichkeit in 1.0.6 anders verhält als in 2.0.6.Am Ende wirft der PN5180 einen IRQ wenn sich eine Karte im Feld befindet. In 2.0.3/2.0.4 gab es wohl einen Bug mit dem Einfrieren der Pins, da wachte der ESPuino sofort wieder auf. Für 2.0.6 kann ich das testen wenn die neue Hardware da ist (Danke an Chef-Papa!)
10mm Holz? Ist die normale Kartenerkennung OK? Man könnte auch im Holz eine Aussparung auf wenige mm runterfräsen…
Welche Settings hast Du angepasst? Für den RC522 gibt es ja einen Wert für die Verstärkung (Gain), beim PN5180 regelt sich das ja automatisch ein. 5V anstelle von 3.3V am 5V-Pin macht Sinn und hast Du bestimmt schon gemacht.
Für LPCD gibt es viele Parameter, ich setze sie hier. Die sind schon ein bisschen 
magic . Meinst Du diese Einstellungen mit „Settings“?
Am Besten hier weiter mit Erfahrungen/Bugs für die noch experimentelle Arduino 2.x Version, sonst gern im LPCD Thread…
Grüße
Dirk
Vielleicht noch eine Randnotiz: Mein ESPuino wollte auf 2.x auch erst nicht in den Deepsleep. Ich hatte dann aus Verzweiflung mal alle Stromquellen abgesteckt und wieder dran… seither macht er das. Hört sich wirklich verrückt an - hat aber geholfen.
1 „Gefällt mir“
Vielen Dank für den Hinweis! Werde ich wohl auch so versuchen 
Aktuell teste ich noch auf der zweiten Hardware und sehe dort wirklich keine Einschränkungne bezüglich Arduino 2.
@tueddy : Ja, diese Eintellungen habe ich gesehen und damit auch schon gespielt (und mit anderen). Alles nicht ganz ideal, auch dass hierbei jedes mal im EEPROM geschrieben wird, für Testzwecke aber sehr hilfreich…
Es wurde zwischendurch mal gesagt, dass LPCD nicht unter Arduino 2 läuft. Das ist definitiv nicht der Fall. Sieht soweit wirklich gut aus. Dass man beim PN5180 endlos viele Einstellungen verändern kann ist natürlich nicht hilfreich . Deine Einstellungen passen aber ziemlich gut, wenn man einen sehr geringen Abstand und kein Metall in der Nähe hat.
Werde ich bald nochmal sehr viel tiefer mit dem PN5180 befassen und dann hoffentlich paar mehr Erkenntnisse bekommen. Bei der anderen Hardware liegen die Probleme vermutlich an den vorhandenen Befestigungsschrauben, die dann den LPCD triggern…
1 „Gefällt mir“
Also das läuft auf jeden Fall. Ich hab’s jetzt mit der neuen 4Layer-mini erfolgreich getestet. Dort klappt der Deepsleep mit und ohne LPCD und das sowas auf Arduino 1 und 2. Zumindest war das jetzt bei zwei Boards der Fall, die ich getestet habe.
Vermutlich ist es sinnvoll mittelfristig auf dem master auf 2.x umzusteigen, damit mehr Leute die Fehler dort finden und diese Version dann immer noch stabiler wird .
Zumindest jetzt wo der Stand dort wirklich solide wirkt…
Also einen Fehler habe ich im Betrieb gefunden: Und zwar gibt es irgendwie Probleme bei der Kopfhörererkennung. D.h. es läuft erstmal alles normal, aber vielleicht so alle 60 bis 120 s (unregelmäßig) blinkt mal kurz der LED-Ring auf und die Musik geht ganz kurz aus. Wenn ich dann ins Log schaue, dann steht dort, dass CMD 0 nicht erlaubt ist und gleichzeitig kommt es zu einem (manchmal auch mehreren) Event(s), die aussehen, als ob man den Kopfhörer eingesteckt hätte. Gehe ich auf Arduino 1 zurück, dann ist dieses Problem wieder weg.
Da muss ich vielleicht nochmal durch meinen Code schauen, ob ich da was falsch mache oder ob das ein ESP32-Arduino-Bug ist.