If the first attempt fails, that might indicate the device isn't ready
yet to service requests. In that case immediately retrying again isn't
the right solution. Adding a small delay seems to increase the success
rate, so it's a good idea anyway, regardless of the underlying reason.
The application shouldn't have to deal with the maximum number of
retries. If the default value isn't good enough, that should be fixed
internally and not on the application side.
The d9 backend already reads the version info, to autodetect the
protocol variant. When doing the same in the vyper2 backend, we don't
have to read the version info again when downloading the dives.
The hardcoded version strings are now grouped into arrays, according to
their corresponding layout descriptor. The main advantage of using
arrays is that new versions strings can now easily be added, without
having to modify any code.
The Nemo Wide 2 uses the same communication protocol as the Icon HD,
except for two differences:
The Nemo Wide 2 requires a different baudrate and parity setting.
Unfortunately it doesn't seem possible to autodetect the correct
protocol variant at runtime. Attempting to proceed with incorrect
settings will render the device unresponsive and requires a battery
reset to recover.Therefore the model code needs to be provided as an
extra parameter, when opening the connection.
The Nemo Wide 2 also appears to have trouble downloading the entire
memory with a single request. Therefore the single large request is
split into many smaller ones. The offical Mares application uses 256
byte packets, and so do we. The Icon HD keeps using the large packets
because they are significant faster.
The extra model parameter breaks backwards compatibility!
The Petrel is slightly different from the Predator because the device
reorders the internal ringbuffer before sending the data. The most
recent dive is always the first one, and there is no need to search for
it, like we have to do for the Predator.
Apparantly, the windows wingdi.h header file already defines the
ERROR macro. By defining the NOGDI macro before including the
windows.h header file, we can prevent the wingdi.h file from being
included and thus avoid the warning. We don't need that header for
anything anyway.
Because the libusb header file includes the windows.h file
explicitly, it needs the same fix.
The recently introduced CNS support caused a regression for older
firmware versions. If a firmware doesn't support a certain sample
yet, the corresponding sample divisor and size are both equal to
zero (the default value for unused bytes). However, because the
size was always checked, regardless of whether the sample is
actually present or not, this zero size caused the parsing to fail.
To fix the regression, the size is now only checked when the
divisor indicates the sample is actually present.
The example application is updated to support the new setpoint,
ppO2, CNS and decompression samples that have been introduced. The
NDL event is removed again.
Having these as events seems less useful since for many dive computers
there are data with every sample - so it makes much more sense to have
these as part of the sample.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far only OSTC and Shearwater Predator are supported. For the OSTC we
support CNS and setpoint changes in the samples (the current hardware
doesn't actually support ppO2 sensors and for the older hw that does I
don't have the correct encoding information).
For the Predator we support only the "average ppO2 during the sample".
The Predator also gives us a CNS value at the end of the dive - I don't
quite know yet how to deliver that back to the consumer. Possibly as CNS
value in the very last sample? That would at least be consistent.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The Shearwater Predator has two different sets of gas mixes for OC
(Open Circuit) and CC (Closed Circuit) mode. Since the dive mode can
be switched during the dive (e.g. in a bailout scenario), there is no
easy way to select one of both sets. With this change, both sets are
returned. It's not a perfect solution, but for CC dives it's already
an improvement.
The Uwatec Smart protocol supports reading individual settings. However
the version functions only reads those three values that we use
internally (model, serial number and device clock). That's a very
arbitrary subset and it would be much better to support reading
specific values. But that's something for later...
The version function requires device specific knowledge to use it (at
least the required buffer size), it is already called internally when
necessary, and only a few backends support it. Thus there is no good
reason to keep it in the high-level public api.
These macros are used internally and don't need to be exposed. In some
cases, the actual values are not even constant, but dependant on the
model and/or the firmware version.
The exact OSTC variant can be detected by means of the serial number.
Each of the three variants is now assigned an artifical model number,
and included explicitly in the list of supported models.
Apparently some older firmware versions don't support the salinity
setting. Because unused bytes are initialized with zero, the salinity
value will be reported as being zero.
To fix this unexpected value, the salinity factor is first checked for
valid values. If the value is out of range, a DC_STATUS_UNSUPPORTED
error is returned to indicate the absence of the value.
Apparently some older firmware versions don't support the salinity
setting. Because unused bytes are initialized with zero, the salinity
adjustment results in a division by zero, which converts all depth
values to infinity.
To fix this regression, the salinity factor is first checked for valid
values. If the value is out of range, no salinity adjustment is done,
and the previous behaviour is retained.
Update the example application to support the new salinity and
atmosperic pressure fields. Because the new fields are not supported by
all backends, they are only included in the output when available.
There appears to be two very different versions of the Sherwood Insight.
The old Insight needs the veo250 backend, while the newer Insight 2
needs the atom2 backend. Currently only the newer version was included
in the list of supported devices, and to increase the confusion it was
even named after the old version.
With this patch, the old version is added to the list, and the new
version is renamed to "Insight 2".
- PO2 warnings (high and low both mapped to the same SAMPLE_EVENT_PO2
event)
- SPEED warning (which according to hw isn't emitted at this point)
- Deco stop violations (both deep and regular mapped to same
SAMPLE_EVENT_CEILING event)
- Deco ceiling and time (this is reported as a series of
SAMPLE_EVENT_DECOSTOP events with packed deco stop depth (in m) and
time (in seconds)
A SAMPLE_EVENT_NDL event (with an optional value indicating the non-stop
time remaining) indicates that the ceiling has been resolved
- Gas change (reported as SAMPLE_EVENT_GASCHANGE2, using another
unfortunate O2% / He% semantic that is used in the
SAMPLE_EVENT_GASCHANGE
This also covers the manual gas set event of the OSTC
- Manual Marker (reported as SAMPLE_EVENT_BOOKMARK)
The two new events (SAMPLE_EVENT_GASCHANGE2 and SAMPLE_EVENT_NDL are added
to the universal app as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This now uses the same formula as the OSTC uses internally which will get
the values reported by libdivecomputer to be consistent with what is
displayed on the OSTC.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When the gas model setting is set to air, the individual gas mix
definitions retain their previous (non-air) values. This is convenient
to avoid having to adjust the gas mixes again on your next nitrox or
mixed gas dive. But the consequence is that for air dives, the gas model
should take precedence over the individual gas mix definitions, and a
single mix with air is returned instead.
We received data from a device where the end-of-profile marker is
missing. Because the device fails to locate the last dive, it goes into
an infinite loop, and keeps sending the same sequence of dives over and
over again. As a result, we receive more data than expected, and the
assert in the progress event is triggered.
We now keep track of the maximum number of bytes remaining and abort
once the limit is passed. The values of the progress events are capped
at the maximum value to avoid the assertion.
