photron

Die Höhe wird über die Luftdruckdifferenz bestimmt. Der Referenzluftdruck gegen den die Differenz berechnet wird kannst du im Brick Viewer auf dem Barometer Tab bei "Referenz Air Pressure" einstellen. Standardmäßig wird da 1013,25mbar verwendet, dass ist der Standardluftdurck auf Meereshöhe. Da sich jetzt aber der wirkliche Meereshöhenluftdruck für deinen Ort auch ständig wetterabhängig ändert ist diese "absolute" Höhenberechnung auch wetterabhängig. Das das um 100m daneben liegen kann ist normal. So verhält sich der Luftdruck. Dass das über längere Zeiträume (im Bereich mehrere Minuten) um 2m schwankt ist schon viel aber noch nicht ungewöhnlich. Kurzfristig sollte die Höhe nur im 5-10cm Bereich schwanken. Wenn du beim "Referenz Air Pressure" 0 einträgst und dann "Set" klickst setzt das Bricklet intern den Referenzluftdruck auf den gerade gemessenen Luftdruck. Dadurch wird auch die Höhe auf 0 gesetzt, da die Luftdruckdifferenz dann 0 ist. Da sich aber der Luftdruck ständig ändert schwankt de Höhenberechnung natürlich weiterhin und kann sich auch auch über den Tag hinweg um mehrere 10m ändern. Fazit: Dein Bricklet funktioniert richtig und Luftdruck verhält sich so.

Nein, die Bricks erkennen beim Neustart was wo angeschlossen ist. Das einzige was es in diese Richtung gibt ist, das brickd standardmäßig nicht Callbacks an alle verbundenen IP Connections weiter gibt, sondern nur an die die vorher GetStackID aufgerufen haben, dies passiert aber automatisch in allen Bindings. Das betrifft dich hier aber nicht und das wird auch mit Protokoll Version 2 anders, da wird da brickd und das Protokoll an sich stateless machen werden so dass es robuster wird.

Damit ich sehen kann ob das Bricklet wirklich die neue FW hat. Hmm lass mich mal ueberlegen. ... Wuerde nach einem flashen des Bricklets der Brickviewer die neuen Firmwarestaende automatisch einlesen sobald sich der Masterbrick mit dem brickd wieder verbunden hat? Ne, oder? Doch genau so passiert das. Wenn du den Brick durch den Reset Knopf in brickv, oder per Reset Knopf auf dem Brick selbst oder durch Ab- und Anstecken des USB Kabels neustartet, dann sieht das für brickd und brickv immer gleich aus. Der Brick verschwindet als USB Device und taucht dann kurze Zeit später wieder als USB Device auf. brickd weiss nicht, dass das der gleiche Brick ist und das braucht er auch nicht. brickd und brickv cachen da nichts. brickv bekommt das Reset/Abstecken durch ein enumerate mit is_new=false mit und das Neuauftauchen als enumerate mit is_new=true. Dann liest brickv auch die Versionsinformationen neu aus. Das heißt in deinem Fall reicht ein Reset des Bricks aus. Du musst nicht neu zu brickd verbinden. Dennoch würde ich gerade dein Reconnect Problem verstehen und beheben. Nur ist mir hier gar nicht klar wie ein Reconnect zu brickd dazu führt, dass der Brick auf USB Ebene ein Problem hat und verschwindet. Komplettes brickd.log. Es ist kein Debugging eingeschaltet. Wenn ich das richtig sehe kommen diese Meldungen und vom reboot der Maschine als der brickd versuchte sich zum Brick zu connecten. Ein "/etc/init.d/brickd start" erzeugen die gleichen Meldungen nochmal. Traceback (most recent call last): File "/usr/share/brickd/brickd_linux.py", line 157, in <module> brickd.daemonize() File "/usr/share/brickd/brickd_linux.py", line 145, in daemonize self.start() File "/usr/share/brickd/brickd_linux.py", line 85, in start reactor.listenTCP(config.PORT, BrickProtocolFactory()) File "/usr/lib/python2.6/dist-packages/twisted/internet/posixbase.py", line 419, in listenTCP p.startListening() File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 855, in startListening raise CannotListenError, (self.interface, self.port, le) twisted.internet.error.CannotListenError: Couldn't listen on any:4223: [Errno 98] Address already in use. Nein, das hat nichts mit dem Brick oder USB zu tun. Das Problem hier ist das brickd versucht den TCP/IP Socket auf Port 4223 zu öffnen und jemand auf diesem Port schon einen Socket offen hat. Wahrscheinlich läuft schon ein brickd und du versuchst noch einen zu starten?

