borg

Plugins: LCD 20x4 1.1 Bricklet 2.0.6, LCD 20x4 1.2 Bricklet 2.0.6 LCD 20x4 Firmwares in HW Version 1.1 und 1.2 getrennt. Dadurch ist kein Auto-Update für das LCD 20x4 Bricklet mehr möglich. In der nächsten Brick Viewer Version wird das Auto-Update wieder funktionieren. Download Plugin: LCD 20x4 1.1 Bricklet, LCD 20x4 1.2 Bricklet

Plugins: LCD 20x4 1.1 Bricklet 2.0.6, LCD 20x4 1.2 Bricklet 2.0.6 Split Firmware in HW Version 1.1 and 1.2 This breaks Auto-Update for LCD 20x4 Bricklet. Auto-Update for LCD 20x4 Bricklet will work again in next Brick Viewer Version. Download Plugin: LCD 20x4 1.1 Bricklet, LCD 20x4 1.2 Bricklet

Firmwares: Stepper Brick 2.0.3 Fehler in UnderVoltage Callback gefixt (falsche FID) Download: Stepper Brick

Firmwares: Stepper Brick 2.0.3 Fix bug in under voltage callback definition (wrong FID) Download: Stepper Brick

Spannungsabfall ist da jetzt nicht direkt ein Problem. Aber ein 20m Kabel ist ja auch eine 20m Antenne, da kann man sich natürlich beliebige Störungen einfangen. Ich befürchte da kann man keine genauen Werte geben (X meter geht, Y meter geht nicht), das wirst du ausprobieren müssen .

Hast du das .jar denn bei bluej hinzugefügt? http://stackoverflow.com/questions/12902466/how-can-i-compile-code-that-uses-a-jar-file-class-with-bluej?answertab=votes#tab-top

Dann musst du das LCD einmal "hotpluggen". Also Master anschließen, mit dem Brick Viewer schonmal in das passende Menü gehen und alles auswählen, dann das LCD am passenden Port anschließen und neu flashen und dann den Master neustarten.

Die 8 Symbole werden mit 8-15 addressiert, nicht mit 0-7. 0-7 konnten wir nicht nehmen, da die 0 das String-Ende kennzeichnet. Das 1-7 funktionieren ist zufall .

Hast du diesen Thread schon gesehen: http://www.tinkerunity.org/forum/index.php/topic,1171.0.html ?

Kannst du ruhig wieder anlöten, aber vorher das Distance IR Bricklet vom Brick abklemmen .

Der Nutzen ist das schöne Aussehen . Zum einen gibt es Tischaufbauten, wo ein Brick und ein paar Bricklets einfach auf dem Schreibtisch neben dem Monitor liegen, das sieht mit Gehäuse einfach schöner aus. Oft ist vielleicht auch der eigentliche Aufbau in einem Gehäuse, aber das eine oder andere Bricklet muss außerhalb sitzen. Es gibt aber auf jeden Fall reichlich Nachfrage nach Gehäusen dieser Art , gibt auch schon irgendwo hier im Forum einen ellenlangen Thread mit Gehäuse-Ideen und Daten zum 3D-Drucken von Gehäusen für Bricks.

@Jan: Wir wollen keine Gehäuse anbieten die für 230V Anwendungen gedacht sind. Dafür gibt es günstige kleine Schaltschränke bei Reichelt o.ä. die exakt für solche Zwecke da sind.

@Loetkolben: Das Gehäuse ist natürlich nicht dafür da um es in ein Kinderzimmer zu stellen, bei einer 230V Verkabelung gehört das zusätzlich immernoch in einen Schaltschrank o.ä. Wegen des Preises müssen wir noch gucken, woanders festmachen kannst du es nach unten hin über die Abstandsbolzen. Anstatt der Schraube unten Abstandsbolzen rein und dann darüber wieder festschrauben. Alternativ natürlich direkt mit längeren Schrauben. Das Prinzip ist so erstmal nur für die Bricklets zu gebrauchen. Was meinst du mit Nasen? Die Dinger nach unten sind Füße, damit du dir den Tisch o.ä. nicht mit den Schrauben zerkratzt die unten rausgucken .

Da das Gehäuse der Wetterstation im Allgemeinen gut angekommen ist, haben wir vor auch für die Bricks/Bricklets auf Dauer Gehäuse in dieser Bauart anzubieten. Den ersten Prototypen haben wir für das Dual Relay Bricklet gemacht, da ist ein Gehäuse sicherlich am sinnvollsten. Anbei ein paar Bilder, die Fotos sind auf die schnelle nichts geworden, hab einfach ein paar Screenshots aus FreeCAD mit reingehängt damit klar ist wie das funktionieren soll. Was meint ihr?

