New firmware 2.28beta

[heinrichsweikamp]

swissdiving Wrote:
> @Matthias,
> Will you integrate DiverM's code into 2.28?

Most likely not. I know the UK diving conditions and agree that's more comfortable at 6m - but the effect to the tissue load at 6m (Again: Assuming a short, no-deco dive) is low.

regards,
Matthias

[swissdiving]

I rest my case.

[DiverM]

Advantage OpenSource: You can compile your own adjusted firmware! -D

[size=x-small]edited a typo...[/size]

[scubatinoo]

heinrichsweikamp Wrote:
-------------------------------------------------------
> Most likely not. I know the UK diving conditions
> and agree that's more comfortable at 6m

In my eyes it's not about doing the safety stop at 6m instead of 5m. It is about displaying the stop between 6 and 3 Meters. In certain conditions it is not possible to stay exactly at 5m for keeping the countdown going. That's why the range has to go from 6 to 3m, regardless of any tissue issues...

[PeJo]

scubatinoo Wrote:

> In my eyes it's not about doing the safety stop at
> 6m instead of 5m. It is about displaying the stop
> between 6 and 3 Meters. In certain conditions it
> is not possible to stay exactly at 5m for keeping
> the countdown going. That's why the range has to
> go from 6 to 3m, regardless of any tissue
> issues...

(tu)

[DiverM]

scubatinoo Wrote:
-------------------------------------------------------
> heinrichsweikamp Wrote:
> --------------------------------------------------
> -----
> > Most likely not. I know the UK diving
> conditions
> > and agree that's more comfortable at 6m
>
> In my eyes it's not about doing the safety stop at
> 6m instead of 5m. It is about displaying the stop
> between 6 and 3 Meters. In certain conditions it
> is not possible to stay exactly at 5m for keeping
> the countdown going. That's why the range has to
> go from 6 to 3m, regardless of any tissue
> issues...


Absolutely! And the reason for me to adjust the depth to 6m and compile my own.

[JeanDo]

This discussion turns creasy... (no offense meant here)

People now want a count-down to be working in a condition they perfectly know to be inefficient for off-gasing.

I am curious to know how to justify that

[scubatinoo]

We are still talking about NDL-Dives, which means you can leave the water without any stop at all... The safety stop feature just adds some more safety to the dives because no one fitts exactly to the Bühlmann model. If you want to discuss this issue, we have to talk about if Bühlmann is the right model for tecnical dives at all... Or is it used by OSTC just because it is simple to implement and it doesn't require an extraordinary hardware, or just because ist is free available? We had the requests about using VPM already...

[swissdiving]

I knew this was going to be fun!!!!
>:D<

Keep it coming.

[Bardass]

I agree with you
Use stopwatch is sufficient at the depth you want during the time you want

[DiverM]

JeanDo Wrote:
-------------------------------------------------------
> This discussion turns creasy... (no offense meant
> here)
>
> People now want a count-down to be working in a
> condition they perfectly know to be inefficient
> for off-gasing.
>
> I am curious to know how to justify that

First let's get rid of a misconception: It's not about off-gasing. It's about micro-bubbles.

Stopping for 3 minutes, anywhere in the 6-3m zone, will reduce formation of micro-bubbles. Deep-stops reduces formation of micro-bubbles, so does the safety-stop, same physics involved. It really is that simple.

[Anonymous User]

DiverM Wrote:
about off-gasing. It's about micro-bubbles.
>
> Stopping for 3 minutes, anywhere in the 6-3m zone,
> will reduce formation of micro-bubbles. Deep-stops
> reduces formation of micro-bubbles, so does the
> safety-stop, same physics involved. It really is
> that simple.


If something is not simple then it's the mechanism that forms or dissolves micro bubbles during sports diving...

[DiverM]

JoStein Wrote:
>
>
> If something is not simple then it's the
> mechanism that forms or dissolves micro bubbles
> during sports diving...

True, the physics involved are very complicated, and sure enough, not understood by many. That said, I'm no expert, and even the experts don't agree on the physics.

Shake two cans of soda, open one immediatly after shaking, and the other after 3 minutes. Same physics.

[nakatomi]

Hi everyone,

today I compiled my own .hex file in order to get the 6m feature. Now unfortunately for a reason I do not understand, my own .hex files don´t work as well as the factory compiled ones. What happens? Well, every couple of minutes the N2 wakes up, rebuilds the MD2 hash and goes to sleep again. A couple of minutes later, the same thing happens. Does anyone have a clue what could be going on here? I cleaned before building, everything else seems to work nicely.

Thanks

Oliver

[heinrichsweikamp]

Make sure,
- to use the linker script 18f4685_ostc_mkII.lkr
- to include p2_deco.o as object file (In case you don't have the compiler installed)
- to set the library search path to code_part1\lib for the clib.lib and p18F4685.lib

regards,
Matthias

[heinrichsweikamp]

DiverM Wrote:
> Shake two cans of soda, open one immediatly after
> shaking, and the other after 3 minutes. Same
> physics.

These aren't micro bubbles anymore...

Since we're not researching on decompression theory on our own, we're using a well-documented, scientificaly verified and widely-used model for the OSTC code. (And this model doesn't know micro bubbles).

regards,
Matthias

[DiverM]

It's normal that a MD2 hash rebuild takes place, but only once I think...

Which exact revision of the source code did you use? And what changes did you make? The resulting hex file I then can compile should be the same as yours, to exclude any compiler misconfiguration?

[DiverM]

heinrichsweikamp Wrote:

> These aren't micro bubbles anymore...
>
> Since we're not researching on decompression
> theory on our own, we're using a well-documented,
> scientificaly verified and widely-used model for
> the OSTC code. (And this model doesn't know micro
> bubbles).
>
> regards,
> Matthias

I have not challenged the validity of the Bühlman algorithm, nor the validity of Erik Baker's Gradient Factors. Although, with hindsight, GF's are all about reducing micro-bubbles.

The bubbles in soda do start as micro-bubbles, the number of bubbles released is directly proportional to the amount of micro-bubbles in the liquid. The number of micro-bubbles depends on the state of agitation of the liquid. Whether those micro-bubbles are able to grow into large bubbles depends on whether the pressure is low enough to let the carbonic acid go out of solution and form C0[sub]2[/sub] bubbles.
The physics involded are the very same. Just so happens that the dissolution process runs faster in soda with carbonic acid, not in the least because of the pressure shock when opening the can.

[swissdiving]

This is still about the safety stop right!? :S

[nakatomi]

DiverM Wrote:
-------------------------------------------------------
> It's normal that a MD2 hash rebuild takes place,
> but only once I think...
>
> Which exact revision of the source code did you
> use? And what changes did you make? The resulting
> hex file I then can compile should be the same as
> yours, to exclude any compiler misconfiguration?


I´ve had this problem for some time now, I just can´t make working images. They compile fine and appear to be ok but they recalculate the hash and do other weird stuff. A couple of months ago I had an image that seemed to work great but would turn on at 7 meters instead of just below the surface. Weird stuff.

So I just deleted the entire source tree and synched again to rev 621. Threw away and made the project files from scratch.
Then I simply set safety_stop_start to .599 with no other changes, built and flashed. Same issue. Strange...

[nakatomi]

heinrichsweikamp Wrote:
-------------------------------------------------------
> Make sure,
> - to use the linker script 18f4685_ostc_mkII.lkr
> - to include p2_deco.o as object file (In case you
> don't have the compiler installed)
> - to set the library search path to code_part1\lib
> for the clib.lib and p18F4685.lib

Thank you Matthias, it seems like I used different clib.lib and p18F4685.lib files.
I´ll keep on testing...

Update: It appears not to md2-hash anymore, I´ll see how it behaves in the water tomorrow and followup

[JeanDo]

@DiverM: I'm happy I contributed to feed that troll.

But more seriously:
* I know about micro-bubbles from interstices or cavitation. In particular created by the valves of the hearth. But this have no direct relation with safety or deep stop.

* I known also about Erik's Baker papers. And GF. But also it says nothing about micro-bubbles or adding an extra safety stops when compartments are all happy.

* I do know about such or such dive schools that recommends to do stops in certain situations. The reason invoked is always vague, resuming to >.

So, does anybody have reference to scientific papers about safety stops ?

[DiverM]

JeanDo Wrote:
-------------------------------------------------------
> @DiverM: I'm happy I contributed to feed that
> troll.
Not taking it personal

>
> But more seriously:
> * I know about micro-bubbles from interstices or
> cavitation. In particular created by the valves of
> the hearth. But this have no direct relation with
> safety or deep stop.
Better known as PFO. And indeed no relation to any form of stop.

>
> * I known also about Erik's Baker papers. And GF.
> But also it says nothing about micro-bubbles or
> adding an extra safety stops when compartments are
> all happy.
True, but Erik C. Baker's Gradient Factors were published before 1998. Today it's 2012 if I recall correctly and some sciency stuff happened in the mean time.

>
> * I do know about such or such dive schools that
> recommends to do stops in certain situations. The
> reason invoked is always vague, resuming to is well known>>.
DAN says you'd better do safety-stops. But you know diving folk, Stubborn as hell. B)-

>
> So, does anybody have reference to scientific
> papers about safety stops ?

DAN and the USN have several papers. But if you want to read up more, wikipedia offers plenty references.


Despite the ZH-L16 algorithm being around since 1985, it is not outdated if used in conjuntion with GF's. It functions exceptionaly well, just not for the reasons Bühlmann and Erik C Baker envisioned.

And my apologies for me possibly being quite blunt.

[JeanDo]

@nakatomi

Interesting. But:

* The first paper advocate a deep stop at 15m too. And reason on compartment loading (with a final illustration using doppler bubble measurements). Using Gradient-factor (which computes from compartment loading too) to generate such deep stop(s) seems appropriate...

* The second paper do not discuss stops. But ascent speed (in short: fast/slow is better than linear). And perform experiments in very arch situations (in order to have ~ 50% of DCS). Again, GF-style deco do generate slowing down profiles.

Anyone have other papers to discuss ?

[scubatinoo]

Guys, please. You came up with arguments like inefficient off-gasing... A safety stop is a safety stop and it doesn't harm anyone and all others can switch it off.

The majority wants to have the stop between 6 and 3m so make them happy and end this discussions.

Don't try to prevent people doing stupid things - they do it anyway. (:P)