AuronX

Eingehende Disconnect-Probes werden verworfen

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?

Die bindings sind in Ordung, weil die anderen bricklets funktionieren.

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

Wie bei Kickstarter geht man einen verbindlichen Kaufvertrag ein, d.h. man kann nicht einfach abspringen.

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 musste z.B. für die Ethernet Extension selbst einen DHCP Client implementieren, das war ganz schön aufwendig.

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:

A TCP SHOULD implement a delayed ACK, but an ACK should not

be excessively delayed; in particular, the delay MUST be

less than 0.5 seconds, and in a stream of full-sized

segments there SHOULD be an ACK for at least every second

segment.

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

Zu den Farben: Ich kann mir vorstellen, dass jemand der so etwas einsetzt gerne auch das Innenleben zeigen moechte. Damit ist "klar" wohl eine gute Wahl. Alles andere, ausser vielleicht weiss, halte ich fuer Spielerei.

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

...würde mir ein Windows-OS da schon schlaflose Nächte bereiten...

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

Warum das Probleme machen kann wenn das Langfristig so läuft (also wenn gar kein Transistor und keine Diode da wären) muss Batti beantworten, da reicht mein Etechnik-Halbwissen nicht aus um das zu erklären .

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

The change in altitude seems to correspond to the pressure changes (left graph), so I think it is due to unstable air-pressure.

I don't know the math, have you tried setting the reference air-pressure to the current pressure? Don't know if it is more reliable in the area of the reference pressure. (Altitude should be around 0m when you do this)