subsurface/core/divesitehelpers.cpp: In member function 'virtual void ReverseGeoLookupThread::run()':
subsurface/core/divesitehelpers.cpp:128:12: error: invalid use of incomplete type 'class QDebug'
qDebug() << "no reverse geo lookup; geonames returned\n" << fullReply;
^
Signed-off-by: Alex Blasche <alexander.blasche@qt.io>
The current BLE read reads just one 20 bype packet. That packet size is set
in ble_serial_ops, so, without being able to test on anything other than
a OSTC3, I assume that this holds for other BLE DCs too. So, I think is
is weird that those interfaces work with the current read() of just one
packet at the time.
As we need a blocking read (at least for the OSTC parser), just read all
data that is available on the input. And when we think we are done, give
the QtEventloop control to see if there is more, and process that incoming
data as well. All this basically implements a blocking read.
CAVEAT 1: This might break the reading from the currently working BLE devices.
CAVEAT 2: With this, I still cannot read the OSTC3 completely. For
developers familiar with the HW transfer protocol: it just stops while
reading the first full dive (header + profile) command 0x66, despite
correctly reading about 5Kb of data before. For some
reason, I do not believe that this is related to this commit.
CAVEAT 3: All above tested on Linux Desktop with bluez stack, and
confirmed NOT to work on Android 7.1.2, build with Qt 5.9.0, And
yes, I know 5.9.1 recommended.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
1) As the OSTC sends data to the BLE central role (the SSRF client) over 2
characteristics, we have to filter the administrative credit data from
the actual dive data that it received. The characteristcStateChanged
function is adapted for this.
2) We have to be sure that the Terminal Client I/O is fully defined during
opening the connecton to the OSTC. From 6d505b24f0c15 we can see
that the last step in setting up the terminal interface is the grant
of credits. This is done by writing to the proper (the only one, with
id = 0x2902) descriptor of the credits RX characteristic. The here
added slot is triggered on the completion of write of credits marking
the final stage of the setup.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The current "select the correct BLE service to talk to" is flawed.
It assumes that the first found non-standard UUID is the right one
and apparently it is for some DCs. But not for the HW devices.
The HW devices use a "standard" ie. approved by the Bluetooth
SIG, controller, that comes with a UUID that our code currently
considers standard so not to be the right one.
This (simple) commit selects the right service for HW. The UUID
is hard coded, and this is ok, because it is tied to the hardware
used by HW. Futher, it does not change anything for other BLE
devices.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This initalizes the Terminal I/O client as described in paragraph 3 of
http://www.telit.com/fileadmin/user_upload/products/Downloads/sr-rf/BlueMod/TIO_Implementation_Guide_r04.pdf
This is for all Heinrichs Weikamp computers, that use referenced BT/BLE hardware
module from Telit Wireless Solutions (Formerly Stollmann E+V GmbH). The 16 bit
UUID 0xFEFB (or a derived 128 bit UUID starting with 0x0000FEFB is a
clear indication that the OSTC is equipped with this BT/BLE hardware.
Furthermore, most devices equipped with this BT/BLE hardware have BT addresses
starting with 00:80:25:...
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This seems really long, but one user appeared to get a response after
almost 10 seconds. So going with 12 for some margin of error.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should be much more robust in getting us the correct Bluetooth address
and the correct vendor / product for our selection.
When we pick a paired device, we extract the address right from its name.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This really doesn't help us as we can't associate a vendor/product with
devices we don't recognize, so we can't download from them, anyway.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For DCs that support both BT and LE, allow the user to connect to both
interface layers. Maybe not usefull in the end (as BT is faster
than LE), but as long as BT on Android is WIP is it very useful
to be able to connect to the interface layer we like.
Just add it to the Paired Devices list twice. The normal way, and
the LE: prepend way.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This really needs to be done differently - we need a structured way
to associate a transport mechanism with each of the dive computers
we support.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Right now we have a quirk for Shearwater devices to set the random
address flag, but also to handle the differences at read/write time.
With this, I can finally download from both the Suunto EON Steel and the
Shearwater Perdix AI with the same binary.
It's not *pretty*, but it works.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We rather use wait in combination with spinning the event loop.
Signed-off-by: Alex Blasche <alexander.blasche@qt.io>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If a device has more than one service the order of service discovery
determined the selection of the service that we intend to interact
with. This assumption is not accurate and is even platform dependent.
Thinking ahead, it is likely that some devices may require us to keep
track and interact with multiple services at the time.
The new logic still suffers from the fact that there is no way
to select the correct service for interaction. This will require
higher level stack changes.
Signed-off-by: Alex Blasche <alexander.blasche@qt.io>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
toUtf8() creates a temporary char* representation which is assigned to
uuid. As soon the object created by toUtf8() gets destroyed, the uuid
pointer points to releases memory.
The intention is to check that we don't have one of the standard
16bit Bluetooth uuids. That's the purpose of QBluetoothUuid::toUInt16().
Signed-off-by: Alex Blasche <alexander.blasche@qt.io>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is somewhat hacky, but it allows at least the Shearwater
libdivecomputer backend to continue to treat even the BLE GATT model as
just a serial protocol.
What it does is create a special "emulate serial behavior over the
packetized BLE protocol" helper layer, that qtserialbluetooth falls back
on when rfcomm is not available.
NOTE! This still requires some BLE packet code changes to work with the
odd way that Shearwater sets up their BLE GATT communication. So note
that no further patches are necessary to *libdivecomputer*, but some
updates are needed for the subsurface qt-ble.cpp code.
I have those updates in my tree, and this code is all tested on my
Perdix AI, but those patches are currently too ugly to commit as-is.
I've cleaned up this "fake serial" code sufficiently, that cleanup comes
next.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems a bit odd, but it actually has three different reasons for it:
- It's a visual indication of BT LE mode for users
- the rfcomm code only works with legacy BT support, and if we scan a
device that only does LE, we want the custom serial code to instead
automatically fall back on a "emulate serial over LE packets" model.
- we want rfcomm to remain the default for devices that do both legacy
BT _and_ LE, but we want people to have the ability to override the
choice manually. They can now do so by just editing the address
field and adding the "LE:" prefix manually, and it automatically gets
saved for next time.
So while a bit hacky, it's actually a very convenient model that not
only works automatically, but allows the manual override.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is some very early and hacky code to be able to access BLE-enabled
dive computers that use the GATT protocol to send packets back and forth
(which seems to be pretty much all of them: a vendor-specific GATT
service with a write characteristic and a notification characteristic
for reading).
For testing only. But it does successfully let me download dives from
my EON Steel and my Scubapro G2.
NOTE! There are several very hacky pieces in here, including just
"knowing" that the write characteristic is the first one, and the
notification characteristic is second. The code should actually check
the properties rather than have those kinds of hardcoded assumptions.
It also checks "vendor specific" by looking at the UUID string
representation, and knowing that the standard ones start with zero.
Crazily, there doesn't seem to be any normal way to test for this,
although I guess that maybe the uuid.minimumSize() function could be
used.
There are other nasty corners. Don't complain, send me patches.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of being "custom serial", it's a IO model that allows serial or
packet modes, independently of each other (ie you can have a bluetooth
device that does serial over BT rfcomm and packet-based communication
over BLE GATT with the same serial operations that describe both cases).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This way in the en_US locale we no longer get shown the odd "dive(s)"
and instead get correct singular and plural forms.
Most of the patch is just a reindentation as it removes the if clause
that used to do the special case of NOT loading a translation for the
en_US case.
Right now we start with a trivial en_US translation file. My guess is
that this will be overwritten once we do the next round of "new strings,
new translations".
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Currently, only a small number of dive computers can be downloaded from
the mobile app. Only present the supported ones to the user. So, currently
restricted to classic BT. Not sure about FTDI support at this point.
Version 2 of the same commit after review from Dirk. Fundamentally,
support is as follows: Android: BT, BLE, and FTDI. iOS: BLE only. For
all other OSses, this commit has no changes. As the BLE backend is
not yet ready, no support on iOS yet.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Translate all of them, but also remove some redundant or possibly
misleading messages. These are now seen by users, not just developers
trying to debug the code.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
