We don't use them, but they seem to be trying to describe what the
developer fields are used for. We may now parse the developer fields
enough to skip over them gracefully, but it looks like we migth some day
want to _really_ parse them, and while I haven't figured it out (at
all!) yet, this may some day help.
For example, we get things like this:
FIELD_DESCRIPTION_name (STRING): "Depth"
FIELD_DESCRIPTION_unit (STRING): "feet"
FIELD_DESCRIPTION_original_mesg (UINT16): 20
FIELD_DESCRIPTION_data_index (UINT8): 0
FIELD_DESCRIPTION_field_definition (UINT8): 0
FIELD_DESCRIPTION_base_type (UINT8): 136
which doesn't tell me anything at all right now, but looks like maybe it
should some day.
It looks like this is defining a developer field for depth in feet
(duh), and the data format may be the same as a RECORD message (20),
which does indeed normally contain the depth (but in mm as an UINT32,
and it's field number 92, so..)
End result: not useful right now, because I'm much too confused about
it. But the debug printout looks interesting.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Not because we use them, but because it makes it clearer from the debug
output that we know what they are and that they aren't interesting..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This also gets the passing of string values right, even if we don't
actually use this right now.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This was part of me trying to figure out the compressed formats and the
developer fields, it's just noise now.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The ACTIVITY message contains a "local timestamp" in addition to the
regular timestamp. That gives us the timezone information.
Or rather, it would give us the timezone info if we actually used it.
But now we at least parse it, so that we *could* use it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We end up using the FIT file name as the "fingerprint" for the dive, and
include it at the beginning of the dive data as such. And because of
how Garmin encoded the FIT files, we ended up having a fixed 24-byte
length for this, which is normally the date encoding:
YYYY-MM-DD-HH-MM-SS.FIT
with the terminating NUL character.
Of course, then Garmin started using a short-form encoding too
(presumably due to FAT filesystem limits), and we have magic code to
sort the dates properly, using the name format
YMDHMMSS.FIT
with the numbers encoded in a shorter format (eg "C4ND0302.fit" is
equivalent to "2022-04-23-13-03-02.fit"). See name_cmp() and
parse_short_name() for details.
Anyway, because we use the (zero-padded) 24 characters of the name as
the fingerprint, we used a fixed-size buffer for the filename that was
limited to that maximum size Garmin creates.
But then you download those things, and have multiple vendors, and
suddenly that 24-character limit on the filename is very annoying.
Instead of fixing this in some clean and generic way, let's just raise
the namelength limit to something bigger, and continue to use the first
24 characters of the name for the fingerprint.
Pretty it isn't, but it makes it slightly easier to import random FIT
files that don't conform exactly to the traditional Garmin format.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since we can now parse FIT files from other vendors than Garmin (ie the
Suunto FIT file export), let's expose this as a generic "FIT file
import" in the dive computer list.
It's all still very much using the Garmin parser, but uses a model ID
that is zero. The only difference that makes is that it also tells the
parser to treat the result as a dive even if it cannot find the actual
dive markers that Garmin uses, since those won't exist in the limited
FIT file export.
This is still somewhat inconvenient, in that you cannot point to the
file itself, you can just point to the directory that contains FIT
files. And right now we have an artifical length limitation on the
filenames, but I'll fix that next.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This was the _actual_ reason why the Suunto FIT file import fell flat on
its face: it adds records with developer fields in them, and I just had
no idea how to parse them.
It turns out that they aren't all *that* horrible to parse: they are
kind of like a special case of the regular FIT event fields.
And no, this does not really parse them: it only parses the layout, and
using that it can then skip the developer fields without causing the
decoder to go all wonky and lose stream synchronization.
At least it works for the specific case of the Suunto FIT files, and the
code makes some amount of sense. The FIT format may be odd, but at the
same time it's most definitely designed for pretty simplistic devices,
so it's not some kind of crazy XML thing.
This gets us parsing those Suunto FIT files at least partially.
That said, it is all very rough indeed, since you have to lie and claim
you're downloading from a Garmin, and have to set up the whole magic
'Garmin/Activity/' directory structure and limit the file size to the 24
characters that Garmin uses.
So this is by no means the real solution.
Considering that Jef doesn't want the Garmin parser in libdivecomputer
anyway, the proper solution might be to move this all to subsurface, and
make it be a "FIT file import" thing instead. Annoying, but on the
other hand it has also been a bit awkward to have it in libdivecomputer.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This turns out to have been another false turn: mis-parsing the FIT file
caused us to think it had compressed records.
So I spent much too much time trying to figure out how those compressed
records actually work. This is the result.
It looks like the only difference between a compressed record and a
regular one is that the compressed record has a single-byte "this is the
record type and the time offset" field at the start. That basically
avoids the need of then having a full 4-byte absolute time for such a
record.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is an empty stub for the HRM profile message, which isn't actually
used by anything I know of, but came up as a result of some mis-parsing
of odd FIT files generated by the Suunto mobile app.
Losing synchronization in the FIT file then caused the parser to think
it needed this message type, and not having it then caused an early
abort.
While it's not actually needed once parsing things correctly, since I
looked up the message number and name for this message type, let's just
keep it around. It won't hurt, and maybe it avoids me having to look it
up in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of returning an error on unrecognized input when parsing, just
skip to the end of the buffer. This makes at least partially parsed
data available, which can help figure out what ended up happening.
This was part of my "Suunto also does FIT files now, and does them very
differently from Garmin" series. I think I parse the Suunto files right
now, but next time this happens, I'd rather get partial data than no
data at all.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Return `DC_STATUS_UNSUPPORTED` for inactive gas mixes, while retaining
the configured gas information. This makes it possible to mark inactive
gases as such, or completely hide them, without affecting the gas
indices that are referenced in gas switches.
Signed-off-by: Michael Keller <github@ike.ch>
Pull libdivecomputer updates from Michael Keller:
- Add time synchronisation for the Shearwater Teric
- Fix two OSTC4 buglets
* 'add_shearwater_teric_timesync' of https://github.com/mikeller/libdc:
Add Time Synchronisation for the Shearwater Teric.
* 'add_ostc4_dump_error' of https://github.com/mikeller/libdc:
Fix bugs in OSTC4 support.
In commit 1c8cd096b57a876c4fb0afc5113aac05d75d924e the block size was
changed from 64 to 1024 bytes. For bluetooth classic communication, this
shouldn't matter, but for some reason it does cause the OSTC4 firmware
upgrade to fail. Maybe some buffering problem in the OSTC4 firmware or
bluetooth stack?
Change the block size back to 64 bytes.
For open-circuit dives it makes no sense to also include the configured
diluents. Usually those diluents are only present because the diver uses
the same dive computer for both open and closed circuit dives.
Add time synchronisation for the Shearwater dive computers. All models
support setting the local time. Only the Teric has basic support for
time zones, and can set UTC time with a timezone offset.
Co-authored-by: Michael Keller <github@ike.ch>
When the dive computer receives an RDBI or WDBI command it doesn't
support, it sends a 3 byte NAK packet containing an error code. Detect
these NAK packets and use it to return a more appropriate error.
The RDBI (Read Data by Identifier) responses always have a fixed length.
Using a resizable buffer for the API only makes the memory management
more complex than necessary.
Also add some symbolic constants to improve readability.
Fix two bugs in the support for OSTC4:
- change block size for writes back to 64 bytes to prevent buffer
overflow on the dive computer side;
- added 'unsupported' response for the dump command on OSTC4.
Signed-off-by: Michael Keller <github@ike.ch>
Add time synchronisation support for the Shearwater Teric. Unlike the
other Shearwater dive computers this model has basic support for time
zones, so we need to set the time in UTC and configure the time zone
offset.
Signed-off-by: Michael Keller <github@ike.ch>
Merge upstream version 0.8.0 into our libdc fork.
Since we tracked the development branch, we already had merged all the
main changes, but it's been a couple of months since the last upstream
merge, and there were a few new changes upstream:
- Divesoft Freedom and Liberty support
- A couple of iostream abstraction layers: a new 'packet layer' and a
HDLC layer, moving code from low-level dive computer downloaders to
generic iostream layers.
- misc minor updates
* tag 'v0.8.0': (25 commits)
Release version 0.8.0
Fix the date of the v0.7.0 release
Add a missing filter for the Aqualung i750TC
Reduce the BLE output packet size to 20 bytes again
Integrate the new packet I/O in the backends
Add a generic packet I/O implementation
Fix a typo in the documentation
Add support for the Divesoft Freedom and Liberty
Integrate the HDLC stream in the eonsteel backend
Add a generic HDLC I/O implementation
Remove the local endianess functions
Use the correct function to free resources
Add the udev rules to the distribution tarball
Add a README file to the contrib directory
Include the revision in the Visual Studio and Android builds
Don't generate the Windows version resource
Move the Visual Studio project to the contrib directory
Add a basic Android build system
Disable the getopt argument permutation on Android
Move the sign extension function to a common place
...
Add time synchronisation for Shearwater dive computers.
This synchronises the local time, which is all that is supported by all
Shearwater models except for the Teric.
Time synchronisation including the time zone for the Teric still has to
be added.
Signed-off-by: Michael Keller <github@ike.ch>
Replace the numeric type with a name (fresh or salt) and change the
density value into an xml attribute. The type is the primary
information here, while the density value is optional.
The dc_parser_set_data() function allows to re-use a parser object for
multiple dives. The advantages of this feature are actually very limited
in practice. The reduction in memory consumption is almost negligible,
because the amount of internal state in the parser is typically very
small. But the implementation requires some additional complexity
because each backend needs code to reset its internal state. Therefore,
the function is removed and the data and size needs to be passed
directly to the dc_parser_new() and dc_parser_new2() functions instead.
Because keeping a reference to the data has also caused issues in the
past, especially for applications implemented in a garbage collected
language, the data will now also get copied internally.
Only a few dive computer backends (reefnet, aladin and memomouse)
require the clock parameters for parsing the date/time. Therefore,
those parameters are removed from the constructor function and
applications should set the clock parameters with the
dc_parser_set_clock() function instead.
The backend specific calibration function are deprecated. Applications
should use the new replacement functions introduced in commit
6ab140461a3a85fba3803283070427f3be413c79.
Because the sample struct is passed by value, the size of the structure
can't be changed without also changing the function signature and
breaking backwards compatibility. This prevents adding new fields in the
future, to support some new features.
When passing the sample struct by reference using a pointer, the size of
the pointer does always remains the same.
For gas consumption calculations it's very convenient to know whether a
tank is used for example in a sidemount configuration, or as
oxygen/diluent tank on a rebreather.
For rebreather dives, it's convenient to know whether a gas mix is used
as a closed-circuit mix (oxygen/diluent) or as an open circuit mix
(bailout).
Some dive computers report the time of the next decompression stop,
while others report the Time To Surface (TTS). Some models can even
report both.
Add a TTS field to the deco sample to support both values.
Rebreathers typically support multiple ppO2 sensors as a safety measure
in case a sensor fails during the dive. The current api can already
report multiple ppO2 values per sample, but it does not provide any
information about which sensor the measurement is from.
The new sensor index provides this info, and can also be used to
distinguish between the average/voted ppO2 value using the special value
DC_SENSOR_NONE.
After the previous commit changed the resolution of the sample time to
milliseconds, the dive computers which actually support a higher
resoltion can now enable this feature and report all samples.
Some dive computers, especially freediving computers, supports multiple
samples per second. Since our smallest unit of time is one second, we
can't represent this, and the extra samples are dropped. Therefore, the
units are changed to milliseconds to prepare supporting this extra
resolution.
The newer u-Blox Nina B2 bluetooth module supports larger packets up to
244 bytes, but the older Telit/Stollman bluetooth module does not.
Trying to send a packet larger than 20 bytes fails. For maximum
compatibility, limit the output packet size to 20 bytes.
Replace the custom packet handling code in the iconhd and ostc3 backends
with the new layered packet I/O, and also integrate it into the idive
and extreme backends.
The latest versions of the Divesoft Freedom (HW 4.x) and Liberty (HW
2.x) dive computers support BLE communication. Previous generations did
support only a mass storage mode, where the dives are available as DLF
files. The BLE communication protocol uses HDLC framing for the data
packets. The dives downloaded over BLE have the same data format as the
DLF files.
Co-authored-by: Jan Matoušek <jan.matousek@rekomando.cz>
Tested-by: Jakub Hečko <jakub.hecko@divesoft.com>
