Zitat:

---

An der Stelle darf man einen wichtigen Punkt nicht aus den Augen verlieren: Das Auslesen des Prüfstands. Mit dem heutigen kompakten & binären PS3 Format dauert das rund 1 Minute. Wie schon weiter oben vorgerechnet würde man bei Umstellung auf "menschenlesbares Textformat" mit dem Zehnfachen rechnen müssen, bei XML eher noch mehr.

---

Das ist ein Punkt, dem mein Prüfstand nicht als Problem hat. Der ist direkt an einem Notebook angeschlossen über USB. Wenn ich mal eine USB-Verlängerung kaufe, lebt das Notebook auch sicherer. Sobald die Messung fertig ist, poppt das Fenster zum speichern der Daten auf. Das geschieht sofort da ich keinen MC auslesen muss.
Daher sehe ich kein Problem bei meinem Prüfstand das Dateiformat beliebig zu gestalten. Habe halt etwas mehr Rechenleistung zur Verfügung als ein MC.

Gruß

Neil

Geändert von Neil am 09. Oktober 2006 um 11:37

Die Übertragung der Daten vom Prüfstand zum Rechner sollte natürlich möglichst kompakt (und damit binär) erfolgen, keine Frage!
Meine Samplerate ist nicht zuletzt deshalb limitiert, weil ich mangels Speicher auf dem AVR die Daten zuverlässig in Echtzeit "rübergepumpen" muß.

Der XML-Vorschlag zeigt zwar, daß es prinzipiell möglich ist, aber auch wie unsinnig er ist. Die eigentlichen Nutzdaten stecken in einem CDATA Container. So kann man das dann weder einfach mal in Excel, noch mit einem selbstgeschriebenen Programm importieren ... Operation geglückt, Patient tot.

Grüße
Malte

Hi,

bei einer sehr hohen Samplerate wird so wieso der Speicher ein Limit setzen. Es geht hier ja auch nicht um die Komunikation Messstand <-> Computer sondern um eine Datei die jeder Prüfstandbetreiber mit jedem anderen austauschen kann. Ersteres wäre ja noch genialer, dann kann man auch die Prüfstände untereinander austauschen.

Ich fasse jetzt mal kurz zusammen was wir hier für Punkte bereits haben:

1. Einheiten getrennt von Daten darstellen damit das Programm die Daten frei interpretieren kann. Die Einheiteninformation dient dazu die Kurve richtig darzustellen. Z.B. speichere ich meine Daten in Newton, das steht in der Datei. Peter will die aber in Pond angezeigt bekommen. Sein Programm liest die Daten aus meiner Datei und macht anhand der Dateiinfo und seinem Setup der Software aus Newton Pond.

2. Es sollte doch trotz großer Datenmenge eine Menschenlesbare Datei sein. Dies erleichtert das erstellen seines eigenen Programms.

3. Es werden keine Bytewerte gespeichert. Das setzt vorraus, das in der Datei die Trennzeichen definiert werden. Also "." oder "," für Dezimaltrennzeichen oder 1000er Gruppen. Vom Prinzip kann es aber auch jedes Zeichen sein. (siehe Punkt 6)

4. Die Samplerate soll variable sein. Jeder Messwert bekommt seine Zeit. Das erlaubt z.B. auch stilisierte Kurven darzustellen indem die Zeitabstände der Werte variabel sind.

5. Die Datei enthält Informationen über die Kalibirerung. Das kann z.B. eine Stützstellenliste.

6. Keine Sonderzeichen sondern nur ASCII Zeichensatz.

Gruß

Neil

So wirst du deine Datei aber extremst aufblasen^^
Speziell die Werte für den jeweiligen Timecode werden dir eine Menge Platz rauben.
Wie Peter schon geschrieben hat, ist die effezienteste Art, die Daten so zu speichern, wie sie der Computer intern auch verarbeitet.
Vielleicht kann man das ganze ja kombinieren, sprich eine INI-File ähnliche Aufteilung (von mir aus auch XML^^) nach folgendem Muster:


Kalibrierwerte, Temperatur etc.

Einheiten für Zeit, Messwert etc.

Timewert=Datenwert
...

Mit einem guten Hexeditior kann man dann durch die Werte Scrollen ... Ich würde übrigens auf Zeilenumbrüche verzichten, evtl. kann man auch das = rausnehmen ... man spart bei jedem Datensatz immerhin 1-3 Byte^^

mfG

Markus

Hi,

zu dem Thema kann man nur sagen "Jein". Wenn du dir zu 100% sicher bist, das du wirklich mit der Samplerate Daten aufnimmst, dann ist das okay.
Wenn du dir nicht sicher bist, dann brauchst du für jede Messung einen Zeitstempel. Außerdem hat der Zeitstempel wie gesagt den Vorteil, das ich asynchron Datenpunkte speichern kann. Wenn ich wirklich nur eine Kurve mit den Kennwerten speichern will, hat das ein Vorteil da dort die Daten weniger werden. So kann man stilisiert eine 10s dauernde Kurve mit z.B. 5 Punkten beschreiben. Hast du aber eine fixe Samplerate, so musst du für diese Kurve wenn du den Peak in der Kurve mit nehmen willst, evtl. eine 1/10s Auflösung haben, was dann wiederum 100 Datensätze wären.
Ich nutze wie gesagt einen USB-AD-Wandler. Der ist in der Lage mir über die Messung eine Aussage zu geben. so gibt er mir nachher die tatsächliche Samplerate an oder ob irgend ein Fehler in der Messung war.
Hier muss die Frage gestellt werden, wie wichtig ist Speicherplatz? Es gibt 1GB Sticks für 15€, muss ich da um jedes Byte kämpfen?

