Aqualung I330R support

[Laurent]

Hello, as the diverlog+ app is poor, will subsurface soon support aqualung I330R dive computer?

[Dirk Hohndel]

We have seen a handful of requests for this model, but it appears that there may have been some changes to the transfer / download protocol that make this harder.
Please reach out if you want to help and are comfortable working with some development tools in the process - this will require tracing transfers with the Aqualung app, among other things.

/D

[Laurent]

Sorry, I think my skills are a bit poor... I can send you a copy of the files stored on my phone in the diverlogplus app folder (in the android - data folder)... May this help you?

[Gmail im Auftrag von Martin Gröger]

hm...

a friend uses this divecomputer and would be happy, if it would work with subsurface.

what do you need? I just can try to manage that without any promisess of success

keep on howling

grey

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/8A945DA8-548F-4569-A024-2FA6015C0BC3%40hohndel.org.

[AMIGAnTOMEK]

I use Subsurface from 5 years and now i buy i330r and i will wait for support for this computer. I try export dive data in .zxu format from DiveCloud but this is not possible. When i try i can open a zxu file and after this i see window with headers and a empty window to drag whis headers but no columns for drag it.

[miika....@gmail.com]

Can you send me the .zxu file so I can take a look what is going on with it?

[AMIGAnTOMEK]

Its fresh exported .zxu file from Diving Log 6.0

[miika....@gmail.com]

I am able to import the zxu on my Linux box with Subsurface 5.0.4. However, the sample time is parsed incorrectly. Looking at the version of DL7 specification I have, Diving Log writes the sample time stamp incorrectly. It only writes half minutes with decimal fraction and full minutes without decimal fraction. This fraction is required in the time based on my interpretation of the specs, should be 0 for full minutes, but still present. Anyway this does not explain why you are unable to import the file. I guess I will need to find a Windows machine from somewhere to test importing with that.

[AMIGAnTOMEK]

Maybe you can try a new import format for normal diverlog format i send you a little log with 5 dives for try. 

[Hugh Idiyit]

I have just ordered an i330R. Would it be helpful if I sent it to the Subsurface team so they could play around with it and analyse the log?

I could do without my new toy for a month :)

[Dirk Hohndel]

> On Feb 14, 2022, at 1:02 PM, 'Hugh Idiyit' wrote:
>
> I have just ordered an i330R. Would it be helpful if I sent it to the Subsurface team so they could play around with it and analyse the log?
>
> I could do without my new toy for a month :)

Thanks for the kind offer. I don't think any of the developers with experience adding support to new dive computers has available time right now.

But just in case - Jef... I assume you saw this?

Thanks

/D

[Jef Driesen]

Yes, I saw this.

Access to an i330R isn't the main problem at the moment. One of the developers
has one, and we have been able to capture the communication. I have made some
progress analyzing those results, but I didn't have time to work on this further
(because I have been busy with other things). It's on my todo list and I'll get
there, but can't tell in advance when.

Jef

[AMIGAnTOMEK]

Any progress with support for this device?

[Jef Driesen]

On 2022-04-12 11:54, AMIGAnTOMEK wrote:
> Any progress with support for this device?

No. The i330r is being recalled for a software update. Thus at the
moment, I have no access to one.

Jef

[Hugh Idiyit]

Hi Jef,

my i330R just updated to FW 1.004.

My offer to send you mine for analysis is still valid but.. it has 0 logged dives atm. So you need to dive by yourself with it to get valid data.

[Dirk Hohndel]

Not that I'm aware of.

/D

On May 28, 2022, at 5:33 AM, Julie wrote:

Dear all,

Any news on supporting the i330R ?

Thanks,

[Vincent]

Hello, 

Like amiga, I tried the following steps:

- Synch dive with Divecloud on DiverLog+ Android app

- Open  https://divecloud.net/files, select a dive and download zip file

- Unzip file and get .zxu file

- Open Subsurface app on MacOS

- Import zxu file: app is crashing with the following exception:

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000010
Exception Codes:       0x0000000000000001, 0x0000000000000010
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [13502]

VM Region Info: 0x10 is not in any region.  Bytes before following region: 4545916912
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                      10ef53000-10f40f000    [ 4848K] r-x/r-x SM=COW  ...OS/Subsurface

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   Subsurface                               0x10f16b260 parse_xml_buffer + 528
1   Subsurface                               0x10f142c36 parse_file + 2262
2   Subsurface                               0x10efff2ae MainWindow::loadFiles(QStringList) + 414
3   Subsurface                               0x10effde72 MainWindow::on_actionOpen_triggered() + 1682
4   Subsurface                               0x10ef62bae MainWindow::qt_metacall(QMetaObject::Call, int, void**) + 62
5   QtCore                                   0x1131cdf6e void doActivate<false>(QObject*, int, void**) + 1118
6   QtWidgets                                0x1115763c6 QAction::activate(QAction::ActionEvent) + 310
7   QtCore                                   0x1131c5b9f QObject::event(QEvent*) + 943
8   QtWidgets                                0x11157f9ea QApplicationPrivate::notify_helper(QObject*, QEvent*) + 266
9   QtWidgets                                0x111580e11 QApplication::notify(QObject*, QEvent*) + 497
10  QtCore                                   0x11319aa34 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 212
11  QtCore                                   0x11319bd79 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 809
12  libqcocoa.dylib                          0x111bec259 QCocoaEventDispatcherPrivate::processPostedEvents() + 313
13  libqcocoa.dylib                          0x111bec9c8 QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) + 40
14  CoreFoundation                        0x7ff8045b9aeb __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
15  CoreFoundation                        0x7ff8045b9a53 __CFRunLoopDoSource0 + 180
16  CoreFoundation                        0x7ff8045b97cd __CFRunLoopDoSources0 + 242
17  CoreFoundation                        0x7ff8045b81e8 __CFRunLoopRun + 892
18  CoreFoundation                        0x7ff8045b77ac CFRunLoopRunSpecific + 562
19  HIToolbox                             0x7ff80d23ece6 RunCurrentEventLoopInMode + 292
20  HIToolbox                             0x7ff80d23e913 ReceiveNextEventCommon + 283
21  HIToolbox                             0x7ff80d23e7e5 _BlockUntilNextEventMatchingListInModeWithFilter + 70
22  AppKit                                0x7ff806fde53d _DPSNextEvent + 927
23  AppKit                                0x7ff806fdcbfa -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
24  AppKit                                0x7ff806fcf2a9 -[NSApplication run] + 586
25  libqcocoa.dylib                          0x111beb62f QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 2495
26  QtCore                                   0x113196acf QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 431
27  QtCore                                   0x11319b042 QCoreApplication::exec() + 130
28  Subsurface                               0x10ef5c01b main + 4059
29  dyld                                     0x11390951e start + 462

