Hi,

wir können die Daten ja auch als TIFF speichern. Also die Kurve direkt als Grafik dargestellt in einem sw Bild. Das kann der Mensch sofort lesen, und es braucht wenn es gepackt wird recht wenig Speicherplatz.
Wie sieht das mit der Auflösung aus? Nehmen wir eine Größe von 1000x1000 zwischen den Achsen. Also das eigentliche Bild ist größer wegen den Skalen am Rand.
Der Messbereich beträgt 100N und 10s. Das bedeutet, wir können auf 0,1N und 10ms auflösen. Das ist doch schon mal was.
Nicht nur das dieses Format sofort von jedem Menschen ohne Probleme gelesen werden kann, es kann sogar von einer Maschine interpretiert werden.
So kann man z.B. ganz einfach den Impuls berechnen, indem man die weißen Pixel unter der Kruve addiert und dann anhand der Auflösung (0,1N 10ms) berechnet.
Ich habe das mal kurz im Groben ausprobiert. Die Exceldatei ist ca. 3,8MB groß. Die Messpunkte sind ca. 10.000 in der Anzahl. Die Kurve als Tif in der Bildschirmauflösung gespeichert (nicht ganz die 1000 Pixel von oben) ergeben 64kB und das gezippt 4kB. Das gezippte excelsheet ist immer noch 914KB groß.
Ist doch garnicht so schlecht oder?

Gruß

Neil

P.S.: Es sollte klar sein das man zum betrachten ein Programm braucht, braucht man für XML und Binärdaten aber auch.

Hiilfe, Mami!!!!!!!!!!!!!!

Zitat:

---

Ich nehme die Daten exakt so wie sie vom Prüfstand her kommen, speichere sie als Datei und hänge meine eigenen Zusatzinformationen hinten dran. Das Programm weiß natürlich, wo das eine aufhört und das andere anfängt. Da fragt man sich: Wenn es so einfach geht, muß es dann wirklich komplizierter sein?

---

Vielleicht weil dies schlechtes Software-Engineering ist? Da hat man doch zwei Pakete von Daten, die man einfach so aneinanderhängt. Man kann dem ersten Paket nicht ansehen, dass noch ein zweites folgen muss, denn das erste Pakete wäre auch alleine ein vernünftiges Datenformat. Es ist auch nicht klar, dass nicht zwei "Prüfstandpakete" hintereinander folgen dürfen, der Prüfstand jedenfalls darf sie so liefern. Man kann auch nicht auf den zweiten Teil zugreifen, wenn man den ersten nicht versteht. Man kreiert mit dem Austauschformat einen neue Schicht, die die Rohdaten vom Prüfstand verwendet, aber da man die Rohdaten interpretieren muss, um überhaupt die neue Schicht in ihre Bestandteile zu zerlegen, verletzt man das Schichtenmodell. Ich bestreite nicht, dass es geht. Es ging in den Cobol-Programmen in den 80er Jahren auch, und war damals zum Beispiel mit Speicherplatzeffizienz auch noch einigermassen zu begründen, heute stehen diese Argumente jedoch auf schwachen Beinen.

Übrigens hätte man unter Anwendung der allersimpelsten BER-Konstrukte die beiden Binärdatenblöcke sehr schön strukturieren können, mit weniger als 12 Byte Overhead. Man würde die genannte Unzulänglichkeit vermeiden und bekäme erst noch ein Format, welches mit dem Hex-Editor sehr schön zu lesen wäre. Und mit ein paar Bytes mehr würde es sogar ein getagtes Format. Eine Implementation von BER müsste man auch nicht weit suchen: das kann so ziemlich jedes netzwerktaugliche System, entweder weil es dies als Teil von SNMP beherrscht, oder dank SSL, welches ebenfalls darauf aufsetzt. Und selbst wenn es fehlen würde, eine BER Implementation in 294 Zeilen kann man auch vom Internet runterladen.

So einfach wie möglich ist schon eine gute Maxime, wenn man daran anhängt: aber nicht einfacher.

Geändert von Andreas Mueller am 09. Oktober 2006 um 22:45

Zitat:

---

wir können die Daten ja auch als TIFF speichern. Also die Kurve direkt als Grafik dargestellt in einem sw Bild. Das kann der Mensch sofort lesen, und es braucht wenn es gepackt wird recht wenig Speicherplatz.
Wie sieht das mit der Auflösung aus? Nehmen wir eine Größe von 1000x1000 zwischen den Achsen.

Die Messpunkte sind ca. 10.000 in der Anzahl. Die Kurve als Tif in der Bildschirmauflösung gespeichert (nicht ganz die 1000 Pixel von oben) ergeben 64kB und das gezippt 4kB. Das gezippte excelsheet ist immer noch 914KB groß.
Ist doch garnicht so schlecht oder?

---

