Raketenmodellbau.org Portal > Forum > Experimental & Forschung > Motorprüfstände > Für Prüfstände: Das .rmb Format
Du kannst keine neue Antwort schreiben
Seiten (8): « 1 2 [3] 4 5 6 7 8 »

Autor Thema 
osmadie

SP-Schnüffler


Supervisor

osmadie

Registriert seit: Feb 2006

Wohnort: Rhein-Pfalz-Kreis

Verein: Solaris-RMB e.V.

Beiträge: 515

Status: Offline

Beitrag 6770922 [Alter Beitrag23. April 2008 um 21:46]

[Melden] Profil von osmadie anzeigen    osmadie eine private Nachricht schicken   osmadie besitzt keine Homepage    Mehr Beiträge von osmadie finden

Jetzt komme ich...
Mir gefällt die Variante von Pierre sehr gut.

Bei meinem Prüfstand gilt derzeit folgendes:

- Maximal 6 Kanäle gleichzeitig, davon 4 analog, 2 digital
- Rate je Kanal einstellbar von 10 bis ca. 15000 Samples/s
- Maximalrate für alle Kanäle zusammen ca. 9000 bis 15000 S/s
- Zeitstempel wahlweise aktivierbar
- Ereignis-Marker wahlweise aktivierbar (z.B. Ereignis Zündung_ein wird mit Zeitstempel abgelegt)
- 10Bit Auflösung

Die Daten werden während der Aufzeichnung paketweise per I²C-Bus in ein externes EEPROM geschoben. Um hier keinen Flaschenhals zu erzeugen, habe ich mich auf maximal 4Byte pro Messwert beschränkt.

Die 4 Byte der Messwerte sind wie folgt aufgeschlüsselt:
- 3 Bit für die Kanal-Nummer (1 bis 6, 0 ist ungültig, 7 ist der Ereignis-Kanal)
- 10 Bit für den AD-Wert
- 19 Bit für den Zeitstempel

Der Zeitstempel hat eine Auflösung von 0,8µs, d.h. er läuft alle 0,42s über. Das ist dann beim Auswerten auf dem PC entsprechend zu beachten.

Am Anfang wird ein Header erstellt, der Infos wie Datenrate, Aufnahmeparameter, aktive Messkanäle,... enthält.

Alle Messdaten werden in 128Byte-Päkchen ans EEP geschickt. Dabei hat jedes Paket am Anfang noch einen 2Byte-Blockzähler, damit beim Auslesen der Daten ein einfacher Konsistenz-Check gemacht werden kann.

Im PC werden die Daten so wie sie kommen erst mal als Roh-Datensatz in ein eigenes Verzeichniss geschrieben und schreibgeschützt.

Anschließend werden die Daten geprüft und nach der Prüfung werden die Blockzähler entfernt. Der Rest wird mit zusätzlichen Benutzerdaten ergänzt und so als eigentliche Messdatei gespeichert.

Ich denke, der Ansatz von Pierre, bei der Hardware anzufangen, ist richtig. Ich würde aber trotzdem bei den Aufnahmedaten keine Nullen auffüllen, da diese die Aufnahmerate beim Speichern während der Aufnahme unnötig belasten. Ich finde es besser, die Aufnahmedatenstruktur im Header so zu beschreiben, dass nur das gespeichert werden muss, was auch wirklich benötigt wird.

Ich schlage deswegen vor, den Header so zu gestalten, dass alle derzeitig vorhandenen Aufnahmevarianten damit erfasst werden können.

