AuronX

Idealerweise sollte das jetzt gar kein ruckeln mehr sein oder? Weil ein paar Millisekunden sollte sich das OS des PC ja nicht davon stören lassen, dass es kein ACK gibt.

Was passierte denn mit den Disconnect-Probes vor diesem Patch? Also was passiert wenn ich neue Bindings mit altem brickd nutze?

Das wäre wirklich schade. Aber danke fürs aufschreiben

Okay, in voller ahnungslosigkeit: Eine sinnvolle Zuordnung von Treiber zu Zeile ist nicht möglich? Oder eine Firmware-seitige Korrektur des krummen Verhaltens? Weil das ist ja schon Fehlverhalten, ihr könnt bestenfalls dokumentiertes Fehlverhalten daraus machen.

Das aufgespannte Brett im Hintergrund fixiert dein Werkstück, richtig?

Ich verstehe ungefähr die erste Häfte deines Beitrages nicht. Also ich verstehe nicht was du sagen willst und bin mir nicht sicher ob du verstanden hast was das Ziel ist (Ziel ist es nicht eine IDE aufs Brick zu bringen).

Ah Danke, habe das Cursor-Feature vollkommen übersehen. Ich denke nicht, dass es gewollt ist. Da das Problem meiner Erinnerung nach bisher nicht im FOrum erwähnt wurde tippe ich auf nicht bekannt Frohe Ostern!

Ich konnte bisher nur den WriteLine-Aufruf in der API entdecken... was meinst du genau? Dass du bei WriteLine(0, 0, "foo") nicht in Zeile 1 ganz vorne landest?

Das heißt die anderen Bricklets und das IO16 sind auf 2.x geupdatet?

juristische Theorie: Korrekt lebensnahe Praxis: Du müsstest deinen Kunden im Zweifelsfall verklagen; oder eben darauf verzichten, dass doch alle bezahlen... Gerichtsverfahren sind auch teurer als Bricklets und dein Image hätte auch schon bessere Tage erlebt als den, an dem du deine Kunden verklagst...

Ich sehe IPv6 in der Unendlichkeit verschwinden ^^

Ich habe ja auch keine AHnung, aber mein erster Ansatz wäre es ein Mikrofon ans Analog In anzuschließen. Soweit ich mich richtig an den Physikunterricht erinnere wird im Mikrofon ein Magnet durch eine Spule bewegt und Spannung induziert. Das heißt man könnte von der Spannung auf Lautstärke schließen? Wie gesagt keine Ahnung, vielleicht verursacht mein Aufbau auch Feuer... aber möglicherweise kann da jemand anderes etwas zu sagen.

Wow... interessant das zu lesen Zum delayed ACK habe ich erstmal nur das einschlägige RFC (1122) bemüht: Möglicherweise könnt ihr bei eurem Chip ja nicht nur am Timeout sondern auch am Zähler stellen? Also sowas wie "ACK auf jedes 3. Packet"?

...oder einen alternativen Deckel ohne Displayloch? Wäre mri aber nciht so wichtig, weil durchsichtig ist durchsichtig... mit oder ohne Loch

+1, sehe ich ganz genauso! Kein Temperature finde ich etwas schade, aber reicht ja möglicherweise...

Alsoooo... Linux auf dem Pi ist genauso gut oder schlecht geeignet wie nen normales Windows. Du hast kein "berechenbares" Scheduling, es könnte immer irgendwas schlimmes passieren, das dazu führt, dass deine Antwortzeit mal höher geht (i.d.R. maximal wenige Millisekunden). Es ist halt kein Echtzeitbetriebsystem, deswegen gibts auch keine Garantien in dem Sinne wie man es aus der Informatik gewohnt ist. Rein praktisch: Ich vermute mal, dass sowohl Windows als auch Linux auf dem RaspPi "schnell genug" und "zuverlässig genug" sind. Auf jeden Fall um Welten zuverlässiger als ne drahtlose Verbindung. Aber ich würde damit nicht auf dem Mars ein autonomes Auto fahren lassen und auch keinen Passagierflieger. Viele Grüße Jan edit: Also kurz: Mir ging es nur um die Aussage "Für so ein Echtzeitsystem [...] würde mir ein Windows-OS da schon schlaflose Nächte bereiten."

