borg

Yes, you can use a negative "switchOnVelocity": https://github.com/openhab/openhab/wiki/Tinkerforge-Binding#dc-brick To control 4 motors you need 4 DC Bricks. If you just want to switch them for a specified duration you could of course also use the Dual Relay Bricklet or the Solid State Relay Bricklet. Do you know how much power your motors need and at which voltage?

Sehr unschön. Ich befürchte da muss mittelfristig eine neue Lösung her, wir haben da wohl unsere Tests nicht lange genug betrieben . Die Frage ist wie genau eine bessere Lösung aussehen würde. Am besten wäre es vermutlich wir würden sowas mit in den Shop aufnehmen mit einem kleinen dazu passenden Adapterbricklet: http://www.vegetronix.com/Products/VG400/ Leider sehr teuer... Edit: Den hier könnten wir auch gut auslesen (I2C): http://www.adafruit.com/products/1298 Ist aber auch ein ganz guter Preissprung .

I uploaded the Brick firmwares with the current version of the new SPI protocol that will be used with the RED Brick: http://download.tinkerforge.com/_stuff/red_brick_spi_test/ If you have time and you want to help us, you can try it out. The firmwares are compatible to each other, but not to the older firmware versions. There shouldn't be any noticeable difference between the firmwares(regarding speed, latency, etc). If are interested to know why we need a new protocol for the stack communication, i already wrote in a blog entry about it:

Du musst einmal auf Reset drück nachdem du den USB Stecker reinsteckst wenn der Stack selbst schon per Step-Down Power Supply versorgt ist. In den letzten Brick Versionen haben wir die USB Hotplug Funktionalität entfernt, da sie durch große Hitzeentwicklung (unerwünscht) ausgelöst werden konnte. Siehe hier: http://www.tinkerunity.org/forum/index.php/topic,673.msg15985.html#msg15985

Mhhh, das muss ich dann mal selbst nachbauen hier. An und für sich sollten die Bricks jetzt mehr Zeit haben für Berechnungen und andere Kommunikation (da wir während der SPI-Kommunikation weiterlaufen können). Daher kann ich mir das gar nicht erklären.

Wir haben das Analog In aus dem Programm genommen weil wir mit der Messqualität nicht zufrieden waren. Das Bricklet bestand ja quasi aus 4 schaltbaren Widerständen. Dadurch war der Innenwiderstand der Anschlüsse nicht besonders hochohmig und Aufgrund der Verschaltung konnten wir dann auch schonmal sowas wie 5% Messfehler haben. Dazu kommt dann noch das der Messfehler in jedem Bereich anders ist, wodurch es zu Sprüngen kommt wenn man den Messbereich wechselt. In Summe waren wir mit der Qualität des Bricklets überhaupt nicht zufrieden. Wir arbeiten schon länger an einem Ersatz, leider sind wir mit dem letzten Prototypen ein bisschen über das Ziel hinausgeschossen: Dieser Prototyp hat eine galvanische Trennung zwischen Brick- und Messseite und man kann 2x Spannung messen. An die BNC Buchsen kann man direkt Probes anschließen, aber man kann alternativ auch Kabel an die grünen Buchsen anschließen. Leider befürchten wir dass das Bricklet vermutlich zu hochpreisig werden würde, daher haben wir dort erstmal nicht weitergemacht. Ich gehe aber stark davon aus, dass wir auf Dauer wieder ein Bricklet haben welches spezifisch zum Messen von Spannungen ist.

Ich hab Brick Firmwares mit der aktuellen SPI Protokoll Version für den RED Brick hochgeladen: http://download.tinkerforge.com/_stuff/red_brick_spi_test/ Falls jemand Lust und Zeit hat die neue SPI Protokoll Version zu testen wären wir über Feedback dankbar. Die Firmwares sind zueinander kompatibel, allerdings nicht zu älteren Versionen. Es sollte kein großer unterschied zu den alten Firmware Versionen vorhanden sein (was Geschwindigkeit, Latenz usw angeht). Zur Begründung des neuen Protokolls zitiere ich mal einen älteren Blog Eintrag:

RED Brick im EMV Labor Blogeintrag

RED Brick in EMC laboratory Blog entry

Wir verkaufen im Moment die "Verpackungseinheiten" so wie sie original von MakerBeam vorgesehen sind. D.h. die 40mm Profile bekommen wir z.B. schon eingeschweißt in 8er Packs. Dort allgemein kleinere Stückzahlen anzubieten wäre schwierig. Wenn wir die auspacken würden müssten wir versuchen die wieder ähnlich professionell einzuschweißen, damit sich auf dem Lieferweg nicht alles gegenseitig zerkratzt. Ich befürchte das wäre den Aufwand für uns nicht wert. Ein kleineres Kit als das offizielle Starter Kit wäre natürlich möglich, müssten wir mal gucken was man da dann sinnvolles zusammenstellen kann.

Da die Frage schon öfter gestellt wurde hab ich mal ein kleines Beispiel geschrieben dafür (in Python): #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 from tinkerforge.ip_connection import IPConnection import threading class Enumerator: WAIT_TIME = 0.1 uids = [] lock = threading.Lock() def __init__(self, ipcon): ipcon.register_callback(IPConnection.CALLBACK_ENUMERATE, self.cb_enumerate) self.timer = threading.Timer(Enumerator.WAIT_TIME, self.lock.release) self.timer.start() ipcon.enumerate() self.lock.acquire() self.lock.acquire() def cb_enumerate(self, uid, connected_uid, position, hardware_version, firmware_version, device_identifier, enumeration_type): self.timer.cancel() if not uid in self.uids: self.uids.append(uid) self.timer = threading.Timer(Enumerator.WAIT_TIME, self.lock.release) self.timer.start() if __name__ == "__main__": ipcon = IPConnection() ipcon.connect(HOST, PORT) enumerator = Enumerator(ipcon) print enumerator.uids ipcon.disconnect() Ausgabe: olaf@pc:~# python enumerate_all.py ['5W6gHB', '6JLUGS', '6kqhAN', '6QGtV5', '6QENvq', '5W5BYn', '6Kvxz4', '631cHu'] Wenn keiner Verbesserungsvorschläge hat füge ich das inkl. Beschreibung der Dokumentation hinzu.

Ich dachte jetzt das man nach jedem Enumerate eines Bricks/Bricklets einen 50ms Timer startet bzw neustartet und wenn der Timer auslöst ist die Enumerierung vorbei. D.h. es dauert dann in Summe solange wie die Enumerierung dauert plus 50ms für den Timeout.

Leider nicht, diese Information ist im System nicht vorhanden. Der Master eines Stacks baut sich Stück für Stück dynamisch eine Routing-Tabelle auf, wie viele Stapelteilnehmer er in Summe wirklich hat weiß er auch nicht. Wenn dein System per USB angeschlossen ist kannst du aber mit relativ kleinen Timeouts arbeiten (50-100ms oder sowas).

Das ist bereits geplant . Als nächsten Schritt haben wir vor Motoren mit ins Programm zu nehmen und dann auch mit dem ganzen Zubehör Kits zu machen. Man sollte damit dann viel bauen können ohne weiter Zusatzteile (außer vielleicht ein paar lasergeschnittene Platten), was uns sehr gut gefällt.

Der sollte nirgends mehr verlinkt sein. Wir haben leider erst gerade festgestellt das wir mit unserem Vertrag mit DHL nur bis zu 1200mm lange Pakete verschicken können. Ein "Maxitransport" würde uns schlappe 54,90€ kosten und als "Sperrgut" schlappe 22,50€ zusätzlich zum normalen Preis . Die Bestellungen die wir bisher bekommen haben mit 1500mm MakerBeams schicken wir natürlich raus, aber darüber hinaus müssen wir erst gucken ob wir da einen besseren Deal bekommen können.

Die könnte man evtl. wirklich als GPIO nutzen . Wir haben es mal in die Hardware-Errata aufgenommen.

MakerBeam bei Tinkerforge Blogeintrag

MakerBeam bei Tinkerforge Blog entry

Wenn ich das an die Wand bauen wollte würde ich das andersherum anbringen. * Die "Unterseite" zeigt von der Wand weg * Der Bricklet-Stecker zeigt nach oben * Anstatt schrauben im Gehäuse oben (zur Wand hin) kann man weiter Bolzene oder sogar M3-Haken o.ä. reinschrauben um es an die Wand zu hängen. Vorder- und Rückseite verhalten sich bzgl. der Empfangsstärke bei dem NFC/RFID Bricklet gleich .

Öh, zum an die Wand hängen war das Gehäuse gar nicht gedacht. Ich hatte eher daran gedacht das man es auf einen Tisch stellt. Wenn es da hinreichend Interesse gibt könnte man vielleicht ein zusätzliches "Wandgehäuse" machen.

Wie du im Schaltplan sehen kannst, werden Bereits alle Pinne unseres Bricklet-Steckers benutzt. Wir können also keine zusätzlichen LEDs oder Buzzer mehr schalten. Aber wie du selbst schon sagst kann man dafür ja andere Bricklets verwenden .

Ja.

Die Verdrahtung von den LEDs ist leider nicht spezifiziert bei den WS28** ICs. Selbst bei unseren Pixel und Strips die wir im Shop verkaufen sind sie nicht gleich verdrahtet . Im Brick Viewer kann man das aktuell nicht einstellen, sollten wir aber auf Dauer einbauen!

NFC ist auf 10cm Abstand spezifiziert. Das NFC/RFID Bricklet sollte das exakt einhalten, umstellen kann man da nichts. Wenn du request_page aufrufst hast du ja zuvor request_tag_id aufgerufen. Du bekommst immer den Inhalt des Tags mit der tag id die du zuvor ausgelesen hast. D.h. wenn du zwei Karten auslesen willst die sich im Lesebereich aufhalten musst du request_tag_id aufrufen, dann die Daten auslesen, dann wieder request_tag_id aufrufen (im Zweifelsfall solange bis du eine neue tag id bekommst) und dann die Daten von der zweiten Karte auslesen. Das funktioniert Problemlos, genauso macht das dein Handy auch .

Benutzt du einen USB 3.0 Port? Falls ja musst du evtl. den Treiber aktualisieren: http://www.tinkerforge.com/de/doc/FAQ.html#eines-meiner-bricks-wird-im-brick-viewer-nicht-angezeigt