PDA

View Full Version : Computer



ootini
02-09-2014, 12:41 PM
This isn't really a home build CCR as such, more of an exercise in coding.

I'm writing up a few software projects at the moment and was curious, are there any features / functions / or any suggestion really, that you guys would be interested in seeing on a CCR computer?

I noticed a lot of talk about the logic used by the Vision system when determining which cells are out of range etc.

So the floor is open, anything goes. (apart from stupid shit obviously.)

For what it's worth I'm coding in Java.

Nickpicks
02-09-2014, 12:50 PM
Can you produce a PDF file of it?

ootini
02-09-2014, 12:54 PM
Can you produce a PDF file of it?

Of the code?

jturner
02-09-2014, 01:48 PM
Of the code?

No, just saying all the amazing things it will do and how little it will cost. Bonus points are awarded for a subtle slagging off of other on-market products!

But, joking aside, I've always thought a "time left until you would run out of bailout gas if you bailed out right now, using the gas mixes, volumes and SAC rates you have provided me" calculation would be good and interesting to know.

bubbleless
02-09-2014, 02:11 PM
Ok lets start.

You need to decide what hardware you are going to be using first......

1- Monitor the sensors , covert to ppo2 display info in real time or near enough, in an easy to see/ read format.

Using 3-7 sensors ??

cuvavu
02-09-2014, 02:27 PM
Cost of gas, had you been on OC. So you can tell all the OC divers about it. Constantly.

Simon A
02-09-2014, 02:50 PM
Cost of gas, had you been on OC. So you can tell all the OC divers about it. Constantly.
No! just add a buddy screen that continually updates this information during the dive.
:)

ootini
02-09-2014, 02:55 PM
Ok lets start.

You need to decide what hardware you are going to be using first......

1- Monitor the sensors , covert to ppo2 display info in real time or near enough, in an easy to see/ read format.

Using 3-7 sensors ??

I'm actually working on a module now that will allow the user to define the number of cells in use, with three set as the minimum (purely because most units have three cells as standard.).
I can poll the sensors as often as is required, at the moment it's once per second, is that often enough? Too often?

I'm currently working on the software engine, the GUI (display) will come afterwards.

I've built in a few functions that are probably not that useful but helped me get my head around the logic I was aiming for. Namely, if the units depth drops below the MOD for the diluent it goes bat shit mental; obviously this is something the diver should be in control of, but I just added it as an idiot alarm.

Digger
02-09-2014, 03:01 PM
Make two cells the minimum, quite a few homebuilding and some kiss divers will use two to avoid your brain making bad decisions if two cells are wrong but agree.

Digs.

ootini
02-09-2014, 03:02 PM
Make two cells the minimum, quite a few homebuilding and some kiss divers will use two to avoid your brain making bad decisions if two cells are wrong but agree.

Digs.

That was one thing that was a catalyst for this project really. The logic behind the question, when 1 out of 3 cells goes off range, do you assume that cell is correct and the shit is hitting the fan, or do you assume that cell is wrong and the 2 "agreeing" cells are to be trusted.

witchieblackcat
02-09-2014, 03:47 PM
That was one thing that was a catalyst for this project really. The logic behind the question, when 1 out of 3 cells goes off range, do you assume that cell is correct and the shit is hitting the fan, or do you assume that cell is wrong and the 2 "agreeing" cells are to be trusted.

I was taught to do a dil flush and find out...

witchieblackcat
02-09-2014, 03:48 PM
I'm actually working on a module now that will allow the user to define the number of cells in use, with three set as the minimum (purely because most units have three cells as standard.).
I can poll the sensors as often as is required, at the moment it's once per second, is that often enough? Too often?

I'm currently working on the software engine, the GUI (display) will come afterwards.

I've built in a few functions that are probably not that useful but helped me get my head around the logic I was aiming for. Namely, if the units depth drops below the MOD for the diluent it goes bat shit mental; obviously this is something the diver should be in control of, but I just added it as an idiot alarm.

I'd be interested in reviewing the code and maybe trying a few junit test cases for coverage and sanity if you want the help.

ootini
02-09-2014, 03:49 PM
I was taught to do a dil flush and find out...

Which is why I was interested in the logic the Posiedon MKVI uses, where it's continually dil flushing each cell to verify them as it goes along. Would something like that be remotely useful you think?

ootini
02-09-2014, 03:59 PM
I'd be interested in reviewing the code and maybe trying a few junit test cases for coverage and sanity if you want the help.