I supposed that the file format generated by i330 isn't yet recognized?

If it can helps I attached the file.

It seems that Subsurface app is coded in C++ but I haven't worked on this language for a while!

Tell me if I can help to support this dive computer..

Thanks

[Dirk Hohndel]

Hi Vincent,

If I import the file below on Linux or macOS I get this:

[Tim Blankshain]

Hi,

Are there any updates on Subsurface supporting the i330r?

Tim

[Hugh Idiyit]

A friendly question, is there any news in the roadmap?

[Dirk Hohndel]

I don't think so - at least not that I've seen it.

/D

[Jef Driesen]

On 29/08/2022 21:25, Dirk Hohndel wrote:
> I don't think so - at least not that I've seen it.

No update at this moment. It's on my todo list, but I have been too busy with
other things.

Jef

[Yvo Buchholz]

Hi,

im also lockimg for an option to import my dives from the I330R.
But wehen I download the .zxu files from divecloud and try to import them into Subsurface only an empty dive is added.

I tried the File from @Dirk to check if I got corrupted files but even with his file only an empty Dive is added (tryed on Windows)

[Yvo Buchholz]

I added somme Screenshots and the .zxu file

[Jason Bramwell]

This is what I see with the same .zxu file, it imports the profile but nothing else. There doesn’t looks like there is a whole ton of detail in the .zxu file but location should be in there.

 

JB

 

 

Sent from Mail for Windows

--

You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/6fae4766-e0f0-40b6-bd71-e7dd2e252cc7n%40googlegroups.com.

 

[Yvo Buchholz]

If i could get the same result i would be finde. 

May u can share the import settings trouh a screenshot?

And what version of Subsurface are u using (im on 5.0.10)

I found a BUG:

If im changing the language to English im getting the graph!

When Subsurface is set to German the import fails (like shownm before) 

[Roger Doger (Roger)]

I am a new diver and have purchased the i330R.  
I will be following this topic. 

[Gerhard Van Huyssteen]

I'm also a new dive, also with an i330R, and will also follow this topic :-)

[Horst Kraus]

Hello, I also bought the i330R and tried several Apps. But nothing looks as Subsurface and - the main reason - I already started with Subsurface. So for me it is very difficult to import CSV. I am looking forward for an direct connection via Bluetooth on Microsoft (Laptop) as well as IOS and Adndroid OS on my IPad and mobile Phone.

Is there already someone working on this?

Thx Horst

[Linus Torvalds]

Ok, I broke down and ordered an i330R.

So in a week or so I'll hopefully be able to try to make sense of the ble situation. Knock wood.

       Linus

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/7fb4c91a-d76a-4dcf-ac98-2a5ad97718edn%40googlegroups.com.

[Horst Kraus]

Hi Linus,

thx much for your support. I think the I330R is an interesting computer and it offers a lot for its price.

So I assume that many divers will buy it and looking forward to use it with Subsurface.

Again, many thx

Horst

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CAHk-%3DwiYVssVNdeS548kkOa2zGU7AEg%2BjNzmMBCFQMR0wzdM9g%40mail.gmail.com.

--

Horst Kraus

Im Hirschel 9

D- 65623 Hahnstätten

Tel: +49 (0) 1525 311 62 72

[Guillaume Betous]

Hello everyone,

My wife also bought one a few months ago. If I can help in any way... don't hesitate to ask me !

gUI

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CAGVOYU7NzRPNdxq8yMuCbFgGbUd6_YBM2sQUqL9-eNEd-KGWtw%40mail.gmail.com.

--

Pour la santé de votre ordinateur, préférez les logiciels libres.

[Hugh Idiyit]

Many choose another TC because the i330R is not yet supported by Subsurface. I read this again and again in other forums.

[Linus Torvalds]

Annoying. Once more, we have what appears to be some odd non-standard
pairing thing for a dive computer that wants to use a special magic
sequence (by DiverLog+) to do something magical to "register" the
device.

So I have the i330R, and it's not talking unless you do something very
very special.

I have bluetooth packet snoop logs for it, but I was really hoping it
wasn't going to be yet another case of having to figure out some new
way of doing things wrong.

Oh well.

End result: no progress yet, but maybe I'll get the energy to try to
make sense of it all during the weekend.

Linus

[Linus Torvalds]

On Thu, Feb 9, 2023 at 1:50 PM Linus Torvalds
<torv...@linuxfoundation.org> wrote:
>
> So I have the i330R, and it's not talking unless you do something very
> very special.
>

> I have bluetooth packet snoop logs for it [...]

Hmm. It's more than just an added handshake to make it pair. In fact,
maybe the "pairing" it does with DiverLog+ is the same kind of
completely fake pairing the i770R did.

It turns out that apparently Pelagic has actually changed the protocol
entirely, and it is no longer doing the thing it used to do:

* byte 0: <0xCD>
* Seems to always have this value. Don't ask what it means
* byte 1: <d 1 c s s s s s>
* d=0 means "command", d=1 means "reply from dive computer"
* 1 is always set, afaik
* c=0 means "last packet" in sequence, c=1 means "more packets coming"
* sssss is a 5-bit sequence number for packets
* byte 2: <cmd seq>
* starts at 0 for the connection, incremented for each command
* byte 3: <length of data>
* 1-16 bytes of data per packet.
* byte 4..n: <data>

because the command header seems to have grown from that 4-byte thing
to a 5-byte thing.

The first byte is still 0xCD - don't ask me what deep meaning that has
to Pelagic, and the second byte is *similar*, although the "1 is
al;ways set" is no longer true. Now it seems to be a "multi-packet
reply has ended" bit, with one final ACK/result packet afterwards.

The third byte ("byte 2" above when doing that offset thing) doesn't
seem to be a sequence byte any more, and may be an actual command byte
(the reply always has the same byte). The fourth byte is some random
noise, and now the <length of data> is in the *fifth* byte.

