Device serial numbers [was: Clean up some of the dive computer nickname code]

[Jef Driesen]

On 2013-01-10 00:10, Linus Torvalds wrote:
> Side note: as discussed with Dirk, the intent of this series is that
> we can save other information about the dive computer (serial numbers
> etc) in the device info structure.
>
> However, quite frankly, looking at what we get at least right now 
> from
> libdivecomputer, I doubt it is worth it. The "serial nr" thing is an
> integer, which is unlikely to actually match any serial numbering on
> the package or anything like that.
>
> For example, the Suunto serial number that libdivecomputer gives me
> for the helo2 is 389152795. The *actual* serial number of the device
> is "23500027".
>
> Guess what? Serial numbers are strings, not numbers. Look around,
> you'll notice that manufacturers almost always encode serial 
> "numbers"
> with letters etc. The libdivecomputer interface is wrong.
>
> It so happens that the Suunto serial number strings are strings that
> have all numbers, but they aren't *one* number. They are four bytes
> representing two numbers each, and the "23500027" string is actually
> the four bytes 23 50 00 27 (0x17 0x32 0x00 0x1b). And libdivecomputer
> has incorrectly parsed those four bytes as one number, not as the
> encoded serial number string it is. So the value 389152795 is 
> actually
> hex 0x1732001b, which is 0x17 0x32 0x00 0x1b, which is - 23 50 00 27.
>
> IOW, the serial numbers libdivecomputer gives us are useless. You
> could perhaps turn them into an actual serial number string on a
> per-vendor (or per-device) basis, if you know the vendor rules. The
> Suunto vendor rules *seem* to be pretty simple, based on the two
> devices I have (the Vyper Air clearly uses the same encoding, giving
> another 8-byte string). Other dive computers? Who knows?
>
> Anyway, the current libdivecomputer "serial number" information is
> wrong. It has some information, but the information is in the wrong
> format, and you need vendor-specific knowledge to turn it into the
> right string.
>
> As a result, there's no point in having subsurface save it. We can 
> use
> the integer form for the device ID hash, and that's all it is 
> actually
> useful for. It would be good if libdivecomputer continued to give the
> old "numeric serial number" for that use, but to make it *useful* we
> also need some interface to get the actual vendor string
> representation, so that we can save that. If we get the correct 
> serial
> numbers in the proper format that the vendor uses, *that* information
> wou;ld be useful to save for things like warranty purposes etc.
>
> It could be as simple as a new libdivecomputer callback ("given this
> serial *number*, what is the string for it?"), but it would probably
> be better to expand the current DC_EVENT_DEVINFO event to simply give
> us a string in addition to the number. Because it's not necessarily
> the case that all serial number strings can even be represented as a
> single 32-bit integer.

The primary purpose of the serial number in the DC_EVENT_DEVINFO event 
is to be able to uniquely identify individual devices (e.g. for use with 
the fingerprint feature). For this purpose, it doesn't really matter if 
the serial number (as returned by libdivecomputer) doesn't match the 
real serial number (as printed on the hardware). That's why I didn't 
bother to decode it properly, and just return the raw bytes wrapped in a 
32bit integer. In this sense the serial number is more like an opaque 
device id, and it was not really intended to be shown to the end-user 
(e.g. for warranty purposes).

Until now, all serial numbers did nicely fit into a 32bit integer, but 
if there ever happens to be a device where this isn't possible, we can 
always calculate some hash, just like you already do in subsurface. But 
of course that will only work if we make no guarantees that the 
libdivecomputer serial number will match the real serial number.

Jef