photron

Das Problem ist, dass die Sockets Extension standardmäßig nicht aktiviert ist in der Windows-Distribution von PHP, die es auf der PHP Webseite zum herunterladen gibt. Du musst in der php.ini folgende Zeile einfügen: extension=ext/php_sockets.dll Mir war bis eben nicht bekannt, dass die Socket Funktionen eine Extension sind. Daher ist das bisher noch nicht dokumentiert, ich werde das verbessern.

Edor und BuddaKaeks: Falls eure Rechner auch Renesas USB 3.0 Controller verwenden, dann schaut doch auch mal bitte welche Treiberversion da installiert ist. Es muss 2.1.16 oder neuer sein damit es funktioniert.

Kein Problem, das Problem ist gelöst, das ist was zählt Der Geräte Manager zeigt den Brick in diesem Fall immer an. Der Name hängt wie gesagt damit zusammen aus welcher Quelle Windows ihn nimmt, das der sich ändert hat nichts zu bedeuten. als auch mit der speziellen mit der Logausgabe reproduzieren können. Das Problem war also wirklich der zu alte Treiber, mit dem libusb nicht klar kam. Das ist hier speziell ein Problem zwischen libusb und dem Renesas USB 3.0 Treiber vor Treiberversion 2.1.16, der Geräte Manager ist von diesem Problem nicht betroffen. libusb versucht eine Funktion des USB Treiber zu verwenden, um den Verbindungsstatus der USB Geräte zu erfahren. Genau diese Funktion hat aber eine Fehler im alten Renesas Treiber. Dies führt dazu, dass libusb das betroffene USB Gerät nicht auflistet wenn brickd libusb nach der Liste der USB Geräte fragt. Dadurch taucht dann der Brick im Endeffekt nicht in brickv auf. Das sieht alles sehr gut aus, ich kann auch keine weiteren Probleme im Log erkennen.

Okay, hier eine brickd Version bei der libusb Debug Ausgabe aktiviert ist. Dazu zunächst alle anderen brickd Instanzen stoppen und sicherstellen, dass der Master Brick angesteckt ist. Dann diese brickd.exe mit --debug und --log-to-file Option starten: brickd.exe --debug --log-to-file --log-to-file deshalb, weil die Logausgaben umfangreich sein werden. brickd schreibt dann eine brickd.log Datei in den Ordner in dem brickd.exe liegt. Dann einen Moment warten, damit brickd seine Arbeit tun kann, und dann wieder beenden. Jetzt steht hoffentlich im brickd.log was das Problem ist. Daher hätte ich dann gerne die brickd.log Datei. Am einfachten hängst du sie hier an einen Post an. Wir kommen dem Problem schon noch auf die Schliche brickd_libusb_debug.zip

Das ist ein Problem. Laut libusb.org hat der Renesas Treiber vor Version 2.1.16 einen Bug der verhindert, dass libusb damit richtig umgehen kann. Allerdings ist der Link zu einem neueren Treiber veraltet. Wir sollten diesen Hinweis wohl mal ins FAQ aufnehmen. Diese Version sollte das auf libusb.org beschriebene Problem nicht mehr haben. Daher wundert es mich, dass das nicht geholfen hat. Das der Brick ohne Treiber im Geräte Manager als Master Brick, mit Treiber aber als Tinkerforge Brick auftaucht ist normal. Ohne Treiber nimmt Windows den Namen auf dem USB Descriptor des Bricks, da hat jeder Brick seinen Namen stehen. Mit Treiber nimmt Windows den Namen aus dem Treiber. Wir verwenden für alle Bricks den gleichen Treiber, daher haben alle Bricks nach der Treiberinstallation den gleiche Namen. Windows 8 macht das besser, vor allem, da Windows 8 ohne extra Treiber klar kommt. Eigentlich solle Windows den Treiber automatisch beim Einstecken des Bricks finden und einreichten. Extra zu diesem Zweck registrieren der brickd und der brickv Installer den Brick und den Bootloader Treiber beim System, wenn die erkannte Windowsversion diese benötigt. brickd.exe --debug und USBView Screenshot sehen leider wie erwartet aus. Was ist das USB-Verbundgerät am Renesas USB Hub? Kannst du das abstecken? Wenn ja, findet brickd dann den Master Brick? Einen weiteren USB Hub zu verwenden bringt wahrscheinlich nichts, so lange der Renesas USB 3.0 Hub des Laptop mit in der Kette ist. Bzw. ich verstehe dich auch richtig, dass du mit dem extra Hub am Laptop keinen erfolgt hattest, Windows finden den Brick, brickd aber nicht?

ThirtySomething, die libusb die dem brickd 2.0.8 auf Windows beiliegt sollte mit dem Renesas Controller parat kommen. Die Information aus dem Geräte-Manager sehen aus wie erwartet, bzw. bringen mich ertsmal nicht weiter bei dem Problem. Steckt denn der Brick an einem der USB 3.0 Ports, oder steht er an einem der USB 2.0 Ports des Intel Series 6 Chipsatzes? Wobei USB 2.0 eigentlich keine Probleme machen sollte. Welche Treiberversion ist für den Renesas Controller installiert? brickd zum Testen Hier einmal zum Testen brickd 2.0.8 mit aktualisierter libusb: http://download.tinkerforge.com/_stuff/brickd_windows_2_0_8_d5aa1f0b606a70bb41a114aba414cb41682eb35a.exe USB View Tool Und hier ein Tool von Microsoft, das den gesamten USB Bus als Baum darstellt. Ein Screenshot davon mit angestecktem Brick könnte hilreich sein. http://download.tinkerforge.com/_stuff/usbview.exe Ansonsten muss ich mal sehen wie ich aus libusb raus bekomme was das Problem ist. brickd in Debug Modus Was du auch noch mal testen kannst ist den Brick Daemon Dienst über die Computerverwaltung zu stoppen und dann brickd.exe manuell aus dem Explorer heraus starten. Am besten legst du eine Verknüpfung zu brickd.exe an und hängst dann hinten an das Ziel der Verknüpfung " --debug" (ohne die "") an. Dann über die Verknüpfung brickd starten. Ich würde erwarten dass du beim Anstecken des Bricks an USB diese Meldung siehst, die besagt, dass Windows ein neues Gerät gefunden hat: <D> <other|main_windows.c:213> Received device notification (type: arrival) Aber nicht diese, die besagt, dass libusb ein neues USB Gerät gefunden hat welches ein Brick ist: <D> <usb|usb.c:118> Found new USB device (bus: 1, device: 2) Das würde meine Erwartung bestätigen, dass libusb den Brick nicht findet und damit brickd ihn nicht finden kann.

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. Edit: Veraltete Firmware entfernt.

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.