The replies from the dive computer now seem to have an optional "data"
part, and then always a two-byte "result" part (that's what that "1 is
no longer always set" bit in the second byte is part of).

So a sequence now can look something like this:

cmd: cd 40 fa f6 09 000000000000000000
reply: cd c0 fa 94 02 0100

cmd: cd 80 fa 2e 10 150216ff4e53159000204744332420ff
reply: cd c0 fa cc 02 027e

cmd: cd 40 22 4a 09 000000000c00000000
reply: cd 80 22 02 10 01000000c8550f008000000047440000
reply: cd c0 22 40 02 02fb

cmd: cd 40 97 12 09 373031550000000000
reply: cd c0 97 68 02 01fb

cmd: cd 40 27 32 09 000000000001000000
reply: cd a0 27 76 60 150216ff4e53159000204744332420…
reply: cd a1 27 ce 60 ffffffffffffffffffffffffffffff…
reply: cd 82 27 08 40 ffffffffffffffffffffffffffffff…
reply: cd c0 27 8e 02 02fb

cmd: cd 40 29 c6 09 000000000001000000
reply: cd a0 29 88 60 000001010002000000000000050505…
reply: cd a1 29 f6 60 000000000000000000000000000000…
reply: cd 82 29 26 40 000000000000000000000000000000…
reply: cd c0 29 18 02 0200

…

Jef, does this remind you of anything? It certainly bears some
similarities to what the current "Oceanic Atom2" rules are, but it's
very much not at all the same.

Linus

[Jason Bramwell]

Surely the manufacturer making this proprietary is actually more effort on their part rather than keeping things simple and open, especially changing this from a previous computer that they have on their ecosystem, I don’t really understand why they’d do that. I think the DiverLog+ app is free so it’s not like they are making money out of the software like game’s consoles used to do, make a loss on the hardware but recoup the money on the software.

Jason

Sent from my iPhone

> On 10 Feb 2023, at 01:51, Linus Torvalds <torv...@linuxfoundation.org> wrote:
>
> On Thu, Feb 9, 2023 at 1:50 PM Linus Torvalds

> --
> You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CAHk-%3Dwhq4SmgQJxQ9Ti4nhFX%3DrEN_oFop44zWa_kNtfqeEf3Rw%40mail.gmail.com.

[pe...@familie-neuhaus.de]

Hi all, any news on the Subsurface  support fo i330R?

I need to purchase a new dive computer ... but I want one compatible with my existing Subsurface log book. Thus, asking.

In any case: Thanks to those of you working on the issue.

Peter

[barnaby...@gmail.com]

Hi all,
Does it connect to Subsurface desktop (or mobile) via the cable?

Thanks,

Barnaby

[Gaétan RYCKEBOER]

Hi,

The i330 is really an annoying device. Cheap and really clear when down in the dark, the only way I know for the moment to fetch the logs and configure it is via the android/ios app which uses a really non standard BT handshaking and communication protocol.

It seems that Aqualung as done all they would be able to, to obfuscate the protocol and data exchange.

No, it doesn’t connect via cable.

No, it doesn’t connect to their own PC or Macos app.

No, it doesn’t connect to any other application than divelog+ on Android or IOS.

And no, the divelog+ doesn’t export the logs by any way to be imported into subsurface.

Even the Linus best efforts to reverse engineer the data exchange protocol are (for the moment?) unsuccessful.

In fact, on more time, they sell a device and publicize the fact that the user will be allowed to use the dive logs, but it is not the case. You may consider a return to seller, I personally do.

[Gaétan RYCKEBOER]

It is not completely true.

You can import the logs in the mobile app (only!), synchronize to the cloud which is (for now) free as a beer, use them in the Divelog on Windows or MacOS, but if you want your own datas, you need to pay for the full version which is the only one able to export the datas.

So, when buying the computer, take in account that you will need a license for divelog full software to export the datas, which is 20$ more.

It doesn’t seems completely legal to me (because it is written down nowhere ; it is even written that the PC software will be able to synchronise with the computer which is a lie), at least it is not fair.

[Yvo „Langenscheid“ -]

I have to correct the last Information:

Yes you can only get the Divelogs from your computer using the DiverLog+ App

From there you can export the divelogs to Divecloud (free account needed which allows you to store 10 dives).

And from Divecloud you can export the Dives in the DAN file format which can be imported into Subsurface.

Not every datapoint is transferred perfect (location, dive number, …) but it works for the basic datasets.

Am 05.06.2023 um 06:54 schrieb Gaétan RYCKEBOER <woy...@gmail.com>:

It is not completely true.

You received this message because you are subscribed to a topic in the Google Groups "Subsurface Divelog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/subsurface-divelog/TOrg_Bw1Qng/unsubscribe.
To unsubscribe from this group and all its topics, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/97203272-b7d3-4ed1-9c41-f490cbdc81b6n%40googlegroups.com.

[Matija Semenič]

I import dives to divelogs.de from full Diverlog app, then I can sync it with Subsurface or any other Diving app. 

ponedeljek, 5. junij 2023 ob 11:11:48 UTC+2 je oseba yvo.bu...@gmail.com napisala:

[Linus Torvalds]

On Mon, Jun 5, 2023 at 12:15 AM Gaétan RYCKEBOER <woy...@gmail.com> wrote:
>
> Even the Linus best efforts to reverse engineer the data exchange
> protocol are (for the moment?) unsuccessful.

I wouldn't say "Even Linus", and I won't call it my "best effort".

More like "I was hoping it looked exactly like something else but with
just a small change". Which is commonly the case for new dive
computers, but this time it was annoyingly more than that, and I
couldn't find it in myself to care enough to figure things out.

Jef does seem to have a handle on it, so it will hopefully happen soonish,

Linus

[JB2Cool]

I am a bit surprised (should i be?) that it doesn't looks similar to something else already existing, i ran into a similar thing with someone trying to export logs from a piece of Cressi software last week, it's like they are going out of their way to make things hard for you when there are established file formats and existing protocols, why make something new and proprietary? I could understand it if the manufacturers were trying to lock you in to an ecosystem like Apple do but if they are just trying to sell diver computers then surely it's easier for them to make them work with an existing piece of software and then they wouldn't have to even bother making their own software.

Am I being naive or is there more to it than that?

JB

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CAHk-%3Dwjsn3-_Ps%3Db%3D_wPCn%3D7jbZa%2Bu0Z1HOnhwMzkCmuvFQoCQ%40mail.gmail.com.

[Linus Torvalds]

On Mon, Jun 5, 2023 at 12:03 PM JB2Cool <jb2...@gmail.com> wrote:
>
> I am a bit surprised (should i be?) that it doesn't looks similar to something else already existing,

Well, it might not be due to any actual evil intentions.

Some of the dive computer protocols are really pretty bad, and have
years (decades) of history. At some point somebody decides that they
want to add a field that is really not going to fit in the old
protocol any more, and they just make some core part of it wider or do
something else.

And usually when you do that, and you know "ok, this means that the
other side really needs changes", you then just go all in and make all
the other changes you've wanted to do for a long time, but just
couldn't do when you tried to keep it all compatible.

So big changes could be quite natural. The changes might not look
very sane, but maybe it all still fits within the framework of the
vendor parsing code, and it's just a fairly small change for them.

That said, there are also very real reasons why those dive computer
manufacturers do end up trying to keep a strict grip on downloaders:
yes, they made their money selling you that dive computer, but they
want to sell you the _next_ dive computer you buy too.

So if they can keep you locked into their ecosystem, and all your
dives are in their vendor format, and you get used to _their_ way of
doing things, then you'll probably upgrade to another of their dive
computers next time you buy one.

Linus

[Michael Keller]

On Tuesday, June 6, 2023 at 4:03:51 AM UTC+12 JB2Cool wrote:

I am a bit surprised (should i be?) that it doesn't looks similar to something else already existing, i ran into a similar thing with someone trying to export logs from a piece of Cressi software last week, it's like they are going out of their way to make things hard for you when there are established file formats and existing protocols, why make something new and proprietary? I could understand it if the manufacturers were trying to lock you in to an ecosystem like Apple do but if they are just trying to sell diver computers then surely it's easier for them to make them work with an existing piece of software and then they wouldn't have to even bother making their own software.

Am I being naive or is there more to it than that?

I think looking at this as a 'software problem' is not entirely correct. In most cases for dive computers the firmware running on the device comes first, and the data exchange protocol and the log management software are just an 'afterthought' to that. And firmware design is often driven by electronics designers and engineers who are typically thinking less in terms of 'versioning' and 'backwards compatibility' and more in terms of cost effectively producing and selling physical units. Looked at it from this point of view, it is entirely possible that entirely different microprocessor architectures or bluetooth chipsets are used for successive devices within the same product family, for cost or availability reasons, and then require a more or less complete rewrite of the firmware, with the communications protocol done as an afterthought when the rest of the firmware is already working. I've seen cases of products where the microprocessor architecture was changed and the firmware was rewritten for one and the same 'product', without any change of the UI exposed to the customer...

When you buy a washing machine or a TV set you don't care if it is 'backwards compatible' to your last washing machine or TV set, and more that it meets the requirements and has some nice features on top.

Just my 2 cents

  Michael Keller 

[Maik Brunner]

Hi guys,

I am a software developer & consultant from Germany. Normally I am working on telematics devices for heavy trucks and logistics which also includes embedded programming, interfaces and communication protocols. I also own an Aqualung i330r and will get a Ratio ix3m 2 soon which I plan to use together with Subsurface. I am very interested to be able to manage both computers with the same software.

@Linus: May I help you to dig deeper into the communication protocol of the bluetooth messages exchanged between the reading device and the Aqualung i330r? Would it help you if I provide you some code which is able to communicate with the computer and is also able to parse the payload?

Kind regards,

Maik

[Gaétan RYCKEBOER]

It seems that the library advances, and all the logs are currently available for engineering and development. But…
The season advances, and the lib is still not advanced to early commits… :)
Do you have any dev status of it? Do you think some early adopters may try to help the team fixing bugs?

