Tauchausrüstung Foren

Anbei Screenshots für den CCR-TG ohne bzw mit Bailout. Habe nur eine 11.1L BO mit 200 Bar Luft angegeben

Beides gerechnet mit MultiDeco 2.2.4 auf Android.
Ich kriege keine Fehlermeldung

Grad am iPad probiert, selbe Fehlermeldung. Es tritt anscheinend auf, wenn die Schrittweite gleich dem letzten Stopp ist. Wenn man Schrittweite auf 6m stellt und Last stop auch auf 6 tritt es auch auf.
version 1.105

Schreibt doch dem Entwickler. Hatte mit dem vor ein paar Jahren kurz Kontakt. Hat schnell und kompetent geantwortet.

Scheint ja tatsächlich ein Bug zu sein, wenn's bei Euch auf iOS nicht funzt und bei mir auf Android ohne Murren klappt

Danke für euren check, werde dem support ne E-Mail schreiben.

Okay, ich habe Rückmeldung von Ross Hemingway, der Sachverhalt ist geklärt:

Es ist kein Bug, nein, natürlich nicht, es liegt an der lästigen Mathematik... lest selbst die Antwort:

/Zitat_anfang
The message says... the deco steps used, and the weak deco gas, prevent off gassing from being achieved in satisfactory time (or at all).

The 6m stop and and short dives and weak deco mix, simply do not fit together. Its made worse by GF, which is nothing more than a math fudge - one that imposes limits that have little or no relevance to the actual required deco.

Its not a bug... its a mathematical fact - too much fudging results in a deco that cannot be calculated or performed.

The v1.105 has no differences in the deco from previous versions, and the Android and iOS programs use the identical deco program code. Any variance is in the settings or sequence of dives computed.

/Zitat_ende

Nun, ich habe noch ein wenig rumgespielt mit den Parametern:

42 m, 10 min, Air-Diluent, SP 1.3, Dekoschrittweite, letzter OC-Stop und letzter CCR-Stop auf 3m, ZHL-C+GF, Bailout mit Luft -> wird gerechnet
41 m, 10 min, Air-Diluent, SP 1.3, Dekoschrittweite, letzter OC-Stop und letzter CCR-Stop auf 3m, ZHL-C+GF, Bailout mit Luft -> Fehlermeldung
40 m, 10 min, Air-Diluent, SP 1.3, Dekoschrittweite, letzter OC-Stop und letzter CCR-Stop auf 3m, ZHL-C+GF, Bailout mit Luft -> Fehlermeldung
39 m, 10 min, Air-Diluent, SP 1.3, Dekoschrittweite, letzter OC-Stop und letzter CCR-Stop auf 3m, ZHL-C+GF, Bailout mit Luft -> wird gerechnet
38 m, 10 min, Air-Diluent, SP 1.3, Dekoschrittweite, letzter OC-Stop und letzter CCR-Stop auf 3m, ZHL-C+GF, Bailout mit Luft -> Fehlermeldung

Wie gesagt, der eigentliche TG wird gerechnet, das Problem tritt für den Bailout-Plan auf. Das war alles mit GF 50/75 im Bailout-Fall.
Setze ich z. B. GF-high im Bailout-Fall auf 100%, dann wird wieder ohne Fehlermeldung gerechnet.

Was soll ich sagen: Mein Vertrauen in die Multideco-Berechnungen hat sich nicht gerade erhöht.

D.h. Das Problem ist, das man vom Nitrox (Cc Setpoint ) auf OC Luft wechselt, wenn ich es richtig verstanden habe?

Warum dann mit Unterschiedlichen Tiefen mal ok, mal nicht? Werden dann andere Gewebe schlagend?

Wäre interessant sich die einzelnen Gewebe mal anzuschauen.

@ Sven, Danke für die Rückmeldung!

Ich bin kein Deko und Theorie Experte, hab mich sber mal was mit dem Bühlmann und Geweben beschäftigt.

Ehrlich gesagt macht die Antwort auf mich nicht so wirklich Sinn. Wir haben es hier nicht mit 2 Inertgasen zu tun, also ist federführend pN2 zur Zeit T in Tauchgang -> Aufsättigung.
Das ergibt eine Startsättigung pro Gewebe ab Bailout. Jetzt wird mit anderem pN2 (wegen Bailoutgas vs Setpoint) die Berechnung fortgeführt.
Soll dann nicht einfach ab "schlechtest möglichem Zeitpunkt", aka Beginn Aufstieg, die Berechnung der Gewebesättigung mit dem Baolpitgas erfolgen. Selbst mit Luft 10min Bottom Time ab Start ist in vernünftiger Runtime ein Aufstieg möglich. Das Programm soll einen doch nur sicher hochbringen, wie es ein TC auch machen würde. Ich seh kein Grund für eine mathematische Problematik, ausser das ggfs Stopps sehr kurz sind auf einer Tiefe und da was nicht richtig abgefangen/gerundet wird. Möglicherweise, weil die Gewebe wegen achnell/langsam anders gesätigt sind als entstätigt werden und das führt zu einer nicht interpretierbaren Situation?