Bug is fixed, see here: http://www.tinkerunity.org/forum/index.php/topic,674.msg10881.html#msg10881

Wir sind gerade dabei die Dokumentation von cosm auf Xively umzustellen, ist gleich fertig. So eine unnötige arbeit... und dann ist der neue Name auch noch schwieriger als der alte .

Beispiel dafür gibt es hier: http://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Rugged/Tutorial.html

Ah verstehe, das geht am besten mit dem Analog In Bricklet (oder auch Voltage/Current Bricklet) mit den "threshold callbacks": http://www.tinkerforge.com/de/doc/Software/Bricklets/AnalogIn_Bricklet_Java.html#BrickletAnalogIn::setVoltageCallbackThreshold__c.short-.short- Da gibt es sogar ein Beispiel für: http://www.tinkerforge.com/de/doc/Software/Bricklets/AnalogIn_Bricklet_Java.html#threshold

Exakt! Es geht dabei einfach nur ums rauschen: Die erste hälfte ist mit Default-Mittelwert-Parametern und die zweite Hälfte hat alle Parameter auf 0. Bei einer Wetterstation will man das ganze rauschen nicht sehen, da ändert sich dann ja ständig der Wert und man kanns kaum noch ablesen. Wenn man jetzt aber die Sensordaten mit den IMU Daten oder anderen Sensoren fusionieren will (z.B. mit einem Kalman-Filter) sind die gemittelten Werte nicht so gut zu gebrauchen, weil sie schon mehrere ms alt sind und gar nicht mehr zu den anderen Sensoren passen.

Worüber bestimmst du denn die Bodenfeuchtigkeit und welches Bricklet nutzt du dafür? Der Master Brick selbst kann ja nicht direkt die Bodenfeuchte messen .

Also die alte Firmware hatte fest einen Mittelwert der Länge 10 und einen gleitenden Mittelwert der Länge 25. Der gleitende Mittelwert wird auf den Mittelwert angewendet. Warten musst du nicht, du bekommst halt solange den alten Wert zurückgegeben bis ein neuer berechnet wurde . Die maximale Länge des gleitenden Mittelwerts ist 25 weil wir nicht mehr Platz auf dem Bricklet haben für mehr. An und für sich wäre für Wetterstationen ein noch größerer gleitender Mittelwert sinnvoll. Mit dem zusätzlichen "normalen" Mittelwert bekommt man halt noch mehr rauschen raus. Einmal als Klarstellung: Die neue Firmware verhält sich genauso wie die alte Firmware wenn man am Averaging nicht rumstellt. Am Averaging rumstellen sollte man nur wenn eine Latenz in der Größenordnung von 20ms zu hoch ist. Welche Werte dann gut sind muss man ausprobieren, ich denke es wird in solchen Fällen meistens Sinn machen alles auf 0 zu stellen.

Wenn z.B. die Länge des Mittelwertes 10 ist, werden 10 Luftdruckwerte aufsummiert und dies Summe wird dann durch 10 geteilt. Anzahl der Werte über die gemittelt wird, genau . Zusaetzlich zu was? Zum Mittelwert? Was ist ein gleitender Mittelwert? Wie kann ich das ohne Mathestudium das verstehen? Wie muessen die Zahlen zueinander stehen? Kann das jemand an einem Beispiel erklaeren? Bei dem normalen Mittelwert summiere ich immer 10 Werte, bilde darüber den durchschnitt, summiere 10 neue Werte, bilde Durchschnitt usw. Bei dem gleitenden Mittelwert speicher ich 10 Werte, bilde den Mittelwert, füge einen neuen Wert hinzu, entferne den letzten Wert, bilde den Mittelwert, füge einen neuen Wert hinzu usw. Wie du das am besten einstellst: Für eine Wetterstation o.ä. einfach auf Default lassen. Wenn die Werte des Barometers in einem "Sensorfusion-Algorithmus", z.B. mit dem IMU Brick verwendet werden sollen, muss die Mittelwertbildung verkleinert werden. Sonst haben wir zuviel Latenz um sehr gute Ergebnisse zu erzielen. Spoiler: Zur Sensorfusion mit den IMU Daten wird es bald ein Beispiel (vielleicht sogar ein Kit) geben .

Firmwares: IMU Brick 2.0.2 Orientierungs-Berechnung an/aus API hinzugefügt I2C Kommunikation synchron Plugins: Barometer Bricklet 2.0.1 API für Konfiguration der Mittelwertbildung hinzugefügt Download Firmware: IMU Brick Download Plugin: Barometer Bricklet

Firmwares: IMU Brick 2.0.2 Add orientation calculation on/off API make i2c communication synchronous Plugins: Barometer Bricklet 2.0.1 Add API for configuration of averaging parameters Download Firmware: IMU Brick Download Plugin: Barometer Bricklet