CNS profile and what else?

[heinrichsweikamp]

Hi,

The next beta will have a small update of the logbook format. I'll add the CNS profile to the data stream (As usual, customizable like the temperature profile).
The internal logbook will show the entry AND exit time of the dive, working average depth and CNS after the dive.
We'll also double the logbook memory capacity.
Any suggestions what to add?

Cheers,
Matthias

[dmainou]

Can we get the ceiling and temperature rendered on the graph?

Minimum and max temp
Surface interval
First stop
Max TTS
Max ascent rate
(if possible max descent rate)
Battery before and after the dive

Thanks mate, every day I love more my mk2.

[Rob]

A command to write the logbook and profiledata from pc to the OSTC.
To implement a kind of backup/restore for the OSTC.

regards
Rob

[mrbredon]

I know it's not logbook related.
But what I miss on the OTSC is a safetystop feature like the Suuntos have.
Means:
If a nodeco dive is deeper than 18m th computer request a safetystop and 5m for 3mins and counts it down.
Would be really nice for the normal holiday dives in Egypt or so...


regards
Axel

[dmainou]

mrbredon Wrote:
-------------------------------------------------------
> I know it's not logbook related.
> But what I miss on the OTSC is a safetystop
> feature like the Suuntos have.
> Means:
> If a nodeco dive is deeper than 18m th computer
> request a safetystop and 5m for 3mins and counts
> it down.
> Would be really nice for the normal holiday dives
> in Egypt or so...
>
>
> regards
> Axel


It's probably easy to add but what prevents you at pressent from arriving at 5m and using the stop wtch to count to 3 min?

I fail to see the great added value?

my two cents

[mrbredon]

@dmainou

I know that I could use the stopwatch.
But it would be more convinient if the OTSC does it by its own.

The value added depents on the user.
I personally see no value added in the entry time...

And if it is easy to implement, the why not ?

Axel

[sailor]

Hi,

computers with safety stop features have a different target group.

But to use the entry time rather then the exit time is pretty much industry standard.

Just my 2 cents, Reiner

[Bardass]

dmainou Wrote:
-------------------------------------------------------
> Can we get the ceiling and temperature rendered on
> the graph?
>
> Minimum and max temp
> Surface interval
> First stop
> Max TTS
> Max ascent rate
> (if possible max descent rate)
> Battery before and after the dive
>
> Thanks mate, every day I love more my mk2.

+1 with Dmainou

[dmainou]

mrbredon Wrote:
-------------------------------------------------------
> @dmainou
>
> I know that I could use the stopwatch.
> But it would be more convinient if the OTSC does
> it by its own.
>
> The value added depents on the user.
> I personally see no value added in the entry
> time...
>
> And if it is easy to implement, the why not ?
>
> Axel


BTW, that 3min at 5m is pretty much a PADI thing which goes well with the aggressive tables of the Oceanic Haldanian model. NAUI, to the best of my understanding promotes a much deeper safety stop based on Weinke's RGBM tables.

Suunto and others picked it out of fashion as PADI started promoting it to improve diver buoyancy and slow ascents.

With your ZHL you will have a conservative profile and if you use it on GF you are likely to get a mandatory 1 or 2 minute stops well before an Oceanic computer would ask for it.

So,it can get included but I believe that you already have a very powerful tool at hand. You just need to know what to do with it.

I am not picking up a fight or implying you don't know how to use it. I'm simply stating that the OSTC does so much more than a 3min @ 5m safety stop.

D

[Gucky]

Hallo,

bitte keine Bevormundung durch einen automatischen Sicherheitsstop!

[tiefunten]

An improvement of the logbook function sounds perfect. For me, the most important thing is to correct the bug within the calculation of the average depth. The entry-time is nice to have - but calculating it manually at least trains the brain

[JeanDo]

I would strongly suggest to log the GF (absolute) value.

It is a rather techy data, but it is interesting to evaluate the actual > you took during the ascent, hence to have an insight of what the various GF_low/GF_high settings do.

[dmainou]

JeanDo Wrote:
-------------------------------------------------------
> I would strongly suggest to log the GF (absolute)
> value.
>
> It is a rather techy data, but it is interesting
> to evaluate the actual you took during the
> ascent, hence to have an insight of what the
> various GF_low/GF_high settings do.

+1

[Solodiver]

JeanDo Wrote:
-------------------------------------------------------
> I would strongly suggest to log the GF (absolute)
> value.


+1
And please, please SetPoint too!

IMHO the temperature is already included, displaying is a thing which should be adressed to Jdivelog. Or do we talk about a display in the small OSTC screen?

CNS Values could be calculated (again) afterwards, so there is no strong need to store and transfer them in OSTC...

Thx,
Jan

[heinrichsweikamp]

dmainou Wrote:
-------------------------------------------------------
> Can we get the ceiling and temperature rendered on
> the graph?

On the OSTC itself? These informations are already stored (but not displayed).

> Minimum and max temp

Max. temp will most likely be the surface temperature due to the slowness of the sensor. Max. temp after 5 minutes of the dive or so could work.

> Surface interval

Ok, can be re-calculated from the other dives in the logbook.

> First stop
> Max TTS

Is already stored (But not displayed).

> Max ascent rate
> (if possible max descent rate)
> Battery before the dive

