forum.heinrichsweikamp.com

Hallo,

PDF file: http://www.heinrichsweikamp.net/ostc/co ... rface2.pdf

Zwei Programmierer von PC Software haben zurecht angemerkt, dass das jetzige Protokoll wenig Spiel f?r zuk?nftige Erweiterungen wie ppO2 Sensoren oder Flaschendruckkontrolle l?sst. Ich m?chte daher o.a. Protokollbeschreibung mal als Vorschlag f?r die n?chste Beta machen. ?nderungen habe ich in rot markiert.

Kommentare?

Viele Gr?sse,
Matthias Heinrichs

Hello,

PDF file: http://www.heinrichsweikamp.net/ostc/co ... rface2.pdf

Two developers of PC software noted that the current serial protocol is not very flexible and can not be used for future developments like ppO2 sensors or tank pressure sensors. I would like to propose this new protocol, changes are in red.

Comments?

Regards,
Matthias Heinrichs

Hallo,

Ich finde das neue Protokoll geht etwas zu grossz?gig mit dem Speicher um. Mein Vorschlag:
Ein Flagbyte alle 10sek., ein 2. Flagbyte jede Minute zus?tzlich und 2*3 Byte/min f?r irgendwelche Sensoren. Wenn's nicht reicht kann man das ja in Zukunft nochmal erweitern.

Gruss,
Hans-J?rgen

Hallo Matthias

Ich w?rde evt. noch die M?glichkeit vorsehen, das Aufzeichnungsinterval zu ?ndern. Daf?r k?nnte man eine Custom Function hernehmen und im Tauchgangsheader das Interval speichern. Auf die Batteriespannung im Header k?nnte man verzichten. Den Flaschendruck im Header k?nnte man auch weglassen, da der erste Flaschendruck im Profil als Anfangsdruck genommen werden kann. Wenn der Rechner luftintegriert ist w?re es evt. noch interessant die RBT (Remaining Bottom Time) im Profil zu speichern.

Sch?ne Gr??e,
Sven

Hallo,

Hier mal meine Variante f?r ein flexibleres Protokoll: http://www.heinrichsweikamp.net/ostc/co ... rface3.pdf

Es werden also alle 10sek. 2Byte Tiefe und ein FlagByte abgespeichert.

Die letzten 3 Bit dieses Bytes geben an wieviele Bytes ZUS?TZLICH noch dranh?ngen (Kann man einfach mit einem XOR maskieren und erh?lt die Anzahl der Bytes), die anderen Bits geben an was f?r Informationen in diesem Bytes stecken.

Es kann pro Tiefensample immer nur eine extra Information gespeichert werden. ?ndert sich z.B. Decodaten oder Temperatur nicht braucht aber auch nichts angeh?ngt zu werden.

Bitte kommentieren!

Viele Gr?sse,
Matthias

Hallo Matthias, Hallo Logbuch-Entwickler,

Den Vorschlag von Sven mit der variablen Sampling-Rate finde ich gut, ist aber sicher kein "Must".

Bez?glich des Vorschlags (Protokoll3): Die angedachte Variante ist schick, hat aber m.E. einen Haken: Da nur 1 Wert hinter der Tiefe angegeben werden kann muss der OSTC entscheiden was er denn jetzt als Zusatz-Info speichern soll, gibt es eine klar definierte Prio-Liste?
So eine h?tte dann aber den Nachteil, dass unter Umst?nden gewisse Events nie mehr gespeichert werden.
Gewisse Werte neigen dazu, regelm?ssig Events auszul?sen (Temperatur wird sicher immer um 0.1? ?ndern, der Flaschendruck ist auch bei jedem Sample tiefer, ppO2 wird sicher auch dauernd kleinere Schwankungen haben, Decostatus ist bestimmt auch mit jedem Sample anders).

Ich denke wir m?ssen da Unterscheiden zwischen Messwerten und Events.
Als Messwerte w?rde ich alles definieren was sich st?ndig ?ndert (ppO2, Temperatur, Decostatus, Flaschendruck, ...).
Als Events w?rde ich alle einmaligen oder vom Benutzer ausgel?sten Aktionen definieren (Gas-Wechsel, Gas-Konfiguration, Slow-Warnung, Marker, Deco-Ceiling passed, ...).

Folgender Vorschlag:
Messwerte werden regelm?ssig protokolliert. Wie oft wird ?ber eine Custom-Function als Sample-Divisor konfiguriert (z.B. 3 = bei jedem dritten Sample, 0 = nie). Diese Divisors stehen im Tauchgangs-Header.

Das sieht dann wie folgt aus:
2-byte Tiefe, 1-byte Flagbyte, x-byte erweiterte Informationen.