P.S.: Das ist C und nicht C# ^^

Ich würde statt des Ardu ein Rasp-Pi nehmen. Für die Steuersignale ist WLAN gut genug... Nur die Regelung sollte nicht über Funk laufen.

Ohne das zu einer zu weiten Diskussion führen lassen zu wollen: Aber auch ein normales Linux ist dafür nicht besser geeignet. Gebe dir aber recht, direkt per USB wäre besser und noch viel besser wäre OnDevice, zumindest was die garantierte Antwortzeit betrifft. Niemand wird garantieren können, dass es nicht wieder Kamerasalat gibt, solange die Regelung über WiFi läuft und kein "Notschalter" für Verbindungsabbrüche vorhanden ist.

Ich muss anders fragen: Warum bringt der Pi dich auf 0? Musst du durch sein Gewicht alles neu berechnen? Oder kannst du dein Programm nicht auf dem Pi ausführen? Weil der Pi ist ja nur ein kleiner Computer. Bei den meisten Programmiersprachen würde ich erwarten, dass du die Programme auch auf dem Pi nutzen kannst. Aber vermutlich übersehe ich den wesentlichen Punkt der dich auf null zurückwirft.

@remote: Das mit dem Totalausfall ist natürlich nicht normal. Eine Sekunde je nach Störeinflüssen aus der Umgebung schon. Wenn ich hier im Plattenbau mit zig Nachbarn ein 2,4 GHz WLAN betreibe brauche ich keine Computerspiele übers Netz spielen, weil meine Verbindung zu oft zu lange aussetzt, einfach weil alle Kanäle mindestens 3-fach belegt sind. @webster: Vor einem Live-Einsatz würde ich jeweils schauen auf welchen Kanälen die meisten Störungen sind und jeweils mit meinem eigenen Kanal "ausweichen". Wenn dir das dann so reicht ist ja alles cool. Ansonsten wäre noch meine Frage: Wie hast du es (software-technisch) momentan umgesetzt, dass ein Umstieg auf nen Rasp-Pi dich auf 0 zurückwerfen würde?

Ich muss aber Borg recht geben: Eine Funkstrecke ist per Definition eine unsichere verbindung, gerade wenn du mit deiner Kamera auf Konzerten utnerwegs bist wird es zu (kurzen) Aussetzern kommen (egal mit welcher Funktechnologie). Die Konsequenz ist, dass dein Aufbau damit klarkommen sollte. Warum kannst du keinen PC an der Seilkamera befestigen? Nen Rasp-Pi ist ja gerade mal Scheckkarten groß... Nur meine paar Cent...

Kurze Antwort: Gar nicht... Du brauchst einen PC der mit den Bricks kommuniziert (im kleinsten Fall ein Mini-PC wie der Raspberry Pi). Auf dem PC an dem dein Brick angeschlossen ist brauchst du den Brickd (sofern du keine WiFi-Extension nutzt). Der PC der steuern soll (potenziell aber nicht notwendigerweise der gleiche PC wie der mit dem Brickd), baut dann eine Verbindung mit dem Brickd auf.

@borg: Ist das auch eine Nebenwirkung des Schedulings auf Millisekunden-Basis? Ich habe die Befürchtung, dass das an weit mehr Enden Probleme verursacht als bisher angenommen... (es wäre vielleicht sinnvoll eine Liste mit Problemen zu führen die auf das aktuelle Scheduling zurückzuführen sind... fände ich interessant ^^)

@Batti: Wäre cool, wenn du die Zeit dafür finden würdest