borg

Die Schaltung kannst du dir hier angucken: https://github.com/Tinkerforge/ambient-light-bricklet/raw/master/hardware/ambient-light-schematic.pdf ankommen solle maximal 3,3V beim AD Wandler! Der TEMT6000 zieht Strom abhängig vom der einfallenden Lichtstärke und je nachdem welche Widerstände wir wie beschalten resultiert das in unterschiedlichen Spannungen die vom AD Wandler gelesen werden können.

Klingt nach einer guten Idee, habs mir auf die TODO Liste geschrieben.

Bei Nachrichten die nichts zurück geben ist das schwierig, bei Nachrichten die etwas zurück geben bekommst du einen Timeout! Wenn du wissen möchtest ob ein Master noch ansprechbar ist könntest du also z.B. einmal get_voltage() aufrufen.

Wenn du einen passenden analogen Sensor findest sollte das gehen. Wir haben auf dem Bricklet 4 Widerstände drauf die wir unterschiedlich schalten um unterschiedliche Bereiche hochauflösend auslesen zu können. Das müsste für den neuen Sensor dann natürlich neu berechnet werden.

The communication protocol will be documented. It is important that the language bindings are generated using our generation config files etc., otherwise every api change and new product will be a huge pain in the ass.

We have a new employee and his first task is to make new programming language bindings and to document the low-level TCP/IP communication (so it is in theory possible to use every programming language) The remaining question is of course: Which programming langauge should we support first? What should have the highest priority?

@Shell: Wie würden die Callbacks in der Shell funktionieren? Und wie granular sollte das sein? Ich befürchte das es einfach zuviel wird wenn man aus jeder Funktion von jedem Brick/Bricklet einen Befehl macht. Was ich mir vorstellen könnte ist sowas: tf brick dc set_velocity 150 tf bricklet temperature get_temperature # Gibt Temperature auf stdout aus etc. Der einzige Befehl den die Shell dann kennen muss ist "tf". Das wäre glaube ich vergleichsweise schnell generiert, damit könnte man aber dann natürlich nur die getter/setter abbilden

0b1111 ist äquivalent zu (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3) http://de.wikipedia.org/wiki/Bitmaske

