kuli

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

Das https://www.adafruit.com/products/326 oder das https://www.adafruit.com/products/684 wäre ein schönes neues Bricklet.

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

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...

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?

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...

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.

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.

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?

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

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

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?

Find ich auch. Electricity Bricklet oder Power Measurement Bricklet fänd ich gut. Wobei der zweite Name mehr aussagt jedoch auch lange ist.

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 ;-)

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...

ich möchte zusätzlich zum brickd den brickv am raspbian wheezy installieren, doch leider bekomm ich das paket python-qwt5-qt4 nicht drauf. die genaue fehlermeldung beim installieren lautet: python-qwt5-qt4 : Depends: python-qt4 (>= 4.9.1) but it is not going to be installed python-qt4 ist in der version 4.9.3 installiert. hat jemand eine idee wie ich das problem lösen könnte? - ich selbst bin leider kein linux guru...

bin auch für die genauere version! .. sonst muss ich einen externen verwenden edit: möchte mich auch an einem quadcopter versuchen

ja das lieg wahrscheinlich an der leistung des systems. aber wie gesagt, die meiste zeit geht beim laden und initialisieren verloren. wenn das programm mal läuft, gehen die einzelnen abfragen bestimmt schneller. mach mal eine messung vom methodenaufruf selbst! ist es notwendig dass du bei jeder abfrage das programm erneut starten musst?

du misst hier die gesamte ausführungszeit des programms. d.h. es muss geladen werden, dann wird irgendwann die ipconnection initialisiert, ... und dann erst wird die methode aufgerufen. von daher finde ich die zeiten nicht so merkwürdig. wenn du die zeit für den methodenaufruf selbst wissen willst, musst du das über die programmiersprache lösen. in java geht das mit System.nanoTime()

dynamische bindungen sowie der garbage collector bedeuten jedoch (viel) mehr arbeit für die cpu

ok, alles klar, danke!

naja es ist nur ein einziger method call und 1.5ms ist find ich 'viel' zeit. weiß jemand wie hoch genau die latenzen bei usb sind? wenn das mit 1ms pro request stimmt, müssten es bei einem get-request ja mindestens 2ms (rtt) sein.. oder wird eine maximale latenz von 1ms garantiert und weniger kanns immer sein?

bei mir dauert ein method call über java ca. 1.5ms .. was ich gelesen habe wirds nie unter 1ms gehen, da es usb nicht zulässt. was die programmiersprache am RPi angeht: C wird natürlich schneller sein als java.. aber es hängt davon ab was du machen willst.. kann leicht sein dass java reicht python wird soviel ich weiss nativ vom RPi unterstützt.. da hast du aber einen overhead, da python interpretiert wird

ja, BEC hab ich deaktiviert. wenn die stromversorgung von der selben quelle kommt, gehört die masse auch weggenommen - hab ich aber noch nicht getestet. welche periode hast du eingestellt?

@macbull: habe mir zufällig genau den selben regler und motor gekauft und bis jetzt auch nur mit dem viewer getestet. allerdings scheint der servo-brick auf positionsänderungen relativ langsam zu reagieren (liegt das am viewer?). hast du sonst irgendwelche erfahrungen damit gemacht? arbeitest du mit den 19500µs?