Loetkolben

Hach ist das schoen. Ich habe gerade mal wieder die Bricks an einem Linuxkaestchen (Cubietruck) per "brick-flash-cmd" geflasht. Hat einwandfrei funktioniert. Leider muss man aber noch umstecken wenn man 2 Masterbricks hat, aber man muss den Stack nicht abbauen und zum PC bringen. Und vielleicht gibt es auch noch mal ein Remote-Update-Masterbrick 3.0 Der Loetkolben

Och. Laeuft wie ein Doeppchen! Nur zur Info: Das Timing beim Rendering (in dieser temporaeren FW 2.0.5) ist nicht veraendert worden. Man kann nur einfach eine LED setzten ohne das Callbacks loslaufen. Wenn man mit der ID 3 das Rendering aus- und einschaltet werden, wie bisher, die uebertragenen Werte nur nach Ablauf der Zeit auf die LEDs transferiert. Also die Brickletfirmware tut exact das was der Name verspricht! DANKE! Der Loetkolben

Hallo zusammen, ich bin mir nicht sicher, aber wurde da nicht mal was gemacht in Zusammenhang mit der Einfuehrung der Protokollversion 2?? Hier mal 2 Threads: Socketverbindung bei Verwendung von WLAN/Ethernet IPConnection->getConnectionState Vielleicht kommt ihre damit weiter. Der Loetkolben

Hallo photron, das zweite zuerst. Ja, du hast Recht, die Reihenfolge wie die Befehle eingehen ist egal, da die Werte ja zwischengespeichert werden. Dieser Logikschritt war mir nicht so klar. Alles ok. Das Problem mit den Callbacks mit einer kleinen Zeichnung. [LED-Strip---Master---USB---MiniPC]---LAN---SWITCH---LAN---PC1 +--PC2 +--PC3 | +---Router---VPN---Internet----vServer1 | | +-vServer2 | | | +----Hamburg-PC1 | +-Hamburg-PC2 | +-------Paderborn-NAS1 +-Paderborn-NAS2 +-Paderborn-NAS3 Wenn nun alle 10 Devices je eine LED "steuern" und dort ihren Status abliefern, bekommen doch alle 10 Devices die Callbacks presentiert. Da gibt es nun 2-ein-halb Probleme: 1. Wenn man die Callbacks nicht sauber abfaengt, dann koennen sie einem den Rechner zumuellen und zum Absturz bringen. (Endlos wartender Prozess und naechster Prozess per Cron gestartet) Das ist mir passiert und ein vServer ist kollabiert. Jetzt kann man sagen, dass ich besser programmieren sollte. OK, stimmt ein wenig. 2. Nur ein halbes Problem: Der Netztraffik im LAN ist hoch und so ziemlich alle Switchports sind beschaeftigt. Da kann man an den LED des Switches auch nichts mehr sinnvolles erkennen. (Flashing LAN) 3. Grosses Problem: Wie hoch ist der Traffic der Callbacks? Wenn jetzt nun, wie in meinem Beispiel, Callbacks zu 7 Devices per DSL rausgeht dann ist doch der Upload arg belegt. Deshalb: Vermeide Calbacks! Immer? Nicht immer, aber dann wenn man sie nicht braucht! Danke Der Loetkolben

Hallo zusammen, mein Problem Keller TF WLAN 1 + Master (2.3.4) --- Wlan 2 Etagen --- FB7240 --- LAN +-- VPN -- LAN 1. Ich hatte an der FB Aenderungen gemacht. Der Laptop hat sich wieder problemlos mit der FB verbunden. Der TF Stack nicht. Ich wollte nicht in den Keller laufen und habe die FB per Power off/on resettet. Nun war der Stack wieder aus dem LAN und per VPN/LAN erreichbar. Warum hat sich der Stack nicht automatisch wieder verbunden? Vielleicht ist das aber ein Problem der FB?! 2. Nun ca. 24 Stunden spaeter kommt wohl aber ein Stack Problem hinzu: Ploetzlich war der Stack nur noch aus dem LAN (Ping/Brickv) ansprechbar. Aus dem VPN/LAN (geroutet) konnte er weder per Ping noch per Brickv angesprochen werden. Warum? Es sah so aus, als haette der Stack sein Default Gateway verloren. Habe dann aus dem lokalen LAN per Brickv den Stack resettet und schon war er auch wieder aus dem (entferten) VPN/LAN erreichbar. Was ist das und warum passiert das? Der Loetkolben

