Hello and welcome to our community! Is this your first visit?
Register
Page 7 of 7 FirstFirst ... 567
Results 61 to 67 of 67

Thread: Computer

  1. #61
    Established TDF Member
    Join Date
    Dec 2012
    Posts
    894
    Likes (Given)
    9
    Likes (Received)
    238
    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.

  2. #62
    Established TDF Member witchieblackcat's Avatar
    Join Date
    Dec 2012
    Location
    Penwortham
    Posts
    1,665
    Likes (Given)
    1670
    Likes (Received)
    490
    Quote Originally Posted by Ken View Post
    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
    Quote Originally Posted by ootini View Post
    This isn't really a home build CCR as such, more of an exercise in coding.

  3. #63
    Complete member ootini's Avatar
    Join Date
    Dec 2012
    Location
    Wales
    Posts
    1,032
    Likes (Given)
    403
    Likes (Received)
    360
    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)
    Last edited by ootini; 05-09-2014 at 10:30 AM.

  4. #64
    Complete member ootini's Avatar
    Join Date
    Dec 2012
    Location
    Wales
    Posts
    1,032
    Likes (Given)
    403
    Likes (Received)
    360
    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.

  5. #65
    #keepittea ebt's Avatar
    Join Date
    Dec 2012
    Location
    dahn saf
    Posts
    1,852
    Likes (Given)
    377
    Likes (Received)
    1119
    Blog Entries
    1
    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.

  6. #66
    Complete member ootini's Avatar
    Join Date
    Dec 2012
    Location
    Wales
    Posts
    1,032
    Likes (Given)
    403
    Likes (Received)
    360
    Quote Originally Posted by ebt View Post
    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.

    Quote Originally Posted by ebt View Post
    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.

  7. #67
    TDF Member
    Join Date
    Jan 2013
    Location
    Yorkshire
    Posts
    403
    Likes (Given)
    362
    Likes (Received)
    126
    Quote Originally Posted by ootini View Post
    ...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.


 
Page 7 of 7 FirstFirst ... 567

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •