OSTC3, cR, sport and 2 :  heinrichs weikamp forum The fastest message board... ever.
OSTC's running hwOS 
OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Duglum ()
Date: May 21, 2019 11:25PM

Nachdem mein erster OSTC 2 TR wohl einen Hardwarefehler hatte und sich nicht mit einem Sender pairen liess konnte ich das Ersatzgerät auf einem wunderschönen Trip über die letzten 2 Wochen endlich mal gründlich in 21 Tauchgängen testen. Als Backup hatte ich (wie sich herausstellte zum Glück!) parallel noch meinen OSTC Sport am Arm. Der Sport lief mit 10.52, der 2 TR mit 3.01.

Vor den folgenden Fakten möchte ich mein Fazit bereits vorziehen: Im großen und ganzen muss ich sagen dass ich enttäuscht bin. Diese ganzen Probleme, Fehler und Versäumnisse dürfen bei einem derart teuren Produkt einfach nicht vorkommen. Erst recht nicht bei einem welches gesundheitlich relevante Daten liefert.
Wenn ich nicht mit meinem Sport schon vorher jahrelang so super zufrieden gewesen wäre würde ich das Gerät zurückgeben und mir einen Perdix AI von Shearwater zulegen damit Ruhe ist.

1. Laden des OSTC
Meine Reisedestination war ziemlich warm und der QI-Lader des OSTC schaltet ja bei Übertemperatur ab. Soweit so gut, bei 29° Umgebungstemperatur wurden allerdings über eine komplette Nacht nur 2% aufgeladen. Das ist ungenügend. Der Lader lag dabei zwischen einem Holztisch und dem OSTC. Den Lader auf den OSTC legen ging dann etwas besser, das ist allerdings sehr fummelig da das QI-Pad so leicht und das Kabel so steif ist.

2. Zuverlässigkeit des Senders und Verarbeitung/Anzeige der Daten:
- Bei fast allen Tauchgängen gab es zwischendurch immer mal wieder Komplettausfälle der Kommunikation zwischen Sender und Computer, teilweise über Minuten. Am Display stand nur noch XMTR (o.ä.) failed und das wars. Nach einer Weile kam das Signal dann wieder zurück. Sowas darf nicht sein.
- Wenn man die Flasche am Ende des Tauchgangs zudreht, der OSTC aber noch im Tauchmodus ist (5min delay) dann wird ein Druck von ">400 bar" angezeigt und eine SAC von 99l/min. Dazu ein fettes rotes Warndreieck. Korrekt wäre wohl ein Druck von 1bar.

3. Logging der Senderdaten:
Beim import in Subsurface ist mir heute aufgefallen dass die Senderdaten scheinbar gar nicht mitgeloggt werden! Das ist doch überhaupt erst der Witz einer Senderintegration. Hoffe das wird schnellstmöglich noch nachgeliefert.

4. Das schlimmste zum Schluss: Der Bugreport:
Der 2 TR hat sich bei einem der Tauchgänge unter Wasser irgendwann in den Gauge Modus geschaltet, d.h. es waren keinerlei Deko-Informationen mehr sichtbar! Die Gewebeaufsättigung wurde ebenfalls nicht übernommen so dass die Werte beim nächsten Tauchgang nicht mehr stimmten. Der Senderdruck und das eingestellte Gas (Nx32) wurden aber noch angezeigt. Der betroffene Tauchgang wird im Subsurface auch mit ZH-L16-GF 50/75 angezeigt.
In diesem konkreten Fall war die Situation jetzt nicht sonderlich wild: Es war ein Dümpeltauchgang mit minimaler Deco, es war sowieso der zweitletzte TG des Trips und ich hatte ja noch den Sport am Arm.
Trotzdem darf ein Bug dieses Kalibers es nun wirklich niemals nicht in ein solches Produkt schaffen...
Die Tauchgangsdaten kann ich zur Verfügung stellen...

OSTC Sport #12483
OSTC 2 TR #17196



Edited 3 time(s). Last edit at 05/22/2019 03:14PM by Duglum.

Attachments: ostc2tr_gauge_bug.png (629.7 KB)  
Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Ralph ()
Date: May 22, 2019 07:39AM

Hallo,

kannst du bitte die auf dem TR verwendete Firmware-Version angeben? Im Test ist das noch nie passiert, vom Code her sollte es nicht passieren können, daher ist jede Info hilfreich mit der sich der Auslöser dieses Fehlers näher einkreisen lässt. Hat der Rechner nach dem Tauchgang im Oberflächenmodus tatsächlich "Gauge" als Betriebsmodus angezeigt, oder stand dort wieder/noch "OC"? Als welcher Typ ist der Tauchgang ins Logbuch eingetragen worden?

Danke!



Edited 1 time(s). Last edit at 05/22/2019 07:48AM by Ralph.

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Duglum ()
Date: May 22, 2019 03:22PM

Hi Ralph,

der TR lief mit 3.01, steht auch oben schon. winking smiley
Im Oberflächenmodus war dann tatsächlich Gauge eingestellt.

Im Logbuch des OSTC steht der Tauchgang ebenfalls als Gauge, es sind aber trotzdem die Infos zu den Deko-Einstellungen sichtbar.

Anbei ein paar Fotos.

Was mir grad übrigens auch noch einfällt: Bei der NoFly-Anzeige ist auch irgendwas gründlich im argen. Durch die vielen TG über viele Tage war die DeSat-Zeit irgendwann bei gut 38h. Das haben der 2TR und der Sport auch nahezu identisch angezeigt. Die NoFly-Zeit lag dann allerdings auf dem Sport irgendwo bei 22-24h, auf dem 2TR allerdings zwischenzeitlich bei weit über 40h... also mehr als die DeSat-Zeit. Das ist ja schon rein logisch nicht möglich...

OSTC Sport #12483
OSTC 2 TR #17196

Attachments: ostc2tr_gauge_bug_tg_graph.png (203.6 KB)   ostc2tr_gauge_bug_tg_info.png (243.4 KB)   ostc2tr_gauge_bug_tg_gasliste.png (186.2 KB)  
Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Ralph ()
Date: May 22, 2019 08:18PM

OK, Danke, diese Spuren werden bei der Fehlersuch enorm helfen.

Dass Deko- und Gaseinstellungen in Gauge-Logs erscheinen war in der 3.01 noch normal (wenn auch etwas sinnbefreit), in der aktuellen Entwicklungsversion werden diese in nicht-deko-Tauchmodi nicht mehr angezeigt. Ins Log selbst werden sie trotzdem noch hineingeschrieben, sonst passt das Format nicht mehr für die verschiedenen 3rd Party Logbuch-Programme.

Der Code bzw. Algorithmus für die Berechnung der Entsättigungs-Zeit ist bei Sport und Tech gleich. Da eine vollständige Entsättigung mathematisch nie erreicht wird, ist das Kriterium der Zeitpunkt wenn alle Gewebe soweit runter sind dass sie maximal 5% über Umgebungsdruck liegen.

Die No-Fly-Zeit ist bei Sport und Tech dagegen völlig unterschiedlich programmiert: im Sport läuft einfach ein Timer herunter, während die Tech quasi einen Dekostopp berechnet, nach dessen Ende ein Aufstieg auf die eingestellte Höhe gemäß Bühlmann möglich ist. Da kann es tatsächlich passieren dass die No-Fly-Zeit länger wird als die Entsättigung, denn mit 5% Überdruck (Ende der Desat-Zeit) auf den ganz langsamen Geweben darf man lt. Bühlmann noch nicht auf die Höhe die im OSTC für den Kabinendruck hinterlegt ist.

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Ralph ()
Date: June 02, 2019 11:10AM