Definitely, I'd appreciate it!

cuvavu
02-09-2014, 04:07 PM
I can poll the sensors as often as is required, at the moment it's once per second, is that often enough? Too often?

You probably want to make tests to simulate a momentary bad reading, and write code to exclude these outliers. If you do that you'll probably see for yourself how often you need to sample it, it'll depend on how often you get bad readings and how quickly real O2 changes happen. In reality you'd want to see how the cells behave and create a testing model based on that.

witchieblackcat
02-09-2014, 04:44 PM
Which is why I was interested in the logic the Posiedon MKVI uses, where it's continually dil flushing each cell to verify them as it goes along. Would something like that be remotely useful you think?

Not sure that you could do a continual dil flush on units not designed to do it.
I doubt the extra logic would be that useful although you'd need something to calculate and indicate if one or more cells weren't on message. Just thinking about it now it could be quite tricky with lots of cells - I'd just considered three cells where one is straying but (staying with AP) all one, two or three could have wandered... It would be even worse with more cells when some wander up, some down and some stay right...

witchieblackcat
02-09-2014, 04:47 PM
You probably want to make tests to simulate a momentary bad reading, and write code to exclude these outliers. If you do that you'll probably see for yourself how often you need to sample it, it'll depend on how often you get bad readings and how quickly real O2 changes happen. In reality you'd want to see how the cells behave and create a testing model based on that.

I think I'd want to know about a momentary bad reading as it suggests something isn't quite right somewhere.
Once per second seems pretty brisk considering Suunto computers sample, update and recalculate deco requirements somewhat slower than that. Not sure about other computers.

LearnerDiver
02-09-2014, 04:52 PM
I think I'd want to know about a momentary bad reading as it suggests something isn't quite right somewhere.
Once per second seems pretty brisk considering Suunto computers sample, update and recalculate deco requirements somewhat slower than that. Not sure about other computers.

When I was playing building a HUD I sampled the cells more than once per second and kept a moving average over several readings to slightly smooth any odd readings

dwhitlow
02-09-2014, 05:43 PM
Which is why I was interested in the logic the Posiedon MKVI uses, where it's continually dil flushing each cell to verify them as it goes along. Would something like that be remotely useful you think?
The Vision uses the average of the two cells closest as the actual ppo2 and discounts the third. If any cell varies by more tha 0.2 bar it alerts with a cell error alarm.

Whilst the frequent cell checks might not be needed it would be useful to follow a cell error alarm with a dil flush to confirm the two are closer to the predicted ppo2 than the one.

bubbleless
02-09-2014, 06:26 PM
Calibration of cells.... o2 or other known gas

ebt
02-09-2014, 08:31 PM
My pet project (atmega based) scans cells during cal and decides how many cells it has connected. I dont do any voting, I merely generate an alarm and let the user assess from the displays themselves.

with respect to scan frequency, I poll every 250ms. One of the best diagnostics on the KISS was seeing raw cell output in realtime so you could see response rate, 1 sec intervals would screw that.

ootini
03-09-2014, 08:28 AM
Not sure that you could do a continual dil flush on units not designed to do it.
I doubt the extra logic would be that useful although you'd need something to calculate and indicate if one or more cells weren't on message. Just thinking about it now it could be quite tricky with lots of cells - I'd just considered three cells where one is straying but (staying with AP) all one, two or three could have wandered... It would be even worse with more cells when some wander up, some down and some stay right...

I was considering this last night. I was hoping to develop a generic program that could take the best bits of various boxes and ram that functionality in to a single device but I think the various hardware configurations of boxes will limit that quite severely.

ootini
03-09-2014, 08:29 AM
You probably want to make tests to simulate a momentary bad reading, and write code to exclude these outliers. If you do that you'll probably see for yourself how often you need to sample it, it'll depend on how often you get bad readings and how quickly real O2 changes happen. In reality you'd want to see how the cells behave and create a testing model based on that.

To be honest, I thought that would be a very, very bad idea. Surely a momentary bad reading is something the diver would definitely want to know about.

ootini
03-09-2014, 08:31 AM
I think I'd want to know about a momentary bad reading as it suggests something isn't quite right somewhere.
Once per second seems pretty brisk considering Suunto computers sample, update and recalculate deco requirements somewhat slower than that. Not sure about other computers.

If this single unit was monitoring the box itself and calculating deco, why would it matter that it's faster than, as you say a Suunto? I understand there would be limitations based on the hardware in use (for what it's worth the first embedded system will be on a raspbery Pi I think).

