Report the number of tank sensors independently of the number of
gasmixes. This fixes an unintuitive error message popping up when
importing dives with more sensors than gasmixes.
Fixes https://github.com/subsurface/subsurface/issues/4221.
Reported-by: @bwong2132
Signed-off-by: Michael Keller <mikeller@042.ch>
The BLE changes in commit e83732e200620882b13804f1ca54c1ab90a38188 are
causing major problems for some of the usb-serial enabled models, like
the Puck Pro and Quad Air.
These models appear to require a small delay of a few milliseconds
between sending the two command bytes and the remainder of the command
payload. I suspect the device is still busy processing those first two
bytes, and thus not ready in time to receive the remaining data. Instead
of manually adding a fixed delay, restore the previous behaviour and
wait for the ack byte again. This has the advantage that the delay is
automatically proportional to the response time of the dive computer.
For the BLE communication nothing changes.
Add the configured stack run time and the remaining stack run time at
the start and end of the dive as extra information.
Signed-off-by: Michael Keller <github@ike.ch>
Remove the timesync function from the code for the Predator - testing
has shown that this function is not supported by this model.
Signed-off-by: Michael Keller <github@ike.ch>
Remove the unused transport filter for the file based Garmin importers,
as it is not used at all in the way that the USB storage transport is
implemented.
Signed-off-by: Michael Keller <github@ike.ch>
Remove the code that forces hiding of O2 sensor readings despite the
sensors being reported as properly calibrated by the divecomputer.
This fixes the problem of no sensor readings showing on DiveCAN
controllers due to the fact that the sensor calibration values are
returned as defaults on these devices.
Also increase the timeout for data reads - this seems to improve the
reliability when reading logs of long dives.
Signed-off-by: Michael Keller <github@ike.ch>
I verified that this bug is breaking the reporting of the serial number on my dive computers as well - they all report as `0`. Merging this as it is affecting a lot of users.
Ignore timestamps on messages that we do not read any other fields from
- with the new (firmware >= 16.x) .fit file format these messages seem
to be sent out of order, causing other messages to be ignored if they
come after them in the file but are before them in the timeline.
Track the OC / CCR state at the beginning of the dive based on the
dive type - this avoids spurious 'switched to ...' messages caused by
new 'gas switch' messages at the beginning of dives.
See also https://forums.garmin.com/developer/fit-sdk/b/news-announcements/posts/important-fit-activity-file-message-change
Signed-off-by: Michael Keller <github@ike.ch>
Add support for the Garmin Descent Mk3(i) models.
This pretty much just updates the entry in the device list to cover Mk2
and Mk3 models.
It does nothing to add support for MTP when reading from an Mk3 model -
I have not been able to get MTP support on linux going reliably, and I
do not have an Mk2 / Mk3 to test with anyway.
I suspect that MTP support is incomplete anyway, as the
product IDs for models like the Mk2S and Mk2G are not detected.
This change also adds an extra info field for the Model (based on a
heuristic and incomplete list).
It also fixes the data type for the sensor_type field.
Signed-off-by: Michael Keller <mikeller@042.ch>
Add support for FIT files generated by the Garmin Descent Mk3.
This just fixes a field number limitation, it has not yet been
verified that the Mk3 file format is properly interpreted by Subsurface.
Signed-off-by: Michael Keller <mikeller@042.ch>
The new models appear to be compatible with the previous G2, but with
new model numbers and bluetooth names. The USB VID/PID for the G3 is
still unknown.
Reported-by: Greg McLaughlin <support@moremobilesoftware.com>
When no compass bearing is set on the dive computer, the stored value is
initialized to zero. Since this can also be a valid value, those zero
values are only ignored untill another non-zero value is present.
In later firmware versions, the value will get initialized to 0xFFFF
instead.
Returning disabled gas mixes to the application mainly results in lots
of unnecessary information. Therefore, remove all disabled gas mixes,
unless they are actively used. Many other dive computers do not even
include disabled gas mixes in the data.
Unlike previously assumed, the on/off state of each gas mix is actually
available in the PNF data format (opening record 4). For the older
Predator data format, this info isn't available and all gas mixes are
manually marked as enabled.
The IX3M 2 with the APOS5 firmware supports a new info record containing
the GPS coordinates. To be able to identify this new record type, the
previously reserved field at byte offset 52 is now used to store the
record type: zero for the existing sample record and one for the new
info record.
This also fixes the underlying problem of the zero timestamp in commit
3c50e91a1096332df66b2d33d64e5a8dc9136ab9, because the zero timestamp was
the result of incorrectly interpreting the first info record as a sample
record.
Previously the timestamp of the first sample was always a non-zero
value, but the IX3M 2 with the APOS5 firmware now appears to record a
timestamp of zero. This was incorrectly detected as a backwards time
jump because the time is also initialized to zero.
Sending the two byte command header and then waiting for the ack byte
before sending the remainder of the command payload causes problems for
some (but not all) users. Most likely the extra roundtrip time due to
waiting for the ack byte results in a delay that sometimes exceeds a
timeout in the dive computer while it's waiting for the payload data.
On the other hand, sending both the command header and the payload data
in one single packet is also not an option, because it causes problems
for some models, like the Mares Matrix. See commit
59bfb0f3189b14ae858650b851539d59e3fefe86 for details.
As an alternative solution, send the packet payload immediately after
the header, without waiting for the ack byte. This eliminates the extra
roundtrip time, while still sending out two separate bluetooth packets.
The functionality provided by the filter function is not only useful for
the built-in transports, but also for the applications. For example in
combination with a custom transport.
The USB I/O backend needs some additional information (e.g. interface
number and in/out endpoints) to setup the USB connection. This info is
currently maintained inside the descriptor filter function and gets
passed to the USB backend by means of the filter parameters.
This approach is not only unnecessary complex, but also makes it very
difficult to expose the filter function in the public api because the
data structures for those parameters are private.
Therefore, this data exchange is replaced with a direct mapping between
the USB VID/PID and the configuration info in the USB backend itself.
Passing the descriptor for which the filter function is being called is
a good practice and will also allow to implement some more specific
filtering in the future.
Returning disabled gas mixes to the application mainly results in lots
of unnecessary information. Therefore, remove all disabled gas mixes,
unless they are actively used. Many other dive computers do not even
include disabled gas mixes in the data.
The removal of the disabled gas mixes requires a two pass approach for
parsing the profile data. The first pass is only used to discover which
gas mixes are actively used during the dive. Next, all disabled and not
actively used gas mixes are removed from the list. Since removing one or
more gas mixes also invalidates the index of the remaining gas mixes,
the profile needs to be parsed again to report the new index in the gas
switch samples.
The original one based index is used as the stable gas mix id, used for
looking up the new gas mix index.
