Frequently Asked Questions

Why is the pyro "on time" of your products only 50 milliseconds?

Altus Metrum flight computers are designed for use with low-current e-matches. The e-matches available for use in the rocketry hobby are mostly designed for use in the fireworks industry, where it's an advantage to retain continuity after firing to allow series strings of matches to be fired on a high-voltage DC ignition system.

The problem this poses for us is that it means battery drain continues for the entire on-interval, even after the pyro device fires. Since many of our products include radio transmitters necessary for helping to find the rocket after flight, "using up" the battery during pyro events limits the time available to locate and recover the rocket after flight. So, our goal is to balance "enough time to be sure we fire the pyro" against "so long we're just running the battery down".

In bench testing some years ago, we measured an average firing time of about 13 microseconds for commercial e-matches using a fully charged single-cell LiPo battery. That led us to choose 50 milliseconds on-time. In practice, this has worked out brilliantly for more than a decade.

Can I change the pyro channel "on time" to something longer?

On all Altus Metrum products, the dedicated apogee and main channels use a fixed 50 millisecond firing interval that can only be changed by modifying the firmware.

On products with programmable channels like TeleMega, EasyMega, and EasyTimer, the programmable channels can have the "on time" set to whatever you want.

What kind of igniters do you support with your electronics?

Altus Metrum in-flight products are designed to work with "low current e-matches". Most often, the ones available at reasonable prices are made for use in the fireworks industry. Local motor vendors tend to know how to get these and other supplies like black powder and are a good place to start. A number of Chinese makers sell e-matches on eBay at extremely reasonable prices, the best search to find them is "fireworks connecting wire".

High-current initiators like Estes igniters, holiday light bulbs, etc, are unlikely to work.

Can I configure and/or update the firmware on a TeleMini v3.0 board over USB?

Conceptually, it's easy. In practice, it's really fiddly, because what you have to play with are 3 small holes in the board on 0.050 inch centers.

Leaving the micro USB connector off is one of the ways we made TeleMini fit in an 18mm tube. But the main system on chip has USB available still, so when he laid out the board, Keith brought the required pins out, thinking it might be helpful in debugging or something, and our software should know what to do if it sees a TeleMini show up on USB.

On one edge of the board, there are 6 holes in a row, one of which has a square pad, though you really have to squint at it to see which pad that is. It's the third pad in from one end, and has 2 round holes on one side and 3 on the other. The side with two is what you care about... they are the USB plus and minus data lines. 3 connections will do it, GND / D+ / D-.

To actually connect to these holes, the quickest hack is probably to take some existing USB A to mini or micro B cable, cut the B connector off, then carefully strip the outer jacket, strip the conductors, twist and tin their stranded leads, and just stick them into the appropriate holes. Note that the usual color code for such cables is black for ground, red for 5V (avoid like the plague getting that near our boards!), green and white for the data lines. On the cables we buy for TeleDongle, et al, green is D+ and white is D-, but sadly not everyone seems to get that right who sells cheap cables. I've never seen anyone mess up the red and black wires. Fortunately, if you get the data lines reversed, it won't hurt anything, it just won't work.

It's going to be a bit of a challenge to keep everything making contact long enough to talk to the board. You might consider finding some 50-mil pitch header pins to solder the wires to so you have a single thing you're putting in and out of the holes. Or maybe some micro grabbers on each wire? If you come up with some great solution, please let us know so we can share the information.

In any case, once you have the USB port wired up, with a battery and power switch hooked up to the board it should show up as a USB device on your computer and you should be able to use altosui to configure it and update the firmware just like any of our other products.

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.