Should be possible. Personally I don't see much sense here.

Regards,
Matthias

[heinrichsweikamp]

JeanDo Wrote:
-------------------------------------------------------
> I would strongly suggest to log the GF (absolute)
> value.

As a profile or just the end-of-dive value?

> various GF_low/GF_high settings do.

GF_low and GF_high should be there, of course. I'll add this at once...

Regards,
Matthias

[heinrichsweikamp]

Solodiver Wrote:
> And please, please SetPoint too!

Done.

Matthias

[heinrichsweikamp]

tiefunten Wrote:
> perfect. For me, the most important thing is to
> correct the bug within the calculation of the

Done (For all dives made with 1.91 and later). It's now also the real value computed during the dive. Not recalculated from the samples.

regards,
Matthias

[heinrichsweikamp]

mrbredon Wrote:
> And if it is easy to implement, the why not ?

Hi Axel,

Yes, it's quite easy to implement. This idea has been discussed some times here.
Personally, I don't think that a computer generated safety stop does increase divers safety.

When we add this, it's definitely a customizable feature (ON/OFF).

Regards,
Matthias

[Chilihead]

Sehr schick wäre natürlich eine "ceiling-anzeige" wie beim Shearwater-Predator wie hier bereits schonmal beschrieben und bebildert.

ist aber vermutlich nicht ganz so einfach/schnell zu integrieren.

------------------------------------

Sicherheitsstopp-Anzeige als CF ... ok... dann kann ich ihn ja auf OFF lassen

[JeanDo]

--> Record absolute GF as a profile, so the curve can be seen on JDiveLog or DivingLog afterward.
GF at end-of-dive is not decisive, because the end-of-dive is not very well defined... And if you do your runtime, is should be the Gf_high value.
Also, the GF curve is too jaggy to be displayed on the small OSTC screen. See below:
[img]http://www.heinrichsweikamp.com/file.ph ... val_GF.jpg[/img]

Storing (or recomputing) the max absolute GF value can be interesting too, because you don't always do you run-time to the centimeter, and because it can be displayed together with the various dive parameters...
BUT (just as min/max temperature, ascent/descent speed) the instantaneous value is not very meaningful: the max of some averages over small time is far better...

Safety stop: I can add that, it is not so different from a gas-switch stops. Actually, you can already fake it by setting a gas-switch at the requested depth, for the requested time... Should work for weekend air dives

[nakatomi]

"When we add this, it's definitely a customizable feature (ON/OFF). "

IMHO, it will definitely help you sell more units

Almost every weekend I dive with beginners, who are absolutely amazed when it comes to the readability of the MK.2/N2 and the many features it offers.

But then the missing safety stop is a turn-off for some.
Because it makes them feel this dive computer is not the right one for them and not compatible with what they were taught in their OWD classes.

And yes, of course I agree that safety stops are for the most part pointless, that is for someone who knows what he is doing in the first place.

But having this feature would also make life simpler for me, when guiding beginners. Every once in a while I completely forget the safety stop, or forget when it started and will cut it short by a minute or so.
Especially beginners can be quite emotional when it comes to things like this and I hate the resulting discussions

[tiefunten]

dmainou wrote: Max TTS

+1!

[dmainou]

heinrichsweikamp Wrote:
-------------------------------------------------------
> mrbredon Wrote:
> > And if it is easy to implement, the why not ?
>
> Hi Axel,
>
> Yes, it's quite easy to implement. This idea has
> been discussed some times here.
> Personally, I don't think that a computer
> generated safety stop does increase divers safety.
>
>
> When we add this, it's definitely a customizable
> feature (ON/OFF).
>
> Regards,
> Matthias

Ok, I agree that if this will open the market for HW then I get the benefits as I deal with a stronger company.

The OSTC is priced very competitively even against the lower end computers. Locally a new, basic, Oceanic veo goes for 300 and a direct import from HW will cost under $700. This makes it cheaper than the cheapest suunto and with a colour screen! So, yes go for the lion share of the market.

May I humbly suggest that if HW is going down the path of catering for the recreational market that the solution be something a bit more holistic? That is, treat the recreational divers as such.

Since their knowledge of decompression theory and CF manipulation could potentially account to Zero, then I would do add a menu entry within the "reset" or "setup" menu to activate the "recreational mode".

This mode will simply:

• Reset all CF's to default,
• Change the deco type to ZHL-OC,
• Change the salinity to match other recreational computers,
• Turn the safety stop ON,
• Hide and thus prevent the manipulation of the CF's, salinity and decotype.
• Hide the CCR set point menu,
• Change the label of the "recreational" menu to "full capabilities",
• Add a warning in the simulator about going into decompression.

By doing this, HW would allow a recently qualified diver to operate the computer safely until such day when they feel capable of manipulating the cf's on their own.

Provided that HW, beefs up the manual then the silly, repetitive questions in these forum will also be minimised. (please make it an online manual so you can keep up with the development and its distribution)

HW will then be able to market the computer as the last computer any diver will ever need

My two cents

D

* PS there could even be a recreational SF1,2 & 3 that keeps widening the gap between CF's 11 & 12 (Sati and Desat).

[nakatomi]

Fantastic ideas, dmainou. I really like them!

Especially, as a result, this thought:

"...the last computer any diver will ever need"