Antwort zwischendurch. Nein. Es kann sein, dass von einem Server ausserhalb die Sensoren per Cron (TCP/netcat) abgefragt werden. Alle 10 Minuten ein Request, also kein Dauerrequest. Ein Enumerate wird nicht durchgefuehrt. Okay, ich hätte jetzt gehofft du hättest genau das Problem das ich im Rahmen der Vorbereitung für die Elektor Live gefunden und behoben habe. Das Problem war das wenn 2 Clients/Bindings recht zeitgleich ein GetStackID für das gleiche Device ausgeführt haben, dass ihre intern Datenhaltung dann durcheinander geraten ist. Da GetStackID ein Braodcast ist wird auch die Antwort an alle geschickt und beide Clients bekommen die Antwort zweimal. Das kann dann u.a. dazu führen, dass der Brick in brickv nicht angezeigt wird, da brickv dadurch beim Aufzählen des Bricks eine Exception bekommt. Dieser gleichzeitige Aufruf von GetStackID für das gleiche Device kommt typischerweise durch die Verwendung von Enumerate zustande. Da das bei dir aber nicht der Fall ist und du auch nicht von 2 Clients GetStackID aufrufst hast du noch ein anderes Problem Erinnert mich daran, dass ich die korrigierte brickd Version releasen sollte. Kommt morgen

Okay, ignoriere erstmal alles was ich da noch gerade gefragt habe und beantworte mir die nächste Frage zu erst. Debian -- Brickv.1.1.13 -- LAN -- Debian -- Brickd -- USB -- Master1.4.0 Hast du in diesem Aufbau noch ein weiteres Programm neben brickv, dass gleichzeitig mit brickd verbunden ist und mit enumerate arbeitet?

Welche brickd Version ist das? Warum reconnectest du hier? Das ist ja hier nicht notwendig. Die Verbindung um die es da geht, ist die TCP/IP Verbindung zu brickd, nicht die USB Verbindung von brickd zum Master Brick. Hab das hier gerade nachgestellt und es funktioniert wie erwartet. Und was meinst du mit "weg"? Wird der Brick nicht mehr in brickv angezeigt? Wenn du erneut reconnectest taucht er dann wieder auf? Gibt es eine Exception in brickv? Kennt lsusb ihn noch? Was sagt das brickd Log dazu? Beim Connect broadcastet brickv einen Enumerate Request an alle und dann noch ein GetStackID an alle Devices die Enumerate aufzählt. Ich sehe nicht warum das ein Problem wie das hier erzeugen sollte. Welche Kommunikation? Welche Versionen? Firmware, brickd oder brickv? Reset und (Dis)connect sind zwei sehr verschiedene dinge für einen Brick. Der Brick an sich hat mit dem (Dis)connect zu brickd nichts zu tun! Nein, da das nichts mit einander zu tun hat und das auch nicht sinnvoll ist im Allgemeinen.

Ich spalte das hier mal in einen neuen Thread ab.