Bei 1000 Pixeln horizontal kann man grundsätzlich nur 1000 Messpunkte darstellen. Da die Messpunkte nur 1000 Werte abbilden können (1000 Pixel vertikal), kann man diese mit 10bit codieren. Man braucht also für die Codierung nicht mehr als 10000bit, also 1250 Byte. Jedes binäre Format, welches mehr braucht, ist nicht wirklich speicherplatzeffizient.

Excel kann wohl kaum als Massstab dienen. 10000 16bit Ganzzahlen lassen sich als Text in weniger als 60000 Bytes codieren. Man kann das auch noch mit ein paar Bytes pro Zahl strukturieren. Mit BER zum Beispiel käme man wohl etwa 400kB durch, wenn man jeden einzelnen Wert kapselt. D.h. bereits das unkomprimierte Format ist deutlich platzsparender als das komprimierte Excel. Excel ist eben auch kein Austauschformat, sondern ein Format, in dem Verarbeitung zweckmässig möglich ist.

Moin,

ausser Peter und Neil sagen fast alle anderen im Thread dass die Daten von thrustcurve etc. pp. völlig ausreichend sind. Jetzt kommt ein Peter daher und macht neue Vorschläge die sicherlich allemal erheblich besser sind als die Ami-Daten.
Es geht doch eigentlich darum, eine Alternative zu Thrustcurve zu schaffen, welche sich mit UNSEREN Anforderungen deckt... Jetzt haltet euch doch mal nicht an einzelnen Pixeln fest. Peters Motordaten haben sich doch schon hundertfach bewährt.
Vielleicht sollte man den Thread doch mal splitten ?

Gruß
Tom

Zitat:

---

Original geschrieben von Andreas Mueller
Man kann auch nicht auf den zweiten Teil zugreifen, wenn man den ersten nicht versteht.

---

Man kann, möchte ich an der Stelle sagen, auf überhaupt nichts produktiv zugreifen, das man nicht versteht. Natürlich muß jede Software, die einen Messdatensatz grafisch darstellt, numerisch auswertet oder in ein anderes Format konvertiert, pingelig genau verstehen, wie das Format aufgebaut ist. Daran kommst Du nicht vorbei, ob Du es nun in XML Format, binär, Rocksim oder CSV speicherst, ja nicht einmal dann, wenn Du die Daten in Gedichtform packts und von der Kanzel herab in Reimen vorträgst.

Im übrigen ist es nicht ganz richtig, daß wir es mit zwei Blöcken zu tun haben, es sind mindestens drei. Wir haben:

a) die reinen Messdaten
b) Parameter des Prüfstands
c) Benutzerparameter

Der mögliche, vierte Block "Auswertungsergebnisse" wird von mir nicht gespeichert, weil man diese Werte ja beliebig oft und schnell neu erzeugen kann. Dennoch wäre es eine Überlegung wert, ob man nicht einige Eckdaten wie Brenndauer, Gesamtimpuls usw. mit in den endgültigen Datensatz packt.

Was ist das überhaupt, der "endgültige" Datensatz? a) und b) kommen bei uns direkt vom Prüfstand. Das halte ich für systematisch richtig, der Prüfstand sollte wissen, mit welchem Kalibrierfaktor und mit welcher zeitlichen Auflösung er den aktuellen Versuch aufgezeichnet hat. Es wäre riskant, diese Parameter vom Benutzer eintragen zu lassen. Möglich wäre es allerdings, und wer eine fertige Schaltung zum Auslesen der Datensignale benutzt, dem bleibt vielleicht garnichts anderes übrig.

Wir erkennen an diesem Punkt, daß der Benutzer eine zentrale, aber auch etwas unstetige Rolle beim Zustandekommen des "fertigen Datensatzes" spielt. Ich kann z.B. die jungfräuliche Rohdatei, die mir der Prüfstand sendet, einfach abspeichern. Ich kann sie gleich auf der Stelle mit allen wichtigen Parametern versehen. Ich kann aber auch nur einige wenige Parameter angeben und sie wieder zwischenspeichern. Ich kann sie beliebig oft aufrufen und die Parameter verändern.

Der Punkt ist: Die Datei lebt. Abhängig von der Laune des Benutzers schwanken sogar die angezeigte Kurve und die berechneten Ergebnisse, weil z.B. das Treibstoffgewicht eine gewisse Rolle spielt.

Weshalb ich darauf so hinweise? Weil es mir so vorkommt, als sollten wir vor lauter Formatgirlanden nicht vergessen, daß am Ende eine benutzerfreundliche Lösung stehen muß. Wir sollten uns irgendwann auch Gedanken machen, was das im Detail heißt.

Geändert von Peter am 10. Oktober 2006 um 10:23

