M4ST3R

Wie lustig, dass so viele das Problem haben und noch kein Thread dazu existiert :-D

Also erst mal kein Problem mit dem einklinken dafür ist das hier ja ;-)

Der ESC braucht zusätzlich Strom um den Motor zu versorgen. Angaben zur richtigen Batterie stehen in den Specs vom ESC

Musst vermutlich 2 verschiedene nehmen wegen der Reichweite. Wobei bei 2m +x wird es ein Problem. Ansonsten könnte man das Volumen ja berechnen

Ein Traum in Schleiflack;-)

Werfe dafür ein Storno ein! Finde AuronX hat recht!

Vlt wären verschiedene Stecker hilfreich für Input und Output

Glaube die generelle Überarbeitung ist sinnvoll. Auch das Enumerate wurde schon diskutiert bzw. die UID müsste bei Device verfügbar sein

Mit dem Handy geht's

Kenne es nur von Propellern und hab die Erfahrung gemacht, dass das nicht so gut hält.

Finde schrauben persönlich besser als die Klemme. Hält einfach besser

Kann mich mal kurz einer aufklären, was das Problem mit PayPal ist?

Looks like a funny little guy! Maybe you can add a distance bricklet and check the distance and avoid collision with walls

+1 für den pragmatischen Baumarkt Ansatz

Nur als kleine Anmerkung hier ein kurzer Bericht.

http://netbeans.dzone.com/nb-tinkerforge-course-report

Mehr auf Nachfrage bei Interesse

Oder einfach Befestigungen ... wollte auch was beitragen

Benutze immer die von Computern. Da liegen immer viel zu viele Schrauben bei und die passen super

@OT Apple Steuer lol!  Sehr geil!

Also habe noch keine TF entwickelt. Allerdings geht das kostenfrei nur, wenn du ein Jailbreak gemacht hast. Ansonsten brauchst du einen Entwickler Account beim Dörrobst um Dinge ohne Appstore auf deinem Device zu installieren. Gibt es für 99$ bei Apple zu erwerben. Ist leider nicht so leicht wie beim Droiden

Möglicherweise wollt ihr auf die Netbeans Platform portieren

Dann ist es sehr einfach gemacht, weil die das von Haus aus mitbringt.

Können uns da gerne mal drüber unterhalten!

Diese Felder sind alle nur package-visible, das ist auch okay so.

Aber es sollte definitiv public getter dafür geben (so ist ja zumindst der Java-Stil ^^)

 

Wenn TF nicht schneller ist mache ich dazu später noch nen Pull Request.

Ja so eilig ist es nicht. Das Programmiertraining ist jetzt vorbei. Werde demnächst ein paar Bilder der "Software" hier zeigen oder verlinken. Ist leider aus Zeit und zum Teil auch aus gründen wie diesen nicht soo viel raus gekommen wie ich erwartet hatte aber ist ein guter Anfang!

Ich denke sobald die UID leichter zugänglich ist sollte es zumindest leichter möglich sein, diese Dopplung einfach selbst zu vermeiden.

Ja das schon aber das doppelte Enumerate bzw. n-fache ist ansonsten auch nicht sinnvoll.. muss man sich mal ansehen!

+1 für beides

Sorry für die vielen Fragen, aber ich möchte dich gut verstehen

Kein Problem ist noch früh am morgen und ich sitze in der Trainingssession, deswegen immer nur so Sachen die uns hier direkt auffallen.

Es gibt ja die Abstract Class Device wenn ich das richtig gesehen habe. Dort ist UID etc. vorhanden. Nur das wird nicht an die Erbenden Bricks/Bricklets übergeben.

Ja das mit Enumerate erklärt das natürlich. Allerdings sollte man sich da irgendwas überlegen (fällt mir spontan nichts ein) um das zu ändern. Weil so teilweise die Bricks/lets doppelt angelegt werden

Ja möglich wäre das, aber zu viel Aufwand für eine Funktion die keine Funktion für mich hat

Naja es geht ja gerade darum, dass man das was angeklemmt wird einfach erkennt und verarbeiten kann.

Gerade für den GUI Designer den wir gerade bauen brauchen wir alle Informationen über das Brick.

Das Enumerate ist allerdings nicht threadsicher. Wenn man zwei Java Programme öffnet direkt hintereinander, dann läuft das Enumerate zwei mal durch. Sollte ja eigentlich nicht sein.

Das größte Problem ist halt, dass man nur durch Enumerate alle Informationen über das Brick/let bekommt. Aber das sollte eigentlich im gesamten Programm zur Verfügung stehen. Man sollte ja von jeder Stelle im Programm auf die Informationen zugreifen können ohne ein kompliziertes Mapping zu veranstalten. Gerade UID etc. sind ja Basisinformationen die man für Connection etc benötigt

Also das Problem ist eigentlich, dass du nur beim enumerate den Namen und die UID + StackID hast.

Man müsste nur die abstract Class vollständig in die einzelnen Bricklets übernehmen. Dann hätten alle Bricks und Bricklets (gehen wir mal von einem Master hier aus) auch die UID.

So könnte man ein enumerate fahren und bekäme eine Liste mit Devices, die man dann separieren müsste. Deswegen fände ich eine ID für alle Bricks auch super dann hätte man nicht das Problem mit Strings und dem zuschneiden etc.

Dann könnte man nach dem Enumerate einfach die einzelnen Bricks generieren und in in seinem Code verarbeiten.

Momentan ist ja das Problem, dass man sobald man das Enumerate mit entsprechendem Device verwirft keine Ahnung mehr hat was sein Masterbrick für eine UID hat. Momentan müsste (ich werds nicht tun) ich mir die Mühe machen und eine Map mit Device und Masterbrick schreiben um an alle Informationen zu kommen. Aber das wäre natürlich bei einer vollständigen Implementierung des Masterbricks völlig unnötig! Aber scheinbar sehen das ja mehrere Leute hier so. Was sagt die TF Crew dazu?

Abwärtskompatibel wäre es trotzdem, weil man einfach nur zusätzliche Felder generiert und somit keine Änderung an vorhandenen hätte.

Edit: kann es sein, dass die Enumerate nicht threadsicher ist?

Naja. Mit den 38°C ist ja auch die Temperatur direkt auf dem Chip im Gehäuse gemeint. Das hat nix mit der Umgebungstemperatur zu tun.

Das passt schon. Da ist ja noch das Chipgehäuse runtherum.

 

Das ist "als Vergleich mal an den Haaren herbeigezogen" als wenn du die Umgebungstemperatur messen willst und das Thermometer dazu in deine Hosentasche steckst.

Ich glaube du hast den primären Post von mir nicht gelesen oder? Heute sagt mein Master Brick was von -0,5 - 3°C

Ich möchte mal behaupten der Sensor hat n Schaden! Aber egal brauche den nicht!