We've had sporadic Altus Metrum customer reports about RF susceptibility issues with their TeleMetrum installations. In almost every case, these problems have been completely resolved by either making sure the system battery has sufficient charge before launch, or through the application of standard engineering techniques such as twisting wire pairs to reduce differential coupling. However, even when every technique we could think of had been applied, once in a while someone still had issues.

Around the time of LDRS this year, the incidence of such reports seemed to increase. One customer, in particular, had an installation in which he virtually always saw continuous resets of the board once his 54mm airframe was put on a launch rail, and several customers reported seeing board resets during ejection charge firing. Keith and I saw a board reset during main charge firing happen in person at NCR's Oktoberfest, and with a couple days available to work together after that launch, we decided it was time to figure out what was really going on.

Here's what we've learned.

In bench testing, it quickly became clear that the problem was the 3.3 volt power supply rail getting pulled down far enough to reset the CPU. This most frequently happened during ejection charge firing, when the input of the LDO regulator is pulled down by the near-short presented by the e-match when a pyro FET is turned on. To keep the 3.3 volt rail voltage up during firing, we include a 100uF bulk capacitor on the regulator's output. In all of our prior bench testing, we never saw the 3.3 volt rail droop significantly. Clearly something had changed... or maybe several things had changed?

The first thing I wondered about was whether the new Kalman filtering code, which requires more compute cycles from the processor, might be consuming enough more power to pull the rail down faster during charge firing. After poking around at it, though, we have no data to suggest the new code makes a measurable difference in power consumption.

The next thing we pondered was that at least some of the e-matches we and others are using in the hobby now come from the fireworks industry, where it is apparently considered a feature for the match to retain continuity after firing. This means the input of the LDO gets held down for longer than with the e-matches we used to use and Quest Q2G2 igniters that open when fired. But that still didn't make sense as the root cause, as we chose the FET firing time such that even with a dead short across the igniter terminals, the 3.3 volt rail wouldn't be pulled down far enough to cause trouble during firing.

One of the big changes between v1.0 and v1.1 on TeleMetrum was that the newer boards incorporate a better reset circuit. This helps ensure the GPS chip always comes up running at power on, which was a problem at temperature extremes with older boards. However, a side-effect of this change is that a v1.1 board will reset any time the 3.3 volt rail drops below 3.15 volts, whereas older boards didn't trip until a much lower voltage. So the recent increase in reports might just be related to more v1.1 boards being placed in service?

While experimenting on the bench, we observed that injecting RF energy into the input of the LDO regulator had the effect of pulling down the output voltage, presumably because the internal reference source accumulates charge and is fooled into thinking the output is too high. Since our designs all have the power switch contacts ahead of the LDO, the wires going out to the switch and back are effectively an antenna... as are, to a lesser extent, the wires going to the e-matches. There is some variability from part to part in just how badly the LDO reacts. But by attaching a tuned length of wire as an antenna to the LDO input and playing around, we were finally able to reproduce the problem reliably on a test board at my bench!

On further analysis, we realized that the output of the USB battery charger chip and the input of the LDO both expect a 1uF bypass cap to ground. At some point, those looked redundant and we eliminated one of the two. Unfortunately, we weren't internalizing the fact that the switch leads were between the two caps, and the one we left was on the output of the charger and not at the input of the LDO. Placing a suitable bypass cap right at the input of the LDO turns out to have a truly dramatic effect on RF immunity!

Once we realized that RF getting into the LDO input was the problem, Keith pointed out that we used to see "noise" in the accelerometer data on earlier boards that was caused by the 3.3 volt rail moving slightly during radio transmit, which we fixed with a hardware change on v1.1. We are now convinced that this was at least partly related to RF coupling to the LDO input, not just the change in power consumption on the LDO output. We didn't realize what was going on in earlier testing because we often didn't have ematches wired up, so RF coupling was minimal. But going back to flights logged with v1.0 boards that included deployment, and studying the magnitude of the "steps" in acceleration data observed when the transmitter was on, Keith was able to compute the amount the 3.3 volt rail must have sagged if the real acceleration wasn't changing... which in some cases was as much as 180mV! We think this proves that RFI could cause the LDO to drop its output voltage below the reset controller set point on v1.1 boards.

