[PATCH 4/3] Document quirks with Ostc 4 versions

[Jef Driesen]

On 29-12-16 15:40, Anton Lundin wrote:
> On 29 December, 2016 - Jef Driesen wrote:
>
>> On 28-12-16 21:06, Anton Lundin wrote:
>>> -	// for now libdivecomputer gives us the firmware on device undecoded as integer
>>> +	// libdivecomputer gives us the firmware on device as an integer
>>> 	// for the OSTC that means highbyte.lowbyte is the version number
>>> +	// For OSTC 4's there is actually a another minor, x.y.Z, but its not
>>> +	// exposed via libdivecomputer, so we won't trigger this update flow
>>> +	// when the Z changes
>>> 	int firmwareOnDevice = devData.libdc_firmware;
>>> 	QString firmwareOnDeviceString = QString("%1.%2").arg(firmwareOnDevice / 256).arg(firmwareOnDevice % 256);
>>
>> The OSTC4 version number has four parts (X.Y.Z.Beta) and is (for
>> compatibility reasons) packed into two bytes, but it's done
>> different from the OSTC3 version number which has only two parts
>> (X.Y). You can find the details in libdivecomputer commit
>> ff15b865b2e35d38f0ee394c3a0d0218a763d5af.
>>
>
> As I read the documentation:
> Version/Identity (2) 0x69
>
> Note 2: OSTC4: limited version info, only major and sub-major version
> number, use 0x6B for complete info
>
>
> Not that I don't trust you, but where did you get the information about
> the version number packing from?

I got that info from Christian Weikamp.

I discovered this by accident, when we were investigating the ndl/deco bug. I 
wanted to implemented a workaround based on the firmware version, and noticed 
the decoded firmware version was not really what I expected :-)

The code was tested against data from Christian (I don't have an OSTC4 myself), 
so it should be correct.

Jef