AuronX

Wäre aber ziemlich witzig Aber verstehe was du meinst.

Ich glaube die Verbindung zwischen Brick und Bricklet zu manipulieren ist auch nicht der Use-Case von TF-Hardware. Ich habe das bisher immer mehr als Plug & Play gesehen, das gefrickel findet erst ab den Bricklets statt (z.B. wenn ich irgendwas an die Ausgänge eines IO hänge usw). Ich denke deswegen sind Lötpunkte an den "internen" Stellen auch nciht vorgesehen (das Brickletkabel ist nunmal "innerhalb" des Stacks).

Ein Kommilitone meinte zu mir man könnte noch unter dem Stichwort NoNagle suchen ^^

Hmmm... bei meinem selbstfahrenden RC-Auto habe ich es damals darauf geschoben, dass mein ESC zu langsam reagiert hat... möglicherweise war der ja gar nicht schuld

Ich kann aufgrund des Postings des Eröffners nur raten, dass er vermeiden möchte ein USB-Kabel zu zerstören. Da die Alternative aber ist im Fehlerfall einfach den Stack zu grillen und das ohne jegliche Gewährleistung seitens TF, würde ich dringend dazu raten entweder ein USB-Kabel für 2 Euro zu kaufen und zu zerstören oder wie von Gizmo vorgeschlagen eines auf dem Recyclinghof zu erwerben um auch noch das letzte Taschengeld zu sparen und die Umwelt zu schonen.

Meinst du was er auf dem Recyclinghof will oder wie er den Strom in das Kabel bekommt? Ich meine da ein wenig Ironie in dem "toll" gelesen zu haben, aber das könnte täuschen... immerhin redet ihr hier gerade Seitenweise darüber den Strom so in den Stack zu kriegen wie es nciht vorgesehen ist, da ist ein Vorschlag den Strom so reinzubekommen wie es vorgesehen ist gar nciht so unangebracht.

Nur um das nochmal vollkommen richtig zu verstehen: Der Gewährleistungsverlust ist bei diesem Vorgehen aber auch enthalten oder?

The simpler solution is to add the missing accessor, my Pull Request for the C#-Bindings can be found here: https://github.com/Tinkerforge/generators/pull/30 Lets see how TF likes this change

