photron

LukasRtM, hat der Master Brick vorher funktioniert? Hast du diesen Master Brick vorher flashen können? Hast du ein anderes USB Kabel probiert?

Richtig, set-value mit 0 macht alle Relais aus, da set-value immer alle Relais setzt. Wenn du jetzt nur ausgewählte Relais setzen willst ohne andere zu beeinflussen kannst du set-selected-values nehmen. Das nimmt zwei Bitmasken als Parameter. Mit der ersten wählst du welche Relais du überhaupt schalten möchtest und mit der zweiten bestimmst du wie diese geschaltet werden. Wie bereicts bekannt: Relais 0 einschalten, alle anderen ausschalten: 20 = 1 tinkerforge call industrial-quad-relay-bricklet $uid set-value 1 Jetzt Nur Relais 3 einschalten, die anderen nicht ändern: 23 = 8 Mit 8 wird Relais 3 ausgewählt und auch eingeschaltet: tinkerforge call industrial-quad-relay-bricklet $uid set-selected-values 8 8 Nur Relais 3 ausschalten: tinkerforge call industrial-quad-relay-bricklet $uid set-selected-values 8 0 Mal was komplexeres: Relais 0 ausschalten und gleichzeitig Relais 1 ein. Dazu beide auswählen (20 + 21 = 3) und schalten (21 = 2): tinkerforge call industrial-quad-relay-bricklet $uid set-selected-values 3 2

BuddaKaeks, unter Windows 8 brauchst du keinen extra Treiber. Der der bei brickd und brickv dabei ist für Windows 7 und älter. Windows 8 bringt den Treiber schon selbst mit. Schließt ihr die Bricks an USB 3.0 an? USB 3.0 Abschlüsse sind typischerweise innen blau. Wenn ja, was für USB 3.0 Host Controller sind im Geräte Manager unter USB-Controller aufgeführt? Nachtrag: Egal ob es USB 3.0 ist oder nicht, ich hätte gerne einmal einige Details zum USB Host Controller und zum USB Root Hub aus dem Geräte Manager. Im Eigenschaften Dialog gibt es einen Details Tab. Da interessieren mich die Werte für folgende Eigenschaften: - Hardware-IDs (erste Zeile genügt) - Geräteklasse - Geräteinstanzpfad - Busverhältnisse - Klassenkurzname Ich vermute, das libusb ein Problem hat den Brick zu finden, weil der USB Root Hub intern anders benannt ist als libusb das erwartet.

Ich habe mir das jetzt mal angesehen und werde aus dem brickv Crash nicht so recht schlau. Ich kann es zum Absturz bringen indem ich auf dem Stepper Brick Tab das Häkchen bei Enable aus machen. Der Backtrace dazu in GDB geht bis dies in die Qt Library rein. Was das genaue Problem ist nicht direkt offensichtlich. Allerdings ist mir auch etwas in brickd aufgefallen. Ubuntu 13.10 bringt libusb 1.0.16 mit. Mit dieser Version kann libusb selbst auf USB Hotplug reagieren. Da libusb das vorher nicht konnte hat sich brickd bisher selbst darum gekümmert. Das Problem daran ist, da jetzt beide auf UEvents des Kernels lauschen gibt es ein Race zwischen brickd und libusb wer den UEvent für ein eingestecktes USB Gerät zu erst sieht. Wenn libusb ihn zuerst sieht dann ist alles gut. Aber wenn brickd ihn zuerst sieht und dann libusb nach der Liste der USB Geräte fragt, dann liefert libusb eine veraltete Liste zurück und brickd findet das neu eingesteckte USB Gerät nicht. Daher wird es in kürze eine neue brickd Version geben, die erkennt ob libusb Hotplug kann und sich dann auf libusb verlässt anstatt selbst libudev (Linux) oder IOKit (Mac OSX) dafür zu verwenden. Damit ist dann diese Problem behoben.

Das sollte möglich sein, du brauchst halt nur eine passenden Coss-Compiler Toolchain, selber hab ich das noch nicht gemacht. Hier wird z.B. beschrieben wie man sich das baut: http://www.gurucoding.com/en/rpi_cross_compiler/index.php Google "cross compile from windows for raspberry pi" wirft noch mehr Anleitungen raus.

Wir rechnen im Moment damit, dass es noch mindestens 6 Wochen bis zur Veröffentlichung dauern wird. Ein LED Strip Bricklet wird dann bis zu 320 LEDs ansteuern können.

Eigentlich steht alles in der Anleitung die du verlinkt hast drin. Auf der Tinkerforge Seite braucht du brickd und die Shell Bindings. Brickd hast du schon installiert, was dir noch fehlt sind die Shell Bindings: http://www.tinkerforge.com/de/doc/Software/API_Bindings_Shell.html#api-bindings-shell In deren Zip findest du ein Python Script namens tinkerforge. Das du dann auf deinem Raspberry Pi wie beschrieben startest: tinkerforge listen --enable-execute Damit du das so staten kannst musst du das Skript z.B. nach /usr/local/bin kopieren. Du kannst es aber auch direkt aus dem Verzeichnis starten in dem du es entpackt hast, musst dann aber ein ./ vorhängen: ./tinkerforge listen --enable-execute Port 4223 ist nicht richtig in der NetIO App. 4223 ist der Port für brickd, NetIO kann aber nicht direkt mit brickd kommunizieren. Dafür öffnet tinkerforge listen Port 4217 und kümmert sich um die Übersetzung zwischen den Textbefehlen die NetIO senden kann und dem binären Protokoll dass brickd spricht. Soll heißen Port 4217 wie in der NetIO Demo schon angegeben muss so bleiben.

Nein, kein Problem mit Windows 8 bekannt, das sollte direkt funktionieren. Taucht der Master Brick im Geräte-Manager auf? Dort sollte in der Kategorie USB-Geräte ein Master Brick sein.

Alle 3 Barometer Bricklets haben das gleiche Problem. Die SDA Leitung des I2C Busses ist nicht mehr mit dem Sensor IC verbunden. Wenn ich eine Drahtbrücke zwischen Bricklet Stecker SDA Pin und Sensor IC SDA Pin löte funktioniert es wieder. Scheint in Problem mit der Leiterplatte zu sein.

Hm, aus Python heraus ein Segfault in Qt. Spontan würde ich sagen, dass das ein Bug in Qt selbst ist, bzw in PyQt ist und nicht in brickv, aber ich mag mich täuschen. Ubuntu 13.10 ist ja auch noch in Beta, also nicht soo verwunderlich. Warum das gerade beim Stepper Brick auftritt kann ich aus dem Stegreif heraus nicht sagen. Muss ich mir mal genauer ansehen.

Prinzipiell hast du recht, das hätte bool statt uint8_t sein sollen. Aber es ist jetzt eigentlich zu spät das noch zu ändern. Denn das würde die API brechen und das wollen wir eigentlich vermeiden.

Ich hab da mal einen Satz zu geschrieben.

Das ist komisch. Versuch mal den Erase Knopf gedrückt zu halten und dabei das USB Kabel einstecken. Der Microcontroller geht in den Bootloader Modus, wenn beim Starten der Erase Knopf gedrückt ist. Dabei kann das (Neu-)Starten durch Reset Knopf drücken oder USB Kabel einstecken passieren.

Der Sensor des Barometer Bricklets ist über I2C angebunden und stellt einen Druck- und Temperaturwert, sowie Kalibrierungswerte zum Auslesen bereit. Diese müssen nach einer im Datenblatt spezifizierten Formel verrechnet werden, um den richtigen Druck- und Temperaturwert zu bestimmen. Auf dem Humidity Bricklet verwenden wir den HIH-5030 Sensor. Dieser gibt einen Spannung aus die die gemessene Luftfeuchte repräsentiert, sonst nichts. Hier ist also prinzipiell keine Temperaturwert zu holen.

Richtig, ist korrigiert, danke für den Hinweis.

Das ist jetzt unerwartet, dass die Werte bei 10, -40, 0 blieben. Melde dich mal bitte per Email (info@tinkerforge.com).

Scheint also wirklich der Sensor ein Problem zu haben. Wirklich ungewöhnlich, dass das gleich mit zweien zu gleichen Zeit passiert. Hast du beide Stationen schon ähnlich lange in Betrieb, sind also beide Bricklets schon ähnlich lange in Benutzung? Ich habe mal die CRC Prüfung rausgenommen im angehängten Plugin. Kannst du mal testen, was das ändert? Ich würde erwarten, dass du jetzt wieder Werte bekommst die aber stark neben der Wirklichkeit liegen, weil die Kalibrierungsdaten korrupt sind, oder auch die rohen Messwerte an sich nicht richtig ausgelesen werden können. barometer-bricklet-no-crc-check.bin

