forum.heinrichsweikamp.com

Hi,

To avoid any confusion with the 2.98beta here in the forum I have renamed the latest beta (With a lot of new functions and changes) 2.99. It's attached to this post. This version also previews the SAC rate display and side-mount mode for OSTC 2 TR users. Just run the version with the internal simulator and check some of the new warnings and info (Try a OC gas change to start). Most of these new features will get into the 3.00 stable then and some feedback is always appreciated.

regards,
Matthias

One thing to add: This beta will, unfortunately, reset your settings to default (Will not affect the logbook)!

It's a requirement due to some internal changes.

regards,
Matthias

I like the new display colour options and how some of the information is laid out (time of day and surface pressure are a nice touch)...

Not sure if it's just the simulator though, but operation feels a bit laggy.

Further edit: I have rolled back to 2.98 as the lag seems to be present in normal menus as well. By lag I mean a noticeable difference between button press and cursor moving along the menu.

In terms of feedback - I like the air integration features. Will there be a way to switch them off for non-AI models? Example: bar reading of air on main screen.

Hi,

if you mean the display color options (Settings -> Display Settings -> Colour Scheme) - they have been there since ages...

Yes, the content of the custom views has been rearranged a little bit, reducing multiple displaying of the same parameter and grouping some parameters that have cross-relations into the same view. That created some space for the surface pressure.

My OSTCs run quite smooth regarding button press to cursor reaction in surface modes and menues. But yes, to stabilise the display animations (blinking et. al.) in dive mode, the processing sequence has been changed so that Display Animation now takes preceedance over menu operation. That introduces a little bit of lag.

The Air Integration functions should not be visible on none-TR models. Maybe the hardware detection routine is not perfect yet. Which type of OSTC are you using? Anyhow, they can be deactivated via Settings -> Pressure Display -> Mode = off. When mode is set to off, all TR-specific code is skipped. Well, this menu entry schould also only be visible on TR models...

BR
Ralph

Hi Ralph,


- Between 2.98 and 2.99, the display colour options have changed. I was remarking that the new colour selection is quite more pleasant compared to the old colour selection.

- The lag is on the surface as well as the simulator, running on an OSTC2 (2017). I'll be curious to see if anyone else is reporting it.. if not, I will re-install 2.99 and give it another go.

- The TR option that was visible to me was the air tank pressure on the surface mode. As pointed out above, I am running an OSTC2 2017. I cannot recall if I saw anything directly correlated to the air integration functions in the simulator, but I am certain it was on the surface screen to the very least. Either way, if it is something that can be deactivated, as you pointed out, it is not really the end of the world

Ah, you mean the design of the displays regarding colors as such - yes, that has been worked on to establish an even more consistent visual encoding if something is at a Level of an attention, a warning, if a value is invalid or outdated or not available, etc.