Vorschlag für den Header und den Rest der Daten:
- 10 Byte Kennung für Start der Header-Daten = Erkennungs-Code für den Dateityp
- 2 Byte Versionsnummer für das Speicherformat (auch wenn wir uns viel Gedanken machen... irgendwann brauchen wir auch mal eine neue Version...)
- 20 Byte Name der Aufnahme (wer sowas unterstützen will...)
- 1 Byte Messwert-Datensatz: Anzahl a der Bits für die Kanal-Kennung
- 1 Byte Messwert-Datensatz: Anzahl b der Bits für den Zeitstempel (=0 bei Aufnahme ohne Zeitstempel)
- 1 Byte Messwert-Datensatz: Anzahl c der Bits für den AD-Wert
- 2 Byte Größe eines individuellen Speicherblocks
- n Byte Daten des individuellen Speicherblocks (nutze ich z.B. für sonstige Aufnahme-Parameter)
- 1 Byte Anzahl der genutzten Kanäle
- 1 Byte Anzahl der Sensoren (ist nicht zwangsläufig gleich Anzahl der genutzten Kanäle)
Für jeden genutzten Kanal:
- 1 Byte Nummer des Kanals
- 12 Byte Kennung des angeschlossenen Sensors
- 2 Byte Aufnahmerate des Kanals in Samples/s
Für jeden Sensor:
- 12 Byte Sensor-Kennung
- 2 Byte Anzahl der Bytes für technische Daten zum Sensor
- n Byte technische Daten zum Sensor (z.B. Technologie analog/digital, AD-Wertebereich, Messbereich, Faktor für Phys-Wert...)
- 1 Byte Anzahl der Kalibrierzeilen
- n * 4Byte Kalibrier-Kennlinie (2 Byte AD-Wert, 2Byte Phys-Wert)
- 10 Byte Ende-Kennung für den Header = Start für die Messdaten
- N * x Byte Messwerte
- 10 Byte Ende-Kennung für die Messdaten = Start für eine eventuelle Mini-Auswertung der Daten
- 2 Byte Anzahl der Bytes für Auswertung der Messung
- n Bytes Daten zur Auswertung der Messung
- 10 Byte Ende-Kennung der Datei

Die Anzahl der Bytes für den Messwert ergibt sich aus den Anzahlen der Bits a+b+c (s.o.)
Es muss festgelegt werden, in welcher Reihenfolge die Bits in dem Messwert-Datensatz zu stehen haben.
Beispiel:
a=3
b=19
c=10
=> 32Bit = 4Byte. Aufteilung: a=MSB, c=LSB also:

aaab bbbb bbbb bbbb bbbb bbcc cccc cccc
MSB LSB

Fehlt noch was? :-)

Gruß,
Oliver


Der erste Schluck aus dem Becher der Wissenschaft führt zum Atheismus, aber auf dem Grund des Bechers wartet Gott.
Werner Heisenberg
CharlyMai

Foren-Prediger


Administrator

CharlyMai

Registriert seit: Mär 2005

Wohnort: Hannover

Verein: SOLARIS-RMB e.V. (P2;T2) / AGM / TRA#21598

Beiträge: 1970

Status: Offline

Beitrag 6770923 [Alter Beitrag23. April 2008 um 22:28]

[Melden] Profil von CharlyMai anzeigen    CharlyMai eine private Nachricht schicken   Besuche CharlyMai's Homepage    Mehr Beiträge von CharlyMai finden

Da hier ja die Bestrebung ist, das Datenformat einheitlich zu gestalten, würde ich immer noch zu einer "Festen" Variante tendieren..

Da normalerweise das auslesen der Daten NACH der eigentlichen Messung erfolgt, bin ich immer noch für ein auffüllen mit Nullen beim SENDEN (wer wie was in dem Messtand speichert, und sei es auf Lochstreifen steht hier nicht zur Debatte)

Das mag im Moment ein ziemliches "Nullenfüllen" sein, erleichtert jedoch Immens
a) das senden der Daten, da ich nicht erst den String zusammensetzen muss
b) Brauche keine "Alphanumerische" Eingabe von "Aufnahmedaten"
c) Kann in der Software später alles ausfiltern, was mich stört, und mir fehlen keine Daten ...
d) habe eine Definierte Stelle wo die Messdaten liegen
e) auch Anfänger (Einsteiger) können sagen welches Bit in dem String was zu bedeuten hat, denen wird der Einstieg in die Programmierung erleichtert ...

