AuronX

Oh Nein, jetzt sehe ich es auch... ich geh mal weinen :'(

Ich glaube unterhalb des Akkupacks das Stützrad zu erkennen.

Deswegen dann wohl auch Türgong per SMS

Bedenke, dass sie regelmäßig zum Staubwischen angehoben werden müssen Also das mit sets/kits ist mir auch egal, aber tatsächlich habe ich mich auch gefragt ob im set schrauben fehlen oder ob ich nur nciht verstanden habe wie es gedacht ist ^^ man schraubt die dinge die zum schrauben gedacht sind halt gerne fest. Die HDDs in meinen Rechnern habe ich auch mit 4 Schrauben befestigt obwohl 2 reichen sollten ^^ das sollte dich glücklich machen

Tut mir leid Loeti, aber ich finde so wie deine Konstruktion aussieht sollte ein TF-Projekt das liebevoll gemacht ist aussehen. Dann muss ich konsequenterweise auch dafür sein, dass du so schön weiterbasteln kannst und so ein Wetter-Brick würde dir nun wirklich den Bastelspaß verderben @Arcane: Multi-Analog wäre nach dem was ich hier so lese bestimmt gut, aber gabs dafür nicht irgendwie zu wenige A-D-Wandler auf den Bricks? Und gab es dann nicht andere Nachteile wenn man die wie beim Joystick multiplexed hat? TF? Oder könnte man einfach noch nen paar A-D-Wandler mit aufs Bricklet tun?

Offenbar scheint das im Moment begrenzt zu sein, also ja. Ich denke TF wird noch kurz recherchieren was das rechtlich bedeutet (in EU sind die Kanäle bis zur 13 frei, in US nur bis 11 oder so). Ich weiß jetzt aber auch nicht, ob TF da beim Export in die USA was beachten müsste oder nicht ^^ edit: okay borg hat ja schon geantwortet... doofe zweite seite -.-

Ich befürchte das ist nicht für alle eine Option ^^ Ich würde aber sagen, dass im AP-Modus nur der Client (also der PC/das Smartphone) fürs Reconnecten verantwortlich ist, automagischer Reconnect seitens Binding ist aber meines Wissens nur in Python im Github implementiert.

jooooo

Btw. wäre da ein Button "Reset Factory Default" möglich? Oder ist das aus irgendeinem Grund eine schlechte Idee?

Im Ernst? Trololol... ich frage mich ja noch immer wie man Microsoft wegen des Mitlieferns von Browsern und Mediaplayern abmahnen kann, aber diese ganze Apple-Politik rechtmäßig sein kann ^^

Ah, jetzt sind die Tomaten auf meinen Augen weg ^^ 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. Ich denke sobald die UID leichter zugänglich ist sollte es zumindest leichter möglich sein, diese Dopplung einfach selbst zu vermeiden.

Was meinst du mit "nicht threadsicher"? Meinst du den Fakt, dass wenn du zweimal fragst zwei mal geantwortet wird? Das Grundprinzip aller Callbacks in TF ist ja, dass die TF-Hardware nciht den Absender kennt, deswegen wird so ein Callback (wie etwa Enumerate) einfach allen geschickt, die gerade auf Enumerate hören. Das heißt wenn ein Programm läuft das auf enumerate hört und jetzt ein zweites startet und auch enumerieren lässt, dann werden beide Programme die enumerate-nachrichten empfangen. Ist es dieses Phänomen das du meinst? Dann schreibst du noch Wie meinst du das? Sorry für die vielen Fragen, aber ich möchte dich gut verstehen

Also 27°C sind ja ~300K. Wenn sich die 15% jetzt auf 300K beziehen, dann würde das bedeuten, dass der Sensor bei einer Temperatur von 27°C einen Wert zwischen -18°C und 72°C anzeigt Auf jeden Fall steht ja im Datenblatt, dass die absolute Temperatur beschissen ist ohne Kalibrierung, während die relative dann recht gut funktioniert. Ich vermute also wenn du ihn einmal kalibrierst (dir das Offset merkst), sollte es besser laufen.

Ich hab mal gerade nachgedacht was so geht... Ich könnte mir vorstellen so eine Funktion auf der IPConnection zu implementieren: public Device CreateDevice(String uid) Ich rede mal gerade nciht über Details der Implementierung, weil da kann man an vielen Stellen streiten. Aber die Semantik wäre, dass ich eine uid reingebe und ein Device rausbekomme das diese uid trägt. Also damit meine ich natürlich, dass ich beispielsweise ein BrickletTemperature in der Hand halte, aber auch das ist ja ein spezielles Device. Ich bin mir nur gerade nicht sicher, wie weit einen das bringt. Weil jetzt habe ich ein Device in der Hand von dem ich nicht weiß was es kann und ich muss wieder switchen (per instanceof o.ä.). Würde dir sowas helfen? Oder ist dein Problem noch ganz woanders zu suchen und ich verstehe es noch nicht?

