On 2017-10-31 12:12, Berthold Stoeger wrote:
Hi Jef,
On Dienstag, 31. Oktober 2017 11:29:00 CET Jef Driesen wrote:
On 2017-10-23 00:55, Berthold Stoeger wrote:
> On Sonntag, 22. Oktober 2017 04:31:39 CEST Linus Torvalds wrote:
>> so you literally *could* try to claim it's a G2 and try to see how far
>> it downloads.
>
> The handshake is different. The G2 client sends 1b and 1c10270000 and
> expects
> 01 as the answer twice. The Aladin Sport returns 00 in both cases.
> Since
> LogTrak doesn't do any handshake, I just removed the call to
> scubapro_g2_handshake().
Am I right you only tested downloading over bluetooth (BLE)? Can you
also try over USB? I suspect that logtrak still does the handshaking
when downloading over USB. If that's correct, then omitting the
handshaking is not specific to the Sport Matrix, but the underlying
transport.
To my knowledge the Sport Matrix does only support BLE! At least that's
how I
read
https://ww2.scubapro.com/en-GB/SWE/instruments/computers/products/aladin-sport-matrix.aspx:
| For PCs and Macs that are not equipped with built-in Bluetooth Low
Energy
| technology, the end user will have to buy a Bluetooth Low Energy USB
dongle
| which is available on the market.
I simply assumed it was similar to the G2, which supports both.
That's why I feel that dc_descriptor_get_transport() should return
flags, not
enums. You want to differentiate between USB, BT, USB+BT, don't you?
Indeed! Such a change is already on my todo list :-)
Because it breaks backwards compatibility, I will introduce it together
with some other non-backwards compatible changes, like the I/O
factoring. That way applications only have to be updated once.
But yes, doing handshakes based on transport not model is a good idea.
The less "if (model == X)" code we need, the better!
Note that in most cases the exact model number is communicated by the
device during the download. Needing the model number up front breaks
this auto-detection mechanism. (You would be surprised how many users
don't know exactly which model they have. For some dive computers, the
naming can indeed be confusing.)
I don't have access to the computer right know and will answer to your
other
remarks later.
Excellent!
Jef
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
