Skip to content

Home Support

Dive computer imports and log file formats

How dive computer downloads actually work, why dive log file formats fragment between manufacturers, and how to keep a scuba logbook readable for decades rather than for one product cycle.

An abstract dive profile curve showing descent, bottom time and a stepped ascent

This page explains how dive computer downloads work, why the format situation became as fragmented as it did, and what a diver can do about it. It was written against SharkPoint's DCU import modules, but the problem it describes is not specific to any one program — and it is the reason logbooks get stranded.

What a download actually moves

A dive computer records samples: depth at a fixed interval, usually with temperature and, on air-integrated models, cylinder pressure. Downloading a dive moves that sample series, plus a header with the date, time, maximum depth, duration and whatever settings the computer applied.

What it does not move is everything else about the dive. The computer does not know the site name, the buddy, the visibility, the weight carried or what you saw. This is why the sensible workflow has always been to import the profile and write the dive up separately — and why SharkPoint's DCU modules were built to append a profile to a dive already in the logbook rather than create a new entry from it.

Why formats fragmented

In the period SharkPoint was published there was no shared exchange format for dive data in general use. Each manufacturer wrote its own desktop software, which stored dives in its own file layout, and third-party logbooks had to be taught each layout individually.

That is the whole reason DCU was a family of modules rather than a feature: an import routine had to be written against a specific manufacturer's native log files. Add a new computer to the market and someone had to do the work again.

The situation has improved. There is now considerably more convergence on open exchange formats for dive data, and several current logbook programs read a broad range of computers directly rather than through per-vendor modules. But the underlying risk did not disappear — it moved. Proprietary formats still exist, cloud logbooks still hold data in shapes their owners control, and a program that cannot read your computer today is still a program that cannot hold your logbook.

The generational trap, from inside one product

Fragmentation is not only a between-vendors problem. It happened inside the SharkPoint range itself.

When the database format changed between the 1.5 and 2.0 generations, DiveSync 1.5 could not read the newer format. The concrete result was that the Palm DualPack could never be supplied with SharkPoint for Windows v2 — the Palm edition and the version 2 desktop simply could not be synchronised. Divers on Palm hardware were, in effect, held at the older generation.

This is worth dwelling on because it is the general case in miniature. A logbook is only as durable as the format it sits in, and the format can be broken by the same vendor who created it, without anyone acting in bad faith.

Keeping a logbook readable

The practical advice has not changed much in twenty years:

  • Check the import list before you commit. Whether a program reads your specific dive computer is the first question, not the last. It is far easier to choose differently at dive fifty than at dive eight hundred.
  • Prefer software that exports as well as imports. The ability to get data out, in a documented format, matters more over a lifetime than any feature on the marketing page. A logbook you can leave is a logbook you can keep.
  • Export periodically, not just at the end. An export taken while the software still runs is worth a great deal more than a file you cannot open on a platform that no longer exists.
  • Keep the raw downloads. The files the dive computer's own software produced are the closest thing to an original. Storing them alongside the logbook costs almost nothing and preserves the option of re-importing later.
  • Keep a printed or plain-text summary of the core numbers. Unglamorous, and the only format guaranteed to outlive every program discussed here. SharkPoint's EPF print system existed partly for this reason.
  • Test a restore. A backup nobody has ever opened is a hypothesis.

What the profile is good for

Once imported, a profile is worth reviewing rather than merely storing. Ascent rate, safety stop discipline and time spent at maximum depth are all visible in a profile and all soften in memory. Comparing the plan to what happened is one of the more useful things a logbook can do.

Interpretation, though, is a training and dive-medicine matter rather than a software one. Nothing a logbook displays after the fact changes what was safe during the dive, and the authority in the water remains the diver's training and their computer. The Divers Alert Network publishes the standing guidance on ascent rates, safety stops and decompression risk, and the underlying research is indexed on PubMed.

See compatibility for what the SharkPoint range connected to, and what belongs in a dive log for the fields worth filling in.