For Ratio dive computers we can't tell by the Bluetooth name which model it is.
There are BT only models and BLE only models. The failure case here was a user
on iOS (BLE only) with a BLE only dive computer which we didn't recognize
because previously we returned a BT only device (which isn't supported on an
iPhone), and the lookup won't return a valid descriptor if the transport needed
isn't available.
These days BLE is far more common, so return a BLE enabled name by default, but
try a BT only name just in case.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The code works ok falling back to just Perdix and Petrel 2, but
it looks confusing to the user to see an incorrect name in the
connection drop down.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It's confusing to have the same name refer to two different models.
Unfortunately, that's what Aqualung is doing by simply changing the
model number and serial number, but not the external branding.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Use the explicit QBluetoothUuid instead of just QUuid and deal with new
constants and signal names.
At least with Qt6 we no longer need the ugly QOverload hack.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Somehow three identical lines snuck into commit 0a4e37ee8b ("core/BT: simplify
detection of bluetooth names").
Reported-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of that super long if-else if chain, have something more
structured using a table for the common case of prefix based names.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It would be so much nicer if we could just let libdivecomputer do this,
but the filter function there doesn't quite do things the way we need
them to be. Which is why we have our own function here.
This is a small attempt to rationalize the code that we have to make it
easier to maintain.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
New (late 2020) iX3M hardware (refered to as 'iX3m with Sequared Buttons'
in the Ratio support section) appears to identify as iX5M, both in the
Bluetooth name and reported revision e.g.
$ ./ratio-toolbox-x86_64.AppImage info | head -n2
Model: Ratio® iX5M GPS TECH+
Firmware version: 4.1.26/016 (English)
Add a second Bluetooth name matcher for this variation, returning the same
(generic) model as is currently used.
Signed-off-by: Damian Zaremba <damian@damianzaremba.co.uk>
Android can't scan for classic BT devices, so when BT support was first
added, we simply didn't use the discovery agent at all and relied on the
list of paired BT devices provided by Android.
This still worked fine for a lot of BLE devices that allowed 'bonding'
with the Android device - similar to pairing. But some BLE devices (like
the Shearwater Peregrine) don't support bonding and so our Android code
didn't see them at all.
With this commit we start a BLE only scan on Android to add to the list
of already paired devices.
Fixes: #2974
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We certainly should log errors and the complete list of discovered
devices.
Also, it's good practice to set a specific search time (I picked three
minutes). This way we won't constantly scan and drain resources.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We call the same helper from two spots. Once when we report the already
paired BT devices on Android, and once from the deviceDescovered signal
for the discovery agent. Let's make sure we can tell where the info came
from.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There is no need to continue to look, and at least with the Shearwater
Peregrine having the scan run while we are trying to discover characteristics
appeared to cause issues.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I can no longer reproduce the case where this rescan was necessary.
So let's remove it as it causes additional wait time for BT/BLE users on macOS.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds the Oceanic Veo 4.0 & Pro Plus 4, the Sherwood Wisdom 4 and the
Tecdiving DiveComputer.eu to our list of known names.
The Oceanic Pro Plus X detection is simply moved to have the other names
in a more logical order.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This updates libdivecomputer to support the Oceans S1 and McLean Extreme
divecomputers.
It also adds the Oceans S1 to the list of dive computers we reconize by
bluetooth name.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If the user asks to have all BT/BLE devices shown, we should behave
consistently to the case of a recognized dive computer and always show the
device name. In almost all cases the BT/BLE address (and even worse on
iOS/macOS the weird uuids) are completely meaningless.
If there isn't a name, don't add a leading space in order to make it easy to
detect if we have an address without a name (which almost certainly isn't a
dive computer, so it should be towards the end of the list of addresses - which
will be handled in a later commit).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This fixes a rather subtle bug.
In btdiscovery.cpp we are detecting dive computers based on their BT name and
are setting up product+vendor as the key for that lookup. QMap always uses case
sensitive comparisons and a tiny inconsistency snuck into our code.
libdivecomputer names for the Aqualung dive computers i200C / i300C / i550C end
in an upper case C (as matches the official branding), but in btdiscovery.cpp
we have those names with lower case c. And therefore didn't recognize these
dive computers.
Obviously this is easy to fix by fixing those three strings, but I decided that
it was silly to set ourselves up for similar oversights in the future. So
instead I switched the matching of the descriptor to simply be allways all
lower case.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This isn't really a useful performance improvement, but it's still better,
IMHO, because we don't have a less specific match later on potentially change
an already executed match.
Because of our coding style the comment covering multiple cases of Pelagic dive
computers now is associated just with the first of those entries. I don't see a
way to do this differently without being in violation of our coding style, so
I'll just keep it like this.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Both Shearwater Petrel and Petrel 2 identify as 'Petrel' as their BT and BLE
names. But only the Petrel 2 supports BLE, thus only the Petrel 2 shows up in
the list of known dive computers on iOS (which supports only BLE but not
BT-only). By switching this around to always pick Petrel 2 we now correctly
detect such a dive computer on iOS.
Fixes#2739
Reported-by: Rick Holcombe <wrh@nc.rr.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The code seemed to do something really reasonable by picking one of the
supported OSTC versions - except that the one it picked didn't support
BT/BLE and therefore our logic of recognizing dive computers on iOS
failed.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
At least in one of the logs we saw there seemed to be trailing spaces.
It should be enough for the BT name to start with "Mares Genius" in
order to be recognized.
Suggested-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We don't have the "show all dive computers" logic on mobile, so we need
something like this.
Possibly we should use the libdivecomputer matching code if it exists,
but that's a much bigger change, let's do this incremental one for now.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The way we handle singletons in QML, QML insists on allocating the
objects. This leads to a very idiosyncratic way of handling
singletons: The global instance pointer is set in the constructor.
Unify all these by implementing a "SillySingleton" template. All
of the weird singleton-classes can derive from this template and
don't have to bother with reimplementing the instance() function
with all the safety-checks, etc.
This serves firstly as documentation but also improves debugging
as we will now see wanted and unwanted creation and destruction
of these weird singletons.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
I got confirmation from Tiago Thedim Dias that my libdivecomputer patch
makes BLE downloading work from the i200c, and already pushed out the
libdivecomputer changes earlier. This updates the subproject in
subsurface to have those changes.
This also adds the bluetooth name patterns for the i300c and a few other
Aqualung dive computers we hadn't added yet. That should make them show
up in the bleutooth device list even without having to check the "Show
all bluetooth devices" check-box.
Tiago claims he didn't need that, and I wonder if we have some overly
permissive match somewhere, but it's the right thing to do regardless.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It needs a newer version of libdivecomputer to actually download, but
early very experimental code exists in the Subsurface-NG branch.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Note that we don't really have libdivecomputer support for it yet, only
newly added model numbers etc. But the name detection should make it
easier for people to at least download a memory dump.
In addition to the libdivecomputer model number updates, this also has a
merge of Jef's upstram libdivecomputer changes.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is just a trivial update to recognize the BT name, and a
libdivecomputer submodule update to get the updates to libdivecomputer
to recognize the new USB IDs etc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
See https://www.kdab.com/goodbye-q_foreach/
This is reduced to the places where the container is const or can be made const
without the need to always introduce an extra variable. Sadly qAsConst (Qt 5.7)
and std::as_const (C++17) are not available in all supported setups.
Also do some minor cleanups along the way.
Signed-off-by: Rolf Eike Beer <eike@sf-mail.de>
And offer an option to show all devices in the settings. This is intentionally
not stored in the preferences as this should never be needed. We don't support
BT or BLE dive computers that we don't recognize. This is a last resort in case
a new firmware were to change the name or some other weird issue causes us not
to recognize a dive computer - and that should be fixed instead of worked
around.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
By default we'll only show devices that we believe to be dive computers,
but the user can override that with the recently introduced check box.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
At least on a Mac we can get here without a discoveryAgent if BT is off,
so don't derefence the NULL pointer in that case.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is an attempt to fix issue #1896. While this seems a Qt issue in
combination with very specific Android devices, this might be a fix. Do
not check for a very specific state of the local BT controller, but just
check if it is powered on.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Just like with the Aqualung i770R in 7697003498 this name follows the
pattern of a model number in ASCII encoding, followed by the serial
number of the device.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The name seems crazy until you realize that FQ is 0x4651 which is the model
number of the i770R. And the six digits are the serial number of the device.
Still crazy, but at least now you understand WHY.
Thanks to Jef for decoding that.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes no sense, but apparently we need to start a fresh scan in order to be able
to talk to a different BLE dive computer on the Mac.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On macOS, we cannot connect to a BT/BLE device until we have scanned it. Right
now this just sits quietly and waits, which given how long this can take is
rather unsatisfying and might look like Subsurface is hung.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