Based on these observations, I'm making two hardware changes for the next version of TeleMetrum (version 1.2), and Keith is also making a software change. We have tested all of these changes on real boards both on the bench and in test flights, and the net effect is a major improvement in the RF immunity of TeleMetrum.

The first hardware change is moving to a slightly lower trip voltage on the reset controller. Instead of 3.15, the new part trips at 3.00 volts nominal. This gives us more "headroom" to tolerate 3.3 volt rail droop during charge firing, and will allow the board to operate longer on a given battery charge. This change is not relevant for v1.0 and prior.

The second hardware change is adding an appropriate bypass capacitor right at the LDO input. This requires a PCB update, but it's possible for me to update existing production boards by adding an 0402 cap right across the appropriate pins on the regulator chip.

The software change prevents our altimeters from turning on the radio transmitter while an ejection charge is firing. Since the RF transmitter draws substantial additional power, this should help keep the 3.3 volt rail from drooping. This may not really matter, but it feels like the right thing to do. This change will be part of our next stable firmware release.

We think most TeleMetrum customers need not worry about these updates. But if you have seen odd resets on the rail or during ejection charge firing in flight with a TeleMetrum v1.1, feel free to contact me about updating your existing board to include these improvements.

Keith and I released version 1.0.2 of AltOS, the open source firmware and software system associated with our Altus Metrum hobby rocket avionics systems.

This release includes a fix for the defect in version 1.0.1 that prevented rebooting an altimeter from idle to pad mode over the radio link. This affects both TeleMetrum and TeleMini boards, and re-flashing the altimeter firmware is required to pick up this fix.

We also restored the pre-1.0 mode selection behavior for TeleMetrum at power on. This is also an altimeter firmware change, but does not affect TeleMini.

AltOS 1.0 — TeleMini support and a host of new features

Bdale and I are pleased to announce the release of AltOS version 1.0.

AltOS is the core of the software for all of the Altus Metrum products. It consists of cc1111-based microcontroller firmware and Java-based ground station software.

AltOS Firmware — TeleMini support, Kalman Filtering and more

Support for the new TeleMini altimeter is included in version 1.0 along with a wealth of other new features:

• Change telemetry to be encoded in multiple 32-byte packets. This enables support for TeleMini and other devices without requiring further updates to the TeleDongle firmware.

  Previous versions of the firmware used a large monolithic telemetry packet 95 bytes long. The old single-packet format included all of the rapidly updating data coming from the on-board sensors, along with slowly changing GPS data and never-changing configuration data. Not only were the packets large (reducing the reliability of reception), they were also device-specific, encoding precisely the set of information available in TeleMetrum.

  The new telemetry system uses mulitple different formatted telemetry packets, all 32 bytes in length, transmitting rapidly changing data often and other data more slowly. This should improve reception, but more importantly, allows for different devices to send different sets of data.

  Within the TeleDongle, this change was implemented by removing all of the telemetry decoding logic from the embedded device and moving it to the AltosUI java code running on the host. This means that the TeleDongle can now receive arbitrary telemetry packets without having new firmware installed.

• Support operation of TeleMetrum with the antenna pointing aft. Previous firmware versions required the antenna to be pointing upwards, now there is a configuration option allowing the antenna to point aft, to aid installation in some airframes.

  A TeleMetrum user, DK Duncan, changed the firmware on his board to flip the accelerometer ADC values around. This produced something that worked on the ground, so he went and flew it. And it just worked.

  I added this as a configuration option, including all of the Java code to change it. Nice that any Altus Metrum user can try things like this out and then have them get added in the next version of the software.

• Ability to disable telemetry. For airframes where an antenna just isn’t possible, or where radio transmissions might cause trouble with other electronics, there’s a configuration option to disable all telemetry. Note that the board will still enable the radio link in idle mode.

  Terry Lee is taking a TeleMetrum board for a ride during LDRS this year, but with TeleMetrum mixed in with a pile of other electronics, he didn’t want us transmitting during flight and causing potential RFI issues with other boards in the air frame. Instead of building a custom version of the firmware, we just made this a configurable mode.

