Using OSTC3 (BT/BLE version) current firmware version 2.97.
Using Subsurface, I found a strange CNS reading. It steps from 69% to 70 + 2^14 (16454%). I do not remember seeing that during the dive, but the divelog on the OSTC3 also shows an end CNS that is in the 2^14 range. Being involved in Subsurface development, I first suspected a bug in there (or libdivecomputer), but showing the strange high value on the device itself makes me believe its firmware.
A little bisecting in my logbook shows that this bug was not there in firmware 2.26.
Weird CNS values, possible firmware bug
Re: Weird CNS values, possible firmware bug
Well, it is a bug!
On many variables, the upper bits which are not needed to hold the operational value are used for flags, indicating e.g. thresholds exceeded, value not computed yet, etc. Normally, these flags are removed before the variable's content is printed to the screen. Obviously, you found a place were the bit 14 flag (attention threshold exceeded in this case) leaked through. We'll fix it in the next Service Pack!
BR
Ralph
On many variables, the upper bits which are not needed to hold the operational value are used for flags, indicating e.g. thresholds exceeded, value not computed yet, etc. Normally, these flags are removed before the variable's content is printed to the screen. Obviously, you found a place were the bit 14 flag (attention threshold exceeded in this case) leaked through. We'll fix it in the next Service Pack!
BR
Ralph
-
heinrichsweikamp
- Posts: 4379
- Joined: Sunday 13. May 2007, 18:07
Re: Weird CNS values, possible firmware bug
Hi,
Ralph provided me with the (easy) fix within minutes after this post. Thanks for sharing this find. A new 2.97 SP2 will be released tomorrow.
A work-around for libdivecomputer would be possible but I don't want to bother Jef with issues like this
Regards,
Matthias
Ralph provided me with the (easy) fix within minutes after this post. Thanks for sharing this find. A new 2.97 SP2 will be released tomorrow.
A work-around for libdivecomputer would be possible but I don't want to bother Jef with issues like this
Regards,
Matthias
Re: Weird CNS values, possible firmware bug
Hi Ralph and Matthias,
as always, the support from HW is one of the best a diver can find in the industry, so thanks (again). And fully agree that we do not need to bother Jef on this.
One thing slightly related is firmware version numbering. This is the 2nd time we see a SP stable release, and (obviously) both libdivecomputer and Subsurface seem confused by this. I'm currently writing an email to the Subsurface developer emailing list, as some changes are required at our end to detect these SP firmware releases with same version number automatically.
Jan Mulder
as always, the support from HW is one of the best a diver can find in the industry, so thanks (again). And fully agree that we do not need to bother Jef on this.
One thing slightly related is firmware version numbering. This is the 2nd time we see a SP stable release, and (obviously) both libdivecomputer and Subsurface seem confused by this. I'm currently writing an email to the Subsurface developer emailing list, as some changes are required at our end to detect these SP firmware releases with same version number automatically.
Jan Mulder
Re: Weird CNS values, possible firmware bug
Hi Jan,
the idea with the SP = Service Pack numbers was to be able to provide "only" bugfixes, whereas new firmware numbers x.y should be reserved to changes in functionality or new features. So from this / my point of view, it should be irrelevant for external tools which SP version the OSTC is running. Are there any aspects with the SPs i'm not aware of?
Thanks,
Ralph
the idea with the SP = Service Pack numbers was to be able to provide "only" bugfixes, whereas new firmware numbers x.y should be reserved to changes in functionality or new features. So from this / my point of view, it should be irrelevant for external tools which SP version the OSTC is running. Are there any aspects with the SPs i'm not aware of?
Thanks,
Ralph
Re: Weird CNS values, possible firmware bug
> Are there any aspects with the SPs i'm not aware of?
Probably. Subsurface (www.subsurface-divelog.org) has functionality to upgrade the firmware of the OSTCs. For this, it detects the latest version from the HW website (using http://www.heinrichsweikamp.net/autofir ... ngelog.txt) As the version number is not changing for a SP release, Subsurface users are not notified that there is a new version available. Obviously, we (the Subsurface developers) can extend the parsing of this .txt file to detect also SP releases, but this aspect is relatively new, and I just realized it. Parsing-wize, it would be simpler (at our end), to simply add a digit (so instead of 2.97 SP1, 2.97.1), but we can live with any defined choice of versioning scheme for firmware versions.
--jan
Probably. Subsurface (www.subsurface-divelog.org) has functionality to upgrade the firmware of the OSTCs. For this, it detects the latest version from the HW website (using http://www.heinrichsweikamp.net/autofir ... ngelog.txt) As the version number is not changing for a SP release, Subsurface users are not notified that there is a new version available. Obviously, we (the Subsurface developers) can extend the parsing of this .txt file to detect also SP releases, but this aspect is relatively new, and I just realized it. Parsing-wize, it would be simpler (at our end), to simply add a digit (so instead of 2.97 SP1, 2.97.1), but we can live with any defined choice of versioning scheme for firmware versions.
--jan
Re: Weird CNS values, possible firmware bug
Hi,
if only the version number from the website will be checked, it will be easy to write it as e.g. x.ySPz to make parsing easier. This is just a text file. But if this version number will be checked against the version reported by the OSTC (via readout through the comm interface), unfortunately the SP level is not transmitted in the moment. How does Subsurface trigger a software update notification: by caching the last known version or by cross-checking with the connected OSTC?
-R.
if only the version number from the website will be checked, it will be easy to write it as e.g. x.ySPz to make parsing easier. This is just a text file. But if this version number will be checked against the version reported by the OSTC (via readout through the comm interface), unfortunately the SP level is not transmitted in the moment. How does Subsurface trigger a software update notification: by caching the last known version or by cross-checking with the connected OSTC?
-R.
Re: Weird CNS values, possible firmware bug
> if only the version number from the website will
> be checked, it will be easy to write it as e.g.
> x.ySPz to make parsing easier. This is just a text
> file.
Then write it as x.y.SPz. That said, imho, the SP text does not add anything relevant, so then x.y.z is as good.
> But if this version number will be checked
> against the version reported by the OSTC (via
> readout through the comm interface), unfortunately
> the SP level is not transmitted in the moment. How
> does Subsurface trigger a software update
> notification: by caching the last known version or
> by cross-checking with the connected OSTC?
Subsurface does not cache the firmware version of the connected OSTC. Ok, not really true, as it is visible in all previous downloaded dives, and you might consider that as a form of a cache. But this not mean very much as the OSTC can be upgraded outside of Subsurface.
So we check against the reported firmware version from the connected device. Which obviously is an issue now the SP releases does not report this over the interface.
> be checked, it will be easy to write it as e.g.
> x.ySPz to make parsing easier. This is just a text
> file.
Then write it as x.y.SPz. That said, imho, the SP text does not add anything relevant, so then x.y.z is as good.
> But if this version number will be checked
> against the version reported by the OSTC (via
> readout through the comm interface), unfortunately
> the SP level is not transmitted in the moment. How
> does Subsurface trigger a software update
> notification: by caching the last known version or
> by cross-checking with the connected OSTC?
Subsurface does not cache the firmware version of the connected OSTC. Ok, not really true, as it is visible in all previous downloaded dives, and you might consider that as a form of a cache. But this not mean very much as the OSTC can be upgraded outside of Subsurface.
So we check against the reported firmware version from the connected device. Which obviously is an issue now the SP releases does not report this over the interface.
Re: Weird CNS values, possible firmware bug
I get the idea behind SP's, but I don't like the detail that they can't be represented in the current version number scheme, with anything less than changing the protocol and logbook format of the device.
Numbers are just numbers, so rather than sticking with 2.97 and adding service packs on top of that, just inc the fw number by one every service pack. You can even start with a zero at the end, call it 2.100 where 2.100 is the initial release, and 2.101 is the first service pack and so on.
(I wonder what will break when softwareversion_y starts being 3 digits, but hey, subsurface will handle it.)
//Anton
Numbers are just numbers, so rather than sticking with 2.97 and adding service packs on top of that, just inc the fw number by one every service pack. You can even start with a zero at the end, call it 2.100 where 2.100 is the initial release, and 2.101 is the first service pack and so on.
(I wonder what will break when softwareversion_y starts being 3 digits, but hey, subsurface will handle it.)
//Anton
Re: Weird CNS values, possible firmware bug
Hi all,
fully agree, we should avoid putting any effort in revised protocols, libraries etc. The SP was born out of the "beta" tag and should therefore stay as such: to identify internal development versions and maybe pre-release versions that get posted here in the forum for early-bird users, but that do not go into the official release track.
BR
Ralph
fully agree, we should avoid putting any effort in revised protocols, libraries etc. The SP was born out of the "beta" tag and should therefore stay as such: to identify internal development versions and maybe pre-release versions that get posted here in the forum for early-bird users, but that do not go into the official release track.
BR
Ralph
Re: Weird CNS values, possible firmware bug
But now I'm getting a little confused. A beta is something completely different in my book, than a true bug-fix release that is marked "Stable". Both the beta and SP versions are published at the HW website, so there is nothing internal to it. A beta is even meant for more testing from adventurous users. Further, I assume that any release with any version marking that is marked "Stable" is safe to install for any user (which makes it very different from beta releases that can have known and unknown deficiencies)
I fully agree with Anton and Ralph that changing the protocol and logbook format of something as a version number is not the way to go. But also agree with Anton that I do not like that SP versions can't be represented in the current version number scheme.
And what confuses me most is "... but that do not go into the official release track". For example, all the 2.97 SP1 fixes and the CNS fix is checked in to master (not on some topic branch that might need to be merged later). So I would be very surprised when any of those commits would be reverted for a 2.98 release.
I fully agree with Anton and Ralph that changing the protocol and logbook format of something as a version number is not the way to go. But also agree with Anton that I do not like that SP versions can't be represented in the current version number scheme.
And what confuses me most is "... but that do not go into the official release track". For example, all the 2.97 SP1 fixes and the CNS fix is checked in to master (not on some topic branch that might need to be merged later). So I would be very surprised when any of those commits would be reverted for a 2.98 release.