LOHAN sucks Reg reader's instrument to death As followers of our Low Orbit Helium Assisted Navigator (LOHAN) project will be aware, we've done quite a bit of head scratching as to how we're going to fire the rocket motor of our Vulture 2 spaceplane. Click here for a bigger version of the LOHAN graphic Over the past few months, we've been working inexorably towards a …
isn't there a shop somewhere in Malta that sells barometric pressure switches like the ones made in switzerland, just a different colour? I have absolutely no idea of how easy it is to get them posted from Virginia to Espana. As for vac pressure gauges for my cyclotron we used to buy some s/h stuff from Island Scientific Ltd on the IoW www.island-scientific.co.uk, they have an Edwards Model: VSK16K 30mB-1000mBar absolute but might have some smaller/cheaper ones?
GA aircraft and Air Transport (airliners and cargo planes) follow ICAO rules and work in knots (speed), feet or flight levels (height), ft/min (rate of climb) and nautical miles (distance). Flight levels are measured in units of 100 ft using an altimeter set to 1013 mb, so FL 120 is nominally 12000 ft but may vary by several hundred feet either way depending on the barometric pressure at that time and place.
Gliders generally use ICAO units except that we measure rate of climb in knots (a) because its easier to calculate glide angles when both airspeed and climb rates are in the same units and (b) 1 knot is almost exactly 100 fpm. Except, that is, in Europe, where gliders are metric so they use km/h (speed), metres (height), m/s (rate of climb) and km (distance). Also, glider pilots almost everywhere measure the tasks we fly in km, mainly because that's what the FAI uses and most of the recognised achievement badges and diplomas are defined by the FAI.
I don't know what units the military use, but ICAO units would seem probable since this would simplify interactions between military and civil air traffic controllers.
Instead of a Bourdon or Diaphragm gauge, perhaps you should be using a Thermocouple/Pirani/Thermistor gauge. These work by having a heater and temperature sensor (the same element in the case of the Pirani gauge) and the device gets hotter the less gas there is to cool it. Work well down to milliTorr (1 Torr = 1mmHg).
http://www.belljar.net/tcgauge.htm
C'mon, blokes. You already have a GPS aboard which has been qualified to report MSL elevation (altitude) above 65,000 ft. That data will be FAR more accurate than the reading from an absolute pressure instrument operating at just one percent of full scale. Except for an instrument-grade transducer that will be too heavy and costly to fly, most have cumulative errors on the order of +/- 1%, and that's the absolute pressure you're trying read! We learned this lesson early on when we first started flying GPS beacons along with telemetered baro pressure, which we had previously relied on for determining altitude. We were crestfallen to learn that what we had believed to be apogees in excess of 120K' turned out to be more like 90 - 100K' per the GPS. And given that the rocket ignition altitude is mission critical, wouldn't you want the most precise measurement available up there?
Assume the tube is 10 inches across - area of the tube end is 5 squared Pi or nearly 80 square inches.
At a vacuum of 26 inches of Mercury, the force down on the lid is the equivalent of having the best part of 1,000 lb sat on it.
I'm assuming a vacuum of 29 inch Hg is -15 lb/square inch pressure.
(I think my aths is correct, but if not do please point out where)
Actually, these look like the solidest bricks I've seen in Spain. This weekend I tried to put a (ahem) big TV on a wall for someone.
The wall is made of bricks that have a skin of about 8mm, a 40mm gap and then another skin of 8mm. The skin is terracota (so more fragile than glass), and the individual bricks are about 500mm long and about 200mm high. (yes they are stuck together at the edges see example here The right-hand side is an outside wall; the left-hand side is an internal wall. The yellow bit could be insulation, butis normally air; in fact for external walls, there may only be a single skin of bricks. or here )
The TV has a mass of 35Kg, plus add anouther 8Kg for the bracket and it was a case of guess what happens. Is it that the fixings just pull out of the bricks, or that the brick gets pulled out of the wall, still attached to the TV?
Next weekend I'll find out.
I'd recommend this:
http://www.featherweightaltimeters.com/The_Raven.php
The baro is good to 100k feet, has high-current outputs designed specifically for lighting rocket motors, and is very configurable. It's also designed and sold by a guy who worked on the power systems for the Mars Rovers, so he knows what he's doing...
I doubt that you busted the sensor, it's quite robust and well protected. The batteries should be well enough sealed for short-term use.
Nope, my suspicions were aroused by the maximum altitude figure of 32707ft, which, as any fule kno, is close to the upper limit of 32767 for a signed 16 bit integer. Any more than that and the top bit will be set, which will make the value negative. What happens after that is up to the software.
This time RTFM could be misleading; the MS5534 datasheet says 'All calculations can be performed with signed 16-Bit variables.' Maybe so if you deal only in metres.
You're not the first to be had by this one, I found in 1986 that FS II on the Amiga would fly into the ground if you set the autopilot for more than 32767 feet, and the first Ariane 5 launch was downed by almost exactly the same bug.
You might need to reset the thing to get back the calibration data, but it's probably not broken, unlike the Ariane. Have fun!
This post has been deleted by its author
Mr Barnes returns to the code from six years ago and has a look...
Altitude is a 32 bit variable, so that should be ok.
Arse... >> show_altitude((int)altitude,1);
ints are 16 bit on this compiler/processor... good spot, John. In my defence, it was intended to stop within *breathable* atmosphere!
Lester, if you want to send it back I'll have another think about. Still don't know why it stopped working, though.
Yes.
The (int) cast will just slice off the high bits, so there would be a sign change to negative at 32768 (-32768) feet. The display routine converts negative back to positive and holds the sign separately, so an increase in altitude over 32767 would show as a descent back to zero; thereafter it would climb again.
So I think your analysis is correct. Easily fixed either by persuading the display to use more digits and a long int input, or by (cough) using meters instead!
If the display's still alive, of course.
That reminds me of a similar exploit in Elite: Frontier on the Amiga. That game used unsigned 16-bit integers to compute interstellar distances with each increment representing 1/100th of a light year. This meant that if you set your hyperdrive to jump to a system exactly 655.36 (or a multiple thereof) light years away, the jump would take zero time and apply zero "wear" on your hyperdrive, allowing you to use it for much longer without having to pay for "maintenance".
I remember my friend and I then wrote a program in Blitz Basic on the Amiga to compute Pythagorean jump coordinates for all the major systems in Elite: Frontier. For example, if you wanted to jump from Lave to Facece, our program would find you a system as close to (but not less than) 655.36 light years away from both Lave and Facece as possible, allowing you to hop between the two systems in virtually zero time and with no wear on your hyperdrive.
As a result, we were able to get from the Eagle starter ship all the way up to a fully-equipped Panther Clipper with a Large Particle Accelerator in less than 3 in-game months!
The total failure could very well be heat related. The power supply and other parts need convection to keep cool. Convection is not possible without gas. Your faulty altitude readings might also be related when the analog voltages went out of regulation or got too noisy. If there are any electoytic caps they might have failed as most are rated to only modest altitudes.
I've never tried exposing AA batteries to a decent vacuum but I wouldn't be that surprised if they leaked.
Also this is probably a good test to do to your electronics bundle before launch. If they're going to overheat/leak/explode it'd probably be better to find out before launch
I don't thing a separate altimeter is needed. Tap the NMEA data feed between the onboard GPS receiver and your tracking transmitter, feed it to a program that extracts the altitude from the data stream and use this to trigger the launch.
In a little more detail: parsing the GPGGA sentence provides the 'antenna height' information. All the program needs to do is recognize when a preset height has been exceeded and trigger the launch sequence. Any Arduino or similar micro-controller with a serial input and a digital output should be easily able to handle this. Possibly even a Parallax BS2 STAMP could manage it. The launch trigger might be as simple as using a relay or a MOSFET to switch on power to the rocket igniter.
The COCOM non-military limits on GPS are i think you cannot exceed 1,000 knots speed and 60,000 ft altitude at the same time.
In theory with all chipsets you should be able to exceed one limit as long as you dont exceed both but in practice many manufactures implement this as OR rather than AND.
For a list of good chipsets where you can exceed 60k feet as long as your slower than 1000 knots look here:
http://ukhas.org.uk/guides:gps_modules
The "anti-scud" rules require that civilian GPS's cease reporting when the altitude is over about 65,000 ft AND the speed is over Mach 1. Some suppliers read that as an OR, but many don't, and those are the ones that high altitude balloonists use for flights up beyond 130.000 ft (40 km) MSL. This rule would very likely kick in if the GPS were mounted on the LOHAN rocket, however.
What else varies in a well-defined manner with altitude, apart from pressure and temperature? Ozone concentration. A suitable ozone sensor will set you back all of £20 or so.
Here you go:
http://sumaoutlet.com/mq131-ozone-gas-detection-module-gas-sensor-ozone-sensor-module-p-3723.html?zenid=itfhuhkjudlj6u4ug116fqnrg1
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