ootini
03-09-2014, 08:34 AM
My pet project (atmega based) scans cells during cal and decides how many cells it has connected. I dont do any voting, I merely generate an alarm and let the user assess from the displays themselves.

with respect to scan frequency, I poll every 250ms. One of the best diagnostics on the KISS was seeing raw cell output in realtime so you could see response rate, 1 sec intervals would screw that.

I don't particularly like the term "real time". Whenever quantizing is used "real time" no longer applies, it's a sample rate and the smaller that sample rate is the more "real time"-like the values will be harvested, but it's still not real time. I need to find some rate that is fast enough to be effective and useful, but not so fast that the processing load suffers.

ootini
03-09-2014, 08:35 AM
Sorry about all the individual replies*, it's just easier that way.

*including this one.

witchieblackcat
03-09-2014, 09:23 AM
If this single unit was monitoring the box itself and calculating deco, why would it matter that it's faster than, as you say a Suunto? I understand there would be limitations based on the hardware in use (for what it's worth the first embedded system will be on a raspbery Pi I think).

Just thinking that Suunto have it mainly right.
Over frequent polls would put a load on deco calculation but more importantly I think we want a gentle recalculation otherwise it'd be a bit jerky.

ootini
03-09-2014, 10:19 AM
Just thinking that Suunto have it mainly right.
Over frequent polls would put a load on deco calculation but more importantly I think we want a gentle recalculation otherwise it'd be a bit jerky.

Understood! Cheers. I know my old shitty Mares Nemo recalculates every 20 seconds but that's an open circuit nitrox computer, not sure if it needs the same level of precision that a CCR computer would.

witchieblackcat
03-09-2014, 10:30 AM
It's suitably parametrised it can be tweaked to perfection once it's coded.

ootini
03-09-2014, 10:47 AM
I don't see any reason why the sample rate for the cells would have to be the same as the sample rate for depth / deco recalc, do you?

I'm thinking I could poll the cells every second, then poll depth and recalculate deco every 10 seconds, possibly using some average of the cell readings over the past 10 seconds for the deco calculations. The polling of the cells every second could simply be for diver monitoring purposes.

As I said earlier, this is all preplanning and just trying to iron out any obvious gotchas early on.

notdeadyet
03-09-2014, 11:53 AM
That was one thing that was a catalyst for this project really. The logic behind the question, when 1 out of 3 cells goes off range, do you assume that cell is correct and the shit is hitting the fan, or do you assume that cell is wrong and the 2 "agreeing" cells are to be trusted.

If I get a vote out then I dont assume anything. I check against the passive secondary (real distrust of software driven displays) and verify against a dil flush with the o2 addition switched off.


Surely a momentary bad reading is something the diver would definitely want to know about.

I'm not overly bothered. The weakest part of cell monitoring is the bit between the cells and the display. Very fine signal wires, not the greatest connectors, metals exposed to a damp environment, etc. You'd probably be getting warnings all the time.

The original Mk15 electronics averaged the three cells when they all agreed. If one went out of range then it assumed the reading was 70% of what it should be then used that in the average.

It ran on a SP of 0.9. So if 2 cells read 0.9 and one read 0.2 then 3 possibilities exist: 0.2 is right, 0.9 is right or none are right. Using the averaging method it would calculate the loop at 0.69.

if 0.2 was right then the averaging means it will blow the loop to 0.4. Not ideal but better than voting out which would mean the loop would end up going hypoxic instead.

If 0.9 is right then the loop gets blown to 1.1. When i had a dead cell it blew the loop to only 1.3. So what? Voting logic would keep it at 0.9.

Either way it displays a warning so if none are right you'd be doing a dil flush anyway.

It was a nice system but fell out of favour against voting logic.



Sent from my GT-I9300 using Tapatalk

ootini
03-09-2014, 03:58 PM
Out of interest, am I safe in assuming touchscreen TFTs don't work under water?

ootini
03-09-2014, 03:59 PM
http://www.amazon.co.uk/Touchscreen-Gloves-devices-Blackberry-Samsung/dp/B002Q8685A

jamesp
03-09-2014, 06:42 PM
Indicating the Hi/Lo trend of the cells when sampled.

