borg

Plugin: LED Strip Bricklet 2.0.4 Use measured timings instead of faulty datasheet values Download: LED Strip Bricklet Firmwares: DC Brick 2.0.3, IMU Brick 2.0.4, Master Brick 2.2.2, Servo Brick 2.0.5, Stepper Brick 2.0.5 Remove rarely used USB hotplug feature (prevents accidiential stack restart after heatup) Download: DC Brick, IMU Brick, Master Brick, Servo Brick, Stepper Brick

Tja, ich hab nochmal ein wenig rumgetestet. Folgende Feststellungen: Bei mir funktioniert es mit einem WS2812B Strip sowie mit einem 256 WS2812B-Pixel-Array mit folgenden Vorgehensweisen: * Einfaches Sleep der Zeiten wie sie im Datenblatt stehen (Zeiten für Funktionsaufrufe etc. werden nicht beachtet) * Kalibriertes Sleep damit die Zeiten die im Datenblatt stehen exakt eingehalten werden * Zeiten so nutzen wie sie in Tims Blog beschrieben werden Dabei kann ich jeweils keinerlei Flackern o.ä. feststellen. Ich hab mal eine Firmware gebaut die die gemessenen Zeiten aus dem Blogeintrag möglichst gut einhalten: * Low Phase von 250ns (genau zwischen 60 und 500ns) * High Phase von 1250ns (mehr als das Minimum von 625ns) * Gesamtzeit 1500ns (250ns über der Minimalgesamtzeit von 1250ns) Damit haben wir in jeder Richtung reichlich Abstand zu den Minima und Maxima. Funktioniert das bei dir besser, Loetkolben? bricklet_led_strip_v2_0_4_beta1.bin

Wenn ich nach dem gehe was er so schreibt sind die Timings ja nahezu egal. Er verwendet für WS2811, WS2812 und WS2812B in seiner lib den gleichen Code der folgende Einschränkungen einhält: Wenn wir danach gehen ist der Code von V2.0.3 absolut OK.

Ich hab eine mögliche Fehlerquelle gefunden, der WS2812 hat andere Timings als der WS2812B! Das war mir nicht bewusst. ich hab die Timings des WS2812 implementiert. Vergleiche Seite 4 in den beiden Datenblättern: http://acrobotic.com/datasheets/WS2812.pdf http://acrobotic.com/datasheets/WS2812B.pdf Interessanterweise hatten wir auf der Maker Faire einen WS2812B Streifen und der lief mit den WS2812 Timings über zwei Tage ohne Probleme . Support für den WS2812B füge ich dann noch hinzu . Du kannst zwischen WS2812B und WS2812 anhand der Anzahl der Pinne der LED unterscheiden. 2812 hat 6 Pinne und WS2812B hat 4.

We should have called it color1, color2 and color3. Unfortunately there is no standard on how the colors are connected. So some manufacturers connect them "RGB", others connect them "BGR". The LED strips we are selling are actually connected the other way around than the LED pixels... At the time we made the API we didn't know that there are these differences.

Kannst du ein Foto von der Verkabelung machen?

Ist vielleicht ein Timing Problem. Wir halten die im Datenblatt angegebenen Timings noch nicht auf die ns genau ein, da wir hier keine Probleme damit hatten hab ich es aber einfach erstmal ignoriert. Das kann ich aber nächste Woche noch verbessern, mal gucken ob es noch mal Feedback diesbezüglich gibt. Edit: Ich hab mich schonmal daran Versucht die Protokollimplementierung zu verbessern: https://github.com/Tinkerforge/led-strip-bricklet/commit/1f70acb7021b5fa49e1ac8c2527d085f0f971c37 Wir werden das nochmal mit ein paar unterschiedlichen WS2812 Strips durchtesten.

Plugin: LED Strip Bricklet 2.0.2 Unterstützung für WS2811 und WS2812 hinzugefügt Download: LED Strip Bricklet

Plugin: LED Strip Bricklet 2.0.2 Add support for WS2811 and WS2812 Download: LED Strip Bricklet

Das ist leider aktuell nicht möglich.

Die Daten aus dem Datenblatt sind schon korrekt, die typische Periode in der ein Magnetfeld detektiert werden kann ist 75ms, was 13Hz entspricht. Ich hab mal ein "bis zu 13Hz" in die Dokumentation mit eingefügt. Entschuldigung für die unklare Beschreibung!

