Frequently Asked Questions

What altitude limits exist for the GPS receivers on Altus Metrum products?

The U-blox parts we use perform well in airborne mode, and are the gold standard for hobby rockets. However, series 8 and below reportedly stop reporting above 50km altitude, and series 10 stops reporting above 80km. We do not have flight data from anyone who's gone that high to confirm or deny this, though others report confirming it with GNSS simulation systems.

What do I do about a virus warning when installing AltOS?

As long as you're downloading from altusmetrum.org, any virus or trojan warnings you get, particularly on windows, are false positives.

We build everything from source using only open source tools on a well maintained Linux system, sign all our Windows installers with a Microsoft-approved cryptographic key, and distribute the bits from a well maintained Linux server we own .. so there's really no plausible chance of infection. We're highly confident that there's nothing vile in our code, and there's no way for us to know what about our builds might cause them to appear to still look too much like a virus in the minds of some anti-virus tools.

If your anti-virus tool is complaining, the best thing to do is report this false positive to your vendor. If they hear about it often enough, maybe they'll fix it for you. In the meantime, the only answer we know of is to turn off your anti-virus tools long enough to download and install our software.

Why won't my computer talk to my Altus Metrum product?

Make sure you have a battery and power switch attached, and when you turn on the power switch, the board beeps at you. If not, resolve that first. Note that some products like TeleGPS don't have a beeper, or need a switch attached, but you always need a battery attached to power up the board... a USB cable alone is not sufficient!

You need to have our software installed, you can find the free download here.

Plug a USB cable into the board and your computer.

The next step is to get the board into the right mode. For flight computers with an accelerometer, you need to power up the board in a not-nose-up orientation. For products like EasyMini that do not have an accelerometer, you need to have the USB cable attached to the board at power up to let it know you want to talk to it from your computer instead of going in to pad mode.

Your computer should "see" the board once it powers up and beeps out the battery voltage and then two "dits" (Morse code I) indicating that it's entering idle/interactive mode, followed by the pyro continuity beeps one time only. At that point, you should be able to configure it from our software, etc. If, instead, you hear 'di dah dah dit' (Morse code P) and the continuity beeps repeat every few seconds, the board is in pad mode and you won't be able to talk to it.

By FAR the biggest problem we see are folks trying to use micro USB cables that don't have all the pins connected. Apparently, lots of cables shipped these days for battery charging only have the power and ground pins and just can't be used for actual USB data transfer. We sell a cable that we know works if you can't find one locally.

Don't be afraid to try several USB cables until you find one that works!

Can I fly your products to an apogee over 100k feet?

Our flight computers use a Kalman sensor-fusing filter to estimate the flight state, which consists of three values:

1. Height above ground
2. Vertical speed
3. Vertical acceleration

Apogee is assumed to be where vertical speed crosses zero.

