Hard off switch on the Hammer Head

Mark Chase · 31st October 2006, 13:42

Quote: (Originally Posted by jradomski)

personally, I think a deco option WILL become available sometime in the future for the secondary as an upgrade (the pressure sensor is already there).. I know I wount chose the route... I like the fast response of the secondary.. When in classic mode its a true po2 display with very little damping.. Once you start to integrate deco, you slow the response time.. as dives start to get big you can REALLY start to impact responsiveness.. Having to do "test" ascents evertime you want to calculate a TTS takes alot of time.. Considering that all these devices want to use as little power as possible, they are generally run at the slowest clock frequency they can to save power....

I remember talking to Gene about the explorer, until he put in a few tricks his TTS was taking nearly a minute for big dives... I know I have done dives on the HH that the TTS calc took 30-45 seconds, so by the time it actually displayed the TTS it was already wrong! On some deep stuff I have seen deco jump over 30 minutes between TTS calculations..

And yet my inline VR3 never seemed to cause me a problem? it displayed PP02(ok on one cell only) and did deco calcs. It will be interesting to watch out for this on the sheerwater linked to all three cells.

Perhaps I am not doing big enough dives to notice but I did take the inline VR3 down to just over 100m and it didn't seem to mind. On any big dive (which is past 60m for me) I have a picture in my mind of how much deco I will be doing anyway having analyzed dry tables on my PC before the dive so I am not shocked by the eventual figure.

ATB

Mark Chase

***jradomski*** · 31st October 2006, 13:45

Quote: (Originally Posted by Genesis)

Uh, why would that be the case for the PO2 displays? No multitasking executive (or at least multiple threads?) in this thing?

a full RTOS will take up too much resources.. some stuff you obviously can run as interrupt driven functions, but the overhead needed by full decompression software dictates you take a conservative approach.. in general since you dont have alot of ram to work with.. You need to run multiple copies of the data, for the actual loading and for the test ascents.. for this type of application I think a linear execution model is much more predictable.. (aside from the data sampling, input processing and final display)

I personally prefer to keep interrupt drivent functions short and sweet.. Only do what HAS to be done there.. This keeps the system responsive and limits the nesting of interrupts.. I have seen to may apps fail becuase of nested/missed interrupts and running out of stack space..

Don;t get me wrong I am not saying, its not possible, it definately is, but there are always trade offs.. From experience, the normal operating loop on the HH appears (data processing, input check and then display) to be linear, but setpoint control and time keeping is a background operation..

***jradomski*** · 31st October 2006, 13:50

Quote: (Originally Posted by Mark Chase)

And yet my inline VR3 never seemed to cause me a problem? it displayed PP02(ok on one cell only) and did deco calcs. It will be interesting to watch out for this on the sheerwater linked to all three cells.

Perhaps I am not doing big enough dives to notice but I did take the inline VR3 down to just over 100m and it didn't seem to mind. On any big dive (which is past 60m for me) I have a picture in my mind of how much deco I will be doing anyway having analyzed dry tables on my PC before the dive so I am not shocked by the eventual figure.

ATB

Mark Chase

I'm talking about responsiveness.. yes it does work as does the HH, but as the deco piles up you will notice the po2 DISPLAY gets updated less frequently..

Genesis · 31st October 2006, 13:59

Well, multiple threads of execution do not require a full RTOS.

One of the benefits of at least some development-system level support for multiple threads of execution is that you can run things "in the background" (e.g. deco computations) without noticably impacting the user's experience in terms of what should appear to be "real time" data display.

I realize that there is generally a clash between all of the various "I want's" when it comes to embedded systems control, especially when power management becomes a guiding light (e.g. the desire to run for 10s of hours on single a single disposable battery.)

***jradomski*** · 31st October 2006, 14:52

Quote: (Originally Posted by Genesis)

Well, multiple threads of execution do not require a full RTOS.

One of the benefits of at least some development-system level support for multiple threads of execution is that you can run things "in the background" (e.g. deco computations) without noticably impacting the user's experience in terms of what should appear to be "real time" data display.

I realize that there is generally a clash between all of the various "I want's" when it comes to embedded systems control, especially when power management becomes a guiding light (e.g. the desire to run for 10s of hours on single a single disposable battery.)

Thats usually the biggest clash.. especially since most low power microcontrollers only have between 128 and 1024 bytes of ram, and if you get one with 2048 you feel like you have the world.....

