Wer sich bisher bei Winfried oder mir ein Prüfstandsdiagramm abholte, der bekam eine Grafikdatei -siehe Beispiel weiter unten- und mußte mit dem zufrieden sein, was sie abbildet. Was ja normal nicht schlecht ist, aber dem einen oder anderen wäre es sicher lieber, er könnte die Kurven nach eigenen Wünschen überlagern, dehnen, berechnen oder einfärben. Dazu braucht man die passende Software. An der mach ich gerade Aufräumarbeiten; es wäre also vorstellbar, eine geeignete Version als Freeware an Interessierte abzugeben.

Bin übrigens selber erstaunt, was sich da so angesammelt hat. Es gibt dank Winfrieds nimmermüdem Schaffen Kurven mit 1000, 2000, 4000, 10.000, 20.000 und 37671 Messpunkten pro Sekunde. Und in Y-Richtung 12, 14 oder 16 Bit Auflösung. Das habe ich im Lauf der Zeit noch mit mehreren Dateiformaten verkompliziert.
Es ist beispielsweise nicht mehr ganz trivial, beliebige Kurven maßstabsgerecht übereinander zu legen. Das kann dem Benutzer aber egal sein, soll sich die Software drum kümmern.

An genau diesem Punkt tut sich noch eine Möglichkeit auf: Auch diejenigen, die mit eigenen Meßvorrichtungen Schub/Zeitkurven aufzeichnen, könnten ihre Daten prinzipiell in dieses Programm einspeisen und so beispielsweise mit den von uns aufgezeichneten Kurven überlagern. Oder sonstwas damit treiben.

Zum Beispiel hier im Archiv eine Bibliothek aus Original Messdaten aufbauen. Interessenten gucken dann nicht mehr wie bisher auf eine statische Bitmap irgendwo im Netz, sie laden sich vielmehr die aktiven Datensätze samt Software herunter und arbeiten damit, füttern die Daten z.B. in ein Flugbahnberechnungsprogramm. Nur mal so dahingedacht.

Wer macht mit?

Zitat:

---

Original geschrieben von Peter
aber dem einen oder anderen wäre es sicher lieber, er könnte die Kurven nach eigenen Wünschen überlagern, dehnen, berechnen oder einfärben. Dazu braucht man die passende Software. An der mach ich gerade Aufräumarbeiten; es wäre also vorstellbar, eine geeignete Version als Freeware an Interessierte abzugeben.

---

Wenn es nur darum geht, mit Kurven aus verschiedenen Quellen zu arbeiten, dann scheint es mir etwas übertrieben, überhaupt noch Software zu schreiben. Es gibt freie Software in grosser Zahl, mit der man als Datenfiles vorliegende Datensätze graphisch darstellen kann, bzw vorgängig verschiedensten Operationen unterwerfen kann. Ganz unmittelbar kommen mir da in den Sinn:
- gnuplot
- Ploticus (kann auch SVG, SWF, PS, EPS und damit PDF)
- Tobi Oetikers RRDtool
- Das R Projekt: http://www.r-project.org/
Alle diese Produkte sind auf allen Plattformen frei verfügbar.

Wer (wie ich) Zugang zu maple oder Mathematica hat (zum Beispiel an einer Hochschule), wird den Gesamtimpuls wohl auch mit deren numerischer Integrationsfunktion berechnen. Das ist allerdings so einfach, dass man es auch mit einem Dreizeiler in awk machen kann.

Und auch bei den Datenformaten gibt es ja auch schon einige. Jedes Simulationsprogramm scheint von der Idee besessen, ein eigenes Format definieren zu müssen. Das Hauptverdienst dieser Formate ist aber, dass sie auch die "Metadaten" zu einem Motor festhalten. Dazu bräuchte es dann nur noch ein ganz winziges Frontend-Programm (zum Beispiel ein kleines Perl-Script), welches aus diesen bekannten Motorbeschreibungsfiles Graphiken produzieren kann.

Zitat:

---

Zum Beispiel hier im Archiv eine Bibliothek aus Original Messdaten aufbauen. Interessenten gucken dann nicht mehr wie bisher auf eine statische Bitmap irgendwo im Netz, sie laden sich vielmehr die aktiven Datensätze samt Software herunter und arbeiten damit, füttern die Daten z.B. in ein Flugbahnberechnungsprogramm. Nur mal so dahingedacht.