Use the enumeration callback of the IPConnection. 2.0 example: public void main(...) { //... ipcon.Enumerate += EnumerateCB; } static void EnumerateCB(IPConnection sender, string uid, string connectedUid, char position, short[] hardwareVersion, short[] firmwareVersion, int deviceIdentifier, short enumerationType) { if(enumerationType == IPConnection.ENUMERATION_TYPE_DISCONNECTED) { return; //we don't care for disconnected devices } if(deviceIdentifier == 216) //Temperature-Bricklet, as of http://www.tinkerforge.com/doc/Software/Device_Identifier.html#device-identifier { var bricklet = new BrickletTemperature(uid, sender); bricklet.SetTemperatureCallbackPeriod(100); bricklet.Temperature += TemperatureCB; } } private static void TemperatureReached(BrickletTemperature sender, short temperature) { //update your database with sender.uid and temperature } This example contains mostly code from my mind, so there might be typos. Also: I saw that there is no Accessor for the UID on the Device-class. So my comment about "use sender.UID" is wrong, but I think this needs to be changed (Pull Request in preparation ^^)

Aber gab es da nicht auch Möglichkeiten auf diese Weise alles zu grillen? Was sollte man nicht tun, wenn man das vorhaben sollte? War da nciht was mit Masse oder so?

Also Windows erkennt deinen Master nicht (neue Hardware gefunden), aber im Brick Viewer werden dir deine Bricklets und dein Brick angezeigt und funktionieren? Oder versuchst du die UID zu ändern, obwohl gar nichts angezeigt wird? Versuch mal zusammenzufassen was jetzt alles funktioniert und was nicht, denn das ist mir im Moment noch nicht ganz klar.

Naja... die Anforderung im µs-Bereich zu messen ist damit halt nicht zu schaffen. Millisekunden sind hier die Einheit der Wahl, wenn das nicht reicht, dann wirds wohl eine andere Lösung sein müssen. Aber möglicherweise reichen auch Millisekunden?

Ich befürchte auch, dass die einfachste Lösung die Zerstörung des USB-Kabels ist...

WTF? Windows zerstört?

Im wesentlichen schaut der Laser halt von oben auf die Platte und kann jetzt nur alles gerade durchschneiden oder nicht. Du kannst also keine Einkerbungen o.ä. damit anfertigen. Ist aber dennoch erschreckend, wie viel damit so zu basteln ist. Bei uns am Institut wurde mit nem Lasercutter sogar schon Papier geschnitten

I am not aware of how active the english forum is, however it might be useful if it would be splitted according to the german forum (beginners, hardware, software). This might be more encouraging than, the current partitioning of the english Forums.

Ah okay, dachte die 64 Bit wurden auch vollständig ausgenutzt. Ich denke nach eurer ersten Milliarde Bricklets sollte es Champagner geben und keine Hash-Kollisionen Danke für die Erläuterung!

Wie meinst du das? Da 32 weniger ist als 64 würde ich spontan sagen, diese Aussage ist falsch unvollständig Bezieht sich das auf die bisher vergebenen UIDs? Oder ist es nur insgesamt unwahrscheinlicher geworden? (Denn Kollisionen sind ja unvermeidlich wenn der Wertebereich kleiner wird)

@Einstein: Die UIDs wurden gekürzt und die alten längeren werden dementsprechend umgerechnet. Ich vermute es hängt damit zusammen. Ist die neue UID kürzer?

15 Mal ist tapfer Ist der Master sicher schon geflasht oder hängt er noch im Bootloader? Hast du für den Bootloader die korrekten Treiber ebenfalls installiert? LG Jan

Würde möglicherweise auch hierzu passen: http://www.tinkerunity.org/forum/index.php/topic,1277.0.html

Da -40°C der niedrigste Wert ist den das Bricklet laut Doku zurückgeben kann, würde ich auch sagen da stimmt was nicht ^^ Ich frage mich ob dein einer Master kaput-kalibirert ist. Stimmt denn der Druck des Barometers? Hast du noch ein Temperatur-Bricklet oder so, dessen Wert du mal kontrollieren kannst? Oder probier das Bricklet mal an nem anderen Port des 1.0 Master. Klingt für mich (und ich hab diesbezüglich leider fast nur Forenwissen ) nach nem Problem mit nem AD-Wandler deines einen Masters.

Werden die im Fehlerfall auch auf Seite der WiFi-Extension wieder freigegeben? Ach grr warte... borg du hast doch zum Testen den BrickViewer getestet, der nutzt Callbacks. Ich habe bisher bei den anderen nur gelesen, dass sie Getter nutzen. Wenn du Callbacks nutzt, dann versucht dein Stack irgendwann dir einen Callback zu senden, sendet also was per TCP. Dann wird irgendwann ein Timeout zuschlagen und der Socket als Fehlerhaft geschlossen (Vermutung). Wenn ich den Stack jetzt aber nur per Getter/Setter nutze, dann versucht die Wifi-Extension niemals eigenständig meinem Programm etwas zu senden (nur beim Beantworten von gettern). Wenn ich jetzt Die Verbindung fehlerhaft trenne (kein FIN-Paket), dann wird der Extension niemals auffallen, dass die Verbindung verloren ging -> Socket bleibt offen Können die anderen bestätigen, dass meine Annahmen richtig sind? (Ihr nutzt keine regelmäßig auftretenden Callbacks während sich die WiFi-Extension aufhängt) LG Jan P.S.: Wenn nic mitliest wird er sich ins Fäustchen lachen, weil das wieder ein Grund mehr für eine Ping-Funktionalität ist

Zum Glück sind heutzutage die Handys besser im Fotografieren als früher die Kameras ^^ Aber schon interessant dieser Ausdruck, sieht fast so aus als wäre das Gehäuse geschlüpft! Was sind das für farblose Fäden?

Zumindest würdet ihr so auch auf die Titelseite von Spiegel Online kommen ^^