Bericht zum Abschluss der Untersuchung bzgl. des Bugreports "Computer schaltet während des Tauchgangs vom OC-Modus in den Gauge Modus":

Der wohl am schwierigsten zu findende Fehler ist derjenige Fehler, der wohlmöglich gar nicht existiert... Auch wenn es natürlich im nachhinein nicht zu beweisen ist dass obig beschriebenes Verhalten nicht passiert ist, so ist nach eingehender Analyse des Programmcodes mit an Sicherheit grenzender Wahrscheinlichkeit auszuschließen dass es tatsächlich passiert ist.

Ein paar Details / Hintergründe: der Betriebsmodus OC / CCR / Gauge / ... wird im OSTC in einer Integer-Variablen gespeichert, wobei den jeweiligen Modi Zahlenwerte zugeordnet sind. Am Ende des Tauchgangs wird dieser Zahlenwert mit in das Logbuch geschrieben, wodurch es der Logbuchfunktion möglich ist anzuzeigen in welchem Modus der TG durchgeführt wurde. Wenn der TG als "Gauge" angezeigt wurde, dann stand diese Variable am Ende des TG auf dem Zahlenwert für Gauge.

Während des laufenden Tauchgangs wird diese Modus-Integer-Variable mit ihrem Zahlenwert jedoch gar nicht verwendet. Stattdessen wird ein Mal am Beginn des Tauchgangs wenn der OSTC vom Oberflächen- oder Sleep-Modus in den Tauchmodus wechselt die Integer-Variable gelesen und anhand ihres Wertes werden Flags - boolsche (1 Bit) Anzeiger - gesetzt. Für jeden Modus gibt es ein dediziertes Flag und nur jeweils eines von ihnen wird gesetzt. Die gesamte weitere Ablaufsteuerung im OSTC während des Tauchgangs wird ausschließlich über diese Flags gesteuert. Die Flags liegen in einer anderen Variablen / Speicherzelle als die eingangs beschriebene Integer-Variable, Die Tauchmodi sind in der Zahlen- sowie Flag-Variable unterschiedlich kodiert.

Wenn der OSTC während eines Tauchgangs seinen Tauchmodus umschalten sollte, dann müssten beide Speicherzellen ihren Wert ändern, und das so, dass die unterschiedlichen Kodierungen in beiden Speicherzellen kongruent auf den neuen Modus weisen. Dies als solches ist schon recht unwahrscheinlich, noch dazu wird auf beide Speicherzellen im gesamten Programmcode der während des Tauchgangs ausgeführt wird an keiner einzigen Stelle schreibend zugegriffen. Die Flags werden nur 1x am TG-Beginn gesetzt, der einzige Schreibzugriff auf die Integer-Variable erfolgt aus dem Programmcode für das Oberflächenmenü sowie aus der Comm-Funktion (OSTC konfigurieren über BT). Beide Codebereiche werden im Tauchmodus nicht ausgeführt.

Beim verwendeten PIC-Controller besteht die Möglichkeit sogenannte Bank-Fehler zu machen: der gesamte Speicher ist in mehrere Speicher-Bänke aufgeteilt und vor dem Zugriff auf eine bestimmte Speicherzelle muss die entsprechende Speicherbank ausgewählt werden. Der gesamte Programmcode wurde in der Vergangenheit schon detailliert auf mögliche Bankfehler untersucht und es wurden keine gefunden. Sollte es dennoch einen geben, so kann sich der Wert der Zahlenvariable für den Tauchmodus nur ändern, wenn in falschem Kontext die Bank 14 ausgewählt wird, denn in dieser liegt die betreffende Integer-Variable. Eine solche Bankauswahl gibt es jedoch nirgendwo im gesamten Programmcode. Die einzigen beiden Programmzeilen die auf diese Variable schreiben (Menü und Comm-Mode) benutzen einen bank-freien Zugriffsbefehl. Die Flags liegen wiederum in einer anderen Bank, es müssten also zwei Bankfehler zeitnah zueinander auftreten die noch dazu "gemeinsame Sache" machen.

