Jump to content

kuli

Members
  • Gesamte Inhalte

    28
  • Benutzer seit

  • Letzter Besuch

kuli's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Auch ich habe Interesse an einem Go Binding. Gibt es Neuigkeiten dazu?
  2. kuli

    TF's Eleven

    Das https://www.adafruit.com/products/326 oder das https://www.adafruit.com/products/684 wäre ein schönes neues Bricklet.
  3. Ich habe nun das Problem mit den springenden Button-Zuständen gelöst. Was ich nicht erwähnt hatte ist, dass ich den Stack an dem das LCD Bricklet dranhängt, mit einem StepDown Brick betreibe. Der Auslöser fürs flackern war das Netzteil. Nachdem ich es gewechselt hatte, war der Fehler weg. Hoffentlich erspart das jemendem viel Sucherei
  4. Es ist sehr eigenartig. Hängt nichts am Pin-Header dran passt alles - die Button-Zustände sind auf Released. Komme ich jedoch mit einem leitenden (!) Gegenstand (z.B. Schraubenzieher, oder meinem Button-Kabel) an einem der Button-Pins am Pin-Header an, tritt der Effekt auf. Solange bis ich wieder weggehe. Probiere ich das ganze mit einem nicht-leitenden Gegenstand passiert nix, es ist also kein Wackelkontakt. Als nicht-Elektroniker, kann ich mir das überhaupt nicht erklären...
  5. Ich habs nicht geschafft alle Lötpunkte gleichzeitig heiss zu bekommen. Habe daher mit einer Entlötpumpe zuerst den Lot entfernt, dann den Pinheader reingesteckt und danach wieder Lötzinn drauf gegeben. Da habe ich allerdings noch eine Anschlussfrage: Wenn ich keinen Button gedrückt habe, wechselt der Button-Zustand ganz schnell zwischen Pressed und Released hin und her (wird auch im Viewer so dargestellt). Schließe ich allerdings den Kontakt mit GND, geht der Button in den Pressed-Zustand über. Brauche ich hier zusätzlich noch einen Pull-Down Widerstand? Oder hats da was anderes?
  6. Ok, der duo hat mit 84MHz nur etwas mehr. Das reicht natürlich. Es wäre jedoch schön wenn der gesamte Paket-Transfer am Super-Master versteckt bleibt, und man so wie bei den Bindings mit Setter, Getter und Callbacks arbeiten kann. Dann wären wir wohl wieder beim on-device Thema...
  7. Nein kein Klon, sondern einen Brick der meinen Code ausführt. Also so wie jetzt, nur leistungsstärker. Natürlich sollen dann auch die "Bindings" vorhanden sein mit denen ich alle anderen angschlossenen Brick/lets ansprechen kann.
  8. Ich glaube, dass ein Linux-Board technisch (bezogen auf Größe und Kosten) nicht machbar ist. Dazu kommt, wenn ich eins brauche, verwende ich ganz klar den raspi. Was allerdings cool wäre ist ein Arduino-ähnliches Mikrokontroller-Board. Sprich ein Masterbrick mit mehr Prozessorleistung und mehr RAM. Die C-Bindings (ohne IPConnection) sollten am Board bereit liegen (flashbar). Über eine IDE meiner Wahl soll der geschriebene Code ebenfalls auf den Super-Master geflashed werden können.
  9. Dazu hab ich auch eine Frage: Kann ich statt dem LSS auch einen Transistor nehmen? Wenn ja, welchen? Ich möchte eine einzelne, dreifarbige LED ansteuern, über 3 Servo Kanäle natürlich. Die LED benötigt max 3x20mA bei 2/4/4 V. Wie würde die Schaltung aussehen (bzogen auf GND), wenn der Stack und die LED über zwei verschiedene Stromquellen versorgt werden?
  10. kuli

    USB Kabel kürzen

    Hi Leute, ich möchte euer USB Kabel auf 15cm kürzen. Kann ich den Mantelwellenfilter (Ferrite bead) runtergeben, oder funktioniert dann die Kommunikation nicht mehr? Hat sonst jemand Erfahrung beim Kürzen eines USB Kabels? Ich würde die einzelnen Kabeln einfach wieder zusammenlöten und mit einem Schrumpfschlauch isolieren. lg Kuli
  11. Ausserdem brauchst du den Akkupack am Servo Brick nicht. Der bekommt seinen Strom über USB. Zusätzlich musst du noch das rote Kabel zwischen ESC - Servo Brick wegnehmen (einfach abklemmen). Der ESC versorgt nämlich normalerweise den Empfänger mit Strom. Wenn du vielleicht später den ESC und den Servo Brick über dieselbe Stromquelle versorgst, musst das schwarze Kabel auch noch wegnehmen. siehe hier: http://www.tinkerforge.com/doc/Hardware/Bricks/Servo_Brick.html#brushless-motoren-mit-escs-verwenden
  12. PM ist aber im Gegensatz zu den anderen Abkürzungen nicht gängig. Sagt daher auch nix aus. Ich finds nicht weiter schlimm wenn der Name etwas länger ist, oder fallt dir eine Anwendung ein wo es ein Problem wäre?
  13. Find ich auch. Electricity Bricklet oder Power Measurement Bricklet fänd ich gut. Wobei der zweite Name mehr aussagt jedoch auch lange ist.
  14. Statt einer eigenen ID wärs doch toll den device typ in die UID einzubauen. Aber da haben wir wohl das Problem der Abwärtskompatibilität. Was jedoch wirklich sinnvoll wäre, ist analog zum EnumerateListener für jedes device ein eigener listener. Z.B. einen MasterListener wo dann eine Instanz vom MasterBrick übergebn wird. Add: Natürlich sollte jeder Listener statt nur einer Methode zwei haben, deviceConnected und deviceDisconnected. Soviel zum Thema OO ;-)
  15. danke für den hinweis! ich weiss jedoch nicht was ich in /etc/apt/sources.list eintragen soll. ausserdem habe ich gelesen dass man unter wheezy ein unstable package anders installiert!? ich habe auf jedenfall diese version probiert: aptitude install -t testing python-qwt5-qt4 was jedoch auch den 'unmet dependencies' fehler bringt...
×
×
  • Neu erstellen...