Du kannst die Ethernet Extension draufsetzen, das RED Brick holt sich eine IP per DHCP und dann kannst du dich per SSH drauf verbinden und "apt-get install *" aufrufen. Für jemanden der Linux Kenntnisse hat ist das RED Brick ein ganz normaler ARM Linux PC mit einem vorinstallierten Debian. Wichtig ist uns beim RED Brick lediglich das man keine Linux Kenntnisse benötigt um es zu benutzen (oder das man überhaupt wissen muss das Linux drauf läuft, wir wollen da etwaige Berührungsängste möglichst vermeiden). Wir werden aber natürlich niemanden daran hindern das Linux zu nutzen wenn er möchte . Edit: Das komplette Dateisystems bis auf einzelne Ausnahmen wird read-only sein, damit man auch jederzeit den Strom ziehen kann und der RED Brick trotzdem wieder hochfährt ohne zu mucken. D.h. du musst also das Dateisystem einmal remounten bevor du etwas damit machen kannst, aber die Kommandozeile die man dafür benötigt können wir ja einfach dokumentieren .

Wir haben die generelle Struktur der Software auf dem RED Brick in einem Blogeintrag erläutert: http://www.tinkerforge.com/de/blog/2014/6/20/red-brick-software-infrastruktur Man benötigt vermutlich ein bisschen Verständnis von der Materie um mit dem Blogeintrag überhaupt etwas anfangen zu können, allerdings ist er trotzdem im gewissen Sinne noch sehr oberflächlich. Daher bin ich mir nicht sicher wie sinnvoll er überhaupt ist . Nichts desto trotz würden wir hier gerne versuchen eine Diskussion anzustoßen, da wir jetzt in der Phase sind wo es noch möglich wäre Dinge an dem grundsätzlichen Aufbau der Software zu ändern. Das wird umso schwieriger desto mehr implementiert ist. Also: Kritik, Wünsche, Anregungen, Fragen usw. bitte hier ausführen .

RED Brick Software Infrastructure Blog entry

RED Brick Software-Infrastruktur Blogeintrag

Wo steht das man das "tinkerforge." entfernen soll? Das solltest du nur entfernen wenn die ip_connection.py und die brick_master.py usw im gleichen order wie das auszuführende Script liegt. Du schmeißt da alles ein wenig durcheinander . Wenn du die .egg installierst brauchst du den tinkerforge/ Order selbst nicht mehr, da die Python library direkt im System installiert wird. Oder andersrum: Wenn du den tinkerforge/ Order da hast wird nicht der Kram benutzt der über das .egg im System installiert ist.

Die IP Verbindung wird zum Brick Daemon aufgebaut, die ist auch im anderen Beispielprogramm. Kannst du die neue Exception hier nochmal posten?

Wo hast du den Code denn weg? in deiner Exception steht etwas von "xip_connection", das kommt aber im Code gar nicht vor. Kann es sein das sich da irgendwie aus versehen ein zusätzlich "x" eingeschlichen hat was da nicht hingehört?

Auf einen Master Brick kann man maximal 8 weitere Master Bricks stecken. An diese wiederum können je 4 Bricklets angeschlossen werden. Summa summarum macht das maximal 36 Sensoren.

Du solltest dich ohne etwas in der brickd.config einzustellen mit dem Brick Viewer auf localhost:4223 (host:port) verbinden können.

Das ist komisch. Tritt das Problem denn nur auf wenn du alle Bricklets am Master hast? Oder tritt das Problem auch schon auf wenn du nur ein Temp IR am Master hast?

Naja du kannst eine aspx Anwendung mit mono auf dem RPi schreiben, das ist kein Problem. Dafür musst du natürlich ein Webserver einrichten (sowas wie Apache und nginx). Eine kurze google Suche hat mir diese Anleitung direkt fürs RPi gefunden: http://www.mikeobrien.net/blog/configuring-nginx-mono-and-asp-net-on-raspberry-pi/

Was sagt die Ausgabe von "dmesg" nachdem der Master neu gestartet hat? Ist ein Hub zwischen Master und PC?

Cool . Wie stellst du sicher dass das Licht nicht in die Nachbarelemente reinstrahlt? Hast du eine dicke MDF Platte verwendet wie in dem mikrokontroller.net Artikel?

Kannst du mal die angehängte Master Firmware ausprobieren? Ich hab mal Testweise die USB Hotplug Erkennung ausgebaut. Ich halte es zwar für unwahrscheinlich das es dran liegt, aber hier im anderen Thread hat es für einen Aufbau mit Stepper Brick geholfen: http://www.tinkerunity.org/forum/index.php/topic,2309.0.html Falls es daran liegt sollten wir vermutlich die Hotplug Erkennung komplett rausbauen, sie ist sowieso nur in relativ seltenen Fällen sinnvoll, wo man dann auch den Reset-Taster betätigen kann. Edit: PS: Sowohl auf dem Dual Relay Gehäuse als auch auf der Halteplatte sitzt noch eine abziehbare Schutzfolie firmware_brick_master_2_2_2_beta1.bin