Gruß

Neil

Wenn es ums Platzsparen geht: einfach komprimieren. Textdateien dieser Art schrumpfen da locker auf 10% Ihrer Größe.

Grüße
Malte

Zitat:

---

Frage 3: Ist es überhaupt sinnvoll, zwei Formate für dieselbe Sache zu verwenden?

---

Wenn es wirklich die selbe Sache wäre. Soweit ich das verstehe, ist das Auslesen des Prüfstandes nicht einmal inhaltlich dasselbe wie die Dokumentation von Motordaten. Nicht einmal die Daten sind deckungsgleich. Zum Beispiel braucht ein Prüfstand nicht zu wissen, wie der Motor heisst, wer der Prüfer ist, und an welchem Datum die Prüfung erfolgte, für die Dokumentation ist das eher wesentlich. Die Anwendung, die die Daten aus dem Prüfstand ausliest, wird also in jedem Fall Informationen hinzufügen, um überhaupt erst ein zweckmässiges Austauschformat herzustellen. Da Reinhard oben ein Austauschformat beschrieben hat (da es offensichtlich Informationen enthält, welche der Prüfstand wohl kaum wissen kann), reden wir hier von einer Schicht, in der weder die Auslesegeschwindigkeit noch die Datenmenge wirklich relevant sind.

Zur Geschwindigkeit: es gibt USB-serial und Ethernet-serial adapter, die spielend 1Mbps schaffen. Da wir bei der vorgeschlagenen Datenrate ja wohl ohnehin nicht davon ausgehen können, dass die Daten in Echtzeit übermittelt werden (obwohl das mit Ethernet eigentlich kein Problem wäre und bei modernen Messsystemen auch durchaus üblich ist), geht es nur darum, die paar hundert kB Integer-Daten zu transferieren. Bei geeignet gewählten Tags dürfte das auch in XML mit 20 Byte pro short integer möglich sein (18 Bytes overhead). Zwei Sekunden Schubdaten bei 50kHz wären dann 8Mbit, also in 8Sekunden zu übermitteln. Die Rate schaffen übrigens auch einige AVRs.

Zitat:

---

Wie Peter schon geschrieben hat, ist die effezienteste Art, die Daten so zu speichern, wie sie der Computer intern auch verarbeitet.

---

Nein. Das Wort effizient ist ohne Qualifizierung inhaltsleer. Heiss "effizient" nun "speicherplatzeffizient" oder zum Beispiel effizient im Bezug auf den CPU-Aufwand bei Rechnungen? So sind zum Beispiel Ganzzahlen in einem Computer optimal geeignet für Ganzzahlarithmetik, aber sie sind bei weitem nicht das speicherplatzeffizienteste Codierverfahren für einen Datensatz, von dem man annimmt, dass er im wesentlichen eine stetige Funktion beschreibt. Nur schon eine Codierung nur der Differenzen zwischen aufeinanderfolgenden Werten, die auch auch führende Nullen in Ganzzahlen wegoptimiert, dürfte einen Faktor zwei ermöglichen. Wavelet-Methoden kombiniert mit Huffman-Codierung dürften etwa einen Faktor 10 hinkriegen.

Übrigens sind 16bit Ganzzahlen auch nicht geeignet, wenn es um die Berechnung des Gesamtimpulses geht. Da müsste nämlich mindestens die Summe aller Datenwerte bestimmt werden. Das führt bei 2 Sekunden mit 50kHz bereits zu einem möglichen Overflow wenn der Sensor nur 1bit Auflösung hat. 16bit sind nicht aus der Luft gegriffen: wenn man nichts sagt, ist das, was mir der Compiler auf einem AVR für int gibt. In diesem Fall wären also Floats geeignet. Sie wären sogar speicherplatzeffizienter als eine Textdarstellung: ein float braucht nur 4 Bytes, seine Textdarstellung bis auf ein paar Ausnahmen deutlich mehr.

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

Zitat:

---

Original geschrieben von Andreas Mueller

Zitat:

---

Frage 3: Ist es überhaupt sinnvoll, zwei Formate für dieselbe Sache zu verwenden?

---

---

Die Anwendung, die die Daten aus dem Prüfstand ausliest, wird also in jedem Fall Informationen hinzufügen, um überhaupt erst ein zweckmässiges Austauschformat herzustellen.Richtig. Bei unseren beiden Prüfständen habe ich das ganz einfach gelöst: 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?

"Menschenlesbar" ist übrigens relativ. Eine XML Datei mit heftig vielen Tags liest sich äußerst unangenehm. Kann jeder nachvollziehen, wenn er eine solche Datei mal in einem gewöhnlichen Browser öffnet. Dagegen ist das Betrachten von kompakten, gut strukturierten Binärdaten im Hexeditor eine reine Erholung.

Zitat:

---

"Menschenlesbar" ist übrigens relativ. Eine XML Datei mit heftig vielen Tags liest sich äußerst unangenehm. Kann jeder nachvollziehen, wenn er eine solche Datei mal in einem gewöhnlichen Browser öffnet.

---

Das ändert sich schlagartig, wenn der Leser auch mit XSL Stylesheets umzugehen versteht. Nur ist dann eben sehr hilfreich, wenn alle Datenelemente mit XPath adressierbar sind. Als wenn schon XML, dann richtig.