• Arbitrary frequency selection. The radios in Altus Metrum devices can be programmed to a wide range of frequencies, so instead of limiting devices to 10 pre-selected ‘channels’, the new firmware allows the user to choose any frequency in the 70cm band. Note that the RF matching circuit on the boards is tuned for around 435MHz, so frequencies far from that may reduce the available range.

• Kalman-filter based flight-tracking. The model-based sensor fusion approach of a Kalman filter means that AltOS now computes apogee much more accurately than before, generally within a fraction of a second. In addition, this approach allows the baro-only TeleMini device to correctly identify Mach transitions, avoiding the error-prone selection of a Mach delay.

  Developing this feature made extensive use of the simulator which runs the flight management code using sensor data captured on previous flights. Somehow, we’ve managed to collect log data from over 100 flights; replaying them on the ground means that even before the first flight with the new firmware, we were confident that it would work.

AltosUI — New Features

AltosUI has also seen quite a bit of work for the 1.0.1 release. Of course, many of the changes in AltosUI are to accomodate the new TeleMini altimeter and changes in the AltOS firmware for TeleMetrum. In addition, we’ve also added lots of new features in response to user requests.

• Add main/apogee voltage graphs to the data plot. This provides a visual indication if the igniters failed before being fired.

• Scan for altimeter devices by watching the defined telemetry frequencies. This avoids the problem of remembering what frequency a device was configured to use, which is especially important with TeleMini which does not include a USB connection.

  

• Monitor altimeter state in “Idle” mode. This provides much of the information presented in the “Pad” dialog from the Monitor Flight command, monitoring the igniters, battery and GPS status withing requiring the flight computer to be armed and ready for flight.

• Pre-load map images from home. For those launch sites which don’t provide free Wi-Fi, this allows you to download the necessary satellite images given the location of the launch site. A list of known launch sites is maintained at altusmetrum.org which AltosUI downloads to populate a menu; if you’ve got a launch site not on that list, please send the name of it, latitude and longitude along with a link to the web site of the controlling club to the altusmetrum mailing list.

  

• Flight statistics are now displayed in the Graph data window. These include max height/speed/accel, average descent rates and a few other bits of information. The Graph Data window can now be reached from the ‘Landed’ tab in the Monitor Flight window so you can immediately see the results of a flight.

  

TeleMini Dual-deploy altimeter with telemetry now available

TeleMini is a miniature dual-deploy flight computer with data logging and radio telemetry. Small enough to fit comfortably in an 18mm tube, this powerful package does everything you need on a single board:

• 5kB on-board data logging memory.

• 70cm ham-band digital transceiver for in-flight telemetry and on-the-ground configuration.

• Transmitted telemetry includes altitude, speed, acceleration, flight state, igniter continutity, temperature and battery voltage. Monitor the state of the rocket before, during and after flight.

• Radio direction finding beacon transmitted during and after flight. This beacon can be received with a regular 70cm Amateur radio receiver.

• Barometer accurate to 45k’ MSL. Reliable apogee detection, independent of flight path. Barometric data recorded on-board during flight.

• Dual-deploy with adjustable apogee delay and main altitude. Fires standard e-matches and Q2G2 igniters.

• 0.5” x 1.5”. Fits easily in an 18mm tube.

• Uses rechargeable Lithium Polymer battery technology. All-day power in a small and light-weight package.

• Learn more at http://www.altusmetrum.org/TeleMini/

I don’t have anything in these images to show just how tiny this board is—but the spacing between the screw terminals is 2.54mm (0.1in), and the whole board is only 13mm wide (1/2in).

We’ve been flying these for quite a while; testing the hardware and tuning the firmware. My new 29mm mmt airframe, Koala, sports a TeleMini board for apogee-only deployment. It’s been really nice to have something flying on G’s and H’s that doesn’t depend on the vagaries of delay grains.

AltOS 0.9.2 — Minor update to ground station software

Bdale and I are pleased to announce the release of AltOS version 0.9.2.

AltOS is the core of the software for all of the Altus Metrum products. It consists of cc1111-based microcontroller firmware and Java-based ground station software.

AltosUI — Just a few bug fixes

AltOS version 0.9.2 is a minor release with just a couple of fixes:

• Mac OS X graphing repaired. The 0.9 release was missing a file required to support the graphing feature (jcommon.jar). This has been added.