Standa hat recht die Geräusch sind unbedenklich, wohl aber unschön. Du könntest im Stillstand einfach den Stepper Brick disablen. Wenn das in deinem Fall nicht möglich ist, weil der Motor aktive eine Position halten muss dann kannst du versuchen den Decay Modus passender zu deinem Motor einzustellen. Standardmässig wird Fast Decay verwendet, das ist die sichere Variante. Es gibt im Brick Viewer keinen Regler für den Decay Modus da es bei großen Motoren bei "falschem" Decay Modus zur Überhitzung und Zerstörung des Bricks kommen kann. Mit 1,2A hast du da aber einen Motor bei dem du ohne Problem mit dem Decay Modus experimentieren können solltest. Dazu musst du dann allerdings dann dein eigenen Programm schreiben und über die SetSyncRect Funktion des Stepper Bricks die Synchrongleichrichtung aktivieren und kannst dann über SetDecay zwischen Fast, Mixed und Slow Decay einstellen.

Es gibt Hot, Warm, Cold und Full Cold Start. Je kälter desto weniger zwischengespeicherte Daten wie die Satellitenflugbahnen und die Uhrzeit werden nach dem Neustart wiederverwendet. Mit Enums für Magicnumbers geb ich dir recht und setzte es mal auf die TODO Liste. Dass get_date_time ein DateTime-Objekt zurück gibt wird allerdings nicht passieren in absehbarer Zeit. Da ist das Feld der Möglichkeiten einfach zu groß als das man das im Generator sinnvoll unterbringen könnte.

Wir haben noch mal das GPS Modul gewechselt. Das neue Modul bekommen wir dann auch mit einem Binärprotokoll, das einfacher zu parsen ist. Dadurch ist jetzt auch wieder Platz freigeworden und wir könne GetStatus aufteilen, wie das hier schon vorgeschlagen wurde. Die aktuelle API ist hier zu finden: http://www.tinkerforge.com/doc/Software/Bricklets/GPS_Bricklet_C.html Neben der Aufteilung von GetStatus gibt jetzt GetCoordinates auch den Estimated Position Error (EPE) zurück.

skippi, dass brickd Problem haben kann wenn ihm der RAM ausgeht kann ich verstehen. Warum da aber irgendwie das Neuflashen von Bricks einen Effekt haben soll sehe ich nicht.

Hast du denn das Bricklet neugeflashed?

Alle Bricklets funktionieren an allen Ports aller Bricks. Da gibt es keine Einschränkungen. Da das Problem hier durch neu Flashen des IO-4 Bricklets gefixed wurde, würde ich vermuten, dass das im EEPROM des Bricklets gespeicherte Plugin eine Macke hatte. Das würde auch erklären, warum das Problem an 2 Master Bricks auftrat. Warum es dann nur am Master Brick und dann auch noch von Port und der Extension Konfiguration abhängt ist nicht klar. WIFI braucht mindestens Master Firmware 1.3.0, das ist auch so dokumentiert (auch im Shop). Hattest du zu dem Zeitpunkt eine ältere Firmware verwendet?

Die Kalibrierung für den Sensor wird im EEPROM auf dem Bricklet gespeichert. Die kannst du mittels Brick Viewer ändern, siehe: http://www.tinkerforge.com/doc/Hardware/Bricklets/Distance_IR.html#spannung-distanz-abbildung-speichern

Die MSDN Knowledge Base sagt, dass Windows 8 und Windows 7 (seit Mai 2012) automatisch den passenden Treiber installieren können, wenn ich das USB Gerät korrekt als WinUSB kompatible ausgibt. Wir verwenden WinUSB über libusb, daher sollte das gehen. Ich habe das testweise funktioniert und der Brick sollte sich jetzt als WinUSB kompatible ausgeben können. Leider funktioniert das noch nicht so richtig wie es soll. Bis dahin kann ich dir den WinUSB Driver Installer Zadig von den libsub Entwicklern als Lösung anbieten. Dieser kann unter Windows 8 einen passenden und signierten Treiber installieren. http://download.tinkerforge.com/_stuff/zadig_v2.0.1.159.exe Wenn du das startest sollte das etwa so aussehen: Wichtig ist dabei, dass das richtige Device ausgewählt ist (hier 'Master Brick') und WinUSB als Treiber. Dann 'Install Driver' klicken. Möglicherweise musst du dann noch einmal den Brick ab und wieder anstecken, damit er dann erkannt wird.

