borg

Helligkeit messen ist halt so eine Sache. Draußen im Sonnenschein sind es 10000 Lux, etwas sehen kann ich vermutlich auch noch bei wenigen Millilux (zumindest wenn das Auge sich an die Dunkelheit gewöhnt hat). Das Ambient Light Bricklet misst bis 900 Lux in 0,1 Lux Schritten, damit kann man natürlich nicht wirklich alles abdecken. Ich vermute man müsste mindestens zwei ganz unterschiedliche Sensoren verwenden wenn man gleichzeitig im Millilux, aber auch im Kilolux bereich messen will. Das wäre sogar eine Überlegung wert, so schrecklich teuer sind diese Sensoren nicht.

Es ist min < x < max: if(((BC->threshold_option[i] == 'o') && ((value < BC->threshold_min[i]) || (value > BC->threshold_max[i]))) || ((BC->threshold_option[i] == 'i') && ((value > BC->threshold_min[i]) && (value < BC->threshold_max[i])))) {

Die blaue LED blinkt wenn Daten übertragen werden. Wenn sie alle 18 Sekunden einmal kurz blinkt würde ich davon ausgehen das eine geringe Menge an Daten übertragen wird .

Von den möglichen Lochrastern müssen wir mal ein paar varianten durchprobieren. Da bin ich mir gerade noch unschlüssig was gut ist. Was haltet ihr davon die Platten anreihbar zu machen? Also dass der Rand von den Platten sozusagen wie ein "Puzzle Teil" aufgebaut ist und man kann mehrere kleine Platten aneinander stecken. Dann könnte man sich auf relativ kleine Halterungen beschränken die zu einer großen zusammengesetzt werden können.

Funktioniert: Sehr Cool! Wenn du irgendwelche Fragen hast oder Hilfestellungen brauchst: Immer her damit. Wenn das irgendwann gut genug funktioniert könnten wir das zum automatisierten testen unserer Bindings benutzen . Vielleicht hat ja auch sonst noch jemand aus der Community lust mitzuhelfen.

Mir würde da auf Anhieb keine Möglichkeit einfallen. Ich könnte auch damit leben wenn (Software-)Brickd dort die Nachricht wegwirft. Aber das Protokoll garantiert einfach nicht, das auf eine Anfrage eine Antwort direkt im nächsten TCP/IP Paket kommt, da kommen wir nicht drumrum. Hat das alte Protokoll übrigens auch nicht... Hat nur so wie Loeti es benutzt hat zufällig funktioniert . Kommt nach LabView .

Ich sehe da jetzt das Problem nicht. Im zweiten Fall wird nichts gebroadcasted weil gar kein Socket mehr auf ist. Wo soll Brickd es denn hinschicken ? Du könntest Brickd mit --debug starten, dann bekommst du viel mehr Ausgaben und es wird evtl klarer was passiert. Wie sollen wir denn die Routing Tabelle in so einem Fall in Ordnung bringen? Die korrekten Informationen sind ja nicht mehr da. Die Funktionsweise ist die gleiche wie die von einem Ethernet Switch.

Warum das? Alle unsere Bindings erkennen das die Nachricht nicht für sie ist und schmeißen sie weg. Falls nun aber ein Fehler in der Routingtabelle entsteht, kommt die Nachricht trotzdem noch an (würde sie nicht wenn Brickd sie wegwerfen würden). Noch mehr Sinn macht das Verhalten wenn die WIFI oder Ethernet Extension benutzt wird: Die Brickd Implementierung auf dem Master Brick hat nur eine vergleichsweise kleine Maximalgröße für die Routing-Tabelle. Dort kann es also passieren das sie "überläuft", dann gibt es das gleiche Verhalten. Warum sollte ich die Nachricht denn da wegwerfen und evtl. unnötige Timeouts erzeugen?

Die Wetterstation ist jetzt im Shop !

The weather station is in the shop now .

Is something connected to the Master Brick? Try to unplug everything from the Master Brick before you connect the USB cable, to make sure that none of the other devices are interfering.

Mh, strange. Did the Master Brick work before you tried to flash it? It is not possible to delete or corrupt the Bootloader. Is there something connected to the Master Brick (Extensions, Bricklets etc)?

There is no USB device connected in the dmesg output. Are you sure that you pressed the Erase Button while you plugged the USB connector in (not after it is plugged in)?

Wenn der Brick im Bootloader ist müsste da bei lsusb stehen: Bus 001 Device 115: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader Zumindest das VID:PID Paar sollte dabei sein (03eb:6124). Für mich sieht es nicht so aus als wäre da ein Brick im Bootloader angeschlossen . Was sagt dmesg?

Are you sure the Brick is in the bootloader? Try to press the erase button while you plug the Brick in via USB. Then type in "dmesg" and post the output here.

Jo, das Lasern der Platte hat ein bisschen länger gedauert als eine komplette Wetterstation . Aber es ging ja nur darum einen schnellen Test zu machen.

Wir haben mal gerade Rapid Prototyping betrieben (siehe Anhang). Funktioniert gut, ist auch auf jeden Fall nicht zerbrechlich oder so .

Könnten wir ausprobieren, die Frage ist wie stabil die Bodenplatte noch ist wenn man im 5mm Raster 3mm Löcher macht. Da bleiben ja nur "2mm Rahmen" über .

Jop. Ist ein bisschen ein Zungenbrecher geworden . Aber dafür gibt es ja die Bilder.

www.tinkerforge.com/de/blog/2013/4/18/neue-befestigungskits

What operating system do you use? Do you see something in the device manager (or via lsusb if you use Linux)?

Das ist komisch. Grundsätzlich sollten alle Bricks im Stack neustarten wenn du auf einem Reset Taster drückst, die Reset-Leitungen sind im Stack miteinander verbunden. Das funktioniert rein elektrisch, hat also nichts mit Software zu tun, wo soll da ein 10s Delay entstehen ? Vielleicht hat Batti morgen noch eine Idee was da passieren könnte. Du musst aber vorher "Enable" anklicken um diese Effekte zu erzeugen? Da passiert nicht schrecklich viel wenn du "Enable" klickst, es wird nur ein PWM gesetzt. Sollte selbst wenn ein Defekt vorliegt keinen Unterschied machen.

Hallo Zusammen, Wir haben jetzt eine vorläufige Version der Dokumentation für das neue Starterkit fertig: http://www.tinkerforge.com/de/doc/Kits/WeatherStation/WeatherStation.html Falls irgendwer Vorschläge für Last-Minute-Änderungen hat: Her damit ! PS: Wir konnten bisher leider die Opak-Weiße Variante nicht zufriedenstellend produzieren. Wir bekommen immer schwarze Streifen in den Ecken (siehe angehängtes Bild). Wir haben daher jetzt erstmal schwarzes PMMA bestellt, d.h. es wird anfänglich vermutlich durchsichtig und schwarz als Farbwahl geben.

Naja der PC ist Brickd in dem Fall. Wir können in der Firmware nicht feststellen wenn du dich bei Brickd abmeldest und neu verbindest, dort bekommen wir das nicht mit. Die einzige Möglichkeit das konsistent zu machen wäre gar kein Enumeration rauszuschicken. Das würde allerdings das Routing erheblich erschweren. Beispiel: Du verbindest ganz viele Bricks per USB an den PC und sendest dann ganz viele Setter um auf den Bricks irgendwas zu setzen. Wenn wir kein initiales Enumerate schicken würden, könnte der Brickd nicht wissen wo die Setter hin müssen und er müsste Broadcasten. Dann hätte man "transparenteres" verhalten, aber unterschiedliche Performance je nachdem wie das kontrollierende Programm aussieht... Ich befürchte das Protokoll und das Enumeration Verhalten machen an dieser Stelle so wie sie sind am meisten Sinn.

Eine Enumeration wird gesendet wenn das erste mal eine Verbindung zum PC aufgebaut wird. Unabhängig vom verwendeten Interface.