Ja, so funktioniert diese Firmware zu dem Bricklet. Fuer den Einsatzzweck macht das auch Sinn. Genau! Deshalb muss ich nach dem Uebertragen der Daten via ID 1 mal kurz die FrameDuration > 0 setzen um sie dann nach einer selbst bestimmten Zeit wieder auf 0 zu setzen, damit die Werte auf die LEDs kommen. Um die in dieser Zeit anfallenden Callbacks moeglich klein zu halten, muss man ein wenig beim berechnen der Zeit tricksen. Siehe auch Ausgangsposting. Um diese Zeit moeglichst kein zu halten hatte ich eine kleine Aenderung vorgeschlagen. Siehe letzer Beitrag von mir. Eine grosse Loesung mit eigener ID nehme ich natuerlich gerne an. Ja, so ungefaehr. Wobei ich noch eine Anregung geben darf: Um eine LED am Bricklet aus der Ferne VON SERVER A zu setzen, muss man dann IMMER "nur" 4 Befehle absetzen: 1. WS2812 Init (Da nicht speicherbar und Bricklet Zustand unbekannt) 2. FrameDuration = 0 (Sicherheitshalber) 3. LED Werte uebermitteln 4. RenderFrame ausloesen Man muss nur aufpassen, dass nicht NICHT AUCH SERVER B zur gleichen Zeit eine andere LED setzen will. Die ersten beiden Befehle sind ja egal, wenn sie wiederholt werden, aber wenn die Schritte 3 und 4 verschachtelt reinkommen gibt es ein Problem: 3. LED Werte uebermitteln von Server A 3. LED Werte uebermitteln von Server B 4. RenderFrame von Server A 4. RenderFrame von Server B Ich Moment halte ich dies auseinander indem ich zeitversetzt arbeite. Wenn ihr schon schon eine neue ID machen moechtet, dann "clont" doch einfach die ID 1 (Werte annehmen) und rendert die Werte dann sofort auf die LEDs IN EINEM ZUG. Wenn man in diesem Zug auch noch in einem Byte den LED Typ mit angeben koennte waere es prima! Danke. Der Loetkolben PS: Warum das Ganze? Ich habe auf diversen Servern und NAS Buechsen ein kleines Script am laufen, dass Werte ausliest und diese Werte als Farben auf die LEDs des weit enferten LED-Strip-Bricklets sendet. Somit muss keine weitere Programmlogik (Wertesammler / Monitoring Tools) vorhanden sein. Z.B.: - EMail vorhanden: LED 1 gelb, bei mir aus 10 eMails LED 1 rot. - NAS HDD Spindown check: Schlaeft die Platte, dann LED 2 Gruen, sonst LED 2 Rot. - HDD Fuellgrad auf dem vServer: LED 3 verschiedenen Farben. - Kellerfenster auf: LED 10 tuerkis. u.s.w. Man kann das auch per Textdisplay machen, aber so ist es dezenter die Infos in der LED Wohnraumbeleutung unterzubringen. ;-)

Hmm. Ich habe den Eindruck, dass wir aneinander vorbeireden. Von einer Halbierung der Rate habe ich nicht gesprochen. Vielleicht verstehe ich auch den Ansatz nicht. Frage: Wenn ich "set_frame_duration" von 0 auf x ms setze, was wird beim ersten mal, nach dem setzen auf x ms, zuerst ausgefuehrt? a) die Wartezeit von x ms? b) das Anzeigen der Farben auf die LEDs? Ich denke es geht so: a b a b Besser faende ich : b a b a b Mal sehen wie die neue FW ist. Danke Der Loetkolben