Ich kann das Problem hier reproduzieren. Eine Lösung ist in Arbeit.

Das ist eine sinnvolle Idee. Ich habe dazu gerade den ersten Schritt getan und alle Funktionen in den Configs mit ihrer "minimumRequiredFirmwareVersion" versehen. Als nächsten kommen, dann Checks dafür in den Bindings.

Sollte jetzt funktionieren.

Der Zeichensatz des LCDs ist fest und damit auch die Ausrichtung der Zeichen. Es ist daher rein technisch nicht möglich die Zeichen auf den Kopf zu drehen.

1. Nein, das geht nicht. 2. Ich nehme mal an du machst das im Moment so oder so ähnlich: lcd.WriteLine(0, 0, "Joystick: " + x + ", " + y); Da die Darstellung von x maximal 4 Zeichen (-100) bis 1 Zeichen (0) lang sein kann, musst du nur 3 extra Leerzeichen anhängen um bei x = 0 die restlichen 3 Zeichen zu "löschen". Da ich hier x und y in einer Zeile habe macht das 6 Leerzeichen, also: lcd.WriteLine(0, 0, "Joystick: " + x + ", " + y + " "); 3. Du musst einfach durch 10.0 (float) statt durch 10 (int) teilen: lcd.WriteLine(0, 0, "Temperature: " + t / 10.0);

Brick Daemon 1.0.10 Enable non-root usage on Linux Avoid potential data corruption in python-libusb1 Downloads: Windows, Linux, Mac OS X

Brick Daemon 1.0.10 Kann jetzt als nicht-root User unter Linux gestartet werden Mögliche Datenkorruption in python-libusb1 vermieden Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.13 Switch from green to dark green in graphs for better contrast on gray Show Barometer Bricklet altitude also in feet Fix progress dialog for Bricklet flashing Handle old names for Temperature IR and Distance IR Bricklets in Check-for-Updates dialog Automatically restore IMU factory calibration after flashing Improve flashing verification speed by reading whole flash pages Improve progress dialog for firmware and plugin discovery in flashing window Add basic FreeBSD support Add button to restore factory calibration to IMU calibration window Add missing image for Dual Replay Bricklet plugin Downloads: Windows, Linux, Max OS X

Brick Viewer 1.1.13 Grün durch Dunkelgrün in Graphen ersetzt Barometer Bricklet Höhe wird nun auch in Fuß angezeigt Fortschrittsanzeige beim Flashen von Bricklets verbessert Alte Namesversionen des Temperature IR und Distance IR Bricklets beim Check-for-Updates werden richtig behandelt IMU Werkskalibrierung kann nach dem Flashen automatisch wiederhergestellt werden Geschwindigkeit des Verifikationsschritts beim Flashen beschleunigt Fortschrittsanzeige bei der Abfrage der verfügbaren Firmware und Plugin Versionen verbessert Grundlegende FreeBSD Unterstützung Knopf zum automatischen Wiederherstellen der Werkskalibrierung zum IMU Kalibrierungsfenster hinzugefügt Fehlendes Bild zum Dual Replay Bricklet Plugin hinzugefügt Downloads: Windows, Linux, Max OS X

Bindings: C/C++ 1.0.23, C# 1.1.15, Delphi 1.0.7, Java 1.0.21, PHP 1.0.16, Python 1.0.24, Ruby 1.0.13 Add get_usb_voltage function to Master Brick API [All] Add Barometer Bricklet examples [All] Handle difference between currentThread and current_thread to support Python 2.5 [Python] Changed callback_queue from class variable to instance variable [Python] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby