m0d

versuche bitte explizit stderr und stdout umzuleiten: * * * * * /home/lpd/aussenwerte.sh >> /home/lpd/aussenwerte.lst 2>&1 --m0d

Gibt es zu der Temperaturdiffernez mittlerweile eine Erklärung oder weitere Informationen? Auch hierzu scheint es noch kein Update zu geben: http://www.tinkerunity.org/forum/index.php/topic,2810.msg17826.html --m0d

Es sollte keinen Unterschied machen, ob Du die Werte mittels Callback oder "GetAirPressure()" abfragst. 930 hPa als untere Grenze ist meiner Meinung nach OK.

@raphael_vogel: Auf welcher Höhe misst Du denn Deine Werte? Als Hinweis, der Wert von 954,4 hPa bezieht sich auf Meereshöhe. Somit kann es lokal durchaus zu Messwerten unter 940 hPa kommen.

Auch ich hatte tw. Probleme mit der Stromversorgung am Raspi. Ein aktiver USB-Hub sollte in diesem Fall Abhilfe schaffen. Das neue Modell des Raspberry Pi (Model B+) wurde u.a. dahingehend überarbeitet und bietet eine stabilere Stromversorgung sowie 4 USB-Ports. --m0d

Wie sieht denn die Ausgabe von lsusb aus? Wird das Gerät selbst erkannt? --m0d

"dpkg" löst Paket Abhängigkeiten (im Gegensatz zu "apt-get") nicht automatisch auf. Eine Möglichkeit wäre hier z.B.: apt-get update && apt-get install pm-utils --m0d

Wie bereits erwähnt gibt es Probleme mit Hard Float, bzw. der HF-Version von Mono. Diese äussern sich auf dem Pi z.B. durch die Ausgabe eines falschen Datums und können wie folgt reproduziert werden: csharp> Console.WriteLine(DateTime.Now); 0/735308/0001 8:18:48 PM csharp> Bei der Soft Float Version von Raspbian konnte ich bisher keine Probleme feststellen. Mittlerweile gibt es jedoch auch eine funktionsfähige HF-Version von Mono http://www.raspberrypi.org/phpBB3/viewtopic.php?f=34&t=62496 --m0d

Versuch's mal damit sudo apt-get install python python-qt4 python-qt4-gl python-qwt5-qt4 python-opengl python-serial pyqt4-dev-tools (http://www.tinkerunity.org/forum/index.php/topic,1770.msg11834.html#msg11834)

kleiner Hinweis, du kannst C# auch auf dem Pi mittels Mono (http://www.mono-project.com/) verwenden. Mono ist als Debian-Paket verfügbar und kann mit apt-get installiert werden. Bei mir läuft z.B. die Erfassung von Wetterdaten auch mit C# auf dem Pi. Probleme hatte ich anfangs mit der Hard Float Version von Raspbian. Mit der Soft-Float Installation läuft jedoch alles problemlos.

Mittels Distance IR Bricklet kann einfach ermittelt werden, ob jm. vor dem Display steht und dann die Beleuchtung eingeschaltet werden, funktioniert super...

Super vielen Dank, jetzt funktionieren beide Bricklets wieder. Es waren in der Tat die Abhänigkeiten (qwt). --m0d

Habe gerade festgestellt, dass das Verhalten beim Rotary Poti Bricklet identisch ist mit dem vom Distance IR Bricklet, beide werden nicht mehr vollständig erkannt. Das GPS-Bricklet am gleichen Port wird jedoch erkannt...

Habe im "Updates / Flashing" Dialog den entsprechenden Port ausgewählt und als Plugin "Distance IR". Das Flashen läuft erfolgreich durch, leider wird das Bricklet noch immer nicht erkannt

Hallo Community, habe seit kurzem Probleme mit meinem Distance IR Bricklet. Das Bricklet wird im Brick Viewer nicht mehr richtig erkannt. Der Brick Viewer zeigt zwar die aktuelle FW Version sowie die UID an, allerdings wird weder der Typ noch der enstsprechende "Reiter" im Brick Viewer angezeigt... Besten Dank für Eure Hilfe, m0d distanceir

Hallo TFler, nachdem im Dezember 2012 bereits Anfragen für eine Neuauflage der Chibi Extension hier im Forum diskutiert wurden und als Termin dabei Mitte 2013 im Gespräch war, würde mich interessieren, wie die Planungen bzgl. einer Neuauflage aussehen. Auch in der Timeline habe ich zum Thema nichts gefunden. Auf eine Neuauflage wartet gespannt, m0d (und vermutlich noch einige mehr )

Auch ich habe noch immer Probleme seit dem Update auf 2.0.1. Hier eine kurze Beschreibung: Stack mit WLAN-Modul und Step-Down Temperatur-, Luftfeuchte-, Luftdruck- und Helligkeits-Bricklets Verbindung: "Access Point: Static IP" Power Mode: "Full Speed" Stack läuft mittlerweile ca. 1 Tag problemlos. Dannach ist der Stack zwar mittels Ping erreichbar, jedoch kann z.B. über den brickv keine Verbindung mehr hergestellt werden. Nach einem Neustart (durch Abschalten des Stroms) ist der Stack wieder erreichbar.

Ein Fehler scheint gefunden: An einem Bricklet-Port waren Pins verbogen, bzw. kurzgeschlossen. Nachdem diese wieder in der richtigen Position sind, haben sich jetzt auch die Mess-Ergebnisse des Barometer-Bricklets (was übrigens _nicht_ am defekten Port angeschlossen war) verbessert. Die Chip-Temperatur liegt jetzt bei ca. 0,3 °C wohingegen der Luftdruck noch relativ stark abweicht. Das Barometer zeigt eine Höhe von ca. 970m - korrekt wäre etwas um 600m. Muss das Barometer-Bricklet noch kalibriert werden?

Die Temperatur des Temperatur-Bricklets stimmt, auch die Luftfeuchte ist meiner Meinung nach korrekt. Was nicht stimmt ist der gemessene Luftdruck des Barometer-Bricklets sowie die Chip-Temperatur des Barometer Bricklets, allerdings nur am Master-Brick der Wetterstation! Werde das noch an einem anderen Port des "Wetterstations-Master-Bricks" testen und berichten...

Hallo zusammen, habe in einer Wetterstation (im Ausseneinsatz) ein Master Brick 1.0 mit Fw 1.4.6 im Einsatz. Temperatur-/ Humidity-Bricklet funktionieren auch soweit. Ein eben angeschlossenes Barometer-Bricklet liefert jedoch an besagtem Master permanent -40 °C als Chip Temperatur zurück. Es ist zwar recht frisch (ca. -6 °C) aber -40 °C stimmt selbst bei Toleranz-Abzug nicht. Schliesse ich das Barometer-Bricklet an einen zweiten Master-Brick 2.0 mit Fw. 1.4.6 an, so stimmt die Chip-Temperatur. Daher vermute ich, dass das Barometer-Bricklet nicht defekt ist. Hat jm. eine Idee wo das Problem liegen könnte? Danke schonmal! --m0d

Bei mir trat das Problem beim Debuggen eines Mono-Projekts auf, nachdem IPConnection Objekte erzeugt aber nicht "Destroy()"t wurden.

konnte das Problem ebenfalls schon nachvollziehen. Bei mir trat das Problem beim Debuggen eines Programms auf, d.h. sofern die "IPConnection" zwar aufgebaut aber nicht wieder korrekt freigegeben wurde. Nach ein paar aufgebauten und nicht freigegebenen IPConnections war eine Verbindung erst wieder nach einem Reset möglich. @borg: Könnten mehrere nicht freigegebene IPConnection-Objekte zu dem Problem führen? Ein IPConnection Objekt könnte ebenfalls nicht freigegeben werden, wenn aufgrund einer schlechten Verbindung keine Kommunikation mit dem Stack mehr möglich ist.

Gab es nicht auch bereits Überlegungen, die Chibi Extension neu aufzulegen, nachdem die WLAN Extension nun funktionsfähig ist? Grundsätzlich scheint das Interesse ja nach wie vor vorhanden zu sein... --m0d

Mir gefällt der Strahlenschutz von thunderbird sehr gut. Dank der genauen Bauanleitung [+1] auch kein Problem beim Nachbau. Allerdings frage auch ich mich, ob ein Korrosionsschutz für die Bricklets bei längerem Außeneinsatz notwendig wird?

Ist eine Funktion geplant, um die Zeit abzufragen? Dann könnte man das GPS-Bricklet zur synchronisation eines NTP-Servers verwenden.