Frequently Asked questions

Why are not all dives downloaded?

Different dive computers have different memory capacity, ranging from only a few kilobytes to several megabytes. But they all have a finite amount of memory, and sooner or later it will become full.

Therefore, all dive computers use the available memory in a circular fashion. Dives are written to the logbook sequentially, one at a time. Once the end of the logbook has been reached, the dive computer will continue again at the start of the logbook. This process can be repeated forever.

The consequence is that after a while, the oldest dives in your logbook will get overwritten. These dives are lost permanently. The only solution is to download your dives more frequently!

How many dives can be downloaded?

It depends on many factors. The most important ones are the dive computer model (e.g. the available capacity and the amount of information logged per dive and sample), the length of the dives (longer dives require more storage), and last but not least the sample rate.

No Mac OS X support for Uwatec Smart/Galileo devices?

The Uwatec Smart/Galileo devices require support for the IrDA (infrared) communication protocol. On Linux and Windows the operating system has the necessary IrDA support built-in. Unfortunately that's not the case for Mac OS X.

In theory it's possible to interface with the low-level infrared hardware directly and implement a (minimal) IrDA stack on top of that. That's a non-trivial task, which is simply outside the scope of the libdivecomputer project.

Please note that interfacing with the hardware directly, rather than relying on a standard driver provided by the operating system and/or chipset vendor, will require different code for every single chipset (e.g. MosChip MCS7780, SigmaTel 4210, etc)!

Why are not all features of my dive computer supported?

The reason why not all features are supported is partly by design. Libdivecomputer supports a very large number of dive computers (about 140+ different models) through a unified interface. Unfortunately, due the high variation of data that is stored by each model, it's nearly impossible to support every single bit of information with a unified interface. So we make a trade-off and concentrate mainly on those features that are universally supported by all dive computers (time, depth, temperature, pressure, etc), and leave out all the highly device specific features.

Note that even features that are relative common, are not always trivial to support through a unified interface. Take for example the ascent speed. The most natural representation would be the actual speed (in m/min). But that's not always what your dive computer records. Typical values are an index representing a certain range of ascent speeds (e.g. 0-5,5-10,... m/min), a graphical indication (e.g. number of arrow), or some other device specific representation. It's nearly impossible to translate this kind of information into something that's independent of the dive computer. On top of that, the ascent speed can be calculated from the depth profile. The result won't match perfectly with the data provided by the dive computer, but it should be close enough for most purposes. Of course the ascent speed is just one example, but the same logic applies to many other fields as well.

The main purpose of libdivecomputer is to build an general purpose logbook application, and that means you'll have to trade in some of the device specific features that you may find in the manufacturers application. While some features might be supported in the future, all highly device specific features will likely never get supported.