[AR] Re: Safing of liquid vehicle

  • From: "Monroe L. King Jr." <monroe@xxxxxxxxxxxxxxxxxx>
  • To: arocket@xxxxxxxxxxxxx
  • Date: Tue, 10 Nov 2015 02:02:37 -0700

You could double up on that by locking out the main valves with a second
switch.

I would also use mechanical removable lock out devices on the supply
lines.

Remote filling would become a factor at some point. That point would be
when I felt a tank rupture would kill people on the pad flying pieces
not withstanding. (when protective clothing and gear would not be
sufficient)

-------- Original Message --------
Subject: [AR] Re: Safing of liquid vehicle
From: "Monroe L. King Jr." <monroe@xxxxxxxxxxxxxxxxxx>
Date: Tue, November 10, 2015 1:47 am
To: arocket@xxxxxxxxxxxxx


I think a pneumatic switch near the pad would be the best solution. Have
that switch activate your circuit breaker for main power.
I think primary logic systems could safely be activated and the ground
crew could monitor systems other than main control such as telemetry and
comms.
All main control systems would be tied to that main breaker and
inoperative during pad operations. Allowing other on board systems to be
active.

The line on the pressurizing end of the pneumatic switch would not be
connected until the pad is clear.



-------- Original Message --------
Subject: [AR] Re: Safing of liquid vehicle
From: Paul Breed <paul@xxxxxxxxxx>
Date: Mon, November 09, 2015 11:50 pm
To: arocket@xxxxxxxxxxxxx


Thinking about it I'd put 25 ohms in series with the opto rleay and put
short on other side of 25 ohms to be nice to drive electronics...



On Mon, Nov 9, 2015 at 10:43 PM, Paul Breed <paul@xxxxxxxxxx> wrote:

I really don't like switches......
So what I would do is add a direct Short on the Input side of Opto solid
state relays powering the electronics.
The logic drivers/cpu should not be damaged by brief operation into the
short.

I'd test that the relay won't activate with short in place.
I would put this short on a plug (think phono plug) with a long kevlar
lanyard.

Then I'd walk away and pull the plug remotely.

I did some remote pyro stuff for a rookoon and the entire pyro ignition
system had both the ground and power
sides of the circuit switched by cap coupled MOSFET switches... ie if the
cpu was not activlly pulsing the fet gates throgh
cap -> diode -> gate The switch was not on. Had LED betwwen highside
switch and ground and low side switch and power...
So when either of the pyro activations was active LED's would be lit.....
Pyros would not fire unless BOTH switches were active and the individual
pyro channel was active.















On Mon, Nov 9, 2015 at 8:38 PM, <qbert@xxxxxxxxxxxxxxx> wrote:

We used a form of your servo ball valve system in the Condor and it
proved to be very reliable. At first all we used was a re-playable servo
controller and then as we went further along we got into autopilots and
mini computers to control all of the electronics right from the throttle
on
up to the recovery systems. Just about everything had a servo
incorporated
into it's inner workings in one form or another.

Robert

At 08:24 PM 11/9/2015, you wrote:

That's essentially equivalent to computer failure or valve failure. I
had considered putting small DC solenoid valves on each tank (powered
remotely) for that exact reason. My original plan was to use those as
the
primary tank vents too (either the onboard or ground power could open
them)
but I decided to go with my custom servo ball valves, mainly because I
needed the LOX vent not to freeze up during filling. Looking back, it
would have been cheaper to use the solenoid valves as vents and have a
separate manual valve for the LOX vent during filling.

That would be a bummer of a day though - get everything fueled up and
ready to go, only to have the onboard computer die. That's why I plan
to
have a spare of every removable component ready to go:)

-Bob

On 11/09/2015 08:46 PM, Mark C Spiegl wrote:

One scenario which keeps me up at night is a power failure at the pad.
(and frequently overlooked by amateurs) Something somewhere in the
system
should fail into an _open_ state, or at least have the ability to be
manually opened without too much risk. Power failures happen for all
kinds
of silly reasons.
Â
--MCS
Â
Â






Other related posts: