Home / News

News Archive

April 3, 2001 meeting notes

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:



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:





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.





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









© 2001-2011 Armadillo Aerospace, LLC. All rights reserved.