I`ve seen cells that were slower reacting, but not wrong!

Dill flush works, but as its an exercise....

For a multiple cell set up, the ability to swich out a "dodgy" reading cell.

Compares between "main" cells and "redundant" cells (ie 1,2,3 against 4,5...) alarms if readings drift.

deepunderground
03-09-2014, 07:24 PM
Dil flush function ? Activate it, dil flush for a bit then it shows which cells came closest

ootini
04-09-2014, 12:52 PM
Dil flush function ? Activate it, dil flush for a bit then it shows which cells came closest

I think with a "normal" CCR this couldn't be completely automatic though? Doesn't a "manual" dil flush require the diver to compress the lungs, activate the ADV and purger the gas from a dump valve or mouth? This is my understanding of a dil flush by the way, I may well be wrong.

Baron015
04-09-2014, 01:17 PM
I don't see any reason why the sample rate for the cells would have to be the same as the sample rate for depth / deco recalc, do you?

I'm thinking I could poll the cells every second, then poll depth and recalculate deco every 10 seconds, possibly using some average of the cell readings over the past 10 seconds for the deco calculations. The polling of the cells every second could simply be for diver monitoring purposes.

As I said earlier, this is all preplanning and just trying to iron out any obvious gotchas early on.

Why so infrequently, and therefore inaccurately ?

You could poll cells, depth and recalculate deco every 10ms.

That's quite different from what you choose to show to the diver, perhaps that is a moving average or smoothed function to better suit how humans like to operate.

No need to compromise the machine algorithm due to human perception requirements though.

---
The first principle is that you must not fool yourself - and you are the easiest person to fool.

Baron015
04-09-2014, 01:20 PM
The function I want, as per the Sentinel, is to be able to turn off individual cells. That way having established which cell is wrong with a dil flush, I can disable it, not rely on voting.

But I think the way the Poseidon regularly checks each cell by squirting diluent onto the face, is definitely the way of the future.

---
The first principle is that you must not fool yourself - and you are the easiest person to fool.

witchieblackcat
04-09-2014, 01:23 PM
Why so infrequently, and therefore inaccurately ?

You could poll cells, depth and recalculate deco every 10ms.

That's quite different from what you choose to show to the diver, perhaps that is a moving average or smoothed function to better suit how humans like to operate.

No need to compromise the machine algorithm due to human perception requirements though.


Whereas I agree that the algorithm can be very much quicker than the display there are considerations of machine speed and polling speed to consider. I don't know how quickly a poll would take but it is > 0ms as is the recalculation. I'd leave plenty of padding (for time) for future proofing and additional functionality as it comes along.


I think with a "normal" CCR this couldn't be completely automatic though? Doesn't a "manual" dil flush require the diver to compress the lungs, activate the ADV and purger the gas from a dump valve or mouth? This is my understanding of a dil flush by the way, I may well be wrong.

That's what I was taught too.

ootini
04-09-2014, 01:40 PM
Why so infrequently, and therefore inaccurately ?

You could poll cells, depth and recalculate deco every 10ms.

That's quite different from what you choose to show to the diver, perhaps that is a moving average or smoothed function to better suit how humans like to operate.

No need to compromise the machine algorithm due to human perception requirements though.

---
The first principle is that you must not fool yourself - and you are the easiest person to fool.

Processor load would be the biggest concern.

Baron015
04-09-2014, 01:43 PM
Processor load would be the biggest concern.

What kind of processor is this running on ?

And did you really suggest you are going to run something safety critical on Java ? Good luck proving your exception handling is safe.

ootini
04-09-2014, 02:05 PM
What kind of processor is this running on ?

And did you really suggest you are going to run something safety critical on Java ? Good luck proving your exception handling is safe.

As I said in the OP it's an exercise in coding. I don't actually expect anyone to use this thing as life support. As a test bed I'll probably run it on a Raspberry Pi, which is no where as powerful as the machine I'm developing the software on.

Baron015
04-09-2014, 02:28 PM
As I said in the OP it's an exercise in coding. I don't actually expect anyone to use this thing as life support. As a test bed I'll probably run it on a Raspberry Pi, which is no where as powerful as the machine I'm developing the software on.

All fair enough, but processing power more likely to be an issue due to development tooling not oriented to produce efficient code for an embedded device, rather than sampling and recalc frequency.

On the Pi, the GPU is actually quite powerful. You could code some of the maths routines to execute on that, speed up your recalc time quite a lot.

ootini
04-09-2014, 03:07 PM
I've just seen the price of Piezoresistive Pressure Transducers. Holy shit.

**EDIT** Panic over, it turns out I was looking at rather high end bits n bobs. I can get this: http://www.digikey.de/product-detail/en/MS5541-CM/223-1099-1-ND/1991411 for 20ish. I believe it's the same unit the OSTC 3 uses.

bubbleless
04-09-2014, 06:10 PM
I've just seen the price of Piezoresistive Pressure Transducers. Holy shit.

**EDIT** Panic over, it turns out I was looking at rather high end bits n bobs. I can get this: http://www.digikey.de/product-detail/en/MS5541-CM/223-1099-1-ND/1991411 for 20ish. I believe it's the same unit the OSTC 3 uses.

If your not using it underwater and only as a mock up use pizio sounders penny's same thing without the 20 housing.

Baron015
04-09-2014, 08:49 PM
If your not using it underwater and only as a mock up use pizio sounders penny's same thing without the 20 housing.

Why buy one at all, are you planning to put it inside a pressure pot ?

ootini
04-09-2014, 09:06 PM
Why buy one at all, are you planning to put it inside a pressure pot ?

On the first prototype it will all be faked just using more "domestic" sensors. Probably just a pot that provides similar output.

Then a cheapo piezo in a housing, throw it in a swimming pool and hope for the best.

witchieblackcat
04-09-2014, 09:16 PM
And did you really suggest you are going to run something safety critical on Java ? Good luck proving your exception handling is safe.

I can't see a problem with using Java as long as the JDK is available. The latest versions are not only pretty stable but also brisk. That's why half of the internet runs on it.


Sent from my iPad using Tapatalk

Baron015
04-09-2014, 09:29 PM
I can't see a problem with using Java as long as the JDK is available. The latest versions are not only pretty stable but also brisk. That's why half of the internet runs on it.


Sent from my iPad using Tapatalk

Hmmm. If you are planning to use JSR-1/JSR-282 ("The Real-Time Specification for Java") then maybe. Also see JSR 302: Safety Critical Java Technology.

Otherwise, no, it is not predictable enough for safety critical applications, due to garbage collection, exception handling, and other language features that can interrupt time critical functions. A rebreather / direct life support system has very different requirements to "half the internet".

---
The first principle is that you must not fool yourself - and you are the easiest person to fool.

Baron015
04-09-2014, 09:32 PM
On the first prototype it will all be faked just using more "domestic" sensors. Probably just a pot that provides similar output.

Then a cheapo piezo in a housing, throw it in a swimming pool and hope for the best.

Sounds fun, will you throw the whole Pi into the swimming pool in some kind of housing, or just the sensor ?

What do you have planned for the Pi to tell you what it's doing / thinking ?

witchieblackcat
04-09-2014, 09:39 PM
Hmmm. If you are planning to use JSR-1/JSR-282 ("The Real-Time Specification for Java") then maybe. Also see JSR 302: Safety Critical Java Technology.

Otherwise, no, it is not predictable enough for safety critical applications, due to garbage collection, exception handling, and other language features that can interrupt time critical functions. A rebreather / direct life support system has very different requirements to "half the internet".

---
The first principle is that you must not fool yourself - and you are the easiest person to fool.

I think for the exercise described a bog standard JDK will be adequate. Especially if you're not running on the limit of the processor.


Sent from my iPad using Tapatalk

ootini
04-09-2014, 09:43 PM
Sounds fun, will you throw the whole Pi into the swimming pool in some kind of housing, or just the sensor ?

What do you have planned for the Pi to tell you what it's doing / thinking ?

I'm not 100% sure at the moment. All depends on how I get on casing it all up. One thing I am definitely going for is inductive charging so in "theory" once I'm happy with the setup, I can seal the whole case up, transfer software via WiFi / Bluetooth and reharge a batter pack using a conductive plate. I'm actually amazed inductive charging isn't already in use for most diving applications, computers / torches etc.

ootini
04-09-2014, 09:45 PM
I think for the exercise described a bog standard JDK will be adequate. Especially if you're not running on the limit of the processor.


Sent from my iPad using Tapatalk

Yeah, the Pi is the proof of concept test bed. I'm pretty sure Raspbian comes with the Java JDK 7, which for the prototyping stage is fine.

Baron015
04-09-2014, 09:52 PM
I think for the exercise described a bog standard JDK will be adequate. Especially if you're not running on the limit of the processor.


Sent from my iPad using Tapatalk

Fine, underestimate timing issues of realtime programming at your peril. You won't learn anything from the prototype about this unless you try it.

ootini
04-09-2014, 09:54 PM
Fine, underestimate timing issues of realtime programming at your peril. You won't learn anything from the prototype about this unless you try it.

As I've stated I'm not planning on really doing anything in real time, that's why I was asking earlier about sampling rates. Or am I misunderstanding what you mean?

Baron015
04-09-2014, 09:59 PM
As I've stated I'm not planning on really doing anything in real time, that's why I was asking earlier about sampling rates. Or am I misunderstanding what you mean?

All digital systems are sampled.

Realtime refers to there being functions of your system that must predictably complete/respond within some time constraint, and that your system guarantees that this will complete/respond before it's deadline irrespective of system load or other events going on.

This type of requirement is typical of life support and other safety critical systems eg avionics, air traffic control, system control programs for nuclear reactors, etc.

Also used in financial systems, eg the Eurex T7 derivatives exchange software.

Most normal "half of the internet" systems just make best endeavours to get some response out when it's done. Usually this is ok. Consequences of late response or no response are not too bad. Normal java is like this. If your function is interrupted by garbage collection and takes an extra 250ms then never mind. If a runtime exception occurs and there is no response at all, oh well. However this is not OK for safety critical applications (and some financial transactions like high frequency trading) so there are special tools, techniques and languages you can use to ensure your system can operate reliably in realtime.

I want my closed circuit dive computer to be reliable like avionics, not reliable like an internet web server.

ebt
04-09-2014, 10:00 PM
Let the man build his proof of concept.... of course there'll be lots of changes before/if it goes to something submersible. Its a learning experience.....

Baron015
04-09-2014, 10:16 PM
Let the man build his proof of concept.... of course there'll be lots of changes before/if it goes to something submersible. Its a learning experience.....

Yes of course. Just making helpful suggestions. Hard to change the system architecture later.

witchieblackcat
04-09-2014, 11:25 PM
Fine, underestimate timing issues of realtime programming at your peril. You won't learn anything from the prototype about this unless you try it.

I think I've an idea if them thanks. I've only been programming Java since 1999 when some of your issues were grounded. These days most of your issues have been sorted out.

If it was a nuclear power station we're talking about I'd suggest we learnt Ada or something similar but for a simplish thing like a proof of concept rebreather that isn't actually going to be used BBC Basic would probably be enough.


Sent from my iPad using Tapatalk

Baron015
04-09-2014, 11:33 PM
I think I've an idea if them thanks. I've only been programming Java since 1999 when some of your issues were grounded. These days most of your issues have been sorted out.

If it was a nuclear power station we're talking about I'd suggest we learnt Ada or something similar but for a simplish thing like a proof of concept rebreather that isn't actually going to be used BBC Basic would probably be enough.


Sent from my iPad using Tapatalk

Sorry, I didn't realise you were building the prototype.

Ken
05-09-2014, 05:46 AM
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.

witchieblackcat
05-09-2014, 09:18 AM
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

This isn't really a home build CCR as such, more of an exercise in coding.

ootini
05-09-2014, 10:28 AM
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).

Stage 1
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.

Must do:
Be waterproof
Sense depth
Count in water time
Inductive charging

Should do:

Could do:

Stage 2
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.

Must do:
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)

Should do:
Bluetooth or WiFi data transfer
Dive simulation / planning

Could do:
Digital compass
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?)

Stage 3
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.

Must do:
As stage 2
Allow the diver to switch gasses
Allow the diver to switch deco algorithms

Should do:
More advanced logging.

Could do:
As stage 2

Stage 4
This is where I'd add CCR support. The ability to read cells using whatever logic / method seems most appropriate. (mCCR)

Must do:
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

Should do:
Alert diver to out of range cells (alarm, not just monitoring)
More advanced logging for cell info etc
Calculate bailout limitations

Could do:
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

Stage 5
An evolution of stage 4 that includes not only the ability to read CCR information but also control the CCR itself. (eCCR)

Must do:
As stage 4
Trigger solenoids based on loop information

Should do:
Automatically switch setpoints based on dive information or at least alert the diver to do so.
Stuff I haven't thought of yet.

Could do:
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)

ootini
05-09-2014, 10:28 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/showthread.php?12760-Home-built-computer if that's OK?

Unless you guys want to discuss the CCR specific aspects here, I don't mind.

ebt
05-09-2014, 11:10 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.

ootini
05-09-2014, 11:20 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.

I completely agree, it's just an idea, and as I said, a bad one.


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.


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.

LearnerDiver
05-09-2014, 11:41 AM
...I've no intention of this being commercial, or even used in anger as a sole device....

Thats exactly why I did some of my stuff; because you can and its a good learning exercise

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.