Re: Bluetooth blues
> I was under the impression that the Petrel 2 and the Uemis were your test > devices when coding the Bluetooth interface and that access to the Petrel 2 > has more or less been sorted out?? Am I mistaken? I have only two devices: OSTCs and OSTC 2. Rick helped me to test the connectivity with a Petrel 2 device. > Do you know whether the Petrel 2 definitely needs a pin number? I have no idea. You can test it using the bluetoothctl tool. Here is an example: $ bluetoothctl [bluetooth]# agent KeyboardOnly Agent registered [bluetooth]# default-agent Default agent request successful [bluetooth]# pair 00:13:43:0D:21:0D Attempting to pair with 00:13:43:0D:21:0D [CHG] Device 00:13:43:0D:21:0D Connected: yes Request PIN code [agent] Enter PIN code: If it doesn't need a PIN code, then the last part will be missing. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Bluetooth blues
Unfortunately the API doesn't allow you to specify a PIN code. There is a bug [1] reported and also a partial implementation for an agent[2] which could be used to pass the PIN code, [1] - https://bugreports.qt.io/browse/QTBUG-42740 [2] - https://codereview.qt-project.org/#/c/85595/ On Fri, Oct 23, 2015 at 2:50 PM, Anton Lundin <gla...@acc.umu.se> wrote: > I took a look at qt parring interfaces, shouldn't there be a way to test a > couple of standard parring codes? > > //Anton > > On October 23, 2015 12:02:19 PM GMT+02:00, Claudiu Olteanu > <olteanu.vasilica.clau...@gmail.com> wrote: >>Hi there, >> >>If your remote device requests a custom PIN code for the pairing >>process, your should pair the devices using a different tool. >>Currently QtBluetooth doesn't have support for custom PIN codes. >> >>A workaround could be to use bluetoothctl, register an agent using the >>following commands, initiate the pairing process using our application >>and enter the pin code when it is requested: >> >>[bluetooth]# agent KeyboardOnly >>[bluetooth]# default-agent >> >>Claudiu >>___ >>subsurface mailing list >>subsurface@subsurface-divelog.org >>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Bluetooth blues
Hi there, If your remote device requests a custom PIN code for the pairing process, your should pair the devices using a different tool. Currently QtBluetooth doesn't have support for custom PIN codes. A workaround could be to use bluetoothctl, register an agent using the following commands, initiate the pairing process using our application and enter the pin code when it is requested: [bluetooth]# agent KeyboardOnly [bluetooth]# default-agent Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: ostc BT download failure
Please try to unpair - pair the devices and then repeat the steps. There are moments when the device gets stuck and doesn't work properly. If this doesn't work try to get some logs using the hcidump tool. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: ostc BT download failure
It should work with qt 5.4.1 too. From your logs it seems that the devices exchanged some data but there was something wrong with the communication protocol. If there is something wrong with your qt version I believe that it would fail on the connection step. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH 2/2] qtserialbluetooth: use QIODevice::Unbuffered io
Hi there, I just tested the patches and all seems good. Thanks for making time to resolve this issue. I managed to update the firmware on my OSTC Sport device using our BTH implementation (from 10.18 to 10.20). I also have an OSTC 2 device with an old firmware (1.81) but it doesn't detect that there is an update for it (even though the latest version is 1.88). Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: ostc BT download failure
Hi, Anton is right. It seems that after it sends a command to the device, the received response is not a valid one (your device doesn't recognize the command sent). Therefore it could be a problem with the version of your firmware. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Bluetooth issue on Mac
Hello, Unfortunately I have no idea why it cannot find QBluetoothServiceInfo meta type at run time. I looked over the qtconnectivity implementation for OS X platforms and over our sources but I couldn't see anything obvious. Maybe Thiago has a better idea. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: User manual: Bluetooth UI description
Hi there, Steve is right. You should keep the documentation for the old native implementation because it still works. Also there are some misleading information. On Windows platforms the pairing status is done automatically on the connection step, while on the other platforms it should be done manually by the user. When you right click on a discovered item a context menu will popup and you will have an option for pairing. Also there are other things that should be mentioned: on Windows, the implementation works only with adaptors which support Microsoft Bluetooth stack (not BlueSoleil, WinCOMM). But don't worry, I will update tonight the user manual and I will send it to you for a review. Have a nice day, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Fix Bluetooth address truncation
Hi there, There was an issue reported by Steve regarding the Bluetooth address on Windows 10 platforms. The first patch should fix the problem. Claudiu 0001-Fix-Bluetooth-address-truncation-issues-on-Windows.patch Description: Binary data 0002-Rename-BTH_ADDR_STR_LEN-macro.patch Description: Binary data ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Bluetooth Issues and Fixes
Hi there, Sorry for the late response. Unfortunately today I am a little busy but I will try this weekend to reproduce your problem and to find a solution. > General notes and questions: > > I potentially may have caused the issue with the native Bluetooth by trying > to trouble-shoot the Windows SPP outgoing com port issues noted above? I don't have too much experience on Windows 10 but I will try see if the old native Bth implementation works on my environment. My focus was on our custom implementation and I didn't have the chance to test the old one. > Running Bluetooth log view software I can see the correct mac address of the > dive computer shown when it comes into range of the laptop. I will do some investigation and I hope that I will find out why the Bluetooth address is not converted correctly. > > When doing the scan, where is it getting the mac address for the devices > from and/or storing it? The Bluetooth address is stored in a QBluetoothDeviceInfo object and saved as user data to QListWidgetItem items. > What is the button with the ellipse next to ellipsis (3 dots) next to the > device or mount point drop-box supposed to do? I believe that it does a search for a Uemis dive computer or something like that. Cheers, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Bluetooth interface questions and a UI suggestion
Hi there > I have a question about the Bluetooth download interface. > > When selecting import -> Import from dive computer, there are two > possibilities: > > 1) In the MountPoint textbox of the Download panel, the address of the > Bluetooth device is shown. It looks like this happens automatically when > selecting Shearwater and Petrel from the list of supported DCs. Then one > needs to check the checkbox marked "Choose Bluetooth" and hit the > Download button to start downloading. The Bth address appears because it was cached during your last download attempt. Since commit 9e97f124c it should also cache the value of your checkbox (hopefully :-) ) . If you select a new family device it will disappear. > 2) When selecting the "Choose Bluetooth" check box, a new panel opens > with the full details of the Bluetooth interface, allowing activation of > local Bluetooth and scanning for remote Bluetooth devices. > > What determines which of these two routes of action is taken? I suspect > it is determined, amongst others, by the state of the local Bluetooth > interface. If it is switched on, then the Bluetooth address is shown in > the MountPoint text box. is this correct? In the MountPoint text it is shown the name of your dive computer which was selected and saved in the BTH selection dialogue. If you attempt to do a download the Bth address of your remote device will be cached and shown on your next session. That address it is not the same as the one your local Bth device has. The information you saw in the new panel is related with your local Bth device and its state. > Here is a suggestion: In the dropdown list of mount points, add a > Bluetooth item. If the Bluetooth item is selected from this dropdown > box, it switches on the local Bluetooth device and opens the Bluetooth > panel referred to in 2) above. This allows one to do away with the > checkbox "Choose Bleutooth". I like your suggestion. The only problem is that it is not necessary to open the Bluetooth selection dialogue to initiate a download. If you want to use the same device as the last time and your Bluetooth adapter is ON you should be able to successfully download the information. Now this is done by caching the value of the "Choose Bluetooth" checkbox. Therefore if we want to remove the checkbox, we should should cover this scenario too. Cheers, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Exit with failure if dc_open method fails
If the dc_serial_*_open method fails then we should exit with
an error and don't try to open the device using the native
implementation.
Currently if the local Bluetooth adapter doesn't connect successfully
to a dive computer it tries to open the device using the native serial
implementation (libdivecomputer.c: 944 - serial == NULL).
I am not sure how it should work for the serial FTDI implementation if
it fails. Should it try to open the device again using the old native
serial
implementation? Anton?
Cheers,
Claudiu
From d6a9615d61ac7699001491ad8a599f6a4c7dd3af Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu <olteanu.clau...@ymail.com>
Date: Wed, 9 Sep 2015 19:39:12 +0300
Subject: [PATCH] Exit with failure if the first dc_open method fails
If the dc_serial_*_open method fails then we should exit with
an error and don't try to open the device using the native
implementation.
Signed-off-by: Claudiu Olteanu <olteanu.clau...@ymail.com>
---
libdivecomputer.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libdivecomputer.c b/libdivecomputer.c
index 3e4cfad..3c69900 100644
--- a/libdivecomputer.c
+++ b/libdivecomputer.c
@@ -941,13 +941,10 @@ const char *do_libdivecomputer_import(device_data_t *data)
#endif
}
- if (serial_device) {
- if (rc == DC_STATUS_SUCCESS) {
- rc = dc_device_custom_open(>device, data->context, data->descriptor, serial_device);
- } else {
- report_error(errmsg(rc));
- }
-
+ if (rc != DC_STATUS_SUCCESS) {
+ report_error(errmsg(rc));
+ } else if (serial_device) {
+ rc = dc_device_custom_open(>device, data->context, data->descriptor, serial_device);
} else {
#else
{
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[Bluetooth support] Macros
Hi there,
I believe that it is a little confusing that in order to compile and
to make work the Bluetooth support, two different macros
should be defined (BTSUPPORT and SSRF_CUSTOM_SERIAL).
Even thought the first one is defined, the implementation will not
work without the second one. Therefore I believe that it is a good
idea to disable the Bluetooth option from GUI if SSRF_CUSTOM_SERIAL
is not defined. I attached a patch which will do the trick.
Another solution would be to disable the BTSUPPORT option from cmake
if SSRF_CUSTOM_SERIAL is not defined. Unfortunately I don't
have too much experience with cmake and I don't know how to do that.
Claudiu
From 87c860fa35109c0b03ee9dabc102d1667fd33195 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu <olteanu.clau...@ymail.com>
Date: Tue, 8 Sep 2015 19:29:36 +0300
Subject: [PATCH] Disable Bth option from GUI if the SSRF_CUSTOM_SERIAL is
undefined
The Bluetooth implementation doesn't work is SSRF_CUSTOM_SERIAL
is undefined. Therefore it is a good idea to remove it from
the UI if the libdivecomputer version is wrong.
Signed-off-by: Claudiu Olteanu <olteanu.clau...@ymail.com>
---
qt-ui/downloadfromdivecomputer.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qt-ui/downloadfromdivecomputer.cpp b/qt-ui/downloadfromdivecomputer.cpp
index f2378d5..71761bf 100644
--- a/qt-ui/downloadfromdivecomputer.cpp
+++ b/qt-ui/downloadfromdivecomputer.cpp
@@ -100,7 +100,7 @@ DownloadFromDCWidget::DownloadFromDCWidget(QWidget *parent, Qt::WindowFlags f) :
ui.downloadCancelRetryButton->setEnabled(true);
ui.downloadCancelRetryButton->setText(tr("Download"));
-#if defined(BT_SUPPORT)
+#if defined(BT_SUPPORT) && defined(SSRF_CUSTOM_SERIAL)
ui.bluetoothMode->setText(tr("Choose Bluetooth download mode"));
ui.bluetoothMode->setChecked(default_dive_computer_download_mode == DC_TRANSPORT_BLUETOOTH);
btDeviceSelectionDialog = 0;
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Bluetooth download - segfault when Choose Bluetooth download mode isn't selected
> > Thanks for the quick response Claudiu. I'll test this tonight my time. > Just out of curiosity, could you reproduce/test it by selecting Shearwater, > Petrel, and any MAC address? I think the crash happened before it > connected with my dive computer. > I don't know why I didn't think about that :-). Yes, I can reproduce the bug if I select the Shearwater, Petrel and a dumb MAC address. I also tested with the patch applied and the application doesn't crash anymore. Btw, the native Bluetooth is great and I'm impressed by how way it works. > I'm deliberately trying to find ways to make it do the wrong thing. > Thanks. I am glad that it resists to the dark side attacks :). There are some scenarios that I forgot to test but I am not sure if they will affect the flow: - use the "Force download of all dives" option - save the libdivecomputer dump/log file I will run some tests tonight. Have a nice day, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Bluetooth download - segfault when Choose Bluetooth download mode isn't selected
> Interesting. > Claudiu, is this something you can look into? Yes, sure. I will start looking over it tonight when I will get home. > It seems to me we either shouldn't keep those settings or we need to make > sure that if we have these settings things are correctly set up... > > If I select 'Choose Bluetooth download mode', run a Bluetooth scan, and > > select my dive computer, everything works as it should. > > So the easiest solution would be to just not remember these - but can we > redo the steps automatically to make this even easier for the user? Another solution could be to save user's option about using our Bluetooth implementation (to cache the value of the flag/checkbox). I suspect that the reason why the application crashed is because the bluetoothMode flag was false and when the device was oppened it didn't use our custom dc_device_custom_open method. It is not necessary to use the Bluetooth selection dialogue before downloading if the BTH address wad cached. As I said, I will do some investigation when I will get back home. Cheers, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Issue using QT Bt functionality on Fedora
Hi there, In order to use our custom Bluetooth implementation you should define SSRF_CUSTOM_SERIAL variable. By default the project is compiled without Bluetooth support and uses the native serial communication from libdivecomputer. I know that it is confusing because the "Bluetooth download mode" option is still available in the UI. I will send a patch to remove the option when the SSRF_CUSTOM_SERIAL flag is not set. Regards, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Add translation for Bluetooth download mode
Hi there, This patch should translate the strings used for the implementation of Bluetooth support. I am not sure if I should also update the .ts files. Claudiu 0001-Translate-strings-for-Bluetooth-download-mode.patch Description: Binary data ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: at some point we need to release Subsurface 4.5
Oh :). I thought about it but I don't know why I forgot to ask you. So it is also my mistake. Let me know if it works or if you encounter other problems. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: at some point we need to release Subsurface 4.5
OK, deleting the plist file, shutting the system down and restarting worked. BT is alive and well again. Here's what Subsurface reports: The local Bluetooth adapter cannot be accessed. So this indicated that in BtDeviceSelectionDialog::updateLocalDeviceInformation() localDevice-isValid() returns false... So QtBT isn't finding any devices. Any suggestions how to debug that? /D Unfortunately I don't have any idea how Bluetooth works on OSx. I encountered the same problem on Linux when the libqt5-qtconnectivity library was missing or when the BlueZ driver wasn't installed correctly. The Qt framework couldn't communicate with the driver via D-Bus and localDevice-isValid() was always returning FALSE. Maybe Thiago has any suggestions or we could start talking with Alex, the maintainer of QtBluetooth module. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: at some point we need to release Subsurface 4.5
Bluetooth support = BT support is looking fairly good on Linux and making progress on Windows, I think, but I'm sure there are tons of small issues lurking here and there. Has anyone gotten it to work on Mac, yet? Also ready for Beta 1, except for OS X where it also doesn't appear to work at all :-( Can you be more specific? Is your local Bluetooth adapter recognized? Did you receive some specific errors? ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Add native Bluetooth support for Windows platforms
Sorry for the late response but I didn't have access to Internet for the last three days. Thiago, thanks again for the review. I saw that the patches are now in the upstream. Dirk, if you think that it is necessary I can send you another patch using the WSAStringToAddressW (like Thiago suggested), or forcing the cast from const char* to char * (like Lubomir suggested) and continue to use the WSAStringAddressA function. Have a nice day, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATH] Add native Bluetooth support for Windows platforms
Hi Thiago,
Thanks for making time to look over the patches!
Subject: [PATCH 03/17] Use only the BTH address to check if the device was
already added
There are moments when the name of the device cannot be obtained.
Therefore we should use only the Bluetooth address to identify if
the discovered device was already added to the list.
- QListQListWidgetItem * itemsWithSameSignature =
ui-discoveredDevicesList-findItems(deviceLabel, Qt::MatchStartsWith);
+ QListQListWidgetItem * itemsWithSameSignature =
ui-discoveredDevicesList-findItems(remoteDeviceInfo.address().toString(),
Qt::MatchContains);
This is a little confusing. I understand that the device is added to the
list
first as a MAC address only and then replaced by the label. But I'm not
sure if
the fix is correct... where is the corresponding addition to the list in
the
first place? How can we be sure that the change to a label hasn't happened?
Sorry for the confusion but after some discussions with Dirk I removed that
commit.
All the new patches were included in my latest e-mail from this thread.
Also you can
find them in this branch [1].
The only difference is that patch number 3 was replaced with this one [2]
and
I added a new one [3].
Now I clear the list with the discovered devices when a new device lookup
is
initiated.
Subject: [PATCH 05/17] Add skeleton for Bluetooth custom serial
implementation
on Windows platforms
This patch, by itself, doesn't do anything, except:
BtDeviceSelectionDialog::~BtDeviceSelectionDialog()
{
delete ui;
+#if defined(Q_OS_WIN)
+ // Terminate the use of Winsock 2 DLL
+ WSACleanup();
+#else
This will mess up the winsock DLL internal refcounting, so it could
accidentally shut down all sockets in Subsurface... I know the matching
WSAStartup is in patch 12, but this means that patches 5 through 11 are not
testable as they (potentially) break Winsock2. I'm not talking about
testing
the Bluetooth code (the initializeDiscoveryAgent code isn't added until
patch
17). This is about the whole Subsurface. The WSACleanup bit should be
moved to
patch 12.
Ok, I will move the WSACleanup call in the same patch where WSAStartup is
used.
Please initialise the stopped and running variables. In patch 11, when you
actually use them, the stopped variable is used uninitialised, in:
while (result == SUCCESS !stopped){
As for the running variable, the isActive function may race against the
initialisation, so please initialise it too.
I had that in mind but I totally forgot :). I will do the initialization.
Subject: [PATCH 06/17] Add implementation for BTH custom serial open
method
on
Windows platforms
@@ -51,7 +51,49 @@ static int qt_serial_open(serial_t **out, dc_context_t
*context, const char* dev
+ char *address = strdup(devaddr);
There doesn't seem to be any need for strdup here.
Yes, you are right.
Subject: [PATCH 10/17] Add internal method which returns a pretty message
about the last error on Windows
Hint: you could have used qt_error_string(). That does exactly what you
did in
your code.
Thanks for the hint! I will remove the internal function and use the one
you
suggested.
Subject: [PATCH 11/17] Add implementation for our custom BTH device
discovery
service
+ WSAQUERYSET *pResults = (WSAQUERYSET*)buffer;
[...]
+ if (WSAAddressToStringA((LPSOCKADDR)
socketBthAddress,
[...]
+ QString deviceName =
QString(pResults-lpszServiceInstanceName);
+ QString deviceAddress = QString(addressAsString);
I'm not going to hold you to this, so this is just learning for next time.
It's usually a good idea to use the W functions on Windows instead of the A
ones. First of all, they are faster, since they are the real native
functions
-- the A functions need to convert from wchar_t to char back and forth.
Not to
mention that this conversion is lossy, so the A functions cannot represent
all
possibilities.
Second, they are supported on Windows CE, whereas the A functions aren't.
Not
really important to us, but it gets you in the right habit.
And third, you would avoid an UTF-8 decode in those two QString creations
--
instead, you could have used QString::fromWCharArray or QString::fromUtf16,
which are simple memcpy. Or, in the case of addressAsString, you could have
used QString itself as your buffer:
QString deviceAddress(BTH_ADDR_STR_LEN, Qt::Uninitialized);
if (WSAAddressToString(
reinterpret_castwchar_t*(deviceAddress.data()),
...
deviceAddress.truncate(addressSize);
Thank you for your detailed explanation! I didn't know about the difference
between the W functions on Windows instead of the A ones.
Since I will create a new set of patches I will try to add all the things
you
suggested.
Please
[PATCH] Add native Bluetooth support for Windows platforms
Hi there,
As I promised, I created a new set of patches. You can find it
attached to this e-mail.
Here is a list with the changes I did after the feedback:
- initialized the internal variables (patch 06)
- moved the *WSACleanup* call from patch 06 to patch 12
- removed the implementation of my internal *getLastError* and started
using *qt_error_string* (patch 11)
- used *WSAAddressToStringW* instead of *WSAAddressToStringA* (patch 11)
- avoided some code duplication (patches 14, 15, 17)
I hope that I covered all of Thiago's suggestions.
You should know that I didn't call *WSACleanup* if the
*WSAStartup* failed because this call was already made in the
*BtDeviceSelectionDialog* destructor and I didn't know exactly
how I should handle this elegantly :).
Also I didn't remove the call of strdup method from
*qtserialbluetooth::qt_serial_open *because the
*WSAStringToAddressA* method is expecting to receive
LPSTR {aka char*} parameter while I have the address
represented as const char*.
I tried as well to replace the WSAStringToAddressA with
WSAStringToAddressW but I had to represent the
address as a wchar_t* and and when I wanted to use
mbstowcs_s for conversion (from const char* to wchar_t*)
the compiler couldn't find the declaration to the method
(even though I included the stdlib header). After some
failed attempts I gave up :).
Cheers,
Claudiu
From ca22cc110c07284499be9aab4e0230dbc13932e2 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Tue, 18 Aug 2015 20:11:25 +0300
Subject: [PATCH 01/18] Cleanup Bluetooth local device and the discovery agent
on exit
Do some extra cleanup when the BtDeviceSelectionDialog is
destroyed.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 007fe94..ce759cc 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -61,6 +61,15 @@ BtDeviceSelectionDialog::BtDeviceSelectionDialog(QWidget *parent) :
BtDeviceSelectionDialog::~BtDeviceSelectionDialog()
{
delete ui;
+
+ // Clean the local device
+ delete localDevice;
+
+ // Clean the device discovery agent
+ if (remoteDeviceDiscoveryAgent-isActive())
+ remoteDeviceDiscoveryAgent-stop();
+
+ delete remoteDeviceDiscoveryAgent;
}
void BtDeviceSelectionDialog::on_changeDeviceState_clicked()
--
2.4.3
From a235c7dd8fe18fc40c3efa75f5a01f0787ba43e3 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Tue, 18 Aug 2015 20:12:15 +0300
Subject: [PATCH 02/18] Check the last error when the BTH device scanning is
finished
If there is no error reported when the device scanning is finished
then report to the dialog status that the scanning finished
successfully. Otherwise report the last error.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index ce759cc..3af2501 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -124,7 +124,12 @@ void BtDeviceSelectionDialog::on_scan_clicked()
void BtDeviceSelectionDialog::remoteDeviceScanFinished()
{
- ui-dialogStatus-setText(Scanning finished.);
+ if (remoteDeviceDiscoveryAgent-error() == QBluetoothDeviceDiscoveryAgent::NoError) {
+ ui-dialogStatus-setText(Scanning finished successfully.);
+ } else {
+ deviceDiscoveryError(remoteDeviceDiscoveryAgent-error());
+ }
+
ui-scan-setEnabled(true);
}
--
2.4.3
From ccfd2068dad95052f1c5e473a976d684993efc39 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Tue, 18 Aug 2015 20:15:49 +0300
Subject: [PATCH 03/18] Clear the BTH discovered devices list on each search
Clear the Bluetooth discovered devices list on each search.
In this way we will show only the devices that are in range
and active during the last scannning. Also if we clear the
list before each call we don't need to check anymore if the
discovered device is already in the list.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 3af2501..7f53740 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -118,6 +118,7 @@ void BtDeviceSelectionDialog::on_clear_clicked()
void BtDeviceSelectionDialog::on_scan_clicked()
{
ui-dialogStatus-setText(Scanning for remote devices...);
+ ui-discoveredDevicesList-clear();
remoteDeviceDiscoveryAgent-start();
ui-scan-setEnabled(false);
}
@@ -145,28 +146,28 @@ void BtDeviceSelectionDialog::hostModeStateChanged(QBluetoothLocalDevice::HostMo
void
Re: at some point we need to release Subsurface 4.5
Bluetooth support = BT support is looking fairly good on Linux and making progress on Windows, I think, but I'm sure there are tons of small issues lurking here and there. Has anyone gotten it to work on Mac, yet? Claudiu / Thiago - do you have a TODO list? The patches sent should add support for Windows and fix the issues reported so far (at least the ones that could be reproduced:) ). Until now we managed (Rick, Steve and me) to test the implementation on Windows XP SP2, Windows Vista, Windows 7, Windows 8.1 and Windows 10. There were no issues reported which are related to the data transfer. Unfortunately I didn't receive any feedback for MAC platforms and I don't have any environment in which I could run some tests. I am really curious how it works. Regarding the TODO list this is what I have in mind: - improve the UI for Linux Mac platforms (remove the context menu with the pairing functionalities and add a separated button for that) - add support for other dive computer families which have Bluetooth functionality (like Aeris) - implement a new feature which will add the possibility to do firmware upgrade directly from Subsurface app User manual === That needs massive work for all the amazing features that we have added. Willem, will you be able to do that? Once we have agreed on a feature set for the Android app, that needs a separate user manual as well. Volunteers? I am planning to update the Bluetooth section with the usage of our custom Bluetooth implementation and with some troubleshooting tips. Cheers, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATH] Add native Bluetooth support for Windows platforms
Hi,
I did the modifications we discussed and I added two extra
improvements (patch number 4 and 19).
The modifications are available on *bth_windows* branch [1].
I thought that it would be easier for Thiago to review the new code
if I will create a separate branch.
Claudiu
[1] - https://github.com/claudiuolteanu/subsurface/tree/bth_windows
From b5225ce0a5d94e70253d0a97b3f894234c7f93df Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sun, 16 Aug 2015 15:51:32 +0300
Subject: [PATCH 01/19] Cleanup Bluetooth local device and the discovery agent
on exit
Do some extra cleanup when the BtDeviceSelectionDialog is destroyed.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 007fe94..ce759cc 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -61,6 +61,15 @@ BtDeviceSelectionDialog::BtDeviceSelectionDialog(QWidget *parent) :
BtDeviceSelectionDialog::~BtDeviceSelectionDialog()
{
delete ui;
+
+ // Clean the local device
+ delete localDevice;
+
+ // Clean the device discovery agent
+ if (remoteDeviceDiscoveryAgent-isActive())
+ remoteDeviceDiscoveryAgent-stop();
+
+ delete remoteDeviceDiscoveryAgent;
}
void BtDeviceSelectionDialog::on_changeDeviceState_clicked()
--
2.1.4
From 546184eb3d8e246ed4dd34b31d43bd37b2312e44 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sun, 16 Aug 2015 15:52:31 +0300
Subject: [PATCH 02/19] Check the last error when the BTH device scanning is
finished
If there is no error reported when the device scanning is finished
then report to the dialog status that the scanning finished
successfully. Otherwise report the last error.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index ce759cc..3af2501 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -124,7 +124,12 @@ void BtDeviceSelectionDialog::on_scan_clicked()
void BtDeviceSelectionDialog::remoteDeviceScanFinished()
{
- ui-dialogStatus-setText(Scanning finished.);
+ if (remoteDeviceDiscoveryAgent-error() == QBluetoothDeviceDiscoveryAgent::NoError) {
+ ui-dialogStatus-setText(Scanning finished successfully.);
+ } else {
+ deviceDiscoveryError(remoteDeviceDiscoveryAgent-error());
+ }
+
ui-scan-setEnabled(true);
}
--
2.1.4
From 70ad7b8a83d3f594ec0dc5ba089aa4944e5a8a1d Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sun, 16 Aug 2015 15:56:31 +0300
Subject: [PATCH 03/19] Clear the BTH discovered devices list on each search
Clear the Bluetooth discovered devices list on each search.
In this way we will show only the devices that are in range
and active during the last scannning. Also if we clear the
list before each call we don't need to check anymore if the
discovered device is already in the list.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 3af2501..cbc247d 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -118,6 +118,7 @@ void BtDeviceSelectionDialog::on_clear_clicked()
void BtDeviceSelectionDialog::on_scan_clicked()
{
ui-dialogStatus-setText(Scanning for remote devices...);
+ ui-discoveredDevicesList-clear();
remoteDeviceDiscoveryAgent-start();
ui-scan-setEnabled(false);
}
@@ -145,28 +146,27 @@ void BtDeviceSelectionDialog::hostModeStateChanged(QBluetoothLocalDevice::HostMo
void BtDeviceSelectionDialog::addRemoteDevice(const QBluetoothDeviceInfo remoteDeviceInfo)
{
- QString deviceLabel = QString(%1 (%2)).arg(remoteDeviceInfo.name()).arg(remoteDeviceInfo.address().toString());
- QListQListWidgetItem * itemsWithSameSignature = ui-discoveredDevicesList-findItems(deviceLabel, Qt::MatchStartsWith);
+ QColor pairingColor = QColor(Qt::red);
+ QString pairingStatusLabel = QString(UNPAIRED);
+ QBluetoothLocalDevice::Pairing pairingStatus = localDevice-pairingStatus(remoteDeviceInfo.address());
- // Check if the remote device is already in the list
- if (itemsWithSameSignature.empty()) {
- QListWidgetItem *item = new QListWidgetItem(deviceLabel);
- QBluetoothLocalDevice::Pairing pairingStatus = localDevice-pairingStatus(remoteDeviceInfo.address());
- item-setData(Qt::UserRole, QVariant::fromValue(remoteDeviceInfo));
+ if (pairingStatus == QBluetoothLocalDevice::Paired) {
+ pairingStatusLabel = QString(PAIRED);
+ pairingColor = QColor(Qt::gray);
+ } else if (pairingStatus == QBluetoothLocalDevice
Re: [PATH] Add native Bluetooth support for Windows platforms
Can you explain this a bit more? Should we not prefer the deviceLabel IF we can get it? When I created that patch I thought that it would be better to use only the device address to identify if the device is already in the list. This is due the fact that currently the pattern of the deviceLabel is *$deviceName ($deviceAddress) $pairingStatus *. There are moments when the device name is missing and moments when the pairing status is different. Now if I think more clearer if we don't update the devices state it would lead to some inconsistent states. Probably it would be a better idea to clear the list with the discovered devices when a new device lookup is initiated. In this way we will show only the devices that are in range during the last scanning. If you agree with this I can send you another patch. b) did you write all this from scratch or was this inspired by some existing BT code for Windows from some other project? This is a non-trivial chunk of code in an area I'm not very familiar with... (and just to avoid email communication issues - no, I'm not doubting that you wrote this code... I just want to make sure that if there is a source we should credit that we do). The code is written from scratch but I used two sources of inspiration: - for the implementation of our custom serial callbacks I looked over the Native bluetooth communication sample created by Jef - for the device lookup I looked over a sample[1] provided by Microsoft Corporation to demonstrate how to use Winsock 2.2 Api and RFCOMM protocol I didn't know where I should mention them :) . While Jef is probably already mentioned for his help I am not sure if Microsoft should be mentioned when you get inspiration from one of their samples. Also you should know that our custom serial implementation is based on the native serial implementation provided by Jef (the design). I thought that it is obvious but I just wanted to be clear :). Claudiu [1] - https://code.msdn.microsoft.com/windowsdesktop/Bluetooth-Connection-e3263296 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATH] Add native Bluetooth support for Windows platforms
No I didn't do any copy and paste. I will send you tomorrow the patches with the modification discussed (I will clear the discovered devices list after each update) and I will update the commit message for the patch with the implementation of a device discovery agent. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Testing Native Bluetooth support on Windows platforms
Ok, thanks a lot for your help! As I said, the download mode is supposed to work only if the devices are paired. If the devices are not paired then Windows will ask for your permissions to pair them and you should allow it. If you have any questions or suggestions, please let me know. Have a nice day, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATH] Add native Bluetooth support for Windows platforms
These patches will add Bluetooth support for Windows platforms
and will fix some potential issues.
Since we cannot use the QtBluetooth framework I needed to
implement our custom Bluetooth device discovery agent.
I decided to create a separated class and raise the same signals
as QtBluetoothDeviceDiscoveryAgent class.
I am not sure if this is the best idea or the most elegant one but it works.
Claudiu
From 3d2e55d597aed27515650792f8bd77bf742f6576 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Wed, 12 Aug 2015 22:46:31 +0300
Subject: [PATCH 01/17] Cleanup Bluetooth local device and the discovery agent
on exit
Do some extra cleanup when the BtDeviceSelectionDialog is destroyed.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 007fe94..ce759cc 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -61,6 +61,15 @@ BtDeviceSelectionDialog::BtDeviceSelectionDialog(QWidget *parent) :
BtDeviceSelectionDialog::~BtDeviceSelectionDialog()
{
delete ui;
+
+ // Clean the local device
+ delete localDevice;
+
+ // Clean the device discovery agent
+ if (remoteDeviceDiscoveryAgent-isActive())
+ remoteDeviceDiscoveryAgent-stop();
+
+ delete remoteDeviceDiscoveryAgent;
}
void BtDeviceSelectionDialog::on_changeDeviceState_clicked()
--
2.4.3
From aaa885948c1847bf766d3f0f6e546e4651100cca Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Wed, 12 Aug 2015 22:46:56 +0300
Subject: [PATCH 02/17] Check the last error when the BTH device scanning is
finished
If there is no error reported when the device scanning is finished
then report to the dialog status that the scanning finished
successfully. Otherwise report the last error.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index ce759cc..3af2501 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -124,7 +124,12 @@ void BtDeviceSelectionDialog::on_scan_clicked()
void BtDeviceSelectionDialog::remoteDeviceScanFinished()
{
- ui-dialogStatus-setText(Scanning finished.);
+ if (remoteDeviceDiscoveryAgent-error() == QBluetoothDeviceDiscoveryAgent::NoError) {
+ ui-dialogStatus-setText(Scanning finished successfully.);
+ } else {
+ deviceDiscoveryError(remoteDeviceDiscoveryAgent-error());
+ }
+
ui-scan-setEnabled(true);
}
--
2.4.3
From f21c7c9f9a9a135faed50b66b57223f6165658b3 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Wed, 12 Aug 2015 22:48:54 +0300
Subject: [PATCH 03/17] Use only the BTH address to check if the device was
already added
There are moments when the name of the device cannot be obtained.
Therefore we should use only the Bluetooth address to identify if
the discovered device was already added to the list.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 3af2501..7fd2c7c 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -146,7 +146,7 @@ void BtDeviceSelectionDialog::hostModeStateChanged(QBluetoothLocalDevice::HostMo
void BtDeviceSelectionDialog::addRemoteDevice(const QBluetoothDeviceInfo remoteDeviceInfo)
{
QString deviceLabel = QString(%1 (%2)).arg(remoteDeviceInfo.name()).arg(remoteDeviceInfo.address().toString());
- QListQListWidgetItem * itemsWithSameSignature = ui-discoveredDevicesList-findItems(deviceLabel, Qt::MatchStartsWith);
+ QListQListWidgetItem * itemsWithSameSignature = ui-discoveredDevicesList-findItems(remoteDeviceInfo.address().toString(), Qt::MatchContains);
// Check if the remote device is already in the list
if (itemsWithSameSignature.empty()) {
--
2.4.3
From d24aa8f4eeb6182750d79c78ff093a4043b3fad2 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Wed, 12 Aug 2015 22:56:46 +0300
Subject: [PATCH 04/17] Add set_timeout callback for Bluetooth custom serial
implementation
The new callback will be usefull when we will implement the support
for Windows. The implementation of native serial set_timeout method
uses a HANDLER on Windows and we will use the WinSock2 API which has
a socket descriptor.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qtserialbluetooth.cpp | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/qtserialbluetooth.cpp b/qtserialbluetooth.cpp
index 5a982d6..378f330 100644
--- a/qtserialbluetooth.cpp
+++ b/qtserialbluetooth.cpp
@@ -224,6 +224,15 @@ static int
Re: Testing Native Bluetooth support on Windows platforms
Windows 10 puts a message on the right side of the screen: Add a device, Tap to setup your OSTC3 (see win10-ostc3+bluetooth01.jpg). Then it fails with the message: Error, Unable to open 00: etc, No device found (see win10-ostc3+bluetooth02.jpg). That message is prompt when your devices are not paired. When your local BTH adapter tries to connect to the remote one it tries to automatically pair the devices (if they are unpaired). Therefore, Windows asks for your permissions and puts that message box. I will write these details in the user manual. Tried again this time I clicked the windows message that popped up and paired the OSTC3 and it worked (as it always used to when paired). Unpaired and tried again and it failed again but this time the progress bar reached 100% (see win10-ostc3+bluetooth03.jpg). The progress bar status is not quite accurate when you press the retry button. Were your devices paired? Did your dive computer device entered in Download mode? As I said, when the Windows prompts for your permissions, you should allow it. Also there are moments when the connection method will raise a timeout and it will fail if the pairing step takes too long. Cheers, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Testing Native Bluetooth support on Windows platforms
Hi Benjamin, Can you please give me more details? Are your devices paired? When you say that the application crashes you mean that your receive a SEGV error and it is forcibly closed? It would be useful if you can take a look in the Event Viewer (open Run/Command terminal and write *eventvwr *command) , Windows Logs - Application section and tell me the last related message with Subsurface application (if the application crashed it should be logged with Error level). More useful it would be to start the application using gdb. If you don't have it you can download it from here [1]. I don't know if you ever use it before. To run the application you should: - open Command Prompt - run $PATH_TO_GDB\gdb.exe $PATH_TO_SUBSURFACE\subsurface.exe - execute run command This will start the application for you. Next you should do the exact steps and reproduce the problem. Finally you will receive some output which hopefully it would be useful to understand what is causing your crash. Best wishes, Claudiu [1] - https://www.dropbox.com/s/a31qjio4d1bw84u/gdb.zip?dl=0 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Testing Native Bluetooth support on Windows platforms
On the Vista machine, the device name was displayed, even before I had paired. I totally forgot about the existence of Windows Vista :). I will create a virtual machine to see if I can reproduce your problem. I like that pairing is now 'invisible' to the user. But it would be good if you could detect when downloading fails, and provide a more meaningful message to prompt the user to pair manually (this goes for all systems, not just Windows). Unfortunately I am not sure if I can detect if the connection failed due to pairing issues. I looked over the errors returned by Winsocket2 connect method and the only one which could be useful is WSACONNREFUSED. If this is the error returned by the connect method I can suppose that there was an authentication error. When I use the Qt Bluetooth API [1], there is nothing to suggest an authentication error / connection refused. I thought that I could write about this possible issue on the user manual and our users will be aware about this potential problem. I didn't need to download the Microsoft C++ package on either system. I can't remember doing it previously for either computer, but the Vista laptop is old, so there's a chance I did in the past and forgot about it. When Steve reported his issue this was the first thing I had in mind Therefore I removed the application and the Microsoft C++ x86 packages. When I tried to install again the application I encountered the same problem. That is why I thought that this could fix his issue. In his scenario it seems that it was something wrong with the registers. Anyway, thanks again for your help and I hope that your little vacation went as expected. Claudiu [1] - http://doc.qt.io/qt-5/qbluetoothsocket.html#SocketError-enum ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Testing Native Bluetooth support on Windows platforms
Steve, did you use the installer I sent? If you created your own installer, be aware that my changes are not in the upstream. I ask these because in the screenshot in seems that your application is using the implementation with the Qt Bluetooth framework. Currently the Qt Bluetooth library is available only on Linux, Android, iOS, OSx and BlackBerry platforms. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[GSoC] Week 11 - Native Bluetooth support
Hello, Here is a short report about the last week: - finished the implementation of data transfer for Windows platforms - created 3 new environments for testing the solution (Windows Xp SP2, Windows 7, Windows 10) - tested the solution with my HW OSTC devices on 7 different environments: - Lenovo Y50 (OS: Windows 8.1) - Lenovo Y510p (OSes: Windows 8.1, Windows 7 (VM), Windows XP SP2 (VM), Windows 10 (VM)) - Acer Aspire One D260 (OS: Windows 7) - Dell Latitude e5430 (OS: Windows 8.1) This week I want to : - create and send the patches for review - update the user manual documentation - potential bug fixing Have a nice week, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Testing Native Bluetooth support on Windows platforms
Tested from the OSTC3+ and Petrel 2 and both worked as expected. I'm glad that it worked. Thanks for the feedback! Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Testing Native Bluetooth support on Windows platforms
Hello, Yes this is a 32 bit build. The installer fails because probably you don't have *Microsoft Visual C++ 2013 Redistributable (x86)* package installed on your laptop. You can download it from here [1]. Currently I don't have an environment to create the 64 bit installer so please install the Microsoft C++ package to resolve this issue. Regards, Claudiu [1] - http://download.microsoft.com/download/2/E/6/2E61CFA4-993B-4DD4-91DA-3737CD5CD6E3/vcredist_x86.exe ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Testing Native Bluetooth support on Windows platforms
I decided to create a virtual machine with Windows 10 (x64) and to run some tests there too. I didn't encounter any problems regarding the data transfer. The only thing that I saw is that on my all virtual machines (Windows XP SP2, Windows 7, Windows 10) the first time you start to lookup for devices, the names of the devices are not displayed correctly (they are empty). If you do another lookup, then it manages to collect the information about each device's name. Best wishes, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Testing Native Bluetooth support on Windows platforms
Hi there, I wanted to let you know that I finished the implementation of the native Bluetooth support on Windows platforms. If you have a dive computer with Bluetooth support from HW_OSTC3 or Shearwater family it would be very useful if you will help me to do some tests. You can download the installer from here[1]. The download transfer is supposed to work on Windows platforms greater than or equal to Windows XP SP 2. You should know that if your local Bluetooth device is not using the Windows Bluetooth stack and uses another one (WINCOMM, Soleil, etc.) it will not work. Currently I tested the installer on 4 laptops with their integrated Bluetooth adapter: - Lenovo Y50 (OS: Windows 8.1) - Lenovo Y510p (OS: Windows 8.1, Windows 7 (VM), Windows XP SP2 (VM)) - Acer Aspire One D260 (OS: Windows 7) - Dell Latitude e5430 (OS: Windows 8.1) On some environments the pairing step took more than expected and the download process got stuck. If you encounter the same problem please try to manually pair the devices. Also on my virtual machines with Windows 7 and Windows XP SP2 sometimes the name of the devices are not displayed correctly (they are empty). If you have any issues/questions, please let me know. Have a nice weekend, Claudiu [1] - https://www.dropbox.com/s/pz03kd0qno05m45/subsurface-4.4.2-1329-ge45e3f0e8392.exe?dl=0 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Petrel 2 bluetooth link
andrej@antares:~$ subsurface Map theme file does not exist: Ignoring to load the following file since it doesn't look like a valid Marble plugin: /boot/initrd.img-3.19.0-25-generic Reason: '/boot/initrd.img-3.19.0-25-generic' is not an ELF object Ignoring to load the following file since it doesn't look like a valid Marble plugin: /boot/initrd.img-3.19.0-23-generic Reason: '/boot/initrd.img-3.19.0-23-generic' is not an ELF object Ignoring to load the following file since it doesn't look like a valid Marble plugin: /boot/vmlinuz-3.19.0-25-generic Reason: Permission denied Ignoring to load the following file since it doesn't look like a valid Marble plugin: /boot/vmlinuz-3.19.0-23-generic Reason: Permission denied QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory Set the current dive site: 0 qt.bluetooth.bluez: Bluez 4 detected. qt.bluetooth.bluez: void QBluetoothDeviceDiscoveryAgentPrivate::_q_propertyChanged(const QString, const QDBusVariant) Discovering QVariant(bool, true) qt.bluetooth.bluez: Discovered: 00:13:43:0E:68:77 Petrel Num UUIDs 1 total device 0 cached false RSSI -70 qt.bluetooth.bluez: Emit: 00:13:43:0E:68:77 qt.bluetooth.bluez: Discovered: 00:13:43:0E:68:77 Petrel Num UUIDs 1 total device 1 cached false RSSI -71 qt.bluetooth.bluez: Duplicate: 00:13:43:0E:68:77 qt.bluetooth.bluez: void QBluetoothDeviceDiscoveryAgentPrivate::_q_propertyChanged(const QString, const QDBusVariant) Discovering QVariant(bool, false) The connection on RFCOMM channel number 1 took more than expected. Wait another 15 seconds. qt.bluetooth.bluez: void QBluetoothSocketPrivate::_q_readNotify() 22 error: -1 Resource temporarily unavailable Failed to connect to device 00:13:43:0E:68:77 . Device state QBluetoothSocket::UnconnectedState . Error: QBluetoothSocket::UnknownSocketError Set the current dive site: 0 This is strange, because if the connection on RFCOMM channel 1 fails, it should try to connect again on channel number 5. If not it means that the remote device din't send any response and the connection took more than expected. You always receive the same output? ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Petrel 2 bluetooth link
Hi there, Note that the testing version is just that. It works for me, and your help in testing is much appreciated, but there's a reason why it isn't called stable. You might come across bugs. This development cycle includes more new features than normal, including native bluetooth support, and some are still work in progress. I am not sure if native bluetooth support has been tested with Bluez 4. I didn't have the chance to test it with Bluez-4.X but it should work. It would be a great help for us if you will give me some feedback, Andrej. If you encounter any problems please let me know. I will try to create the same environment and help you fix the issues. Native Bluetooth support isn't yet in the documentation. To use it, go to download (ctrl-D), check the Choose Blueooth download mode box. Power on your bluetooth device if it isn't already, hit scan and select your dive computer. If it doesn't say it's paired, right click to pair it. Click save to close the bluetooth dialog, then select download. Also you should know that pairing with devices which require a custom PIN code isn't supported yet. Therefore if the pairing step fails, you should try to pair the devices manually (using bluedevil, bluetoothctl or other tools). I'm off for a few days diving, so won't be able to help much, but please do report any issues. Claudiu is the one who has done the great work in bringing the native bluetooth support. Thanks for the kind words and enjoy your diving days! I hope that as soon as you come back from your trip I will have finished the Windows installer. Currently I managed to test it on Windows 7 and Windows 8.1 and the download process works fine the first time. When you try to do some consecutive downloads it fails. Cheers, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[GSoC] Week 9 - Native Bluetooth support
Hi there, This week I managed to implement a sample which connects to remote a Bluetooth device and exchanges some bits using the Windows API. For the beginning I wanted to see if I can make my HW OSTC2 and OSTCs devices enter in download mode. I didn't encounter too many problems so I decided to step forward. I spent most of the time trying to do a cross building for Subsurface project on Linux for Windows. I met a lot of problems but in the end I managed to create an installer with the latest Subsurface version. This week I want to finish the integration of the download sample and to create an installer with it in order to do some tests and to receive some feedback. Regards, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
In general the mentor is not necessarily the clean up person... I know, Thiago offered, but just to put this out here. When I said that he should do some investigations I didn't mean to start hunting memory leaks on my code. I can do that by myself using their best friend - Valgring :). I just wanted to point out that I have more background in C and I don't have too much experience with C++ and Qt. Therefore, I certainly can do some design mistakes or I can make the code more complicated than it should be. I am more than pleased with the hints he gave me. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
Hi, I agree with Thiago. Probably it is a good idea to keep the Bluetooth download feature only for versions = 5.4. This is due the fact that in version 5.4 they added support for BlueZ 5.X stack and probably most of the users have this stack. To be honest I didn't take into account to test the implementation using a lower version than 5.4. If you want I can do that. I know that QtBluetooth library was introduced in version 5.2. The main feature from version 5.3 is that the module was ported to Android. Also both 5.2 and 5.3 versions have support only for Bluez 4.X. I expect the source code to work with Qt version 5.2 for a Linux platform with BlueZ 4.X (excepting the part where I tested that the discovery agent was successfully created). As I said before, I can create a new environment and I can do some tests for Qt 5.2 on Linux and for Qt 5.3 on Linux and Android. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[GSoC] Week 8 (Native Bluetooth support)
Hello, Here is a summary about what I did last week: - tested and fixed some issues for Android platform - implemented a combobox which can be used to choose the local Bluetooth adapter - continue the documentation and developing the sample for Windows platform - created a new environment with Windows 7 - implemented the device discovery functionality and tested for Windows 7 and 8.1 (using MS stack) - implemented a service discovery functionality and tested for Windows 7 and 8.1 (using MS stack) Below you can find some things that I discovered and you should know: - there are 4 stacks for Bluetooth on Windows ( Microsoft, Widcomm, Stonestreet One Bluetopia Bluetooth and BlueSoleil) - not all devices work with the MS stack - Bluetooth functionalities like connection to serial devices was introduced in Windows XP SP2 - more details about Bluetooth support on Windows platforms [1] - I didn't find an API which can be used to control the local adapter (turn on/off, get/set device information) - I didn't find an API which can be used to pair/unpair devices Now I don't know exactly which version of Windows our users use. If it is greater than 8 then I am not sure if we should put effort on adding support for Window platforms. As you probably know from Thiago, on Qt 5.6 they are planning to add Bluetooth support for Windows 8.X and Windows 10. This will be released by the end of this year. What I know is that programming with Win32/Winsock2 API is quite tricky (at least for me..:) ). Also, after I installed the driver (BlueSoleil) for my dongle something went wrong and my sample with device discovery didn't work anymore. The only way to make it work again was to remove the BlueSoleil driver. To be honest I didn't expect to be harder to work on Windows :). Next I am planning to try to connect the devices and to do some data transfer. Claudiu [1] - https://msdn.microsoft.com/en-us/library/windows/hardware/dn133849%28v=vs.85%29.aspx?f=255MSPPError=-2147217396 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
Thanks for the info, Rick! Did you tried to download the dives after you paired the devices manually (using bluetoothctl)? Currently the QtBluetooth library doesn't have an agent which can be used to set a custom PIN code on pairing step [1]. I don't know when they will implement it. The pairing step must be done only once when you connect a new device to the computer. Therefore we decided to postpone the implementation of a custom agent. The only way to test if the pairing command was triggered from our widget is to open a default agent in the background and see if the PIN code request is raised. One solution is to use the bluetoothctl tool: agent KeyboardOnly default-agent Unfortunately I don't know why some devices need a pairing code and others don't need one. As I said before, I assume that they are smarter and they try some basic PIN codes on the authentication step. Claudiu [1] - https://bugreports.qt.io/browse/QTBUG-42740 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
Hi Rick, I can select my usb bluetooth dongle (using the one that came with my petrel), and power it up or down, but I was not able to pair or unpair (when previously paired using the onboard bluetooth). Downloading fails with the usb dongle, even when it had already been paired. It didn't make any difference whether onboard bluetooth was powered or not when I tried. Can you give me more details about the downloading step? It fails on the connection step or it gets stuck during the download mode? You should find some logs on the console. Does the onboard bluetooth device work after applying the patches? I tested my patches on my OpenSuse env with a Gembird Mini3 Tiny Bluetooth v.2.1 dongle and I didn't encounter problems during the download. The pair/unpair commands work too. Unfortunately the device is not recognized on my Fedora virtual machine. Probably it is a problem with my driver because on their site the latest driver has support for Windows 7 and I have Windows 8.1. Also, please check if the pairing status from the Bt selection widget is the same as the one from bluetoothctl/bluedevil tools. Regards, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
I didn't think to try that before. But I just tried and it worked. Great to hear that :). That's annoying. Thankfully, most systems have a reasonably friendly way to pair bluetooth devices, and it only needs to be done once. Can you detect if pairing fails, and ask the user to pair the device using their operating system? It's been a while since I've used the Shearwater Desktop program, but I think it requires the user to pair the device using Windows. I know. Most of the embedded devices require a custom PIN code. I don't know why they haven't taken into account this from the beginning. Currently if the pairing fails there is a log message Local device error: Pairing error shown in the status section. Maybe I should expand this message and specify that the user should try to pair the devices using their operating system. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Ctrl-+ and Qt5.5
Hi there, I have a Fedora 22 with Qt 5.5.0 and the shortcut is working. Subsurface version: 4.4.2-1040-g5cbbff008411c322. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
Child QObjects don't need to be cleaned. But I'm not seeing any parent-child relationship here. I'm deferring to you here. I'm just pointing out, I haven't done any investigation. Would you like me to? I don't have too much experience with C++ and Qt framework. If you have time, it would be safer if do some investigation? I saw that Q_OS_MAC doesn't include the open source version and I didn't know which is that :). Huh? I didn't look over the implementation. I just read the description from here[1] and it is mentioned something about an open source version :). [1] - http://doc.qt.io/qt-5.5/qtglobal.html#Q_OS_MAC ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
Claudiu, most people only have one local bluetooth device. We shouldn't
display a list to select an entry if there's only one entry to be selected.
Can you hide the list if the list contains only one?
Of course I can do. One of the attached patches (#0009) should do the trick.
Where is this deleted? Does QBluetoothLocalDevice take ownership?
This information should remain until the widget is destroyed. I thought
that it will be automatically deleted when I delete the *ui *instance.
Should I
manually clean his children?
All of those QString() should be tr() so they cna be translated. I haven't
checked previous patches for this...
None of the patches uses tr() . I will create a patch in the end which will
do the
translations.
+#elif defined(Q_OS_ANDROID) || (QT_VERSION = 0x050500
(defined(Q_OS_IOS) || defined(Q_OS_OSX)))
Hint: Q_OS_DARWIN and Q_OS_MAC also mean Q_OS_IOS || Q_OS_OSX.
I saw that Q_OS_MAC doesn't include the open source version and I didn't
know which is that :).
Thanks for the hints,
Claudiu
From 3608bc8431449aff26f0f0563337d136de08cd2b Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sun, 19 Jul 2015 22:11:16 +0300
Subject: [PATCH 11/11] Update the message shown on pairing erorrs
Advice the user to use his operating system for the pairing
step if the remote device requires a custom PIN code.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 9cde87e..007fe94 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -272,7 +272,9 @@ void BtDeviceSelectionDialog::pairingFinished(const QBluetoothAddress address,
void BtDeviceSelectionDialog::error(QBluetoothLocalDevice::Error error)
{
ui-dialogStatus-setText(QString(Local device error: %1.)
- .arg((error == QBluetoothLocalDevice::PairingError)? Pairing error : Unknown error));
+ .arg((error == QBluetoothLocalDevice::PairingError)? Pairing error. If the remote device requires a custom PIN code,
+ please try to pair the devices using your operating system.
+ : Unknown error));
}
void BtDeviceSelectionDialog::deviceDiscoveryError(QBluetoothDeviceDiscoveryAgent::Error error)
--
2.1.4
From f9dc098f4912b339d956195777bbc171ca4c2836 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sun, 19 Jul 2015 21:50:06 +0300
Subject: [PATCH 09/11] Hide the local BT combobox if there is only one device
If there is only one local Bluetooth adapter, then hide the
selection combobox and the label.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index f84d9cd..1d6b812 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -26,22 +26,29 @@ BtDeviceSelectionDialog::BtDeviceSelectionDialog(QWidget *parent) :
// Populate the list with local bluetooth devices
QListQBluetoothHostInfo localAvailableDevices = localDevice-allDevices();
- int defaultDeviceIndex = -1;
int availableDevicesSize = localAvailableDevices.size();
- for (int it = 0; it availableDevicesSize; it++) {
- QBluetoothHostInfo localAvailableDevice = localAvailableDevices.at(it);
- ui-localSelectedDevice-addItem(localAvailableDevice.name(),
- QVariant::fromValue(localAvailableDevice.address()));
+ if (availableDevicesSize 1) {
+ int defaultDeviceIndex = -1;
- if (localDevice-address() == localAvailableDevice.address())
- defaultDeviceIndex = it;
- }
+ for (int it = 0; it availableDevicesSize; it++) {
+ QBluetoothHostInfo localAvailableDevice = localAvailableDevices.at(it);
+ ui-localSelectedDevice-addItem(localAvailableDevice.name(),
+ QVariant::fromValue(localAvailableDevice.address()));
+
+ if (localDevice-address() == localAvailableDevice.address())
+defaultDeviceIndex = it;
+ }
- // Positionate the current index to the default device and register to index changes events
- ui-localSelectedDevice-setCurrentIndex(defaultDeviceIndex);
- connect(ui-localSelectedDevice, SIGNAL(currentIndexChanged(int)),
- this, SLOT(localDeviceChanged(int)));
+ // Positionate the current index to the default device and register to index changes events
+ ui-localSelectedDevice-setCurrentIndex(defaultDeviceIndex);
+ connect(ui-localSelectedDevice, SIGNAL(currentIndexChanged(int)),
+ this, SLOT(localDeviceChanged(int)));
+ } else {
+ // If there is only one local Bluetooth adapter hide the combobox and the label
+ ui-selectDeviceLable-hide();
+ ui-localSelectedDevice-hide();
+ }
// Update the UI information about the local device
updateLocalDeviceInformation
[PATCH] Bluetooth improvements
Hi there,
I attached some patches which should improve the user experience
when the Bluetooth download mode is enabled.
The first patch should stop the device discovery agent when the
user press the Save/Cancel button. In this way we don't need the
modifications from commit #94d3aa04dccc3 . I should have done this
from the beginning.
Patch number 4 adds a combobox which can be used to
select a local Bluetooth adapter. In this way, if a user has more
than one local Bluetooth device (integrated, dongles, etc.)
he can choose which one he wants to use.
The last patch should enable the Bluetooth connectivity for iOS/OSx
platforms with Qt version 5.5.0.
Claudiu
From 039085972fbb4f59b4ab1c349a34c32d7538774e Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sat, 18 Jul 2015 23:14:00 +0300
Subject: [PATCH 8/8] Use SPP's uuid to connect to a device on iOS/OSx
platforms
Use the uuid of the Serial Port Profile service to connect to a
remote Bluetooth device on iOS/OSx platforms with a Qt version greater
than 5.5.0.
In the future the same section should be used for BT connectivity on
Linux platforms. Currently there is a problem with the SDP discovery
and it doesn't work as expected.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qtserialbluetooth.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qtserialbluetooth.cpp b/qtserialbluetooth.cpp
index 95f3611..aad082e 100644
--- a/qtserialbluetooth.cpp
+++ b/qtserialbluetooth.cpp
@@ -80,7 +80,7 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev
loop.exec();
}
}
-#elif defined(Q_OS_ANDROID)
+#elif defined(Q_OS_ANDROID) || (QT_VERSION = 0x050500 (defined(Q_OS_IOS) || defined(Q_OS_OSX)))
// Try to connect to the device using the uuid of the Serial Port Profile service
QBluetoothAddress remoteDeviceAddress(devaddr);
serial_port-socket-connectToService(remoteDeviceAddress, QBluetoothUuid(QBluetoothUuid::SerialPort));
--
2.1.4
From 69a75fed05fc3d00c645f5c3690271344c7b561d Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Thu, 16 Jul 2015 23:06:22 +0300
Subject: [PATCH 1/8] Stop the SDP agent if the Clear/Save button was pressed
If the Cancel button was pressed then we should stop the
SDP agent. The same thing happens when the Save button
was pressed. We don't need to add new BT remote devices
to the list if the widget was closed or if the list with
the discovered BT devices was cleared.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 9b97da3..6a2a977 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -86,6 +86,12 @@ void BtDeviceSelectionDialog::on_save_clicked()
// Save the selected device
selectedRemoteDeviceInfo = QSharedPointerQBluetoothDeviceInfo(new QBluetoothDeviceInfo(remoteDeviceInfo));
+ if (remoteDeviceDiscoveryAgent-isActive()) {
+ // Stop the SDP agent if the clear button is pressed and enable the Scan button
+ remoteDeviceDiscoveryAgent-stop();
+ ui-scan-setEnabled(true);
+ }
+
// Close the device selection dialog and set the result code to Accepted
accept();
}
@@ -95,6 +101,12 @@ void BtDeviceSelectionDialog::on_clear_clicked()
ui-dialogStatus-setText(Remote devices list was cleaned.);
ui-discoveredDevicesList-clear();
ui-save-setEnabled(false);
+
+ if (remoteDeviceDiscoveryAgent-isActive()) {
+ // Stop the SDP agent if the clear button is pressed and enable the Scan button
+ remoteDeviceDiscoveryAgent-stop();
+ ui-scan-setEnabled(true);
+ }
}
void BtDeviceSelectionDialog::on_scan_clicked()
--
2.1.4
From 6a7329188804d14a580840e55e87e207c9f8d1e1 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Fri, 17 Jul 2015 01:21:49 +0300
Subject: [PATCH 2/8] Use itemClicked signal instead of itemActivated for BT
device selection
On Android platforms the system is configured to raise the
itemActivated signal when the user double clicks an item.
Since the items are small it is pretty hard to double click
them. Therefore use the itemClicked signal instead of the
itemActivated signal.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 6 +++---
qt-ui/btdeviceselectiondialog.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 6a2a977..b81b1f3 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -29,8 +29,8 @@ BtDeviceSelectionDialog::BtDeviceSelectionDialog(QWidget *parent) :
// Disable the save button because there is no device selected
ui-save-setEnabled(false);
- connect(ui-discoveredDevicesList, SIGNAL(itemActivated(QListWidgetItem*)),
- this, SLOT
Re: [PATCH] Bluetooth support for Android
And that's where it went wrong. They wouldn't pair. The Petrel says bt init fail. I'm off to work now. Might get a chance this evening to work out pairing. This is strange. Do you have other smart device (with Android/iOS) where you can try the pairing step? It could be a problem with the firmware. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth support for Android
The scan works, and scrolling across tells me that it knows the Petrel is paired. But the save button is greyed out so quit is the only way I can leave this dialog. I observed that when you select an item the signal is not always raised (QListWidget::itemActivated). Probably on Android platforms the system is configured to raise the event when the user double clicks the item. Maybe it would be a good idea to use itemClicked signal instead of itemActivated. Meanwhile please try to double click the item. Sorry for the inconvenience :). Now it crashes - presumably because I couldn't select my Petrel. Yes, it crashes because the address of your device wasn't saved and it tries to use the native serial implementation. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth support for Android
It works fine if it's still in scanning mode. The only thing delaying me is that it's really difficult to double click a little item in a list on a phone screen. Or I have fat fingers. Hmm..then I have to figure out if there is a problem with Android 5.1.1 or with my HW dive computers. I know that it is annoying to double click on that little items. In the beginning I had some problems to understand why the Save button is not activated on item selection. I will use the itemClicked signal to fix this issue. Thanks for your help, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth support for Android
That's brilliant. It works! Screenshot attached. Well nearly. The ok button is off the screen so I can't save them. Great :-). It works when you wait for the scanning process to end or it doesn't matter? And yes, currently not all buttons are on the screen. I changed the UI only for the download one. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth support for Android
I'm sure it's possible, but I couldn't work it out in the 3 minutes I tried while brushing my teeth before I left late for work (a little bike race is keeping me up late, so getting up in the morning is a bit harder). I'll try again this evening, and if that fails I'll check I can pair my phone to my tv and computer. Ok, thanks. Let me know if I can help you with other information. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth support for Android
Hi Thiago, Is this method supposed to work elsewhere too? Is there a reason not to use it everywhere? This method should work on every supported platforms but I cannot obtain the correct result using it on Linux. I mentioned before that I believe there is a bug on the QtBluetooth library because when I start a full SDP discovery agent I cannot find the SPP service from my HW OSTCs device. The same thing happened on Rick's environment with his Petrel2 device. I sent some e-mails on the qt-interest list but I didn't receive any response to the last one. That is why I decided to use directly the port number on Linux platforms. It would be interesting to test whether this happens on other Android devices too, especially those using BlueZ instead of Bluedroid. I tested the application on two different devices (Nexus 5 and Nexus 8) but unfortunately both have the same Android version (5.1.1). If I don't wait for the scanning process to finish, the download gets stuck. Also I tried to install the application on a device with Android 4.3 but I cannot use any buttons and cannot access the one with the Import functionalities. You can find some links with two screenshots([1], [2]) from Android 4.3 and one from Android 5.1.1 [3]. I don't know why, but on Android 4.3 the header is missing. I am not sure how the Bluetooth will work with the Android Emulator tool and I don't know how to test if this issue persists on Android versions with BlueZ stack. By the way, the pair/unpair functionalities are not available on Android because we cannot access the context menu :). I will change the UI after I will finish the support for Windows platforms. What's the use for this? How likely is answering in 20 seconds when in 5 it didn't answer? If 25 seconds is better, why not always wait for 25 seconds? If the device is in Connecting state or in ServiceLookUp it means that the connection step took more than expected and maybe we should give it another try and wait longer. This can happen when it is the first time when you try to connect to that device. I didn't want to always wait for 25 seconds because if somehow the Bluetooth from the dive computer was stopped before I started the download, then the application can freeze for 25 seconds. Therefore I decided to let a timeout for 5 seconds to receive a feedback from the remote BT device. If I don't receive anything it means that there is something wrong with the device. These values are not final and we can make them smaller. Please add a simple comment to the source code why this is done, in addition to the commit. Something like // on Android, the device gets stuck in if we try to use it before discovery is done I will do that. Thanks for the feedback! Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth support for Android
It's July. Alex may be on his 4-week vacation. Ping him again next week to see if he's back. Ok, thanks for the info! Then I will wait for Alex to finish his vacation and I will welcome him with some potential bugs on QtBluetooth library:-). ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Bluetooth support for Android
Hi there,
I attached some patches which can be used to fix the issues
related to Bluetooth connectivity on Android platforms.
On Android, a connection to a service cannot be established
using a port. The first patch should fix this issue using the uuid
of the SPP service on the connection step.
On my device with a Android 5.1.1 I observed that if I start the
download process without waiting for the scanning process to
end, then the devices gets stuck after downloading a few
packages. I did over 20 tests for both my dive computers
(HW OSTC2 and HW OSTCs) and I got the same results.
I looked over the Android logs using the logcat tool and I saw
that the download mode always gets stuck when the scanning
process is stopped. I am not sure if this is a bug on the Android
platform, or on the Qt framework.
You can find some logs below.
For the moment I created a patch which blocks the save
button until the scanning process is finished.
Best wishes,
Claudiu
[ 07-13 21:24:09.687 11588:11772 D/Subsurface ]
(null):0 ((null)): [SUBSURFACE] read 1024
[ 07-13 21:24:09.837 11588:11772 D/Subsurface ]
(null):0 ((null)): [SUBSURFACE] successfully read 1024
[ 07-13 21:24:09.837 11588:11772 D/Subsurface ]
(null):0 ((null)): [SUBSURFACE] read 1024
[ 07-13 21:24:10.064 11588:11772 D/Subsurface ]
(null):0 ((null)): [SUBSURFACE] successfully read 1024
[ 07-13 21:24:10.064 11588:11772 D/Subsurface ]
(null):0 ((null)): [SUBSURFACE] read 1024
[ 07-13 21:24:10.359 11588:11772 D/Subsurface ]
(null):0 ((null)): [SUBSURFACE] successfully read 1024
[ 07-13 21:24:10.359 11588:11772 D/Subsurface ]
(null):0 ((null)): [SUBSURFACE] read 1024
[ 07-13 21:24:10.567 11588:11630 D/BluetoothAdapter ]
stopLeScan()
[ 07-13 21:24:10.577 2427: 2489 D/BtGatt.GattService ]
stopScan() - queue size =1
[ 07-13 21:24:10.578 2427: 2501 D/BtGatt.ScanManager ]
stop scan
[ 07-13 21:24:10.582 2427: 2501 D/BtGatt.ScanManager ]
configureRegularScanParams() - queue=0
[ 07-13 21:24:10.582 2427: 2501 D/BtGatt.ScanManager ]
configureRegularScanParams() - ScanSetting Scan mode=-2147483648
mLastConfiguredScanSetting=2
[ 07-13 21:24:10.582 2427: 2501 D/BtGatt.ScanManager ]
configureRegularScanParams() - queue emtpy, scan stopped
[ 07-13 21:24:10.593 2427: 2443 D/BtGatt.GattService ]
unregisterClient() - clientIf=5
From d66fad97993323ba3ed422e624cab47d7fe799f5 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Mon, 13 Jul 2015 23:37:49 +0300
Subject: [PATCH 1/2] Use SPP's uuid to connect to a device on Android platform
On Android, a Bluetooth connection to a service cannot be
established using a port. Therefore we use the uuid of the
Serial Port Profile service to connect to the remote BT
device.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qtserialbluetooth.cpp | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/qtserialbluetooth.cpp b/qtserialbluetooth.cpp
index f06f24e..95f3611 100644
--- a/qtserialbluetooth.cpp
+++ b/qtserialbluetooth.cpp
@@ -54,6 +54,7 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev
timer.setSingleShot(true);
loop.connect(timer, SIGNAL(timeout()), SLOT(quit()));
+#if defined(Q_OS_LINUX) !defined(Q_OS_ANDROID)
// First try to connect on RFCOMM channel 1. This is the default channel for most devices
QBluetoothAddress remoteDeviceAddress(devaddr);
serial_port-socket-connectToService(remoteDeviceAddress, 1);
@@ -79,8 +80,22 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev
loop.exec();
}
}
+#elif defined(Q_OS_ANDROID)
+ // Try to connect to the device using the uuid of the Serial Port Profile service
+ QBluetoothAddress remoteDeviceAddress(devaddr);
+ serial_port-socket-connectToService(remoteDeviceAddress, QBluetoothUuid(QBluetoothUuid::SerialPort));
+ timer.start(msec);
+ loop.exec();
- if (serial_port-socket-socketDescriptor() == -1 || serial_port-socket-state() != QBluetoothSocket::ConnectedState) {
+ if (serial_port-socket-state() == QBluetoothSocket::ConnectingState ||
+ serial_port-socket-state() == QBluetoothSocket::ServiceLookupState) {
+ // It seems that the connection step took more than expected. Wait another 20 seconds.
+ qDebug() The connection step took more than expected. Wait another 20 seconds;
+ timer.start(4 * msec);
+ loop.exec();
+ }
+#endif
+ if (serial_port-socket-state() != QBluetoothSocket::ConnectedState) {
free (serial_port);
// Get the latest error and try to match it with one from libdivecomputer
--
2.1.4
From b535e9137bdcd67b9f92f097cc91a9961fb1a98d Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Mon, 13 Jul 2015 23:44:09 +0300
Subject: [PATCH 2/2] Wait until the BT scanning process is done on Android
platforms
Block the Save button on Android platforms until the scanning
for remote Bluetooth devices is finished.
The reason we do that is because there is a bug
[GSoC] Week 7 (Native Bluetooth support)
Hello, Here is a resume about the things I did this week: - successfully downloaded the dives from 3 different environments (ArchLinux, Fedora 22, OpenSuse 13.2) - compiled and tested our custom BT serial implementation with the new Qt 5.5.0 - compiled and tested our custom BT serial implementation for Android platform - fixed the connectivity issues for Android platform (I will send you a patch tomorrow) - started the documentation for Windows support and started working on a prototype For the next week I want to finish documentation and the prototype to see what functionalities I can cover with Microsoft Bluetooth stack. Have a nice week, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
In my mind, a error message that says: This should never happen and it happens in a number of cases isn't a great message =) I know that the message is ambiguous. It appears when the QtBluetooth library cannot communicate with your local Bluetooth device. The reason why it cannot communicate with the device is not exposed by the framework. If the qtbluetooth library was installed correctly and you can control your BT device using BlueZ tools, then this message should never appear. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
Thanks, Claudiu... this is looking promising. Thanks for the great news, Dirk. Now we need to figure out what's going on on Mac. I am not sure how I can help you with this. I don't have a Mac device. I could try to install OSx on a virtual machine. Or I could start to investigate the Microsoft Bluetooth stack and make a plan for the second stage of the project. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
I managed to compile the project with Qt5.5.0. I saw that Bluetooth connectivity doesn't work for the moment with this version. I will investigate it tomorrow. I just wanted to let you know that I managed to successfully download the dives from both devices using our custom BT serial implementation and Qt 5.5.0 (on VM with Fedora 22). I don't know why but there are moments when the connection step gets stuck (for both Qt 5.5.0 and Qt 5.4.2 versions and both virtual machines - ArchLinux and Fedora). I believe that there is something wrong with the virtualization layer. If I go on my native OS (Windows 8.1), do some Bluetooth pair/unpair commands, go back on my VM, do again the pair/unpair commands and finally try to download the dives, it works. Dirk, maybe you should try to do that on your Mac. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
The only way you're allowed to run OS X in a VM is if you have genuine Apple hardware, which usually implies you've already got access to OS X in real hardware anyway... I didn't know that. Thanks for the info! Is it ok with you if I start the documentation for the second stage of the project (Bluetooth support for Windows platforms)? ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
W/Subsurface(17379): (null):0 ((null)): qt.bluetooth: Connecting to port is not supported D/Subsurface(17379): (null):0 ((null)): Connection on channel 1 failed. Trying on channel number 5. W/Subsurface(17379): (null):0 ((null)): qt.bluetooth: Connecting to port is not supported D/Subsurface(17379): (null):0 ((null)): Failed to connect to device 00:12:6F:38:3D:8A . Device state QBluetoothSocket::UnconnectedState . Error: QBluetoothSocket::ServiceNotFoundError Thanks for the help! I am aware of that. On Android a connection to a service can not be established using a port. We should use the UUID of the SPP service. Currently there are some problems with the SDP discovery service and I decided to remove that part from our implementation. I will update the code to use the uuid of the Serial Port Profile on Android platforms. It would be useful if you can send me the patch which fixes the Android build environment. Thanks, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
Due to that broken device i got a: This should never happen, please contact the Subsurface developers ... By the way, this error is usually generated when the Bluetooth service is not started or when the Qt framework cannot communicate with your local BT device (the library is not installed correctly or the dbus communication is not working). Try to see if you can control your Bluetooth device using bluetoothctl tool. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
It would be great if there was a way to switch to using another bt device on your host. I started working on it but I haven't had the chance to finish it. Another thing i thought about was (re)using your bt-libdc thingie in the Configure Dive computers dialog there. It would be great if one could change settings in the devices and to be able to upgrade the firmware over native bluetooth. I think that would be a great bonus task =) Yes, you are right. It would be great if the user will be able to upgrade his firmware or to change settings in the device. I thought about it but I decided to postpone until I finish the data transfer on Windows platforms. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
Hi, I wanted to let you know that after I did the firmware upgrade everything works fine. I tested both devices on all three environments (OpenSuse, Fedora, ArchLinux) and I didn't encounter any problem. Now we just have to figure out why Dirk's devices don't work. Dirk, do you have other environment on which you can run the tests? Thiago, do you have a dive computer with Bluetooth support? Do you believe that you can help me with some tests? Thanks, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
Sorry, my mistake! Somehow I deleted the qtserialbluetooth.cpp source from SUBSURFACE_CORE_LIB_SRCS list :-). I managed to compile the project with Qt5.5.0. I saw that Bluetooth connectivity doesn't work for the moment with this version. I will investigate it tomorrow. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
Hi Thiago, + bool on = !(mode == QBluetoothLocalDevice::HostPoweredOff); That's slightly weird :-) I know that this is weird but there is no HostPoweredOn enum :-). It can be either off, connectable, discoverable or discoverable limited inquiry. Therefore I choose to use !(mode == QBluetoothLocalDevice::HostPoweredOff)) instead of (mode == QBluetoothLocalDevice::HostDiscoverable || mode == QBluetoothLocalDevice::HostConnectable || ..) Hint: QString has a multiarg arg that works on QStrings and is slightly faster. If you remember, please use it next time. Hint: please use the Qt API for the containers. I had to look up to see if the empty() function was a getter of the emptiness state or whether it emptied the container. Thanks for your feedback! I will keep in mind what you said. This is the first time I work with Qt framework and obviously I have a lot to learn. Cheers, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
Oh yeah :). I don't know what was in my mind when I did that :)). On Tue, Jul 7, 2015 at 12:02 AM, Thiago Macieira thi...@macieira.org wrote: On Monday 06 July 2015 23:19:58 Claudiu Olteanu wrote: + bool on = !(mode == QBluetoothLocalDevice::HostPoweredOff); That's slightly weird :-) I know that this is weird but there is no HostPoweredOn enum :-). It can be either off, connectable, discoverable or discoverable limited inquiry. Therefore I choose to use !(mode == QBluetoothLocalDevice::HostPoweredOff)) instead of (mode == QBluetoothLocalDevice::HostDiscoverable || mode == QBluetoothLocalDevice::HostConnectable || ..) I meant doing bool on = !(x == y); instead of bool on = x != y; -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
Actually, here's one. The fake open function for the OSTC 2N. That could have been its own commit, added before the next commit that adds all the qtserialbluetooth stuff. That's a simple example, but maybe it illustrates what I mean. It is funny that in the beginning I did an isolated commit for that. In the end I thought that it would be better to separate the patches in three groups: - changes on the current UI - implementation of the selection dialog - implementation of our custom serial communication I know that some of them contain too many lines of code but I thought that it would be easier to group them by their main scope. I won't ask you to refactor the commits because I don't think there's anything wrong in what you did. Just something to look into for the future. I will try to use a high degree of granularity for the commits in the future. Thanks for your feedback! Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PULL REQUEST] libdivecomputer - Subsurface-testing branch
Hi,
These patches create a generic way to represent any type of serial
communication. They are used to create a custom serial implementation
for HW_OSTC3 and SHEARWATER families.
Claudiu
From 05d830371f2bce35820bebb7419ed27946b3a658 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sat, 27 Jun 2015 15:11:15 +0300
Subject: [PATCH 1/7] Extend the transport enum descriptor for serial
communication
Add a new transport type which can be used to identify
Bluetooth serial communication.
Signed-off-by Claudiu Oleanu olteanu.clau...@ymail.com
---
include/libdivecomputer/descriptor.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/libdivecomputer/descriptor.h b/include/libdivecomputer/descriptor.h
index 6f9735d..f1c815d 100644
--- a/include/libdivecomputer/descriptor.h
+++ b/include/libdivecomputer/descriptor.h
@@ -33,7 +33,8 @@ typedef enum dc_transport_t {
DC_TRANSPORT_NONE,
DC_TRANSPORT_SERIAL,
DC_TRANSPORT_USB,
- DC_TRANSPORT_IRDA
+ DC_TRANSPORT_IRDA,
+ DC_TRANSPORT_BLUETOOTH
} dc_transport_t;
typedef struct dc_descriptor_t dc_descriptor_t;
--
2.1.4
From b4092f3b4b04f9b31097f6c79b2e1cdafcaf5a06 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sat, 27 Jun 2015 15:14:16 +0300
Subject: [PATCH 2/7] Create a generic way to represent any type of serial
communication
Add a structure which holds references to basic operations
on a serial communication. This can be used to pass a set
of function pointer callbacks in order to create a custom
implementation for serial communication.
Add a generic structure to represent the needed information
for a serial communication.
Implement the initialization method where the user can
pass a set of function pointer callbacks and set some
custom data for the serial device.
Create open method for the native serial implementation.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
include/libdivecomputer/Makefile.am | 3 +-
include/libdivecomputer/custom_serial.h | 63 ++
src/Makefile.am | 3 +-
src/custom_serial.c | 79 +
4 files changed, 146 insertions(+), 2 deletions(-)
create mode 100644 include/libdivecomputer/custom_serial.h
create mode 100644 src/custom_serial.c
diff --git a/include/libdivecomputer/Makefile.am b/include/libdivecomputer/Makefile.am
index 71887d5..a0ed196 100644
--- a/include/libdivecomputer/Makefile.am
+++ b/include/libdivecomputer/Makefile.am
@@ -53,4 +53,5 @@ libdivecomputer_HEADERS = \
citizen.h \
citizen_aqualand.h \
divesystem.h \
- divesystem_idive.h
+ divesystem_idive.h \
+ custom_serial.h
diff --git a/include/libdivecomputer/custom_serial.h b/include/libdivecomputer/custom_serial.h
new file mode 100644
index 000..a52d49b
--- /dev/null
+++ b/include/libdivecomputer/custom_serial.h
@@ -0,0 +1,63 @@
+/*
+ * libdivecomputer
+ *
+ * Copyright (C) 2015 Claudiu Olteanu
+ * base on code that is Copyright (C) 2008 Jef Driesen
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#ifndef CUSTOM_SERIAL_H
+#define CUSTOM_SERIAL_H
+
+#include string.h
+#include stdlib.h
+
+#include context.h
+#include descriptor.h
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+typedef struct serial_t serial_t;
+
+typedef struct dc_serial_operations_t
+{
+ int (*open) (serial_t **device, dc_context_t *context, const char *name);
+ int (*close) (serial_t *device);
+ int (*read) (serial_t *device, void* data, unsigned int size);
+ int (*write) (serial_t *device, const void* data, unsigned int size);
+ int (*flush) (serial_t *device, int queue);
+ int (*get_received) (serial_t *device);
+ int (*get_transmitted) (serial_t *device);
+} dc_serial_operations_t;
+
+typedef struct dc_serial_t {
+ serial_t *port;//serial device port
+ dc_transport_t type; //the type of the transport (USB, SERIAL, IRDA, BLUETOOTH)
+ void *data;//specific data for serial device
+ const dc_serial_operations_t *ops; //reference to a custom set of operations
+} dc_serial_t;
+
+void dc_serial_init(dc_serial_t *device, void *data, const dc_serial_operations_t *ops);
+
+dc_status_t dc_serial_native_open(dc_serial_t **serial, dc_context_t *context, const
Re: [PULL REQUEST] libdivecomputer - Subsurface-testing branch
Hi Lubomir, Thanks for the info! Yeah, probably I shouldn't named the thread PULL REQUEST. Since these are the differences between my repository and the Subsurface' one, I thought that the process is similar with a pull request. Also I knew that Dirk prefers patches instead of pull requests. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[GSoC] Week 6 (Native Bluetooth support)
Hi there, I spent this week doing some tests to find out the possible reasons of some issues: - first the QtSocketBluetooth::connectToService(address, uuid, mode) doesn't work as expected. On some devices, the SPP profile is never found. - second on some environments the connection takes too long when I use my second device (HW OSTC2) and the timeout event is raised Besides my OpenSuse distribution (BlueZ 5.30 and Qt 5.4.1) I created two new environments: - Fedora 22 : Bluez 5.29 and Qt 5.4.2 - ArchLinux 2015.07.01 : BlueZ 5.31 and Qt 5.4.2 Regarding the first issue I did some investigations and I started to talk with the maintainer of QtBluetooth API. He said that it could be a bug in the library and I provided him some extra information. Now I am waiting for his feedback. To be honest, I am a little stuck with the second problem. My HW OSTC Sport device works on all environments while the OSTC 2 model doesn't. On the OpenSuse environment there are moments when I successfully connect to the device and initiate the data transfer mode and moments when it gets stuck in the Connecting state. On the other two environments the device always gets stuck on the connecting state. Now I don't know what to do next and how to tackle the problem. I did everything I had in mind (extended the timeout, verified that the date of the device is set correctly, looked over the HCI logs and see what could be wrong, tried to use directly the RFCOMM 1 channel). Have a nice week, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
I forgot to specify that the Fedora 22 and ArchLinux environments are two virtual machines. I don't know if this could cause the problem. If it does, I expect that it shouldn't work with the HW OSTCs device as well. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
I tried your patch, and it works. But it works by falling back (after a delay) to channel 5. To confirm, I commented out the fallback conditions, so it only tried the uuid method, and that fails. Thanks again! It is quite strange why the QBluetoothServiceDiscoveryAgent doesn't find the SPP service. On my HW OSTC2 device there are moments when the SDP search ends with no results and moments when it finds the SPP service. All happens randomly and I couldn't find a pattern. There might be someone on this list with more Qt and/or bluetooth knowledge that could help. Otherwise, I'm sure there'll be a Qtconnectivity mailing list or forum you could try. I have sent an e-mail on the qt-interest mailing list about this issue and to the maintainer of the Qt Bluetooth API. I will let you know if I will receive an answer. I suspect the 5s delay could be reduced, but I don't know what to. I didn't know how small to make the delay. I know that it is frustrating to wait more than 10 seconds to connect to the Petrel 2 device. I hope that the issue with the SDP search will be fixed soon and the delay will not be a problem anymore. Have a nice weekend, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
So it seems that all Petrel 2 use channel 5. At which stage do we need to know the correct channel? Do we have the name of the device at that stage already? No, we don't have the name of the device at that stage. The only information we have is its Bluetooth address. As I said, if the Qt SDP discovery service will work properly, then we can easily use QtBluetoothSocket::connectToService method with the uuid of the Serial Port Profile. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
Hi, The thing is that when I try to connect to a device I use the UUID of the serial port profile. It shouldn't matter if the service is listening on a different channel because in backgorund it should execute a sdp query. It could be a problem from the framework or maybe there is something that I am missing. I will try to investigate this. For the moment if the connection fails, I will try to make a new one using the RFCOMM channel number 5. In this way, the user doesn't need to specify which model of Petrel device he uses. Also, I will keep in mind your suggestions about the UI and I will improve it in the end, when the bluetooth download mode works as expected on all platforms. Thanks for your help, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
Assuming it's similar to setting up a connection on the command line with rfcomm, I think most devices use channel 0, not 1. I can't test this because mine uses channel 5. Can you try both 0 and 1 with the OSTC, and see if one works and the other doesn't? I could be wrong, but as far as I know the RFCOMM channels can be in interval [1, 30]. I tested it just to be sure and if I set the channel to 0 it doesn't work. Have a nice day, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
Hello, I can't claim to know how it works, but it appears that on my system at least, QBluetoothUuid::SerialPort is being treated as the port number, rather than the UUID. To test my theory, I tried using QBluetoothUuid::TcsBin, and it worked. Clearly it shouldn't, except that the value of TcsBin is 0x005 (http://doc.qt.io/qt-5/qbluetoothuuid.html), and my dive computer uses channel 5. I don't know if the syntax is wrong, or if this is a bug in qtconnectivity (5.4.1 on Fedora 22). Damn! This is my mistake. I forgot to create an instance of a QBluetoothUuid object and I used directly the enum. Therefore, the second parameter was considered to be the port . Thanks for your help, Rick! I couldn't figure it out without you. I will send you an appropriate patch soon. Now I have to see why he doesn't find the Serial Port Profile service. :) Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
I attached a patch which should resolve the issues regarding
the connection.
I know that this is not the ideal solution but I wanted to cover all cases.
First I try to make a connection using the UUID of a service.
If the timer expires and the device is in the ServiceLookupState, then
I extend the waiting time.
If the connection ends with a ServiceNotFoundError then I try to force
the connection on channel 1. If this doesn't work, I try again on channel
number 5.
I took this decision because the QBluetoothServiceDiscoveryAgent
cannot find the SPP service from my HW OSTCs device. I don't know
why. I captured the HCI events during the Qt service discovery proces
and they are identical with the ones raised by sdptool.
The interesting thing is that when I use my HW OSTC 2 device, the SPP
service is discovered.
If you want I can remove the part where it tries to initiate a connection
using SPP's uuid. I can try to make a connection on channel 1 and if
it fails I try again on channel number 5. This would work if the SPP
service is always listening on channel 1 or on channel 5.
Cheers,
Claudiu
From 18edac581b3d3f3bb4221f627d4751f5db55d904 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Wed, 1 Jul 2015 01:50:12 +0300
Subject: [PATCH 4/4] Add different attemtps for Bluetooth connection
First try to make a connection using the UUID of a service.
If the timer expires and the device is in the ServiceLookupState,
then extend the waiting time.
If the connection ends with a ServiceNotFoundError then try to
force the connection on channel 1. If this doesn't work, try again
on channel number 5.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qtserialbluetooth.cpp | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/qtserialbluetooth.cpp b/qtserialbluetooth.cpp
index 329907b..d56f5fd 100644
--- a/qtserialbluetooth.cpp
+++ b/qtserialbluetooth.cpp
@@ -4,6 +4,7 @@
#include QtBluetooth/QBluetoothSocket
#include QEventLoop
#include QTimer
+#include QDebug
#include libdivecomputer/custom_serial.h
@@ -45,14 +46,40 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev
// Create a timer. If the connection doesn't succeed after five seconds or no error occurs then stop the opening step
QTimer timer;
+ int msec = 5000;
timer.setSingleShot(true);
loop.connect(timer, SIGNAL(timeout()), SLOT(quit()));
// Try to connect to the Serial Port Profile service
- serial_port-socket-connectToService(QBluetoothAddress(devaddr), QBluetoothUuid::SerialPort);
- timer.start(5000);
+ QBluetoothAddress remoteDeviceAddress(devaddr);
+ serial_port-socket-connectToService(remoteDeviceAddress, QBluetoothUuid(QBluetoothUuid::SerialPort));
+ timer.start(msec);
loop.exec();
+ if (serial_port-socket-state() == QBluetoothSocket::ServiceLookupState) {
+ // It seems that the lookup for Serial Port profile took more than expected. Take a beer and wait another 20 seconds :)
+ qDebug() The lookup service took more than expected. Wait another 20 seconds.;
+ timer.start(4 * msec);
+ loop.exec();
+ }
+
+ if (serial_port-socket-error() == QBluetoothSocket::ServiceNotFoundError) {
+ // If Serial Port Profile wasn't found by the discovery agent try to connect to channel number 1.
+ // Most devices uses this port for the Serial Port Profile service.
+ qDebug() Didn't find the Serial Port Profile. Trying to connect to channel number 1.;
+ serial_port-socket-connectToService(remoteDeviceAddress, 1);
+ timer.start(msec);
+ loop.exec();
+
+ if (serial_port-socket-state() != QBluetoothSocket::ConnectedState) {
+ // Try to connect on channel number 5. Maybe this is a Shearwater Petrel2 device.
+ qDebug() Connection on channel 1 failed. Trying on channel number 5.;
+ serial_port-socket-connectToService(remoteDeviceAddress, 5);
+ timer.start(msec);
+ loop.exec();
+ }
+ }
+
if (serial_port-socket-socketDescriptor() == -1 || serial_port-socket-state() != QBluetoothSocket::ConnectedState) {
free (serial_port);
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
I've tested your patches, and your work looks great!
Hi Rick,
First of all, thanks a lot for your help! It helps me a lot to know that
it worked for a device that I didn't have the chance to test personally.
It gives me hope that I am on the right track.
To test a bit more, I unpaired my dive computer through the KDE Bluetooth
system tray thing, and tried to pair it again through the Bluetooth dialog
in Subsurface. I have to admit that right-clicking and choosing pair
seemed less than intuitive, but it worked flawlessly. I did not need to
use bluetoothctl. Downloading dives again 'worked', except there were no
new dives after downloading everything previously, so nothing was
downloaded.
To be honest I don't have too much experience with the UI/UX. I though
that usually when an user wants to execute an action on a specific item,
he just uses the right button click and he selects the action from a
context menu. If you have other suggestions, please let me know.
Can you do a similar query through qtbluetooth? Or perhaps try channel
zero first (should work for OSTC computers, Shearwater Predator and Petrel
v1), if that fails, try channel 5. I'm only aware of dive computers using
those two channels, but you could try brute force after that.
I suspect that this is caused by the timer which after 5 seconds
without a feedback will stop the connecting process. This is just a
speculation but I believe that the device starts to interrogate each
channel (incrementally) and searches for the UUID of the required
service. It is possible that if the Serial Port Profile is available on
channel 5, the connection needs more time to succeeds.
Therefore, do you think that you can apply the attached patch and
try again? First remove the patch number 5 and then apply this one.
This patch increases the timeout from 5 seconds to 20. If the timeout
signal is raised and the device is in lookup service state, then it waits
another 30 seconds. I just want to eliminate this possibility.
As further testing, I also tried using the Bluetooth dongle that came with
the Petrel 2. The dialog in Subsurface only recognized the onboard
Bluetooth device, i.e. hci0, even when I used hciconfig to turn hci0 off
and hci1 on. I'm guessing you know this.
Yes, I am aware of this. The thing is that your onboard Bluetooth
device is set as default. If you set the Bluetooth dongle as default,
then it will be used in the Subsurface dialog. I will make a drop-down
list where the user can select which local Bluetooth device he
wants to use.
Best wishes,
Claudiu
From 47c3787ac376c608737eb56e66601469e2c21bfe Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Mon, 29 Jun 2015 20:46:32 +0300
Subject: [PATCH 4/4] Increase the waiting time for Bluetooth LookUpSevice
If the lookup for Serial Port profile took more than expected
then wait another 30 seconds.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qtserialbluetooth.cpp | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/qtserialbluetooth.cpp b/qtserialbluetooth.cpp
index 329907b..62a 100644
--- a/qtserialbluetooth.cpp
+++ b/qtserialbluetooth.cpp
@@ -4,6 +4,7 @@
#include QtBluetooth/QBluetoothSocket
#include QEventLoop
#include QTimer
+#include QDebug
#include libdivecomputer/custom_serial.h
@@ -43,16 +44,23 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev
loop.connect(serial_port-socket, SIGNAL(connected()), SLOT(quit()));
loop.connect(serial_port-socket, SIGNAL(error(QBluetoothSocket::SocketError)), SLOT(quit()));
- // Create a timer. If the connection doesn't succeed after five seconds or no error occurs then stop the opening step
+ // Create a timer. If the connection doesn't succeed after 20 seconds or no error occurs then stop the opening step
QTimer timer;
timer.setSingleShot(true);
loop.connect(timer, SIGNAL(timeout()), SLOT(quit()));
// Try to connect to the Serial Port Profile service
serial_port-socket-connectToService(QBluetoothAddress(devaddr), QBluetoothUuid::SerialPort);
- timer.start(5000);
+ timer.start(2);
loop.exec();
+ if (serial_port-socket-state() == QBluetoothSocket::ServiceLookupState) {
+ // It seems that the lookup for Serial Port profile took more than expected. Take a beer and wait another 30 seconds :)
+ qDebug() The lookup serice took more than expected. Wait another 30 seconds.;
+ timer.start(3);
+ loop.exec();
+ }
+
if (serial_port-socket-socketDescriptor() == -1 || serial_port-socket-state() != QBluetoothSocket::ConnectedState) {
free (serial_port);
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] libdivecomputer - custom implementation for serial communication
Hello Jef,
Thanks for making time to let us know what you
have in mind for the next release. More or less it is
similar with the changes I made, except that I tried
to avoid to modify the native serial implementation.
I will make you a short resume about the changes
I did because I believe that there were too many
posts and it is not easy to keep the track.
The dc_serial_t structure is declared as:
struct dc_serial_t {
serial_t *port; //serial device port
dc_transport_t type; //the type of the transport (USB, SERIAL, IRDA,
BLUETOOTH)
void *data; //specific data for serial device
const dc_serial_operations_t *ops; //reference to a custom set of operations
} dc_serial_t;
As you can see, the only difference is that I
added a new member (dc_transport_type).
I thought that this can be used to identify the
type of the transport and to do some specific
operations if they are needed.
Also I used a pointer member for serial_t.
Dirk suggested to remove the pointer but
it was easier for me to use it :).
I choose to represent all functions which are
used for the communication and may need
a custom implementation, depending on the
protocol used (Bluetooth, IRDA, etc).
The dc_serial_operations_t is:
struct dc_serial_operations_t
{
int (*open) (serial_t **device, dc_context_t *context, const char *name);
int (*close) (serial_t *device);
int (*read) (serial_t *device, void* data, unsigned int size);
int (*write) (serial_t *device, const void* data, unsigned int size);
int (*flush) (serial_t *device, int queue);
int (*get_received) (serial_t *device);
int (*get_transmitted) (serial_t *device);
} dc_serial_operations_t;
As I said, I tried to avoid modifications on
native serial implementation. Therefore I used
the same signatures for needed functions.
I preferred to do that because I wanted to keep
backwards compatibility and to do as few changes
as possible. So I created a dc_device_custom_open
method where the application can pass a reference
to a dc_serial_t structure.
Also I added a dc_serial_native_open which
creates a dc_serial_t structure for the
native serial implementation. In this way I could
use it in the DEVICE_FAMILY_device_open
method and maintain the backwards compatibility.
It is obvious that you have a clear idea about
how the libdivecomputer API should look
like and which are the things that need to be
refactored/cleaned.
I would definitely like to help you (now or later).
Dirk, Thiago, do you think that I should refactor
again the libdivecomputer? Should I change
again the design? Or I should continue my current
work, use the current design for all vendors
which have Bluetooth support, implement the
Bluetooth transfer on Windows platforms and finally
start to modify the design as Jef suggested?
I ask this because in the end the Subsurface
custom serial implementation doesn't need
many changes to be integrated with a new
version of libdivecomputer and with its design.
Also, I already have a functional prototype.
I am not sure how to prioritize things. :)
So please let me know what you think.
Thanks,
Claudiu
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] QtBluetooth implementation
This patch sets a timer for the connecting step.
If the connection doesn't succeed after five seconds or
no error occurs then stop the opening step and exit with failure.
On Sat, Jun 27, 2015 at 4:09 PM, Claudiu Olteanu
olteanu.vasilica.clau...@gmail.com wrote:
In order to make our custom serial implementation to work with the
new dc_serial_t custom design you have to apply the attached patch.
In the end I will create some new patches in order to have a clean branch.
Best wishes,
Claudiu
From faccea72faaa47de119bb4cef7bf0b98f2eed853 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sun, 28 Jun 2015 15:55:15 +0300
Subject: [PATCH 11/11] Add a timer for Bluetooth connecting step
Create a timer for the QEventLoop used in the qt serial bluetooth
openning method. If the connection doesn't succeed after five seconds or
no error occurs then stop the opening step and exit with failure.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qtserialbluetooth.cpp | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/qtserialbluetooth.cpp b/qtserialbluetooth.cpp
index 9c3bf5d..329907b 100644
--- a/qtserialbluetooth.cpp
+++ b/qtserialbluetooth.cpp
@@ -3,6 +3,7 @@
#include QtBluetooth/QBluetoothAddress
#include QtBluetooth/QBluetoothSocket
#include QEventLoop
+#include QTimer
#include libdivecomputer/custom_serial.h
@@ -41,11 +42,18 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev
QEventLoop loop;
loop.connect(serial_port-socket, SIGNAL(connected()), SLOT(quit()));
loop.connect(serial_port-socket, SIGNAL(error(QBluetoothSocket::SocketError)), SLOT(quit()));
+
+ // Create a timer. If the connection doesn't succeed after five seconds or no error occurs then stop the opening step
+ QTimer timer;
+ timer.setSingleShot(true);
+ loop.connect(timer, SIGNAL(timeout()), SLOT(quit()));
+
// Try to connect to the Serial Port Profile service
serial_port-socket-connectToService(QBluetoothAddress(devaddr), QBluetoothUuid::SerialPort);
+ timer.start(5000);
loop.exec();
- if (serial_port-socket-socketDescriptor() == -1) {
+ if (serial_port-socket-socketDescriptor() == -1 || serial_port-socket-state() != QBluetoothSocket::ConnectedState) {
free (serial_port);
// Get the latest error and try to match it with one from libdivecomputer
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: BT support, brief tests
Hi Dirk, I managed to reproduce the bug changing the Bluetooth address saved in the device *QComboBox*. Apparently if you set an incorrect address in that section the *QBluetoothSocket* connect method doesn't raise a *SocketError* and it gets stuck. I added a timer, like you suggested. It raises a timeout signal after 5 seconds and close the qt_serial_open step. I will send you a patch on the [*PATCH] QtBluetooth implementation* thread. I don't know if this will fix your problem. Could you check if the address is set correctly? Thanks, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 5 (Native Bluetooth support)
I think the one other BT device that several of our testers have (including me) is the Shearwater Petrel / Petrel2 Thanks! Then I will start to do the changes for that vendor and I will send you the patches. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
Hello,
I need some help to test if the native serial implementation
works after the changes I did on the libdivecomputer project.
If you have a device from HW_OSTC3 or SHEARWATER families
please take the first 7 patches and apply them on the libdivecomputer
branch.
Unfortunately I don't have a SHEARWATER device so the only think
I did was to make sure that the sources compile after my modifications.
If you have a dive computer with Bluetooth support you can take the
the last 4 patches[*] and apply them on the Subsurface branch.
The Bluetooth support should work on Linux/OS X platforms.
For devices that require a custom PIN code on the pairing
step you should start a keyboard agent. One possible solution is
to use *bluetoothctl* tool and to run the following commands:
*# agent KeyboardOnly*
*# default-agent*
Also it would be useful if you could run the *hcidump *tool in
background.
Please let me know if you have any questions.
Thanks,
Claudiu
[*] Just to be sure that there is no confusion, the following patches
should be applied on Subsurface project:
- 0001-Add-checkbox-and-button-for-Bluetooth-download-mode.patch
- 0002-Add-a-new-dialog-which-can-be-use-to-select-the-Blue.patch
- 0003-Implement-the-custom-Bluetooth-serial-communication-.patch
- 0004-Enable-QtBluetooth-logging.patch
From 05d830371f2bce35820bebb7419ed27946b3a658 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sat, 27 Jun 2015 15:11:15 +0300
Subject: [PATCH 1/7] Extend the transport enum descriptor for serial
communication
Add a new transport type which can be used to identify
Bluetooth serial communication.
Signed-off-by Claudiu Oleanu olteanu.clau...@ymail.com
---
include/libdivecomputer/descriptor.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/libdivecomputer/descriptor.h b/include/libdivecomputer/descriptor.h
index 6f9735d..f1c815d 100644
--- a/include/libdivecomputer/descriptor.h
+++ b/include/libdivecomputer/descriptor.h
@@ -33,7 +33,8 @@ typedef enum dc_transport_t {
DC_TRANSPORT_NONE,
DC_TRANSPORT_SERIAL,
DC_TRANSPORT_USB,
- DC_TRANSPORT_IRDA
+ DC_TRANSPORT_IRDA,
+ DC_TRANSPORT_BLUETOOTH
} dc_transport_t;
typedef struct dc_descriptor_t dc_descriptor_t;
--
2.1.4
From b4092f3b4b04f9b31097f6c79b2e1cdafcaf5a06 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sat, 27 Jun 2015 15:14:16 +0300
Subject: [PATCH 2/7] Create a generic way to represent any type of serial
communication
Add a structure which holds references to basic operations
on a serial communication. This can be used to pass a set
of function pointer callbacks in order to create a custom
implementation for serial communication.
Add a generic structure to represent the needed information
for a serial communication.
Implement the initialization method where the user can
pass a set of function pointer callbacks and set some
custom data for the serial device.
Create open method for the native serial implementation.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
include/libdivecomputer/Makefile.am | 3 +-
include/libdivecomputer/custom_serial.h | 63 ++
src/Makefile.am | 3 +-
src/custom_serial.c | 79 +
4 files changed, 146 insertions(+), 2 deletions(-)
create mode 100644 include/libdivecomputer/custom_serial.h
create mode 100644 src/custom_serial.c
diff --git a/include/libdivecomputer/Makefile.am b/include/libdivecomputer/Makefile.am
index 71887d5..a0ed196 100644
--- a/include/libdivecomputer/Makefile.am
+++ b/include/libdivecomputer/Makefile.am
@@ -53,4 +53,5 @@ libdivecomputer_HEADERS = \
citizen.h \
citizen_aqualand.h \
divesystem.h \
- divesystem_idive.h
+ divesystem_idive.h \
+ custom_serial.h
diff --git a/include/libdivecomputer/custom_serial.h b/include/libdivecomputer/custom_serial.h
new file mode 100644
index 000..a52d49b
--- /dev/null
+++ b/include/libdivecomputer/custom_serial.h
@@ -0,0 +1,63 @@
+/*
+ * libdivecomputer
+ *
+ * Copyright (C) 2015 Claudiu Olteanu
+ * base on code that is Copyright (C) 2008 Jef Driesen
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#ifndef CUSTOM_SERIAL_H
+#define
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
I'll try tonight (Australian time) on Fedora 22. What should the device show up as in the download dialogue? Thanks! I added a checkbox in the download dialogue which can be used to enable the Bluetooth downloading mode. When you activate it a new dialog will be created. You can use it to scan for remote BT devices and to select the one you want to connect to. After you select a device and press the Save button you can start the download process using the old Download button. If you have other questions, please let me know. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
I didn't know that. Thanks for the heads up! In the beginning try to see if it connects to the device using this version. It attempts to make a connection to the Serial Port Profile. Therefore, if the service is listening on RFCOMM channel 5, then it should successfully connect. If not, please apply the attached patch. This is just a temporary solution :). From 664e67fb248dd8fded44ab27d2d0cadaa1a74749 Mon Sep 17 00:00:00 2001 From: Claudiu Olteanu olteanu.clau...@ymail.com Date: Mon, 29 Jun 2015 01:25:13 +0300 Subject: [PATCH 5/5] Use channel 5 for Shearwater Petrel 2 devices This is a temporary solution for Shearwater Petrel 2 devices. Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com --- qtserialbluetooth.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/qtserialbluetooth.cpp b/qtserialbluetooth.cpp index 329907b..f9fae3b 100644 --- a/qtserialbluetooth.cpp +++ b/qtserialbluetooth.cpp @@ -48,8 +48,8 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev timer.setSingleShot(true); loop.connect(timer, SIGNAL(timeout()), SLOT(quit())); - // Try to connect to the Serial Port Profile service - serial_port-socket-connectToService(QBluetoothAddress(devaddr), QBluetoothUuid::SerialPort); + // Try to connect to connect on 5 RFCOMM channel (only for Shearwater Petrel 2 devices) + serial_port-socket-connectToService(QBluetoothAddress(devaddr), 5); timer.start(5000); loop.exec(); -- 2.1.4 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] libdivecomputer - custom implementation for serial communication
Hi there,
I did the modifications we discussed. You can find attached some new
patches. I hope that now they are grouped correctly.
For the moment I updated only the HW_OSTC3 family to use the custom
serial implementation.
These patches can be applied on the origin/Subsurface-testing branch.
Please let me know if the old native serial communication doesn't work
after you apply them.
I will send you a new patch for the Subsurface project to work with the
new design of the *dc_serial_t* structure.
Claudiu
On Fri, Jun 26, 2015 at 11:29 PM, Claudiu Olteanu
olteanu.vasilica.clau...@gmail.com wrote:
One way to do this would be to copy Jef's copyright line and add yours
below:
* Copyright (C) 2008 Jef Driesen
* Copyright (C) 2015 Claudiu Olteanu
Thanks for the information. Now it is more clear for me.
I think that I should remove the fd, timeout and context fields and
to add a serial_t *port member
See what I wrote above. I'm fine with other. I seem to remember that Jef
in general prefers the structures with common parts in front that can
simply be passed around and then work as expected...
This is good to know. I believe that it would be easier to use a pointer
to
a *serial_t* structure since all the functions expect to receive a
pointer.
In the old implementation, all structures which are used to represent
a device contain a member which is a pointer to a *serial_t* structure.
Therefore I believe that this is more in line with the old design.
This feels like it should have been squashed into the first patch...
Yes, you are right. I forgot to add it in the beginning.
As a general rule I do NOT enforce this. I am MUCH happier when people do
small patches and commit often. But since you were reworking the patches
anyway (and will be reworking them to address the data structure issues)
it would be nice to turn commits that clearly are nothing but fixups into
just that (git even has the cool --fixup feature in newer versions...
I didn't know about the --fixup feature. I will take it into consideration
on the
future, when I will create my final patches. Also I intend to submit new
ones,
which doesn't contain fixup commits.
Right now I can't merge this into the Subsurface-testing branch because
most of our testers have USB (or more correctly, serial) based devices.
But once this becomes transparent I can add this and we can get much more
testing.
I totally understand that. I created the patches only to receive some
feedback
from you and to decide on the architecture.
Claudiu
From 05d830371f2bce35820bebb7419ed27946b3a658 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sat, 27 Jun 2015 15:11:15 +0300
Subject: [PATCH 1/5] Extend the transport enum descriptor for serial
communication
Add a new transport type which can be used to identify
Bluetooth serial communication.
Signed-off-by Claudiu Oleanu olteanu.clau...@ymail.com
---
include/libdivecomputer/descriptor.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/libdivecomputer/descriptor.h b/include/libdivecomputer/descriptor.h
index 6f9735d..f1c815d 100644
--- a/include/libdivecomputer/descriptor.h
+++ b/include/libdivecomputer/descriptor.h
@@ -33,7 +33,8 @@ typedef enum dc_transport_t {
DC_TRANSPORT_NONE,
DC_TRANSPORT_SERIAL,
DC_TRANSPORT_USB,
- DC_TRANSPORT_IRDA
+ DC_TRANSPORT_IRDA,
+ DC_TRANSPORT_BLUETOOTH
} dc_transport_t;
typedef struct dc_descriptor_t dc_descriptor_t;
--
2.1.4
From b4092f3b4b04f9b31097f6c79b2e1cdafcaf5a06 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sat, 27 Jun 2015 15:14:16 +0300
Subject: [PATCH 2/5] Create a generic way to represent any type of serial
communication
Add a structure which holds references to basic operations
on a serial communication. This can be used to pass a set
of function pointer callbacks in order to create a custom
implementation for serial communication.
Add a generic structure to represent the needed information
for a serial communication.
Implement the initialization method where the user can
pass a set of function pointer callbacks and set some
custom data for the serial device.
Create open method for the native serial implementation.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
include/libdivecomputer/Makefile.am | 3 +-
include/libdivecomputer/custom_serial.h | 63 ++
src/Makefile.am | 3 +-
src/custom_serial.c | 79 +
4 files changed, 146 insertions(+), 2 deletions(-)
create mode 100644 include/libdivecomputer/custom_serial.h
create mode 100644 src/custom_serial.c
diff --git a/include/libdivecomputer/Makefile.am b/include/libdivecomputer/Makefile.am
index 71887d5..a0ed196 100644
--- a/include/libdivecomputer/Makefile.am
+++ b/include/libdivecomputer/Makefile.am
@@ -53,4 +53,5 @@ libdivecomputer_HEADERS
Re: [PATCH] QtBluetooth implementation
In order to make our custom serial implementation to work with the
new dc_serial_t custom design you have to apply the attached patch.
In the end I will create some new patches in order to have a clean branch.
Best wishes,
Claudiu
From e42bcde1b96b2f0cd01812a946b8dfc587ee1709 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Sat, 27 Jun 2015 15:34:09 +0300
Subject: [PATCH 10/10] Update the QtBluetooth serial implementation to work
with the the dc_serial_t structure
This is a temporary patch.
The patch updates the message that is displayed when the local Bluetooth
device cannot be accessed, fixes the return check from qt_serial_open
method and uses the new dc_serial_t structure.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/btdeviceselectiondialog.cpp | 3 ++-
qtserialbluetooth.cpp | 36 +---
2 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/qt-ui/btdeviceselectiondialog.cpp b/qt-ui/btdeviceselectiondialog.cpp
index 49f8f58..e0daa45 100644
--- a/qt-ui/btdeviceselectiondialog.cpp
+++ b/qt-ui/btdeviceselectiondialog.cpp
@@ -14,7 +14,8 @@ BtDeviceSelectionDialog::BtDeviceSelectionDialog(QWidget *parent) :
/* Check if Bluetooth is available on this device */
if (!localDevice-isValid()) {
QMessageBox::warning(this, tr(Warning),
- Your local Bluetooth device cannot be accessed. Please check if you have installed qtconnectivity library.);
+ This should never happen, please contact the Subsurface developers
+ and tell them that the Bluetooth download mode doesn't work.);
return;
}
diff --git a/qtserialbluetooth.cpp b/qtserialbluetooth.cpp
index 5a2b3be..9c3bf5d 100644
--- a/qtserialbluetooth.cpp
+++ b/qtserialbluetooth.cpp
@@ -23,33 +23,33 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev
return DC_STATUS_INVALIDARGS;
// Allocate memory.
- serial_t *device = (serial_t *) malloc (sizeof (serial_t));
- if (device == NULL) {
+ serial_t *serial_port = (serial_t *) malloc (sizeof (serial_t));
+ if (serial_port == NULL) {
return DC_STATUS_NOMEMORY;
}
// Library context.
- device-context = context;
+ serial_port-context = context;
// Default to blocking reads.
- device-timeout = -1;
+ serial_port-timeout = -1;
// Create a RFCOMM socket
- device-socket = new QBluetoothSocket(QBluetoothServiceInfo::RfcommProtocol);
+ serial_port-socket = new QBluetoothSocket(QBluetoothServiceInfo::RfcommProtocol);
// Wait until the connection succeeds or until an error occurs
QEventLoop loop;
- loop.connect(device-socket, SIGNAL(connected()), SLOT(quit()));
- loop.connect(device-socket, SIGNAL(error(QBluetoothSocket::SocketError)), SLOT(quit()));
+ loop.connect(serial_port-socket, SIGNAL(connected()), SLOT(quit()));
+ loop.connect(serial_port-socket, SIGNAL(error(QBluetoothSocket::SocketError)), SLOT(quit()));
// Try to connect to the Serial Port Profile service
- device-socket-connectToService(QBluetoothAddress(devaddr), QBluetoothUuid::SerialPort);
+ serial_port-socket-connectToService(QBluetoothAddress(devaddr), QBluetoothUuid::SerialPort);
loop.exec();
- if (device-socket-socketDescriptor() == -1) {
- free (device);
+ if (serial_port-socket-socketDescriptor() == -1) {
+ free (serial_port);
// Get the latest error and try to match it with one from libdivecomputer
- QBluetoothSocket::SocketError err = device-socket-error();
+ QBluetoothSocket::SocketError err = serial_port-socket-error();
switch(err) {
case QBluetoothSocket::HostNotFoundError:
case QBluetoothSocket::ServiceNotFoundError:
@@ -65,7 +65,7 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev
}
}
- *out = device;
+ *out = serial_port;
return DC_STATUS_SUCCESS;
}
@@ -193,18 +193,16 @@ dc_status_t dc_serial_qt_open(dc_serial_t **out, dc_context_t *context, const ch
return DC_STATUS_NOMEMORY;
}
- serial_t *port;
+ // Initialize data and function pointers
+ dc_serial_init(serial_device, NULL, qt_serial_ops);
// Open the serial device.
- int rc = qt_serial_open (port, context, devaddr);
- if (rc == -1) {
+ dc_status_t rc = (dc_status_t)qt_serial_open (serial_device-port, context, devaddr);
+ if (rc != DC_STATUS_SUCCESS) {
free (serial_device);
- return DC_STATUS_IO;
+ return rc;
}
- // Initialize data and function pointers
- dc_serial_init(serial_device, (void*)port, qt_serial_ops);
-
// Set the type of the device
serial_device-type = DC_TRANSPORT_BLUETOOTH;
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] QtBluetooth implementation
Hello, Just to make sure we get the terminology straight... the local device is your computer or tablet or whatever Subsurface is running on, the remote device is the BT dive computer, correct? When I said the local device I was referring to the local Bluetooth device where the Subsurface is running on. The remote device is the dive computer which has support for Bluetooth. I assume that means turn on/off BT support on your computer? Yes, that is what I meant to say. I should have been more specific. This message seems off as a user facing message. The QtConnectivity libraries would have come with the install - either as dependency or Linux or bundled with the executable on Windows / Mac. What other reasons could there be for this test failing? Bluetooth turned off maybe? Think of this as something you tell the user so she can fix it... If the Bluetooth is turned off it wouldn't be a problem. I faced this issue when I played with the BlueZ and Qt versions and the Qt framework couldn't connect to the local Bluetooth device using the BlueZ stack. One of the reasons was that that the qtconnectivity library was missing or the BlueZ was not installed correctly. If the dependencies are installed correctly this should never happen. Many BT UIs do that... I always wonder if it wouldn't be better NOT to show the hex address if you have a name... Probably they use the address because it is unique. Two Bluetooth devices may have the same name and you could easily choose the wrong one. So the close function above frees the device when it closes it. Is the caller required to set it to NULL? Because if someone passes a device to close() (and the memory gets freed) and then to read() (admittedly a bug) then you dereference freed memory here. I guess that's just how the API works? Yes, you are right. I should probably set the device to NULL after the memory was freed. For the moment this is not a problem because the close method is called on libdivecomputer project and after this happens no other operations are called. Not having looked at the API in enough detail... but to me get_transmitted() sounds like how much has been transmitted, whereas bytesToWrite() sounds like a count of data in a queue... The bytesToWrite function returns the number of bytes that are waiting to be written. The native serial implementation uses the ioctl TIOCOUTQ command to get the number of bytes in the output buffer so I though that it would be ok if I will use the bytesToWrite method to get the expected results. Sorry if the messages from the commits had some spelling issues or if they were too coincise but I spend a lot of time to resolve the merging conflicts and after a while I decided that it would be a lot easier for me to create a new branch and to commit again my sources :-). Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] libdivecomputer - custom implementation for serial communication
I believe this is a good direction. From the discussion earlier I'm
doubtful that Jef agrees, but maybe a successful implementation can sway
him :-)
It would be good if he will give us some feedback.
That looks odd. You should have Jef's Copyright there (since it's
based on his code), but you should add your own Copyright as well
as you created this file.
I didn't know what to do with the license and how to handle this
problem :). If I will write my name at the end it would be enough?
+typedef struct serial_t serial_t;
+
+typedef struct dc_serial_operations_t
+{
+ //TODO in the end serial_t should be replaced with dc_serial_t
Can you explain that comment in more detail?
serial_t is an opaque structure that is used internally in
libdivecomputer. It contains members that dc_serial_t doesn't contain
(e.g. baudrate, duplex settings, termios data, etc). Since the
libdivecomputer code expects to pass a serial_t to the API functions, I'm
not quite sure what you mean that you would like to pass a dc_serial_t
around instead...
I believe that the baudrate, duplex settings, etc. can be set
using the *data field from dc_serial_t structure. These are specific to
the native serial communication. On IRDA or Bluetooth communication
we only need a file descriptor, a context and a timeout.
So I wanted to create a generic structure which can hold minimal information
needed for any serial implementation and to offer the possibility
to add some specific data.
Now I believe that this is a bad idea and the structure can be represented
as
typedef struct dc_serial_t {
dc_transport_t type;//the type of the transport
(USB, SERIAL, IRDA, BLUETOOTH)
serial_t *port; //serial device port
void *data; //specific data for device
const dc_serial_operations_t *ops; //reference to a custom set
of operations
} dc_serial_t;
There's clearly some overlap between the structures, but they are quite
different.
I think that I should remove the fd, timeout and context fields and
to add a serial_t *port member
This feels like it should have been squashed into the first patch...
Yes, you are right. I forgot to add it in the beginning.
Won't that break things for OSTC devices that are USB (so all but the very
latest dive computers from HW - which are the two that you have)?
Maybe I'm missing what you are doing with the data pointer below. I need
to look at this not as a patch but in the final code to make sure I
understand it more completely.
Yeah, it seems that you are encapsulating all this. OK. But then why not
include a serial_t as member of dc_serial_t ?
As I said it the beginning, now I believe that it would be a better
idea to add a serial_t member. :-)
For the moment it will break things for OSTC devices but after we will
decide how the dc_serial_t structure should look like, I will create
a new dc_serial_usb_open method and a dc_serial_irda_open and use it.
Thanks for the feedback. I will try to use it and improve the current
implementation. Please let me know if you agree with the new proposed
dc_serial_t representation.
Cheers,
Claudiu
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] QtBluetooth implementation
One of the things that I would like to see as part of the project deliverables is of course documentation / addition to the user manual. There we need to be especially careful to do this in a way that makes sense to the non-technical person... just a diver with a computer. I will write the documentation after I will create a functional prototype for all the devices. So I wonder what a good message would be. We have a few messages that are basically This should never happen, please contact the Subsurface developers and tell them bla (I am paraphrasing, of course, but that's the idea). I think that would be more appropriate. Yes, it is a better message. In this way the user will not be confused with unnecessary information. For the average diver... how many do you think can make any sense of that Bluetooth address? Maybe show it if someone hovers over the name? But if we have a name I really wouldn't show it in the UI I thought that it will be enough to show the name of the device in the selection dialog and use its address on the device combo box. In the communication process I only need that address and it was easier for me to save it on the *ui.device* combobox. If you want I can fill the text with the name of the device. The way the API works you would have to set the variable to NULL in the caller - doing so in the function won't make a difference, right? Yes, it won't make a difference. The current native serial implementation doesn't set it to NULL. If someone wants to use the device after it was closed it means that there is a problem with its logic and the program should exit with failure. Usually I find merging in git really easy, assuming you use the right tools. Visual 3-way merge helpers like meld are really wonderful. Thanks for the tips. I usually use Meld when I need to work with TFS repositories on a Linux platform. It is a great tool but in that day I totally forgot about it. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: BT support, brief tests
I have a Shearwater Petrel and am looking forward to being able to test your work at some stage. I can download dives fine on Linux and Windows but find needing sudo to set up the connection annoying. Thanks for the support. I hope that I will have a complete Bluetooth implementation soon and the community will help me to test all the dive computers which has BT capabilities. It's probably not the OSTC that requires a pin. I played around (a lot) with connecting my Petrel, and found that whether I need to enter a pin () or not depends not on the dive computer but on whether I'm using the onboard bluetooth (no pin required) or a dongle (some ask for a pin, some assume the default). This is good to know. I tested the pairing step with an onboard Bluetooth and a dongle one. On both scenarios the dive computer requires a PIN code for authentication. Probably some Bluetooth devices are smarter and have some default PIN codes which are tried on the pairing step. Have a nice weekend, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] QtBluetooth implementation
I attached some patches for the QtBluetooth serial implementation.
The UI exposes the following functionalities:
- read information about the local device and its state
- scan for remote devices
- pair/unpair with a remote device (it doesn't work for custom PIN codes)
- turn on/off the local device
- logging
- data transfer (dive logs import)
For the moment the *qt_serial_bluetooth* implementation works
only with *hw_ostc3* and *hw_ostc* (hopefully :-) ). After you agree with
the modifications and the design of libdivecomputer project I will
start to add support for other vendors.
Known issues:
- during the installation of libdivecomputer, the *custom_serial* header
is not copied
- the pair command doesn't work with devices which require a specific PIN
code
- the design of the UI is ugly :-)
Cheers,
Claudiu
From 22b5410764b67556b7a928e0367ac949e7547147 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Fri, 26 Jun 2015 03:13:53 +0300
Subject: [PATCH 1/9] Add checkbox and button for Bluetooth download mode
The checkbox will be used to enable the Bluetooth
downloading mode. The button will be used to create
a dialog selection where the user will be able to
scan and select remote devices.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qt-ui/downloadfromdivecomputer.cpp | 20
qt-ui/downloadfromdivecomputer.h | 2 ++
qt-ui/downloadfromdivecomputer.ui | 17 +
3 files changed, 39 insertions(+)
diff --git a/qt-ui/downloadfromdivecomputer.cpp b/qt-ui/downloadfromdivecomputer.cpp
index c5d57e6..838a9e5 100644
--- a/qt-ui/downloadfromdivecomputer.cpp
+++ b/qt-ui/downloadfromdivecomputer.cpp
@@ -99,6 +99,9 @@ DownloadFromDCWidget::DownloadFromDCWidget(QWidget *parent, Qt::WindowFlags f) :
ui.ok-setEnabled(false);
ui.downloadCancelRetryButton-setEnabled(true);
ui.downloadCancelRetryButton-setText(tr(Download));
+ ui.chooseBluetoothDevice-setEnabled(ui.bluetoothMode-isChecked());
+ connect(ui.bluetoothMode, SIGNAL(stateChanged(int)), this, SLOT(enableBluetoothMode(int)));
+ connect(ui.chooseBluetoothDevice, SIGNAL(clicked()), this, SLOT(selectRemoteBluetoothDevice()));
}
void DownloadFromDCWidget::updateProgressBar()
@@ -493,6 +496,8 @@ void DownloadFromDCWidget::markChildrenAsDisabled()
ui.chooseDumpFile-setEnabled(false);
ui.selectAllButton-setEnabled(false);
ui.unselectAllButton-setEnabled(false);
+ ui.bluetoothMode-setEnabled(false);
+ ui.chooseBluetoothDevice-setEnabled(false);
}
void DownloadFromDCWidget::markChildrenAsEnabled()
@@ -512,6 +517,21 @@ void DownloadFromDCWidget::markChildrenAsEnabled()
ui.chooseDumpFile-setEnabled(true);
ui.selectAllButton-setEnabled(true);
ui.unselectAllButton-setEnabled(true);
+ ui.bluetoothMode-setEnabled(true);
+ ui.chooseBluetoothDevice-setEnabled(true);
+}
+
+void DownloadFromDCWidget::selectRemoteBluetoothDevice()
+{
+ qWarning() Selecting a remote Bluetooth device...;
+ //TODO add implementation
+}
+
+void DownloadFromDCWidget::enableBluetoothMode(int state)
+{
+ ui.chooseBluetoothDevice-setEnabled(state == Qt::Checked);
+ if (state == Qt::Checked)
+ selectRemoteBluetoothDevice();
}
static void fillDeviceList(const char *name, void *data)
diff --git a/qt-ui/downloadfromdivecomputer.h b/qt-ui/downloadfromdivecomputer.h
index 92db09d..0b63d28 100644
--- a/qt-ui/downloadfromdivecomputer.h
+++ b/qt-ui/downloadfromdivecomputer.h
@@ -77,8 +77,10 @@ slots:
void updateProgressBar();
void checkLogFile(int state);
void checkDumpFile(int state);
+ void enableBluetoothMode(int state);
void pickDumpFile();
void pickLogFile();
+ void selectRemoteBluetoothDevice();
private:
void markChildrenAsDisabled();
diff --git a/qt-ui/downloadfromdivecomputer.ui b/qt-ui/downloadfromdivecomputer.ui
index ff80935..f232967 100644
--- a/qt-ui/downloadfromdivecomputer.ui
+++ b/qt-ui/downloadfromdivecomputer.ui
@@ -116,6 +116,23 @@
/property
/widget
/item
+ item row=11 column=0
+ widget class=QCheckBox name=bluetoothMode
+ property name=text
+stringChoose Bluetooth Download mode/string
+ /property
+ /widget
+ /item
+ item row=11 column=1
+ widget class=QToolButton name=chooseBluetoothDevice
+ property name=toolTip
+stringSelect a remote Bluetooth device./string
+ /property
+ property name=text
+string.../string
+ /property
+ /widget
+ /item
item row=0 column=0 colspan=2
widget class=QLabel name=label
property name=text
--
2.1.4
From 99acdca1b852a0ffa8e1c339bdd6f4efffae9d28 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Fri, 26 Jun 2015 03:18:08 +0300
Subject: [PATCH 2/9] Implement temporaty UI design for Bluetooth selection
dialog
Implement a temporary UI design for Bluetooth selection dialog.
Functionalities
[GSoC] Week 4 (Native Bluetooth support)
Hi there, In the first part of the week I wanted to integrate the functionalities from my prototype to Subsurface project. Therefore I added a dialog widget to the *DownloadFromDCWidget* where an user has the possibility to: - turn on/off his local Bluetooth device - see some information about the local device - scan for remote devices - pair/unpair - select a device and save its address for the *DownloadThread* Next I tried to make the *libdivecomputer* project to accept callbacks to custom functions used for serial communication. Here [1] you can find how the new structure looks. I am not sure if this is the best way to do it. If you have other suggestions please let me know. For the moment I choose to have the same functions signatures as the ones from native serial implementation [2] to avoid some modifications. I created a new method [3] which can be used to open a device and pass a reference to a custom implementation of a *dc_serial_t* structure and I modified the *hw_ostc* and *hw_otsc3* implementations [4] to use the new structure. I created a method [5] which can be used to initialize the native serial implementation and to initialize a *dc_serial_t* instance. This was used in the old device opening method [6] for backwards compatibility. I already tested the serial native implementation with my HW OSTCs device and it still works. I didn't start to make changes on other families of devices because I want to know if you agree with this modifications and if you have other ideas on how I can improve them. In the end I started to implement the serial communication using the QtBluetooth API [7] and I am still working on it. In the next week I want to finish the data transfer implementation and to test it. Cheers, Claudiu [1] - https://github.com/claudiuolteanu/libdc/blob/Subsurface-testing/include/libdivecomputer/custom_serial.h [2] - https://github.com/claudiuolteanu/libdc/blob/Subsurface-testing/src/serial.h [3] - https://github.com/claudiuolteanu/libdc/blob/Subsurface-testing/src/device.c#L177-201 [4] - https://github.com/claudiuolteanu/libdc/commit/960f9d1a3904c17668369694ea196a5f4a66fd88 [5] - https://github.com/claudiuolteanu/libdc/blob/Subsurface-testing/src/custom_serial.c#L47-80 [6] - https://github.com/claudiuolteanu/libdc/blob/Subsurface-testing/src/hw_ostc3.c#L272-278 [7] - https://github.com/claudiuolteanu/subsurface/blob/master/qtserialbluetooth.cpp ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 3 (Native Bluetooth support)
Given the lack of Bt support on Windows when just using bluez I wonder if there is value in Anton's idea to modify libdivecomputer to use a callback to open a serial connection and then have Subsurface (or other consumers of libdivecomputer) provide that serial stream back to libdivecomputer. This way we could still use QtBluetooth on the Subsurface side but benefit from the libdivecomputer download algorithms. Does this seem like a reasonable direction? /D Yes, it is a reasonable direction but I have to remind you that *QtBluetooth* doesn't have support for Windows. They probably started to work on it [1] but there is no information about the release date. Therefore for Windows we should use the *MS Bluetooth* stack. The same technology is used/will be used in *libdivecomputer* project. The only benefit with *QtBluetooth* API is that it has support for OSx, iOS, Android and Linux. I am not against *QtBluetooth* API, because I am already accommodated with the API but I believe that it would be more beneficial for both projects to have the Bluetooth implementation in the *libdivecomputer* project, since it is already started. I am a little confused about which direction to go. I read the link suggested by Jef and there are some drawbacks mentioned. Also, the discussions were from 2014 and I don't know if any idea from there was taken into consideration and it will be used in a new release. I remember that Jef said that he intends to do some major changes on the API in the next release. Also I believe that it would be helpful if the new API will allow applications to open the low-level communication transport (already implemented in the *libdivecomputer*, like Jef suggested) or to open a custom one implemented in the application which respects the same layout (like Anton suggested). It will require some extra code in the application side but it will cover a lot of usages. In this way we can create our custom implementation with the *QtBluetooth* API for its supported platforms, while for Windows we can finish the implementation from the *libdivecomputer* project. The applications will be responsible to implement features like pairing/scanning/hci control if they want to use Bluetooth protocol for communication and extract the address of the remote device. The job of the *libdivecomputer* will be to assure the communication and the data parsing. It will not be its responsibility to enumerate serial, usb or bluetooth devices or to expose an API to control the devices. [1] - https://bugreports.qt.io/browse/QTBUG-40698 Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
