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 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.
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 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>
The Oceans S1 uses a plaintext and line based communication protocol
over BLE. The larger payloads, which also contain plaintext data, are
transferred using the XMODEM-CRC protocol.
Based-on-code-by: Linus Torvalds <torvalds@linux-foundation.org>
The Deepblu Cosmiq+ uses a plaintext and line based communication
protocol over BLE, where the binary payload data is encoded as
hexadecimal characters.
Based-on-code-by: Linus Torvalds <torvalds@linux-foundation.org>
For dive computers where the reference time (epoch) of the device is
unknown, libdivecomputer uses the current time of the device (devtime)
and the host system (systime) to synchronize both clocks.
Currently, both timestamps are passed directly to the constructor of the
parser. With the new public function, the application can adjust the
timestamps afterwards.
Some dive computers store the depth as an absolute pressure value (in
bar). To convert to a depth value (in meters), the atmospheric pressure
and water density are required. For dive computers that do not have
those values available, libdivecomputer uses a default value. With the
new public api functions, applications can adjust those default values.
Some dive computers already provided a backend specific calibration
function. Those functions are now deprecated. They are kept around to
maintain backwards compatibility for now, but they will be removed in
the next version.
Report the decompression algorithm (Buhlmann, VPM, RGBM or DCIEM), and
if available also the parameters. For now only the conservatism setting
is supported, and for the Buhlmann algorithm also the Gradient Factors
(GF).
The Sporasub SP2 uses a very simple communication protocol and memory
layout, but with some unusual aspects:
Dives are artifically limited to a maximum of 6000 samples.
Unlike all other dive computers, the dives are not stored in some kind
of ringbuffer structure. Once the memory is full, no new dives can be
recorded. The existing dives need to be erased first, and the dive
computer will start recording again at te start of the memory area. The
Sporasub application has an "Auto-clear watch memory after data
transfer" feature for this purpose.
I didn't implement a more efficient download algorithm because
downloading a full memory dumps takes less than 10 seconds.
The hexadecimal value 0x80000000 is too large to be represented as a
signed 32bit integer. Therefore the default type for the constant is an
unsigned 32bit integer. This is a bit annoying because the timezone
field is actually defined as a signed integer, and thus comparisions
produce -Wsign-compare compiler warnings.
Fixed by switching to INT_MIN, which is the same underlying value but
interpreted as a signed integer.
The memory buffer already supported appending and prepending data, but
not inserting data anywhere in the buffer. That's exactly what the new
function does. The free space is still maintained at either the start or
the end of the buffer.
The USB communication is now also implemented as an I/O stream
transport. Unlike most I/O devices, USB communication supports multiple
interfaces and endpoints. This requires some some special care:
In the general case, autodetection isn't really possible without
additional knowledge. Hence the need for the filter parameters to pass
this kind of information.
The implementation assumes two bulk endpoints for the standard
read/write interface. Communication with the control endpoint is
supported through the new DC_IOCTL_USB_CONTROL_{READ,WRITE} ioctl's.
The set_latency function is the perfect example of a feature that should
be implemented as an ioctl: it's only implemented by a single driver,
and the functionality is also highly platform specific.
This new ioctl function allows to perform I/O stream specific requests
through a generic interface. This provides an easy way to extend the I/O
interface with some driver specific features, without having to modify
the public api.
The Linux implementation is very straighforward and just a lightweight
wrapper around the select function. But the Windows implementation is
much more complex, because the Windows event notification mechanism
behaves very different:
The WaitCommEvent function does not support a timeout and is always a
blocking call. The only way to implement a timeout is to use
asynchronous I/O (or overlapped I/O as it's called in the Windows API),
to run the operation in the background. This requires some additional
book keeping to keep track of the pending background operation.
The event mechanism is also edge triggered instead of level triggered,
and reading the event with the WaitCommEvent function clears the pending
event. Therefore, the state of the input buffer needs to be checked with
the ClearCommError function before and after the WaitCommEvent call.
The check before is necessary in case the event is already cleared by a
previous WaitCommEvent call, while there is still data present in the
input buffer. In this case, WaitCommEvent should not be called at all,
because it would wait until more data arrives.
The check afterwards is necessary in case WaitCommEvent reports a
pending event, while the data in the input buffer has already been
consumed. In this case, the current event must be ignored and
WaitCommEvent needs to be called again, to wait for the next event.
The Uwatec Smart, Meridian and G2 backends are almost identical, except
for the low-level packet sending and receiving code. With the new I/O
layer, those three backends can easily be unified in a single backend.
The Meridian and G2 are completely removed, only the family types are
kept for backwards compatibility.
When two or more identical (or very similar) dive computers are
connected, the USB VID/PID can be ambiguous. That's because the VID/PID
identifies the type of the USB device, and not the individual device.
But each USB HID device descriptor returned by the device discovery
represents a single connected device, and thus guarantees to open the
correct USB device.
To obtain the same behaviour as before, an application can simply open
the first discovered device.
Currently the dive computer backends are responsible for opening (and
closing) the underlying I/O stream internally. The consequence is that
each backend is hardwired to a specific transport type (e.g. serial,
irda or usbhid). In order to remove this dependency and support more
than one transport type in the same backend, the opening (and closing)
of the I/O stream is moved to the application.
The dc_device_open() function is modified to accept a pointer to the I/O
stream, instead of a string with the device node (which only makes sense
for serial communication). The dive computer backends only depend on the
common I/O interface.
With the support for multiple transports per device, the
dc_descriptor_get_transport() function became obsolete because it does
support only a single transport type. Applications should use the new
dc_descriptor_get_transports() function instead.
Because the list of supported built-in transports depends on the
availability of external libraries (libusb, hidapi) and the operating
system, the application needs some mechanism to retrieve this
information at runtime. Therefore, a new dc_context_get_transports()
function is added, which returns a bitmask with all the available
built-in transports.
Several dive computers support multiple transports. For example the
Suunto Eon Steel supports both USB HID and BLE. All devices using
bluetooth classic communication support both the native bluetooth
transport and the legacy serial port emulation.
To support this feature, the values of the dc_transport_t type are
changed into bitmasks, and the dc_descriptor_t struct is extended with a
bitfield with all the supported transports.
Add a function to query the underlying transport type. This allows the
dive computer backends to implement transport specific behaviour where
necessary.
For the built-in I/O implementations, the transport type is obviously
always hardcoded, but for a custom I/O implementation the application
needs to provide the correct type. Hence the transport type can't be
hardcoded in the vtable and needs to be passed as a parameter.
Add a new type to distinguish between closed circuit (CCR) and
semi-closed circuit (SCR) diving. Some dive computers from HW and
DiveSystem/Ratio support this.
Because the CCR/SCR abbreviations are more commonly used, let's take the
opportunity to also rename the existing DC_DIVEMODE_CC. To preserve
backwards compatibility, a macro is added to map the old name to the new
one.
Reported-by: Jan Mulder <jlmulder@xs4all.nl>
The purpose of the new I/O interface is to provide a common interface
for all existing I/O implementations (serial, IrDA, bluetooth and USB
HID). With a common interface the dive computer backends can more easily
use different I/O implementations at runtime, without needing
significant code changes. For example bluetooth enabled devices can
easily switch between native bluetooth communication and serial port
emulation mode.
The new interface is modelled after the existing serial communication
api. Implementations where some of those functions are meaningless (e.g.
IrDA, bluetooth and USB), can just leave those functions unimplemented
(causing the call to fail with DC_STATUS_UNSUPPORTED), or implement it
as a no-op (always return DC_STATUS_SUCCESS).
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.
The back-end parser seems to be the same as for the Uwatec Smart (aka
Galileo Sol). At least that's the assumption right now.
The downloader just uses USB HID (very similar to EON Steel) rather than
the horrible IrDA thing.
There's also eventually a BLE thing, but that's for the future.
This is an unholy mixture of the Uwatec Smart downloader logic and the
EON Steel usbhid transfer code. The back-end is pure Uwatec Smart
(model 0x11, same as Galileo Sol).
I'm not at all sure this gets everything right, but it downloads
*something*.
[Jef Driesen: Renamed the backend to uwatec, and made some smaller
cosmetic changes to match the existing coding style.]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