[Jef Driesen]

On 10/08/2023 12:50, Gaétan RYCKEBOER wrote:
> It seems that the library advances, and all the logs are currently available for
> engineering and development. But…
> The season advances, and the lib is still not advanced to early commits… :)
> Do you have any dev status of it? Do you think some early adopters may try to
> help the team fixing bugs?

I expect to have something ready to test in the next few days. To help testing
this first version, you'll need either Windows or Linux (these are the only
platforms for which I have a BLE enabled build environment) and a bit of
technical knowledge for running command-line applications. If you can help with
this, let me know.

Something that you can already try now is it to pair the i330R using the Windows
control panel ("Add new bluetooth device"). Next, download this build:

https://libdivecomputer.org/builds/experimental/windows/dctool-ble.exe

and run with these options:

dctool-ble.exe -vv scan -t ble

If the i330R is detected, then everything is ready for the next step.

Jef

[Jef Driesen]

On 17/08/2023 14:12, Gaétan RYCKEBOER wrote:>>
https://libdivecomputer.org/builds/experimental/windows/dctool-ble.exe
>>
>> and run with these options:
>>
>> dctool-ble.exe -vv scan -t ble
>>
>> If the i330R is detected, then everything is ready for the next step.
>

> The tool is downloaded and working, but doesn’t seem to scan anything. Instead, it only displays the BT registered list, and – of course – isn’t able to see the i330r.

Did you first try to pair the i330r using the built-in Windows tools? Using the
"Add new bluetooth device" in the Windows control panel? That's was the
important part to try.

The command-line can indeed only see devices that first have been added to the
Windows system. It can't setup the pairing on its own. So if the pairing with
Windows doesn't work, then we can't use the command-line tool.

Jef

[Holger Wi]

I tried your instructions. Here is what I've found:

For windows to recognize the i330r it is necessary to enable advanced bluetooth scanning (found under devices - device settings):

Once done, the name is (at least for me) "GD" followed by the serial number.

Unfortunately, I was unable to connect the computer because it requiers a 6-digit passcode. For me it only shows up when trying to add the computer in the DiverLog+ app.
On the AL i330r the bluetooth symbol turns green when trying to pair from the PC, but no passcode is shown.

I was wondering if it really is necessary to do all that. It is pretty easy to get hands on the log files (.zxu) after uploading them to DiveCloud.
They are simple text files with all the data readable from notepad. Imo it should be pretty easy to implement an import dialog within Subsurface itself.
However, this is way off my field of expertise.

Cheers

[Jef Driesen]

On 17/08/2023 18:57, Holger Wi wrote:
> I tried your instructions. Here is what I've found:
>
> For windows to recognize the i330r it is necessary to enable advanced bluetooth

> scanning (found under devices - device settings): Zwischenablage01.jpg

>
> Once done, the name is (at least for me) "GD" followed by the serial number.

The "GD" is the model number of the i330R.

> Unfortunately, I was unable to connect the computer because it requiers a
> 6-digit passcode. For me it only shows up when trying to add the computer in the
> DiverLog+ app.
> On the AL i330r the bluetooth symbol turns green when trying to pair from the
> PC, but no passcode is shown.

The problem here is that the i330R uses a proprietary pairing mechanism instead
of the standard bluetooth pairing. To make the i330R show the passcode, we need
to send some commands. But of course that already requires a connection to the
dive computer. But on windows, the command-line tool can only connect to devices
that are already paired. So this is a chicken and egg problem.

Is subsurface able to detect the i330R?

> I was wondering if it really is necessary to do all that. It is pretty easy to
> get hands on the log files (.zxu) after uploading them to DiveCloud.
> They are simple text files with all the data readable from notepad. Imo it
> should be pretty easy to implement an import dialog within Subsurface itself.
> However, this is way off my field of expertise.

I guess for most users a direct download is a lot more convenient, than having
to go through another app and cloud service. I don't remember the exact details,
but I believe the zxu export files only contain a very limited amount of
information.

Jef

[Holger Wi]

I am also unable to connect or even recognize the Computer directly within subsurface.

Ofc a direct download would be easiest, but imo the option to import the data in any way would already be a huge blessing. The provided import dialog does only recognize parts of the data and after assigning the correct data types no graph is visible.
The .zxu does however include all the vital information: date, time, dc model & serial & firmware, location (gps and name), rating, dive time, depth and temperature at various times and then some.

