Hello and welcome to our community! Is this your first visit?
Are you building a toy or something that you really want to work? Apart from the programming language run time issues there are problems with general purpose OSs which can mess with timing done by software.
A rebreather is pretty low class as a control problem as it has many floppy bits and a biological side with unpredictable behaviour. It also has feed back from the cells so whether you open the O2 for 10ms or 20ms probably doesn't matter.
On the other hand, when you start getting random lookups or weird timing problems I rather have something with the simplest underpinnings. Avoid dynamic memory allocation, use polling rather than threads and keep everything as simple in flow control as you can.
Having something which is good enough 99.9% of the time can be very frustrating.
Maybe we need to read post #1
Originally Posted by Ken
Originally Posted by ootini
Thanks for all your feedback so far! Much appreciated.
Just to clarify this is basically a proof of concept experiment / toy. One day I may well take it to a swimming pool for testing, possibly even take it on a dive just to test a few bits and bobs. I'd just like to point out that I don't expect anyone to ever actually use it as a sole computer/controller on a dive. I'd like the opportunity to let a CCR diver take it along on a dive just to see how it reacts etc but obviously not connected directly to /controlling a live CCR.
With all this in mind I've decided to rethink what I'm trying to do and have decided it will be a staged project (including funky / cheesey names).
This will be a basic dive timer, nothing more, based on the Raspberry Pi. I'll need a raspberry Pi, obviously, with wet connectors, depth sensor, simple LED readout displaying time and depth. Should be nice and easy to code.
Count in water time
A basic non gas switching, single algorithm OC dive computer. The next obvious step up from stage 1 is a computer using an "industry standard" algorithm calculating deco on the fly. Basically the same as most entry level computers. This will need a more advanced display and the addition of some user input buttons.
As stage 1
Calculate deco at a sensible rate
Log dive information
Cope with repetitive dives
Calculate SI / no fly / de sat etc
Display everything properly (better than LED readout)
Bluetooth or WiFi data transfer
Dive simulation / planning
Accelerometer (although I'm not sure why this might be useful)
MP3 player (probably a bad idea)
Monitor cylinder pressure
Monitor light levels (might be handy to record this to know about overhead environments during log review?)
This is where things get more interesting, take stage 2 and add gas switching and the possibility of using more than one algorithm. Whether this is simultaneous or one at a time I've yet to decide. Would there be any benefit from being able to view the calculations of multiple algorithms underwater? Sounds like it could be dangerous, but again it's just an experiement / toy. Hardware would most likely remain as stage 2 other than tweaks and upgrades etc, the development would be in the software.
As stage 2
Allow the diver to switch gasses
Allow the diver to switch deco algorithms
More advanced logging.
As stage 2
This is where I'd add CCR support. The ability to read cells using whatever logic / method seems most appropriate. (mCCR)
Sense input from at least 2 cells
Allow diver or unit to define the number of cells in use
Calibrate o2 cells
Allow diver to define setpoints
Allow diver to switch setpoints during the dive
Monitor cells in a sensible way
Monitor cylinder pressures
Alert diver to out of range cells (alarm, not just monitoring)
More advanced logging for cell info etc
Calculate bailout limitations
Make recommendations, dil flush etc to verify cells
Automatic eperb jetison (probably a bad idea)
Wireless transmission of cell data
Cost of gas used based on OC
Shut down monitoring of specific cells during the dive if they off message or fail etc
Dual system redundancy
An evolution of stage 4 that includes not only the ability to read CCR information but also control the CCR itself. (eCCR)
As stage 4
Trigger solenoids based on loop information
Automatically switch setpoints based on dive information or at least alert the diver to do so.
Stuff I haven't thought of yet.
Automatic dil flushing (This might require custom eCCR hardware and I doubt I'll have the cash to buy a donor unit for hacking up)
Last edited by ootini; 05-09-2014 at 10:30 AM.
I'm going to start a new thread outside of the CCR sub forum as this isn't a CCR specific project anymore.
I'm going to shift discussion of this project here: http://www.thediveforum.com/showthre...built-computer if that's OK?
Unless you guys want to discuss the CCR specific aspects here, I don't mind.
Last edited by ootini; 05-09-2014 at 11:09 AM.
All the time its just a 'coding exercise', you can build it on whatever you want. But....I think the second you want to use it in anger for anything approaching 'critical' functions, you're going to have a massive rethink on hardware/os/language (and some of the posts made before will become suddenly very relevant).
To put it another way, the idea that my deco calcs/setpoint control would share a processor with something playing mp3's horrifies me. You might get a better feel for the issues if instead of using a Pi, you started on something like an arduino. That way you'd get a feel for running non-blocking code, tight power management, state machines and interrupt driven events.
PS. As usual you're trading processor power for battery life, but when you think a Pi eats about 2W in operation v ~10mW for an arduino/ATmega, you start to grasp why the likes of Pi havent been used like this.
PPS. Even the arduino route wouldnt realise a 'commercial product'. But it'd make a product I'd be happy to use for myself.
Last edited by ebt; 05-09-2014 at 11:13 AM.
I completely agree, it's just an idea, and as I said, a bad one.
Originally Posted by ebt
Originally Posted by ebt
I've no intention of this being commercial, or even used in anger as a sole device. I like the idea using my tried and trusted computer on a dive but taking the Pi box with me just to see what happens but that's about it.
I need to do more investigating of the various components available, Pi, Arduino, Beaglebone etc I only chose the Pi due to it's popularity and availability, and availability of assistance through various communities etc.
Thats exactly why I did some of my stuff; because you can and its a good learning exercise
Originally Posted by ootini
If its a bottom timer with depth and deco obligations whats the issue if it craps out during a dive? You just change to your back up device and/or tables just as you would now if your main computer crapped out. If it displays completely different data to your backup computer then you would hopefully pick that up at the testing stage; an 8 bar water filter housing and a hose and you can test dive profiles and results against a Suunto or similar whilst sat supping coffee.
I think/hope there is a market for a nice simple timer with depth and logging, nothing more, keeping it simple, which is why I'm working on a couple and why other people are doing the same.
Simplest way to deal with the MP3 player issue is just to keep it separate, mine uses a standalone controller, player, amplifier, and battery but could easily share the same housing as the computer as it doesn't share anything else - but would mean lots of buttons so I reckon keeping them separate devices is easier.