It works like the G2, but has a different model number, and different USB device ID.
Lots-of-testing-by: Vincent <vavincavent@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge with Jef's upstream libdivecomputer:
- some OSTC parsing fixes, including getting the initial CNS into the
first sample
- syntactic cleanups to the Scubapro Aladin Sport Matrix support to
match upstream
* git://git.libdivecomputer.org/libdivecomputer:
OSTC: initialize initial CNS from header
Use an out-of-range value as undefined
Support for the Scubapro Aladin Sport Matrix.
It turns out that the Scubapro G2 itself does not care at all, but
apparently some of the other dive computers that use the same protocol
do).
In particular, Vincent reports that his Scubapro Aladin Square downloads
ok with the USB ID's switched to c251:2006, but only if we send 32-byte
USB HID payload packets, even though the command itself is much smaller.
Otherwise it will simply not reply at all.
To actually download correctly, we'll still need to do some model-
specific USB ID updates, and there will be some model changes for the
Aladin Square, but this at least fixes the transport side.
Jef had actually already done this because of the Windows behavior side,
I just hadn't thought it could possibly matter. Mea Culpa.
Reported-and-tested-by: Vincent <vavincavent@gmail.com>
Cc: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Cc: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As the OSTC does not report a CNS value on the first sample, we need to
initialize it differently. This can be solved by using the initial CNS
value form the dive header, and storing that value in the first sample.
The resulting patch is very similar to 44f629f03a91a3b3.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The main purpose of the magic value UNDEFINED, is to indicate that a
value isn't present in the data. But since the value 0xFF can actually
be stored in the data, we can't distinguish between those two cases.
This ambiguity can be avoided by using a magic value that lies outside
the valid range for 8 and 16 bit fields.
Note that an initial gas mix value of 0xFF remains interpreted as
UNDEFINED, but this is now made explicit.
The code relied on the dives being ordered by date in the directory
listing, which is normally true. But once the dive computer fills up
(after 400 dives or so), it starts re-using entries in the dive list,
and the dive directory is no longer ordered by date.
This matters because we want to download the latest dives first, since
subsurface will generally stop downloading once it finds an existing
dive.
NOTE! If you screw up the date on the dive computer, the old behavior
was possibly more to your liking, since - as long as the dive list
hadn't filled up - it wouldn't really order by date, but by dive
creation.
However, I don't see any way to get that information once the dive list
has filled up, so "order by dive date" is as good as it gets.
If you do screw up dates, and you want to download new dives that are
"older" than the dives you already have, you will need to basically set
the "download all dives" flag, and then select the new dives manually.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The model number was wrong. Mea culpa.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull Uwatec date handling fix from Jef Driesen.
This merges with upstream libdivecomputer, where Jef fixed the overly
complicated and fragile date parsing of the Uwatec smart backend.
It used to try to guess the base epoch of the dive computer by comparing
current time on the dive computer with the current time on the
downloader, but if the time and date of either was wrong (and the date
on dive computers often is) that would get the wrong answer.
* git://git.libdivecomputer.org/libdivecomputer:
Replace the clock calibration with a fixed epoch
The protocol is identical to the G2 protocol, with the exception of a
missing handshake.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently the date/time parsing assumes the reference time (epoch) of
the device clock is unknown. Hence we retrieve the current time of the
device (devtime) and the host system (systime) during the download.
Since both timestamps represent the same instant in time, but with a
different reference time, we can calibrate the device clock as follows:
ticks = parser->systime - (parser->devtime - timestamp) / 2
But this produces wrong results once the device clock has been adjusted
manually. Adjusting the device clock will suddenly increase (or
decrease) the devtime, while the systime continues ticking forwards
normally. Hence all dives recorded before the time adjustment will get
an incorrect date/time value.
Fortunately all devices appear to use a fixed epoch (2000-01-01 00:00:00
UTC) and we can simply replace the calibration with a hardcoded value.
Reported-By: Linus Torvalds <torvalds@linux-foundation.org>
Merge with upstream libdivecomputer: USB HID fixes.
* git://git.libdivecomputer.org/libdivecomputer:
Make the initialization thread-safe
Initialize the usb library only once
Perform the initialization inside a critical section.
Unfortunately Windows critical sections, which are the simplest
synchronization mechanism available on Windows, do not support static
initialization. A call to InitializeCriticalSection is required.
Therefore a simple spinlock, with an implementation based on atomic
operations, is used as a workaround.
Initializing the hidapi library more than once is tricky. The hid_init()
function can be called multiple times, but the the hid_exit() function
will free the resources unconditionally, regardless of how many times
the hid_init() function has been called. The consequence is a premature
termination of the library.
To avoid this problem, the calls are reference counted. Note that this
workaround can't protect against calls made outside the libdivecomputer
code!
The libusb library doesn't suffer from this problem, because each
initialization returns a new context pointer. But for consistency, we
now also use a single reference counted libusb context.
Merge with upstream libdivecomputer:
- workarounds for Windows libusb and hidapi issues
- misc random cleanups/noise
- rename DiveSystem to Ratio
- make Cochran with better with FTDI
- new support for: Suunto D4f, Ratio idive tank pressure, and Sherwood
Insight temperature and Oceanic ndl/deco sample.
* git://git.libdivecomputer.org/libdivecomputer:
Workaround for a Windows libusb issue
Use a fixed size packet for sending
Replace the size macro with the sizeof operator
Use the correct printf format for the size_t type
Move platform specific macros to a common header file
Use the correct data type for the return value
Rename the DiveSystem vendor to Ratio
Fix the Sherwood Insight temperature
Implement the ndl/deco sample
Change communication parameter to work better with FTDI
Retry read operations on failure
Add support for the Suunto D4f
Implement the tank pressure
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.
Merge with upstream libdivecomputer:
- uwatec cleanups and fixes (G2/trimix parsing etc)
- event and bookmark fixes for Oceanic, iDive/iX3M and Aqualung i300
* git://git.libdivecomputer.org/libdivecomputer:
Use more descriptive names
Use two passes to parse the profile data
Fix the Uwatec trimix data format
Implement the ndl/deco, rbt and bookmark samples
Implement the setpoint sample for the iDive and iX3M
Implement the ndl/deco sample for the Aqualung i300
Update the msvc project file
This with serial_ftdi.c changes and other libdivecomputer changes
enables Cochran DCs to work with libftdi on android devices.
Signed-off-by: John Van Ostrand <john@vanostrand.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Technically this is inaccurate because while some Perdix and Petrel 2
models do in fact support dual stack, the Petrel only does BT. But
the Petrel 2 identifies itself as Petrel via BT, so we need to flag
them both here.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Jef reports that this is required for HIDAPI, and while I would really
like to just make the report type part of the custom packet_io interface
instead of making it visible here, this is the minimal fix for now.
See commit d251b373becc ("Add a zero report ID to the commands"), which
does the same thing, except for the fact that we now need to treat BLE
and USB HID differently.
I may still end up teaching the USB HID custom-IO layer to add the
report ID byte, and just specify it at dc_usbhid_custom_io() time
instead. That would make the G2 code not have to care about the
transfer protocol again.
(But the other user of USB HID - the Suunto EON Steel - has much bigger
protocol differences between USB HID and BLE, so the whole "try to be
protocol-agnostic" hope may be just a pipe dream anyway, and it's just
the Scubapro G2 that _could_ work that way).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The EON Steel can use the new 'timesync' interface to set the time
automatically from the computer it is connected to.
This also regularizes the EON Steel command names a bit, and adds a few
new commands (you can also read the time etc, which this doesn't
actually use).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge with upstream libdivecomputer from Jef:
- more Cochran work from John Van Ostrand
- new 'timesync' interface to synchronize the clock on a dive computer
- support for Aqualung i200
- misc updates (Cressi Leonardo fix, OSTC 3+ renaming, fix surface pressure on iX3M, idive salinity parsing)
- HIDAPI work.
It turns out that HIDAPI is not compatible with libusb in the actual
packet sending path, so this will need some more cleanups - Jef doesn't
see the issue because he doesn't have a generic packet IO layer and
doesn't share packets with the BLE code.
* git://git.libdivecomputer.org/libdivecomputer: (25 commits)
Add basic timezone support
Add time synchronization to the example application
Implement the new api for the HW devices
Add support for synchronizing the device clock
Use hidapi as the default USB HID library
Workaround for a Windows hidapi issue
Reset the number of bytes to zero on error
Add a zero report ID to the commands
Fix compatibility issue with hidapi
Implement the salinity field
Fix the atmospheric pressure for the iX3M
Rename the OSTC 3+ to OSTC Plus
Locate the most recent dive using the logbook pointers
Add support for the Aqualung i200
Add event handling to TM model
Fix profile buffer size and address size
Add three event codes
Add support for the Commander TM
Dump function no longer assumes reads begin at byte 0
Remove unneeded function
...
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.