I have attached a demo file (only personal info, location and serial number is replaced).

[Gaétan RYCKEBOER]

>> But on windows, the command-line tool can only connect to devices that are already paired. So this is a chicken and egg problem.
>>
>> Is subsurface able to detect the i330R?

No, it doesn’t (using the regular 5.0.10). It sees the devices, even not paired, but not the GDxxxxxx.

/a contrario/ yes, Windows is now able to scan the GDxxxxxx, and request the pin code

—
This machine has no brain.
Use your own.

Gaétan Ryckeboer

[Gaétan RYCKEBOER]

Hi,

> https://libdivecomputer.org/builds/experimental/windows/dctool-ble.exe
>
> and run with these options:
>
> dctool-ble.exe -vv scan -t ble
>
> If the i330R is detected, then everything is ready for the next step.

The tool is downloaded and working, but doesn’t seem to scan anything. Instead, it only displays the BT registered list, and – of course – isn’t able to see the i330r.

[Gaétan RYCKEBOER]

> But on windows, the command-line tool can only connect to devices that are already paired. So this is a chicken and egg problem.
>
> Is subsurface able to detect the i330R?

Dunno, I’ll install it. My devices are usually a MacBook and an iPhone.

Is it possible to snif the ID using the IOS BT session ?

[Jef Driesen]

On 18/08/2023 11:44, 'Gaétan RYCKEBOER' via Subsurface Divelog wrote:
>>> But on windows, the command-line tool can only connect to devices that are already paired. So this is a chicken and egg problem.
>>>
>>> Is subsurface able to detect the i330R?
>
> No, it doesn’t (using the regular 5.0.10). It sees the devices, even not paired, but not the GDxxxxxx.

Have you enabled the "Show all BT devices" checkbox? Without that setting
subsurface will hide bluetooth devices that are not recognized as a dive
computer, and the i330R is of course not recognized yet. Can you try to perform
a scan, and send the two subsurface log files:

https://subsurface.github.io/faq/#where-do-i-find-the-log-files-on-windows

If subsurface is able to see the i33OR, then we should be able to use subsurface
as the host application for testing instead of dctool. That will be less
convenient for me, but not impossible.

> /a contrario/ yes, Windows is now able to scan the GDxxxxxx, and request the pin code

Does the i33OR show the pin? Because if it doesn't then we're still stuck.

Jef

[Holger Wi]

Hey Jef,

sorry for the somewhat late reply. I am not able to find the i330R within Subsurface. Neither BLE nor BT classic shows anything.

The log files are attached with dummy MAC and IP addresses.

Windows does recognize the computer, but it still does not show a pin.

[Nikolai Filchenko]

Small help from my side

i330r is using proprietary pairing method.

Sequence without known access code:

RequestAccess {0xcd ,0x40 ,0xfa ,0xf6 ,0x09 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00}

RequestAccessData {0xcd ,0x80 ,0xfa ,0x92 ,0x10, <16 times 0x00>}

RequestAccessCode {0xcd ,0x40 ,0xfb ,0x8e ,0x09, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}

Now pin is shown on display

SendAccessCode {0xcd ,0x80 ,0xfb ,0x8e ,0x06, <6 bytes pin. Encoding is fancy - every byte contain one digit (not char, just value 0-9)> }

Reply contains 16 byte access code in first packet

HandshakeRw  {0xcd ,0x40 ,0x22 ,0x4a ,0x09, 0, 0, 0, 0, 0x0c, 0, 0, 0, 0}

SendAuthCode {0xcd ,0x40 ,0x97 ,0x12 ,0x09, 0x37, 0x30, 0x31, 0x55, 0x00, 0, 0, 0, 0} This is magic packet with model-dependent constants

Now normal communication should work

Sequence with known access code:

RequestAccess {0xcd ,0x40 ,0xfa ,0xf6 ,0x09 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00}

RequestAccessData {0xcd ,0x80 ,0xfa ,0x92 ,0x10, <16 byte access code>}

HandshakeRw  {0xcd ,0x40 ,0x22 ,0x4a ,0x09, 0, 0, 0, 0, 0x0c, 0, 0, 0, 0}

SendAuthCode {0xcd ,0x40 ,0x97 ,0x12 ,0x09, 0x37, 0x30, 0x31, 0x55, 0x00, 0, 0, 0, 0} This is magic packet with model-dependent constants

Now normal communication should work

[Gaétan RYCKEBOER]

Hi,

is the pincode different at each session? 

I also wonder if the pincode is not available on the DiverLog+ connection screen?

[Nikolai Filchenko]

Pincode is different on every request (it is shown on computer screen). Access code from response to correct pin code could be used for all future sessions (at least from the same device).

[Jef Driesen]

Nikolai,

Your analysis matches with the information we already have. The problem
is getting the implementation tested. One of the problems is that we now
need to ask the user for the PIN code. Currently libdivecomputer has no
mechanism for that (easy to add, I already have a proof of concept
available), but also the host applications (Subsurface, Diving Log, etc)
have no functionality to ask for the PIN (that's also more complicated
to add). I already tried with libdivecomputer's dctool command-line
client instead, but on Windows its BLE implementation requires a paired
bluetooth device, and that's of course not possible with this
proprietary pairing mechanism.

Anyway, in order to move forward with this, I already worked on
preparing a patched (Windows) build of subsurface. Can you (or anyone
else with a I300R) give this a try? You can download the installer here:

https://libdivecomputer.org/builds/experimental/windows/i330r/subsurface-installer.exe

After installation replace the libdivecomputer dll with this one:

https://libdivecomputer.org/builds/experimental/windows/i330r/libdivecomputer-0.dll

Note: I recommend to install in a different directory and not overwrite
your existing subsurface install.

Now the I330R (and also the Apeks DSX) should be available for
selection, and when you try to download the dive computer should show
the PIN code. Try with the "Save libdivecomputer logfile" checkbox
enabled, and send me the log. Also send the two subsurface log files:

https://subsurface.github.io/faq/#where-do-i-find-the-log-files-on-windows

The actual download will still fail, because the build is still missing
a dialog to request the PIN, but that's fine for now.

Note: In the subsurface bluetooth scanning dialog you'll need to enabled
the "Show all BT devices" checkbox. Without that setting subsurface will
hide bluetooth devices that are not recognized as a dive computer, and I
forgot to add the info to make it recognize the i330R.

Next, download this build:

https://libdivecomputer.org/builds/experimental/windows/i330r/subsurface-dialog.exe

