April
3, 2001 meeting notes:
In Attendance:
John Carmack
Russ Blink
Phil Eaton
Neil Milburn
Darin Smith
New supplies
4 x 1/8” NPT male to ¼” NPT female fittings
4 x 1/8" NPT female/female fittings
4 x 1/4" NPT female/female fittings
4 x ½” NPT male/male fittings
½” NPT female T fitting
½” NPT manual ball valve
-6 and -8 hose end wrenches
MachZ PC104 CPU board and utility board
PC104 VGA board
PC104 ISA bus adapter
Extra PC104 standoffs
Bench top DC power supply
6 liter flask for measuring large peroxide loads
4 x disposable chemical safety suits for manned vehicle
150’ of 800 lb strength chain for tethering the manned
vehicle
We now have our own domain name:
www.armadilloaerospace.com
We finally have storage arranged for our drum of
peroxide, and X-L will be shipping it out before the end of the week. The minimum chemical warehousing invoice is
$500 a month, so we probably won’t stay there permanently, unless we wind up
storing multiple drums at a time.
Peroxide supply should be off the critical path
for quite some time now.
Attitude sensing is probably the only remaining
critical path issue for Spider. Russ is
now directly comparing the circuit in the GyroMouse with what we have on our
sensor board, trying to get the Gyration ASICs to work right. Once we get data of comparable stability to
what the GyroMouse demonstrated, but without the mouse protocol sync issues, we
should be good to go.
I am crossing my fingers, hoping that we will
have hovering flight video for Space Access ’01.
Computer Stuff
We are planning on launching some of our
electronics package in a conventional HPR rocket at the next Dallas area launch
next weekend. We will get GPS, rate
gyro, and accelerometer data logged, and test the telemetry link under real
world conditions.
We are going to use Neil’s level 3 rocket, so
space isn’t much of an issue, but I still took it as another incentive to try
out a different CPU module for our flight computer. The one we have used in Spider in an EBX form factor single board
computer from WinSystems, with PC104 modules stacked on top. It is a very full featured board, with Ethernet,
video, and four serial ports, but it is 6”x8”, extending well past the 4” by 4”
PC104 stack.
I recently got a Tri-M MZ104 CPU module, which
is a normal sized PC104 module. It has
USB support, a more modern BIOS, and support for 64mb of ram (up from 32mb on
the other), but only has two serial ports, no onboard video or Ethernet, and the
system nvram battery and speaker are on a separate utility board.
In theory, I should have been able to just pull
all the PC104 boards (DC/DC power supply, IDE Flash drive, PCMCIA adapter) off
of the old CPU board and plug them on the new one, and it would boot right up
for me to telnet in.
It didn’t work out that way.
With no onboard video I couldn’t debug why it
wasn’t booting, so I had to buy a PC104 video board. I also got a PC104 to ISA bus adapter, which I was going to use
if I needed to add an Ethernet before the PCMCIA got working, but I couldn’t
find an ISA video card anywhere (it’s been at least seven years since I’ve seen
one), so I had to get a dedicated PC104 video board.
What I finally found out was happening is that
the WinSystems BIOS identified my flash drive as having 32 heads, while the
Tri-M BIOS identified it as having 16 heads, so it couldn’t load LILO. The Phoenix bios on the Tri-M didn’t even
support 32 heads as an option, but the WinSystems bios did allow 16 heads if
you disabled LBA mode.
So, I had to configure both BIOS in a non-default
way and reformat the drive to get it to the point where I could move the drive
between the two systems and have it boot on both.
An added annoyance of this arrangement is that
the Tri-M board doesn’t have an nvram battery on the main cpu board, so it
wouldn’t keep the non-default bios setting after a power down unless the
utility board was plugged in.
The utility board is sort of nice, with firmly
mounted connectors for mouse, keyboard, serial, parallel, USB, etc, but it
doesn’t have a PC104 stack-through, so it positively caps the stack, which
limits flexibility a bit. Also, the
utility board didn’t actually fit with the included cables. I either had to get slightly longer ribbon
cables and use taller standoffs, or remove a couple connectors on the bottom
that interfered with the PC104 bus connector below it. That was odd.
Finally, everything got worked out. I’m still not sure which setup I like
better. The pure PC104 stack is more
compact, but I may need to add another board for more serial ports, and pulling
the video board on and off is enough of a hassle that I may just leave it on,
which further diminishes the form factor advantage.
I got enough standoffs so that we can secure all
four corners of the PC104 stack, to prevent the flexed pull-out that we saw on
the last flight test. There is still
some concern that the nylon standoffs might strip if the parachute in the HPR
deploys hard.
One of the minor issues with our current
electronics box is that the solid state relay driver board is run off of the
parallel port, which boots up with a couple bits set. If it boots before the tank is filled, that just wastes battery
power, but if the computer has to be rebooted for any reason while the tank is
full, we need to disconnect the driver board or the engines would fire.
I had hoped that we would be able to get around
that by using the dedicated digital IO port on our WinSystems SBC, but it turns
out that they all boot as on. If we rebuild
the driver board, we could add an optional inverter and use the DIO lines, but
for now we are just going to live with it.
An issue we are going to have at the McGreggor
launch is that our current telemetry setup requires a wireless base station, so
I need to do one of three things: make a battery pack for the base station, get
the native Prism II driver working, or buy a new Lucent Orinoco card that is
well supported by the main driver.
I wrote code to directly read the data from a
serial port Logitech Wingman Warrior joystick, which is probably what we will
use on the manned vehicle. I like the Microsoft
Sidewinder Precision better, but it is USB only. I could have just used the Linux joystick drivers, but for flight
control operations, I really like doing as much of the work as possible in a
single application. I vastly prefer to
enable IO ports or map memory regions into a root user app over writing kernel
drivers.
I built cables and wrote code to interface with
a Garmin GPS35 OEM unit, which is a very nice, compact GPS without any user
interface. In addition to the expected
NMEA text format, the Garmin binary interface include the position in floats
and doubles (as opposed to only thousandths of a degree-minute in NMEA), which
brings up the possibility of doing some attitude sensing with multiple sensors
if the positional errors are exactly correlated between the units.
I am beginning to investigate getting some generic
A/D channels on the flight computer for other sensors. I am currently torn between using a PCMCIA
solution that I could also use in my laptop, or a simple IO port mapped PC104 solution
that would work directly from user mode on the flight computer without having
to deal with PCMCIA kernel driver issues.
New Data Acquisition
Our previous testing has been done with a load cell meter
from Omega that also outputs the meter readings over a serial port. The major drawback has been that it only
outputs twelve samples a second even in “fast” mode, which is not enough to
investigate many engine characteristics.
We also determined that the samples were instantaneous, rather than
averaged over the 12hz period, so pulse width modulated streams came out
extremely noisy.
We are moving to amplifying and reading the load cell
directly, without the meter, and also reading chamber pressure simultaneously with
the engine solenoid control.
We are using a Dataq DI-151RS A/D converter that I have had
for a while. It is pretty low end, but
it seems to work ok. It connects over a
serial port and can either read one channel at 240hz or two channels at 120hz. The range is 12 bit –10V to 10V, and it
checked out right where it should on the bench power supply.
I made a new version of our script driven test stand driver
program that reads and logs the dataq instead of the serial meter. They offer an active-X control for their hardware,
but after some digging around I was able to get the raw serial protocol, which
was more what I wanted.
I bought an OmniAmp III from Omega to provide a regulated
10V excitation and amplify the millivolt level output from the load cell.
The pressure transducer is an OMega PX703-1KS5V heavy duty
1V to 5V output with a 1000 psi limit.
We made a bunch of test runs tonight with the pressure
transducer at the 240 hz sampling rate, intending to investigate the chamber
pressure during pulse width modulation, but we ran into some issues.
We calibrated the pressure transducer against the regulator
on our nitrogen bottle, getting the following values:
0 psi: 2250
100 psi: 2332
200 psi: 2414
300 psi: 2497
400 psi: 2578
A solid 82 units per 100 psi, right on the expected 1000 psi
range from 1V to 5V.
We loaded up a water test and ran it to test the connections
and software. It operated as expected,
showing some pressure during the blow down phase, but it had the peculiarity
that the pressure dipped noticeable below zero at the end. I checked the current outputs, and it was
back at zero.
We then did a 200ml peroxide run with the test script. The run was pretty wet, never completely
clearing up. The pressure graph also showed
much higher numbers at the end than should have been possible – 600+ psi with
only a 400 psi tank pressure.
Assuming I had botched the psi calculation, we made another
run with it just outputting the raw A/D numbers, and did some conversions by
hand. Same result – starts off sort of
reasonable, but then goes much higher than it should.
The runs were still wet, so we decided to make a fresh
catalyst pack. The existing pack was a
couple months old, and had been fired a lot.
On opening it up, there was some preferential stripping down the center,
so we might want to consider going back to having a spreader plate on top of
the pack.
We cut a new pack with 15 disks compressed by a half inch,
and set up for a simple, straight run without any pulse testing. The run was perfectly clean, although there
was a little audible pulsation after the first second of firing. We are used to seeing that when we don’t
compress the packs quite enough. Fresh
packs made like this will consistently work well, but we still need to figure
out exactly the process by which they “wear out”. ERPS people have suggested that our water testing is probably bad
for the packs.
The data from this run was interesting. After starting perfectly smooth, you could
clearly see the audible pulsations in the data. With our old setup, this would have come out as random noise, but
now we could zoom way in and see that they were nice little sine waves. However, the pressure climbed way up at the
end again.
We weren’t trusting our instruments at this point, so we
took a normal pressure gauge and screwed it into the engine. Russ put on one of our new chemical
protection jumpers and stood close enough to watch the pressure gauge during
the next firing. The next firing was
clean just like the previous one, and Russ reported that the needle bounced
around during the pulsations, but did not rise towards the end.
We are now out of peroxide until the drum arrives.
When I got back to the office, I looked up the pressure
transducer spacs. It is listed as Operating
Temperature: -40 to 250 degrees F, Compensated Temperature: -4 to 185 degrees
F. When we vented the nitrogen at the
end of the water test, it probably went well below –4, and certainly engine
operating temperature goes well over 185, so I expect that that is our problem.
We could probably get through a run by just putting the
pressure transducer on a hose to keep it farther away from the engine, but that
will probably have some effect on the latency and chamber blow down
volume. We may try just filling the
transducer with water or silicone to buffer it a bit.
If we trust the initial data before it clearly goes out of
whack, it means that we have a chamber pressure of over 300 psi, which calls
into question one of the assumptions we had been making.
We scaled our original engines based on the numbers Juan
Lozano provided for the engine we contracted from him, which assumed 400 psi
inlet pressure and 300 psi chamber pressure for a 100lb thrust motor. Scaling from there down to our desired 15lb
thrust motors gave us a fair amount less than 15lb of thrust. I assumed that our heavily compressed foam
packs were giving a lot higher pressure drop than his packs, so our chamber
pressure must be lower.
Now that we have measured data, I am inclined to believe that
Juan’s listed numbers were calculated, rather than measured.
Two representative runs from today’s tests are here:
media.armadilloaerospace.com/2001_04_03/Pulsed.xls
media.armadilloaerospace.com/2001_04_03/FullRun.xls
The yellow line is the pressure trace, the pink line is the
solenoid on/off state, and the first column is just timing info for me to make
sure we aren’t dropping samples. You
can still learn some about the pulse attack and decay behavior, even though the
pulsed run was with the bad catalyst pack.
When we test again, we will compress the pack some more to
see if that makes the pulsations go away as it did on previous tests. Russ is talking about trying to machine some
cavitating venturies as inserts into pipe fittings, which should, in theory, go
a long ways towards smoothing out runs.
Now that we know that we aren’t losing as much chamber pressure as we
thought, there isn’t as much incentive to work with looser packs, except for
the 98% capable ceramic catalysts from X-L.
Todo
Clean up pwm2.exe to take a parameter for single or dual
channel, find the missing column bug
Temperature test the pressure transducer
Make a PC104 mounting plate for the GPS-35
Get all my source code up on OpenVTVL at SourceForge
Find large foam blocks to test as landing gear.
Get seat for manned vehicle
Finish the direct load cell sampling setup
Wireless base station issues
Update flight computer software to log and transmit GPS
Update GPS trace visualizing program to take UDP as well as
radio modem input
News