Meines Erachtens ist das eher eine ausweichende Antwort eines Programmieres. Kenne ich zur genüge selbst durch die Arbeit...

Nicht interpretierbar wohl eher nicht. Anscheinend hat er mathematisch ein Problem es abzubilden, und will nicht zusätzlich was einbauen um das aufzulösen, weil er dann Annahmen zur Deko treffen müsste, er will aber nur das Modell "as it is" verwenden - verständlich.

Also ich hatte mit GF 40/80 sowohl für CCR als auch Bailout gerechnet und das hate ohne Fehler funktioniert

Was hattest du denn für GF??

Also am iPad kommt bei mir bei 41m der Fehler auch bei 40/80. Schrittweite & Last stop 3m, wenn die Werte unterschiedlich sind wird's berechnet.

Keine Ahnung was du rechnest.

41m funzt bei mir mit 40/80 und jeweils 3m.
Da muss irgendeine andere Einstellung noch mit reinspielen

Natürlich vereinfacht: Also mathematisch nicht interpretierbar kann ich mir schwer vorstellen. Im Grunde pro Gewebe (die voneinander abhängen..) hast du die aktuelle Sättigung sowie mit welcher Rate es ent- bzw. aufsättigt - abhängig von dem Partialdruck der Gase. Die GF geben dir dann einen Grenzwert der Sättigung an..demzufolge weisst du ob du hier "warten" musst oder aufsteigen darfst. Nicht interpretierbar wäre sowas, wenn ein Gewebe aufsättigt und dann erst das vorherige kritische weit genug entsättigt wäre. Das kann hier aber nach logischem Verstand nicht so auftreten.

Ich vermute eher, dass er nicht "rückwärts" den nächsten Dekostopp berechnet wie ein TC, sondern da nur die Einstellungswerte berücksichtigt. Wenn da was "komisches" vorkommt, dann kommt die Meldung anstelle von dynamischer Schrittweite.

Weitere Spekulation: Sollte es wirklich nur bei iOs auftreten könnte es sein, dass eine Gleitwertvariable eine andere native Genauigkeit hat, und so das zufällig da auftritt.

Kennt ihr den Baltic Deco Planner?
Benutze ich seit vielen Jahren, ohne jemals nicht-plausibele Ergebnisse zu erhalten.

/Zitat_anfang
The message says... the deco steps used, and the weak deco gas, prevent off gassing from being achieved in satisfactory time (or at all).
/Zitat_ende

Wieso genau kann der 40m TG von MultiDeco nicht berechnet werden, ein 42m TG mit ansonsten gleichen Parametern aber schon? Das off gassing müsste ja noch viel länger dauern.

/Zitat_anfang
The 6m stop and and short dives and weak deco mix, simply do not fit together. Its made worse by GF, which is nothing more than a math fudge - one that imposes limits that have little or no relevance to the actual required deco.
/Zitat_ende

Nun ja, ich schrieb ja von 3m Stopps... Und Luft ist nun nicht die Katastrophe bei einem 40m TG. Und wenn man MultiDeco für den Bailout-Aufstieg Luft UND ein EAN28 anbietet, dann rechnet es den Bailout-Aufstieg (!), und zwar nur mit Luft. Es gibt also im Grunde gar kein Problem mit der Berechnung.

/Zitat_anfang
Its not a bug... its a mathematical fact - too much fudging results in a deco that cannot be calculated or performed.
/Zitat_ende

Okay, es ist also ein mathematischer Fakt, dass dieses Profil nicht berechnet werden kann. Ich habe in Subsurface mal alle meine Parameter von MultiDeco übernommen, Subsurface kann das Profil rechnen. Die Subsurface-Leute nehmen dann vermutlich keine Mathematik, sondern irgendwas anderes.

/Zitat_anfang
The v1.105 has no differences in the deco from previous versions, and the Android and iOS programs use the identical deco program code. Any variance is in the settings or sequence of dives computed.
/Zitat_ende

Davon bin ich noch nicht überzeugt, aber da ich keine Android-Version im Zugriff habe, kann ich nicht mal eben testen. Die Vielzahl der Parameter macht es gerade etwas schwierig über die Ferne.