Stack mit LED-Strip + WIFI hängt sich bei zu vielen Daten auf

[remotecontrol]

Hallo zusammen,

 

ich bin heute auf einen Effekt gestossen, den ich für einen Firmware-Bug halte - mindestens für einen unschönen Effekt:

 

Stack mit Step-Down, Master (FW 2.3.0), WIFI Ext., LED-Strip-Bricklet und 50 LED-Pixel WS2801, Framerate 60ms (~15 Hz), C++ Anwendung läuft auf PC.

 

Da das WIFI leichten Schankungen unterliegt kann es passieren, dass auch mal 400ms keine Daten übertragen werden.

Wenn das aber passiert, dann stauen sich die Callbacks auf. Als Folge kommen danach in 1ms z.B. 7 Callbacks in der Anwendung an, was in meiner ersten Implementierung dann direkt 7x die kompletten Framedaten gesendet hat (eben 1x pro Callback).

 

Als Folge hat sich der Stack vereinzelt verabschiedet - nur Reset hat geholfen.

 

Dann habe ich das umgestellt auf Semaphores und der Callback sollte nur dann das Senden über einen 2. Thread triggern, wenn nicht eh noch ein Sendevorgang aktiv war. Beim Umsetzen hatte ich kurzzeitig einen Bug im Code und habe quasi dauerhaft Daten gesendet, als Folge hat sich der Stack wieder verabschiedet - nur Reset half.

 

Jetzt ist das bereinigt und ich lege nach dem Senden noch eine zusätzliche Pause von 4ms ein, d.h. auch wenn in 1ms 7 Callbacks kommen, wir nur ein Frame übertragen - dann läuft alles stabil.

 

Es scheint, als würde sich der Stack aufhängen, wenn zu schnell Daten per WIFI gesendet werden. Das ist unschön.

 

Gerade der in der Doku beschriebene Ansatz funktioniert mit WIFI nämlich nicht mehr stabil, da es zu einer konzentierten Anzahl Callbacks kommen kann und eine zu hohe Datenrate den Stack zum Aufhängen bringt - so meine Beobachtung.

 

Viele Grüße

[Quantasy]

Bei folgendem Szenario hängt sich der TF-Stack garantiert auf und kann ausschliesslich durch einen 'Kaltstart' wieder (für den nächsten Aufhänger) gestartet werden:

 

 

Hier der Stack:

Master 2.0 -> LED-Bricklet (2801 40LEDs) (12V-5A)

Master 2.1 -> LED-Bricklet (2812 160LEDs) (5V-8A)

WiFi Ext 1.0 mit Fritzbox über (b+g+n) WPA2 verbunden

Master 2.0 -> LED-Bricklet (2812 192RGB-LEDs) (5V-10A)

StepDown von gespiesen mit (12V 5A)

 

 

Via LAN ist ein PC angehängt (irgend ein Debian System)

BrickViewer (2.3.6)

BrickDaemon (2.2.2)

 

 

Nun alle LEDs per BrickViewer anschalten (showColor)

Vielleicht noch ein wenig am RGB-Channel was ändern... und #@PENG@#

 

Das GUI des BrickViewers reagiert nicht mehr....

Das geht meist nur ein paar Sekunden, manchmal aber auch bis zu einer Stunde (Scheint mir eine Race-Condition o.ä. zu sein).

Irgendwann versucht BrickViewer wieder zu reconnecten...

Aber die Fritzbox meldet klar, dass der Tinkerforge-Stack nicht mehr angehängt sei. Ping ist auch schluss.

 

Mach ich was grundsätzlich falsch? Ist das die Grenze von TF via WLAN?

Via USB läuft die Sache nämlich (obwohl ich das aber nicht über längere Zeit (Tage) getestet).

 

Ich habe mehrere WiFi Extensions v.1 getestet... Immer das selbe Resultat.

Auch mit einem 2.1 Master scheint es sich gleich zu verhalten, kann aber, wenn da noch Hoffnung besteht gerne nochmals nachgucken.

 

Kann da irgendwer weiterhelfen? Ich weiss, es gibt da verschiedenste Threads, die dazu (oder irgendwie verwandt) am Laufen sind, aber dieser Thread schien mir so ziemlich genau den Nagel auf den Kopf zu treffen... auch wenn er schon älter ist.

 

Ich habe auch einen Debug und ein Log gemacht. Aber... schaut selber, hab nix geändert daran.

 

 

logger_debug_1477592997.log

logger_data_1477592997.csv

[Quantasy]

Positives Feedback:

Durch das Ersetzen der WiFi-Ext1.0 mit WiFi-Ext2.0 Firmware (2.0.3) funktioniert diese Konstellation nun robust.

 

Beschrieben im Reply 81 von

http://www.tinkerunity.org/forum/index.php/topic,3809.msg23395.html#msg23395