RonR
Contributor
Software testing for embedded purpose built devices tends to be better as well - a system I wrote the firmware for was required to demonstrably operate correctly across 10k input sequences. That's a bit more stringent than any of the desktop or cell phone projects I've worked on. Not saying the app hasn't been tested that thoroughly, just saying that I haven't seen that level of testing. An algorithm such as ZHL-16C isn't that hard to code - heck, you can implement it in an hour or so if you know what you're doing, but validating function in a multi-tasking environment such as an iPhone is bigger than just the algorithm.
I was going to sit this out, having already commented on another iPhone in a box solution several months ago. But I have to second your comments above.
There is a world of difference between embedded development and desktop/ smartphone development. Algorithms, while not completely trivial, are fairly straightforward. The difficult part of a dive computer is handling correctly, in real time, all the potential things a diver could do, expected and unexpected. Dealing with all these multiple inputs, while correctly handling all the data, displaying what needs to be displayed, and prioritizing tasks appropriately is something that takes far more effort than simply developing an app that will do decompression calculations based on sensor inputs. It's far more complex than it seems on the surface (sorry), and unless you have actually been through the process of building the firmware for such a device it would be very easy to underestimate the task.
As to the overall concept, your point about taking the phone in and out of the case is a good one. You also have two computers- essentially a display-free computer taking the sensor inputs and processing them so they can be communicated with the phone, and the iPhone providing display and processing power as well as some peripherals. The communication between the two devices needs to be pretty much flawless. The Rube Goldberg factor starts getting pretty high, and my engineering spidey-sense starts tingling. There is a point of diminishing returns at which a dedicated hardware design starts looking like a better overall solution.
On the positive side, there is no inherent reason this couldn't work, given the right quality of design effort, and there are plenty of old iPhones in the world that could be recycled into alternate functions like this so the prize device isn't placed at risk. It's clearly aimed at a casual recreational market, and like most multi-purpose devices, it's bound to compromise on some functions compared with dedicated devices. I don't think it is the optimum solution for a dive computer, but as a device for logging dives with GPS tagging and divelog inputs, it could be great.
Ron