...rather than use a global variable and a macro.
This should be a no-op in preparation to allow planning
several versions of a dive.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Reportedly the case 2 corresponds to Perdix, so it might be that both
Petrel and Perdix use same model number (or the model is mistaken
before).
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Instead of the (usually incorrect) text about insufficient privileges,
just mention a generic error and suggest that the user creates a
libdivecomputer log file.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Jef made the OSTC interface be a generic 'dc_device_timesync()' and so
the old OSTC-specific code doesn't exist any more.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Simplify and fix prestation of weights. Due to the attempt to round
only the grams part (by just adding 50 to it, and truncating
afterwards) a weird effect was introduced. For example, a value
0.98 was presented as 0.10. Just replay the old logic, and see
what happens. Rewrote the logic to a simpler and better one.
fixes: #532
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
There is something with ndl / tts / temp in the Liberty DLF files. If
that bit is set, the values are bogus. There is something more to it
here which I haven't figured out.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
We always step forward 16 bytes, so make it a for loop so a continue
won't throw us into a eternal loop.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Back when I wrote this code I made a typo. This fixes it.
Reported-By: Alexander Gottwald <jugendtrainingtsck@gmail.com>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When I unified the sample pressures in commit 11a0c0cc70 ("Unify
sample pressure and o2pressure as pressure[2] array") I did all the
obvious conversions, including the conversion of the Poseidon txt file
import:
case POSEIDON_PRESSURE:
- sample->cylinderpressure.mbar = lrint(val * 1000);
+ sample->pressure[0].mbar = lrint(val * 1000);
break;
case POSEIDON_O2CYLINDER:
- sample->o2cylinderpressure.mbar = lrint(val * 1000);
+ sample->pressure[1].mbar = lrint(val * 1000);
break;
which was ObviouslyCorrect(tm).
But as so often is the case, obvious doesn't actually exist. The old
"o2cylinderpressure[]" model had an implicit sensor associated with it,
and that implicit sensor mapping wasn't obvious, and didn't get fixed.
It turns out that the way the Poseidon sensor mapping works, the O2
cylinder is cylinder 0, and the diluent cylinder is cylinder 1, so just
use the add_sample_pressure() helper to set both sensor index and
pressure value.
And since we now do all the sensor indexing right, we can also get rid
of some manual cylinder sample pressure code, because the generic dive
fixup will just DTRT. It used to screw up because the diluent sensor
number was wrong before, and the import code tried to work around that
by hand.
Reported-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
...even when not showing transitions, this makes the
first stop look more like a stop (since it does not include
several minutes of ascent).
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Calling access() makes no sense at all on android, but this atleast
fixes a compilation error on ndk 15+.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
In the serial api for libdivecomputer is ok to send NULL as the int
pointer actual, if you dont't care about how many bytes that where
actually read or written.
This makes sure we don't crash if the ble backend where ever used with
such a backend.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
So the manual gas pressure case keeps showing issues, and in many ways it
really is a fairly complex thing, since it needs interpolation of the
intermediate pressures - possibly over several gas changes.
So you might have beginning and ending pressures for one cylinder, but
then use another cylinder in between.
We've historically got all the code to do this, but the big rewrite for
multiple cylinder pressures didn't get all the details right, and so
here's a few more fixes for the case that was shown by a dive by Robert
Helling. Hopefully we're approaching the old code situation, except now
with concurrent gas pressure handling support.
Reported-by: Robert Helling <helling@atdotde.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The core to plot manually entered pressures without any sample data did
the obvious thing: it ended the pressures at the end of the dive as
indicated by the last sample.
However, that obvious thing didn't actually work, because sometimes the
last sample is long long after the dive has actually ended, and we have
no plot_info data for that.
This depends on the dive computer used: most dive computers will not
report samples after the end (even if they may internally remember them
in case the diver just came up to the surface temporarily), but some
definitely do. The OSTC3 is a prime example of that.
Anyway, the code was fragile and wrong - even if passed a time past the
end of the plot_info data, "add_plot_pressure()" should just have
associated that with the last entry instead. Which also allows us to
simplify the whole endtime logic entirely, and just use INT_MAX for it.
Gaetan Bisson's test-case also showed another oddity: we would plot the
gas pressure even for cylinders that had no has use (ie beginning and
ending pressures were the same). That's kind of pointless in so many
ways. So limit the manual pressure population to cylinders that
actually have seen use.
Reported-by: Gaetan Bisson <bisson@archlinux.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The Google Maps API V3 *does* require a key if one needs to generate
a lot of payed trafic and monitor said trafic, otherwise it doesn't:
https://stackoverflow.com/a/8785844
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The creation of a cloud account from mobile was broken. This fixes
it. Basically, we need to go online for a moment, and setup a correct
local and remote repo for the cloud storage.
Tested for the following scenarios: 1) inital account creation
including PIN handling from mobile, from a clean install .
2) open an already validated cloud account from a clean install.
3) open no-cloud style local account.
4) Switch between 2 already validated could accounts.
5) Try to create a cloud account without data connection.
Notice that scenario 4) does not work perfectly. A restart of
the app is needed to see the new logbook. So that is to be fixed.
Scenario 5) seems a non realistic corner case. This does not work
in a gracefull way. The user needs to remove the app, install it
again, and retry with data connection.
Further notice this is backgroud/core processing only. So no QML UI
changes as proposed (for example) bij Davide.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
strstr is a case sensitive compare and the string reported from
libgit2 reads "reference" and not "Reference". Further investigation
reveals commit 909d5494368a0080 of libgit2. Here, the change is
made from Reference to reference, breaking our rather poor way
of detecting something from an error string. So, to be future-proof
to more libgit2 oddities, it might be wise to use strcasestr
in this situation. But this seems a not fully supported variant of
strstr, so leave it at this point.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The other pressure sensors were disabled on import because we didn't use
to handle multiple sensors well at all.
Now it "JustWorks(tm)".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
"If it hasn't been tested, it doesn't work".
All my testing of the multiple sensor pressures have been with some
reasonably "interesting" dives: they actually *have* sensor pressures.
But that test coverage means that I missed the truly trivial case of
just having manual pressures for a single cylinder.
Because there's only a single cylinder, it doesn't have any cylinder
changes, and because there were no cylinder changes, it never filled in
the use range for that cylinder.
So then it never showed the pressure profile at all.
Duh.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The momentary SAC rate got broken by the multiple ressure handling too,
and always used just the first cylinder.
This uses the new "get_gasmix()" helper to see what you're breathing,
and will do the SAC rate over all the cylinders that contain that gas.
So it should now DTRT even for sidemount diving (assuming you had the
same gas in the sidemount cylinders).
NOTE! We could just do the SAC rate over *all* the gases you have
pressures for, and maybe that's the right thing to do. The ones you are
not breating from shouldn't have their pressure change. But maybe some
people add their drysuit argon gas to the gas list?
So this may need more work, but it's a step in the right direction.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In commit e1b880f4 "Profile support for multiple concurrent pressure
sensors" I had mindlessly hacked away at some of the sensor lookups from
the plot entries to make it all build, and forgotten about my butchery.
Thankfully Jan and Davide noticed in their multi-cylinder deco dives
that the deco calculations were no longer correct.
This uses the newly introduced "get_gasmix()" helper to look up the
currently breathing gasmix, and fixes the deco calculations.
Reported-and-tested-by: Jan Mulder <jlmulder@xs4all.nl>
Reported-by: Davide DB <dbdavide@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We have a few places that used to get the gasmix by looking at the
sensor index in the plot data, which really doesn't work any more.
To make it easier for those users to convert to the new world order,
this adds a "get_gasmix()" function. The gasmix function takes as its
argument the dive, the dive computer, and the time.
In addition, for good performance (to avoid looping over the event list
over and over and over again) it maintains a pointer to the next gas
switch event, and the previous gas. Those need to be initialized to
NULL by the caller, so the standard use-case pattern basically looks
like this:
struct gasmix *gasmix = NULL;
struct event *ev = NULL;
loop over samples or plot events in increasing time order: {
...
gasmix = get_gasmix(dive, dc, time, &ev, gasmix);
...
}
and then you can see what the currently breathing gas is at that time.
If for some reason you need to walk backwards in time, you can just pass
in a NULL gasmix again, which will reset the event iterator (at the cost
of now having to walk all the events again).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This finally handles multiple cylinder pressures, both overlapping and
consecutive, and it seems to work on the nasty cases I've thrown at it.
Want to just track five different cylinders all at once, without any
pesky gas switch events? Sure, you can do that. It will show five
different gas pressures for your five cylinders, and they will go down
as you breathe down the cylinders.
I obviously don't have any real data for that case, but I do have a test
file with five actual cylinders that all have samples over the whole
course of the dive. The end result looks messy as hell, but what did
you expect?
HOWEVER.
The only way to do this sanely was
- actually make the "struct plot_info" have all the cylinder pressures
(so no "sensor index and pressure" - every cylinder has a pressure for
every plot info entry)
This obviously makes the plot_info much bigger. We used to have
MAX_CYLINDERS be a fairly generous 8, which seems sane. The planning
code made that 8 be 20. That seems questionable. But whatever.
The good news is that the plot-info should hopefully get freed, and
only be allocated one dive at a time, so the fact that it is big and
nasty shouldn't be a scaling issue, though.
- the "populate_pressure_information()" function had to be rewritten
quite a bit. The good news is that it's actually simpler now, although
I would not go so far as to really call it simple. It's still
complicated and suble, but now it explicitly just does one cylinder at
a time.
It *used* to have this insanely complicated "keep track of the pressure
ranges for every cylinder at once". I just couldn't stand that model
and keep my sanity, so it now just tracks one cylinder at a time, and
doesn't have an array of live data, instead the caller will just call
it for each cylinder.
- get rid of some of our hackier stuff, like the code that populates the
plot_info data code with the currently selected cylinder number, and
clears out any other pressures. That obviously does *not* work when you
may not have a single primary cylinder any more.
Now, the above sounds like all good things. Yeah, it mostly is.
BUT.
There's a few big downsides from the above:
- there's no sane way to do this as a series of small changes.
The change to make the plot_info take an array of cylinder pressures
rather than the sensor+pressure model really isn't amenable to "fix up
one use at a time". When you switch over to the new data structure
model, you have to switch over to the new way of populating the
pressure ranges. The two just go hand in hand.
- Some of our code *depended* on the "sensor+pressure" model. I fixed all
the ones I could sanely fix. There was one particular case that I just
couldn't sanely fix, and I didn't care enough about it to do something
insane.
So the only _known_ breakage is the "TankItem" profile widget. That's
the bar at the bottom of the profile that shows which cylinder is in
use right now. You'd think that would be trivial to fix up, and yes it
would be - I could just use the regular model of
firstcyl = explicit_first_cylinder(dive, dc)
.. then iterate over the gas change events to see the others ..
but the problem with the "TankItem" widget is that it does its own
model, and it has thrown away the dive and the dive computer
information. It just doesn't even know. It only knows what cylinders
there are, and the plot_info. And it just used to look at the sensor
number in the plot_info, and be done with that. That number no longer
exists.
- I have tested it, and I think the code is better, but hey, it's a
fairly large patch to some of the more complex code in our code base.
That "interpolate missing pressure fields" code really isn't pretty. It
may be prettier, but..
Anyway, without further ado, here's the patch. No sign-off yet, because I
do think people should look and comment. But I think the patch is fine,
and I'll fix anythign that anybody can find, *except* for that TankItem
thing that I will refuse to touch. That class is ugly. It needs to have
access to the actual dive.
Note how it actually does remove more lines than it adds, and that's
despite added comments etc. The code really is simpler, but there may be
cases in there that need more work.
Known missing pieces that don't currently take advantage of concurrent
cylinder pressure data:
- the momentary SAC rate coloring for dives will need more work
- dive merging (but we expect to generally normally not merge dive
computers, which is the main source of sensor data)
- actually taking advantage of different sensor data from different
dive computers
But most of all: Testing. Lots and lots of testing to find all the
corner cases.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This does both the XML and the git save format, because the changes
really are the same, even if the actual format differs in some details.
See how the two "save_samples()" routines both do the same basic setup,
for example.
This is fairly straightforward, with the possible exception of the odd
sensor = sample->sensor[0];
default in the git pressure loading code.
That line just means that if we do *not* have an explicit cylinder index
for the pressure reading, we will always end up filling in the new
pressure as the first pressure (because the cylinder index will match the
first sensor slot).
So that makes the "add_sample_pressure()" case always do the same thing it
used to do for the legacy case: fill in the first slot. The actual sensor
index may later change, since the legacy format has a "sensor=X" key value
pair that sets the sensor, but it will also use the first sensor slot,
making it all do exactly what it used to do.
And on the other hand, if we're loading new-style data with cylinder
pressure and sensor index together, we just end up using the new semantics
for add_sample_pressure(), which tries to keep the same slot for the same
sensor, but does the right thing if we already have other pressure values.
The XML code has no such issues at all, since it can't share the cases
anyway, and we need to have different node names for the different sensor
values and cannot just have multiple "pressure" entries. Have I mentioned
how much I despise XML lately?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We had a "add_sample_pressure()" helper functions that was local to just
the libdivecomputer downloading code, but it really is applicable to
pretty much any code that adds cylinder pressure data to a sample.
Also add another helper: "legacy_format_o2pressures()" which checks the
sample data to see if we can use the legacy format, and returns the o2
pressure sensor to use for that legacy format.
Because both the XML and the git save format will need a way to save the
compatible old-style information, when possible, but save an extended
format for when we have data from multiple concurrent sensors.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Independ of the settings, the threshold to reset the GPS data was
hard coded to 5 minutes. Now, honour the entered (and updated during
a session) time to refresh the GPS data in the location service.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This tries to sanely handle the case of a dive computer reporting
multiple cylinder pressures concurrently.
NOTE! There are various "interesting" situations that this whole issue
brings up:
- some dive computers may report more cylinder pressures than we have
slots for.
Currently we will drop such pressures on the floor if they come for
the same sample, but if they end up being spread across multiple
samples we will end up re-using the slots with different sensor
indexes.
That kind of slot re-use may or may not end up confusing other
subsurface logic - for example, make things believe there was a
cylidner change event.
- some dive computers might send only one sample at a time, but switch
*which* sample they send on a gas switch event. If they also report
the correct sensor number, we'll now start reporting that pressure in
the second slot.
This should all be fine, and is the RightThing(tm) to do, but is
different from what we used to do when we only ever used a single
slot.
- When people actually use multiple sensors, our old save format will
start to need fixing. Right now our save format comes from the CCR
model where the second sensor was always the Oxygen sensor.
We save that pressure fine (except we save it as "o2pressure" - just
an odd historical naming artifact), but we do *not* save the actual
sensor index, because in our traditional format that was always
implicit in the data ("it's the oxygen cylinder").
so while this code hopefully makes our libdivecomputer download do the
right thing, there *will* be further fallout from having multiple
cylinder pressure sensors. We're not done yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
good (1) = 5
medium (2) = 3
bad (3) = 1
There seems also to be 0 used in the log, even though it is not
mentioned in the valid selections. This is not giving any stars for this
option...
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Note that I have not been able to do a positive test for this due to
lack of CCR sample data. But at least OC dives are now categorized
correctly.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
"cur_dc" may be NULL when the XML source isn't a subsurface XML file,
and xml parsing is supposed to use "get_dc()" to pick a dive computer
when the nesting of the XML may not be proper.
Now, XML sources that don't have the proper dive computer nesting
markers generally also do not end up having the extra-data string
information, but one example of this is the simple XML that the
libdivecomputer 'dctool' program generates.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Our "get_has_used()" helper only filled in gas usage for cylinders that
had a gas change event associated with them. That works really badly
for things like CCR, but also simply for cases where the dive computer
wasn't necessarily explicitly notified about usage, like sidemount
diving etc.
Just remove the logic. If some use ends up particularly wanting to
ignore some cylinder, they can always do it in the caller instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Because of how we traditionally did things, the "o2pressure" parsing
depends on implicitly setting the sensor index to the last cylinder that
was marked as being used for oxygen.
We also always defaulted the primary sensor (which is used for the
diluent tank for CCR) to cylinder 0, but that doesn't work when the
oxygen tank is cylinder 0.
This gets that right at file loading time, and unifies the xml and git
sample parsing to make them match. The new defaults are:
- unless anything else is explicitly specified, the primary sensor is
associated with the first tank, and the secondary sensor is
associated with the second tank
- if we're a CCR dive, and have an explicit oxygen tank, we associate
the secondary sensor with that oxygen cylinder. The primary sensor
will be switched over to the second cylinder if the oxygen cylinder
is the first one.
This may sound backwards, but matches our traditional behavior where
the O2 pressure was the secondary pressure.
This is definitely not pretty, but it gets our historical files working
right, and is at least reasonably sensible.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we load sample data from a git save-file, we always default to
using the state from the previous sample (except for the special case of
cylinder pressure where an empty value does not mean "same", but
"interpolate", see core/load-git.c: new_sample()).
But the corollary to that is that it's always redundant to save sample
data that hasn't changed since the previous sample.
For some reason, the rbt, bearing and heartrate sample data didn't
follow that rule, and instead saved with lots of extra reduncancy.
(The alternative would be to clear those samples at load time, and make
them act like the pressure data, but it would appear that all these
three values may as well just have the normal "if no change, don't save
them" semantics).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a very timid start at making us actually use multiple sensors
without the magical special case for just CCR oxygen tracking.
It mainly does:
- turn the "sample->sensor" index into an array of two indexes, to
match the pressures themselves.
- get rid of dive->{oxygen_cylinder_index,diluent_cylinder_index},
since a CCR dive should now simply set the sample->sensor[] indices
correctly instead.
- in a couple of places, start actually looping over the sensors rather
than special-case the O2 case (although often the small "loops" are
just unrolled, since it's just two cases.
but in many cases we still end up only covering the zero sensor case,
because the CCR O2 sensor code coverage was fairly limited.
It's entirely possible (even likely) that this migth break some existing
case: it tries to be a fairly direct ("stupid") translation of the old
code, but unlike the preparatory patch this does actually does change
some semantics.
For example, right now the git loader code assumes that if the git save
data contains a o2pressure entry, it just hardcodes the O2 sensor index
to 1.
In fact, one issue is going to simply be that our file formats do not
have that multiple sensor format, but instead had very clearly encoded
things as being the CCR O2 pressure sensor.
But this is hopefully close to usable, and I will need feedback (and
maybe test cases) from people who have existing CCR dives with pressure
data.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We currently carry two pressures around for all the samples and plot
info, but the second pressure is reserved for CCR dives as the O2
cylinder pressure.
That's kind of annoying when we *could* use it for regular sidemount
dives as the secondary pressure.
So start prepping for that instead: don't make it "pressure" and
"o2pressure", make it just be an array of two pressure values.
NOTE! This is purely mindless prepwork. It literally just does a
search-and-replace, keeping the exact same semantics, so "pressure[1]"
is still just O2 pressure.
But at some future date, we can now start using it for a second sensor
value for sidemount instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Some Petrel 2 computers are dual stack. We need to list the Petrel here as well
since the Petrel 2 actually identifies itself via BT/BLE as Petrel and we can't
tell them appart until after we started a download.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is both correct (many Perdix support BLE) and necessary
as the Perdix AI identifies itself (sadly) as Perdix.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The adapted define was confusingly wrong. Apparently, the BUFSIZ
define was coming from some include file, and was dependent on
platform (Linux 8K, Andorid 1K). Simple rewrite to a new define
and a proper value for both Linux and Android. If 4K is big
enhough, is a little uncertain, as its depends on the read
behavior of all libdivecomputer parsers using this serial
BLE interface.
The buffer size needed (on read, as that is the most prominent
direction when interfacing with DCs) is (most likely) 2x the
maximum block the libdc parsers request at once. I did not
study all parsers, but the Shearwater parser request 20 bytes
at once (we know that from the 1 packet at the time read, we
had before). The OSTC parser request 1K blocks for data
that is longer than 1K (like profiles, header tables).
The 1K we had on Android was working for Shearwater,
Eon Steel, but not for OSTC,as its reads 1K at the time
at max, and overflowing the buffer.
So 32k or 64k seems way to big (as in, much bigger than
any libdc read).
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
No idea why this now shows up as an error in the iOS build.
We need to refer to the typedef, not the underlying struct.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Apparently, OSTC Sport has a BT name like OSTCs<space><serial>.
Small code addition to detect this properly. As long as we
do not have an improved way of detection. Notice that most of
the HWs use the same BT hardware, so simple detection on offered
services will not work.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
See also b409e9fc91 and 709c1df2af. The OSTC parser
cannot handle reads of single 20 byte BLE packages in serial mode.
Instead of doing a deeper down agressive read, we can read on
the serial level more subtile. As the parser is requesting a
specific number of bytes, we just read that number of bytes and
return them. As the 20 byte BLE packets do (obviously) not
align with the reading requirement of the libdc parser, a little
housekeeing needs to be done in between individual reads.
CAVEAT 1: In contradiction to 709c1df2af, this is supposed to
work for all parsers that properly specify the needed bytes to fetch.
CAVEAT 2: All above tested on Linux Desktop with bluez stack.
Subsurface mobile is step 2.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Commit 709c1df2af introduced a hard blocking read for BLE devices.
This did break BLE reads from multiple DCs, and (in hindsight) was not
a correct implementation. It would require, for example, dynamic
read buffers as especially profile data grows with dive time, and
in addition, and more importantly, also the OSTC libdc parser cannot
process the entire profile of a dive at once (but likes to receive
it in 1K blocks). So, basically, it introduced issues, and did not
solve the OSTC read.
This commit reverts this hard blocking read (and as such will break
OSTC BLE reads). But it enables removal of the special cases for
the EON Steel and G2.
A next commit will solve OSTC BLE reads.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Handle credits. Do not just ask for maximum credits all the time as this
will stop the download. Also do not let the credits go back to 0 (while
this might work, this is not tested). Getting back the 0 credits stops
the download, and even when it can be restarted, it is less efficient
(and not needed). Notice also that it takes some time before a grant
request is honoured. During testing I saw reception of up to 25 packets
between request and grant. So a lower bound for the request of
32 packets seems resonable.
One aspect the Telit/Stollmann TIO puzzeled me. Sections 4.1 and 4.2
both talk about credits, but my hyphothesis is that there are two
credits counters in play. One for traffic either way. This commit
only deals with credits granted by Subsurface to the OSTC to send
data. Credits granted by the OSTC to allow Subsurface to send new
commands is NOT part of this commit, and is seemingly not needed
in our scenario. As we only send new commands to the OSTC when
a previous one is finished (per HW's interface spec), the OSTC
does not run out of credits to receive commands.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
While it's nice to have the numerical model in the logfile,
on the screen the user wants to see the dive computer product
name. And none of those hex numbers that make the text so long
that it becomes useless.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This reverts commit ed43b5dced ("Add
support for tank sensor battery for Perdix AI") since a much better
solution to get to that information has been implemented in
libdivecomputer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We use a little script to create the code snippet. This script in return
relies on comments that were added to the latest libdivecomputer source
(in the Subsurface-branch).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a bit awkward with a VENDOR event - but at the time the strings
are generated, we don't have the information, yet, that we need to
determine these values (we need the last sample parsed, but the strings
are created as part of the dive headers.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
