photron

Ein GPS Bricklet 2.0 ist in Entwicklung. Es wird voraussichtlich das Firefly X1 Modul von GlobalTop verwenden.

The documentation is correct. The JSON payload should contain a uv_light member. I've fixed the implementation now.

Link added.

Gehts hier ums Wiki?

Um welchen Eintrag geht es?

Das originale PIL gibts nicht für Python3, das stimmt. Aber dessen Fork Pillow schon: https://pillow.readthedocs.org

markus5766h, keine Sorge. Wir ändern da nichts dran

Es gibt neue Erkenntnisse: Es kann sein, dass die Tinkerforge.dll durch Windows beim Download als "von einem anderen Computer stammend" markiert wird. Wenn das der Fall ist, dann verweigert LabVIEW das Laden der DLL. Um das Problem zu beheben muss einfach im Eigenschaftendialog der Tinkerforge.dll im Windows Explorer das "Zulassen" Häkchen gesetzt bzw. der "Unblock" Knopf geklickt werden. Nach einem LabVIEW Neustart sollte es dann funktionieren.

Die Verkabelung ist richtig. Das Problem ist, dass die RGB LEDs einfach 3 Farbkanäle haben und die Reihenfolge der Kanäle nicht immer RGB ist. Das war uns bei der Entwicklung des Bricklets noch nicht bewusst, ansonsten hätten wir das wohl "Color Channel 1, 2, 3" statt "RGB" genannt

Schau mal bitte im Windows Explorer im Eigenschaftendialog der Tinkerforge.dll nach. Wenn dort unten auf der "Allgemein" Seite steht, dass die Datei von einem anderen Computer stammt, dann verweigert LabVIEW die DLL zu laden. Um das zu beheben muss du im Windows Explorer im Eigenschaftendialog der Tinkerforge.dll unten auf der "Allgemein" Seite den "Zulassen" Haken setzen und dann LabVIEW neustarten.

Ich bin gerade dabei Brick Daemon für Windows 10 IoT Core zu portieren. Unter Windows 10 IoT Core steht nicht die ganze Windows API zur Verfügung, sondern nur die neue Universal Windows Platform, in der einige Teile der Windows API fehlen die Brick Daemon und ins besondere libusb verwenden. Mit der Portierung von Brick Daemon selbst bin ich soweit durch. Ich habe mir angesehen wie viel Aufwand es wäre libusb auch zu portieren und mich dagegen entschieden. Stattdessen wird Brick Daemon für Windows 10 IoT die neue Windows Runtime API Windows.Devices.Usb nutzen. Diese scheint aber im Moment auf Windows 10 IoT Core noch einen Bug zu haben, so dass ich bisher nur RED Bricks aber nicht die anderen Bricks über Windows.Devices.Usb ansprechen kann. Da bin ich gerade dabei das im Microsoft Windows IoT Forum zu klären. Im gleichen Zuge werde ich mit auch im die C# Bindings kümmern.

Wenn du defekte Hardware hast dann tauschen wir die natürlich aus. Wende dich dafür bitte mit Verweis auf diesen Thread hier an info@tinkerforge.com. wicd erschien 2014 zur Erstellung der ersten Image Version als brauchbare Lösung. Mittlerweile würde man wahrscheinlich systemd-networkd verwenden. Kein Tinkerforge Package ist in Debian.

Verstehe ich das richtig, dass das Problem mit unserem GSM Stick zusammenhängt? Sprich mit unserem funktioniert es nie, mit anderen GSM Sticks funktioniert es aber sehr wohl?

Wir haben das gerade noch mal getestet und es funktioniert hier. Wenn der Stick nicht direkt im Mobile Internet Tab auftaucht, dann taucht er aber nach einem Klick auf den Refresh Knopf auf. Wir wird der RED Brick mit Strom versorgt? Was ist sonst noch am RED Brick angeschlossen? Ist der Stick direkt am RED Brick angeschlossen oder per Hub?

GMT-2? Wir haben hier eigentlich gerade GMT+2. http://wwp.greenwichmeantime.com/time-zone/gmt-2/ Does GMT-2 observe Daylight Saving Time? GMT-2 does not operate Daylight-Saving Time Ist also alles korrekt. Du hast einfach auf dem RED Brick eine Zeitzone eingestellt, die kein DST kennt. Du kannst über den Brick Viewer im RED Brick Settings Tab Uhrzeit und Zeitzone mit deinem PC synchronisieren. Dass sollte das Problem beheben.

TCP/IP funktioniert so leider nicht. Und auch das Disconnect Probe hilft da leider nicht so richtig. Was unserem TCP/IP Protokoll momentan fehlt ist ein richtiger Heartbeat um Verbindungsverlust in beide Richtungen zu erkennen. getConnectionState() sagt dir ob die TCP/IP Verbindung besteht. Das hat allerdings nicht damit zu tun ob du gerade auch Daten übertragen kannst, bzw. ob eine WLAN Verbindung besteht. TCP/IP ist absichtlich so entworfen worden, dass zwischendurch auch mal keine Daten übertragen werden können, weil die unterliegende Verbindung wie z.B. WLAN gerade nicht besteht. Deine " Echtzeit-ConnectionState Funktion" gibt es schon. du kannst einfach anstatt getConnectionState() abzufragen irgendeinen Getter aufrufen. Wenn dieser einen Timeout liefert, dann besteht die WLAN Verbindung gerade nicht.

Ja.

