When libusb uses the Windows HID api internally, it does automatically
prepend a zero report ID to the data for devices which support only a
single report. But apparently it also returns a size of one byte extra!
As a workaround, the number of bytes is limited to the actual size.
See commit c9ed92d3f55c259931527a27d018eb5791a176dd for a similar issue
in the hidapi library.
The Windows HID api always expects to receive a fixed size buffer
(corresponding to the largest report supported by the device). But
unlike the hidapi library, the libusb library doesn't automatically pad
the buffer to the expected size when trying to send less bytes. Thus
when trying to submit the transfer, the underlying Windows api call
immediately fails with ERROR_INVALID_PARAMETER.
To workaround this problem, pad the data packet with zeros manually and
always send the entire packet (1 byte report ID and 32 bytes payload).
At the time support for the Orca and iDive series was implemented, they
were being sold under the "DiveSystem" brand. But nowadays, the newer
iDive and iX3M series are being sold under the "Ratio" brand. Since this
frequently confuses end-users, let's rename the libdivecomputer vendor
name as well.
The Orca and the original iDive series remain under the DiveSystem
brand.
The parameters used with the FTDI USB serial port drivers didn't work
well with directly with libftdi1. The new baud rate results in the same
effective baud rates for both.
The rbstream block size was reduced to help with the unreliability of
the libftdi communications.
Using FTDI for custom I/O resulted in very unrealible reads. This patch
allows more reliable use of FTDI custom I/O, like what might be needed
when used on a mobile device like Android.
[Jef Driesen: Modified to retry only for non-fatal errors. This simply
restores the code from commit b3d2c603ddec9758fb36706bbde46ce23ca9f0ed,
which was removed in commit 55e8f83eb5d934e65fbf587d427de267f174c651.]
With the new APOS4 firmware, the latest ix3m and idive models support a
wireless tank sensor. For dives without a tank pressure sensor, the
pressure field in the sample is zero. Thus the first non-zero value
indicates the presence of a tank sensor.
Those two samples are no longer unknown. The first one contains some
freedive related data, and the second one contains some additional data
with several sub types. At the moment only the tank and gas mix info is
used.
In the trimix data format, the tank and gas mix information is no longer
stored in the header, but in a special sample. Because this sample is
usually located at the end of the profile, the info isn't available yet
during the first pass. Hence the need for a second pass.
Without this change, the tank and gas mix samples will be missing unless
the caller calls the dc_parser_get_field() function before calling the
dc_parser_samples_foreach() function.
The trimix dive header is only 84 bytes large, instead of 0xB1 bytes.
The difference is quite hard to notice, because compared to the normal
Galileo data format, the majority of the fields are located at exactly
the same offset. But there are also some subtle differences, like the
settings field containing the freedive and gauge bits.
To fix this bug, a new header table is added. The rest of the code is
updated to use this new table instead of the old trimix flag. The only
place where the old flag is still used is for the decoding of the tank
and pressure sample.
Allthough most dive computers always use local time and don't support
timezones at all, there are a few exceptions. There are two different
sources of timezone information:
- Some of the newer Uwatec/Scubapro devices use UTC internally and also
support a timezone setting. This UTC offset is currently taken into
account to obtain the dive date/time, but the UTC offset itself is
lost.
- Uwatec/Scubapro and Reefnet devices rely on the clock of the host
system to synchronize the internal device clock and calculate the
dive date/time. The consequence is that the resulting date/time is
always in the timezone of the host system.
In order to preserve this timezone information, the dc_datetime_t
structure is extended with a new "timezone" field, containing the UTC
offset in seconds. Devices without timezone support will set the field
to the special value DC_TIMEZONE_NONE.
The dc_datetime_localtime() and dc_datetime_gmtime() functions will
automatically populate the new field with respectively the local
timezone offset and zero. The dc_datetime_mktime() function will take
into account the new timezone field for the conversion to UTC. The
special value DC_TIMEZONE_NONE is interpreted as zero.
Being able to synchronize the dive computer clock with the host system
is a very useful feature. Add the infrastructure to support this feature
through the public api.
On Windows, the hidapi library uses the standard Microsoft USB HID
driver, while libusb requires the installation of a different driver
(WinUSB or libusbK). But installing one of the libusb drivers breaks
compatibility with other applications using hidapi (Scubapro LogTRAK and
Suunto DM5) because only one driver can be active. Switching
libdivecomputer to hidapi avoids this problem.
On Linux, the hidapi library doesn't seem to offer any advantages over
libusb. Most distributions don't even have the hidapi library installed
by default. Because there are usually two variants of the hidapi library
available on Linux (hidapi-libusb and hidapi-hidraw), the autotools
build system won't be able to detect it out-of-the-box, and will
automatically fallback to the libusb implementation.
On Mac OS X, hidapi is already the default (and also the only option).
The Windows HID api always expects to receive a fixed size buffer
(corresponding to the largest report supported by the device). Therefore
the hidapi library internally pads the buffer with zeros to the expected
size, but apparently it also returns the size of the padded buffer! As a
workaround the number of bytes is limited to the actual size.
The hidapi read and write functions return a negative value if an error
occurs. Those negative values should not be returned to the caller as
the actual number of bytes (or used in the logging). The value is reset
to zero instead.
The zero report ID byte is required when using the hidapi library. We
just never noticed this problem before, because we use libusb by
default, and libusb doesn't need the extra zero byte.
The hidapi library requires that the first byte contains the report ID.
For devices which support only a single report, the report ID byte
should be zero. The remaining bytes contain the actual report data.
Now, when hidapi uses libusb internally, it strips the zero report ID
byte again before passing the data to libusb. Thus in order to remain
compatible with the hidapi based implementation, our libusb based
implementation should do the same.
The correct name for the OSTC 3+ is OSTC Plus nowadays. Allthough the
exact name doesn't really matter because all OSTC3 based models are
compatible, using the correct name should reduce confusing for
end-users.
I received a bug report from a device which failed to download new dives
after a reset (probably caused by an empty battery). This reset appears
to reset the internal dive counter back to zero, and also resets the
write pointer back to the begin of the logbook ringbuffer, but leaves
the existing logbook entries in place. The result is that the logic to
find the most recent dive based on the highest internal dive counter,
will be wrong because it finds those old entries.
The discovery of the logbook (and profile) write pointers eliminates the
need to search for the most recent logbook entry.
I dived the model enough to wrap the profile buffer and I was wrong
about where the end was. Also, the buffer starts 3 bytes after where it
could. We were treating profile pointers as 4 bytes when they are two
bytes. This worked most of the time when short tissues were clear
(tissue load follows the pointer).
The Cochran Commander TM appears to be a first generation Commander with
limited storage and function compared to later models.
The main differences are:
- The TM doesn't support high-speed transfer so use the 0x05 read
command and don't change to a higher baud rate. Still reset to 9600
to wait for the heartbeat.
- The TM has a different config command (one byte).
- The TM has only one config page.
For previously supported Cochran computers high-speed read of log and
profile data started at byte 0. Older models that lack the high-speed
transfer function use the standard speed read commands and so the log
and profile data are read at higher addresses.
Since moving to per-dive download of profile data (and now rbstream
download) the data->sample_data_offset and data->sample_size variables
aren't used so calculating them doesn't make sense.
The progress bar was taking 18 seconds between updates on a Commander II
when using a 128K pagesize. Since devices differ in their baud rates, it
makes sense to use smaller pages on slower devices. This change reduces
it to 32K on a Commander II and to 64K on EMC devices.
