Very timid beginning framework for BLE communication

Rick Walsh rickmwalsh at gmail.com
Mon Apr 24 00:44:45 PDT 2017


Hi Linus (et al)

On 20 April 2017 at 06:49, Rick Walsh <rickmwalsh at gmail.com> wrote:

>
>
> On 20 Apr. 2017 5:49 am, "Linus Torvalds" <torvalds at linux-foundation.org>
> wrote:
>
> On Wed, Apr 19, 2017 at 12:33 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >
> >> It's really just three commits:
> >>
> >>       custom serial: pass device_data_t to bluetooth operation function
> >>       Expand 'bluetooth_mode' from a boolean to an emun
> >>       Prepare to split the custom serial operations up by RFCOMM-vs-BLE
> >>
> >> and each of them actually tries to be a total no-op at this time. But
> >> the intent is to make it possible for core/qtserialbluetooth.cpp to
> >> simply have a different set of operations for BLE devices where RFCOMM
> >> doesn't work.
> >
> > I looked at the code and it makes sense to me. I assume the debug fprintf
> > in the last one is there intentionally... :-)
>
> Well, you picked up on the *one* change that is actually supposed to
> do something.
>
> Yeah, it's "intentional" in the sense that without that line, I
> couldn't see if my code actually did anything or not.
>
> It's obviously not meant to be real in the end. Once we have code that
> actually handles the BLE case, that printf no longer makes sense at
> all. Right now it's there to show that "yes, we actually noticed that
> the device was a BLE device" .
>
> >> In particular, somebody should probably test that it still works with
> >> the RFCOMM model. I'm particularly worried about devices that can do
> >> *both* traditional bluetooth *and* BLE. Because right now it just says
> >> that if the device can do BLE, we'll pick the BLE model. Of course,
> >> right now that BLE model ends up falling back to the same old RFCOMM
> >> code (which would fail on a BLE-only device), so it should still work
> >> with a "RFCOMM *and* BLE" device, but whatever..
> >>
> >> Comments?
> >
> > I need to check back with Shearwater - I think they have some devices
> that
> > do both, rfcomm and BTLE
>
> Yeah, so that's definitely the most interesting case.
>
>
> The Petral 2 does both, and I think the "original" Perdix too. I might
> have a chance to test with my Petral 2 this weekend but not before.
>

So I just tested with my Petrel 2, using the USB Bluetooth controller that
came with the DC.  I don't think that controller actually supports BLE.  I
received the insufficient privileges error.
[0.000099] ERROR: No such file or directory (2) [in
../../src/serial_posix.c:177 (dc_serial_open)]
[0.000153] ERROR: Failed to open the serial port. [in
../../src/shearwater_common.c:46 (shearwater_common_open)]

For comparison, I downloaded with Master (51ee9d4 Latest translations) fine.

Next, I tried a different controller (Targus Bluetooth 4.0), which says on
the packet that it does support BLE.  I had to go through the pairing thing
again, but pairing wouldn't work with the ble-prep branch.
qt.bluetooth.bluez: Discovered:  "00:13:43:0E:6B:D0" "Petrel" Num UUIDs 1
total device 3 cached RSSI -59 Class 0
qt.bluetooth.bluez: Updating RSSI for "4A:4F:4D:FE:1B:B6" QVariant(short,
-80)
qt.bluetooth.bluez: Updating RSSI for "1C:1A:C0:92:76:54" QVariant(short,
-76)
qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Failed to create pairing "org.bluez.Error.InProgress"
qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Failed to create pairing "org.bluez.Error.InProgress"
qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Failed to create pairing "org.bluez.Error.InProgress"
qt.bluetooth.bluez: Failed to create pairing
"org.freedesktop.DBus.Error.NoReply"

I paired the device from Subsurface master build, then tested download from
the ble-prep build again.  This time the download worked.
qt.bluetooth.bluez: Discovered:  "00:13:43:0E:6B:D0" "Petrel" Num UUIDs 1
total device 0 cached RSSI 0 Class 0
qt.bluetooth.bluez: Discovered:  "1C:1A:C0:92:76:54" "1C-1A-C0-92-76-54"
Num UUIDs 0 total device 1 cached RSSI 0 Class 0
qt.bluetooth.bluez: Discovered:  "4A:4F:4D:FE:1B:B6" "4A-4F-4D-FE-1B-B6"
Num UUIDs 0 total device 2 cached RSSI 0 Class 0
qt.bluetooth.bluez: Discovered:  "90:00:DB:C6:98:B0" "Galaxy S6" Num UUIDs
14 total device 3 cached RSSI 0 Class 5898764
qt.bluetooth.bluez: Updating RSSI for "4A:4F:4D:FE:1B:B6" QVariant(short,
-85)
qt.bluetooth.bluez: Updating RSSI for "1C:1A:C0:92:76:54" QVariant(short,
-76)
qt.bluetooth.bluez: void QBluetoothDeviceDiscoveryAgentPrivate::stop()
Using bluetooth mode 2
qt.bluetooth.bluez: void QBluetoothSocketPrivate::_q_readNotify() 16 error:
-1 "Resource temporarily unavailable"

I think the bluetooth mode 2 means it was using BLE.

I don't know why it gave the error 16 at the end of the terminal output,
but download worked and no error was shown in the ui.

Summary of brief testing, it appears:
- download works with a BLE controller
- this breaks pairing (at least for me)
- this breaks bluetooth support for at least one non-BLE controller


> I suspect BLE is generally the "preferred" model (newer, lower power),
> but obviously only when we have a working BLE downloader. Which was
> why I did that "assume BLE if it's supported".
>
> If there is somebody who has a RFCOMM mode, _and_ supports BLE, and
> then the BLE protocol is something entirely different, we'd really
> need the low-level libdivecomputer code to explicitly pick one over
> the other.
>
> It might be something as hacky as the libdivecomputer code doing
>
>     /* We don't handle BLE yet, force RFCOMM fallback */
>     if (device->bluetooth_mode == BT_LE) device->bluetooth_mode =
> BT_RFCOMM;
>
> before doing the dc_serial_open() call.
>
> But hopefully we'd never need anything like that, just because any
> dive computer that supports both would use the same protocol and we'd
> just prefer BLE.
>
>                      Linus
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170424/326c0a84/attachment.html>


More information about the subsurface mailing list