Hallo,
ich weiss nicht, ob ich alles verstanden habe.
Wenn ich die Aufgabe lösen müsste, dann würde ich zu einem
Motorlauf folgendes speichern:

- gemessene Schubkurve mit den normierten (kalibrierten) Werten,
- physikalische Rahmenbedingungen (Temp., Luftdruck),
- geometrische Informationen zum Motor und zur Ladung.

Nicht zu diesen Daten gehören nach meiner Meinung Skalierwerte des Prüfstands.
Das Messprogramm sollte die Verrechnung selbständig vornehmen.
Am Prüfstand sollte es aber möglich sein, eine Normierung bzw. Kalibrierung vorzunehmen.
Die Gütewerte (Wiederholgenauigkeit und Messfehler) können dann wieder im Datensatz
erscheinen.

Hoffentlich bin ich nicht am Thema vorbei, ich habe nur den letzten Beitrag von Peter gelesen.

Christoph

Hallo Christoph,

das siehst du genau richtig. Ich würde aber den Punkt physikalische Rahmenbedingungen schon mit Werten des Prüfstandes versehen. Es gibt ein paar Parameter des Prüfstandes die einen Einfluß auf das Ergebnis haben und die man wissen sollte. So ist z.B. der Messbereich und die Auflösung wichtig. Warum? Der Messfehler hängt von diesen Werten ab. Wenn ich eine Auflösung von 1N habe, und einen Messbereich von 1000N, so habe ich einen minimalen relativen Fehler von 0,1%. Wenn ich aber einen Motor mit nur 20N Spitzenwert vermesse, dann habe ich 5% Fehler. Wenn ich die beiden Werte nicht kenne, dann habe ich ein Problem bei der Bewertung.

Ich kann auch Peters Punkt halb verstehen, warum der Prüfstand wissen sollte wie er eingestellt ist. Aber wenn er mir nur die Ad-Wandler Werte liefert, dann braucht er es eigentlich nicht.
Hier spielt die Frage eine Rolle, was soll der Prüfstand schon alles machen? Mein Prüfstand liefert mir nur den reinen AD-Wandler Wert und die Software auf dem Notebook macht daraus reale physikalische Werte. Dem Prüfstand ist egal was ich wissen will oder was er misst. Wenn ich aber den Prüfstand die Aufgabe gebe, die Daten zu speichern wenn der Messwert eine bestimmte Schwelle überschreitet oder unterschreitet, dann muss er schon wissen was er da messen soll.

Um der Lösung des Formates näher zu kommen, würde ich schon sagen das wir in der Datei physikalische Werte aufnehmen und keine Werte die der Prüfstand liefert. Gerade das macht es so universal. Der eine Prüfstand misst mit 12Bit der andere mit 16Bit. Schon hat ein Digit eine andere Bedeutung. Das sollte aber der großen Zahl der Anwender egal sein, den die wollen den Wert in Newton oder Pond haben.

Zitat:

---

Es geht doch eigentlich darum, eine Alternative zu Thrustcurve zu schaffen, welche sich mit UNSEREN Anforderungen deckt... Jetzt haltet euch doch mal nicht an einzelnen Pixeln fest. Peters Motordaten haben sich doch schon hundertfach bewährt.

---

Ich würde nicht unbedingt sagen eine Alternative, sondern eher eine Ergänzung. Würden wir eine Alternative schaffen, dann müßte jeder Motor aus der Datenbank neu vermessen werden. Das ksotet Zeit und Geld. Eher würde ich hin gehen und all die Motoren vermessen die dort nicht zu finden sind. Wenn das Format in der Lage ist sogar bessere Werte zu liefern, dann okay. Es sollte aber auch den reinen Thrustcurv Nutzer noch helfen können, denn ich denke das sind der größte Teil der User.

Mir ist gerade aber noch ein anderes Problem eingefallen. Wie wollen wir die Widerhohlbarkeit der Motoren darstellen? Peter hat ja erwähnt, das dort teilweise eine sehr große Streuung vorhanden ist. Wenn wir also eine Datenbank aufbauen wollen als Alternative zu Thrustcurve, dan wäre das ein Punkt der besser wäre. Soll man also im Format der Datei eine weitere Spalte einfügen für die Streuung dieses Punktes in der Datenkurve?
Im Prinzip braucht man folgende Werte zu jedem Zeitpunkt der Kurve:

1. Mittelwert
2. Streuung
3. Max
4. Min

Dann hat man eine Aussage wie gut die Motorenqualität über die Produktion ist.

Gruß

Neil