• Fixed multiple flight log downloading. Attempts to download more than one recorded flight log would fail in weird ways. The failures have been addressed and additional diagnostics are presented when things go wrong.

• You can see the AltOS version number in the ‘Configure AltosUI’ dialog box now. This should make it easier to tell what you’ve got installed.

• Post-flight graphing tool. This lets you explore the behaviour of your rocket after flight with a scroll-able and zoom-able chart showing the altitude, speed and acceleration of the airframe along with events recorded by the flight computer. You can export graphs to PNG files, or print them directly.

No Firmware Update

AltOS version 0.9.2 does not include any firmware changes. We’re still busy testing the Kalman filter code; that’ll be in the next major release.

AltOS 0.8 — New Software and Firmware for Altus Metrum Devices

Bdale and I are pleased to announce the release of AltOS version 0.8.

AltOS is the core of the software for all of the Altus Metrum products. It consists of cc1111-based microcontroller firmware and Java-based ground station software.

AltosUI — New Features in the AltusMetrum Ground Station

AltOS version 0.8 contains significant upgrades to the ground station software, AltosUI:

• Post-flight graphing tool. This lets you explore the behaviour of your rocket after flight with a scroll-able and zoom-able chart showing the altitude, speed and acceleration of the airframe along with events recorded by the flight computer. You can export graphs to PNG files, or print them directly.

• Real-time moving map which overlays the in-progress flight on satellite imagery fetched from Google Maps. This lets you see in pictures where your rocket has landed, allowing you to plan recovery activities more accurately.

• Wireless recovery system testing. Prep your rocket for flight and test fire the deployment charges to make sure things work as expected. All without threading wires through holes in your airframe.

• Optimized flight status displays. Each flight state now has it’s own custom ‘tab’ in the flight monitoring window so you can focus on the most important details. Pre-flight, the system shows a set of red/green status indicators for battery voltage, apogee/main igniter continutity and GPS reception. Wait until they’re all green and your rocket is ready for flight. There are also tabs for ascent, descent and landing along with the original tabular view of the data.

• Monitor multiple flights simultaneously. If you have more than one TeleDongle, you can monitor a flight with each one on the same computer.

• Automatic flight monitoring at startup. Plug TeleDongle into the machine before starting AltosUI and it will automatically connect to it and prepare to monitor a flight.

• Exports Google Earth flight tracks. Using the Keyhole Markup Language (.kml) file format, this provides a 3D view of your rocket flight through the Google Earth program.

Continuing Features

AltOS version 0.8 continues to provide the following features:

• Receive and log telemetry from a connected TeleDongle device. All data received is saved to log files named with the current date and the connected rocket serial and flight numbers. There is no mode in which telemetry data will not be saved.

• Download logged data from TeleMetrum devices, either through a direct USB connection or over the air through a TeleDongle device.

• Configure a TeleMetrum device, setting the radio channel, callsign, apogee delay and main deploy height. This can be done through either a USB connection or over a radio link via a TeleDongle device.

• Replay a flight in real-time. This takes a saved telemetry log or eeprom download and replays it through the user interface so you can relive your favorite rocket flights.

• Reprogram Altus Metrum devices. Using an Altus Metrum device connected via USB, another Altus Metrum device can be reprogrammed using the supplied programming cable between the two devices.

• Export Flight data to a comma-separated-values file. This takes either telemetry or on-board flight data and generates data suitable for use in external applications. All data is exported using standard units so that no device-specific knowledge is needed to handle the data.

• Speak to you during the flight. Instead of spending the flight hunched over your laptop looking at the screen, enjoy the view while the computer tells you what’s going on up there. During ascent, you hear the current flight state and altitude information. During descent, you get azimuth, elevation and range information to try and help you find your rocket in the air. Once on the ground, the direction and distance are reported.

AltOS Firmware Update

AltOS version 0.8 contains a minor firmware update for TeleMetrum to resolve an issue with main deployment. A mis-feature in the igniter firing code would delay main deployment by 2 seconds in some cases.

Thanks to our contributors!

We had a lot of help with this release:

• Anthony Towns wrote both the new data graphing interface and the moving map display.

• Bob Finch helped clean up our documentation, and provided flight testing for the firmware updates.

Future Plans

A number of features are implemented or in process in the sources available in our publicly visible repository that are not part of the current stable release.