During dive mode as well as when running the simulator (actually it's the same code being executed in both cases), the deco calculations are done in chunks that run for about half a second each. During these times, button presses are sensed and stored, but get processed once the current chunk has completed. That generates the lag. It should be possible to cut the chunks into smaller pieces (in terms of runtime per chunk) to increase responsiveness to button presses. But coding of that Change won't come before a V3.0 firmware.
In surface and surface menu mode, the code for procesing of the button operations has not changed, so there should not be additional lag...

By checking the code, TR-specific outputs should be inhibited / skiped on none-TR OSTCs. I'm still investigating...

BR
Ralph

The new screens are very useful and even the new settings, the only shortcoming of this beta is that it marked 4% battery with 4 volts, re-stating 2.98 returned to score 78%

Uup, you mean in surface mode it showed only 4% of battery charge while at the same time the battery voltage read 4.0V ?

Did you do a charging cycle, asking because once the charging controller signals 'battery full' the percentage reading will get calibrated and the percentage reading set to 100%. From that point on, percentage will be clocked up and down again dependent on current consumption and (partial) charging.

Hi sharpw,

regarding "The TR option that was visible to me was the air tank pressure on the surface mode.": on my side i could not reproduce this bug. Do you have some more details that could help to narrow down the source of the misbehaviour?

thanks,
Ralph

No I have not calibrated anything, I had just done a dry test, this thing had never happened to me with other updates, in fact, once re-installed the 2.98 is back in order

ok, so i won't digg into this any deeper in the moment as i am doing a lot of firmware uploading while developing and something alike never happened on any of my target OSTCs.

Ralph,

Sure - I will re-upload 2.99 tonight and take a picture of what I can see..

Regards

I actually liked the old red/orange scheme, use it a lot for night dives where the display is too bright even on the lowest setting. I was pleasantly surprised by the new scheme during the latest dives though, and the screen seemed less bright (on a different computer though).

Good afternoon,

This morning, I had a problem with my OSTC Plus / hwOS 2.99 beta : during descent, the screen froze (see picture attached) and stayed frozen until the battery was empty. The battery level was above 50% and the unit worked well on the surface.

Fortunalely I had a second computer. After battery removal and charging, the OSTC Plus restarted normally, no data was lost except the profile of the last dive (the one with the problem).

Any idea ? Bug in 2.99 beta or trouble with the unit ?

I dived with Matthias the day before, but this morning he was away...

Best regards.

Information to be added to my last post above : just before this dive, I changed the color scheme to standard and the brightness to high. Probably no relationship, but who knows...

Hello,

I have also found some (non-critical) issues in the current beta. This kind of hang-up with the compass (Was it calibrated?) should not happen but that's why we call it a beta version. We'll look into this, of course. The next stable 3.00 (Or however we'll call it) is still some weeks away.

Btw.: It's always a nice surprise meeting other OSTC users during diving

Regards,
Matthias

Hi,

As fa as I remember, I did not recalibrate the compass after loading 2.99 beta for in-situ testing.

Best regards.

Hello,
I think i found a bug:
On the page "Gas Needs Ascent" the right Gas ammount is shown. On page "Air/SAC/Need" sometimes it shows the right ammount, but sometimes it shows constant 400 (bar).
I can reproduce this error multiple times at the simulator(with gas "needs warning").
Maybe I need the TR sender (hope i will get it soon )?

Thanks Sascha,

i'll have a look at it.

BR
Ralph

heinrichsweikamp Wrote:
--------------------------------------------------
> The next stable 3.00 (Or
> however we'll call it) is still some weeks away.
>
Any news?

Hi Sasha,

coming back on:

"On the page "Gas Needs Ascent" the right Gas ammount is shown. On page "Air/SAC/Need" sometimes it shows the right ammount, but sometimes it shows constant 400 (bar)."

During times when - as you call it - the right ammounts are shown, are these ammounts pressures > 400 bar? I checked the code and found that pressure need values are in general limited to 999 bar, whereas in the TR-specific 'meassured / SAC / needed' view the need-value is limited to 400 bar due to memory utilization schemas.

Regarding next firmware release: we are nearly finished, but as usual things always take a bit longer than expected due to tiny late findings and improvements that are decided to go "alive" as soon as possible, too...

Best regards,
Ralph

Hi,

Last week I performed my first CCR dives with an OSTC (hwOS 2.99). It's globally satistying (approximately the same deco as the CCR computer), but there is two points I'm not sure to understand. Diluant was air.

With a set point of 0.7, the indication Dil:0.70 (white) is displayed from the surface to 18 m ; reaching 19 m, Dil:0.60 (yellow) is added with a yellow warning sign ; the first (white) indication is still displayed. Both yellow indications disappear when the setpoint is changed to 1.3.

Questions:
- The diluant will give a PpO[sub]2[/sub] higher than the setpoint at 23 m, so why the Dil:0.XX indication is it displayed above this depth ? Is it a 0.1 bar security margin ?
- Once the Dil:0.XX indication is displayed, what's the use to also display the white Dil:0.70 indication ? This is espacially disturbing with the layout screen, on which both indications and B/O are displayed in turn.

Second question : during dive, B/O3:NDL is displayed. What's the meaning of the 3 ? I have only one OC gas valid, gas 1.

All this can be reproduced in simulator mode.

Best regards,
Didier

Hi Didier,

you are given credential for discovering a bug or better to say misconception!

The white Dil:0.XX origins from the activated setting "always show ppO2" which does not make sense in combination with CCR mode as in CCR mode the current ppO2 is shown in the lower left corner at all times. I will supress this output in the next firmware.

The yellow Dil.X.XX message is actually an attention (yellow = attentions, red = warnings), informing you (as you have guessed) that your current pure diluent will - on a diluent flush - yield a ppO2 approching or exceeding your setpoint. The attention kicks in at 0.1 bar below current setpoint. This attention shall drive you either to adjust your setpoint or to be aware that a diluent flush won't bring down your ppO2 below setpoint any more. This message will be given in warning color (red) once the pure diluent's ppO2 is outside the general ppO2 min/max limits.

B/O3:xxx means xxx minutes TTS if doing a bailout and having 3 minutes delay until actual begin of ascent. This function is a variant of the normal fTTS and is detailed in the new HWOS tech manual: download HWOS tech manual / english.

best regards,
Ralph

Hi Ralph,

Thanks for your very clear (and quick) answers. And happy to help you to find some little bugs !

Have a nice day.

Ralph already mailed me the fix for this Bug (tu)

I think I can post a new (final?) beta 2.99 very soon. We also did real life testing of this version in the water.

Regards,
Matthias