and to really multithread apps you need to have plenty of ram available to store the intermediate results and all the registers..

on one of my projects I had to abandon a graphic display because it simply took up too much ram to buffer the screen...

Genesis · 31st October 2006, 15:09

Yep - I was going to do a pixel-mapped display for the K1, but there wasn't enough RAM to buffer the screen and do it right, so that went out the window......

Seriously though 2k isn't that hard to find nowdays, and a threaded implementation is very doable in 2k...... The K1's controller code is multithreaded; there are four threads running in the present implementation (sensor read/condition, solenoid, buzzer and microswitch read) plus the "main", which is the display loop. There's enough room in the processor's EEPROM and RAM to do a relatively simple (e.g. gradient factor) deco algo if I wanted to - the current code consumes less than 1/3rd of the code space and (13k out of 32k) and about 1/3 of the available RAM (~600 bytes out of 1.5k usable), but I don't, mostly because I don't like the "all eggs in one basket" thing.

One of the interesting things about the chip I'm using is that it has INTERNAL 10bit ADCs (8 of them), which, if you're willing to run millivolt signals down a handset cable (I'm not) can lead to a VERY nice "nothing but wire" solution in the head. It also has IEEE 32-bit floating point on-chip..... in its "standard packaging" its somewhat power hungry but if you put a different crystal (slower) on it you can cut that WAY down - the chip itself is an ATMEL ATMega32. (Really, do you need 14 MIPS of computational power for something like this?!)

Thing is, I find the entire "ultra low power thing" to be somewhat of a red herring. Yes, you can make ultra-low power devices, so long as they're passive displays with no backlight! As soon as you want to drive a solenoid or backlight the power monster rears his ugly head and you start to deal with the compromises that seem to be at the root of this problem.

***jradomski*** · 31st October 2006, 16:02

Quote: (Originally Posted by Genesis)

Yep - I was going to do a pixel-mapped display for the K1, but there wasn't enough RAM to buffer the screen and do it right, so that went out the window......

Seriously though 2k isn't that hard to find nowdays, and a threaded implementation is very doable in 2k...... The K1's controller code is multithreaded; there are four threads running in the present implementation (sensor read/condition, solenoid, buzzer and microswitch read) plus the "main", which is the display loop. There's enough room in the processor's EEPROM and RAM to do a relatively simple (e.g. gradient factor) deco algo if I wanted to - the current code consumes less than 1/3rd of the code space and (13k out of 32k) and about 1/3 of the available RAM (~600 bytes out of 1.5k usable), but I don't, mostly because I don't like the "all eggs in one basket" thing.

One of the interesting things about the chip I'm using is that it has INTERNAL 10bit ADCs (8 of them), which, if you're willing to run millivolt signals down a handset cable (I'm not) can lead to a VERY nice "nothing but wire" solution in the head. It also has IEEE 32-bit floating point on-chip..... in its "standard packaging" its somewhat power hungry but if you put a different crystal (slower) on it you can cut that WAY down - the chip itself is an ATMEL ATMega32. (Really, do you need 14 MIPS of computational power for something like this?!)

Thing is, I find the entire "ultra low power thing" to be somewhat of a red herring. Yes, you can make ultra-low power devices, so long as they're passive displays with no backlight! As soon as you want to drive a solenoid or backlight the power monster rears his ugly head and you start to deal with the compromises that seem to be at the root of this problem.

The "threads" you are using makesense.. and are easily handled as interrupt events (periodic or real time) and really have no dependecny on other factors.. but once you start adding in morecomplex functions, alot of time you have to do things sequantially.. for example displaying data.. its all dependent on where you are and what is already ready.. The "main"function is best to logically go through a sequence unless you are off doing something other than your main "wait" loop..

You really cant put a display update as a peridoic function,since you would really have to start tracking multiple possible screens and have multiple "screen" buffers.. I've used avr processors in the past,and they work well for alot of applications..

silent running · 31st October 2006, 17:37

Quote: (Originally Posted by jradomski)

I agree partially, but most of the resets are not due to this, its due to the system losing the ground of the battery.. In apps that I have a Powerhungry component, that I usually determine some threshold that I stop it from working, generate an alarm, and try and maintain the rest of the system in alarm state..
On a life support system this gets to be a tricky choice... If I am monitoring a serious condition like low o2, and I know I am past my threshold that will likely reset my device and lose all my data, do I try and see if I can solve the most immediate problem that is.. low o2,, I say thats probably the better choice, since its the most pressing issue, even though we know what the probably outcome is, but we MAY still be able to raise the o2 and solve The most pressing issue....

What good is deco data if you die of anoxia..

Joe, why would anybody die of anoxia if they're monitoring PO2 and can use the manual O2 inject? I have a hard time believing you or anybody else in a low power situation would rather lose deco info/power just to keep the solenoid going...

cys · 31st October 2006, 18:08

Quote: (Originally Posted by silent running)

Joe, why would anybody die of anoxia if they're monitoring PO2 and can use the manual O2 inject? I have a hard time believing you or anybody else in a low power situation would rather lose deco info/power just to keep the solenoid going...

A functionally equivalent solution would be if the system gave a warning of an impending battery condition that will not support the solenoid, and then you, the user, could go in to the menu and turn off the solenoid. It is currently possible to turn the solenoid off in the menu (it's never completely off and will kick in at very low pO2). That said, the most pressing item still seems to me to be the possibility of removing the solenoid test firing upon initialization underwater.

***jradomski*** · 31st October 2006, 23:50

Quote: (Originally Posted by silent running)

Joe, why would anybody die of anoxia if they're monitoring PO2 and can use the manual O2 inject? I have a hard time believing you or anybody else in a low power situation would rather lose deco info/power just to keep the solenoid going...

Well if it got to the point where the solenoid HAD to fire, the diver wasnt doing their job.. From a manufacturer's liability standpoint, it would be hard to argue the point in your favor that you knew the o2 was too low and you didn't want to try and inject some becuase you MIGHT reset the computer and lose some other data..
If the diver was doing his job, it would be above the point where it HAD to try and fire and the point would be moot..

You do need some line in the sand that if the o2 crosses this that you have to atleast give it a go, regardless of other settings/consequences..

I rather not lose information that is useful, but if for some other **** UP, my o2 got too low I rather have the controller try and cure the immediate danger.. The whole key is about limits and where to set them.. You do need some type of Oh Shit override, its just a matter of where..

There needs to be the addition of some fomr of power monitoring so there can be a "soft" disable, so that if things got really bad, the controller woudl still make an attempt.. It is possible that there is enough charge to momentarily open the valve injecting some oxygen but then forcing the controller to reset.. this may solve or at least improve the immediate danger..

31st October 2006, 13:42	#31 (permalink)
Mark Chase I go down for ages Current Rebreather/s: Classic Kiss Other Rebreather/s: Inspiration Classic Join Date: Jan 2005 Location: Kent Posts: 2,558	Re: Hard off switch on the Hammer Head Quote: (Originally Posted by jradomski) personally, I think a deco option WILL become available sometime in the future for the secondary as an upgrade (the pressure sensor is already there).. I know I wount chose the route... I like the fast response of the secondary.. When in classic mode its a true po2 display with very little damping.. Once you start to integrate deco, you slow the response time.. as dives start to get big you can REALLY start to impact responsiveness.. Having to do "test" ascents evertime you want to calculate a TTS takes alot of time.. Considering that all these devices want to use as little power as possible, they are generally run at the slowest clock frequency they can to save power.... I remember talking to Gene about the explorer, until he put in a few tricks his TTS was taking nearly a minute for big dives... I know I have done dives on the HH that the TTS calc took 30-45 seconds, so by the time it actually displayed the TTS it was already wrong! On some deep stuff I have seen deco jump over 30 minutes between TTS calculations.. And yet my inline VR3 never seemed to cause me a problem? it displayed PP02(ok on one cell only) and did deco calcs. It will be interesting to watch out for this on the sheerwater linked to all three cells. Perhaps I am not doing big enough dives to notice but I did take the inline VR3 down to just over 100m and it didn't seem to mind. On any big dive (which is past 60m for me) I have a picture in my mind of how much deco I will be doing anyway having analyzed dry tables on my PC before the dive so I am not shocked by the eventual figure. ATB Mark Chase __________________ Is it supposed to make that noise ? I took my unit to the dive shop and demanded they bolt on every thing that would fit. Join my elite diving teem and get a Tshirt "Doing It Chasey"Hammerhead Eccr Advanced Diving System
(Online)

31st October 2006, 13:45	#32 (permalink)
*jradomski* Moderator Current Rebreather/s: Inspiration Classic Sport Kiss Optima rEvo Other CCR Home Build Other Rebreather/s: Inspiration Vision Evolution Megalodon Classic Kiss rEvo Other CCR Home Build Join Date: Mar 2005 Location: "Da" Bronx Posts: 2,890	Re: Hard off switch on the Hammer Head Quote: (Originally Posted by Genesis) Uh, why would that be the case for the PO2 displays? No multitasking executive (or at least multiple threads?) in this thing? a full RTOS will take up too much resources.. some stuff you obviously can run as interrupt driven functions, but the overhead needed by full decompression software dictates you take a conservative approach.. in general since you dont have alot of ram to work with.. You need to run multiple copies of the data, for the actual loading and for the test ascents.. for this type of application I think a linear execution model is much more predictable.. (aside from the data sampling, input processing and final display) I personally prefer to keep interrupt drivent functions short and sweet.. Only do what HAS to be done there.. This keeps the system responsive and limits the nesting of interrupts.. I have seen to may apps fail becuase of nested/missed interrupts and running out of stack space.. Don;t get me wrong I am not saying, its not possible, it definately is, but there are always trade offs.. From experience, the normal operating loop on the HH appears (data processing, input check and then display) to be linear, but setpoint control and time keeping is a background operation.. __________________ Joe Radomski CCR Trimix Instructor Trainer ANDI Instructor Trainer Director #10 All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.
(Online)

31st October 2006, 13:50	#33 (permalink)
*jradomski* Moderator Current Rebreather/s: Inspiration Classic Sport Kiss Optima rEvo Other CCR Home Build Other Rebreather/s: Inspiration Vision Evolution Megalodon Classic Kiss rEvo Other CCR Home Build Join Date: Mar 2005 Location: "Da" Bronx Posts: 2,890	Re: Hard off switch on the Hammer Head Quote: (Originally Posted by Mark Chase) And yet my inline VR3 never seemed to cause me a problem? it displayed PP02(ok on one cell only) and did deco calcs. It will be interesting to watch out for this on the sheerwater linked to all three cells. Perhaps I am not doing big enough dives to notice but I did take the inline VR3 down to just over 100m and it didn't seem to mind. On any big dive (which is past 60m for me) I have a picture in my mind of how much deco I will be doing anyway having analyzed dry tables on my PC before the dive so I am not shocked by the eventual figure. ATB Mark Chase I'm talking about responsiveness.. yes it does work as does the HH, but as the deco piles up you will notice the po2 DISPLAY gets updated less frequently.. __________________ Joe Radomski CCR Trimix Instructor Trainer ANDI Instructor Trainer Director #10 All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.
(Online)

31st October 2006, 13:59	#34 (permalink)
Genesis Bubbless Box of Death Current Rebreather/s: Home Build Other Rebreather/s: Home Build Join Date: Oct 2005 Location: Sunny Florida Posts: 1,394	Re: Hard off switch on the Hammer Head Well, multiple threads of execution do not require a full RTOS. One of the benefits of at least some development-system level support for multiple threads of execution is that you can run things "in the background" (e.g. deco computations) without noticably impacting the user's experience in terms of what should appear to be "real time" data display. I realize that there is generally a clash between all of the various "I want's" when it comes to embedded systems control, especially when power management becomes a guiding light (e.g. the desire to run for 10s of hours on single a single disposable battery.) __________________ "A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American." http://www.denninger.net http://www.diversunion.org/liability.htm - Fix the Diving Cert racket
(Offline)

31st October 2006, 14:52	#35 (permalink)
*jradomski* Moderator Current Rebreather/s: Inspiration Classic Sport Kiss Optima rEvo Other CCR Home Build Other Rebreather/s: Inspiration Vision Evolution Megalodon Classic Kiss rEvo Other CCR Home Build Join Date: Mar 2005 Location: "Da" Bronx Posts: 2,890	Re: Hard off switch on the Hammer Head Quote: (Originally Posted by Genesis) Well, multiple threads of execution do not require a full RTOS. One of the benefits of at least some development-system level support for multiple threads of execution is that you can run things "in the background" (e.g. deco computations) without noticably impacting the user's experience in terms of what should appear to be "real time" data display. I realize that there is generally a clash between all of the various "I want's" when it comes to embedded systems control, especially when power management becomes a guiding light (e.g. the desire to run for 10s of hours on single a single disposable battery.) Thats usually the biggest clash.. especially since most low power microcontrollers only have between 128 and 1024 bytes of ram, and if you get one with 2048 you feel like you have the world..... and to really multithread apps you need to have plenty of ram available to store the intermediate results and all the registers.. on one of my projects I had to abandon a graphic display because it simply took up too much ram to buffer the screen... __________________ Joe Radomski CCR Trimix Instructor Trainer ANDI Instructor Trainer Director #10 All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated. Last edited by jradomski : 31st October 2006 at 14:57.
(Online)

31st October 2006, 15:09	#36 (permalink)
Genesis Bubbless Box of Death Current Rebreather/s: Home Build Other Rebreather/s: Home Build Join Date: Oct 2005 Location: Sunny Florida Posts: 1,394	Re: Hard off switch on the Hammer Head Yep - I was going to do a pixel-mapped display for the K1, but there wasn't enough RAM to buffer the screen and do it right, so that went out the window...... Seriously though 2k isn't that hard to find nowdays, and a threaded implementation is very doable in 2k...... The K1's controller code is multithreaded; there are four threads running in the present implementation (sensor read/condition, solenoid, buzzer and microswitch read) plus the "main", which is the display loop. There's enough room in the processor's EEPROM and RAM to do a relatively simple (e.g. gradient factor) deco algo if I wanted to - the current code consumes less than 1/3rd of the code space and (13k out of 32k) and about 1/3 of the available RAM (~600 bytes out of 1.5k usable), but I don't, mostly because I don't like the "all eggs in one basket" thing. One of the interesting things about the chip I'm using is that it has INTERNAL 10bit ADCs (8 of them), which, if you're willing to run millivolt signals down a handset cable (I'm not) can lead to a VERY nice "nothing but wire" solution in the head. It also has IEEE 32-bit floating point on-chip..... in its "standard packaging" its somewhat power hungry but if you put a different crystal (slower) on it you can cut that WAY down - the chip itself is an ATMEL ATMega32. (Really, do you need 14 MIPS of computational power for something like this?!) Thing is, I find the entire "ultra low power thing" to be somewhat of a red herring. Yes, you can make ultra-low power devices, so long as they're passive displays with no backlight! As soon as you want to drive a solenoid or backlight the power monster rears his ugly head and you start to deal with the compromises that seem to be at the root of this problem. __________________ "A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American." http://www.denninger.net http://www.diversunion.org/liability.htm - Fix the Diving Cert racket Last edited by Genesis : 31st October 2006 at 15:24.
(Offline)

31st October 2006, 16:02	#37 (permalink)
*jradomski* Moderator Current Rebreather/s: Inspiration Classic Sport Kiss Optima rEvo Other CCR Home Build Other Rebreather/s: Inspiration Vision Evolution Megalodon Classic Kiss rEvo Other CCR Home Build Join Date: Mar 2005 Location: "Da" Bronx Posts: 2,890	Re: Hard off switch on the Hammer Head Quote: (Originally Posted by Genesis) Yep - I was going to do a pixel-mapped display for the K1, but there wasn't enough RAM to buffer the screen and do it right, so that went out the window...... Seriously though 2k isn't that hard to find nowdays, and a threaded implementation is very doable in 2k...... The K1's controller code is multithreaded; there are four threads running in the present implementation (sensor read/condition, solenoid, buzzer and microswitch read) plus the "main", which is the display loop. There's enough room in the processor's EEPROM and RAM to do a relatively simple (e.g. gradient factor) deco algo if I wanted to - the current code consumes less than 1/3rd of the code space and (13k out of 32k) and about 1/3 of the available RAM (~600 bytes out of 1.5k usable), but I don't, mostly because I don't like the "all eggs in one basket" thing. One of the interesting things about the chip I'm using is that it has INTERNAL 10bit ADCs (8 of them), which, if you're willing to run millivolt signals down a handset cable (I'm not) can lead to a VERY nice "nothing but wire" solution in the head. It also has IEEE 32-bit floating point on-chip..... in its "standard packaging" its somewhat power hungry but if you put a different crystal (slower) on it you can cut that WAY down - the chip itself is an ATMEL ATMega32. (Really, do you need 14 MIPS of computational power for something like this?!) Thing is, I find the entire "ultra low power thing" to be somewhat of a red herring. Yes, you can make ultra-low power devices, so long as they're passive displays with no backlight! As soon as you want to drive a solenoid or backlight the power monster rears his ugly head and you start to deal with the compromises that seem to be at the root of this problem. The "threads" you are using makesense.. and are easily handled as interrupt events (periodic or real time) and really have no dependecny on other factors.. but once you start adding in morecomplex functions, alot of time you have to do things sequantially.. for example displaying data.. its all dependent on where you are and what is already ready.. The "main"function is best to logically go through a sequence unless you are off doing something other than your main "wait" loop.. You really cant put a display update as a peridoic function,since you would really have to start tracking multiple possible screens and have multiple "screen" buffers.. I've used avr processors in the past,and they work well for alot of applications.. __________________ Joe Radomski CCR Trimix Instructor Trainer ANDI Instructor Trainer Director #10 All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.
(Online)

31st October 2006, 17:37	#38 (permalink)
silent running Mature mouth breather Current Rebreather/s: Prism Topaz Other Rebreather/s: Join Date: Jun 2005 Location: U.S.A. Brooklyn, New York Posts: 1,813	Re: Hard off switch on the Hammer Head Quote: (Originally Posted by jradomski) I agree partially, but most of the resets are not due to this, its due to the system losing the ground of the battery.. In apps that I have a Powerhungry component, that I usually determine some threshold that I stop it from working, generate an alarm, and try and maintain the rest of the system in alarm state.. On a life support system this gets to be a tricky choice... If I am monitoring a serious condition like low o2, and I know I am past my threshold that will likely reset my device and lose all my data, do I try and see if I can solve the most immediate problem that is.. low o2,, I say thats probably the better choice, since its the most pressing issue, even though we know what the probably outcome is, but we MAY still be able to raise the o2 and solve The most pressing issue.... What good is deco data if you die of anoxia.. Joe, why would anybody die of anoxia if they're monitoring PO2 and can use the manual O2 inject? I have a hard time believing you or anybody else in a low power situation would rather lose deco info/power just to keep the solenoid going...
(Offline)

31st October 2006, 18:08	#39 (permalink)
cys ck #157 Current Rebreather/s: Classic Kiss Other Rebreather/s: Join Date: Feb 2005 Location: S. California Posts: 201	Re: Hard off switch on the Hammer Head Quote: (Originally Posted by silent running) Joe, why would anybody die of anoxia if they're monitoring PO2 and can use the manual O2 inject? I have a hard time believing you or anybody else in a low power situation would rather lose deco info/power just to keep the solenoid going... A functionally equivalent solution would be if the system gave a warning of an impending battery condition that will not support the solenoid, and then you, the user, could go in to the menu and turn off the solenoid. It is currently possible to turn the solenoid off in the menu (it's never completely off and will kick in at very low pO2). That said, the most pressing item still seems to me to be the possibility of removing the solenoid test firing upon initialization underwater.
(Offline)

31st October 2006, 23:50	#40 (permalink)
*jradomski* Moderator Current Rebreather/s: Inspiration Classic Sport Kiss Optima rEvo Other CCR Home Build Other Rebreather/s: Inspiration Vision Evolution Megalodon Classic Kiss rEvo Other CCR Home Build Join Date: Mar 2005 Location: "Da" Bronx Posts: 2,890	Re: Hard off switch on the Hammer Head Quote: (Originally Posted by silent running) Joe, why would anybody die of anoxia if they're monitoring PO2 and can use the manual O2 inject? I have a hard time believing you or anybody else in a low power situation would rather lose deco info/power just to keep the solenoid going... Well if it got to the point where the solenoid HAD to fire, the diver wasnt doing their job.. From a manufacturer's liability standpoint, it would be hard to argue the point in your favor that you knew the o2 was too low and you didn't want to try and inject some becuase you MIGHT reset the computer and lose some other data.. If the diver was doing his job, it would be above the point where it HAD to try and fire and the point would be moot.. You do need some line in the sand that if the o2 crosses this that you have to atleast give it a go, regardless of other settings/consequences.. I rather not lose information that is useful, but if for some other ** UP, my o2 got too low I rather have the controller try and cure the immediate danger.. The whole key is about limits and where to set them.. You do need some type of Oh Shit override, its just a matter of where.. There needs to be the addition of some fomr of power monitoring so there can be a "soft" disable, so that if things got really bad, the controller woudl still make an attempt.. It is possible that there is enough charge to momentarily open the valve injecting some oxygen but then forcing the controller to reset.. this may solve or at least improve the immediate danger.. __________________ Joe Radomski CCR Trimix Instructor Trainer ANDI** Instructor Trainer Director #10 All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated. Last edited by jradomski : 31st October 2006 at 23:54.
(Online)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode