Amount of LogBook Entries

[Solodiver]

What is the expected amount of LogBook entries for CCR Usage of the OSTC!? I still have a max. amount of 11 dives in there while a buddies unit show 30+. I know there has been issues with this in the past but learned that they should be solved now. As I only having 10 or 11 dives in there running the newest firrwares all the time I'd be interested in experiences from other CCR divers. I know there are different factors impact this, but I guess I'm doing "normal" dives (70-80min, 60-80m).

TiA,
Jan

PS: I just did reset my logbook and see what happens the next days.

[Solodiver]

After resetting the logbook and doing several dives there are still only 15 dives in the log (only a few having 60min or more, most are less) while my buddies unit running older firmware show 30+. Whats wrong, I thought the size has been doubled?

Thx,
Jan

[heinrichsweikamp]

Hi,

It depends on the profile recording parameters (The number of events (Gas changes, SetPoint changes, Alarms, ect. is also a factor but usually this only add a few bytes/dive). Please post:
CF02, CF20, CF21, CF22, CF23, CF24, CF25, CF26

Hard limit is 255 dives.

Regards,
Matthias

[Solodiver]

Thx Matthias, I checked them before and will do this again. There is no direct or indirect interconnection with CC mode?

I'm still interested in experiences from other CC users.

Thx,
Jan

[heinrichsweikamp]

Solodiver Wrote:
> Thx Matthias, I checked them before and will do
> this again. There is no direct or indirect
> interconnection with CC mode?

Please post the actual values and I will tell you how many bytes/dive minute is stored and how many dive minutes will fit into the memory.

Cheers,
Matthias

[wrobell]

hi Jan,

do you have debug mode switched on?

regards,

w

[heinrichsweikamp]

> do you have debug mode switched on?

Has no effect on profile recording unless CF25>0...

Regards,
Matthias

[fishwithlungs]

Hi guys,

mine was at max with 74 dives on 1.9x.

Regards,
Richard

[Solodiver]

heinrichsweikamp Wrote:
-------------------------------------------------------
> Hi,
>
> It depends on the profile recording parameters
> (The number of events (Gas changes, SetPoint
> changes, Alarms, ect. is also a factor but usually
> this only add a few bytes/dive). Please post:
> CF02, CF20, CF21, CF22, CF23, CF24, CF25, CF26


Here we go:

CF02: 240
CF20: 3
CF21: 15
CF22: 15
CF23: 15
CF24: 0
CF25: 0
CF26: 15

At the moment my logbook shows 15 entries which is much more than in the past. I did some OC dives lately which has not happend before. Also, there are two very short dives logged (7 and 11 minutes), so the actual value is more 13.

Is CF20 having that much impact as the default value is 10?

Is the log somehow compressed or optimized (i.e. not storing any value if there is no change at all)?

> Hard limit is 255 dives.

Would be really cool to have this amount in my internal log

Thx,
Jan

[tiefunten]

Jan, if you set CF20 to 3, the OSTC saves the depth every 3 seconds. I think that is the problem for your small number of dives able to be saved, even worse the longer the dives you are normally doing are. In my opinion the default value of 10 is absolutely ok there, especially when you are making slow decents and ascents and not those rapid bounce dives...
You have to imagine that this is more than threefold the depth data your unit stores than with the default value. Furthermore, (although you adjusted the divisors), you are also saving more Temp/Deco/GF data than with the default value of CF21/22/23: Normally, those CF's are set to 6, which means that every 6th depth sampling (once per minute with the default settings), those data are recorded, too. As your unit saves depth every 3 seconds, you are saving for example the temperature every 3(CF20)*15(CF21)=45 seconds, also increasing the amount of data to be saved.

[heinrichsweikamp]

At last...

Solodiver Wrote:
> Here we go:
> CF20: 3

No surprise, that will basically triple the amount of samples stored compared to the default value -> 2/3 less then others using the default value. As said before, unless you're changing the setpoint very often it does not matter if it's OC or CC.

regards,
Matthias

[Solodiver]

So how many minutes will my unit save then? This has been sugested to be calculated based on my CF. The other reason posting my CF is that we have seen a bug in some Beta versions some month ago so I just want to make sure everything is like expected.

The reason for defining 3s is that I just want to have a smoth dive profile in my logs. There is no need to store temperature and other parameters that often so I'd suggest to increase the corresponding CF.

Is there really a need to store every X seconds if there is not a mentionable change in the parameter? Why can't one define the difference which triggers to save a new record instead of a fixed value? For the depth this could be 10cm for example. The records will then mainly be saved while ascending and descending, in the bottom part and the deco there should not be soo much records.

[tiefunten]

@Solodiver: My profiles are very smooth and fine using a sampling rate of 10s. Do you really think that it is worth to alter the whole code and make it more complicated (just think of the possible mistakes then and the calculation times necessary for what you are proposing) just to have a higher sampling rate? In my opinion, if you want to have these detailed data, you should live with less dives that can be saved by the unit. But of course the margin of CF 21/22/23 could be increased a little bit - but I'm quite sure this would not help enough concerning your memory-problem.

Nevertheless I would propose to increase the memory that can be used for logging dives as long as this space is not needed otherwise. (Matthias told me at the Boot-show that less than half of the memory is used so far).

[scubatinoo]

Keep your buoyancy better under control, then you won't have a jojo-profile in your divelog Kidding you again

Other dive computers store the data every 20 or even every 30 seconds. So i guess we are very happy with 10 sec and the possibility to change this value.

[TnT]

Solodiver Wrote:
-------------------------------------------------------
> Is there really a need to store every X seconds if
> there is not a mentionable change in the
> parameter? Why can't one define the difference
> which triggers to save a new record instead of a
> fixed value? For the depth this could be 10cm for
> example. The records will then mainly be saved
> while ascending and descending, in the bottom part
> and the deco there should not be soo much records.

Some Oceanic dive computers support such a depth based sample rate. It may look interesting at first, but in reality it's a pain in the ass to deal with. First of all, there is no guarantee that you'll actually save memory. That's due to the fact that you do not only have to store the depth, but also the timestamp of each sample. The second problem is that many applications expect a fixed amount of time between two consecutive samples, and that assumption breaks in this case.

If you are interested in the possible problems associated with all kinds of sampling issues, you should read this page I wrote some time ago: http://www.divesoftware.org/libdc/sampling.html

[Solodiver]

Thx, very valuable article. Although I'm pretty sure doing such optimizations is more a challenge than a real problem I get the point. I've no idea about the current implementation of the OSTC but maybe this optimization could at least be done for the event based values like temperature and CNS.

I would like to see an extension for CF 21-26 and also to use as much memory as available for storing the dive profiles (not using the whole amount has been a known information discussed here before). For CF21-26 it would also be nice to have an option to set this off.

Thx,
Jan

[Laurie_the_Knot]

Last November I had a dive trip to the Maldives - no icy diving for me as I'm a Warmducher. I did 35 dives, each about an hour long and the last 31 were retained in the OSTC memory. The relevant CF values were

CF20 = 10 (depth sampling rate) - 6 per minute
CF21 = 6 (divisor temp) - 1 per minute
CF22 = 6 (divisor decodat) - 1 per minute
CF23 = 6 (divisor GF) - 1 per minute
CF24 = 6 (divisor ppO2) - 1 per minute
CF25 = 0 (divisor debug)
CF26 = 6 (divisor CNS) - 1 per minute

I am soon to go on another trip where I hope to exceed 35 dives but I will be leaving my laptop at home so I am relying on the OSTC memory to retain all of the dives. In order to reduce the volume of data stored per dive but still retain as much detail as possible I have decided to amend the CF values as follows

CF20 = 12 (depth sampling rate) - 5 per minute
CF21 = 10 (divisor temp) - 1 per 2 minutes
CF22 = 10 (divisor decodat) - 1 per 2 minutes
CF23 = 10 (divisor GF) - 1 per 2 minutes
CF24 = 0 (divisor ppO2) - disabled as no data available
CF25 = 0 (divisor debug) - disabled
CF26 = 10 (divisor CNS) - 1 per 2 minutes

I have chosen these values since, for me, the data being recorded doesn't change that rapidly but the volume of data should be about 33% less per dive which should enable the storage of 46 dives before overflow.

[Solodiver]

This happens when I set CF=120:

[img]http://www.heinrichsweikamp.com/file.ph ... ok_bug.jpg[/img]

Might also be a bug in 2.21 but I guess this is a generell topic.
I'd also recommend to store an initial and the last value for the temperature.

[Solodiver]

BTW, this is how it looks like in JDiveLog:

[img]http://www.heinrichsweikamp.com/file.ph ... rofile.jpg[/img]

And this is a proper look:
[img]http://www.heinrichsweikamp.com/file.ph ... e=jan1.png[/img]

[Solodiver]

heinrichsweikamp Wrote:
> Please post the actual values and I will tell you
> how many bytes/dive minute is stored and how many
> dive minutes will fit into the memory.

Matthias, is there any answer to this?

I'd also be happy to know in the maximum number of samples which can be stored in the unit as of now.
Please also post a statement if there is any plans to extend the available memory for storing the logs.

Thx,
Jan

[heinrichsweikamp]

CF20: 3
-> 60bytes per minute

CF21: 15
CF22: 15
CF23: 15
CF26: 15
-> 8bytes per minute

Add 61bytes per dive for the dive header + some bytes for alarms (About one byte/alarm). You have 65536bytes of memory available for the logbook.

regards,
Matthias

[tiefunten]

@Matthias: Is there a possibility to increase the memory available for the logbook a little bit!? You told me at the "boot" exhibition that less than half of the existing memory is used by now...

CF20:3 means 60bytes/min, so is it right to assume approx. 20byte/min with CF20:10!?

[Solodiver]

Thx Matthias, this means 3bytes per Sample (CF20) and about 2 bytes per single Event?

Given a maximum number of 255 entries for the logbook we need a maximum of 255*61=15.555 bytes for the headers which means we have 49.981 bytes left for samples and events which means we can store about 14.145 samples incl. events for every 15th sample which means we have about 55 and half samples for a single dive when one tries to reach the max. number of entries in the logbook? As my average divetime for the last year is something between 60 and 70 min I would go for a sample rate of about 70 seconds. Maybe less in the outlook of a increased memory.

@tiefunten: I'd vote for 30byte/min

[tiefunten]

@Solodiver:
When it is really 3bytes/sample (CF20), then it is 18bytes/min when CF20 is set to default (10): 1 sample every ten seconds means 6 samples/min

I don't think it is useful to increase the memory that much to be able to store the maximum entries possible within the logbook. BUT: To be able to store ~50 dives (2-3 weeks of diving, maybe a safari) with nice profile data would be really nice.
That would need (65mins approx. divetime): 26 byte/min x 65mins x 50 (dives) + 50 x 61 byte/dive (header) + (50 byte + x) (1 alarm/dive, I also don't know how much memory is needed for gas switches) >= 87600 bytes. I would vote for an increase of available memory of 50% to approx. 90.000 byte. I am aware that this will further increase the delay time when you are switching to the logbook as the unit has to look through more memory then.

[divinglog]

@tiefunten: the downside of an increased logbook memory is, that the downloading of the dive data takes a lot longer. So people who download every single dive have to wait much longer each time.