Weiterhin gilt festzulegen .... Die Daten ZUM Messtand (wenn denn erforderlich)

Auch hier gilt, das (wenn gewünscht) nicht die Kalibrierung eines Sensors beim anderen den Zündkanal auslöst !!

Hier kann ich persönlich nicht aus Erfahrung sprechen, da ich keinen Messtand habe, aber auch hier bin ich für eine Feste Organisation der Daten (Festgelegter nicht Dynamischer String). Nun gilt zu klären, was alles an einen Messtand geschickt werden müsste ...


viele Grüße
Pierre





Geändert von CharlyMai am 23. April 2008 um 22:30


•"Der Glaube an eine bestimmte Idee gibt dem Forscher den Rückhalt für seine Arbeit.
Ohne diesen Glauben wäre er verloren in einem Meer von Zweifeln und halbgültigen Beweisen." Konrad Zuse

•Konstruiere ein System, das selbst ein Irrer anwenden kann, und so wird es auch nur ein Irrer anwenden wollen.

SOLARIS-RMB e.V. AGM
osmadie

SP-Schnüffler


Supervisor

osmadie

Registriert seit: Feb 2006

Wohnort: Rhein-Pfalz-Kreis

Verein: Solaris-RMB e.V.

Beiträge: 515

Status: Offline

Beitrag 6770925 [Alter Beitrag23. April 2008 um 23:02]

[Melden] Profil von osmadie anzeigen    osmadie eine private Nachricht schicken   osmadie besitzt keine Homepage    Mehr Beiträge von osmadie finden

Ich bin mir sicher, wenn wir ein starres Format vorgeben, wird dieses keine Akzeptanz finden. Ich für meinen Teil möchte auf keinen Fall auf Messrate verzichten, nur weil wegen dem starren Format pro Messwert zusätzlich 6 Byte Nullen in der Hardware rumgeschoben werden müssen obwohl nur 2 oder 4 Byte benötigt werden.

Das ist ja aber gerade der Vorteil eines "einheitlichen flexiblen" Headers. Das Format des Headers ist fest vorgegeben und Varianten sind nur an den vorgegebenen Stellen erlaubt. Damit ist es weiterhin möglich, individuelle Daten zusätzlich mit anzugeben. Spezielle Software kann mit diesen Daten dann noch weiter rumspielen. Aber alles was für die Auswertung der Messung existenziell notwendig ist, muss Teil der fixen Header-Definition sein. Damit können alle anderen Programme, die das Format kennen, nicht aber den individuellen Teil, immernoch die komplette Messung auswerten.

Für diesen "starren" Teil können wir dann eine Auswerte-Routine hier im Forum zur Verfügung stellen, die dann jeder in sein Programm einbinden kann. Hier müssen wir dann noch festlegen, in welcher Form die ausgewerteten Daten vorliegen sollen.

Den Header muss man für eine Aufnahme nur einmal aufbauen. Wenn dieser etwas größer ausfällt, ist das für die Aufnahme selbst egal. Diese kann nämlich weiterhin superschnell und supereffizient ablaufen.

Gruß,
Oliver


Der erste Schluck aus dem Becher der Wissenschaft führt zum Atheismus, aber auf dem Grund des Bechers wartet Gott.
Werner Heisenberg
CharlyMai

Foren-Prediger


Administrator

CharlyMai

Registriert seit: Mär 2005

Wohnort: Hannover

Verein: SOLARIS-RMB e.V. (P2;T2) / AGM / TRA#21598

Beiträge: 1970

Status: Offline

Beitrag 6770927 [Alter Beitrag23. April 2008 um 23:08]

[Melden] Profil von CharlyMai anzeigen    CharlyMai eine private Nachricht schicken   Besuche CharlyMai's Homepage    Mehr Beiträge von CharlyMai finden

Wer soll denn hier auf eine Messrate verzichten ???

Ich Denke Du hast das System nicht verstanden ...

Zitat:
das auslesen der Daten NACH der eigentlichen Messung erfolgt


letzter Beitrag !!

Wie du Deine Daten in Deinem Prüfstand speicherst ist doch Schnuppe .... Egal .. 88 .. Lochstreifen ....

NACH der Messung ..... Da ist deine Messrate vorbei ... gelle ??? Werden die Daten über ein DEFINIERTES FESTES Protokoll übertragen ... und da brauchste dann NICHT auf Messrate zu verzichten sondern lediglich ein paar Sekunden MEHR ÜBERTRAGUNGSZEIT opfern ....

Wenn Daten DIREKT Übertragen werden sollen bei den angestrebten Geschwindigkeiten empfehle ich sowieso ein DualPortet RAM wo auf einer Seite der Messprozzie reinschreibt und auf der anderen Seite der Transfer Prozzie ausliesst ...

viele Grüße
Pierre

Geändert von CharlyMai am 23. April 2008 um 23:13


•"Der Glaube an eine bestimmte Idee gibt dem Forscher den Rückhalt für seine Arbeit.
Ohne diesen Glauben wäre er verloren in einem Meer von Zweifeln und halbgültigen Beweisen." Konrad Zuse

•Konstruiere ein System, das selbst ein Irrer anwenden kann, und so wird es auch nur ein Irrer anwenden wollen.

SOLARIS-RMB e.V. AGM
Neil

99.9% harmless nerd


Administrator

Neil

Registriert seit: Aug 2000

Wohnort: Delft

Verein: SOLARIS

Beiträge: 7776

Status: Offline

Beitrag 6770933 [Alter Beitrag24. April 2008 um 08:08]

[Melden] Profil von Neil anzeigen    Neil eine private Nachricht schicken   Neil besitzt keine Homepage    Mehr Beiträge von Neil finden

Hi,

mein Prüfstand speichert nicht und wird auch nicht über eine COM sondern USB ausgelesen.
Ich denke auch das man hier gerade zwei Diskussionen führt. Einmal wie man die Daten in einer Datei speichert und einmal wie man die vom Prüfstand in den Computer bekommt.
Wir sollten hier nur über das Speichern in einer Datei reden. Den Rest können wir ja in eine neue Diskussion auslagern.

Gruß

Neil

Die Erde ist eine Scheibe. Egal in welche Richtung sich die Menschheit bewegt, sie geht immer auf einen Abgrund zu.


CharlyMai

Foren-Prediger


Administrator

CharlyMai

Registriert seit: Mär 2005

Wohnort: Hannover

Verein: SOLARIS-RMB e.V. (P2;T2) / AGM / TRA#21598

Beiträge: 1970

Status: Offline

Beitrag 6770934 [Alter Beitrag24. April 2008 um 08:29]

[Melden] Profil von CharlyMai anzeigen    CharlyMai eine private Nachricht schicken   Besuche CharlyMai's Homepage    Mehr Beiträge von CharlyMai finden

Was nutzt mir eine Datei die gleich gespeichert wird, wenn die Hardware selber nicht zur Aufzeichnungs/Auswertsoftware Kompatibel ist ????

ich dachte X Prüfstand an z Software .. und .... Funktioniert ....

Pierre

•"Der Glaube an eine bestimmte Idee gibt dem Forscher den Rückhalt für seine Arbeit.
Ohne diesen Glauben wäre er verloren in einem Meer von Zweifeln und halbgültigen Beweisen." Konrad Zuse

•Konstruiere ein System, das selbst ein Irrer anwenden kann, und so wird es auch nur ein Irrer anwenden wollen.

SOLARIS-RMB e.V. AGM
Blackpuma

Epoxy-Meister

Blackpuma

Registriert seit: Jul 2006

Wohnort: Graz

Verein:

Beiträge: 374

Status: Offline

Beitrag 6770935 [Alter Beitrag24. April 2008 um 08:48]

[Melden] Profil von Blackpuma anzeigen    Blackpuma eine private Nachricht schicken   Besuche Blackpuma's Homepage    Mehr Beiträge von Blackpuma finden