Copy it into the same directory where you installed subsurface above and
run it instead of the normal subsurface.exe. This build has a dialog to
request a PIN, but unfortunately the implementation is extremely buggy
and can easily crash the application while the PIN dialog is shown (the
best option to avoid the crash seems to be not moving the mouse and just
type the PIN and hit enter). Again try with the libdivecomputer logging
enabled and send me the log.

PS: The reason for the crash is because the dialog is shown from the
download thread instead of the UI thread and QT (or Windows) doesn't
like that. Sorry, I don't have a more reliable implementation at the
moment. If anyone can help me with that, that would be great.

Jef

[David Piščanec]

Hello.

> Anyway, in order to move forward with this, I already worked on
> preparing a patched (Windows) build of subsurface. Can you (or anyone
> else with a I300R) give this a try? You can download the installer here:
>
> https://libdivecomputer.org/builds/experimental/windows/i330r/subsurface-installer.exe
>
> After installation replace the libdivecomputer dll with this one:
>
> https://libdivecomputer.org/builds/experimental/windows/i330r/libdivecomputer-0.dll
>
> Note: I recommend to install in a different directory and not overwrite
> your existing subsurface install.

Running the executable (With bluetooth logging enabled via QT_LOGGING_RULES) produces:

>  PS C:\Subsurface> $env:QT_LOGGING_RULES = "qt.bluetooth.*=true"
>  PS C:\Subsurface> .\subsurface.exe
>  QObject::connect(QQuickWindow, QDeclarativeGeoMap_QML_6): invalid nullptr parameter
>  Found device:  "Redmi A2" "24:D3:37:61:56:1D"

During the "Show all BT devices" scan, I turned on my smartphone (Redmi A2), and the i330R.

Bluetooth scanning is being performed, as the phone shows up. However, the i330R does not.

The "Found device: ..." message originates from the QtConnectivity library used by subsurface to discover bluetooth devices:

> https://github.com/qt/qtconnectivity/blob/5.15/src/bluetooth/qbluetoothdevicediscoveryagent_win.cpp#L540C9-L540C9

> qtconnectivity version v5.15.0:
> src\bluetooth\qbluetoothdevicediscoveryagent_win.cpp:540:
> qCDebug(QT_BT_WINDOWS) << "Found device: " << foundDevice.name() << foundDevice.address();

qbluetoothdevicediscoveryagent_win.cpp is using legacy windows API, such as the BluetoothFindFirstDevice function.

This API will  not work with Bluetooth Low Energy devices. The i330R is a Bluetooth Low Energy device and thus

will not be discovered.

> https://learn.microsoft.com/en-us/windows/win32/api/bluetoothapis/nf-bluetoothapis-bluetoothfindfirstdevice#remarks

> The BluetoothFindFirstDevice function does not find Bluetooth Low Energy (LE) devices.

> To access Bluetooth LE devices, use the Windows Runtime Bluetooth Low Energy APIs.

> The Windows Runtime APIs for Bluetooth work in both UWP and classic desktop apps.

QtConnectivity does include such a "Windows Runtime API" implementation.

It is specifically not selected by the subsurface windows-building Docker image (mxe-build-container):

> https://github.com/subsurface/subsurface/commit/e71e715cd347d3dc1e503695d7a747f175123e9e

> # Patch the qtconnectivity build to explicilty enable native-win32-bluetooth and ensure another
> # backend is not picked
> ADD qtconnectivity-1.patch /win/mxe/src/qtconnectivity-1.patch

The content of qtconnectivity-1.patch shows it enabling the 'native-win32-bluetooth' feature in configure.json:

> PS C:\Subsurface> docker run -v C:/subsurface:/__w subsurface/mxe-build-container:2.2 /bin/bash -c "cat win/mxe/src/qtconnectivity-1.patch"
> diff --git a/src/bluetooth/configure.json b/src/bluetooth/configure.json
> index 3bd95903..0d41d88f 100644
> --- a/src/bluetooth/configure.json
> +++ b/src/bluetooth/configure.json
> @@ -63,6 +63,7 @@
>  "purpose": "Uses the native Win32 Bluetooth backend.",
>  "section": "Qt Bluetooth",
>  "autoDetect": false,
> +            "enable": true,
>  "output": [ "publicFeature", "feature" ]
>  },
>  "winrt_bt": {

(Further, communication with the i330R is performed from an unpaired state.

https://www.youtube.com/watch?v=FY4YMsxjdK0  is a presentation from the Windows core bluetooth team

on unpaired device connectivity. Unpaired connectivity is introduced by the Windows creators update (Windows 10 version 1703).

Supporting the i330R on windows requires a recent enough version of windows)

A Docker container is used to produce subsurface binaries for windows (MXE Docker container, mxe-build-container).

Quoting a commit message:

> https://github.com/subsurface/subsurface/commit/e71e715cd347d3dc1e503695d7a747f175123e9e

> We previously tried to build the MXE Docker container on GitHub using > an Action, but that really didn't work well and was a lot more trouble > than it was worth. > So this goes back to an offline build mechanism where I simply create > an updated Docker image when needed and push that to Docker Hub.

> dirkhh committed on Oct 30, 2020 

Summary:

BLE devices can not be discovered on builds performed by subsurfaces 'official' mxe-build-container Docker container.

The QtConnectivity library included inside the Docker container is patched _against_ using an implementation based on

the newer, required, Windows Runtime API for Bluetooth.

If committer dirkhh is still active, creating a Docker image, with QtConnectivity patch instead enabling the 'winrt_bt' and 'winrt_btle_no_pairing' features in configure.json,

would be extremely useful for testing.

[Nikolai Filchenko]

If there is branch/tag I could try build and check on win 11. 

Qt6 opensource from official installer does not have any issue detecting and communicationg with i330r

[Jef Driesen]

On 2023-10-17 14:53, David Piščanec wrote:
> qbluetoothdevicediscoveryagent_win.cpp is using legacy windows API,
> such as the BluetoothFindFirstDevice function.
> This API will not work with Bluetooth Low Energy devices. The i330R is
> a Bluetooth Low Energy device and thus
> will not be discovered.

The Qt implementation does also support BLE devices. See the code here:

https://github.com/qt/qtconnectivity/blob/5.15/src/bluetooth/qbluetoothdevicediscoveryagent_win.cpp#L188

But the limitation is that this win32 (SetupAPI) based implementation
only supports the "discovery" of devices that have already been paired
with the Windows tools. It's actually not a real bluetooth discovery,
but just enumerating the information that is already present in the
windows device database.

This is the same limitation as my BLE implementation used in the
libdivecomputer dctool command-line client because it's using the same
SetupAPI api.

For the I330R this limitation is problematic because its proprietary
pairing mechanism prevents the pairing with the standard Windows tools.
For other BLE dive computers this limitation is usually not a problem,
just a bit less convenient.

> [...]

>
> Summary:
> BLE devices can not be discovered on builds performed by subsurfaces
> 'official' mxe-build-container Docker container.
> The QtConnectivity library included inside the Docker container is
> patched _against_ using an implementation based on
> the newer, required, Windows Runtime API for Bluetooth.

Nice detective work! I wasn't aware of this. I also have no idea why
support for the winrt backend is disabled.

@Dirk: Do you remember why this was disabled?

> If committer dirkhh is still active, creating a Docker image, with
> QtConnectivity patch instead enabling the 'winrt_bt' and
> 'winrt_btle_no_pairing' features in configure.json,
> would be extremely useful for testing.

I'll try to create a build with the winrt backend enabled.

Jef

[Jef Driesen]

On 2023-10-17 16:39, Nikolai Filchenko wrote:
> If there is branch/tag I could try build and check on win 11.
> Qt6 opensource from official installer does not have any issue
> detecting and communicationg with i330r

I build the subsurface binary from the "auth" branch in my fork:

https://github.com/jefdriesen/subsurface/tree/auth

Jef

[David Piščanec]

Hello.

> I build the subsurface binary from the "auth" branch in my fork:
>
> https://github.com/jefdriesen/subsurface/tree/auth

I believe the general approach of having libdivecomputer 'request' authentication data from the user via callback will work.

But I disagree with the implementation.

You store the callback data (dc_auth_callback_t function and a void pointer) inside dc_device_t .

Libdevicecomputer allocates devices (dc_device_t structures) very late, and deep, inside the codepath.

In the relevant case, for i330R, this will happen inside libdivecomputer/src/oceanic_atom2.c::oceanic_atom2_device_open ,

by a call to dc_device_allocate. The very same function will later start the handshake via oceanic_atom2_ble_handshake.

Authentication needs to be available for the handshake. We need to register the authentication before the handshake starts.

Thus I recommend to instead store the callback data inside the dc_context_t structure.

dc_context_t is already used to register a logging callback - it can also fit our authentication callback.

Essentially, in the following callgraph, it is easier to register our callback inside do_libdivecomputer_import, between the calls to dc_context_new and dc_device_open,

than to register our callback inside oceanic_atom2_device_open between the calls to dc_device_allocate and oceanic_atom2_ble_handshake.

subsurface             : DownloadThread::run

subsurface             :         do_libdivecomputer_import

libdevicecomputer:                 dc_context_new

libdevicecomputer:                 dc_device_open

libdevicecomputer:                         oceanic_atom2_device_open

libdevicecomputer:                                 dc_device_allocate

libdevicecomputer:                                 oceanic_atom2_ble_handshake

For a proof-of-concept implementation, please see my auth_dialog_squashed branches of subsurface and libdc:

https://github.com/nOOb3167/subsurface/tree/auth_dialog_squashed

https://github.com/nOOb3167/libdc/commits/auth_dialog_squashed

> PS: The reason for the crash is because the dialog is shown from the
> download thread instead of the UI thread and QT (or Windows) doesn't
> like that. Sorry, I don't have a more reliable implementation at the
> moment. If anyone can help me with that, that would be great.

The branches linked above use a Qt synchronization API (QMetaObject::invokeMethod) to pass execution to the UI thread.

I am not a Qt expert, but this should have solved the reliability issue.

[Jef Driesen]

On 19/10/2023 19:31, David Piščanec wrote:
>> I build the subsurface binary from the "auth" branch in my fork:
>>
>> https://github.com/jefdriesen/subsurface/tree/auth
>
> I believe the general approach of having libdivecomputer 'request'
> authentication data from the user via callback will work.
> But I disagree with the implementation.

This is just a quick proof-of-concept I put together to get the i33OR code
tested, and not a proposal for the final api. For example it only deals with the
pin code, but we'll also need some api to store and retrieve the access code,
such that we don't have to re-do the pairing every time.

> You store the callback data (dc_auth_callback_t function and a void pointer)
> inside dc_device_t .
> Libdevicecomputer allocates devices (dc_device_t structures) very late, and
> deep, inside the codepath.
> In the relevant case, for i330R, this will happen inside
> libdivecomputer/src/oceanic_atom2.c::oceanic_atom2_device_open ,
> by a call to dc_device_allocate. The very same function will later start the
> handshake via oceanic_atom2_ble_handshake.
> Authentication needs to be available for the handshake. We need to register the
> authentication before the handshake starts.
>
> Thus I recommend to instead store the callback data inside the dc_context_t
> structure.
> dc_context_t is already used to register a logging callback - it can also fit
> our authentication callback.

I understand your concerns about the problems associating the auth callback with
the dc_device_t handle, but I don't think moving them to the dc_context_t is the
right solution. The pairing mechanism is something that is bound to the device
(e.g. a user can have more than one i330R and thus the application will need to
be able to store more than one access code and associate it with the correct
device), and not the global library context.

Instead of doing the pairing directly in the xxx_device_open() function, it can
be done lazily when calling the xxx_device_{foreach,dump,...) functions. Like we
already do for example in the HW OSTC3 backend with the hw_ostc3_device_init()
functions.

Anyway, the idea that I had in mind was to integrate this functionality in the
I/O stream code. There, we already have an ioctl interface which is used for
retrieving the bluetooth device name (DC_IOCTL_BLE_GET_NAME). This features is
already present to support another proprietary authentication mechanism in some
other Pelagic dive computers. We could easily extend this with a
DC_IOCTL_BLE_GET_PIN and DC_IOCTL_BLE_{GET,SET}_ACCESSCODE, or something along
that line.

> https://github.com/nOOb3167/subsurface/tree/auth_dialog_squashed
> https://github.com/nOOb3167/libdc/commits/auth_dialog_squashed
>
>> PS: The reason for the crash is because the dialog is shown from the
>> download thread instead of the UI thread and QT (or Windows) doesn't
>> like that. Sorry, I don't have a more reliable implementation at the
>> moment. If anyone can help me with that, that would be great.
>
> The branches linked above use a Qt synchronization API
> (QMetaObject::invokeMethod) to pass execution to the UI thread.
> I am not a Qt expert, but this should have solved the reliability issue.

Thanks, this seems to work! I've updated the binaries with your changes (after
reverting the libdivecomputer api changes to maintain compatibility with my
libdivecomputer dll).

I still need to build a new mxe container with the winrt backend enabled. Simply
removing the patch doesn't seem to make a difference.

Jef

[Jef Driesen]

On 18/10/2023 09:25, Jef Driesen wrote:
>> If committer dirkhh is still active, creating a Docker image, with
>> QtConnectivity patch instead enabling the 'winrt_bt' and
>> 'winrt_btle_no_pairing' features in configure.json,
>> would be extremely useful for testing.
>
> I'll try to create a build with the winrt backend enabled.

So far I didn't had much success.