Ah, that is a resistor array. The new hardware version of the Chibi Extension is still called 1.0 (since we didn't change anything about the layout). But if you don't have the dots, you have the old hardware version. Could you contact info@tinkerforge.com with your order id? I guess we will try to replace your Chibi Extensions, i am out of ideas otherwise. It may still be possible that there is some kind of interference at your place that is to blame, but we will see that then .

I really don't know what is going on there then. Oh. you mean the white component with the red-ish rectangle in it? What hardware version do you have? Does the extension have small white dots at the top left and bottom right (on back and front)?

Wie ihr sicherlich mitbekommen habt geht die Weiterentwicklung ein wenig langsamer voran als geplant bei uns. Deswegen haben wir ab morgen einen neuen Mitarbeiter! Seine erste Aufgabe wird es sein neue Programmiersprachen-Bindings zu erstellen und eine Dokumentation über die low level TCP/IP Kommunikation zu schreiben (damit man in Theorie jede Programmiersprache nutzen kann). Die Frage ist jetzt natürlich: Welche Programmiersprachen soll er als erstes machen? Was hat die höchste Priorität? Edit: Kleiner Disclamer: Wir behalten uns vor nicht die Reihenfolge die am Ende beim Poll rauskommt einzuhalten, wir Fragen hier ja nur einen kleinen Teil der Community (im Forum angemeldete deutschsprachige). Das Feedback was wir per Email etc. bekommen haben fließt zusätzlich noch ein.

Die Grundlegende Idee eine Möglichkeit zu bieten mit der man einfache Abläufe grafisch modellieren kann hatten wir natürlich auch schon. Ich könnte mir auch vorstellen das wir ein solches Projekt finanziell oder mit Bauteilen unterstützen, allerdings müssten dafür einige grundlegende Fragen erst geklärt sein: - Worauf soll das Projekt aufsetzen? Müssen wir das Rad neu erfinden? - Was genau ist die Zielsetzung? Wir brauchen eine Liste an Szenarien die man mit der "grafischen Programmierung" umsetzen können soll. - Die nächste Frage ist dann: Was müssen wir tun damit wir diese Szenarien umsetzen können? Brauchen wir Turing-Vollständigkeit oder reicht ein "wenn Wert kleiner, stelle Motor mit X"? Was bleibt von den Szenarien dann noch über?

@Masder Wenn du den Stack über die Step-Down Powersupply mit Strom versorgst muss der Servo Brick nicht zusätzlich mit Strom versorgt werden, richtig.

Der Interrupt den du bei der IO4 bekommst besteht aus 2 Werten: Eine Bitmaske die angibt wer den Interrupt ausgelöst hat und eine Bitmaske die den momentanen Wert darstellt. überprüfen kannst du die Werte folgendermaßen (ungetestet): if bitmask & (1 << 0): print "pin 0 high" else: print "pin 0 low" if bitmask & (1 << 1): print "pin 1 high" else: print "pin 1 low" if bitmask & (1 << 2): print "pin 2 high" else: print "pin 2 low" if bitmask & (1 << 3): print "pin 3 high" else: print "pin 3 low"

I really can't say what is going on there. You say it works one out of ten times. The one time it works, does it work continuously then? Or just for a split second and it stops working after that?

@Nic Hab die Email noch nicht vergessen, ich gucke es mir Sonntag an.

Ja. Die Sprach-Bindings sprechen ja TCP/IP mit brickd, die WLAN Extension spricht natürlich selbst schon TCP/IP, dadurch fällt brickd weg. Dafür muss aber auch eine brickd Implementierung in den Master Brick, das ist natürlich ein bisschen Aufwand.

Ist im Moment nicht geplant, ich weiß auch nicht ob die Nachfrage für sowas groß genug wäre.

Die WLAN Extension wird ein direktes steuern von einem Stack per Smartphone ohne brickd erlauben! Die Hardware für einen Prototypen ist schon bestellt, werde mich da direkt dransetzen wenn RS485 fertig ist. Die Nachfrage nach WLAN ist echt riesig, hätte vermutlich gleich im Startangebot sein sollen.

Das ist normal. Das Current12 Bricklet hat ja eine 12bit Auflösung für 0-12500mA, d.h. pro LSB werden ~3mA gelesen. Da kann man gegen so eine Oszillation nichts machen. Das Bricklet ist dafür gedacht um Ströme im Ampere Bereich zu messen, da machen dann 10mA Oszillation ja auch nichts aus.

Wir sind laut RS Components unter den glücklichen ersten Bestellern , bei uns ist aber noch nichts angekommen.

Du kannst ja auch jetzt schon Android Devices zum steuern nehmen, brickd muss dann nur woanders laufen (es gibt hier im Forum ja schon einige die brickd auf dem Router zum laufen gebracht haben). Ansonsten, eine Reimplementierung von brickd in java für Android ist auf jedenfall möglich. Man muss nur gucken wie groß die Anzahl von Android Geräten ist die 3.1 benutzen und wo die Hardware das auch unterstützt. Eventuell lohnt sich das im Moment noch gar nicht den Aufwand zu treiben.

Komisch das er automatisch nichts findet, bei mir ging das. Eingebunden hat er bei mir folgenden Treiber: C:\Windows\System32\Drivers\atm6124.sys Die hat er automatisch gefunden, sie liegt aber auch in sam-ba 2.9\drv (im SAM-BA Order). Vielleicht kannst du die dort manuell auswählen?

Nene, da ist nichts kaputt, das kriegen wir wieder hin . Kannst du im Gerätemanager bei dem Unbekannten Gerät irgendwo anklicken das er nochmal nach Treibern suchen soll oder so?

Ich hab das gerade nochmal auf einem frisch Installierten Windows getestet, wenn ich das erste mal ein Brick anschließe was im Bootloader ist und ich dann eine automatische Treibersuche starte findet er sowas wie "ATMEL AT91xxxxx Test Board". Wenn ich das wähle und dann SAM-BA starte findet er eine Verbindung auf "\usb\ARM0" (nicht COM).