Interviewer: I recently had the privilege of interviewing Jef Driesen, developer of the widely-used libdivecomputer, about underwater photography, dive technology, and open source. Jef plays a significant role in the diving ecosystem—though one you may not have heard of. His open source libdivecomputer software is the central component of many “divelog” style products—including divelog.blue’s homegrown divecmd, which lets us post dive profiles with our articles. He was also kind enough to send a set of his beautiful underwater photographs. Thanks, Jef, for taking the time to talk with us!
How and why did you start diving?
I did my first dive about 20 years ago (1997). It all started with a SCUBA diving initiation during a sports day event at school. I really loved it, joined the local CMAS diving club and never looked back. Today I’m a 1* Instructor and the head of our diving club, Sub Aqua Club.
Diving is no doubt a true passion for me. Most of my spare time goes to diving, or related activities like underwater photography, traveling (although not as much as I would like) and of course maintaining libdivecomputer.
What sort of software did you use to interface with your first dive computer?
I learned diving with a watch, depth gauge, and the US NAVY diving tables. The first diving computers did exist already, but they were not very common yet. My first dive computer was a Suunto Favor. I still have it, and it still works just fine! It doesn’t support a PC interface at all. My first digital logbook was a simple spreadsheet:
[The spreadsheet has] the same info as in a paper logbook: date/time, dive time, maximum depth, buddies and some notes. (Interviewer: I’ve edited out names to protect the innocent.)
How did libdivecomputer begin?
Long before libdivecomputer was born, it all started with my spreadsheet-based logbook. I learned a bit of Visual Basics for Applications (VBA) to extend it with some more advanced features. After a while, I abandoned the spreadsheet and created a standalone Visual Basic 5 application. Although this application was quite basic, without any bells or whistles, it did what I needed at that time. (Interviewer: I’ve edited out buddy names.)
…Until the moment I migrated from Windows to Linux.
In the meantime I had learned C/C++. Since there were no (actively maintained) applications for Linux, I started writing my own dive manager application (using the gtkmm toolkit). Unfortunately that never reached a functional state, because somehow I became interested in dive computer interfaces and got completely sidetracked. And that’s what gradually evolved into the libdivecomputer project as we know it today.
This would all have been in 2007. The early commits shouldn’t be too far off. At that time we still used Subversion. A few years later I imported the entire Subversion history into git.
(An interesting detail is that I’m still using my good old Visual Basic application. The only difference is that I’m running it on Linux now, inside a virtual machine. I’m a bit stuck with it, because it now contains more than 1500 dives, and I don’t want to lose those when moving to some other application.)
Why C instead of C++ or any other popular language?
The libdivecomputer library is written in C because it’s the most portable and cross-platform language. Almost every other programming language or framework (Python, Java, .NET, etc) has some way to interface with a C library. I did choose the LGPL license because I like the idea that anyone can use the library, but modifications need to be contributed back to the community.
Portability is the main reason [for using C instead of C++]. C++ is certainly not as portable as C! The C++ standard library, the exception mechanism, and many more details are compiler dependent. So unless you are really careful, C++ is simply not portable.
You mentioned starting on Windows—why the move to Linux?
I don’t remember the exact reason anymore. Certainly nothing particular. I just tried it, and happened to like it. At first, I started with a dual boot with Windows. Gradually I got more and more comfortable using Linux, and booted Windows less and less often. Nowadays all computers in my house are running Linux. (My wife and kids do not always appreciate that. But I leave them no other choice if they want me to maintain their systems…)
For libdivecomputer development I can’t really avoid Windows. Since nearly all dive computer manufacturers have a Windows application, I have to use it as well. But luckily we have virtual machines now!
What kind of hardware did libdivecomputer support in the beginning?
The first supported dive computers were the Suunto Vyper and the Uwatec Aladin. Those two brands were (and still are) some of the most popular ones where I live, and their communication protocol was already reverse engineered and published on the internet. That info served as the reference documentation for writing the first libdivecomputer code.
Once I had something usable, I posted announcements on a few diving forums to have the code tested by a few people. That’s how I got into touch with people like Nick Shore (MacDive), Sven Knoch (Diving Log), and others. Very soon many new dive computer models followed. Nowadays libdivecomputer supports about 200 different models.
(Interviewer: some of the earlier announcements (1, 2, 3, and 4) and the original site (http://www.divesoftware.org) are still available online. Later announcements are available in the mailing list archive.)
What’s the “state of open source” regarding diving hardware?
Initially it was very difficult to get any kind of info, especially from the major manufacturers (Suunto, Uwatec, Mares, etc). I tried to contact them, but never got any response back. The smaller companies are much easier in that regard:
Reefnet. Public documentation and (partially) sponsored my Sensus Ultra.
Heinrichs-Weikamp. No doubt the most excellent! They fully support libdivecomputer and supply me with every hardware I need. I currently have a Frog, OSTC 2N, OSTC 2 and OSTC 3. I’m also actively involved in discussion regarding their communication protocol. I’ve met them in person several times already.
(Interviewer: this makes me even happier to use my OSTC 2C, which is of course superbly supported!)
Atomics Aquatics. Also a great example. They support me with documentation and hardware (Cobalt 1 and Cobalt 2). I can contact their software engineers directly, which is great.
Shearwater. Documentation and hardware (Petrel). Unfortunately, I’m having some difficulty reaching them at the moment. It seems my previous contact persons no longer work there. I would like to get back in touch!
Things are changing slowly [for the better]. Even the big manufacturers start to see the benefits of supporting third-party applications. Probably the smartphones have something to do with that. And also the fact that libdivecomputer is used by nearly all third-party applications. Anyway, I now have some contacts at Suunto and Mares too. Of course there is always room for improvement, but it’s definitely a move in the right direction!
Interviewer: thanks to these companies who went out of their way to support libdivecomputer!
Ok… what about the bad news?
If you really want to know (interviewer: of course we want to know!), the data format of the Oceanic (and related) dive computers is without doubt causing me the most trouble! Every single model uses a slightly different format. Thus, every time a new model comes out, I have to find out all those little changes again and again, which is very time-consuming and error-prone. That’s why I usually stick to the strict minimum that I need for libdivecomputer.
So it’s no surprise there are many areas (e.g. pressure sensors, tanks, etc.) where the Oceanic support is not at the same level compared to some of the other models.
Interviewer: as a recent owner of an Oceanic OCS, I’ll do my best to make sure the manufacturers know that libdivecomputer is an essential component of the dive software toolchain. If you own one, please do the same!
Where do you see libdivecomputer heading?
At the moment I’m more interested in adding support for Bluetooth communication in libdivecomputer. Despite the fact that it’s a very popular technology, there is surprisingly little information out there on how to communicate with Bluetooth hardware. There is for example no standard API or anything like that. And Bluetooth Low Energy (BTLE) is even more problematic. It has nearly nothing in common with classic Bluetooth.
But I believe it’s very important to support Bluetooth. The serial emulation on which we are relying now isn’t enough (and doesn’t work on mobile platforms). So this is one of the areas where we need to expand.
(Regarding write support.) Usually I try to stay away from write support. It has the potential to cause a dive computer to malfunction when writing wrong data. That’s a risk I don’t want to take.
(Regarding autodetection.) Autodetection is very difficult. Even if it did work, it would be really slow. It’s also a bit risky. Sending random data to a dive computer can cause problems. I know at least one case where doing that can cause a dive computer to lock up.
Going from dive computers to cameras: any advice?
I’m using a Nikon D7000 in a Hugyfot housing with two Sea & Sea YS-110 strobes. I use a Nikon 60 mm and 105 mm for macro, and a Tokina 10-17 mm fish-eye for wide-angle.
I’m certainly not the greatest photographer, but I’m not doing very bad either. In our Open Belgian Championship 2016 (shootout contest) I got a nice 3rd place in the category wide-angle with model. I’m very proud with that. I would like to setup a website, to show my pictures, but so far I never had time for it.
Interviewer: Jef was kind enough to share some of his photographs. If you like any of them in particular, please contact Jef directly to let him know!
I don’t really connect images to dives. I archive my photos in a simple date based directory structure (YYYY/YYYYMMDD EVENT). My underwater photographs get the dive site as the EVENT, but that’s about it. In the early days I tagged all photos with the animal species, but I gave up long ago because it was just too time-consuming. Although I now somewhat regret that, because trying to find a particular image in a huge collection is no easy task.
Interviewer: I agree. Though we take great pains to document all species in our pictures, it takes a ridiculous amount of time!
As usual, I always have a large collection of photos that is waiting to get processed. I often shoot faster than I can process them.
Are there any stories you can tell regarding these photos?
The seahorse photo comes with an story attached. I was shore diving in l'Escala (Spain). At the dive site there is a nice tunnel, where I want to photograph some shrimps that I spotted a few days earlier.
About half an hour into the dive I heard some kind of beeping sound and I thought by myself: strange, I don’t carry any dive computer capable of making sound and I was the only diver in the water (solo night dive). Until I realize a couple of seconds later that it’s the leak alarm of my camera. Shit. Surfaced as fast as I could. Luckily no leak (probably just condensation). I had plenty of air left, so I decided to continue the dive, but I left the camera in the car, just in case.
I swim again through the tunnel, and just outside I find that seahorse in a sponge on the wall. But of course I don’t have the camera with me anymore. Bad luck for the second time! I try to memorize the place and leave a small marker on the bottom.
A few days later I returned, and guess what the seahorse is still there, in exactly the same sponge! Finally came home with some nice pictures.
I really like nudibranches, too. They are really beautiful little creatures. I can easily spend a whole dive searching for them.
Anything we can do to help libdivecomputer?
Having the dive computer at my place would of course be the most easy for me. But I’ve never done that. It’s simply not practical. For the communication protocol, I give instructions on how to capture the communcation and send me the capture files. I analyze them, do a first implement, and send that back for testing. After a few iterations it usually works.
I also wrote a dive computer simulator, which simulates the dive computer part of the protocol. That allows me to test without needing a dive computer. I just need a memory dump from a real dive computer, and then I can replay the download as often as I want. Works really great.
Interviewer: Thanks, Jef, for taking the time to speak with us! If you’d like to contact Jef, he can be reached at firstname.lastname@example.org. Thanks also to Huck for proof-reading the resulting text.