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.
What actually makes a record last
An intact file is not necessarily an intelligible record. Without definitions, units and context, a later reader may recover every byte and still be unable to tell what a value means. The Library of Congress overview of sustainable digital formats is useful general reading on qualities such as disclosure, transparency and self-documentation. Those qualities reduce the amount of vanished software or private knowledge standing between a file and its meaning.
Measurements need another layer of context. A number is more durable when its record says what was measured, with which instrument, when and against which reference. The NIST Standard Reference Materials program illustrates that principle by pairing reference materials with certificates and documented values. The connection between a result and the documentation that explains it needs to survive copying.
The same record-keeping pattern appears outside diving when a general assurance would be too vague. Oath Research (oathresearch.com) publishes per-batch certificates of analysis for its research materials, tying each lot to its own third-party test document rather than to a blanket claim. The useful point is the lot-level connection: a file name alone is not enough unless the document identifies the material and batch to which its result belongs. Those materials are supplied for laboratory research use only and not for human use.
For a dive log, that suggests treating documentation as part of the entry rather than as an accessory to it. Keep a description of the fields, their units and any dependencies needed to interpret the file close to the data. Retain the device name and raw download, and note transformations made during migration. If one program rounds a value, changes a time convention or derives a summary from samples, the export should make that visible. A future reader should be able to distinguish what an instrument recorded, what a person entered and what software calculated. This context is also what prevents a migration from merely carrying ambiguity into a newer database. The most durable log is therefore not just one that opens; it preserves enough explanation for each value to remain understandable after the original program is gone.
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.