> 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
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.vas
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,
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
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
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
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
___
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
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
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:
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
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
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.
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_
>
> 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
> 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
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
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
___
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
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()
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
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
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
* 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
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
://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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:-).
___
: 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
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
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
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
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
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
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
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
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
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
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.
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 ==
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
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
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
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.
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
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
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
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
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
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
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
.
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
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
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
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
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
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
-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
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
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
.
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
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
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
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
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
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
: 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
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
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
1 - 100 of 123 matches
Mail list logo