10 mbar, -40 °C und 0 m zeigen ein Problem mit der Kalibrierung des Sensors auf dem Barometer Bricklet an. Der Sensor ist vom Hersteller kalibriert. Diese Kalibrierung wird zusammen mit einer CRC Prüfsumme auf dem Sensor gespeichert. Das Bricklet liest beim Start die Kalibrierungsdaten samt Prüfsumme aus und kontrolliert, ob die Prüfsumme passt. Wenn sie nicht passt, dann wird dauerhaft 10 mbar, -40 °C und 0 m ausgegeben. Das kann jetzt bedeuten, dass der Sensor auf deinem Barometer Bricklet defekt ist, bzw. die Kalibrierungsdaten korrupt sind. Ist mir aber noch nicht untergekommen, wenn ich mich richtig erinnere. Es kann aber auch bedeuten, dass die I2C Kommunikation zwischen Sensor und Brick gestört ist. Da das Bricklet aber noch auftaucht, kann dessen EEPROM noch per I2C angesteuert werden. Wodurch ein generelles I2C Problem unwahrscheinlich ist. Ein paar Fragen und Vorschläge ins Blaue dazu: - Ist das Bricklet alleine am Master Brick, bzw funktioniert es wenn es alleine ist? - Haben die Stecker an Brick und Bricklet verbogene Kontakte? Auch wenn das unwahrscheinlich ist, da das EEPROM funktioniert. - Ein anderes Bricklet Kabel, anderen Port am Brick, anderen Brick testen (auch unwahrscheinlich als Ursache, aber dennoch) - Auf dem Bricklet sind auch noch alle Bauteile vorhanden? http://www.tinkerforge.com/de/doc/_images/Bricklets/bricklet_barometer_vertical_800.jpg

Den "richtigen" Luftdruck gibt es ja so erstmal nicht Es kommt darauf an was du tun willst. Wenn du das Barometer Bricklet für meteorologische Zwecke verwenden willst und den Luftdruck wie auf Wetterkarten üblich darstellen willst, dann ist QFF Wert das richtige für dich. Diesen hast du schon ja schon nach der barometrischen Höhenformel bestimmt. Den Referenzluftdruck benötigst du nur, wenn du das Barometer Bricklet zur Luftdruck-basierten Höhenmessung verwende willst, wie FlyingDoc schon richtig erklärt.

Alle Funktionen der C/C++ Bindings geben einen int zurück. Dies ist ein Fehlercode, nicht der aktuelle Zustand des Quad Relays. Siehe http://www.tinkerforge.com/de/doc/Software/Bricklets/IndustrialQuadRelay_Bricklet_C.html#api Getter geben Werte in Variablen zurück. Du übergibst industrial_quad_relay_get_value einen Pointer auf ein uint16_t Variable und dahin schreibt die Funktion dann den aktuellen Zustand des Quad Relays: uint16_t value = 0; industrial_quad_relay_get_value(&iqr, &value); printf("%u", value);

Brick Daemon 2.0.8 Fix dynamic loading of libudev on Linux Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.8 Dynamische Laden von libudev auf Linux korrigiert Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Es sieht so aus als ob du bricklet_industrial_quad_relay.c und ip_connection.c nicht mitkompilieren würdest. Daher dann auch die Undefined Symbol Fehler.

Brick Daemon 2.0.7 Add OpenWrt package Makefile (thanks to bjoern-r) Debian package now works with libudev0 and libudev1 Use GetSystemTimePreciseAsFileTime() on Windows 8 for more precise log timestamps Fix race between socket select thread and USB poll thread on Windows Fix text of some USB related error messages Don't set SO_REUSEADDR for server socket on Windows Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.7 Makefile für OpenWrt Package hinzugefügt (Dank an bjoern-r) Debian Package funktioniert jetzt mit libudev0 und libudev1 Auf Windows 8 wird GetSystemTimePreciseAsFileTime() für genauere Zeitangaben im Log verwendet Race zwischen dem Socket Select Thread und dem USB Poll Thread auf Windows verhindert Text einiger USB bezogener Fehlermeldungen korrigiert SO_REUSEADDR wird für den Listen Socket auf Windows nicht mehr verwendet Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X