Raeusper, rauesper. gibt es schon ein Workpackage fuer den Praktikanten? Als erste (unabhaengige) Massnahme waere es prima wenn nach dem Aktivieren des Rendering zuerst gerendert wird und dann die Zeit ablaeuft und nicht umgekehrt, also so: Statt: ......R......R......R Dieshier: R......R......R......R Kann man es einfach "mal" machen oder spricht was dagegen? Aus meiner Sicht muesste "nur" vor Eintritt in die Schleife das Rendering zusaetzlich am Anfang aufgerufen werden. Der Rest kann ja spaeter kommen. Der Loetkolben.

Hallo zusammen, ich habe ein Dust Detector Bricklet brav im Wohnzimmer stehen. Damit auch die Luft "durchgehen" kann steht es senkrecht auf einer Kante und die Luft kann quasi waagerecht durchstroemen. Der Standort des Bricklets wurde seit Monaten nicht veraendert. Nun zum Problem: Anfaenglich waeren die Werte um ca. 50µg/m. Mittlerweile ist der Durchschnittswert 150µg/m³. Im Tagesverlauf liegt die Schwankung weiterhin bei +/- 10µg/m³. Warum? Wo ist das Problem? Altert der Sensor? Muss da etwas gereinigt werden und wenn ja warum und wie oft? Der Loetkolben