Below 30km altitude (about 100k'), we use both the barometer and the accelerometer to update the flight state, along with a basic Newtonian model of motion. That works super well, pegging apogee within a few sensor samples essentially every time.

Above 30km, the barometric sensor doesn't provide useful data, so we can't use it to update the flight state. Instead, the Kalman filter falls back to a single sensor mode, using only the accelerometer.

At all altitudes, we de-sense the barometric data when we estimate the speed is near or above mach as the sensor is often subjected to significant transients, which would otherwise push the flight state estimates too fast and could trigger a false apogee event.

That means the filter is no longer getting the benefit of two sensors, and relies on just the accelerometer. The trouble with accelerometers is they're measuring the derivative of speed, so you have to integrate their values to compute speed. Any offset error in acceleration measurement gets constantly added to that speed.

In addition, we assume the axial acceleration is actually vertical acceleration; our tilt measurements have enough integration error during coast that we can't usefully use that to get vertical acceleration. Because we don't live in an inertial frame, that means we're mis-computing the total acceleration acting on the airframe as we have to add gravity into the mix, and simply adding that to the axial acceleration value doesn't generate the right value.

The effect of this is to under-estimate apogee when you base the computation purely on acceleration as the rocket flies a parabolic path.

For flights near 100k', all of this works pretty well - you've got the flight state estimates adjusted using the barometric sensor up to 30km, then you're flying on inertial data to apogee.

For flights well above 100k', it's not great; you're usually going fast enough through 100k' that the baro sensor is still de-sensed through the end of its useful range, so the flight state estimates are not as close. After that, as you're flying purely on accelerometer data, there's no way to re-correct the state, so the apogee estimates can be off by quite a bit.

In the worst cases that we've seen, the baro sensor data was wildly incorrect above mach due to poor static port design, leaving the state estimate of speed across the 30km boundary way off and causing the apogee detection to happen far from the correct time.

The good news is that correctly determining apogee is not really all that important at those altitudes; there's so little density that a drogue will have almost no drag anyways. The data we've seen shows a very parabolic path down to about 50k'-60k', even with a recovery system deployed...

So, what we've been recommending is to set up two apogee plans:

1. Use the built-in apogee detection, but add a significant delay (as much as 30 seconds). This will probably fire near enough to apogee to not have a significant impact on the maximum height achieved.

2. Add a back-up apogee which fires after apogee when the height is below about 20-25km. This way, if the flight isn't nominal, and the sustainer ends up reaching apogee in dense air, you aren't hoping the chutes come out before it gets going too fast. And, you get a second pyro channel firing at that altitude even if it reached a higher altitude before.

You can wire these two pyro channels to the same pyro device; you just need to make sure they're wired + to + and - to - (the manual shows which screw terminals are which).

All of this is why we're encouraging people flying way high (like 300k') to find a deployment mechanism which doesn't solely rely on altimeters (like ours) which are designed for modest altitude rocketry. Besides, flights like that probably need active stabilization to make sure they follow the prescribed trajectory so that they don't end up outside the waiver, but that's a whole 'nother adventure...

What do you mean by 'active switch' in the manual?

The only active switch we're aware of is the Featherweight Magnetic Switch.

These need three connections .. a ground, an input, and an output. Of the two switch screw terminals on Altus Metrum products, one is connected to the + side of the battery terminal and is the input to such a switch, the other connects to the output of the switch. Ground can be found on another screw terminal on TeleMega and EasyMega, there's an extra explicit hole you can solder a wire to on TeleMetrum, and all of our products have grounded mounting screw holes.

For a typical, simple, mechanical switch .. you can ignore all this and just connect the two "switch" screw terminals.

What's the maximum current a pyro channel can handle?

Older Altus Metrum products used Vishay Si7232DN FETs as switches. They are rated for 25A continuous, 40A pulsed. Newer products use Taiwan Semiconductor TSM200N03D FETs which are rated for 20A continuous, 80A pulsed. In pyro use, we're closer to the pulsed rating than continuous.

However...

Please note that Ohm's law applies. Whatever your battery voltage is and whatever your e-match or other device's resistance are will limit the actual deliverable current. With a single-cell LiPo battery, the fully charged voltage is 4.2 volts, and a feature of LiPo batteries is that they have very low source resistance, so we can mostly ignore it. A typical e-match has 1.0-1.7 ohms depending on the wire length. The FET on resistance is less than 20 milliOhms, so we can basically ignore that, too. Only the resistance through wiring and the match matters. So, by Ohms law, E = IR, I = E/R or 4.2/1, meaning the most current you can deliver to the pyro element is 4.2 A.

A typical commercial e-match fires in about 13 microseconds under these conditions, which is why we think 50 milliseconds is .. a very long time!

You'd think moving to a 9V alkaline would allow you to deliver 9A, but it doesn't really work that way. Unlike LiPo batteries, Alkaline cells have a very high source resistance and their current producing ability is nowhere near linear. They work fine to fire commercial low-current e-matches, but we strongly prefer LiPo batteries for our own projects.

If you're using a programmable pyro channel on Altus Metrum products that include that capability (TeleMega, EasyMega, EasyTimer) to do something like turn on other electronics, there is an additional consideration. The screw terminal strips we use can handle large peak currents, but are only rated for a maximum of 6A continuous current per screw. This means the best plan if you need to switch something power hungry is to include a high-current FET switch in your electronics, and use our FET to switch just enough current to control it.