Unter erweiterte Informationen stehen dann die zus?tzlichen Infos, je nachdem was bei dem Sample alles vorhanden ist.
Dabei m?ssen die Zusatzinformationen in einer definierten Reihenfolge und definierter L?nge kommen.
Beispiel-Reihenfolge:
- Warnungen (1 byte)
- Gas-Definition (2 byte)
- Gas-Wechsel (1 byte)
- Temperatur (2 byte)
- NDL / Deco (2 byte)
- ppO2 Sensor Werte (??? bytes)
- Flaschendruck Werte (??? bytes)

Die L?nge der Werte mit ??? k?nnten allenfalls auch im Tauchgangs-Header stehen, so w?rden wir uns nix verbauen solange wir noch nicht genau wissen wohin der Kahn f?hrt

F?r jedes Sample wird dann evaluiert welche Zusatz-Bytes kommen (Sample# % Divisor, bzw. gesetzte Bits im Flagbyte) und diese in der definierten Reihenfolge ausgelesen.

Vorteil dieser Variante: Jeder ist selbst daf?r verantwortlich wie viel Speicher er mit jedem Tauchgang "verschwendet" und welche Informationen er dann zur Verf?gung hat.

Was meint Ihr dazu?
Matthias: ist das ?berhaupt realisierbar?
W?rde mich auch anerbieten das Grob-Konzept zu einem genaueren Protokoll-Vorschlag auszuarbeiten...

Viele Gr?sse,
Pascal

Hallo Pascal,

Das ist auf jeden Fall so realisierbar, was passiert wenn Messwerte und Events zusammenfallen? In Deinem Beispiel hast Du es ja zusammengefasst. Wie kann die Logbuch-Software also einfach erkennen wieviel nun genau am Tiefensample dranh?ngt?

Gruss,
Matthias

Den Vorschlag von Pascal finde ich gut. Wenn jemand auf gewisse Daten keinen Wert legt oder sie einfach nicht vorhanden sind (keine Luftintegration) wird kein Speicher verschwendet. Wieviel Bytes am Tiefensample h?ngen steht ja im Flagbyte im Anschlu?. Evt. kann man auch ein 2. Flagbyte dazu nehmen, und in den einzelnen Bits das Vorhandensein der Me?werte speichern. z.B.

00011000

Das w?rde (in der Reihenfolge von Pascal) bedeuten das als Zusatzdaten nur Temperatur und Decodaten folgen, dann kommt das n?chsten Tiefensample. Bei der Bitfolge 10011000 sind dann noch Warnungen vorhanden, bei 00000000 sind keine Zusatzdaten gespeichert, usw.

So mu? nur die Reihenfolge und L?nge der Zusatzdaten in der Protokollbeschreibung festgelegt werden, man kann aber beliebige Daten auslassen. Evt. kann man es auch so machen, das die Zusatzdaten nur gespeichert werden, wenn sich etwas ge?ndert hat. Falls der Flaschendruck ?ber den gesamten Tauchgang nicht gespeichert wird, steht das in einem Flagbyte im Header. So kann man beim Auslesen unterscheiden ob sich einfach nur nichts ge?ndert hat, oder ob generell bei dem Tauchgang keine Daten kommen werden.

Gru?,
Sven

Hallo Matthias und Sven,

Matthias: Wenn Messwerte und Events zusammenfallen kommen deise nacheinander, entsprechend der definierten Reihenfolge.

Sven: Dies w?re nat?rlich eine Alternative (zum Parsen wahrscheinlich auch etwas einfacher). Der Nachteil ist: Wir ben?tigen 1 zus?tzliches Byte pro Sample und sind auf maximal 8 Zusatz-Informationen beschr?nkt. Richtig?

Viele Gr?sse,
Pascal

Hallo Pascal

Jetzt verstehe ich wie du das gemeint hast. Das ist noch besser weil man tats?chlich das Flagbyte spart und nicht auf 8 begrenzt ist. Man schaut also einfach im Header ob und wie oft welche Zusatzbytes kommen. Das Parsen wird dann zwar etwas aufw?ndiger, aber ich denke das ist machbar.

Sch?ne Gr??e,
Sven

Ok, im Flagbyte muss dann eigentlich nur stehen das ein Event und/oder ein Messwertblock angeh?ngt ist. Die L?nge w?rde ich dennoch mit ins Flagbyte packen. Das macht die Auswertung sch?n einfach (Profilaufbau im Logbuch!). Gerne kannst Du, Pascal, Dir da mal was ausdenken an das wir uns alle halten. Ich denke die Implementierung im OSTC ist schnell erledigt. Platzhalter im Header f?r die L?nge der noch nicht genutzten Funktionen ist sinnvoll. Einmal etwas Arbeit aber so wird's vielleicht etwas l?nger halten......

Gruss,
Matthias

Hallo Matthias und Sven,

Gut, ich werde mich mal ans Schreiben der Spezifikation machen.
Ich gehe davon aus, dass ich Euch diese dann im Verlauf des Morgens mal zum Review verschicken kann.

Viele Gr?sse,
Pascal