Jump to content

Retransmission TCP Packets nach LED Bricklet "aktivierung"

Loetkolben
 Share

Recommended Posts

Loetkolben Newbie

Loetkolben

Geschrieben
Geschrieben

Hallo zusammen,

 

ich habe da ein Problem. Um es vorweg zu nehmen, es liegt weder an den dem neuen brickd, noch brickv.

 

* brickd-arm 2.1.0 oder brickd-arm 2.1.1_beta ist egal

* brickv 2.1.1 oder brickv 2.1.x_WS2812 ist egal.

Stack besteht aus Master 1.0 und Master 2.0 und die haben die aktuelle FW 2.2.2

 

Zum Problem: Ich kann ab einem bestimmten Vorgang mit dem LED Bricklet keine Temperaturwerte mehr abfragen!  >:(

 

Normalerweise frage ich einfach mein Temperaturbricklet ab, wie seit Ewigkeiten:

[...]
RECEIVEPACKET=`echo -n -e "$SENDPACKET" | nc -w1 $HOST $PORT | xxd -p`
[...]

Ausgabe: Die Temperatur betraegt: 25.93 Grad.

Folgender TCPDUMP wird dadurch erzeugt:
[start]
21:47:20.034193 IP 192.168.23.81.33714 > Cubian.local.4223: Flags [s], seq 192156249, win 5840, options [mss 1211,sackOK,TS val 1775089049 ecr 0,nop,wscale 7], length 0
21:47:20.034302 IP Cubian.local.4223 > 192.168.23.81.33714: Flags [s.], seq 1364241887, ack 192156250, win 14480, options [mss 1460,sackOK,TS val 545568803 ecr 1775089049,nop,wscale 7], length 0
21:47:20.063362 IP 192.168.23.81.33714 > Cubian.local.4223: Flags [.], ack 1, win 46, options [nop,nop,TS val 1775089056 ecr 545568803], length 0
21:47:20.064039 IP 192.168.23.81.33714 > Cubian.local.4223: Flags [P.], seq 1:9, ack 1, win 46, options [nop,nop,TS val 1775089056 ecr 545568803], length 8
21:47:20.064132 IP Cubian.local.4223 > 192.168.23.81.33714: Flags [.], ack 9, win 114, options [nop,nop,TS val 545568806 ecr 1775089056], length 0
21:47:20.065247 IP Cubian.local.4223 > 192.168.23.81.33714: Flags [P.], seq 1:11, ack 9, win 114, options [nop,nop,TS val 545568806 ecr 1775089056], length 10
21:47:20.093000 IP 192.168.23.81.33714 > Cubian.local.4223: Flags [.], ack 11, win 46, options [nop,nop,TS val 1775089064 ecr 545568806], length 0
21:47:22.096718 IP 192.168.23.81.33714 > Cubian.local.4223: Flags [F.], seq 9, ack 11, win 46, options [nop,nop,TS val 1775089564 ecr 545568806], length 0
21:47:22.097078 IP Cubian.local.4223 > 192.168.23.81.33714: Flags [F.], seq 11, ack 10, win 114, options [nop,nop,TS val 545569009 ecr 1775089564], length 0
21:47:22.122688 IP 192.168.23.81.33714 > Cubian.local.4223: Flags [.], ack 12, win 46, options [nop,nop,TS val 1775089571 ecr 545569009], length 0
[Ende]

 

 

Nun folgendes:

* Ich oeffne den brickv und frage wieder die Temperatur ab. Scripttemperaturabfrage ok

* Verbinde mit Stack. Scripttemperaturabfrage ok

* Klicke auf den Reiter des Temperaturbricklets.  Scripttemperaturabfrage ok

* Klicke auf den LED Bricklet Reiter. Scripttemperaturabfrage ok

* Dropdownauswahl auf WS2812. Scripttemperaturabfrage ok

* Klicke auf "Moving Color" -> Error. Scripttemperaturabfrage haengt!

 

Mein Script kommt nicht wieder. Es haengt am "nc -w1".

TCPDUMP laeuft endlos durch!

 

21:52:08.761175 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 121:131, ack 9, win 114, options [nop,nop,TS val 545597675 ecr 1775161226], length 10
21:52:08.787616 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 131, win 46, options [nop,nop,TS val 1775161237 ecr 545597675], length 0
21:52:08.861229 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 131:141, ack 9, win 114, options [nop,nop,TS val 545597685 ecr 1775161237], length 10
21:52:08.894800 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 141, win 46, options [nop,nop,TS val 1775161264 ecr 545597685], length 0
21:52:08.961349 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 141:151, ack 9, win 114, options [nop,nop,TS val 545597695 ecr 1775161264], length 10
21:52:08.999648 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 151, win 46, options [nop,nop,TS val 1775161290 ecr 545597695], length 0
21:52:09.061185 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 151:161, ack 9, win 114, options [nop,nop,TS val 545597705 ecr 1775161290], length 10
21:52:09.091397 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 161, win 46, options [nop,nop,TS val 1775161313 ecr 545597705], length 0
21:52:09.161271 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 161:171, ack 9, win 114, options [nop,nop,TS val 545597715 ecr 1775161313], length 10
21:52:09.190028 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 171, win 46, options [nop,nop,TS val 1775161338 ecr 545597715], length 0
21:52:09.261238 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 171:181, ack 9, win 114, options [nop,nop,TS val 545597725 ecr 1775161338], length 10
21:52:09.291390 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 181, win 46, options [nop,nop,TS val 1775161364 ecr 545597725], length 0
21:52:09.361213 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 181:191, ack 9, win 114, options [nop,nop,TS val 545597735 ecr 1775161364], length 10
21:52:09.391422 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 191, win 46, options [nop,nop,TS val 1775161388 ecr 545597735], length 0
21:52:09.461254 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 191:201, ack 9, win 114, options [nop,nop,TS val 545597745 ecr 1775161388], length 10
21:52:09.491922 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 201, win 46, options [nop,nop,TS val 1775161414 ecr 545597745], length 0
21:52:09.561213 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 201:211, ack 9, win 114, options [nop,nop,TS val 545597755 ecr 1775161414], length 10
21:52:09.649663 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 211, win 46, options [nop,nop,TS val 1775161453 ecr 545597755], length 0
21:52:09.661230 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 211:221, ack 9, win 114, options [nop,nop,TS val 545597765 ecr 1775161453], length 10
21:52:09.742484 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 221, win 46, options [nop,nop,TS val 1775161476 ecr 545597765], length 0
21:52:09.761209 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 221:231, ack 9, win 114, options [nop,nop,TS val 545597775 ecr 1775161476], length 10
21:52:09.799001 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 231, win 46, options [nop,nop,TS val 1775161489 ecr 545597775], length 0
21:52:09.861221 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 231:241, ack 9, win 114, options [nop,nop,TS val 545597785 ecr 1775161489], length 10
21:52:09.892476 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 241, win 46, options [nop,nop,TS val 1775161514 ecr 545597785], length 0
21:52:09.961214 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 241:251, ack 9, win 114, options [nop,nop,TS val 545597795 ecr 1775161514], length 10
21:52:09.992191 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 251, win 46, options [nop,nop,TS val 1775161539 ecr 545597795], length 0
21:52:10.061194 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 251:261, ack 9, win 114, options [nop,nop,TS val 545597805 ecr 1775161539], length 10
21:52:10.091223 IP 192.168.23.81.33794 > Cubian.local.4223: Flags [.], ack 261, win 46, options [nop,nop,TS val 1775161563 ecr 545597805], length 0
21:52:10.161466 IP Cubian.local.4223 > 192.168.23.81.33794: Flags [P.], seq 261:271, ack 9, win 114, options [nop,nop,TS val 545597815 ecr 1775161563], length 10

 

Wie kann ich es stoppen?

 

Ein CTRL-C in meinen Script ergibt einen Rueckgabewert und beendet erstmal mein Script.

 

Nun klicke ich im Brickviewer auf einen anderen Reiter oder beende den Brickviewer. Sobald ich mein Script starte laeuft der TCP Verkehr wieder endlos.  :(

 

Ich beende den brickd und starte brickd neu. Sobald ich mein Script starte laeuft der TCP Verkehr wieder endlos.  :(

 

NUR der Reset des Masterbrick beendet dieses Verhalten. Nun kann ich mit meinem Script wieder die Temperatur abfragen, solange bis ich mit dem LED Bricklet wieder "spiele".

 

Habt ihr eine Idee dazu?

 

Meine Gedanken dazu: Beim "spielen" mit dem LED Bricklet werden irgendwelche kommunikationsrelevanten Bereiche auf dem Master ueberschrieben. Dies fuehrt dazu, dass die Kommunikation von anderen Bricklets beeintraechtigt ist.

 

 

Edit: Zusatz"problem": Ich habe Probleme beim Ersten setzen der Farben mit meinem Script, wenn vorher die gleichen Farben drin waren. Kompliziert, aber ich kann es (noch) nicht richtig in Worte fassen.

Wenn vor dem Reset Farbwerte gesetzt waren muss ich nach dem Reset fuer alle NEUE Farbwerte setzen um ueberhaupt fuer einzelne LED Farbwerte zu setzen. Hoert sich komisch an, aber ich kann es nicht so recht fassen. Damit will ich nur andeuten, dass sich bei obigen Problem es sich wirklich um Speicherzuordnungsprobleme handeln koennte. Ansonsten vergesst einfach diese Zeilen.

Siehe einen Beitrag weiter unten am Ende.

 

 

Der Loetkolben

 

 

 

 

 

Link zu diesem Kommentar
Share on other sites
Loetkolben Newbie

Loetkolben

Geschrieben
  • Autor
Geschrieben

Hallo zusammen.

 

Ich fass das mal weiter zusammen. Das Bild wird klarer.

 

 

Sobald man LEDs setzt, bleiben einige Verbindungen dauerhaft offen. Vorher werden die Get-Scripte nach ca. 1 Sekunde beendet und liefern einen Wert.

 

Hier der "Code" der das Problem ausloest. Kann, wie im ersten Post beschrieben, auch per Brickviewer ausgeloest werden.

Setze WS2812
DEBUG:SENDPACKET:\x9d\xe8\x00\x00\x0a\x09\x10\x00\xfc\x0a

LED Start:00, Laenge:05, Color:22,33,44 (Alle LED immer gleiche Farben)
DEBUG:SENDPACKET:\x9d\xe8\x00\x00 \x3b\x01\x10\x00 \x00\x00\x05 \x22\x22\x22\x22\x22\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x33\x33\x33\x33\x33\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x44\x44\x44\x44\x44\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00

 

 

In der Prozessliste bleiben die "nc -w1" haengen.

13976  3109  0 01:40 ?        00:00:00 /bin/bash /opt/Tinkerforge/collect.20.144/p.ambientlight-get.02.00.sh -x -h 192.168.20.142 -u 7ud -r
14012 13976  0 01:40 ?        00:00:00 /bin/bash /opt/Tinkerforge/collect.20.144/p.ambientlight-get.02.00.sh -x -h 192.168.20.142 -u 7ud -r
14019 14012  0 01:40 ?        00:00:04 nc -w1 192.168.20.142 4223
14110 21761  0 01:40 ?        00:00:00 /bin/bash /opt/Tinkerforge/collect.20.144/p.ambientlight-get.02.00.sh -x -h 192.168.20.142 -u 7ud -r
14159 14110  0 01:40 ?        00:00:00 /bin/bash /opt/Tinkerforge/collect.20.144/p.ambientlight-get.02.00.sh -x -h 192.168.20.142 -u 7ud -r
14161 14159  0 01:40 ?        00:00:04 nc -w1 192.168.20.142 4223
17621 17583  0 02:00 ?        00:00:00 /bin/bash /opt/Tinkerforge/collect.20.144/p.humidity-get.02.00.sh -x -h 192.168.20.142 -u 7Tf -r
17642 17621  0 02:00 ?        00:00:00 /bin/bash /opt/Tinkerforge/collect.20.144/p.humidity-get.02.00.sh -x -h 192.168.20.142 -u 7Tf -r
17644 17642  0 02:00 ?        00:00:02 nc -w1 192.168.20.142 4223
32632 32588  0 03:00 ?        00:00:00 /bin/bash /opt/Tinkerforge/collect.20.144/p.humidity-get.02.00.sh -x -h 192.168.20.142 -u 7Tf -r
32653 32632  0 03:00 ?        00:00:00 /bin/bash /opt/Tinkerforge/collect.20.144/p.humidity-get.02.00.sh -x -h 192.168.20.142 -u 7Tf -r
32655 32653  0 03:00 ?        00:00:00 nc -w1 192.168.20.142 4223

 

Der TCPDUMP laeuft wie verrueckt durch:

03:16:42.826722 IP Cubian.local.4223 > 192.168.23.81.44353: Flags [P.], seq 578751:578761, ack 9, win 114, options [nop,nop,TS val 547545082 ecr 1780029732], length 10
03:16:42.826785 IP Cubian.local.4223 > 192.168.23.81.44357: Flags [P.], seq 578461:578471, ack 9, win 114, options [nop,nop,TS val 547545082 ecr 1780029732], length 10
03:16:42.826820 IP Cubian.local.4223 > 192.168.23.81.44363: Flags [P.], seq 577981:577991, ack 9, win 114, options [nop,nop,TS val 547545082 ecr 1780029732], length 10
03:16:42.826851 IP Cubian.local.4223 > 192.168.23.81.45759: Flags [P.], seq 459641:459651, ack 9, win 114, options [nop,nop,TS val 547545082 ecr 1780029732], length 10
03:16:42.826883 IP Cubian.local.4223 > 192.168.23.81.50027: Flags [P.], seq 99171:99181, ack 9, win 114, options [nop,nop,TS val 547545082 ecr 1780029732], length 10
03:16:42.853738 IP 192.168.23.81.44353 > Cubian.local.4223: Flags [.], ack 578761, win 46, options [nop,nop,TS val 1780029754 ecr 547545082], length 0
03:16:42.858050 IP 192.168.23.81.44357 > Cubian.local.4223: Flags [.], ack 578471, win 46, options [nop,nop,TS val 1780029755 ecr 547545082], length 0
03:16:42.858679 IP 192.168.23.81.44363 > Cubian.local.4223: Flags [.], ack 577991, win 46, options [nop,nop,TS val 1780029755 ecr 547545082], length 0
03:16:42.859320 IP 192.168.23.81.45759 > Cubian.local.4223: Flags [.], ack 459651, win 46, options [nop,nop,TS val 1780029755 ecr 547545082], length 0
03:16:42.859918 IP 192.168.23.81.50027 > Cubian.local.4223: Flags [.], ack 99181, win 46, options [nop,nop,TS val 1780029755 ecr 547545082], length 0
03:16:42.926722 IP Cubian.local.4223 > 192.168.23.81.44353: Flags [P.], seq 578761:578771, ack 9, win 114, options [nop,nop,TS val 547545092 ecr 1780029754], length 10
03:16:42.926786 IP Cubian.local.4223 > 192.168.23.81.44357: Flags [P.], seq 578471:578481, ack 9, win 114, options [nop,nop,TS val 547545092 ecr 1780029755], length 10
03:16:42.926826 IP Cubian.local.4223 > 192.168.23.81.44363: Flags [P.], seq 577991:578001, ack 9, win 114, options [nop,nop,TS val 547545092 ecr 1780029755], length 10
03:16:42.926859 IP Cubian.local.4223 > 192.168.23.81.45759: Flags [P.], seq 459651:459661, ack 9, win 114, options [nop,nop,TS val 547545092 ecr 1780029755], length 10
03:16:42.926893 IP Cubian.local.4223 > 192.168.23.81.50027: Flags [P.], seq 99181:99191, ack 9, win 114, options [nop,nop,TS val 547545092 ecr 1780029755], length 10
03:16:42.956350 IP 192.168.23.81.44353 > Cubian.local.4223: Flags [.], ack 578771, win 46, options [nop,nop,TS val 1780029780 ecr 547545092], length 0
03:16:42.960392 IP 192.168.23.81.44357 > Cubian.local.4223: Flags [.], ack 578481, win 46, options [nop,nop,TS val 1780029781 ecr 547545092], length 0
03:16:42.961060 IP 192.168.23.81.44363 > Cubian.local.4223: Flags [.], ack 578001, win 46, options [nop,nop,TS val 1780029781 ecr 547545092], length 0
03:16:42.961729 IP 192.168.23.81.45759 > Cubian.local.4223: Flags [.], ack 459661, win 46, options [nop,nop,TS val 1780029781 ecr 547545092], length 0
03:16:42.962333 IP 192.168.23.81.50027 > Cubian.local.4223: Flags [.], ack 99191, win 46, options [nop,nop,TS val 1780029781 ecr 547545092], length 0
03:16:43.026741 IP Cubian.local.4223 > 192.168.23.81.44353: Flags [P.], seq 578771:578781, ack 9, win 114, options [nop,nop,TS val 547545102 ecr 1780029780], length 10
03:16:43.026812 IP Cubian.local.4223 > 192.168.23.81.44357: Flags [P.], seq 578481:578491, ack 9, win 114, options [nop,nop,TS val 547545102 ecr 1780029781], length 10
03:16:43.026850 IP Cubian.local.4223 > 192.168.23.81.44363: Flags [P.], seq 578001:578011, ack 9, win 114, options [nop,nop,TS val 547545102 ecr 1780029781], length 10
03:16:43.026887 IP Cubian.local.4223 > 192.168.23.81.45759: Flags [P.], seq 459661:459671, ack 9, win 114, options [nop,nop,TS val 547545102 ecr 1780029781], length 10
03:16:43.026918 IP Cubian.local.4223 > 192.168.23.81.50027: Flags [P.], seq 99191:99201, ack 9, win 114, options [nop,nop,TS val 547545102 ecr 1780029781], length 10

 

Was passiert im Masterbrick, wenn einmal die LEDs gesetzt wurden? Warum wird die Verbindung nicht mehr geschlossen und das Ergebnis zurueckgeliefert?

 

Mache ich nun einen Reset am Master werden die "nc -w1" beendet und liefern ein RIESENGROSSES Paket zurueck.

 

[Pufferanfang nicht zu sehen]
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
05009de800000a06080005009de800000a06080005009de800000a060800
0500202934d422fd00003671415456330000000000000000000000000000
0000000000026257000022fd000037444700000000000000000000000000
000000000000000000023c55000022fd0000377564000000000000000000
0000000000000000000000000002745a000022fd00003754660000000000
00000000000000000000000000000000000256ae000022fd000065677500
000000000000000000000000000000000000000000023230f3e422fd0000
3652715257410000000000000000000000000000000000000002ebe60000
22fd0000697a650000000000000000000000000000000000000000000002
9de8000022fd000069474800000000000000000000000000000000000000
00000002

 

Eine alte Masterbrick-FW habe ich noch nicht probiert. Das Problem muss aber aus meiner Sicht auch mit den Bindings auftreten.

 

Zu dem Farbenproblem beim ersten setzten:

Habe mal einen (ganz) anderen Stack genommen. USB-Port Power on. Alle 4 LED waren aus.

 

Alle 4 LED auf 11,11,11 gesetzt, aber die 4. LED hat einen starken Gelbstich.

Habe dann NOCHMALS alle 4 LED auf 11,11,11 gesetzt. Keine Aenderung. Die 4. LED blieb bei ihrem Gelbstich. (Sieht so aus: If neuer-set-wert = vorheriger-set-wert do nothing).

 

Dann habe ich alle 4 LED mit 22,22,22 beschrieben. Prima. Alle 4 LED waren heller in weiss.

 

Dann habe ich wieder alle 4 LED auf 11,11,11 gesetzt. Prima. Alle 4 LED sind weiss, aber ein wenig dunkler.

 

Jetzt kann ich alle LEDs so setzen wie ich moechte.

 

Warum immer die Probleme beim ersten mal? Es ist reproduzierbar!  ;)

 

Der Loetkolben

Link zu diesem Kommentar
Share on other sites
borg Community Regular

borg

Geschrieben
Geschrieben

Die ganzen Daten die du da siehst sind die FrameRendered Callbacks. Die kommen je nach eingestellter Frame Duration bis zu 100 mal pro Sekunde.

 

Das erste setzen einer Farbe kann problematisch sein wenn die Pixel schon irgendwas in ihren Shift Registern stehen haben. Da könnten wir vielleicht versuchen im Konstruktur des Bricklets schonmal ein irgendwas zu setzen um dieses "Problem" zu umgehen, wenn du ein Pixel anschließt nachdem der Master gestartet wurde bringt das aber natürlich nichts, da können wir dann auch nichts gegen machen (außer die Daten durchgängig senden, auch wenn sie nicht geändert werden).

 

 

 

Funktioniert die Temperaturabfrage denn auch mit unseren Bindings oder dem Brick Viewer nicht oder ist das ein netcat Problem?

Link zu diesem Kommentar
Share on other sites
Loetkolben Newbie

Loetkolben

Geschrieben
  • Autor
Geschrieben

Die ganzen Daten die du da siehst sind die FrameRendered Callbacks. Die kommen je nach eingestellter Frame Duration bis zu 100 mal pro Sekunde.

 

Aber warum kommen die zur Temperaturabfrage und warum enden die nicht?

Ausserdem wer hat die Callbacks initiiert?

 

 

Das erste setzen einer Farbe kann problematisch sein wenn die Pixel schon irgendwas in ihren Shift Registern stehen haben.

Da könnten wir vielleicht versuchen im Konstruktur des Bricklets schonmal ein irgendwas zu setzen um dieses "Problem" zu umgehen, wenn du ein Pixel anschließt nachdem der Master gestartet wurde bringt das aber natürlich nichts, da können wir dann auch nichts gegen machen (außer die Daten durchgängig senden, auch wenn sie nicht geändert werden).

 

Werden die LEDs bzw. die Speicher nicht beim booten initiiert, bzw. auf "leer" gesetzt?

Die LEDs und Bricklets sind vor dem Start des Masters angeschlossen.

 

 

Funktioniert die Temperaturabfrage denn auch mit unseren Bindings oder dem Brick Viewer nicht oder ist das ein netcat Problem?

 

Mit dem Brickviewer bekomme ich Werte. Die Bindinds habe ich nicht installiert und auch nicht ausprobiert. Ich glaube nicht, dass es ein netcat Problem ist.

 

 

Ich will doch nur eine LED setzen und mir dabei nicht die Kommunikation mit den anderen Scripten und Bricklets zerschiessen.  :'(

 

 

Der Loetkolben

Link zu diesem Kommentar
Share on other sites
Loetkolben Newbie

Loetkolben

Geschrieben
  • Autor
Geschrieben

Wenn ich anstelle des "nc -w1" Scriptes die Temperatur/Linearbrickletstellung mit

"./tinkerforge --host 192.168.20.79 --port 4223 call linear-poti-bricklet edj get-position"

abfrage passiert das Problem nicht. Das Script liefert sofort einen Wert zurueck, auch wenn gleichzeitig die LEDs angesprochen werden.

 

Das "tinkerforge" Shell script wird nicht mit den Daten zugemuellt. TCPDUMP verhaelt sich unauffaellig. Warum?

 

So sieht der TCPDUMP von der "tinkerforge call" Abfrage aus, waehrend die LEDs angesprochen werden. Alles gut:

[Anfang der Daten]
12:41:50.256432 IP 192.168.23.81.39209 > 192.168.20.79.4223: Flags [s], seq 1518293508, win 5840, options [mss 1460,sackOK,TS val 1788506609 ecr 0,nop,wscale 7], length 0
12:41:50.281150 IP 192.168.20.79.4223 > 192.168.23.81.39209: Flags [s.], seq 3646544550, ack 1518293509, win 8192, options [mss 1211,nop,wscale 8,sackOK,TS val 253467215 ecr 1788506609], length 0
12:41:50.281193 IP 192.168.23.81.39209 > 192.168.20.79.4223: Flags [.], ack 1, win 46, options [nop,nop,TS val 1788506615 ecr 253467215], length 0
12:41:50.282615 IP 192.168.23.81.39209 > 192.168.20.79.4223: Flags [P.], seq 1:9, ack 1, win 46, options [nop,nop,TS val 1788506615 ecr 253467215], length 8
12:41:50.313223 IP 192.168.20.79.4223 > 192.168.23.81.39209: Flags [P.], seq 1:11, ack 9, win 257, options [nop,nop,TS val 253467217 ecr 1788506615], length 10
12:41:50.313526 IP 192.168.23.81.39209 > 192.168.20.79.4223: Flags [.], ack 11, win 46, options [nop,nop,TS val 1788506623 ecr 253467217], length 0
12:41:50.316259 IP 192.168.23.81.39209 > 192.168.20.79.4223: Flags [F.], seq 9, ack 11, win 46, options [nop,nop,TS val 1788506624 ecr 253467217], length 0
12:41:50.317071 IP 192.168.20.79.4223 > 192.168.23.81.39209: Flags [P.], seq 11:21, ack 9, win 257, options [nop,nop,TS val 253467218 ecr 1788506615], length 10
12:41:50.317128 IP 192.168.23.81.39209 > 192.168.20.79.4223: Flags [R], seq 1518293517, win 0, length 0
12:41:50.345171 IP 192.168.20.79.4223 > 192.168.23.81.39209: Flags [.], ack 10, win 257, options [nop,nop,TS val 253467221 ecr 1788506624], length 0
12:41:50.345221 IP 192.168.23.81.39209 > 192.168.20.79.4223: Flags [R], seq 1518293518, win 0, length 0
12:41:50.349355 IP 192.168.20.79.4223 > 192.168.23.81.39209: Flags [F.], seq 21, ack 10, win 257, options [nop,nop,TS val 253467221 ecr 1788506624], length 0
12:41:50.349403 IP 192.168.23.81.39209 > 192.168.20.79.4223: Flags [R], seq 1518293518, win 0, length 0
[Ende der Daten]

 

 

Der Loetkolben

Link zu diesem Kommentar
Share on other sites
borg Community Regular

borg

Geschrieben
Geschrieben

Aber warum kommen die zur Temperaturabfrage und warum enden die nicht?

Ausserdem wer hat die Callbacks initiiert?

 

Callbacks gehen immer an alle Socketverbindungen, so ist das Protokoll. Anders ginge es auch gar nicht, woher soll der Brickd wissen welcher Teilnehmer den Callback haben möchte?

 

Die Bindings selbst wissen ob du einen Callback registriert hast und schmeißen die Nachricht weg wenn du keinen registriert hast.

 

Werden die LEDs bzw. die Speicher nicht beim booten initiiert, bzw. auf "leer" gesetzt?

 

Du meinst intern im WS28**? Offensichtlich nicht :D.

 

Mit dem Brickviewer bekomme ich Werte. Die Bindinds habe ich nicht installiert und auch nicht ausprobiert. Ich glaube nicht, dass es ein netcat Problem ist.

Es ist kein Problem mit netcat, aber du kannst nicht davon ausgehen das du direkt als nächste Nachricht die Antwort auf eine Anfrage bekommst nachdem du sie losschickst, so funktioniert das Protokoll nunmal nicht :).

Link zu diesem Kommentar
Share on other sites
Loetkolben Newbie

Loetkolben

Geschrieben
  • Autor
Geschrieben

Aber warum kommen die zur Temperaturabfrage und warum enden die nicht?

Ausserdem wer hat die Callbacks initiiert?

 

Callbacks gehen immer an alle Socketverbindungen, so ist das Protokoll. Anders ginge es auch gar nicht, woher soll der Brickd wissen welcher Teilnehmer den Callback haben möchte?

 

Der ihn angefordert/geoeffnet hat soll die Daten bekommen.  >:(

 

Aber warum werden die Callbacks ueberhaupt ausgeloest? Ich habe das die nicht ausgeloest!

 

 

 

Die Bindings selbst wissen ob du einen Callback registriert hast und schmeißen die Nachricht weg wenn du keinen registriert hast.

 

Das habe ich ja verstanden. Aber der Punkt ist, dass niemand einen Callback registiert hat!

 

Werden die LEDs bzw. die Speicher nicht beim booten initiiert, bzw. auf "leer" gesetzt?

 

Du meinst intern im WS28**? Offensichtlich nicht :D.

 

Verstehe ich nicht. Nach dem (Power-On) booten sind alle LED aus. Wenn ich nun die LEDs setze, dann schickt das Bricklet die Daten an den LED-Strip. Wo soll da noch was im WS2812 stehen? Die Farbwerte werden doch LED zu LED weitergeschoben und dann in dem LED-Chip angezeigt, oder nicht?

 

Eine Moeglichkeit waehre, dass beim Start des Bricklet die Speicherzellen aller LEDs auf 0,0,0 gesetzt und prophylaktisch einmal an den LED-Strip rausgeblasen werden.

 

Ich muss noch doch auf einen definierten Zustand verlassen koennen, bzw. wenn ich 11,11,11 setze, darf die LED nicht 55,55,11 (oder so) anzeigen.

 

 

Mit dem Brickviewer bekomme ich Werte. Die Bindinds habe ich nicht installiert und auch nicht ausprobiert. Ich glaube nicht, dass es ein netcat Problem ist.

Es ist kein Problem mit netcat, aber du kannst nicht davon ausgehen das du direkt als nächste Nachricht die Antwort auf eine Anfrage bekommst nachdem du sie losschickst, so funktioniert das Protokoll nunmal nicht :).

 

Ja, zum einen funkionieren die Bindings, siehe meinen anderen Beitrag. Zum anderen habe ich auch verstanden, dass die naechste Antwort nicht meine Antwort sein muss, deshalb habe ich bei den Temperaturabfragen auch Filter drin, die nach der Antwort suchen, aber dazu muss der Datenfluss mal beendet sein.

Hier werden aber Daten in Temperaturabfrage geschoben ohne das ein Ende gibt. Das liegt wohl an den endlosen Callbacks. Deshalb nochmals die Frage: Wodurch werden die Callbacks ausgeloest?

 

 

Der Loetkolben

Link zu diesem Kommentar
Share on other sites
borg Community Regular

borg

Geschrieben
Geschrieben

Eine Moeglichkeit waehre, dass beim Start des Bricklet die Speicherzellen aller LEDs auf 0,0,0 gesetzt und prophylaktisch einmal an den LED-Strip rausgeblasen werden.

 

So einfach ist es nicht, ich weiß beim Start weder wieviele LEDs noch welcher LED Typ angeschlossen ist.

 

Du triggerst den FrameRendered Callback durch die gesetzte Frame Duration und dadurch das du das erste mal einen LED Wert setzt.

 

Zur grundsätzlichen Funktionsweise des LED Strip Bricklet diesbezüglich haben wir eine Grafik hier: http://www.tinkerforge.com/de/doc/_images/Bricklets/bricklet_led_strip_fixed_frame_rate.png

 

 

Die Firmware im Anhang hat folgende Änderungen:

* Setze LED Werte erneut wenn sie vom Nutzer überschrieben wurden (auch wenn es die gleichen Werte sind)

* Setze LED Werte 2x, auch wenn sie nur einmal vom Nutzer gesetzt wurden (das sollte dein Problem lösen welches bei dem allerersten setzen der LEDs auftritt)

* Eine Frame Duration von 0 bedeutet, dass keine weiteren Frames mehr gesetzt werden, es also auch keinen FrameRendered Callback mehr gibt. Hinweis: Wenn du wieder neue Werte setzten möchtest musst du wieder eine Frame Duration > 0 einstellen.

 

Alternativ, wenn du nur nur alle paar Stunden die Farbe wechseln möchtest, würde in deinem Fall vielleicht eine feste Frame Duration  von 1000ms o.ä Sinn machen. Dann wirst du nicht zugespammt kanst aber trotzdem einfach deine LED Werte nach belieben setzen, es dauert dann halt maximal 1s bis sie angezeigt werden.

bricklet_led_strip_v2_0_5_beta1.bin

Link zu diesem Kommentar
Share on other sites
Loetkolben Newbie

Loetkolben

Geschrieben
  • Autor
Geschrieben

Hallo borg,

 

danke fuer die Firmware, hier ein paar Erfahrungen damit:

 

Man merkt, dass da ein Doppelsetzten passiert, weil die gelbe LED erst erscheint und dann nach ca. 0,2-0,3 Sekunden verschwindet. OK soweit.

 

Dazu noch folgendes (Immer nach Power-on):

Wenn man 4 LEDs hat (index=0 laenge=4), dann ist die 4. LED erst gelb, dann weiss.

Hat man 3 LEDs, dann ist die 3. LED erst gelb, dann weiss.

Hat man 2 LEDs ... also immer die letzte.

 

Seit ihr sicher, dass dieses Verhalten nicht durch un-initialisierte Werte aus dem Brickletspeicher kommt?

 

Ansonsten ist das ein prima Workaround fuer das erstmalige Setzen der LEDs.

 

---

 

OK, man weiss nicht welcher Type LEDs angeschlossen ist um beim Power-on richtig zu initialisieren. Man koennte dies im Master speichern oder passende Firmwares machen. Alles nicht schoen ...  ???

 

Das mit der Frameduration = 0 finde ich eine super Sache. (Habe ich noch nicht getestet) Fehlt eigentlich nur ein "manueller" Set-Frame-Now Befehl.  ;)

