Re: OSTC firmware upgrade partially broken
On 8/14/18 4:40 PM, Jan Mulder wrote: Since May 19, 2018 Heinrichs-Weikamp introduced something new with respect to firmware numbering. On that date a version was released called 2.97 SP1. As I found a simple bug related to CNS display yesterday, I was looking at the HW website and found out that I never had a message from Subsurface about this new version of the firmware. Some observations: [snip] See also: http://forum.heinrichsweikamp.com/read.php?6,19232 Things are getting a bit more complex, as the OSTC3/Plus does not report the SP level on the interface. So 2.97 SP1 reports that it is a 2.97. --jan ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC firmware upgrade partially broken
> On Aug 14, 2018, at 7:59 AM, Jef Driesen wrote: > > On 2018-08-14 16:47, Dirk Hohndel wrote: >>> On Aug 14, 2018, at 7:40 AM, Jan Mulder wrote: >>> Since May 19, 2018 Heinrichs-Weikamp introduced something new with respect >>> to firmware numbering. On that date a version was released called 2.97 SP1. >>> As I found a simple bug related to CNS display yesterday, I was looking at >>> the HW website and found out that I never had a message from Subsurface >>> about this new version of the firmware. >>> Some observations: >>> 1) libdivecomputer seems to report the same (integer) version number for >>> 2.97 and 2.97-SP1. I just upgraded my OSTC3+, and the version stays 609. >>> This seems something for Jef, but not sure this breaks anything at the >>> Subsurface end >> We have the version string in Subsurface. Does that change? It >> certainly appears to deal with X.Y.Z plus a bit for 'beta'. >> You can see it under extra data. > > That's the decoding of the OSTC4 firmware version. For the OSTC3 it's just X.Y Thanks, Jef - I noticed that after sending the email :-( /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC firmware upgrade partially broken
On 2018-08-14 16:47, Dirk Hohndel wrote: On Aug 14, 2018, at 7:40 AM, Jan Mulder wrote: Since May 19, 2018 Heinrichs-Weikamp introduced something new with respect to firmware numbering. On that date a version was released called 2.97 SP1. As I found a simple bug related to CNS display yesterday, I was looking at the HW website and found out that I never had a message from Subsurface about this new version of the firmware. Some observations: 1) libdivecomputer seems to report the same (integer) version number for 2.97 and 2.97-SP1. I just upgraded my OSTC3+, and the version stays 609. This seems something for Jef, but not sure this breaks anything at the Subsurface end We have the version string in Subsurface. Does that change? It certainly appears to deal with X.Y.Z plus a bit for 'beta'. You can see it under extra data. That's the decoding of the OSTC4 firmware version. For the OSTC3 it's just X.Y Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC firmware upgrade partially broken
> On Aug 14, 2018, at 7:40 AM, Jan Mulder wrote: > > Since May 19, 2018 Heinrichs-Weikamp introduced something new with respect to > firmware numbering. On that date a version was released called 2.97 SP1. As I > found a simple bug related to CNS display yesterday, I was looking at the HW > website and found out that I never had a message from Subsurface about this > new version of the firmware. > > Some observations: > 1) libdivecomputer seems to report the same (integer) version number for 2.97 > and 2.97-SP1. I just upgraded my OSTC3+, and the version stays 609. This > seems something for Jef, but not sure this breaks anything at the Subsurface > end We have the version string in Subsurface. Does that change? It certainly appears to deal with X.Y.Z plus a bit for 'beta'. You can see it under extra data. > 2) A HW download of a .txt is used by Subsurface to detect the latest > firmware version available. This .txt looks like this: > > > [2.97] > MD5: ec864820ee576841a2805227d7b39a99 > > - Stable Version - SP1 > > > [2.97] > MD5: 2f97a168530d2c86a43bbe382dde92ad > > - Stable Version - > > > etc. > > > And we do a simple check of the first line. And, we do not detect a 2.97 SP1 > version like this. For us (Subsurface) the easiest way out might be to ask HW > to number these SP releases like 2.97.1 or explicitly define the new firmware > versioning scheme, and add some parsing for the SP deal at our end. Yes, that would seem better. Matthias, is this something you could change on your end? Because in the text file the [2.97] does look unchanged to the previous one below... > 3) And just upgraded my OSTC to 2.97 SP1 using Subsurface (manual selection > of the proper .hex file) and that works just fine. So its the notification to > the user that there is a newer firmware version available that is broken. I'm glad - that part should be the easier one to fix :-) Thanks for the report, Jan. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
OSTC firmware upgrade partially broken
Since May 19, 2018 Heinrichs-Weikamp introduced something new with respect to firmware numbering. On that date a version was released called 2.97 SP1. As I found a simple bug related to CNS display yesterday, I was looking at the HW website and found out that I never had a message from Subsurface about this new version of the firmware. Some observations: 1) libdivecomputer seems to report the same (integer) version number for 2.97 and 2.97-SP1. I just upgraded my OSTC3+, and the version stays 609. This seems something for Jef, but not sure this breaks anything at the Subsurface end 2) A HW download of a .txt is used by Subsurface to detect the latest firmware version available. This .txt looks like this: [2.97] MD5: ec864820ee576841a2805227d7b39a99 - Stable Version - SP1 [2.97] MD5: 2f97a168530d2c86a43bbe382dde92ad - Stable Version - etc. And we do a simple check of the first line. And, we do not detect a 2.97 SP1 version like this. For us (Subsurface) the easiest way out might be to ask HW to number these SP releases like 2.97.1 or explicitly define the new firmware versioning scheme, and add some parsing for the SP deal at our end. 3) And just upgraded my OSTC to 2.97 SP1 using Subsurface (manual selection of the proper .hex file) and that works just fine. So its the notification to the user that there is a newer firmware version available that is broken. --jan ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