Also wenn ich das Richtig verstanden habe ist die Auswertesoftware und Hardware egal. Hauptsache die Daten in der Datei sind alle gleich gespeichert.

Nur wenn alle Dateien in einem Format vorliegen... Welche Software soll das dann lesen und was wollt ihr mit dem Prüfstanddaten eigentlich machen?

LG
Blackpuma

Einmal Weltraum und zurück!

http://www.modellraketen.at
http://wiki.modellraketen.at
MarkusJ

Gardena Master of Rocketry


Moderator

Registriert seit: Apr 2005

Wohnort: Kandel

Verein:

Beiträge: 2148

Status: Offline

Beitrag 6770936 [Alter Beitrag24. April 2008 um 08:51]

[Melden] Profil von MarkusJ anzeigen    MarkusJ eine private Nachricht schicken   MarkusJ besitzt keine Homepage    Mehr Beiträge von MarkusJ finden

Ich denke auch, dass es schier unmöglich ist, alle Prüfstände mit dem Protokoll totzuschlagen, ohne dass dieses für einige schon wieder zu mächtig wird.
Das übertragen der Messwerte ist Sache der Software, hier geht es afaik nur darum, ein flexibles Format zu schaffen, was den Austausch der Ergebnisse zwischen verschiedenen Prüfstandsoftware(n/s?) ermöglichen soll.

mfG
Markus

WARNUNG: Dieser Beitrag kann Spuren von Ironie beinhalten
Ich bin weder eine Suchmaschine, noch ein Nachschlagewerk - PNs zu Themen die im Forum stehen oder dorthin gehören, werde ich nicht beantworten.
Bilder bitte NICHT über Imageshack oder andere Imagehoster einbinden!
Neil

99.9% harmless nerd


Administrator

Neil

Registriert seit: Aug 2000

Wohnort: Delft

Verein: SOLARIS

Beiträge: 7776

Status: Offline

Beitrag 6770937 [Alter Beitrag24. April 2008 um 09:54]

[Melden] Profil von Neil anzeigen    Neil eine private Nachricht schicken   Neil besitzt keine Homepage    Mehr Beiträge von Neil finden

Hi,

es gibt für die Realisierung der Hardware verschiedene Möglichkeiten. Einige werden Microcontroller einbauen, aber nicht alle. Daher können wir hier die Diskussion nicht bei dem Datenstrom zur Software beginnen. Wenn du fertige Datenloggerbausteine verwendest hast du keinen Einfluß auf dem Datenstrom vom Baustein zur Software. Erst in der Software kann ich die Daten so formen wie ich will. Damit jeder mal die Kurven des anderen in seine Software laden kann, unabhängig von der Hardware, sollte ein Format für eine Datei so geschaffen sein das jeder diese laden kann.

Gruß

Neil

Die Erde ist eine Scheibe. Egal in welche Richtung sich die Menschheit bewegt, sie geht immer auf einen Abgrund zu.


Blackpuma

Epoxy-Meister

Blackpuma

Registriert seit: Jul 2006

Wohnort: Graz

Verein:

Beiträge: 374

Status: Offline

Beitrag 6770938 [Alter Beitrag24. April 2008 um 10:37]

[Melden] Profil von Blackpuma anzeigen    Blackpuma eine private Nachricht schicken   Besuche Blackpuma's Homepage    Mehr Beiträge von Blackpuma finden

Aber dazu muss die Software das Format der Datei "verstehen" können. Wenn die Daten nach einem eigenen Format gespeichert sind wird das Programm das nicht lesen können.


PS: Was hast du da für ein Bild in deiner Signatur? Es wird nicht angezeigt.

Einmal Weltraum und zurück!

http://www.modellraketen.at
http://wiki.modellraketen.at
Seiten (8): « 1 2 [3] 4 5 6 7 8 »
[Zurück zum Anfang]
Du kannst keine neue Antwort schreiben