Hmmmm. Da kommt mir eine Idee, vielleicht auch so: Wenn man eine "identische" Set-RGB-Funktion haette dann nur einmal die Daten auf den Strip schickt ohne die endlosen Callbacks zu starten. :grubel:

 

 

 

Die Sache mit den 1000ms habe ich nicht verstanden. Ob 10, 100 oder 1000ms ist doch egal. Sobald eine LED gesetzt wurde geht doch dann das schicken von Callbacks wieder los und blockiert andere Verbindungen.

 

 

Morgen bin ich evtl. nicht mehr am Stack, sonst erst wieder ab Dienstag

 

 

Der Loetkolben

 

 

 

 

Link zu diesem Kommentar
Share on other sites
borg Community Regular

borg

Geschrieben
Geschrieben

Die Sache mit den 1000ms habe ich nicht verstanden. Ob 10, 100 oder 1000ms ist doch egal. Sobald eine LED gesetzt wurde geht doch dann das schicken von Callbacks wieder los und blockiert andere Verbindungen.

Ich weiß nicht was du mit "blockiert andere Verbindungen" meinst, die Callbacks blockieren nichts. Wenn du die Frame Duration auf 1000ms stellst bekommst du nur einen Callback pro Sekunde (jedes mal wenn ein Frame auf die LEDs übertragen wurde). Die Pause zwischen den Callbacks sollte lang genug sein damit dein netcat einen Timeout bekommt.

Link zu diesem Kommentar
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
 Share
Go to topic listing
×
×
  • Neu erstellen...