Edit: Neue LED Bricklet Firmware 2.0.6 verfuegbar mit abschaltbarem Callback Nach der freundlichen Ueberlegung hier "RGB LED Bricklet mit zusaetzlichen LEDs", dass man ggf. das Strip Bricklet erweitert habe ich mal meine Sorgen mit den Callbacks hier beschrieben und einen Loesungsvorschlag hinzugefuegt. Wer sorgfaeltig liest versteht es hoffentlich, aber ansonsten beantworte ich gerne Fragen. Sollte ich Fehler gemacht haben, bitte mal eine Info schreiben. Anbei (unten) das Programm mit dem man eine oder mehrere LED (mit gleicher Farbe) setzen kann. Die Kurzform lautet: #1 WS2812 setzen #2 LED Wert rausschicken #3 Redering aktivieren Kritische Pause #4 Rendering deaktivieren Die Frameduration ist entscheidend zwischen den Punkten 3 und 4, denn: Frage: Die Farbwerte werden erst dann auf die LED gebracht, wenn die Renderingzeit abgelaufen ist!? Also als Beispiel: Rendering 1000ms=1Sekunde - LED Farben uebertragen - Rendering mit 1000ms aktivieren - Nach 0,5 Sekunden das Rendering wieder deaktivieren. ->Es wird keine Farbe auf die LED gesetzt. Man muss mindestens 1 Sekunde warten bis man das Rendering wieder deaktiviert, sonst erscheint keine Farbe auf der LED. Da muss man leider viel experimentieren bis man die Anzahl der Callbacks niedrig hinbekommt und das Programm doch noch funktioniert. Das Problem um Callbacks gering zu halten: Man muss den Renderingwert klein setzen, z.B. 10ms und dann nach ca. 500ms wieder stoppen. (Das shellscript hat ja auch seine Laufzeit) Dann hat man aber noch bis zu 50 Callbacks zu "verdauen". Hilfreich (als Workaround) waere es, wenn nach aktivieren des Rendering sofort gerendert wird und dann erst die Zeit anfaengt zu laufen. Damit koennte man sofort das Rendering wieder deaktivieren und die Farben wuerden trotzdem auf die LED gebracht. Statt: ......R......R......R Dieshier: R......R......R......R Vorschlag zur besseren Loesung: 1. Die Callbacks duerfen nicht automatisch starten, wenn man den ersten Wert gesetzt hat. (Nie automatisch) (Die alten Funktions ID 1 wird genutzt) 2. Es gibt einen API Befehl, der den uebertragenen Wert mit einem "Render-only-once" auf die LED bringt oder 1. Einen kombinierten Befehl der die Farbwerte wie Funktions ID 1 annimmt und sofort einmalig auf die LED bringt. Dabei werden keine Callbacks ausgeloest. Wenn man in dem neuen Befehl auch gleich noch den Chiptypen setzen kann, erspart man sich die Initialisierung, da man den Chiptyp nicht im EEPROM speichern kann. Hier der Code um eine oder mehrere LED (mit gleicher Farbe) zu setzen: #!/bin/bash HOST=192.168.1.99 PORT=4223 tUID=ABC LEDINDEX=00 LEDLENGTH=04 LEDCOLOR=03,03,03 LOGFILEOUTOUTFORMAT=0 RECEIVEPACKETSTORE=0 RECEIVEPACKETPATH=$(dirname $0) while [ $# -gt 0 ] #Solange die Anzahl der Parameter ($#) größer 0 do if [ "$1" = "-x" ] ; then LOGFILEOUTOUTFORMAT=1 ;fi if [ "$1" = "-h" ] ; then HOST=$2 ;fi if [ "$1" = "-p" ] ; then PORT=$2 ;fi if [ "$1" = "-u" ] ; then tUID=$2 ;fi if [ "$1" = "-r" ] ; then RECEIVEPACKETSTORE=1 ;fi if [ "$1" = "-R" ] ; then RECEIVEPACKETPATH=$2 ;fi if [ "$1" = "-li" ] ; then LEDINDEX=$2 ;fi if [ "$1" = "-ll" ] ; then LEDLENGTH=$2 ;fi if [ "$1" = "-lc" ] ; then LEDCOLOR=$2 ;fi shift done #---------------------------------------------------------------------------------- ALPHABET="123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ" BASECOUNT=`expr length $ALPHABET` DECODED=0 MULTI=1 for ((i=`expr length $tUID - 1` ; i > -1 ; i--)) do VALUE=${tUID:$i:1} DECODEDVALUE=`expr index $ALPHABET $VALUE` DECODEDVALUE=`expr $DECODEDVALUE - 1` DECODED=`expr $DECODED + $MULTI \* $DECODEDVALUE` MULTI=`expr $MULTI \* $BASECOUNT` done HEXDECODEDSTR="" HEXDECODED=`printf "%08x" $DECODED` for i in {6,4,2,0} do DIGIT=${HEXDECODED:$i:2} HEXDECODEDSTR=$HEXDECODEDSTR"\x"$DIGIT done #---------------------------------------------------------------------------------- #WS2812 setzen: SENDPACKET=$HEXDECODEDSTR"\x0a\x09\x10\x00\xfc\x0a" echo -n -e $SENDPACKET | nc -q0 $HOST $PORT #---------------------------------------------------------------------------------- SENDPACKET=$HEXDECODEDSTR"\x3b\x01\x10\x00" SENDPACKET=$SENDPACKET"\x$LEDINDEX\x00\x$LEDLENGTH" # index -- uint16 # length -- uint8 # r -- uint8[16] # g -- uint8[16] # b -- uint8[16] LEDCOLOR1=`echo $LEDCOLOR|cut -d "," -f1` LEDCOLOR2=`echo $LEDCOLOR|cut -d "," -f2` LEDCOLOR3=`echo $LEDCOLOR|cut -d "," -f3` LEDLENGTHCOUNTDOWN=$LEDLENGTH for i in {1..16} do if [ $LEDLENGTHCOUNTDOWN -ge 1 ] then LEDRED=$LEDRED"\x$LEDCOLOR1" LEDGREEN=$LEDGREEN"\x$LEDCOLOR2" LEDBLUE=$LEDBLUE"\x$LEDCOLOR3" LEDLENGTHCOUNTDOWN=`expr $LEDLENGTHCOUNTDOWN - 1` else LEDRED=$LEDRED"\x00" LEDGREEN=$LEDGREEN"\x00" LEDBLUE=$LEDBLUE"\x00" fi done SENDPACKET=$SENDPACKET$LEDRED$LEDGREEN$LEDBLUE # Der "Fram-Duration" Wert muss so sein: # Bei sehr kleinem Wert kommen viele Callbacks, bis er wieder (in der nachsten Zeile) auf 0 gesetzt wird und die Callbacks aufhoeren zu "senden". Das muellt nur rum. # Bei grossem Wert (> 1 Sekunde) muss ein Sleep 1 oder Sleep 2 folgen, sonst wird er in der naechsten Zeile wieder auf 0 gesetzt, bevor "gerendert" wurde # und der Wert auf die LED gebracht wurde # # "...\xE8\x03" Callback = 1 Sekunde = Wert 1000 = 03E8 hex # Ist der Wert "so halb", z.B.: "...\x70\x00", dann wird ein rendern mal ausgefuehrt und mal nicht. Warum??? # Ist der Wert "...\x30\x00", wird nur jedes 2. mal der RGB Wert auf die LEDs geschrieben. -> also noch kleiner machen # Bei einem Wert "...\x10\x00", wird jedesmal die LEDs gesetzt, "aber"/und es werden zwischen 1 und 3 Callbacks ausgeloest. # Sofern alle anderen Programme mit den zwischenzeitlichen Callbacks klarkommen waere dies ein Workaround. # 3.7.2016 - Den Wert auf ""...\x07\x00" gesetzt, da die Anzeige nicht ganz zuverlaessig funktioierte. Ab und zu wurde keine LED aktualisiert. echo -n -e $SENDPACKET | nc -q0 $HOST $PORT # LED Wert rausschicken echo -n -e "$HEXDECODEDSTR\x0a\x03\x10\x00\x07\x00" | nc -q0 $HOST $PORT # Redering aktivieren echo -n -e "$HEXDECODEDSTR\x0a\x03\x10\x00\x00\x00" | nc -q0 $HOST $PORT # Rendering deaktivieren echo "LED Start:$LEDINDEX, Laenge:$LEDLENGTH, Color:$LEDCOLOR1,$LEDCOLOR2,$LEDCOLOR3"

Ohhhh!! Da biete ich Kaffee und Kuchen fuer die ganze Mannschaft freihaus! Letztens haben mir die Callbacks des Bricklets meinen weit entfernten Linuxserver in die Knie gezwungen, da die andauernden, von mir nicht bemerkten Callbacks, die TCP Verbindung aufrechterhalten haben. Ja, es liegt an meinemer Programmlogik, aber selbst mit den Bindings bliebe der Dauerbeschuss bestehen. Ich komme auf das Thema mit meinem "Workaround" zurueck. Edit: Habe meine Problem mit dem LED Strip Bricklet hier beschrieben, da es nichts mit diesem Bricklet zu tun hat. BTW: Ich hatte was mit RGB Matrix im Kopf .... Der Loetkolben

Hallo Borg, ich meinte, dass ich mir beim LED Strip Bricklet NICHT SICHER bin ob es da auch ein Problem gab/gibt. Es muessten doch auch alle anderen LED-Dingens auf dem Markt so ein Verhalten zeigen, denn die haengen doch auch an irgendwelchen I/O Pins von Microcontrollern. Vielleicht hilft eine andere Beschaltung? Ich weiss auch nicht, ob bei dem gruenen Flash die Initialisierung schon bei der Software, bzw. Firmware des Bricklets liegt. Es dauert schon einen Moment bis der gruene Flash kommt. Der Loetkolben

Hallo liebes Tingerforgeteam. Das neue WLAN 2.0 Bricklet macht sich technisch erstmal ganz gut, aber der WAF ist nicht ganz so toll. Insbesondere die gruene LED ist extrem grell und beleuchtet ein Schlaf oder Wohnzimmer schon ganz alleine. Gut man kann die LED abschalten, aber dann sehe ich den Status nicht mehr. Ich will ja auch was von der Technik haben. Man muss aber mal der Industrie ein Kompliment aussprechen, dass die aus so einem kleinen Sandkorn so viel Licht rausholen. Das ist schon enorm! - Ihr habt noch ein Widerstandsarray benutzt. Koennte man nicht fuer die gruene LED 2 Widerstaende hintereinander oder falls das zu viel Ohm sind eine Mischung aus 3 Widerstanden schalten? - Achtung Wiederholung: Wenn es 2 Loetpads mit Leiterbahnbruecke geben wuerde, koennte man diese mit einem Bastelmesser durchtrennen und man koennte einen passenden Widerstand dort anbringen. Platz waere "oben" ja genug. Der Loetkolben

