Contributors
It is so refreshing to see people willing to not only make suggestions for this bit of rocket science but also put their rep on the line with material assistance.
There is hope for the survival of the British Boffin after all.
Reader Neil Barnes says he's nailed the reason his barometric altimeter failed the Rocketry Experimental High Altitude Barosimulator (REHAB) test last week, and is poised to reprogram the device for another pop in our shed-built hypobaric chamber. Click here for a bigger version of the LOHAN graphic To recap, Neil kindly sent …
I should perhaps explain that - when paragliding from a mountain, say - you might want to know your height relative to where you left, particularly if you're planning on coming back to the same place...
In general aviation, there are three heights used: flight levels, which are based on a nominal 1013mB sea level pressure and therefore wanders up and down depending on absolute pressure on the day (but everyone uses the same reference so traffic on the same flight level are at the same height); QNH which gives height above mean sea level but needs to be corrected for pressure in the local area; and QFE which is height above a specified landing field.
QNH and QFE both need to be adjustable based on local pressure; FL is basically QNH with a zero offset. On a high pressure day, you can be a few hundred feet above the beach but below mean sea level...
Dear Reg: You claim "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."
Having just taken a look at the datasheet, I agree - it's a typo. They should have said "...can be performed with unsigned 16-bit variables." They contradict their own statement two line further down the page with "This division can be performed by Bit-wise shifting (divisors are to the power of 2). It is ensured that the results of these divisions are less than 65536 (16-Bit)."
However, this isn't the source of your bug. The "calculations" being mentioned only serve to generate the local air pressure (in mbar). Your software problem is probably in the next stage where you convert from mbar to altitude.
And as you said yourselves - if you'd worked in metres as you should be doing (!) then at least you'd have delayed seeing the problem until an altitude of about 32.768km which is seriously high - about the same height achieved when launching rubber chickens attached to helium balloons.
Away with this "feet" and "inches of mercury" mediaeval fixation, folks. The altimeter chip gives you mbar not in.Hg. Luckily with your "convert to feet" bug, you didn't throw a couple of million quid's worth of rocket into the ocean (or into Mars as NASA did last time they went mediaeval).
True about the rate-of-climb approaching zero, but from what I've seen of helium balloon stratospheric rubber chicken exploits, the balloon usually bursts before it reaches its theoretical maximum height (where rate-of-climb would actually be zero).
At the point the balloon bursts, the rate of climb becomes -9.81m/s²: probably sub-optimal conditions for firing the rocket! I guess the plan is for LOHAN's trigger to go off well below this height.
Except for the part where the balloon won't lose enough lift for that before it bursts due to internal overpressure. If the rate of climb drops to 0, you're already too late with your launch as the balloon has obviously burst.
They should know the pressure at which their helium balloon will burst so they can set the pressure and thus altitude for the launch a bit below that. You could use the rate of climb as a back-up to ensure that if the balloon doesn't make it to the target height for whatever reason and doesn't burst either, LOHAN will still launch.
I believe the Zeppelins had such a thing. If the ship rose above 5000m (IIRC) spring-loaded valves on each of the gas-bags in the ship would start venting hydrogen.
Such an idea might make good sense for the LOHAN project as surely being able to fire the rocket from a stable balloon-supported platform would be good? However, it is one more thing to go wrong....
So why the hell are you using feet?
Seriously people, the UK went metric 40+ years ago. And we're still clinging to this ancient standard? An introduction to the International System of Units and the rest of the scientific community is long past due.
Is the hardware vacuum valves programmed on punch cards?
In aviation feet are still used for altitude in the UK, USA, NZ etc. All the Flight Levels are in Thousands of Feet (or, in fact "500s of feet" here)
The only places that use Metres to measure altitude are the former Eastern Bloc.
Yet, other than in the USA, the altimeters are set using hectoPascals (not millibars anymore ... same thing though!)
A bizarre mix!
If you remove the requirement of the balloon's support from your dynamic equilibrium calculation of launch forces, then your launcher will work equally well before the balloon bursts as after. How do you make a stable platform in free-fall? (1) small stabilizing gyros; (2) design the launcher hardware such that the rocket's thrustline passes through the overall centre of gravity. At this location in the structure, of course, must be located an exhaust vent; but arranged around that location we have various masses (batteries, etc.) such that their collective c.g. lies in the thrust line.
Suppose the balloon has not burst. Then we will have a static or slowly ascending platform as the rocket fires. Since the launcher c.g. is in line with the force separating the objects, their inertia will not rotate the launcher (which is a really important consideration even here; a balloon string would do nothing to stop a sudden rotation of the platform). Also, note that in the static, pre-launch configuration the main masses are concentrated near one another; this does make the design prone to spinning due to a small moment of inertia. However, it also makes the platform easier to stabilize with gyros.
Now, suppose the balloon has just burst. Using some simple zero-G detection system such as a mercury switch, the ignition can be triggered rapidly (before much height is lost or too much downward speed built up). This should allow the engine to fire within, say, 100ms (plus igniter heating time and other delays which are TBD) so we can state with confidence we are as high as we're getting by balloon, and also that our vertical speed is still small. We can also state that the support line's gone slack and it's falling toward the launcher, so launch NOW please. :-)
Since we designed the launcher to be free of torque moments due to launch dynamics, and because the required gyro-stabilizers work in freefall, the platform orientation will be steady over the short term transient effects of the launch (although bets are off for, say, a couple of seconds after separation). The stability of the platform does not care about the balloon's effects for transient phenomena.
This also offers us the opportunity to capture a portion of the exhaust in a controlled manner, thereby offering a degree of control over the separation itself.
All of this can be supplied with low-cost, low-weight options. The gyros are the trickiest parts, mass-wise.
Oh, the old "is your int 16-bit or 32-bit" chestnut. It's only been a solved problem in the software world for, well, not quite forever but certainly for most of the current working generation's life. And the reason is that you never use int unless you have some overridingly critical reason to do so. Like goto, it's "considered harmful", and every company I've ever worked at has had a coding standard which says "thou shalt not use int". Instead you use short or long which have explicitly-defined sizes.
Sure you don't need a coding standard if you're just hacking out random stuff in your bedroom.
But the reason for coding standards isn't (only) to create jobs for the QA people, it's also because staying away from known pitfalls is generally the Right Thing To Do and saves you grief further down the line. So if you're smart, you'll probably do it at home too, and the result will be better code.
Ach, no... there was *no* confusion over the size of the variable. The compiler used a 16-bit int.
The original software was intended to work at altitudes of no more than ten or fifteen thousand feet. A sixteen bit int was, and is, quite suitable for that task and the display routine was designed to work in that range.
When I offered the device to Lester to test, it was in the context of not even thought about for six or seven years. In testing, it not unexpectedly did strange things when used outside it's original design parameters.
Hey folks. Neil Barnes generously donated his altimeter to the project to help further progress. Not nice to slap him around just because the instrument got taken beyond its design goals.
Coding standards like insisting on "long" or "short" in preference to "int" don't guarantee anything (I presume we're talking about C here). Read the C language spec - a C compiler is within its rights to have "short" mean 8 bits, and "long" be 16 bits. Especially for a microcontroller C compiler.
I would suggest to you Neil that if you have to rewrite the mbar->altitude calculation that you do it in metres this time round. You'll have more headroom that way, but you'll still need to work unsigned or you'll be limited to 32.768km. The world height record for a helium balloon is apparently 53km, still well within the range of a 16-bit unsigned.
I can understand why you did altitude in feet for the original application of the instrument, but that was for GA use in Europe for a glider. This is for an unmanned balloon rocketry experiment. No need for mediaeval stuff here.