• A Kalman-filter based approach to apogee detection using more than just the baro sensor, so that we can safely control apogee ejection on flights to altitudes beyond the range of our baro sensor alone. Unlike the other items on the list, this will be a significant change to the in-rocket TeleMetrum firmware. It may therefore be a while before this becomes part of a stable firmware release.

• Motor characterization. Because TeleMetrum contains a high-resolution, high-frequency accelerometer, it is possible to take the data from that and compute an accurate thrust curve for the motor.

• Comprehensive PDF and/or HTML -based flight report. Construct a complete report of the flight suitable for publication on the web that includes graphs of the flight and details about motor performance etc.

• Publish flight data to the Altus Metrum web site. This will allow you to share your flight data with others, and let you download flights published by others.

There are any number of additions that could be made to this list; feel free to send along ideas that you’ve got. Of course, all of this software is licensed under the GNU General Public License, so you can get the source and hack on it in the comfort of your own home.

Keith and I just released version 0.8 of AltOS, the open source firmware and software system associated with our TeleMetrum hobby rocket avionics system.

The AltosUI ground station user interface is significantly improved, with lots of new features including a much cleaner view of what's happening during different stages of the flight experience, a post-flight data plotting interface with pan and zoom, and a very cool live view of where the rocket is overlayed on data from Google Maps! All existing TeleMetrum owners are encouraged to download, install, and begin using this new version immediately.

The PSAS team planned to have their LV2.3 airframe updates ready for BALLS this year, but RL interfered and they weren’t ready to go on time. A quick bit of rescheduling and we decided to fly over the weekend of the 16-17 of October.

Tsolo and family welcomed us warmly as we arrived on Saturday afternoon after driving over from Portland. They’ve got a new puppy who is also cute and friendly.

We managed to get the launch tower and flight operations set up before dark, cooked dinner and spent the evening prepping the airframe. It was cold overnight, but the light cloud cover that had been there when we arrived was nearly gone by morning. I called in to open the waiver and was asked to hold until noon, which suited us just fine.

The rocket finally made it onto the rail around 1:30 and we managed to convince the launch controller to actually light the motor at 2:44:39 (according to the GPS data). Flying on a CTI N2850 blue-streak, LV2.3 hit about 380m/s and reached 4851m.

This was the first flight with the new fin system, you can see how that works in the video here:

Portland State Aerospace LV2.3 flight with roll control from Keith Packard on Vimeo.

The roll control system worked as designed, executing a programmed sequence of maneuvers during ascent. You can see the canard fins moving back and forth in the video, controlling the roll of the airframe.

Yes, the fins really do spin separately from the airframe. You can see how that was constructed here:

PSAS LV2.3 Spin Can

Live telemetry and stored flight data, consisting of GPS coordinates along with barometry altimeter and accelerometer information, was collected using the TeleMetrum flight computer. The airframe was recovered about 800m downrange.

Thanks to Portland State University for their support in hosting PSAS and Oregon Rocketry for letting us fly at their launch site.

AltOS — The Altus Metrum Operating System

Altos is the core of the software for all of the Altus Metrum products. It runs on the 8051-based micro-controllers within both the flight computer and the ground station devices. AltOS a small cooperatively multi-tasking operating system.

AltOS Version 0.7.1 Released

Bdale and I have just released AltOS version 0.7.1. Version 0.7.1 is the first release to include the new Java-based ground station software which runs on Linux, Mac OS X and various Windows flavors.

AltOS Changes in 0.7.1

1. Deal with Windows and Mac OSX USB stacks. These two operating systems do “interesting” things with USB and found some boundary conditions within the AltOS USB stack which couldn’t be tested on Linux. With test cases discovered, the ‘panic’ calls were turned into code that dealt with these cases correctly.

2. Increase packet mode payload size and add callsigns. The callsigns are set by the ‘master’ end of the packet link (normally the TeleDongle) so that the entire radio conversation conforms to regulatory requirements. Increasing the payload size makes data transfers go faster.

3. Place configuration data in fixed flash addresses. This change makes it possible to read the serial number and radio calibration data back out of the flash data when reprogramming a device.

TeleMetrum Changes in 0.7.1

1. Ensure GPS date information is written to on-board data logger. The GPS date information is used when constructing eeprom log file names; without this, the eeprom downloading tool would generate a filename based on the current date.

2. Allow TeleMetrum to be used as a programming dongle. This means the user can reprogram a TeleDongle or another TeleMetrum using the TeleMetrum as a programming dongle. Before this, only the TeleDongle could be used to program other devices.

AltosUI - Ground Station Software for Altus Metrum devices

Version 0.7.1 is the first release containing our new cross-platform Java-based user interface. AltosUI can:

• Receive and log telemetry from a connected TeleDongle device. All data received is saved to log files named with the current date and the connected rocket serial and flight numbers. There is no mode in which telemetry data will not be saved.

• Download logged data from TeleMetrum devices, either through a direct USB connection or over the air through a TeleDongle device.

• Configure a TeleMetrum device, setting the radio channel, callsign, apogee delay and main deploy height. This can be done through either a USB connection or over a radio link via a TeleDongle device.

• Replay a flight in real-time. This takes a saved telemetry log or eeprom download and replays it through the user interface so you can relive your favorite rocket flights.

• Reprogram Altus Metrum devices. Using an Altus Metrum device connected via USB, another Altus Metrum device can be reprogrammed using the supplied programming cable between the two devices.

• Export Flight data to a comma-separated-values file. This takes either telemetry or on-board flight data and generates data suitable for use in external applications. All data is exported using standard units so that no device-specific knowledge is needed to handle the data.

• Speak to you during the flight. Instead of spending the flight hunched over your laptop looking at the screen, enjoy the view while the computer tells you what’s going on up there. During ascent, you hear the current flight state and altitude information. During descent, you get azimuth, elevation and range information to try and help you find your rocket in the air. Once on the ground, the direction and distance are reported.

Three Operating Systems, One AltosUI

AltosUI provides all of these features on the three target operating systems, Linux, Mac OS X (version 10.5 or newer) and Windows (XP, Vista or 7). The bulk of the software is written in Java and is built once and tested and delivered on all three target platforms. A tiny ‘shim’ library is built on each system to provide access to the Altus Metrum devices connected over the USB link.

Thanks to our contributors!

We’ve gotten lots of help getting this software built and tested:

• Tim Van Milligan at Apogee Components helped shake out portability and installation issues on Mac OS X and Windows Vista

• Adrian Adamson from Featherweight Altimeters helped with Windows install adventures as well as fixing data export from telemetry files after unfortunately losing eeprom data in a field in Kansas.

• Bob Finch has written a bunch of our documentation, provided packaging files for Arch Linux along with helping debug general Linux compatibility issues.

Future Plans

With the basic AltOS and AltosUI functionality running, we’ve got lots of ideas about where to take the system in the future. And, we’d love to hear ideas from you as well. Some of the ideas we’ve like to get done include:

1. Google Earth file export. We had a Linux-based C program to export a ‘KML’ (Keyhole Markup Language) file that Google Earth can read and present to the user overlayed on satellite photo data.

2. Data Plotting. Being able to plot flight data right in the UI would be nice, and there are several Java plotting packages available to try out.

3. State-dependent display. When the rocket is on the pad, you only want to know if it’s ready to fly. When the rocket is descending on a chute, you want to know where it is in the sky and how fast its falling. Presenting a limited amount of information that is most likely interesting to the user should make the display more useful.

4. Ejection charge testing. The TeleMetrum firmware has the ability to fire ejection charges over the USB or radio links. Safely hooking this up to the user interface will allow for wireless ejection system testing. The key here is “safely”, of course, which means figuring out a ‘fool proof’ user interface.

I’m sure there are any number of additions that could be made to this list; feel free to send along ideas that you’ve got. Of course, all of this software is licensed under the GNU General Public License, so you can get the source and hack on it in the comfort of your own home.

About a week ago, Altus Metrum announced that our 2nd generation ground software was available, and that it runs identically on Linux, Mac, and Windows computers.

Thanks to feedback from early users of this new software, particularly those who flew rockets at various sites over the holiday weekend and reported on their experiences, we're found and fixed several bugs, and made a significant improvement to the Windows installation experience.

Version 0.7.1 is now available for download from our AltOS page. All existing TeleMetrum owners are encouraged to download, install, and begin using this new version immediately.