+1 dafür sry 4 OT ^^

meines ist auch normal... @photron: was bedeutet eigentlich +- 15%? Mir fehlt dafür irgendwie das Bezugssystem. Also wo liegt der Nullpunkt? Bei 0 K? edit: Meines zeigt 30°C, das sind 6°C mehr als das Tempbricklet zeigt... also iO

Sollte zwar in einen anderen Thread, aber ich meine mich zu erinnern, dass auch die offizielle TF-Aussage war: "String parsen". Die TF-Bindings behelfen sich zumindest auch genau damit. Ich denke noch immer, dass das enumerate um etwas wie eine DeviceClass erweitert werden sollte, also eine ID, die nur spezifiziert was für ein Ding da vorliegt. Ich denke 2 Byte (also ein ushort) sollten als Namensraum reichen, aber auch nötig sein. Das könnte in den Programmiersprachen dann in der Regel als enum dargestellt werden. Wenn man die Idee weiterspinnt wird gleich jemand kommen und fragen "was ist wenn ich selbst ein Bricklet baue/die Firmware meines Bricks verändere?" Die Antwort darauf wäre meines erachtens, dass man einen "User-Defined" Addressraum hat. Das heißt z.B. alles was mit Bit 1 beginnt (also alle IDs ab ~32000) würde niemals von TF in Produkten verwendet werden und wäre frei für eigen-Kreationen der Nutzer. Der Haken an meiner Idee? Ich habe keine Ahnung wie/ob das abwärtskompatibel geht.

Das habe ich wohl zu spät gelesen ^^ edit: okay... mein Fix war wohl wirklich ein Schnellschuss ^^ Sorry dafür Das passiert wenn man seine Änderungen nicht testet... *selbstgeißel*

Also bei mir (C#) ist alles schön knackig kurz. Allerdings wird in C# im LEConverter auch beim ersten NUL nicht weitergebaut. Ich schau gleich aml in die Java_Bindings... in 15 Minuten oder so ^^ LG Jan edit: Jo, also Java ist definitiv liebloser implementiert als C# String name = ""; for(int i = 0; i < 40; i++) { name += (char)bb.get(); } Ich werde gleich mal nen Pull Request hochschieben.

Worüber denn Versorgen? Die Frage ist vermutlich diese: Wenn ich das Masterbrick per USB mit Strom versorge und genannte Komponenten dranhängen, reicht das dann oder ist eine zusätzliche Stromversorgung über ein ausreichend dimensioniertes AKW notwendig?

Um WPA zu nutzen muss nur der Schlüssel in Hex-Notation eingegeben werden. Da denke ich niemand jemals seinen eigenen WPA-Key in Hex-Notation eingegeben hat, wäre es möglicherweise für zukünftige Brickv-versionen toll, wenn der brickv den Job übernehmen würde und das einfach ausrechnet ^^ (zu WEP-Zeiten war das noch anders, aber bei WPA kennt man den Hex-Key i.d.R. gar nicht)

Um mich dem gleich mal anzuschließen noch mehr Fragen: Wie viele TCP-Verbindungen zur Extension sind gleichzeitig möglich? (irgendwo im Forum stand mal was von einer, aber die Specs führen das nicht auf) Ich vermute es gibt im 802.11n-Betrieb nur eine Funkstrecke, weil nur eine Antenne, korrekt? Insgesamt sieht der Text zum Brick eher nach Werbung als nach einer Produktbeschreibung (wiederhole so oft wie möglich die Worte Smartphone und Tablet) aus, aber das ist nur meine Meinung ^^

Jetzt hast du photron zum Weinen gebracht @macdiver: ich glaube batti hätte besser daran getan zu sagen, dass es bei dem Bestücker länger dauert und das mit dem "er gibt sich für uns extra mühe" lieber geheim lassen sollen. Lieber zu wenig versprechen und am Ende besser dastehen. Rechne einfach damit, dass der Bestücker sie doch nur normal behandelt ^^ Dann bist du weniger enttäuscht.

Sieht so aus als hättest du die Python-Bindings nicht bzw. nicht dort wo sie erwartet werden. Ich glaube, dass du die Bindings einfach nur ins gleiche Verzeichnis werfen musst wie die Datei die du ausführst. Falls du das schon getan hast, dann werden sie möglicherweise doch woanders erwartet und meine Kenntnisse sind gerade zu staubig

Lass uns deine Gedanken nochmal kurz sortieren, weil ich deine PCs nicht so gut kenne. 1. Welche Programme wolltest du testen? 2. Haben diese Programme schon jemals auf diesem PC funktioniert? 3. Hast du auf diesem PC den brickd installiert, so wie du es auf deinem Laptop getan hast? LG