Hallo liebes Tinkerforgeteam. Was muesste ich machen damit es eine Firmware gibt, die die Moeglichkeit hat 11 LEDs mit dem RGB LED Bricklet anzusprechen? Warum 11? Es gibt 8er und 10er Streifen und ggf. sollte die Stromversorgung via Brickletkabel noch ausreichen. ;-) Was macht eigentlich das RGB Matrix Bricklet? Wuerde die kommende Firmware helfen? Das LED Strip Bricklet macht sehr viel Aerger und Aufwand um eine LED anzusprechen und die "automatischen" Callbacks zu unterdruecken. Da ist sonst Ruck-Zuck der DSL Upload zu. Der Loetkolben

Das Remote Switch Bricklet hat auch bei mir immer mal Timingprobleme gemacht. Z.B. "Nur" wenn etwas physikalisch im Funkweg stand (Also ein verbogenes Signal) konnte man die Steckdose schalten. Das war Buehnenreif. Glaskugel: Kann es an den unterschiedlichen Spannungen der Netzteile liegen, so dass dadurch irgendeine Komponente ein minimal anderes Timing bekommt und so aus der Software-Timing-Toleranz rausfaellt? Damit wuerde das Signal nicht mehr zeitlich passen. Der Loetkolben

Hallo, nachdem die RGB LED Bricklets angekommen sind musste ich feststellen, dass nach/bei jedem Reset des Masterbricks ein gruener "Blitz" von der RGB LED erzeugt wird. Kurz, hell, heftig. Sehr unangenehm. Wenn ich mich noch recht erinnere gab es beim RGB Strip Bricklet auf irgendein Initialisierungsproblem, wo die erste? LED immer "zuckte"?! Aber kann man das nicht bei dem RGB LED Bricklet abstellen. Anbei die Hardwareliste, falls es weiterhilft. Der Loetkolben

Um die Glaskugel noch ein wenig trueber zu machen hier ein aktueller Artikel von teltarif.de. Nur einige WLAN Geraete machen Probleme, wobei sie an anderen AP keine Probleme machen. FRITZ!Box macht Internet-Probleme: Samsung Galaxy S6 & Blackberry Priv Der Loetkolben

Und da wird es noch eine SW Version eben wo man bis zu 7 LED dranloeten dranschrauben kann. Das sollte auch die Versorgunsspannung mitmachen. Der Loetkolben

Den gleichen Fehler wie: In der neuen SW Version (aka neue Oberflaeche) muss die Passwortabfrage gesetzt sein, wenn man aus einem anderen LAN auf die Box zugreift. Ebenso werden nur noch MAC Adressen anstelle von IP Adressen in der Netzuebersicht angezeigt, wenn man im IP-Client mode ist. Von der Abschaffung der debug.cfg / telnet und somit openvpn ganz zu schweigen. Von den Reboots bei WLAN Zugriff wenn die Box mal 4 Wochen ohne Last an ist. Lass es. - Dort hat man sich von SW Qualitaet verabschiedet. Wenn du es machen moechtest oder einen guten Draht hast, wuerde ich dich unterstuetzen. Ich selbst habe zu viele andere IT Baustellen. Der Hammer war letzte Woche, die Bestaetigung, dass die neuere 7390 ein schlechteres Modem hat als die aeltere 7240. Originalton: "Die 7390 ist fuer Hightspeed optimiert und arbeitet an einem ADSL2+ Anschluss nicht so performant" - Schoen, aber hier gibt es kein VDSL. 7240: Down 6,0 Mbit / Up 0,9 MBit 7390: Down 3,8 MBit / Up 0,9 MBit Auch wurde bestaetigt, dass ein Download auf PC1, wenn er exakt 100% Download ausreizt (Was bei 3,8 MBit keine Kunst ist), den DSL Kanal so zu macht, dass bei anderen PC´s kein Surfen mehr moeglich ist (Timeouts). Es wurden einige Balancing Komponenten aus der Firmware entfernt. ! Wenn der Download nur 98% ausnutzt, koennen andere PC surfen, da dann das Balancing funktioniert. Wenn du die Probleme loest zahle ich dir 100 Euro! Der Loetkolben

Was fuer eine Box mit welcher Firmware hast du? Ich bin kein FB Experte, habe/hatte mit einer Fb 7240 massive WLAN Probleme. Z.B. Wenn man ca. 2-3 Wochen nur WLAN mit Smartphone zum eMail Abruf genutzt hatte war alles ok, aber wenn man nach diesen 2-3 Wochen dann ein HD Video auf das Handy streamen wollte machte die Box einen Reset. Danach war erstmal fuer lange Zeit Ruhe. (FritzBox zu sich selbst: "Huch, auf einmal will der User richtig Dampf machen. Da mache ich vorher mal nen Reset.") Wenn man dann wieder wochenlang nur eMails ... und dann erst wieder HD ... dann Reset. Fazit zu den Fritzboxen: Tolle Geraete, aber die Bugs die sie erst bei Langzeitbetrieb zeigen werden nicht geloest. Der Loetkolben

Hallo Tinkerforgeteam, da werde ich mir mal das neue LED Bricklet ansehen. In der deutschen Shopbeschreibung sind noch C&P Fragmente vom Echtzeituhrbricklet. ;-) Bitte mal das vRadiergummi nutzen. Noch was ernsthaftes: Waere es moeglich am Schluss der Tabelle "Technische Spezifikation" im Shop einen Link zur Doku zu setzen. Das nervt ein wenig, wenn man waehrend des stoeberns im Shop etwas nachsehen will und man dazu erst das Bricklet im Dokubereich suchen muss. Danke Der Loetkolben

Das fragen wir uns alle. Hier ein Blick in die Fritz-Glaskugel Re: AVM AP Problem. [War: WLAN Modul defekt? Suche Diagnosetipp] Der Loetkolben

Och. Die scheinen in einem diffusen Gehaeuse zu sein. Das waere prima, wenn sie nicht mehr so start focusieren und das Licht gestreuter austritt. Da lass ich mich mal ueberraschen. Der Loetkolben

Nachdem ich den Thread 3 mal gelesen habe, meine ich verstanden zu haben, dass das Problem deshalb aufkommt, da man beim booten nicht weiss wie viele LED am Strip haengen. Da moechte ich nochmals (m)eine alte Idee ins Spiel bringen wo man die Bricklet Firmware customizen kann. Also per Brickviewer die Anzahl der LED mit in die (kompilierte) Firmware, an eine feste Stelle, schreibt. Damit koennte man auch den Chiptype mit festlegen und den Strip nach dem booten ordentlich initialisieren. BTW: Ebenso koennte man das IO Bricket auf "Out" initialisieren, so dass LEDs nicht leuchten wenn man gebootet hat. Der Loetkolben

Hallo zusammen, mit Freude habe ich gesehen, dass das neue Wifi Modul da ist und man deshalb ein Brickviewer Update machen sollte. Aber das ist immer so ein Aufwand unter Linux, gerade wenn man den Rechner remote bedient. Teilweise hat man die X-Applikation auch nur entfernt per X-forward offen. Zuerst muss man sich die Download URL zusammensuchen, einloggen und dann per console und wget runterladen, sofern man per Remote-Console die URL rueberbekommt. Oder man muss auf dem Remote Rechner einen Browser starten, sofern moeglich, und dann runterladen, console oeffnen, Download suchen und installieren. Hier mein Vorschlag: Waere es nicht moeglich, dass sich der Brickviewer selbstaendig updated? Firefox unter Linux macht das vorbildlich. Alternativ wuerde ich folgende Teil-Verbesserungen vorschlagen: - Der Brickviewer zeigt die Download URL der neuen Version direkt an, so dass man sie fuer wget uebernehmen kann. - Der Brichviewer kann die Datei schonmal runterladen und ggf. per Fileselectbox ablegen - Der Brickviewer kann nach dem runterladen ein xfenster aufmachen und man kann somit bequem das Update eben "eintippen". Das das Autoupdate aufwendig ist verstehe ich, aber ein download und ein oeffnen eines xfensters sollte doch mit 3 Zeilen machbar sein?! Viele Gruesse Der Loetkolben