Apr 17, 2001 Meeting Notes

 

In Attendance:

 

John Carmack

Russ Blink

Darin Smith

 

New supplies:

 

More distilled water

Tide for washing plumbing

Life jacket for piloted VTVL

 

On order:

 

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 workspace

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 mind.

 

Schedule

 

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 controlled hover.

 

Misc

 

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, pilot’s 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 didn’t 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 didn’t know.

 

The fuel level gauge was set by just integrating a chamber pressure sensor, based on chamber pressure being directly proportional to fuel consumption.

 

 

Magnetometer Testing

 

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 don’t know how fast the fields completely collapse, anyway.

 

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 didn’t 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 enter.

 

GPS Interference

 

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 (weakly) indoors.

 

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 purpose...

 

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 Spider.

 

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 comparison.

 

I calibrated the load cell with a 1kg reference mass, which is only about 2% of it’s 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 aren’t 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.

 

media.armadilloaerospace.com/2001_04_17/testruns.xls

 

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 don’t 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 don’t need to run both a serial and parallel cable to the test stand.