Damit muss davon ausgegangen werden, dass die Integer-Variable schon zu Beginn des Tauchgangs auf Gauge-Modus gestellt war und die Flag-Variablen dementsprechend am TG-Beginn gesetzt wurden. Dies passt auch zum im Bild gezeigten Bildschirmaufbau: der untere Bildschirmteil kann nur leer sein im a) Gauge-Modus oder b) nach dem Verlassen des Tauch-Menüs wenn die Flag-Variable für den OC-Modus nicht gesetzt ist. Dass diese sich während des TG verstellt ist auszuschließen, siehe oben. Im Übrigen zeigt die wieder angezeigte Temperatur dass der Wiederaufbau des Bildschirms nach dem Verlassen des Menüs ausgeführt wurde. Die Gasangabe im Custom-View im Zusammengang mit dem Druckwert hat keine Verbindung zum OC-Modus, hier wird lediglich vermittels der Gaszusammensetzung angezeigt mit welchem Tank / Sender diese Anzeige verbunden ist.

Interessanter Weise wurde das gleiche Fehlverhalten vor nicht allzu langer Zeit schon einmal berichtet, im Zusammenhang mit der Sport-Firmware. Die Bedienung der Tauchmodus-Auswahl ist aus Benutzersicht in beiden Firmware-Versionen gleich, die Programmierung dahinter jedoch komplett unterschiedlich. Aus dieser Unterschiedlichkeit resultiert auch, dass die involvierten Variablen an unterschiedlichen Speicheradressen liegen. Ein übergeordneter systematischer Programmierfehler, der diese ganzen Unterschiede gemeinsam überwinden kann ist quasi nicht vorstellbar. Daher liegt der Schluss nahe, dass in beiden Fällen bereits irgend wann vor Beginn des Tauchgangs versehentlich und unbemerkt der Tauchmodus verstellt wurde.



Edited 1 time(s). Last edit at 06/02/2019 11:46AM by Ralph.

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Duglum ()
Date: June 02, 2019 10:47PM

Ralph, Danke für Deine ausführliche Ausführung.
Wäre es vorstellbar dass der OSTC durch eine fehlerhafte Sensorinformation o.ä. kurzzeitig im Oberflächenmodus war? Ich glaube Dir Deine Ausführungen durchaus... bin selbst Techniker.. allerdings bin ich mir auch zu 100% sicher dass der OSTC am Anfang des Tauchgangs noch nicht im Gauge-Modus war. Wann genau die Umstellung erfolgte kann ich leider nicht mehr nachvollziehen, aber wenn es von Anfang an der Fall gewesen wäre wäre mir das nicht erst nach knapp 29 Minuten aufgefallen...

Ein bitterer Beigeschmack bleibt also.
Gibt es nebenbei schon eine ETA zum logging der Druckdaten?

Es wäre im übrigen auch schön wenn sich jemand von H&W (Du, Ralph, bist ja freier Entwickler wenn ich das richtig im Kopf hab?) mal zu der Senderproblematik äussern könnte. Ich bin ja scheinbar nicht der einzige der dieses Problem mit dem miserablen Empfang hat.. siehe anderer (englischer) Thread.

OSTC Sport #12483
OSTC 2 TR #17196



Edited 1 time(s). Last edit at 06/02/2019 10:48PM by Duglum.

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Ralph ()
Date: June 03, 2019 08:09AM

Hallo,

selbst wenn der OSTC zwischenzeitlich im Oberflächenmodus gewesen sein sollte, hätte sich da nichts selbst verstellen können. Habe mich wirklich lange mit dem Fall beschäftigt, aber mir ist wirklich kein Fehlerpfad eingefallen wie so etwas passieren könnte...

Richtig, von mir stammt der TR-Code der die Anzeigen und Warnungen generiert sowie die SAC berechnet. Die Funkstrecke macht Matthias, ich sehe nur die jeweils letzten empfangenen Daten und deren Alter in Sekunden. Ab einem gewissen Alter, d.h. dem Ausbleiben neuer Daten, zeige ich die zuletzt empfangenen Daten erst als 'outdated' und dann später als 'weg'. Hier ist der Code recht "ehrlich", d.h. die Zeitspannen sind recht kurz. Man könnte hier schummeln und bei ausbleibenden neuen Daten länger die alten präsentieren, oder sogar stattdessen dann hochgerechnete Daten ausgeben, aber das macht der Code nicht.

Allgemein ist die Datenübertragung unter Wasser nahezu unmöglich wenn man nicht auf akustische Sender geht, aber die würden Unmengen an Energie verbrauchen. Funk in jeder Form wird vom Wasser innerhalb kürzester Distanzen geschluckt. Deshalb nutzen alle Hersteller eine überwiegend auf Magnetfeldern basierende Übertragung. Die kommt zwar ganz gut mit Wasser zurecht, hat aber als Feind jede Form von Metallen, insbesondere magnetisierbare wie z.B. Stahlflaschen. Ergo saugt ein Stahl-Doppelpack auf Backplate einen Großteil der Sendeenergie weg, insbesondere wenn man den Sender geschützt nach unten zeigend im Raum zwischen Regler und Flaschenhals montiert. Eine Single-Alu auf Softpack / konventionellem Jacket kommt dem Ganzen schon mehr entgegen. Weiterhin muss das Magnetfeld durch die Empfangsspule im OSTC treten können, daraus resultiert die Empfindlichkeit auf die Ausrichtung, die in der Anleitung beschrieben ist. Das ist leider naturgegebene Physik und daran ließe sich auch mit noch so viel Sendeleistung nichts ändern. Man könnte nur in der Software-Auswertung... siehe oben. Soviel aus meiner Software-Sicht.



Edited 2 time(s). Last edit at 06/03/2019 05:54PM by Ralph.

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Kehrmaschine ()
Date: June 03, 2019 01:35PM

Danke Ralph für Deine Erklärung. Ich habe zwar keine Tankpods und nütze einen +Tech, weil die Sender meiner Meinung nach nicht zuverlässig arbeiten (auch bei anderen Herstellern nicht).
Die Vermutung dass die TC die Drücke teilweise nachrechnen habe ich schon seit ca 2 Jahren. Damals hatte ein Freund von mir beinahe einen Tauchunfall, weil sein TC noch 50 bar angezeigt hat und ans Fini hat er nicht geschaut. Plötzlich hat er keine Luft mehr bekommen. Wir haben ihm ans Longhose genommen und den TG sicher beendet. An der Oberfläche hat sich herausgestellt dass sein Fini nur mehr 10 bar gezeigt hat. Bei seinem TC hat es ein paar Minuten gedauert, dann war die Druckanzeige dort analog zum Fini.

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Duglum ()
Date: June 03, 2019 01:48PM

Mhm.. das wäre natürlich auch eine Möglichkeit. Also dass die Konkurrenz einfach schummelt. Wenn das der Fall ist und es technisch nicht besser geht: Mea Culpa, die Physik lässt sich nicht überlisten. Dann ist mir Deine Lösung deutlich lieber, ein Fini hab ich sowieso immer dabei.

Bei meinen TestTG waren es Dümpel-TG im Urlaub.. sprich Mono-Alu. Der Tx war an einem 15cm Schlauch.. sprich zwischen Flasche, Wing und (Titan-) BP.
Ich meine mir einzubilden dass der Empfang besonders schlecht war wenn wir, zwecks Haie guggn, mal wieder besonders nah an irgendwelchen Felsen hingen. Vielleicht war das Vulkangestein dort ja auch besonders eisenhaltig.. hm. confused smiley

Meinst Du ein 90° HD-Adapter um die Ausrichtung des Tx zu ändern könnte was bringen?
(Edit: Meh... scheint es eh nicht zu geben. Nur für direkt an der 1. Stufe, nicht am Schlauchende. Dann muss wohl ein Stück Schnur wie bei den Stagefinis herhalten..)

OSTC Sport #12483
OSTC 2 TR #17196



Edited 2 time(s). Last edit at 06/03/2019 02:37PM by Duglum.

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Ralph ()
Date: June 03, 2019 05:47PM

In Sachen HD- und MD-Adapter ist der deutsche Markt etwas leer, aber bisher habe ich alle meine Adaptions-Bedürfnisse mit Material der Firma OmniSwivel lösen können, vertrieben z.B. in GB von omniswivel.co.uk oder Narked at 90.

Die größte Verbesserung der Empfangsleistung entsteht, wenn man es schafft den Sender so zu positionieren dass die Ausrichtung Sender - OSTC der Abbildung im Handbuch entspricht. Dabei die normale Armhaltung zu Grunde legen. Ich habe mir im Rahmen der Erprobung auch mal einen Sender direkt vor die Brust gehängt weil hinten zu viel Stahl im Weg war.

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: heinrichsweikamp ()
Date: June 03, 2019 06:00PM

Wegen so einem Swivel-Adapter könnt Ihr auch eine mail an uns schicken: info@heinrichsweikamp.com

Gruß,
Matthias

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Duglum ()
Date: June 11, 2019 04:07PM

Matthias: Ist angekommen. Danke!

Gibt es eigentlich ein Changelog für die RX-Firmware? Habe den OSTC 2 jetzt auf RX 1.38 gehoben, sprich die Beta 3.03 testweise aufgespielt. Bin allerdings noch nicht wieder zum tauchen gekommen.

Mir ist übrigens noch ein Vorschlag zur Druckanzeige eingefallen: Vorausgesetzt die Aussetzer in der Übertragung sind tatsächlich physikalisch bedingt und nicht vermeidbar: Wie wäre es damit das Ausrufezeichen und den Fehlertext zu entfernen und stattdessen einfach den Druckwert anders einzufärben? z.B. gelb sobald das Signal verloren geht und rot oder blau wenn das Signal länger als x Sekunden weg ist? Dadurch würde man auch den letzten Wert weiterhin sehen und nicht nur die "---".

Hintergrund meiner Überlegung ist dass ich das Ausrufezeichen mit etwas verbinde was wichtig ist, also meine Aufmerksamkeit verlangt. Das ist aber hier nicht der Fall... schau ich halt aufs Finimeter wenn ich unbedingt den Druck wissen muss.

OSTC Sport #12483
OSTC 2 TR #17196

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Ralph ()
Date: June 11, 2019 06:13PM

Hallo & Danke für den Vorschlag!

Für "outdated values" gibt es schon eine Standardfarbe, das ist dieses dunkle blau. Ich werde das mal einarbeiten, sprich die "Eskalation" bei ausbleibenden Werten etwas zurücknehmen. Die aktuelle Anzeigestrategie ist noch der erste Schuss, da baut man eher ein bisschen mehr in Richtung Sicherheit...

Viele Grüße,
Ralph

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: millsmess ()
Date: June 20, 2019 10:55AM

Moin
würde gerne kurz auf den 3. Punkt (Logging der Senderdaten)im Eingangspost eingehen. Wie sieht es damit aus, ist da Abhilfe in Sicht?

Gruß
Markus

Options: ReplyQuote
Re: OSTC 2 TR - Bugreport und Erfahrungsbericht
Posted by: Ralph ()
Date: June 20, 2019 01:13PM

Hallo Markus,

der Code für die Druckaufzeichnung ist geschrieben, die Tests laufen in den nächsten Wochen, gute Chance dass das schon in die nächste Beta bzw. Release Version kommt.

Options: ReplyQuote


Sorry, only registered users may post in this forum.
This forum powered by Phorum.