---

Vielleicht könnte man sich ja viel Arbeit sparen, wenn man mit John Coker Kontakt aufnehmen würde, immerhin hat er mit http://www.thrustcurve.org genau eine solche Datenbank aufgebaut, in der zu verschiedensten Motoren in verschiedensten Formaten Graphiken und Datenfiles abgerufen werden können. Auch technologisch liesse es sich wohl leicht integrieren, die Chancen stehen gut, dass der Tomcat des Forums mit Cokers JSPs umgehen könnte.

Ich finde das von Peter eine klasse Idee. Die ganzen existierenden
Tools sind zwar bestimmt toll, scheinen mir aber für das eigentliche
Problem hier überdimensioniert bzw. zu wenig spezifiziert. Ich fände
ein einfach zu bedienendes Programm, mit dem ich über ein paar
Mausklicks ruckzuck Impuls, Brenndauer, Max-/Dauerschub, spez.
Impuls,... bekomme wesentlich interessanter, als mich in die
anderen Tools einzuarbeiten und herauszutüfteln, wie ich meine
Belange damit erfüllen könnte.
Peter, welche Unterstützung brauchst Du für ein solches Tool?
Letzten Monat bei Achim zu Hause habe ich Dich auch angesprochen,
die Daten in einem Excel-lesbaren Format anzubieten. Damit könnte
man auch schon mal eine Menge anfangen.
Viele Grüße,
Oliver

Da könnte das Mißverständnis bestehen, daß ich mit der Entwicklung eines eigenen Tools anfangen möchte. Mitnichten, das Teil existiert bereits, und es ist auf die bekannten beiden Prüfstände ausgelegt. Es produziert z.B. Auswertungen wie die unten abgebildete.

Wenn nun jemand auf einem dieser Prüfstände einen ihn interessierenden Motor vermessen bekommt oder einen bestehenden Datensatz näher auswerten möchte, dann liegt es doch wohl nahe, das mit der Software zu tun, die den Datensatz erzeugt hat. Da können mit Verlaub weder dosboxige Gnus noch awk Dreizeiler mithalten. Ich will mich nicht auch noch auf den Laufsteg intellektueller Eitelkeiten begeben, aber die genannten Tools kennen weder das Dateiformat (und dürften allein schon daran scheitern), noch sind sie in irgendeiner Weise auf Motortestzwecke spezialisiert.

Daten von Thrustcurve: Mir sind da als Download Angebote z.B. das Rasp oder das RocSim Format begegnet. Die enthalten ca. 20 oder 30 Meßpunkte für den gesamten Abbrand. Unsere Prüfstandsdaten bestehen aus 1000 bis 37.000 Messpunkten pro Sekunde Brenndauer- das ist also nicht vergleichbar und hat auch nicht dieselbe Zielsetzung. Mal ganz abgesehen davon wirst Du die BC-Motoren auf Thrustcurve ebenso wenig finden wie der Hybridentwickler seinen Eigenbau, logischerweise. Es gäbe also schon Gründe, eine eigene Bibliothek aufzubauen.

@Oliver: Ich hab da eine gute und eine gute Nachricht für Dich :

a) Klar, ich schick Dir das Installationspaket zu und auch die Datensätze, von denen ich mir vorstellen kann daß sie Dich besonders interessieren.
b) Unterstützung ist nicht notwendig, gib mir nur noch ein paar Tage Zeit.

Beispiel für eine Schubauswertung

Geändert von Peter am 26. August 2006 um 21:48

Die Ungenauigkeit der Treibsätze dürfte aber so groß sein, dass zwischen 30 und 30 000 Datensätzen pro Sekunde nahezu kein Unterschied besteht -- selbst bei BCs.

Fällt mir nur grad so ein (nach zwei, drei Pastis...).

Oliver

Zitat:

---

Original geschrieben von Oliver Arend

Die Ungenauigkeit der Treibsätze dürfte aber so groß sein, dass zwischen 30 und 30 000 Datensätzen pro Sekunde nahezu kein Unterschied besteht -- selbst bei BCs.

---

