błędu na rozejście się modelu a naszego organizmu potrzebny jest coraz większy
I to powinny uwzględniać poprawki w algorytmach.
Natomiast faktem jest, że mówimy o komputerach rekreacyjnych (cokolwiek to znaczy) i powinno się ich używać w takich zastosowaniach. 50m+ do rekreacji nie należy...
anarchista [Usunięty]
Wysłany: 30-03-2017, 10:15
grol napisał/a:
50m+ do rekreacji nie należy...
Problem jest inny, komputer powinien informować o dojściu do niebezpiecznego zakresu. Sytuacja która pojawiała się, komputer miał komunikat: Użyj Tabeli, bo padł. Jeszcze gorzej jak nawet tego nie zauważa że jest w krzakach, kazus Piotruś.
Kolejny problem, jaki jest margines sprzętu, czy dekompresję liczy do 50 m, 51 to już nie, czy to powinno posiadać szerszy margines 60 czy 70 m.
Problem jest inny, komputer powinien informować o dojściu do niebezpiecznego zakresu. Sytuacja która pojawiała się, komputer miał komunikat: Użyj Tabeli, bo padł. Jeszcze gorzej jak nawet tego nie zauważa że jest w krzakach, kazus Piotruś.
Kolejny problem, jaki jest margines sprzętu, czy dekompresję liczy do 50 m, 51 to już nie, czy to powinno posiadać szerszy margines 60 czy 70 m.
W artykule są opisane między innymi typowo wielo-gazowe komputery (Mares Icon Hd, Sunnto D9, Galileo Luna), ale nawet jedno-gazowy Mares Puck ustawiony na AIR liczy deco przynajmniej do 70 metrów, chociaż bardzo krzyczy, że mod przekroczony. Natomiast, przykładowo ustawiony na EAN 32, zaczyna się pluć po przekroczeniu MOD (40 metrów), w momencie przekroczenia 44,9 się wyłącza, powrót na dopuszczalną głębokość, powoduję, że dalej działa i liczy deco (ciekawe według czego, ale coś tam liczy).
Wiek: 65 Dołączył: 18 Lut 2009 Posty: 298 Skąd: Kraków
Wysłany: 30-03-2017, 11:39
anarchista napisał/a:
Problem jest inny, komputer powinien informować o dojściu do niebezpiecznego zakresu.
pozdrawiam rc
Racja. Komputery powinny nie tylko pokazywać ile zostało jeszcze czasu NDL lub ile należy odsiedzieć pod jakimś tam hipotetycznym sufitem ale informować np. wizualnie o pojawiającym się w tarkcie dekompresji przesyceniu (Pi-P). Czyli algorytm dekompresyjny powinien włączać alarm informujący użytkownika że zostaje przekroczone dozwolone przesycenie w tkance kontrolnej. W przypadku nurkowań NDL z reguły to tkanka najszybsza będzie tą tkanka kontrolną i ustawienie końcowego przesycenia w tej tkance na 0,8 bara w zupełności powinno wystarczyć do bezpiecznej dekomprescji z użyciem takich ustawien. W przypadku natomiast nurkowań dekompresyjnych to przesycenie końcowe powinno być stopniowo obniżane nawet do zakresu 0,4 bara w zależności od tego jaka tkanka w końcowej fazie odsycania przejmuje kontrolę nad dekompresją.
Mając taką informację bylibyśmy bardziej świadomi tego z jakim przesyceniem wychodzimy na powierznię.
Pozdrawiam Jacek
anarchista [Usunięty]
Wysłany: 30-03-2017, 12:10
jackdiver napisał/a:
do zakresu 0,4 bara w zależności od tego jaka tkanka w końcowej fazie odsycania przejmuje kontrolę nad dekompresją.
Nawet mniej, najniższe Mo dla azotu, dla 16 tkanki, to 12,7 czyli przesycenie tylko 0,27 bar.
0,4 to tylko 11 tkanka kolumna C, bez żadnego konserwatyzmu, pozostałe mniej.
krzkus napisał/a:
(ciekawe według czego, ale coś tam liczy).
Jest taki komplet parametrów, który umożliwia przeliczenie profilu dekompresji, dla dowolnej mieszaniny.
Co to jest, wiem i powinni producenci komputerów, no może z małym wyjątkiem.
Czy wiesz że tabele helioksowe są podane w ciśnieniu helu ? Można zaprojektować wiele mieszanin w oparciu o taką tabelę, obsłużyć wiele głębokości, zachowując ten sam profil dekompresji.
krzkus napisał/a:
(ciekawe według czego, ale coś tam liczy).
Jest taki komplet parametrów, który umożliwia przeliczenie profilu dekompresji, dla dowolnej mieszaniny.
Puck liczy według Rgbm Mares-Wienke, pytanie czy brał pod uwagę czas i głębokość, kiedy jawił się jako wyłączony
Wiek: 61 Dołączył: 24 Maj 2004 Posty: 3724 Skąd: Katowice
Wysłany: 30-03-2017, 12:40
krzkus napisał/a:
liczy według Rgbm Mares-Wienke
Naprawdę? Ach ten wspaniały marketing...
Cytat:
Mares-Wienke RGBM which is not a true RGBM algorithm but a Haldanian model with
some additional safety factors
anarchista [Usunięty]
Wysłany: 30-03-2017, 13:30
krzkus napisał/a:
pytanie czy brał pod uwagę czas i głębokość, kiedy jawił się jako wyłączony
To zależy: czy zatrudnili ludzi znających temat, czy najtańszych na rynku.
Szansa na znalezienie tych pierwszych jest znikoma, raczej zostali Ci drudzy.
is not a true RGBM napisał/a:
Mares-Wienke RGBM which is not a true RGBM algorithm but a Haldanian model with
some additional safety factors
Kanadyjski model szeregowo równoległy wszedł w CCR Innerspace, jako alternatywa. Model hybrydowy Hempelman-Buhlmann okazuje się być niezły. Modele uwzględniające perfuzję też są już na rynku komputerów nurkowych.
Producenci nie spowiadają się, żeby nie uczyć konkurencji.
their Mares-Wienke RGBM which is not a true RGBM algorithm
Czy są jakieś argumenty na poparcie tej tezy, oprócz tego że autor daje odnośnik do pozycji, której sam jest autorem, trochę śmieszne jak na takie kategoryczne stwierdzenie, porównanie wyników (SUNNTO vs MARES) i oczywiście o, którą wersję oprogramowania chodzi ( np. w ICON czy NEMO kolejny soft zmienia się dość znacznie w zakresie liczenia deco).
Wcale nie twierdzę, że tak nie jest, po prostu chciałbym zobaczyć porównanie algorytmów, coś nowszego niż to http://www.scuba-doc.com/rgbmim.pdf
[ Dodano: 30-03-2017, 14:49 ]
SUNNTO RGBM which is true RGBM vs Mares-Wienke RGBM which is not a true RGBM
Wiek: 50 Dołączył: 15 Mar 2010 Posty: 1532 Skąd: Jaworzno
Wysłany: 30-03-2017, 16:49
krzkus napisał/a:
Czy są jakieś argumenty na poparcie tej tezy, oprócz tego że autor daje odnośnik do pozycji, której sam jest autorem,
Był artykuł Bruce R.Wienke w którym wyprowadzał współczynniki kary wynikajace z RGBM opisywał jak ich użyć w modelu Haldanowskim. Tam również pisał że tak działa algorytm w kompach Mares'a.
Trzeba poszukać. No i artykuł był z przed kilku lat możne coś się zmieniło.
[ Dodano: 30-03-2017, 17:01 ]
Między innymi tu rok 2008...
B.R. Wienke, T.R. O’Leary / Computers in Biology and Medicine 38 (2008) 583 – 600 Statistical correlations and risk analyses techniques for a diving dual phase
bubble model and data bank using massively parallel supercomputers napisał/a:
Modified RGBM recreational algorithms (Haldane imbedded
with bubble reduction factors limiting reverse profile,
repetitive, and multiday diving), as coded in Suunto, Mares,
Dacor, UTC, Zeagle, Steam Machines, GAP, ABYSS, HydroSpace,
Plexus decometers, maintain an already low DCS
incidence rate of approximately 1/50,000 or less. More
RGBM decompression meters, including mixed gases, are
in the works.
Nie prawda - to taki sam algorytm neohaldanowski z modyfikacjami wynikającymi z porównywania z RGBM, tak jak zacytował wyżej mi_g.
Te komputery nie mają nawet takich procesorów, które byłyby w stanie przeliczyć algorytm pęcherzykowy.
Co to jest RGBM do końca nie wiadomo, bo, w odróżnieniu od VPM, nie jest on upubliczniony.
anarchista [Usunięty]
Wysłany: 30-03-2017, 22:25
B.R. Wienke, T.R. O’Leary / Computers in Biology and Medicine 38 (2008) 583 – 600 Statistical correlations and risk analyses techniques for a diving dual phase
bubble model and data bank using massively parallel supercomputers napisał/a:
ABYSS
Tu jest lekka sprzeczność w porónaniu do publikacji R.Kłosa z 2016r o możliwościach programu Abyss. Większa ilość tkanek i niesymetryczne odsycanie, nie ma śladu informacji o RGBM ograniczeniach.
Nie prawda - to taki sam algorytm neohaldanowski z modyfikacjami wynikającymi z porównywania z RGBM, tak jak zacytował wyżej mi_g.
To nic nie znaczy, nie wiesz jaki algorytm zastosowano w konkretnej wersji softu, i w jakim stopniu wyniki jego działania są niezgodne z modelem, który dodatkowo nie jest upubliczniony, więc z jakim modelem.
Może wieksze błedy powodują nieprecyzyjne czujniki ciśnienia, albo pomiar czasu. Chyba oczywiste, że nie ma czegoś takiego jak nieograniczona dokłądność.
anarchista [Usunięty]
Wysłany: 30-03-2017, 22:34
krzkus napisał/a:
Może wieksze błedy powodują nieprecyzyjne czujniki ciśnienia, albo pomiar czasu.
Mniejsze.
krzkus napisał/a:
Chyba oczywiste, że nie ma czegoś takiego jak nieograniczona dokładność.
Jak byś liczył w modelu, to znał byś poziom dokładności. Spójrz na ΔM, masz informację o dokładności. Wyniki można podać co do 1 s, tyle że ma to mało sensu. Zwykły kalkulator opędza bardzo dokładnie precyzję obliczeń, spój do publikacji w PHR.
Zobaczysz jak różne poprawki, mocno zmieniają wyniki. Jest goły Buhlmann, z poprawką Crossa, z poprawką na czas połowicznego odsycania, też poprawką na dekompresję tlenową i nie zerową prężność azotu w krwi.
Zwykły kalkulator opędza bardzo dokładnie precyzję obliczeń,
Nie rozumiemy się, kalkulator nie liczyonline pod wodą, jak wpiszesz do kalkulatora nurkowanie z pomiarem głebokości, co 1 sekundę, czyli 3600 watości na godzinę, gdzie dokłądność pomiaru głebokości jest +/- 2 % ? Masz taki kalkulator ? W excelu chcesz to sprawdzić ?
anarchista [Usunięty]
Wysłany: 31-03-2017, 08:11
krzkus napisał/a:
Masz taki kalkulator ? W excelu chcesz to sprawdzić ?
Przeczytaj tekst w PHR. Zrozum, potem zadawaj pytania, teraz nie masz podstaw w rozumieniu jakiegokolwiek modelu: 12, 16, 30, 32, tkankowego.
teraz nie masz podstaw w rozumieniu jakiegokolwiek modelu: 12, 16, 30, 32, tkankowego.
Odniosłem się do modelu RGBM, który jest lub nie odzwierciedlony w niektórych komputerach nurkowych, gdybyś dysponował opisem tego modelu, albo kodem źródłowymi jakiegokolwiek programu, który go realizuje, byłbym wdzięczny.
anarchista [Usunięty]
Wysłany: 31-03-2017, 08:34
krzkus napisał/a:
Odniosłem się do modelu RGBM, który jest lub nie odzwierciedlony w niektórych komputerach nurkowych, gdybyś dysponował opisem tego modelu, albo kodem źródłowymi jakiegokolwiek programu, który go realizuje, byłbym wdzięczny.
Jeżeli nie rozumiesz podstaw, to kod źródłowy jest Tobie nie potrzebny.
Jeżeli rozumiesz podstawy, to wtedy jest zbędny.
RGBM to marketingowa papka, dlaczego Innerspace weszło w szeregowo równoległy model ?
Dlaczego przeliczyłem wpływ perfuzji ?
Dlaczego w SCR specjalnych (o stałym ppO2) opieram się na wentylacji ?
Nie odpowiadaj, zastanów się.
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach Nie możesz załączać plików na tym forum Nie możesz ściągać załączników na tym forum
Administrator FORUM-NURAS uprzejmie informuje, że nie ponosi odpowiedzialności i w żaden sposób nie ingeruje w treść wypowiedzi umieszczanych przez użytkowników na Forum.
Zastrzega sobie jedynie prawo do usuwania i edytowania, w ciągu 24 godzin, postów o treści reklamowej, sprzecznej z prawem, wzywających do nienawiści rasowej, wyznaniowej, etnicznej
czy tez propagujących przemoc oraz treści powszechnie uznanych za naganne moralnie, społecznie niewłaściwe i naruszających zasady regulaminu.
Przypominam, że osoby zamieszczające opinie, o których mowa powyżej, mogą ponieść za ich treść odpowiedzialność karną lub cywilną.
Serwis wykorzystuje pliki cookies, które są zapisywane na Twoim komputerze. Technologia ta jest wykorzystywana w celach funkcjonalnych, statystycznych i reklamowych. Pozwala nam określać zachowania użytkowników na stronie, dostarczać im odpowiednie treści oraz reklamy, a także ułatwia korzystanie z serwisu, np. poprzez funkcję automatycznego logowania. Korzystanie z serwisu Forum-Nuras przy włączonej obsłudze plików cookies jest przez nas traktowane, jako wyrażenie zgody na zapisywanie ich w pamięci urządzenia, z którego korzystasz.
Jeżeli się na to nie zgadzasz, możesz w każdej chwili zmienić ustawienia swojej przeglądarki. Przeczytaj, jak wyłączyć pliki cookie i nie tylko
FAQ
Szukaj
Użytkownicy
Grupy
Kalendarz
Rejestracja
Zaloguj
Album
