hwOS Tech: 2.99 beta 5 released!

[ClaudeDive]

Thank you Ralph,

Top answer very well documented as always!(:P)(tu)B)-

[dadefay]

Hi Ralph,

I dived this week-end with release 2.99 beta 5 ; open circuit with air, no additional gas, no gas change until problem occured. Battery aroung 80%.

No problem during the first three dives, but while descending the fourth time, the current depth was displayed on a red background, Pp02 displayed 0 and an error code (03 as fas as I remember) was shown on the bottom left of the screen.

I entered the gas list, none of the five gases was selected ! After selection of air, the problem disappeared and did not come back again.

Dive profile from Subsurface attached.

Best regards.

[Ralph]

Hi Didier,

that's a strange thing that "normally" can not happen as there is no on-purpose code in the OSTC that switches or alters the current gas by itself. The Subsurface log looks clean to me, so the OSTC did not log any user-initiated gas changes. Can you please confirm this via the built-in logbook view, does it plot the depth in one color (the one associated with your single gas) only?

There is no "error code" with the OSTC outputs, what was displayed in the bottom left is the composition of the current gas. "O3" might have been "O2" meaning pure oxygen, what obyiously does not go along with a ppO2 reading of Zero. So something internal to the OSTC must have become confused, withdrawing all oxygen from the mix, yielding a ppO2 of zero and subsequently raising a low ppO2 warning with the depth rendered in red color. I will dig into the code and search for traces how such a thing may occur.

To our knowledge such a bug has not appeared before, so if anyone reading this here and having observed something similar before, please report! And please be always aware that a diving computer is just a piece of equipment, a quite complicated one, that may fail as any other equipment may do, too. So always have means with you that allow you to end your dive in a safe way.

thanks Didier,
best regards,
Ralph

[dadefay]

Hi again,

You're right, it was probably "Err O2", not "Err 03".

The three views of the internal logbook are attached. On the profile, you can see a blue line at the begining of the descent, but no gas was selected (see the third view). Then I changed for gas 1, the line changed to white and all returned to normal.

Note : on Subsurface, I have a warning sign a few seconds after the begining of the dive.

Kind regards,
Didier

[Ralph]

Hi Didier ,

the key to understanding this event is indeed the 3rd logbook page, which shows the gases that were configured for the dive. Since not long ago, i added *, = and X symbols to indicate their type: * denotes the gas set as first, = denote deco gases, gases with no symbol are of type travel and gases with an X are disabled. Your logbook entry shows all gases in disabled state! So far, so wired as this is not allowed and there are actually several defence lines installed to prevent this situation:

- first, when editing gases through the menu system, as soon as all gases are set to disabled the gas number 1 is automatically promoted to being the First gas.

- second, as part of the dive mode initialization, when the gas to start with is searched for in the gas list and no gas tagged as first is found, again gas no. 1 is reconfigured to being the First gas. And as the data shown on the logbook page are stored at the end of the dive, this correction has no other way as to show up there.

So in that particular case, the OSTC must have tumbled into divemode bypassing all of the above checks - which looks straight from the code pretty impossible... Do you remember doing anything unnormal with the OSTC before the dive, or at least anything other than usual?

The gas that was shown in the lower left corner may very well have been "Err03" which does not denote an error code but "Err" is printed instead of "Nx" for Nitroxes with less than 21% of oxygen as such gases are declared erratic. As such a gas was not configured, the index variable that points to the gas data in memory must have pointed to some illegal memory position where by random a 0 (read as Helium %) and a 3 (read as O2 %) was found. Again, this index variable gets initialized during dive mode initialization and by then has no other chance as to point to a valid gas.

So to sum up, something very strange and very unlikely must have striked your OSTC. I will continue rocking my brain for ideas on a scenario that may have caused it, but honestly for the moment i have no idea...

best regards,
Ralph

[dadefay]

Thanks Ralph for your explanation.

I really did nothing - special or not - between the morning dive and the afternoon dive when the trouble came : the computer stayed with my equipment in a shady corner during lunch, nobody could play with it.

Well, don't spend to much time with that problem, until somebody else reports something similar...

Best regards.

[Live2dive]

Hi Ralph and thank you very much for your explanations to the 1 to 5 points. Some last comments about them:

1-3-4: Ok, thanks!