Wenn es nur darum geht, eine schematische Vorstellung von der Abbrandkurve zu vermitteln, quasi als Etikett für die Verpackung, und wenn man keine großen Ansprüche stellt, dann sind 30 Messpunkte sicher ausreichend. Selbst zur Flugbahnberechnung genügt das, wir bewegen unsere Raketen ja ohnehin allermeistens in einem Flugkorridor von vielleicht 100-600 Metern Höhe. Und mehr als will Thrustcurve nach meiner Interpretration auch nicht bedienen.

Aber es gibt da noch die anderen, die spannenden Fragen für den "Motorenforscher". Kann ich z.B. aus einer kleinen, örtlichen Unregelmäßigkeit der Verbrennungskurve auf eine Luftblase im Treibstoff schließen? Kann ich aus der Kurve eines platzenden Held 5000 etwas aussagen über die Ursache? Kann ich aus dem Verlauf einer Hybridkurve schließen, in welche Richtung ich meinen Motor optimieren muß?

Und wenn ich in diese Richtung denke, dann kann ich fast garnicht genug Messpunkte pro Sekunde haben.

Zitat:

---

Original geschrieben von Peter
Aber es gibt da noch die anderen, die spannenden Fragen für den "Motorenforscher". Kann ich z.B. aus einer kleinen, örtlichen Unregelmäßigkeit der Verbrennungskurve auf eine Luftblase im Treibstoff schließen? Kann ich aus der Kurve eines platzenden Held 5000 etwas aussagen über die Ursache? Kann ich aus dem Verlauf einer Hybridkurve schließen, in welche Richtung ich meinen Motor optimieren muß?

Und wenn ich in diese Richtung denke, dann kann ich fast garnicht genug Messpunkte pro Sekunde haben.

---

Dazu muss ich noch ganz andere Dinge wissen. Zum Beispiel muss ich Auskunft über das Schwingverhalten des Prüfstandes bis 18.5kHz haben. Und wenn ich tatsächlich vermute, dass jenseits von 18.5kHz noch irgend ein Signal vorhanden ist, dann muss mein Messsignal vor dem Digitalisieren durch einen Tiefpass gehen, da die hohen Frequenzen sonst "falsche" Information liefern.

Die Oberflächenvergrösserung durch eine 2mm grosse Blase in einem 10cm langen Grain mit einem Kerndurchmesser von 1cm ist etwa ein Tausendstel. Mit 10bit Auflösung ist das schon mal grundsätzlich nicht zu sehen. Dieses Ereignis würde auch deutlich länger als 0.1 Sekunden dauern, d.h. man könnte es auch bei 30Hz Abtastrate immer noch sehen. Kleinere Blasen verlangen eine gute Auflösung von Sensoren und Elektronik.

Und dann wäre da noch das Problem, auf das Oliver angespielt hat: Um eine Blase zu detektieren, braucht man einen normalen Brennverlauf, der mit grösserer Genauigkeit reproduziert werden kann als das zu messende Ereignis. Solange man den nicht hat, sind gar keine Aussagen über Gründe von Abweichungen möglich, denn genau genommen gibt es die Abweichungen mangels Referenz gar nicht.

Die Hybridoptimierung kann sicher auf Prüfstanddaten aufbauen. Im hohen Frequenzbereich sind vor allem akustische Phänomene interessant, die Resonanzen der Brennkammer und des Tanks geben an, in welchem ungefähren Frequenzbereich diese zu erwarten sind. Einige hundert Hz dürfte das äusserste sein, was man hier noch sieht, mit 1000 Samples/s ist man also immer noch sehr gut bedient. Ausserdem: einen Feedback darüber, ob ein Optimierungsversuch wirklich etwas gebracht hat, erhält man erst, wenn der "optimierte" Motor signifikant besser ist. Also reproduzierbar ausserhalb des (grossen) Streubereichs seines Vorgängers. Der Streubereich dürfte mit 10bit immer noch weit grösser sein als die Auflösung des AD-Wandlers.

Wenn man übrigens tatsächlich vermutet, dass der Anteil hoher Frequenzen wesentlich ist, könnte man den Impuls auch analog integrieren, so wie es zum Beispiel der DDC112 macht. So bekäme man selbst bei 100Hz Samplingrate ein wesentlich genaueres Resultat als mit numerischer Integration, ohne Aliasingeffekte.

