Dive Computer
Preramble
I'm a computer nerd and it runs deep. I started on Fortran 2 in the early 70s and have progressed down the years. Highlights include things like writing 747 simulators in assembler (no, not games, real airline training aids with motion systems to do the feel and all real aircraft parts to give the look) and pulling the 'one error in a million' bug out of a serial port device driver. I like to think I'm getting reasonably good at it after all these years.

So when I look at a dive computer I do it as a time served amateur diver and as a hard bitten professional coder.
And I don't like what I see.

So what's the problem?
Well it's the whole philosophy that the computer is in charge. It isn't. I'm in charge. I'm the one who is putting his health and well being on the line so I can visit these underwater sites. I want the computer to advise but I have to make the decisions because I pay the price. I should never just opt out of that but, somehow, that is what they expect you to do.

I like the Bühlmann decompression models and I like simple computer interfaces so that is the starting point. I want the computer to advise me what Professor Bühlmann would have thought of my dive so far and what the limits are but how close I go to that line has to be my call. Also I don't like menu trees that involve me remembering some combination of magic words to get to the thing that I want so I can turn it on or off. I have this concept of just 'turning the page' until I get to the thing I want and the common ones will be first and the wierdos later but just turn, read and move on until you get the one you want and then on the page it is strictly What You See Is What You Get. Right. Time to deliver.

However it was never going to happen. I looked into building a housing but it was too incredibly expensive not only in money but in time. I did discussed it with my brother and business partner as a project but I couldn't make a realistic case for a program it yourself dive computer. I could only think of about three people that might buy one and two of them were me. I sulked, because it would be so much fun, but regretfully dropped the idea.

Then, a few years later, I decided to move from the Inspiration rebreather to a Sentinel. I already had a VR3 computer from Delta-P and I wasn't very impressed but it did what I wanted as backup to the Inspo Vision built in deco model. I really didn't fancy two Delta-P products, one on each wrist, because that isn't my idea of redundency. However now something wonderful had happened and a company in Germany were offering an open source dive computer. Here is a box that I can put my own code in. I sold the VR3 and bought an OSTC2. It even came with chocolate. I was so happy.

The Plan
The first job was to compile the supplied open source code. It was OK but it wasn't really my style. My style has been built up working on military and aviation equipment over the years so I'm bound to be a bit picky. Working on life support is one thing but, when you get down to it, the guys who are paying for death support raise the stakes a further notch. Their stuff isn't accidentally dangerous it is very deliberatly dangerous and they want it targetted on the bad guys not the good guys. So I took the supplied code as a guide but, any way, I'd prefer to start from scratch so it's all my fault when it goes wrong on me.

The first big change is to convert it from a 'everything in one' compile for the assembler modules to a multi-file model with the linker hooking things up. Also I dropped the C modules. I don't want to assume that their C compiler has the sort of ratings I like and I don't need high level languages, well... except for some of the more interesting uses for typedef<T>.

I managed to obtain all the documentation I needed on the internal parts (if anybody is planning to walk this same route email me) and, by a bit of reverse engineering of the code, I filled in the missing details in the circuit diagram and coded the basics to get the display displaying, the buttons buttoning, the depth sensor measuring, the memory remembering and the USB interface interfacing. Once the hardware was on team it was just down to the simple matter of putting come code behind all of that to make it act as a dive computer should.

The first disappointment came with fonts... Well the OLED display is so lovely but I wanted to mix colours on the display and I was really hoping to do smoothed fonts. Well the OLED can be persuaded to do smoothed fonts quite beautifully but it is very expensive in terms of program code and processor time. I loved them but they just weren't going to happen in a practical computer. Look at those curves on the 12.34. Aren't they sexy? No steppy edges or jagged bits. But no. My final fonts had to end up as on/off pixel maps. The three sizes I wanted for numbers, one small text set and some symbols still took a lot of memory but at least they were reasonable (6898 bytes out of 48K rather then 28K) and they painted reasonably quickly and, as a bonus, a C++ program generated them from a bitmap file so adding some more glyphs is not going to be a problem.

Then there was onto the whole problem of making standardised interfaces for my pages. I wanted a system that meant that each page went in its own source file, it had a standard start, refresh, two buttons and an end function so I just provided a list of pages, it started on page one and everything worked from there. Each page decided what pages it would link too and normally, if you didn't do anything for about forty seconds (configurable naturally), it would just take you back to page one.

One of the things that seems odd to people that have looked at it so far is that there is no distinct 'diving' page. It always powers up on a screen that tells you the depth and time. This is page one. Where you go to for things never changes so as I learn to use it the things that filter into my brain work just the same in the water as they do sitting at my desk.

You wake it up by pushing any button or by diving it to about half a meter and from then on the idea is that the same rules always apply to the buttons, specifically the bottom line of the screen tells you what the buttons do.

Before we go any further let's be completely frank about one thing.
This software is not designed for anybody else. It is designed for me. I need to make that completely clear before I discuss the philosophy of the pages. I dive either small OC dives or small, medium or relatively large rebreather dives. I want the computer to work with me on sensible deco plans and, if something goes wrong, to switch from my rebreather to a bailout mode without giving me any more grief when I'm bailing out as I already have enough problems. I want bailout modes to be quick, simple and blindingly obvious as to what I have selected. Currently you just hit the right button, 'Gas Switch' in green at the bottom, and you get what you have lined up on screen. If something is giving you a bad problem just do the stops on the screen and you are on a basic Bühlmann. It is far better to be back on the boat on that and then think about some conservatism with some O2 than stay longer in the water on badly broken kit and risk your life. At worst you in the 'undeserved bend' territory and they are usually pretty innocuous.

That's the bad side but what about the good?
Well I want gas loading graphics, I want a dive log with pictures and I want realistic TTS values based on my current set up. Also I want to be very clear about what I am doing and how the computer sees my current position. I am going to look at this display and make decisions about how far to overrun its stop recomendations so, if everything is OK, I arrive at stops slowly and late so I reduce my gas loadings below those required by the Bühlmann model.
However this only works well on a rebreather. On a rebreather I do not have a gas plan. I only need a gas plan for my bailout because a full cylinder of O2 lasts about five hours. I can dive as long as I want to and if that makes me safer why not?

Also can I add one more consideration. What is conservatism any way?
"Surely we all know?" you ask. But we don't. I know lots of ideas but I've never seen anybody model conservatism to say if you do this you are N times as safe as not doing it. I've read up on it and I'm reasonably convinced it's not possible with our current gas models. Now there are all sorts of 'this should help' ideas floating about but while I like slow ascents and I like over running the stop times I don't like fiddling with the basic gas model because that is forever.
If you apply something like gradient factors or just simple Pyle stops to a Bühlmann model you are keeping your dive profile away from the bent/not bent line that it draws but I can't say how far you should go and I can't say how helpful it is BUT if the excrement hits the aircon and you suddenly need shortest path out of the water, probably unbent, you can get it. If your conservatism frigs the compartment model you have already thrown that away and you cannot switch to shortest ascent. Hence it is hard to assess what stops you have really missed if you surface early as there is already conservatism loaded into it.













To be continued...



The test dive pot
One of the problems with programming dive computers is testing the things. You can provide a 'dive simulator' mode to feed the right values into the maths and test the functions that use depth and time but you would really like to run things as a system sometimes. Here is my diving simulator.

The main element is a Fulflo LT filter housing from RS online. It has a maximum working pressure of 10 bar and room for a nice big filter, which I do not need. This gives me a 70mm diameter by 200mm long working volume with standard 3/4" BSPP fittings sat on my desk for about 50 quid. I rummaged the fittings out of the spares bin and put an adapter to my big low pressure air tools compressor on it so I can blow it straight down to 80 meters. The label FRONT is just there to remind me which side is facing forwards when it is done up and ready to dive so I can read the displays not have them facing the wall.

I put a cheap air tool regulator valve on the input so I can wind it down and a needle valve on the output which is set to bleed gently during a dive so it comes up when I start to close the regulator again. I find I can adjust to within 10cms of a required depth quite easily although it doesn't want to start gently as the regulator doesn't like to do small fractions of a bar very well.

The pictures show my free diving Suunto D3 and the OSTC2 on its standard software at four and a bit bar. Having a see through front means I can follow a deco profile on the computer as it commands and then, après dive, dump out the recording to see why it made those recommendations. The only thing I can't do is push the buttons.

Incidentally I always run it virtually full of water so if something breaks there isn't much expansion that can happen. You can probably see the water level just behind the FRONT label. The energy in a compressed system almost all resides in compressable materials so if it breaks with lots of gas it goes bang big time propelling bits about at speed. With very little gas in it it would just go pop - hiss and leak water all over my floor.

 by Nigel Hewitt