back to article Code glitch floored Reg reader altimeter

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 …

COMMENTS

This topic is closed for new posts.
  1. Kevin Johnston

    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.

  2. The Axe
    Thumb Up

    3 mile

    So Neil's code will work 3 miles below the surface as well as 3 miles above the surface. Pretty good going in my books from a fellow embedded firmware engineer

  3. Charlie Clark Silver badge
    Happy

    What are these feet and metres you speak of?

    Surely, if the altimeter had been calibrated to use internationally recognised units such as linguini this "schoolboy error" could never had happened?

  4. TeeCee Gold badge
    Joke

    "...robots that have to work three miles underground...."

    Or -15,840 feet in the air as we like to call it.

  5. Neil Barnes Silver badge

    Negative height

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

  6. Steve Hosgood
    Boffin

    These are not the bugs you're looking for....

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

  7. Robert E A Harvey

    quick - call him back

    I reckon you should ask him to keep the rate-of-climb calculation - the best indication of being at the maximum altitude the balloon can reach will be the rate of climb falling toward zero as the baloon loses the ability to lift.

    1. Steve Hosgood
      Boffin

      Re: quick - call him back

      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.

      1. Evil Auditor Silver badge
        Holmes

        Re: quick - call him back

        Steve, you're right. Except for the -9.81m/s² which will be lower at altitude. (Not that it matters but as you wrote it with that precision I just had to intervene;-)

  8. Remy Redert

    @Robert E A Harvey

    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.

    1. Owain 1

      Re: @Robert E A Harvey

      I may be an idiot, but if we know that the balloon is going to burst due to getting too big, then can't you fit some sort of 'hole' in it so that it loses gas as it rises. Or doesn't that help.

      1. Steve Hosgood
        Go

        Re: @Robert E A Harvey

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

        1. Evil Auditor Silver badge

          Re: @Robert E A Harvey

          @Steve: ...and it is one more thing to add weight, which will set the ceiling for LOHAN at a lower height.

  9. Gav
    Boffin

    Arcane measurements

    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?

    1. Anonymous Coward
      Anonymous Coward

      Re: Arcane measurements

      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!

      1. imanidiot Silver badge

        Re: Arcane measurements

        Addendum: A lot of GA uses meters in Europe. (Gliders, hot-air balloons, paragliders, etc)

      2. druck Silver badge

        Re: Arcane measurements

        Flight levels are in 100s of ft according to the ICAO.

  10. Poor Coco
    Boffin

    Free-fall launch can work.

    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.

  11. Graham Bartlett
    Facepalm

    Coding standards are your friend

    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.

    1. Neil Barnes Silver badge

      Re: Coding standards are your friend

      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.

  12. Steve Hosgood
    Megaphone

    Please stop beating up Neil Barnes!

    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.

    1. imanidiot Silver badge

      Re: Please stop beating up Neil Barnes!

      Once you know you can expect an integer overflow, it shouldn't be to hard to implement a simple wrap around checker to detect this.

    2. Lester Haines (Written by Reg staff) Gold badge

      Re: Please stop beating up Neil Barnes!

      "Neil Barnes generously donated his altimeter to the project to help further progress"

      Absolutely. We're talking about nothing more than a glitch here. Neil has kindly agreed to reprogramme the kit and we'll pop it back in the REHAB chamber...

This topic is closed for new posts.