First of all, manually building the docker container requires this commit from
the mxeGcc10 branch:

https://github.com/subsurface/subsurface/commit/551f10591ab1c78e44d9d6f5a37aa7e64acdfab7

For some reason this was never merged, but without it the version of gcc in the
container will be too old to be able to compile subsurface.


Next, when trying to enable the winrt bluetooth backend, building the container
fails because the qtconnectivity configuration checks fail:

Running configuration tests...
Checking for BlueZ... no
Checking for WinRT Bluetooth API... no
Done running configuration tests.

Configure summary:

Qt Bluetooth:
BlueZ .................................. no
BlueZ Low Energy ....................... no
Linux Crypto API ....................... no
Native Win32 Bluetooth ................. no
WinRT Bluetooth API (desktop & UWP) .... no
WinRT advanced bluetooth low energy API (desktop & UWP) . no

ERROR: Feature 'winrt_bt' was enabled, but the pre-condition 'config.win32 &&
!features.native-win32-bluetooth && tests.winrt_bt' failed.

ERROR: Feature 'winrt_btle_no_pairing' was enabled, but the pre-condition
'config.win32 && features.winrt_bt && tests.winrt_btle_no_pairing' failed.

I guess some Windows SDK is needed for compiling this WinRT code?

https://github.com/qt/qtconnectivity/blob/5.15/config.tests/winrt_bt/main.cpp

So unless someone knows how to get this working, it looks like support for the
i330r and DSX won't be available very soon, at least not in the Windows build.

PS: Support for the i330r and DSX in libdivecomputer itself is progressing well.
We already have a working test version with another Windows application (Diving
Log). If anyone wants to help testing there, just let me know. This may not
immediately help subsurface users, but at least it will make sure those devices
are supported by the time someone figures out how to fix the above subsurface
build problems.

Jef

[David Piščanec]

To consume Windows system APIs, historically all you needed to know is eg:

FindFirstFileA is located inside Kernel32.dll, and is a function returning HANDLE,

taking arguments of type LPCSTR and a LPWIN32_FIND_DATAA.

So mingw provided you a header with the function declaration, you linked the dll, and you were set.

Unfortunately that just wasn't object oriented enough.

Therefore Microsoft decided all new Window APIs will be implemented in the number one

most hated technology on the planet, COM:

https://learn.microsoft.com/en-us/windows/win32/com/the-component-object-model

They call the thing Windows RT / WinRT, and to avoid causing general panic and despair,

take some efforts to hide and abstract the underlying COM programming away.

The WinRT APIs are declared inside metadata (.idl and .winmm) files. The files contain declarations, for example:

>        [contract(Windows.Foundation.FoundationContract, 1.0)]
>        [uuid(5A648006-843A-4DA9-865B-9D26E5DFAD7B)]
>        interface IAsyncAction : IInspectable
>        {
>            [propput] HRESULT Completed([in] Windows.Foundation.AsyncActionCompletedHandler* handler);
>            [propget] HRESULT Completed([out] [retval] Windows.Foundation.AsyncActionCompletedHandler** handler);
>            HRESULT GetResults();
>        }

These declarations describe COM objects.

Each programming language supported by WinRT parses these files, and generates code to access these COM objects.

For the C++ language, Microsoft produces two parsings of these WinRT API metadata files:

The Windows Runtime C++ Template Library / WRL:

https://learn.microsoft.com/en-us/cpp/cppcx/wrl/windows-runtime-cpp-template-library-wrl

Consuming WRL requires use Visual Studio / the MSVC compiler, the headers use nonstandard microsoft c++ extensions. We can thus ignore it.

AND

C++/WinRT:

https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/

Consuming C++/WinRT is possible with any compiler implementing a new enough language standard (c++ 17 and later).

This is however, true only in theory, as msvc-isms creeped in:

https://github.com/microsoft/cppwinrt/issues/1037

The Qt library (QtConnectivity specifically) is capable of providing Bluetooth support through several backends.

The WinRT backend is required for unpaired device connectivity (ie the aqualung I330R).

This backend is implemented using C++/WinRT.

As long as the issue linked above (https://github.com/microsoft/cppwinrt/issues/1037) is not resolved,

this WinRT QtConnectivity backend can not be built using mingw.

On 30/10/2023 09:25, Jef Driesen wrote:

> I guess some Windows SDK is needed for compiling this WinRT code?

Yes, that would be C++/WinRT.

It is possible to drop down a level, and consume WinRT APIs by programming against the COM object layer.

I have implemented a proof of concept:

https://github.com/nOOb3167/WinRt0/tree/test

I've got this command line program compiling on MinGW and MSVC.

It achieves a message exchange with the unpaired I330R device.

I believe this implementation approach is viable, and it should be possible to cleanup and integrate such code into subsurface.

On 30/10/2023 09:25, Jef Driesen wrote:

> First of all, manually building the docker container requires this commit from

> the mxeGcc10 branch

I build the docker container with gcc13, but of course it does not resolve the underlying WinRT problem ...

https://github.com/nOOb3167/mingwdockerimage

> /win/mxe/usr/bin/x86_64-w64-mingw32.shared-g++ --version

>   x86_64-w64-mingw32.shared-g++ (GCC) 13.2.0

Summary:

As long as subsurface is willing to suffer programming against COM objects, windows support is possible..

[Dirk Hohndel]

I think one of the challenges is that the maintainer of the Windows port of Subsurface has left the project a few years ago and no one has stepped back up who truly understands Windows. The all of the active developers are on Linux or macOS and many don't even have access to a Windows system.

In other words, I think pull requests that help implement this (and help update the infrastructure where needed) would be very welcome.

/D

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/ed6fc176-bab4-4666-ba05-84886d5022b4n%40googlegroups.com.

[Moritz Barz]

Chipping in on the test version with Diving Log, always happy to give that a try and report back on any test. We already had some conversation and tests in the past over e-mail.

[Holger Wi]

I gave Diving Log 6.0 a try as well. It is possible to import the .zxu files (via Dan D7 importer), however basically all information but the depth profile is missing. And for the profile to be displayed correctly you'd have to set the interval seperately for each dive.

Import via the Diver Log Import dialogue retains all that information, but it requires the whole logbook to be imported, which is a .db3 (HEX) file. This filetype can only be created within the Diver Log Windows app which lacks an import/sync function in the free version.
Subsequently, it is not possibe to export your dives with free software for the time being. At least to my knowledge and hours of research and testing.

[Gaétan RYCKEBOER]

The combination Diving Log / Diverlog works pretty well with the i330R, but you have to export UDCF, not DAN DL7.

What is interesting here, is that the libdiverlog works well and is able to fully associate the i330R on windows platform. It requests setting a Pincode displayed on the computer at the time of the association.

I wish I would give it a try on macos, but with which software?