Habe ich auch gerade gedacht. Rein aus dem Bauch heraus unterscheidet sich der "Frequenzgang" eines Prüfstandes mit angeschraubtem Prüfling doch erheblich von dem einer HiFi-Box. Das liegt daran, daß derartig große Massen sich einfach nicht so schnell bwewgen "wollen". Man sehe sich die Membran eines Hochtöners, oder die eines Mikrophones an. Im Bereich weniger Bruchteile eines Grammes...

Bei Frequenzen jenseits von ein paar hundert Hz wird man nur noch "Rauschen" messen.

Grüße
Malte

Zitat:

---

Original geschrieben von Andreas Mueller
Die Oberflächenvergrösserung durch eine 2mm grosse Blase in einem 10cm langen Grain mit einem Kerndurchmesser von 1cm ist etwa ein Tausendstel. Mit 10bit Auflösung ist das schon mal grundsätzlich nicht zu sehen. Dieses Ereignis würde auch deutlich länger als 0.1 Sekunden dauern, d.h. man könnte es auch bei 30Hz Abtastrate immer noch sehen. Kleinere Blasen verlangen eine gute Auflösung von Sensoren und Elektronik.

---

Wo Du die 10 Bit hernimmst ist mir unklar. Wie eingangs erwähnt reden wir hier über 12, 14 und 16 Bit. Für den nicht so technischen Mitleser ist das die 4-fache, 16-fache und 64-fache Auflösung. Der von Dir beschriebene Treibstoffblock ist ein heftiger Innenbrenner. Weshalb da eine kleine Blase die relative Ewigkeit von 100ms wirken soll, kann man zumindest anzweifeln.

Zitat:

---

Und dann wäre da noch das Problem, auf das Oliver angespielt hat: Um eine Blase zu detektieren, braucht man einen normalen Brennverlauf, der mit grösserer Genauigkeit reproduziert werden kann als das zu messende Ereignis. Solange man den nicht hat, sind gar keine Aussagen über Gründe von Abweichungen möglich, denn genau genommen gibt es die Abweichungen mangels Referenz gar nicht.

---

Da will ich doch gleich mal ein Beispiel liefern, das in einem Aufwasch gleich folgenden Kommentar aufgreift:

Zitat:

---

Original geschrieben von hybrid
Bei Frequenzen jenseits von ein paar hundert Hz wird man nur noch "Rauschen" messen.

---

Falsch- zum Glück. Es sei denn man möchte die folgende, mit 37.000 Messungen/s aufgenommene Kurve als "reines Rauschen" abtun:



Aber zurück zu den "kleinen Störungen", ob Miniblasen oder sonstiges. Im rot umrandeten Bereich seht ihr zwei kleine Spitzen. Die habe ich hier mal vergrößert:



Man sieht jetzt deutlich die beiden scharfen Anstiege, die weder was mit "Rauschen" zu tun haben noch mit reinem Zufall. Übrigens dauert der Anstieg links 2,5 ms und der rechte 2,2 ms. Es handelt sich übrigens um einen Stirnbrenner, gemessen mit 14 Bit Auflösung. Und speziell diese Elektronik ist dem Winfried sehr rauscharm gelungen, finde ich.

Und die Sache mit der "fehlenden" Referenz erweist sich im Blick auf beide Diagramme als zu theoretisch gedacht. Die Wirklichkeit kann ab und an erfrischende Überraschungen bereithalten. Zum Beispiel die, daß die Stetigkeit der Kurve selbst eine sehr gute Referenz sein kann.

Geändert von Peter am 27. August 2006 um 23:56

Zitat:

---

Zitat:

---

Original geschrieben von hybrid
Bei Frequenzen jenseits von ein paar hundert Hz wird man nur noch "Rauschen" messen.

---

Falsch- zum Glück.

---

Die Graphik hat eine Auflösung von ca 0.2ms, d.h. alles was man dort sieht, hätte man auch mit einer Samplingrate von 5kHz gesehen. Da der Anstieg 2ms dauert, hätte man ihn auch noch mit 500Hz gesehen, wie hybrid vermutet hat.

Geändert von Andreas Mueller am 28. August 2006 um 06:20