2: Exceeded MODs. I understand the explanation. But if i configure a max ppO2 for the deepest part of the dive (1'4 for instance), my expectation is to get an attention (yellow) when approaching to it, and a warning (red) if ppO2 arrives to it or rises higher. In fact that is the way it was working in the previous firmware versions...

3: Better gas change (OC). Explanation understood. I much prefer the other way (cue for gas change once you arrive to it's change depth), as it worked in previous versions, but here i must recognize that it's only a personal preference because i'm more on the side of standard gases, always make gas-changes at same depths and team unification. Not a big issue because as you say it's always possible to make a change on the fly when needed.

Thanks again for your detailed explanations and good work.

Llorenç

[Ralph]

Hi Llorenç,

thanks for sharing your opinion! I fear, there isn't the perfect solution whatever way it is done. What i wanted to avoid is that there will be a ppO2 attention given while one is hanging at 21 meters on Nx50 or respectively at 6 meters on pure oxygen. For CNS and for tank pressure / gas needs, there is the concept of an attention serving as a kind of pre-warning and the warning itself. The idea of the attention in these cases is that deplepting gas supplies and build-up of CNS% is something irreversable during the dive and therefor should be brougth to the divers attention while there is still possibility to react on.
Opposit to that, exeeding the ppO2 for short periods doesn't do any harm and can be easily corrected for. So while in deco, the idea is to give a warning if above the ppO2 max deco, all else is ok and should not give yellow attentions while otherwise following the indicated stops. During the bottom (working) phase of the dive, little excursions above the ppO2 max (normal) will be prompted for in yellow, whereas massive excursions above the elevated ppO2 max deco threshold will set off the full warning system with ppO2 in red and the depth blinking in red, too.

For the gas changes, i am fully with you and a technical diver should know by heart when it's time to switch and also be able to switch gases on the fly. If you do the switch on the computer on the fly as well, or if you do it probably less than a minute later on the next regular stop, does not alter the deco calculation results by much. The merrit of the new implementation is, that it will also work in CCR mode: in the previous firmware versions, the diver-initiated switch to a deco gas e.g. switched the ppO2 warning thresholds (norm/deco). But in CCR mode, there isn't a gas switch, so some "internal" parameters needed to be engaged to control the OSTC switching from bottom mode to deco mode. And that (new) way of doing it should also keep consistency when doing a bailout, i.e. when seamlessly switching the OSTC calculations from CCR or pSCR to OC mode...

Side remark: when you do a switch on the fly and also switch the OSTC on the fly, while still being below the deco stop depth, the gas you'll be going to will be displayed in yellow as its ppO2 will be above the ppO2 max normal but below the ppO2 max deco. Furthermore it will be anotated with a '=' symbol that shall depict it as a deco gas (imagine the parallel lines of the equal sign stand for deco stops). Once you select the gas, the OSTC will switch to deco mode as you have on purpose selected a deco gas. And with the OSTC in deco mode now, the ppO2 warning threshold will be rised to ppO2 max deco, so the OSTC will not yell a ppO2 attention or warning at you once you are on the new gas.

Hope it makes sense how the "big puzzle" has been put together now.

Happy Diving,
Ralph

[bosmat]

Good evening,

I tested this beta in different dives in both OC and CCR and I must say that I find it better than the previous both in the menu out of the water and during the dive, compared to my Inspiration and another computer I did not find any error in the decompression calculation or another parameter, really a great job congratulations.

The only change that I would like to be able to set would be to choose whether the classic ascent in stages or progressive celing calculated on the gf set and not just the maximum celing, an option that I find on my ccr, if this is not possible for technical reasons another little thing that I appreciated on my old liquivision xeo was the presence of the seconds in the time of decompression stops.

They are small things but surely they would be nice considering the potential of your products

greetings mattia

[Ralph]

Hello Mattia,

first of all a big thanks for your contribution to testing the latest firmware!

Regarding your suggestions or feature requests: i'm diving an Inspi, too, so i am familiar with the progressive ceiling. True, the ceiling shown by the OSTC is computed with GF-high at all times and intended to be used as kind of emergency stop depth information in case one has to go above the indicated traditional stop depths for whatever reason. The ultimate stop depth, above the ceiling depth, is where the supersaturation hits the 100% mark. So logic is programmed into the firmware that violating the indicated stop depth will make the stop depth show up in yellow color for attention "only". Once the ceiling (at GF-high) is violated, the ceiling depth and the stop depth will turn red, plus the main depth display will start flashing in yellow color. And last and ultimate, when going above 100% supersaturation the main depth will turn to flashing in red color. So in this sequence of escalations, computing of the ceiling at GF-high is necessary to have the right triggers at hand. To avoid confusions, especially in emergency situations, i would like to refrain from computing and displaying two different ceiling depths, i.e. a GF-high one plus a progressive one.

For the stop times, honestly, if the OSTC would show seconds you would see the stops go away before the time has counted down to zero seconds. This has several reasons: First of all, the deco schedule is calculated in a minutes resolution, thus it does not know if a stop needs to last e.g. 5 minutes and 2 seconds or 5 minutes and 49 seconds. If calculation reveals that 5 minutes won't be enough and 6 minutes will be ok, the stop will be scheduled to last 6 minutes. Secondly, to put things towards the safe side, the deco schedule is calculated with the assumption that the diver is not exactly at the indicated stop depth, but a little bit deeper. So the stop times are always a little bit over-estimated. Lastly, as the tissues are re-calculated every 2 seconds according to the real depth, and the deco schedule is updated every 3 to 15 seconds (as more stops, as longer it takes, or in the reverse way: towards the final stops the OSTC becomes faster and faster in updating), the stops will always become cleared a little bit ahead of the initially indicated times.

Hope this little excursion into the inside of the OSTC was helpful to understand how the OSTC algorithmic is designed.

best regards,
Ralph

[Live2dive]

Thank you very much for your detailed explanations, Ralph. They are very clear, and such a transparency is really an important added value for HW computers.

Putting them together helps to have a 'big photo' of how the pieces of the OSTC algorithic puzzle have been designed, and rises higher the confidence on your products.

Happy to contribute to the tests and help in any way possible.

best regards,

Llorenç

[bosmat]

Thank you for all the info,
I had already read these motivations in old posts also on the fact of the tts increased from a meter to the minute from the last stop, I had for whopping several computers all with pros and cons and I must say that your software is the one with which I found myself better, was more a curiosity than a request.
Always available to test

[Erik69]

Dear All,

Thank you for this release, I tried it and it works good.

Will it be a release 2.99 beat 6 with the point 8 for cave diver?

I'm looking foorward to get it


Eric

[Ralph]

Hi Eric,

like your new footer calling for the cave mode.

Well, there are just a few days left until opening of the BOOT 2019 Exhibition
in Düsseldorf, Germany, so to keep the suspense this post of mine will be kept
short of words... Anyhow, to give you a glimpse view behind the curtain, you
can expect the V2.99 to come out of beta. And there won't be a V2.100... For
all other news -- see us at hall 3 / booth C61

BR
Ralph

[heinrichsweikamp]

Hi,

the 2.99 stable is already releases and available though our Apps and on the homepage. There was no time to make an announcement here in the forum, sorry. The Cave feature will follow in the 3.00 stable and can be previewed on the boot show.

regards,
Matthias

[Ralph]

Ähm, i fear Matthias was a little bit over-enthusiastic about cave mode in the last post. Truth has it there is already code for cave mode in the 3.00 working version, but it's not yet complete and operable. To be able to compute alternative versions of ascent calculation models, the hwos firmware needed to receive some internal modularization. That's the main focus of the upcomming v3.00. As a by-product, 3.00 has become incredibly fast...

Ralph

[heinrichsweikamp]

Hi,

But the 3.01 beta will have it

See you in 2 days, we'll leave for the "boot" show today.

regards,
Matthias

[Erik69]

Ralph, Matthias,

Don't worry, I won't let you go without this function !(:P)

I'm noticed a lot of improvements in the last version, but ,you know, french guys, we're never satisfied !


Thanks for the job, and I am volunteer to test the V3.01 !!


Eric

[scuba57]

Hello

I have updated to the stable version 2.99 using the file for the Italian

language but update Ostc 2 always in English

[Ralph]

Hi,

did i got it right: the Italien firmware version actually contains the English language pack?

Or is it only the outputs while the update process? That would be normal as the language switching function does not work while in the update process.

-R.

[scuba57]

HI
you understood well
I installed the final version 2.99 that I found on the homepage

[Ralph]

Arg, the Italian compile setting pointed to the English language file. Fixed it, please find the Italian version attached.

BR
Ralph

[scuba57]

Thank you Ralph
Now it is updated in Italian

[Live2dive]

Hello,

2.99 stable already installed, and tested today in a trimix dive... all perfect!

Thank you for your greay work!

Regards,

Llorenç

[algo]

Hi,

i put the 2.99 on my OSTC2. After the new setup of the parameters i tested it "on the couch" and yesterday i put it with me underwater. So far everything worked fine (as usual!).

I discovered only a small layout bug: In the menus in the bottom line the text from the serial number on should be one character more to the right... (so in my case the "r" from "" has space to be moved right). See also attached picture.

BR,
Alex
ps. i am really looking forward to the v3.00 - it seems to make the OSTC2 even better!