On 09 July, 2015 - Claudiu Olteanu wrote:
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
On 09 July, 2015 - Claudiu Olteanu wrote:
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:
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
On Thu, Jul 09, 2015 at 10:17:41AM +0200, Anton Lundin wrote:
On 09 July, 2015 - Claudiu Olteanu wrote:
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
On Thu, Jul 09, 2015 at 10:15:02AM +0200, Anton Lundin wrote:
On 09 July, 2015 - Claudiu Olteanu wrote:
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
On 29 June, 2015 - Claudiu Olteanu wrote:
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
Hi Anton,
On 9 Jul 2015 7:35 am, Anton Lundin gla...@acc.umu.se wrote:
Chokay. I tried to test against a OSTC Sport, and got some results.
Fist off i got massively de-railed due to that somehow i got
CONFIG_BT_BCM enabled in my kernel which caused btusb to fail its
dependency on btbcm
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
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
On Thu, Jul 02, 2015 at 11:51:39PM +0300, Claudiu Olteanu wrote:
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
Hi Dirk,
On 3 Jul 2015 7:17 am, Dirk Hohndel d...@hohndel.org wrote:
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?
Unfortunately not, my Petrel 2 identifies itself as just a
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
Claidiu,
On 1 Jul 2015 8:55 am, Claudiu Olteanu olteanu.vasilica.clau...@gmail.com
wrote:
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
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
Claudiu,
On 1 July 2015 at 08:55, Claudiu Olteanu olteanu.vasilica.clau...@gmail.com
wrote:
I attached a patch which should resolve the issues regarding
the connection.
Thank, I'll try it out this evening.
I know that this is not the ideal solution but I wanted to cover all cases.
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
Hi Claudiu,
On 30 June 2015 at 17:23, Claudiu Olteanu
olteanu.vasilica.clau...@gmail.com wrote:
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
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
Just some random handwaving here...
The idea of a new dive computer called a Petrel 2 might be the simple
option right now, but what happens if in a future firmware update the
channel number gets changed? Is the idea of doing something similar to the
sdptool query over qtbluetooth not doable?
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
Claudiu,
I've tested your patches, and your work looks great!
Tested on Fedora 22, using a Shearwater Petrel 2 and onboard Bluetooth.
On 29 June 2015 at 08:33, Claudiu Olteanu
olteanu.vasilica.clau...@gmail.com wrote:
I didn't know that. Thanks for the heads up!
In the beginning try to see
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
On 30 Jun 2015, at 05:29, Rick Walsh rickmwa...@gmail.com wrote:
Hi Claudiu,
On 30 June 2015 at 04:37, Claudiu Olteanu
olteanu.vasilica.clau...@gmail.com wrote:
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
Hi Claudiu,
On 30 June 2015 at 04:37, Claudiu Olteanu
olteanu.vasilica.clau...@gmail.com wrote:
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
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
Hi Claudiu,
On 29 Jun 2015 7:50 am, Claudiu Olteanu
olteanu.vasilica.clau...@gmail.com wrote:
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
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
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
Thanks Claudiu,
On 29 Jun 2015 8:08 am, Claudiu Olteanu
olteanu.vasilica.clau...@gmail.com wrote:
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
31 matches
Mail list logo
