Apr 17, 2001 Meeting Notes
More distilled water
Tide for washing plumbing
Life jacket for piloted VTVL
High-flowing billet solenoid valve
Longer serial cables
PC104 A/D board
Our peroxide drum
Pilot headsets for piloted VTVL
Phil: you should come over and grab another table for the
Russ: should we put up some peg-board on the wall to make
finding the tools easier? We should
make a list of any additional tools we still need to get. More vise grips and a socket set come to
Our expected HPR launch of our electronics systems was
rained out over the weekend, so we are reconfigured back to the VTVL.
The peroxide drum is supposed to arrive on Friday. I will call Rinchem tomorrow and see if we
can get five gallons drawn off on Sunday.
If so, we are going to try and fly Spider for real then.
Our gyro board is finally doing exactly the right
thing. There were a couple wires
crossed, but now we are getting the full precision on all axis.
The static drift rate is very good around a degree a
minute. The integration accuracy when
moving it around seems like it will be good enough for our needs, but swinging
it 90 degrees and back will usually result in a few degrees of mismatch. There is still a noticeable cross-couple
between the axis of each gyro, but it is consistent, so I should be able to
factor it out in software.
I am going to be at SpaceAccess 01 next weekend giving a
talk about our projects, so I am really hoping to have video footage of a
We made four brand new catalyst packs for the VTVL engines
today. We are trying one new
modification: on top of 15
silver-plated foam disks, we have also added four non-plated disks. The intent is to try to provide some
spreading of the incoming peroxide before it begins reacting. The compression has also been slightly
increased, with all 19 disks being compressed the same amount as we were
compressing 15 before.
Over the weekend, I got all four serial ports working with
live devices on the flight computer for testing purposes, and learned a few
more things about configuring Linux. I
had five simultaneous data sources running: UDP telemetry, sensor board,
magnetometer board, pilots joystick, and GPS.
Doing some dumps of all the activity every second showed that my home
network was occasionally duplicating UDP packets on the wireless link, which I
need to investigate a bit more.
I have a Lucent Orinoco 802.11b card for the flight computer
now (to replace the Prism II based Linksys one), so I should be able to get
Ad-hoc networking running without carting the base station around now, but my
first stab didnt work, so I need to investigate a bit more.
I recommend the new NASA mission Reports series of books
in general, but two notable things popped out from reading the X-15 reports:
Hydrogen peroxide is apparently hypergolic with ammonia,
which I didnt know.
The fuel level gauge was set by just integrating a chamber
pressure sensor, based on chamber pressure being directly proportional to fuel
We tested a magnetometer in the flight computer box
today. Turning on the engine solenoids
caused up to a 50% increase in the reading on one axis, and up to 20% on the
other axis. As is, it would be hopeless
in our dynamic environment, but if we really wanted to use one, there are four
directions we could follow:
Larger vehicles could move the magnetometer much farther from
the solenoids (they were around 2 away today)
We could try to add shielding around the solenoids.
We could arrange for the solenoids to all turn off at a
specific time and just read the magnetometer then, but that would prevent us
from getting full throttle, and we dont know how fast the fields completely
We could measure the field for each solenoid, and try
subtracting the active solenoids out of the reading, but the on/off ramps would
make it complicated.
Absolute attitude sensing remains an issue
A couple things showed up while testing the magnetometer:
The flight computer didnt shut off all the solenoid bits
when it finished booting. It might be
using the version of setlpt that has the desktop IO port on it.
I still need to look into why redirection console output on
the flight computer immediately aborts the program as if the user had pressed
When I first started testing the Garmin GPS-35, I could get
a position fix with it on my desk.
When we put the GPS neatly on top of the PC104 stack, I
found that I couldn't get a position fix unless I took the stack out to the
middle of my back yard.
Over the weekend I added some diagnostic code to report the
signal strength of all the tracked sats, and powered up each device separately.
With the GPS connected to my laptop, but still installed on
the PC104 stack with everything else powered off, I could get five sats
Powering up the sensor board, which was directly below the
GPS, didn't have any noticeable effect.
Powering up the computer dropped all the sats, even before
the wireless ethernet card was initialized.
After I halted the computer (but left it powered up) and the
wireless ethernet was shut down, it eventually picked up a single sat.
Cutting the power to the computer instantly added 12db to the signal strength
of the sat, and it then began picking the others back up.
I was expecting it to be the wireless ethernet card, but it
turned out to be just the normal computer bus operation. I guess all that
annoying thin sheet metal shielding inside computers actually does serve a
I unscrewed the gps from the top of the stack, and thankful
that I had left a foot and a half of cord on it, moved it away from the stack
and powered everything else back up.
With it separated by some distance, the sats came in again.
We can't just put shielding around the PC104 stack, because
the wireless ethernet needs to get out.
For HPR launches, we can probably mount the PC104 stack on
the bottom of the electronics tube and the GPS on the top, but we may need to
stick it on a (easily damaged) pole on top of Spider for later long-duration
flights. We will probably just wind up not doing any GPS work with
The correct solution is probably to get an external antenna
802.11b card, and properly shield the electronics box.
Test Stand Work
Russ had done some machining for a friend to make one of the
micro hybrids that have been talked about on the web. It basically uses a whipped cream N2O
cylinder and a rolled paper grain, started by a tiny block of AP propellent.
We tested the new load cell amplifier and high (240 hz) data
rate acquisition with a couple runs of this, then ran a couple Estes motors for
I calibrated the load cell with a 1kg reference mass, which
is only about 2% of its full scale value.
I need to grab a 25lb weight to get a better calibration for out
peroxide motor testing.
The load cell and test stand arent terribly accurate at
this low thrust level, and there is about 4N to 5N of friction in the slides,
but the graphs turned out pretty nice.
240 hz sampling is much, much nicer than our old 12 hz samples.
The N2O injector was drilled out a bit for the second micro
hybrid run, resulting in a much better burn, but it still seemed to burn out
and vent N2O at the end. The Estes
motors have a nice, flat end-burner profile after their initial core burn.
These low-thrust tests did resolve something that we had
wondered about the engine thrust values should include the friction in the
test stand, not subtract them out.
The next time we run our mule motor, we will collect both
load cell and pressure transducer data at 120 hz.
Neil: have you been able to get us 6 of hard line to move
the pressure transducer away from the engine?
Russ: when you get a chance, you might want to make a bigger
nozzle for the mule motor for testing.
Alternatively, if we dont care about logging thrust
numbers, we could collect all the data we need by running the mule motor
without any expansion section (just a converging section and the throat) and
just logging chamber pressure. We could
just use the existing original nozzle, and just keep drilling it out between
runs. We could back-calculate what
thrust would be for a given expansion ratio.
I would also like to get combined pressure / thrust logs for
an engine with a full expansion cone, but at different tank pressures. From the ratio of pressure to thrust, we
should be able to see if our expansion ratio is sized correctly.
I am going to see if the dataq needs all the modem control
lines for power, and if not, I am going to move the test stand solenoid control
to the serial cable, so we dont need to run both a serial and parallel cable
to the test stand.