February 8, 2004 notes

 

Electronics work

 

Because we had to put the flight computer on the charger several times during testing last Saturday, I replaced the main battery with a new one nearly three times as large.  That took a fair amount of rearranging on the electronics board, but it should allow us to have the computer on for  almost six hours without a problem.  Our electronics are all still on the circular board that was originally intended for the 2’ diameter vehicle, even though it looks like we are probably never going to fly that configuration.  I will probably wind up rebuilding it on a new mounting board the next time we make a major change.

 

I finally figured out why I couldn’t get the four port serial board working with the Ampro CPU board: the highly integrated board only has two free IRQ available in the default configuration, one of which wasn’t available on the serial port board.  The Ampro won’t let anything else on the PC104 stack fire an interrupt that it might, even if you aren’t using that particular device, like the floppy or LPT port.  The latest bios flash lets you disable the LPT port to get another one back, which I will have to do for the next serial port I need (or mess with the linux kernel to get shared IRQ working with the WinSystems four port board).  I am looking forward to moving to the latest Ampro CoreModule board, which includes four rs232 ports on the CPU board.  That will cut our PC104 stack to only two boards, the Ampro and the AccessIO A/D + DIO board.

 

Ashtech replaced our G12-HDMA GPS with a brand new unit, which works fine.  The original unit would lock up after five minutes, and their initial “repair” (for >$500!) was to reflash the firmware and run it through their quality tests again.  It still locked up after five minutes when I got it back.  After an additional complaint, they sent a brand new unit, which is operating perfectly.  We get 10hz updates, and while the position updates do have occasional discontinuities like all GPS, the velocity updates are very smooth.  Auto-hover should work much better with this than when we were using the laser altimeter.

 

Now that I had the extra serial ports working, I was able to finish the integration of the master cutoff computer.  I had originally had the valve opening only when going into an engine firing mode and closing immediately on release, but the slower 2” cutoff valve made it difficult to do small engine pulses for testing, so I changed it to open initially when the flight control program is started.  If the main computer dies for any reason, the cutoff computer shuts the valve and all engines will go dead, preventing any possible uncontrolled thrusting.  Because the vehicle is naturally unstable, it would veer off course immediately and probably go into a tumble if the computer just shut off, which would cover little ground, but it is safer still to just make it fall like a rock.  The main computer communicates bidirectionally with the cutoff computer, so it can trigger a soft abort-to-powered-landing if the cutoff computer has died for any reason and removed the redundant cutoff.

 

The electronics are completely ready to go for flight tests, and I have been making many minor improvements in the laptop software as well.  The only thing that I am still trying to isolate is that there are occasional errors in the serial communications on the flight computer.  Everything is checksummed, so we don’t get bad data, but I would still like to figure out why we get the occasional bad byte.  It seems to be pretty even over both the GPS and IMU, with a failed checksum every ten minutes or so.

 

Engine problems

 

Unfortunately, we are having problems with our engines.  We haven’t gotten one of the new welded engines to work right, even on the test stand, and we have done a LOT of tests this week.  This is extremely frustrating, because every other aspect of the vehicle and operations are ready to fly today.

 

The great performance that we originally saw with this design may have it right at the edge of working, and minor changes may be inhibiting it.  The last engine that we ran on the test stand basically had very few changes to become engine 0: the spreading plate was replaced with the smaller hole version, the monolith catalyst support was changed from a single bar to a cross, the spreading screens were reduced from ten to six because of the new spreading plate, and a flat top was welded on instead of the bolted aluminum top.  We have been trying to change back to the old configuration, but we can’t replicate it exactly because when we cut the engine open, it has to be below the top flange, so we can’t get enough room at the top.  Even more unfortunately, we don’t have any more fresh rings or 900 cpsi monoliths for complete rebuilding, and they may be long-lead items.  If we have to get new materials, we will overbuild the catalyst to make it less finicky, even if it gives a worse engine T/W.

 

We experimented with different sequences of computer controlled valve pulses for warming, and had a notable experience:  We had warmed an engine most of the way with a nozzle plug, and I had just changed to a slightly longer pulse width, when we saw the feed hose kick hard, knocking a wrench off the trailer.  On the next pulse it did it again.  Russ touched the hose and found it very hot, so we immediately ceased operation and purged tank pressure.  We then figured out that the big valve was able to let such a big slug of propellant in initially that when it cooked off, would generate higher pressure than the tank pressure, and it wasn’t able to completely vent down past the nozzle plug before the next pulse, so when the valve opened again, chamber pressure back flowed into the hose.  This, in combination with the fact that pulses also put a lot of heat into the cold pack, is probably moving us away from pulse warming, unless we have the computer monitor chamber pressures to prevent backflow.