forum.heinrichsweikamp.com

Hi Paul,

In OSTC firmware, GF_low is pinned (for the current dive) to the lowest ceiling you encountered.
Meaning is you start off-gasing while playing around at mid/shallow depth, the model keep in mind you have been deeper, and that you have more secure stops to do.

Regards,

Hi all,

This was a worst case ceiling (10 min at 60 m, Tx 18/50, GF 15/80) with the previous model:

> [img]file.php?2,file=359,filename=deco_spike_GF30-80.jpeg[/img]

With the modified firmware 2.61 (thanks to an idea reported by wrobell), we now have the following ceiling, in exactly the same situation, as simulated by latest OSTC Planner beta:

[img]file.php?2,file=369,filename=deco_noSpikes_fw698.jpg[/img]

The trick is to finish with 2sec steps (ie. 0.33m at 10 m/min, instead of 1 min = 10 m) during ascent before the first stop.
This seems necessary to stabilize the GF model when very different values are used for GF_low and GF_high.

And it produce roughly the same stops: Matthias reported an increase in the order of %1 on his test suite; all tests embedded in OSTC Planner do pass (with the +/- ~ 1 min allowed margin).

Great effort JeanDo.

I see the debate above about mathemathical versus practical problem. I would tend to say that it is not a big deal of a practical nature however it is very important to for the product to be able to show great accuracy with its deco calculations both in simulator and real time/dive mode. This is critical for giving all divers confidence in the device otherwise I'm thinking if this is a problem at this stage of evolution of the software then what else?

Great response from HW to close this down.

Oh and well done to Paul S and Fabio for being eagle eyed and reporting the problem. Nice one! (tu)

Now, i'm getting a spike during ascent... GF 15 / 85
[img]file.php?2,file=370,filename=spikes.jpg[/img]

Ahh, so it was an accuracy problem because it simulates the ascent as a set of time slices. Smaller time slice, more accurate.

Will this have any effect on the battery?

I thought these things usally used the Schriener equation to calculate the gas loading for a clean profile like a projected ascent in one go. I'm guessing that's beyond the CPU in the OSTC?