borg

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.

Da kann ich dir nicht zustimmen . Der Source Code ist ja an der Stelle für beide gleich. Eine Enumeration wird losgeschickt wenn das erste mal eine Verbindung zum PC aufgebaut wird. Da wird nicht zwischen Wi-Fi und USB unterschieden. Das in einem Fall der Stapel schon bestromt ist und im anderen nicht hat damit gar nichts zu tun.

Sie verhalten sich gleich. Starte einen Brick Daemon, verbinde dich darauf und steck dann das Brick per USB an -> Du bekommst ein Enumerate. Das gleiche passiert bei der WIFI Extension: Wenn du dich mit der WIFI Extension das erste mal verbindest ist das äquivalent zum einstecken per USB.

Was verwenden die beiden PCs denn für eine CPU?

Kann man erhöhen: http://www.tinkerforge.com/de/doc/Software/IPConnection_Python.html#IPConnection.set_timeout

Ich glaube die KiCad Bauteilenamen sind schon das was am ehesten an eine BOM herankommt. Wenn dir spezifische Bauteile nicht klar sind frag einfach nach. Die Stecker werden zum Teil spezifisch für uns hergestellt, die gibt es dafür aber auch bei uns im Shop zu kaufen. So eine BOM mit DigiKey Artikelnummer oder so (zum direkt selber Bestellen) haben wir leider nicht. Dafür kaufen wir auch bei zu vielen unterschiedlichen Distributoren ein.

Du hast recht! Da ist in der Tat ein Fehler in der Dokumentation, fixen wir gleich . Danke für den Hinweis.

I will add a sentence somewhere, but there is not much to it. If the "tick task" is not called once in 16 seconds, the Brick will restart (the tick task is normally called every ms).