Das hat nichts direkt mit der Last zu tun. Okay, einmal in die technischen Details. Auf dem Bricklet ist ein IC der RS232 spricht und inter einen 60 Byte Lesebuffer für über RS232 eingehende Daten hat. Das Bricklet ließt diesen Buffer jede Millisekunden aus und schickt dir die Daten per Callback. Wenn deine 30 Byte vom RS232 IC so empfangen werden, dass er gerade die ersten 10 Byte in seiem Lesebuffer gespeichert hat, wenn das Bricklet ihn abfragt, dann bekommst du einen Callback mit diesen 10 Byte. Die restlichen 20 Byte bekommst du dann im nächsten Callback.

Die Abweichung aggregiert sich von Takt zu Takt. Du kannst die Abweichung einer Uhr recht einfach durch einen Faktor X beschreiben mit dem sie zu schnell oder zu langsam geht. Dieser Faktor X hängt von verschiedenen Einflüssen, wie Temperatur und Bauteiltoleranzen ab. Wenn der Brick mit seiner Uhr also 5 Minuten gemessen hat, dann waren dass in Wirklichkeit 5 / X Minuten. Wenn jetzt keine großen Temperaturänderungen auftreten, dann ist das für einen festen Aufbau recht stabil.

Du kannst mehrere Callbacks bekommen und musst die Daten wieder zusammensetzen. RS232 hat in dem Sinne ja erstmal kein definiertes Packetformat. Das Bricklet weiß also nicht wie deine Daten zu interpretieren sind. Der Callback wird sofort aufgerufen, wenn Daten empfangen wurde. Das Bricklet fügt da keine künstliche Verzögerung ein. Das Bricklet kann das nicht. Dafür wäre ein Zwischenspeicher auf dem Bricklet notwendig, der so nicht vorhanden ist. Das Bricklet sendet dir einfach alle empfangenen Daten so schnell wie mögliche. Jegliche Interpretation der Daten ist dann deine Aufgabe. Dadurch hast du die Flexibilität die Daten in jeglicher Weise zu interpretieren, ohne eine feste Vorgabe durch das Bricklet gebunden zu sein.

Warum ist -1 erwartungsgemäß? Ich würde erwarten, dass der PC weiss ob DST ist oder nicht. Hier von meinem PC: >>> import time >>> time.localtime() time.struct_time(tm_year=2016, tm_mon=4, tm_mday=7, tm_hour=9, tm_min=30, tm_sec=47, tm_wday=3, tm_yday=98, tm_isdst=1) Hier von einem RED Brick, dessen Uhr ein paar Tage daneben ist: >>> import time >>> time.localtime() time.struct_time(tm_year=2016, tm_mon=4, tm_mday=4, tm_hour=14, tm_min=32, tm_sec=24, tm_wday=0, tm_yday=95, tm_isdst=1) Was sagt denn date im Terminal dazu? PC: Do 7. Apr 09:34:31 CEST 2016 RED Brick: Mon Apr 4 14:38:14 CEST 2016 Das S in CEST zeit Sommerzeit an. Eigentlich sollte die Umstellung Winter-/Sommerzeit automatisch passieren, wenn du die Zeitzone richtige eingestellt hast.

Das würde man eher so machen. Die Beispiele haben verschiedene Abschnitte und man würde die Beispiele in ihre Abschnitte zerlegen und diese dann zusammenfügen: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID_GPS = "qG8" # Change to your UID UID_IQR = "roq" # Change to your UID from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_gps import BrickletGPS from tinkerforge.bricklet_industrial_quad_relay import BrickletIndustrialQuadRelay import time ende = 7 if __name__ == "__main__": ipcon = IPConnection() # Create IP connection gps = BrickletGPS(UID_GPS, ipcon) # Create device object iqr = BrickletIndustrialQuadRelay(UID_IQR, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected while True: start = 0 while start <= ende: course, speed = gps.get_motion() # speed in 1/100 km/h start = start + (speed/3600) time.sleep(0.1) print("Summe", start) iqr.set_value(0b1111) time.sleep(0.3) iqr.set_value(0b0000) ipcon.disconnect() Der sleep Aufruf hält das Programm (genauer gesagt den einzigen Thread des Programms) da an. Die Neuberechnung wird also auch angehalten. Damit das gleichzeitig laufen kann, kannst du entweder einen weiteren Thread benutzten, oder den Motion Callback des GPS Bricklets, der im Hintergrund auch in einem weiteren Thread ausgeführt wird. Du solltest dich wahrscheinlich erstmal zumindest kurz mit Threads und Nebenläufigkeit beschäftigen. Mit Threads kann man in einem Programm mehrere Dinge parallel ausführen. Du musst dazu in deinem Programm also den Zustand des IO-4 Bricklet Abfragen und dann entweder die Berechnung durchführen, oder weiter das IO-4 Bricklet abfragen. Dann ist der Brick im Booten stecken geblieben? Ist das eine SD Karte von uns? Wenn nicht, wie schnell ist beim lesen. Es kann Probleme mit sehr langsamen SD Karten geben. Wenn es dass nicht ist, dann versuch mal das Image neu auf die SD Karte zu schreiben.

There is no ready-made script for that, but you just need to combine existing examples for the two Bricklets to make that work.

I took a quick look at the code of this tinkerforge_laser_transform_node module and I think it should just work fine if you only have an IMU Brick 2.0 connected. But I've never used ROS, so I cannot be certain. You should probably just give it a try. You could also directly ask the author of the module about this.

Can you explain more detail what you did? Did you upload a bunch of class files or a JAR file? If you put your own code into a package, did you also put the class files into the correct directory hierarchy?