Mir schwebt bei dem Gedanken an eine Treibsatz-Datei ein noch weiter
gefasster Umfang vor. Für ein zu definierendes Datenformat würde ich nicht
nur an Prüfstanddaten denken.
Ich möchte auch eine gewisse Flexibilität in den Datensätzen haben und vor
allem die Möglichkeit haben, noch mehr Informationen zu einem Treibsatz
speichern zu können.
Ich möchte auf verschiedene Messkurven zugreifen können (z.B. Schub, Druck,
Temperatur,...)
Meiner Meinung nach sollten Messdaten auch mit einem Zeitstempel
ausgestattet sein, da ich nicht konstante Zeitintervalle zwischen den
Kurvenpunkten zur Grundlage machen würde. Aber für das zu definierende
Format sollte auch eine Kurve ohne Zeitstempel verwaltet werden können.

Die Daten sollten in kompakter Form gespeichert werden und brauchen nicht
per Texteditor lesbar zu sein. (Hierzu folgendes: Wenn ich Tabellen lesen
und verwalten will, dann lade ich ein Tabellen-Programm. Wenn ich Dokumente
schreiben will, dann lade ich eine Textverarbeitung. Konsequenterweise lade
ich dann ein Treibsatz-Programm, wenn ich Treibsatzdaten lesen oder
verwalten will.)
Ich möchte in dem Format geometrische Treibsatz-Daten speichern können
Ich möchte Treibstoff-/Werkstoff-Parameter speichern können
Ich möchte Simulationsdaten speichern können (auch wieder Schubkurve, Druck,
Massenfluss, Klemmung,...)
Ich würde auch berechnete/ermittelte Daten speichern (z.B. Impuls, char.
Geschwindigkeit, Brenndauer, maximale Belastungen,...), dann muss nicht jedes
Programm, dass diese Daten braucht, diese auch selbst berechnen.

Ich verfolge damit die Ansicht, alle Daten, die zu einem Treibsatz gehören
auch in der einen Treibsatz-Datei zu speichern.

Es müssen nicht in jeder Treibsatz-Datei alle Daten/Datenblöcke zur
Verfügung stehen. Die vorhandenen Datenblöcke werden mit einem kleinen
Header (z.B. eine eindeutige ID, Versionskennung und Datenblocklänge)
versehen und aneinander gehängt. In dem von uns festzulegenden Format
werden diese IDs definiert.

Es könnten Lade- und Speicher-Routinen für Treibsatz-Dateien in verschiedenen
Programmiersprachen oder als Bibliothek im Forum bereitgestellt werden (mit
Anleitung), die jeder in sein Programm einbinden kann.

Ein beliebiges Programm kann dann eine Treibsatzdatei laden, ggf. einige
neue Werte dazu berechnen und dann alles neu abspeichern.

Ein Treibsatz-Programm sollte fähig sein, theoretische und gemessene
Kurven zu vergleichen um z.B. Treibstoff-Parameter bestimmen zu können.
Es sollten verschiedene Treibsätze miteinander vergleichbar sein.
Es sollte die Daten grafisch und als Tabelle anzeigen/vergleichen können.

Über eine Export-Funktion könnten beliebige Kurven in Text- oder Excel-Format
übertragen werden. Dabei könnte auch gleich eine Datenreduktion, Glättung,
... durchgeführt werden.

Soweit von mir
Oliver

Oliver,

dieser Ansatz gefällt mir ausgezeichnet. Ich bin mit meinem privaten Flugbahnprogramm in eine ähnliche Richtung gegangen. Jede (*.V2) Datei speichert alle Daten, die ich nach meinem heutigen Geschmack für die Konstruktion und den Betrieb der Rakete brauche. Dazu gehören (momentan max. 6) Stufen mit jeweils bis zu 10 Clustern die ihrerseits beliebig viele Motoren enthalten. Jeder Cluster kann einen individuellen Zündzeitpunkt haben und wahlweise als Antriebs- oder als Bremstriebwerk arbeiten.

Pro Motorentyp benutze ich einen Link auf die entsprechende Prüfstandsdatei bzw. gebe die wichtigsten Daten ein, falls zu einem noch Motor keine Datei existiert. Das wird dann noch z.B. mit den für die Stabilisierung nach Barrowman erforderlichen Parametern versehen und einigen Umgebungsparametern (Wind etc.)

Man könnte so etwas ein "Konzept" nennen, es mag auch bessere Begriffe geben. Dein Vorschlag läuft auf ein speziell für Motoren umfassendes Konzeptformat hinaus. Ein solches Projekt stelle ich mir durchaus spannend vor.

Übrigens: Mein Prüfstandsprogramm speichert auch Links zu Bildern, also kann man sich ein Foto des Abbrandes über die Schubkurve einblenden. Das ist sicher nur ein schmaler Einstieg in einen weit größeren Bereich, wo man sich z.B. Multimedia und sonstige Dokumentation vorstellen kann, z.B. die Historie einer Rakete und die pro Flug gewonnenen SALT Datensätze, die auch sinnvoll in ein großes Konzeptformat passen könnten.

Gruß
Peter

Geändert von Peter am 10. Oktober 2006 um 16:14