LabVIEWForum.de

Ich würde gerne Daten von einem Rechner auf einen anderen übertragen, wobei es zwischen den beiden nur eine recht unzuverlässige Wireless-Ethernet-Bridge gibt (das Sensor-Gerät ist mobil, weswegen es zu stark wechselnder Signalqualität kommen kann). Bei den Daten handelt es sich um Standbilder aus Kamera-Streams (mehrere Kameras gleichzeitig) und ein paar Telemetrie-Daten (GPS-Position, Temperatur, Luftdruck, Luftfeuchtigkeit u. ä.). Es sollte 1x pro Sekunde so ein Päckchen ankommen. Wenn eins verloren geht, braucht es nicht nochmal gesendet zu werden (die Daten werden zur späteren genauen Auswertung auch am "Sensor"-System aufgezeichnet), da die übertragenen Daten nur zur "Live"-Kontrolle dienen.

Die Kamerabilder liegen mir als JPEGs vor (maximale Auflösung 800x600, werden von einer anderen Software erzeugt), die Sensordaten werden über ein Datenerfassungssystem am USB-Port aufgenommen (das einlesen von diesen soll hier nicht das Problem sein). Wichtig wäre mir, dass nicht ein einziger Übertragungsfehler gleich mein ganzes Paket kaputt macht, sondern z. B. einfach nur das aktuelle Bild von sagen wir "Kamera 2" fehlt (in der Hoffnung, dass beim nächsten Paket wieder ein aktuelles fehlerfrei ankommt). Um zumindest irgenein Bild zu bekommen habe ich mir auch überlegt, die Standbilder in verschiedene Auflösungen runter zu skalieren, die vom höchstauflösenden ausgehend der Reihe nach gesendet werden und das erste das unten fehlerfrei ankommt wird angezeigt (weniger Daten pro Bild heißt weniger Möglichkeiten für Übertragungsfehler, die die Darstellung verhindern).

Wie würdet ihr das lösen? Ich habe bis jetzt immer nur mit "verlässlichen" Kanälen gearbeitet, weswegen mir hier komplett der Ansatz fehlt.

Wenn die Übertragung unzuverlässig ist, wie kannst Du dann ausschließen, dass sie nicht mal eine halbe Stunde oder 2 Stunden,.... ausfällt? Das Ganze wäre mir zu unsicher. Und das mit dem Übertragen der Bilder habe ich nicht so wirklich kapiert.

Gruß Markus

Mit Wireless-Verbindungen haben wir ja als Hobby-Netzwerker in der Wohnung bei mehrköpfigen Familien fast alle unsere Erfahrung. Meine ist jedenfalls die, dass bei schlechter Verbindung die Übertragungrate sinkt, auch bis zu Null herunter, aber von falschen Daten wüßte ich nichts. Das ist doch irgendwie durch das Protokoll abgesichert, dass fehlerhafte Daten kein Chance haben, als gültige Daten durchzukommen. Ich sehe da keine Notwendigkeit, an dieser Stelle das Rad neu zu erfinden.

Aber trotzdem sollte man bei unsicheren Übertragungen - dazu rechne ich alle Arten serieller Kommunikation über irgendwelche Distanzen - immer dafür sorgen, das ein falsches Datenpaket nicht das ganze System zum Absturz bringt. Das heißt auf deutsch: Fehlerbehandlung. Z.B. schlechtes Datenpaket ignorieren, und anschließend ungerührt auf das nächste Paket warten.

Und eingedenk der Tatsache das die Übertragungsrate sinkt, sollte man wohl am besten erst ein niedrig aufgelöstes Bild schicken das quasi in jedem Fall durchkommen sollte und dann das richtige Bild. Braucht das richtige Bild zu lange wird dann halt nur das "Testbild" angezeigt.

(13.12.2012 13:07 )Kiesch schrieb: [ -> ]Und eingedenk der Tatsache das die Übertragungsrate sinkt, sollte man wohl am besten erst ein niedrig aufgelöstes Bild schicken das quasi in jedem Fall durchkommen sollte und dann das richtige Bild. Braucht das richtige Bild zu lange wird dann halt nur das "Testbild" angezeigt.

Genau das habe ich mit "Bild runterskalieren und dann der Reihe nach verschicken" gemeint (nur in umgekehrter Reihenfolge; zuerst ein hochauflösendes, dann ein kleineres und noch ein kleineres - wie weit man das auch immer treiben möchte - das erste aus der Serie, das komplett ankommt, wird angezeigt). Und das "fehlerfrei" war vielleicht missverständlich. Mir ist klar, dass man bei den üblichen Protokollen fehlerhafte Pakete gar nicht zu Gesicht bekommt, weil die schon auf unteren Schichten verworfen werden. Das fehlerfrei bezog sich auf das ganze Bild. Wenn von den vielen Paketen, auf die ein JPEG beim Versand aufgeteilt werden muss, eins verloren geht/verworfen wird, kann das Bild nicht mehr angezeigt werden. Kleineres Bild -> weniger Pakete -> geringere Chance, dass eines fehlt.

TCP scheidet als Übertragungsprotokoll aus, da der ganze Verbindungs(wieder)aufbau und das automatische Neusenden bei verlorenen Paketen mehr Probleme macht als hilft (wie gesagt, Daten die erst nach ein paar Sekunden ankommen, interessieren mich nicht mehr). Am ehesten wird es also irgendetwas UDP-basiertes sein und auf Empfängerseite muss ich etwas erstellen, das die Päckchen wieder zusammen friemelt. Praktisch wäre natürlich auch ein Bildformat, dem ein paar fehlende Daten nichts ausmachen (d. h. der Rest vom Bild bleibt anzeigbar).
UDP lite wäre hier zumindest schonmal praktisch, wird von Labview aber, was ich gesehen habe, leider nicht unterstützt. UDP lite ist im Prinzip nichts anderes als UDP mit dem einen Unterschied, dass die Paket-Checksum nur über einen definierbaren Teil des Pakets, z. B. den Header, gebildet wird. Es wird damit der Anwendung die Enscheidung überlassen, ob ein Paket mit fehlerhafter Payload zu verwerfen ist. (Um's noch weiter zu treiben müsste auch auf link level, das Ethernet-Niveau, die CRC-Prüfung ausgeschalten werden, aber das geht nur noch mit speziellen Treibern für die Netzwerkverbindung)

Die Frage wäre eben, ob Labview von sich aus hier etwas ähnliches/besseres anbietet anbietet. Ich möchte ja das Rad nicht neu erfinden.